[Bug 26552] New: [Shadow]: consider supporting :first-child, nth-child() in content select
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26552 Bug ID: 26552 Summary: [Shadow]: consider supporting :first-child, nth-child() in content select Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: tomalec...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org 3.6 Satisfying Matching Criteria Consider following case. Custom Element that extends ordered list(, and creates a pyramid of news) my-article-list shadow root: div class=lead h1Breaking news:/h1 content select=:first-child/content /div div class=asides content select=:nth-child(2)/content content select=:nth-child(3)/content /div div content/content /div And input should look like: my-article-list articleMost important article/article articleImportant article/article articleImportant article/article articlearticle/article ... /my-article-list Without those pseudo-classes my-articles-list needs to modify light DOM, or at least CSS properties of child nodes, which seems very intrusive to me. Use of .first, .second, ... classes also does not seem right. As the user of my-article-list should now be aware how long should he count, and as for ordered list nodes order already serves this information. I know that it was removed via 21924, but unfortunately I have no idea how hard it would be to implement it, and how it could affect performance. I just guess it could be not much worse than `:not()`. -- You are receiving this mail because: You are on the CC list for the bug.
Re: File API: reading a Blob
On Fri, Aug 8, 2014 at 5:56 PM, Arun Ranganathan a...@mozilla.com wrote: I strongly think we should leave FileReaderSync and FileReader alone. Also note that FileReaderSync and XHR (sync) are not different, in that both don’t do partial data. But we should have a stream api that evolves to read, and it might be something off Blob itself. Seems fair. Other than “chunks of bytes” which needs some normative backbone, is the basic abstract model what you had in mind? If so, that might be worth getting into File APi and calling it done, because that’s a reusable abstract model for Fetch and for FileSystem. Yeah that looks good. https://whatwg.github.io/streams/ defines chunks and such, but is not quite there yet. But it is what we want to build this upon eventually.
Re: Screen Orientation Feedback
On Fri, Aug 8, 2014 at 6:44 AM, Mounir Lamouri mou...@lamouri.fr wrote: Maybe this feedback should be more for DeviceOrientation than Screen Orientation. There has been a few discussions there (public-geolocation). This is the type of procedural issues that I'd really rather not get caught in. I think it's fine to defer to the DeviceOrientation spec, but only if we think there's any chance of it getting added there anytime soon. Given that no drafts, to my knowledge, has been published for a DeviceOrientation v2, that does not seem to be the case. Anyway. I am not convinced that adding new properties will really fix how developers handle this. I asked around and it seems that native platforms do not expose Device Orientation relative to the screen. I am not sure why we should expose something different on the Web platform. I don't think the fact that other platforms do not supply screen relative orientation events is a strong technical argument for why we shouldn't. I'm definitely in favor of looking at what other platforms do, but not with the mindset that what other platforms do is the right thing to do, but rather to see if they have good solutions that we could learn from. Surely other platforms will make design mistakes, just like we do. I think we should work on providing developers the right tools in order for them to do the right thing. I totally agree with this. For all the use cases that I can think of for getting the coordinates relative to the screen is more important than relative to the device. This includes: * A navigation page which shows a map as well as how the device is oriented relative to the map. * A navigation page which shows a map orientated so that the on-screen map matches real world. * A game where an in-game character is controlled by tilting the device left and right to make the character walk left vs. right. I'm sure there are use cases where you need to know the orientation relative to the device rather than relative to the screen, they just seem to be less common to me. Given that, the right tool seems to be to provide the DeviceOrientation events relative to the screen and allow them to be compensated to be relative to the device if needed. Sadly it's too late for that. Authors already have the wrong tool as a default since the DeviceOrientation spec is written and implemented the way it is. However we can at least give authors the right tool as well, by introducing screeAlpha etc. For example, without the Screen Orientation API, they do not know the relative angle between the device natural orientation and the screen. This API is not yet widely available. Some version of it ships in Firefox and IE but is prefixed. It should be in Chrome Beta soon. I don't think the right tool to do the right thing in this case means give them coordinates in a coordinate system that they don't want, and then give them enough information to transform the coordinate into the coordinate system that they do want. I'm not arguing that we remove the relative angle that's in the spec right now. I'm arguing that for device orientation events, we should provide coordinates relative to the screen as well. / Jonas
Re: Blocking message passing for Workers
On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com wrote: This topic is on people minds [1]. My understanding of where we're at is that ECMAScript 7 will bring syntax (async/await keywords [2]) that looks like sync syntax, but acts asynchronously. This should eliminate the need for web devs for blocking message passing primitives for workers. Syntax sugar around async is not a replacement for synchronous APIs. I personally hope it won't happen as it would be a step backwards. Blocking communication (cross-thread/process/computer) was a mistake. We need a culture shift. The browser and Node.js are a step in the right direction (they did not initiate it, but helped popularize it). The problem wasn't that synchronous programming is bad, the problem was that synchronous code in the UI thread blocks UI, and the solution to that is asynchronous programming. Saying therefore all synchronous programming is bad is a very deep misunderstanding of the issue. -- Glenn Maynard
Re: Blocking message passing for Workers
Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: This topic is on people minds [1]. My understanding of where we're at is that ECMAScript 7 will bring syntax (async/await keywords [2]) that looks like sync syntax, but acts asynchronously. This should eliminate the need for web devs for blocking message passing primitives for workers. Syntax sugar around async is not a replacement for synchronous APIs. I have yet to find a use case for hand-written code that requires sync APIs and cannot be achieved with async programming. I personally hope it won't happen as it would be a step backwards. Blocking communication (cross-thread/process/computer) was a mistake. We need a culture shift. The browser and Node.js are a step in the right direction (they did not initiate it, but helped popularize it). The problem wasn't that synchronous programming is bad, the problem was that synchronous code in the UI thread blocks UI, and the solution to that is asynchronous programming. Saying therefore all synchronous programming is bad is a very deep misunderstanding of the issue. If you block on workers, you'll mechanically need more workers. That's what happened with Apache that was spawning more threads as more HTTP requests were coming because the existing threads were busy waiting for blocking I/O. David
Re: Blocking message passing for Workers
Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: There is still a case for blocking primitives for projects that compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3]. I'm glad to be switching last night's twitter discussion to a bigger medium. My question here is: what is the proposal (if there is any) to balance these and simultaneously ensure that we don't wind up limiting ourselves or providing really bad foot guns or two APIs depending on whether you're in the main thread or a worker? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. David
Re: Blocking message passing for Workers
David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: There is still a case for blocking primitives for projects that compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3]. I'm glad to be switching last night's twitter discussion to a bigger medium. My question here is: what is the proposal (if there is any) to balance these and simultaneously ensure that we don't wind up limiting ourselves or providing really bad foot guns or two APIs depending on whether you're in the main thread or a worker? There isn't such proposal and I don't think that can exist which is one reason I'm opposed to the introduction of blocking primitives in workers. I really hope the compile-to-JS use cases will find another way to be solved. There is no other way. Why are you arguing from dogma instead of reason? There's no *reason* to say worker overhead is so expensive we should not allow authors to create more workers as needed when some block (temporarily, let's hope on non-main-thread sync input operations? /be
Re: Blocking message passing for Workers
On Mon, Aug 11, 2014 at 7:52 PM, David Bruant bruan...@gmail.com wrote: Le 12/08/2014 00:40, Glenn Maynard a écrit : On Sat, Aug 9, 2014 at 9:12 AM, David Bruant bruan...@gmail.com wrote: This topic is on people minds [1]. My understanding of where we're at is that ECMAScript 7 will bring syntax (async/await keywords [2]) that looks like sync syntax, but acts asynchronously. This should eliminate the need for web devs for blocking message passing primitives for workers. Syntax sugar around async is not a replacement for synchronous APIs. I have yet to find a use case for hand-written code that requires sync APIs and cannot be achieved with async programming. Asynch complicates diagramming and modelling because you need a state machine instead of a simple ladder diagram. One of the reasons cited for the heartbleed failure was standards imposed complexity. Forcing async when sync will suffice surely complicates some programs. I also find it easier to audit the latter. Jeff
RE: User Intentions Explainer (was: List of Intentions)
I agree with this. We should have a single 'shape' for these events and shared terminology. I think trying to solve all of the problems in one complete spec would be too complex, but if we use an Intentions Explainer to divide the problem into manageable pieces, we can continue on our trajectory of creating these events for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps other user interactions. Are there objections to this approach? If not, I will begin to adapt the Commands Explainer into a more generic Intentions Explainer. -Original Message- From: Jason White [mailto:ja...@jasonjgw.net] Sent: Saturday, August 9, 2014 4:56 PM To: public-indie...@w3.org Cc: public-editing...@w3.org; public-webapps@w3.org Subject: Re: User Intentions Explainer (was: List of Intentions) [Cross-posting the comments below per Janina's thoughtful request.] I concur with Janina's insightful remark [at the Indie-UI teleconference on Thursday] that the explainer could evolve into a (potentially cross-group) requirements document. This raises several issues. 1. Harmonization of terminology. We're already seeing differences between the terminology used by WEB Apps in connection with editing and our own terms for similar concepts, e.g., abstract events and intentions. Naming conventions for events aren't harmonized either. 2. Whether there should ultimately be one spec or several, and where the division should lie, is obviously up for discussion. Given the progress we've made to date, it makes good sense that support for interactive editing could reside in its own spec, with its own development schedule. This, after all, is work that we anticipated in Indie-UI but postponed. 3. If there are two or more specs to be produced in this area, we should provide appropriate cross-references (perhaps a non-normative reference in each spec to the requirements would be sufficient), so that user agent and Web application implementors alike can readily appreciate the relationships between the technologies described in the respective documents. My main concern at this point is that the designs be consistent and that terminology be unified wherever possible.
Re: Proposal for User Agent Augmented Authorization
In response to feedback, I have tightened the purpose of the API to: 1) making Oauth-based authentication work better for web apps by 2) augmenting existing redirect and cookie policies so as to 3) enable single sign on and 4) enable identity management interfaces in user agents. To that end, I put forward the following strawman API for RPs: - navigator.auth.authenticate(providerOne, providerTwo=null, ...) - onSignInChanged.addListener(function(accountObject, isSignedIn=false){}) authenticate() takes a non-empty sequence of objects (one for each IdP the RP wishes to support) holding Oauth URIs: - {authURL: string, returnURL: string, interactive: true} and a third optional property interactive, defaulting to true (following Chrome's Identity API). If interactive is false, then no login UX will be triggered, and the returnURL will only be called if the user is already signed in. onSignInChanged, also following the Chrome Identity API, MAY be fired by the user agent on sign out. Here is a strawman API for IdPs: - Account = {} // Opaque to user agent; properties per IdP. - navigator.auth.getAccounts() // Currently signed in accounts for this IdP. - navigator.auth.addAccount(account) // A newly signed in Account. - navigator.auth.signOut(accountIdPropertyName, accountIdValue, rpURL=null) signOut walks the sequence returned by getAccounts looking for exactly one blob with the specified property/value pair. If it is found, then for the optionally specified RP or for all RPs, the user agent should fire onSignInChanged. Note that the user agent can't force the RP to comply, though the IdP can of course invalidate its token. I have also provided a strawman API for user agent identity management UIs; it seems shakier to me. Expect updates. Feedback welcome via list or: https://github.com/SamPenrose/ua-augmented-auth/issues Thanks, Sam - Original Message - From: Sam Penrose spenr...@mozilla.com From: Marc Fawzi marc.fa...@gmail.com Probably a naive comment, but I'm curious and interested in learning since it's one thing that's been missing from browsers: Does your last comment mean that you'd be baking in dependency on a certain auth standard in the user agent? What happens when the part of the authentication model that is outside the user-agent has a breaking change but not every website updates to that version? By augmented do you mean it's an additional optional layer? Great question. My goal is to avoid that category of breakage as much as feasible. Per the comment you were responding to, I'm going to propose that the best way to do that is to stick with HTTP objects (URIs, cookies), but allow the User Agent to augment the result with contextual knowledge unavailable via GET and SET-COOKIE. Expected an updated proposal, and thanks again to all of you who have responded. On Wed, Aug 6, 2014 at 7:02 PM, Sam Penrose spenr...@mozilla.com wrote: I wrote some user stories for RPs and IdPs with your comments in mind, and it feels like I may have taken the initial cut of the API too far from HTTP semantics: https://github.com/SamPenrose/ua-augmented-auth/issues/9 It also feels like the API and stories need a second protocol, or at least a second Oauth implementation, to firm them up. I'm going to look at $MAJOR_SOCIAL_NETWORK_FEDERATED_AUTH. If anyone can suggest specific HTTP-based protocols to consider*, I'd be much obliged. Expect a revised proposal after a couple clock days of work; calendar ETA TDB. * IndieAuth was suggested here: https://github.com/SamPenrose/ua-augmented-auth/issues/1 - Original Message - From: Sam Penrose spenr...@mozilla.com To: Mike West mk...@google.com Cc: Webapps WG public-webapps@w3.org Sent: Wednesday, August 6, 2014 10:52:52 AM Subject: Re: Proposal for User Agent Augmented Authorization - Original Message - From: Mike West mk...@google.com Hey Sam, this looks interesting indeed! Thanks for the very helpful comments. My main takeaway is that I have failed to communicate the use cases we are trying to solve. I really appreciate your getting down into the weeds of my proposal; you would have had less work to do if I had put clear user stories up front. I will remedy that. It's not clear to me how this proposal interacts with the credential management proposal I sent out last week. Does the following more or less describe the integration you're thinking about, or have I completely misunderstood the proposal? I haven't thought of a specific integration yet, but to be crystal clear: I am not proposing a *replacement* for Credentials Management as you have defined it. It may be that UAA is a vague, handy-wavy, redundant abstraction of what you've so specifically laid out with CM. Or it may be that