[Bug 26552] New: [Shadow]: consider supporting :first-child, nth-child() in content select

2014-08-11 Thread bugzilla
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

2014-08-11 Thread Anne van Kesteren
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

2014-08-11 Thread Jonas Sicking
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

2014-08-11 Thread Glenn Maynard
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

2014-08-11 Thread David Bruant

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

2014-08-11 Thread David Bruant

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

2014-08-11 Thread Brendan Eich

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

2014-08-11 Thread Jeffrey Walton
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)

2014-08-11 Thread Ben Peters
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

2014-08-11 Thread Sam Penrose
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