Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-05 Thread Ryosuke Niwa

 On May 5, 2015, at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
 On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote:
 On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org 
 wrote:
 We can solve this
 problem by running the distribution code in a separate scripting context
 with a restricted (distribution specific) API as is being discussed for
 other extension points in the platform.
 
 That seems like a lot of added complexity, but yeah, that would be an
 option I suppose. Dimitri added something like this to the imperative
 API proposal page a couple of days ago.
 
 
 One thing to consider here is that we very much consider distribution a
 style concept. It's about computing who you inherit style from and where 
 you
 should be in the box tree. It just so happens it's also leveraged in event
 dispatch too (like pointer-events). It happens asynchronously from DOM
 mutation as needed just like style and reflow though.
 
 I don't really see it that way. The render tree is still computed from
 the composed tree. The composed tree is still a DOM tree, just
 composed from various other trees. In the open case you can access
 it synchronously through various APIs (e.g.  if we keep that for
 querySelector() selectors and also deepPath).
 
 I agree. I don't see any reason node distribution should be considered as a 
 style concept. It's a DOM concept. There is no CSS involved here.
 
 Yes there is.  As Elliot stated in the elided parts of his quoted
 response above, most of the places where we update distribution are
 for CSS or related concerns:
 
 # 3 event related
 # 3 shadow dom JS api

These two are nothing to do with styles or CSS.

 I have issues with the argument that we should do it lazily.  On one hand, 
 if node distribution is so expensive that we need to do it lazily, then it's 
 unacceptable to make event dispatching so much slower.  On the other hand, 
 if node distribution is fast, as it should be, then there is no reason we 
 need to do it lazily.
 
 The problem is really the redistributions. If we instead had explicit 
 insertion points under each shadow host, then we wouldn't really need 
 redistributions at all, and node distribution can happen in O(1) per child 
 change.
 
 As repeatedly stated, redistribution appears to be a necessity for
 composition to work in all but the most trivial cases.

Where?  I have not yet to see a use case for which selective redistribution of 
nodes (i.e. redistributing only a non-empty strict subset of nodes from an 
insertion point) are required.

- R. Niwa




Re: Permissions API vs local APIs

2015-05-05 Thread Anne van Kesteren
On Wed, May 6, 2015 at 12:32 AM, Mike West mk...@google.com wrote:
 I agree with Jonas. Extending the permission API to give developers a single
 place to check with a single consistent style seems like the right way to
 go.

Yet others at Google are pushing the expose them twice strategy...
Perhaps because the Permissions API is not yet ready?


-- 
https://annevankesteren.nl/



Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-05 Thread Anne van Kesteren
On Wed, May 6, 2015 at 3:22 AM, Ryosuke Niwa rn...@apple.com wrote:
 Where?  I have not yet to see a use case for which selective redistribution 
 of nodes (i.e. redistributing only a non-empty strict subset of nodes from an 
 insertion point) are required.

Isn't that what e.g. select does? That is, select only cares about
option and optgroup elements that are passed to it.


-- 
https://annevankesteren.nl/



Re: :host pseudo-class

2015-05-05 Thread Anne van Kesteren
On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 It's certainly no weirder, imo, than having a pseudo-element that
 doesn't actually live in any element's pseudo-tree, but instead just
 lives in the normal DOM, but can only be selected by using a
 pseudo-element selector with no LHS.  Pseudo-elements are fucked,
 unfortunately, but we have to live with their quirks, and those quirks
 make them really bad for this particular case.

Why?

And again, from the perspective of the shadow tree, the host element
is not part of its normal DOM. The shadow tree is its normal DOM. This
is the same as ::-webkit-range-thumb. From the perspective of the
light DOM, that element is not part of its normal DOM. But it is part
of the composed DOM.


-- 
https://annevankesteren.nl/



[Bug 28614] New: Weaken the requirement of the time of running async steps

2015-05-05 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28614

Bug ID: 28614
   Summary: Weaken the requirement of the time of running async
steps
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Fullscreen
  Assignee: ann...@annevk.nl
  Reporter: quanxunz...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

For requestFullscreen() and exitFullscreen(), the current spec requires UAs to
execute the async steps as part of the next animation frame task.

I propose that UAs should be allowed to decide when to run those steps, instead
of being forced to run them in the next animation frame.

This change would allow UA to have some transition before putting the page into
fullscreen state (e.g. fade the screen to black)

In addition, UAs may need to do some extra work to put its window into
fullscreen (which could be async because of API of OS), hence at exactly the
next frame, it is possible that the window hasn't been in fullscreen yet, which
means a page may need to rely on the following resize event to correct some
dimensions it uses instead of only the fullscreenchange event.

It seems that, what is the next animation frame task has no definition yet.
With this change, we will not need to define that anymore.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: oldNode.replaceWith(...collection) edge case

2015-05-05 Thread Anne van Kesteren
On Thu, Jan 22, 2015 at 2:18 AM, Glen Huang curvedm...@gmail.com wrote:
 This algorithm shouldn’t slow normal operations down, and I wonder if the 
 spec could use an algorithm like this and not using document fragment.

I looked at this again and we do want to use a DocumentFragment.
Otherwise mutation observers get messy. But I guess we could store
offset parent and next sibling either way. I filed

  https://github.com/whatwg/dom/issues/32

to tackle this. These algorithms could use some cleaning up in general.


-- 
https://annevankesteren.nl/



Re: Permissions API vs local APIs

2015-05-05 Thread Mike West
On Tue, May 5, 2015 at 2:54 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, May 4, 2015 at 10:42 PM, Anne van Kesteren ann...@annevk.nl
 wrote:
  Over in
 https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0006.html
  Jonas pointed out that having two APIs for doing the same thing is
  nuts. We should probably decide whether we go ahead with the
  Permissions API or keep doing permission checks on a per-API basis.

 I personally think having a single API, rather than half a dozen
 navigator.*.hasPermission() APIs is better. If for no other reason
 than that's it's likely going to be significantly easier to keep a
 single API consistent, than the half-dozen different ones.

 I'll also note that the reception on twitter from developers for the
 permission API seemed quite positive.


I agree with Jonas. Extending the permission API to give developers a
single place to check with a single consistent style seems like the right
way to go.

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


Re: Permissions API vs local APIs

2015-05-05 Thread Jonas Sicking
On Mon, May 4, 2015 at 10:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
 Over in 
 https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0006.html
 Jonas pointed out that having two APIs for doing the same thing is
 nuts. We should probably decide whether we go ahead with the
 Permissions API or keep doing permission checks on a per-API basis.

I personally think having a single API, rather than half a dozen
navigator.*.hasPermission() APIs is better. If for no other reason
than that's it's likely going to be significantly easier to keep a
single API consistent, than the half-dozen different ones.

I'll also note that the reception on twitter from developers for the
permission API seemed quite positive.

/ Jonas



Re: :host pseudo-class

2015-05-05 Thread Tab Atkins Jr.
On Mon, May 4, 2015 at 9:38 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote:
 But maybe you're right and the whole
 pseudo-class/pseudo-element distinction is rather meaningless. But at
 least pseudo-class til date made some sense.

 I still don't understand what you find wrong with this.  It's not that
 :host() [can] match an element that cannot otherwise be matched,
 it's that the host element element is featureless, save for the
 ability to match :host.  (That's the definition of a featureless
 element - it's allowed to specify particular things that can still
 match it.)  In other words, it's not :host that's magical, it's the
 host element itself that's magical.

 So :host:hover would not work? I guess you would have to spell that
 :host(:hover)? Because although it does not have features, it has
 features inside the parenthesis?

Correct. The functional :host() pseudo-class can match the selector
against the *real* host element that hosts the shadow tree (and
:host-context() can do so for the entire shadow-piercing ancestor
tree).  But normal selectors inside a shadow tree only see the
featureless version of the host element that lives inside of the
shadow tree.

 Was this concept introduced for other scenarios or just for :host?
 Seems like a very weird rationalization.

Yeah, it was introduced to give the host element the selection
behavior we wanted (I explained this in more detail in my first post
in the thread).

It's certainly no weirder, imo, than having a pseudo-element that
doesn't actually live in any element's pseudo-tree, but instead just
lives in the normal DOM, but can only be selected by using a
pseudo-element selector with no LHS.  Pseudo-elements are fucked,
unfortunately, but we have to live with their quirks, and those quirks
make them really bad for this particular case.

~TJ



RE: Directory Upload Proposal

2015-05-05 Thread Ali Alabbas
I recommend that we change the dir attribute to directories and keep 
directory the same as it is now to avoid clashing with the existing dir 
attribute on the HTMLInputElement. All in favor?

As for the behavior of setting the directories attribute on a file input, we 
have the following options:

1) Expose two buttons in a file input (choose files and choose directory) 
(see Mozilla's proposal [1])
- To activate the choose directory behavior of invoking the directory picker 
there would need to be a method on the HTMLInputElement e.g. chooseDirectory()
- To activate the choose files behavior of invoking the files picker, we 
continue to use click() on the file input

2) Expose two buttons in file input for Windows/Linux (choose files and 
choose directory) and one button for Mac OS X (choose files and directories)
- Allows users of Mac OS X to use its unified File/Directory picker
- Allows users of Windows/Linux to specify if they want to pick files or a 
directory
- However, there would still need to be a method to activate the choose 
directory button's behavior of invoking the directory picker (e.g. 
chooseDirectory() on the HTMLInputElement)
- This results in two different experiences depending on the OS

3) Expose only one button; Windows/Linux (choose directory) and Mac OS X 
(choose files and directories)
- Allows users of Mac OS X to use its unified File/Directory picker
- Windows/Linux users are only able to select a directory
- click() is used to activate these default behaviors (no need for an extra 
method such as chooseDirectory() on the HTMLInputElement interface)
- For Windows/Linux, in order to have access to a file picker, app/site 
developers would need to create another file input without setting the 
directories attribute 
- Can have something like isFileAndDirectorySupported so that developers can 
feature detect and decide if they need to have two different file inputs for 
their app/site (on Windows/Linux) or if they just need one (on Mac OS X) that 
can allow both files and directories

4) Expose only one button (choose directory)
- User must select a directory regardless of OS or browser (this normalizes the 
user experience and the developer design paradigm)
- To make users pick files rather than directories, the developer simply does 
not set the directories attribute which would show the default file input
- Developers that want to allow users the option to select directory or files 
need to provide two different inputs regardless of OS or browser

I am leaning towards option 3 or 4 since it allows us to avoid needing an extra 
method such as chooseDirectory() but also allows the developer to cater the 
experience based on the capabilities of the OS via feature detection as is the 
case with option 3. It also allows us to keep the current look and feel of the 
file inputs meaning we don't break current sites nor do we create an experience 
that puts backwards compatibility at risk by outright changing the behavior of 
the file input.

Thanks,
Ali

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=846931



Re: :host pseudo-class

2015-05-05 Thread Tab Atkins Jr.
On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote:
 On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote:
 I don't understand why :host is a pseudo-class rather than a
 pseudo-element. My mental model of a pseudo-class is that it allows
 you to match an element based on a boolean internal slot of that
 element. :host is not that since e.g. * does not match :host as I
 understand it. That seems super weird. Why not just use ::host?

 Copying WebApps since this affects everyone caring about Shadow DOM.

 We haven't really used (in the sense of shipping across browsers)
 pseudo-elements before for things that are both tree-like (i.e., not
 ::first-letter, ::first-line, or ::selection) and not leaves of the
 tree.  (Gecko doesn't implement any pseudo-elements that can have
 other selectors to their right.  I'm not sure if other engines
 have.)

 I'd be a little worried about ease of implementation, and doing so
 without disabling a bunch of selector-related optimizations that
 we'd rather have.

 At some point we probably do want to have this sort of
 pseudo-element, but it's certainly adding an additional dependency
 on to this spec.

 My understanding is that the question here isn't what is being
 matched, but rather what syntax to use for the selector. I.e. in both
 cases the thing that the selector is matching is the DocumentFragment
 which is the root of the shadow DOM.

As Anne said, no, the thing matched is the actual host element.  But
otherwise, yeah, we're just debating the syntax of how to select that
(while obeying the constraints I outlined in my first post to this
thread).

 If implementing :host is easier than ::host, then it seems like the
 implementation could always convert the pseudo-element into a
 pseudo-class at parse time. That should make the implementation the
 same other than in the parser. Though maybe the concern here is about
 parser complexity?

It's not about parser complexity. (dbaron did use that as an argument
against ::host, but I'm not making that argument; Blink's parser has
no problem with it.)  It's about hitting the (admittedly complex)
constraints sanely within the existing Selectors model.

~TJ



Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-05 Thread Tab Atkins Jr.
On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote:
 On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote:
 We can solve this
 problem by running the distribution code in a separate scripting context
 with a restricted (distribution specific) API as is being discussed for
 other extension points in the platform.

 That seems like a lot of added complexity, but yeah, that would be an
 option I suppose. Dimitri added something like this to the imperative
 API proposal page a couple of days ago.


 One thing to consider here is that we very much consider distribution a
 style concept. It's about computing who you inherit style from and where you
 should be in the box tree. It just so happens it's also leveraged in event
 dispatch too (like pointer-events). It happens asynchronously from DOM
 mutation as needed just like style and reflow though.

 I don't really see it that way. The render tree is still computed from
 the composed tree. The composed tree is still a DOM tree, just
 composed from various other trees. In the open case you can access
 it synchronously through various APIs (e.g.  if we keep that for
 querySelector() selectors and also deepPath).

 I agree. I don't see any reason node distribution should be considered as a 
 style concept. It's a DOM concept. There is no CSS involved here.

Yes there is.  As Elliot stated in the elided parts of his quoted
response above, most of the places where we update distribution are
for CSS or related concerns:

# 3 event related
# 3 shadow dom JS api
# 9 style (one of these is flushing style)
# 1 query selector (for ::content and :host-context)

 I have issues with the argument that we should do it lazily.  On one hand, if 
 node distribution is so expensive that we need to do it lazily, then it's 
 unacceptable to make event dispatching so much slower.  On the other hand, if 
 node distribution is fast, as it should be, then there is no reason we need 
 to do it lazily.

 The problem is really the redistributions. If we instead had explicit 
 insertion points under each shadow host, then we wouldn't really need 
 redistributions at all, and node distribution can happen in O(1) per child 
 change.

As repeatedly stated, redistribution appears to be a necessity for
composition to work in all but the most trivial cases.

~TJ



Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-05 Thread Ryosuke Niwa

 On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote:
 We can solve this
 problem by running the distribution code in a separate scripting context
 with a restricted (distribution specific) API as is being discussed for
 other extension points in the platform.
 
 That seems like a lot of added complexity, but yeah, that would be an
 option I suppose. Dimitri added something like this to the imperative
 API proposal page a couple of days ago.
 
 
 One thing to consider here is that we very much consider distribution a
 style concept. It's about computing who you inherit style from and where you
 should be in the box tree. It just so happens it's also leveraged in event
 dispatch too (like pointer-events). It happens asynchronously from DOM
 mutation as needed just like style and reflow though.
 
 I don't really see it that way. The render tree is still computed from
 the composed tree. The composed tree is still a DOM tree, just
 composed from various other trees. In the open case you can access
 it synchronously through various APIs (e.g.  if we keep that for
 querySelector() selectors and also deepPath).

I agree. I don't see any reason node distribution should be considered as a 
style concept. It's a DOM concept. There is no CSS involved here.

I have issues with the argument that we should do it lazily.  On one hand, if 
node distribution is so expensive that we need to do it lazily, then it's 
unacceptable to make event dispatching so much slower.  On the other hand, if 
node distribution is fast, as it should be, then there is no reason we need to 
do it lazily.

The problem is really the redistributions. If we instead had explicit insertion 
points under each shadow host, then we wouldn't really need redistributions at 
all, and node distribution can happen in O(1) per child change.

- R. Niwa



Microsoft is considering Chrome's Native Messaging

2015-05-05 Thread Anders Rundgren

https://twitter.com/shimonamit/status/571046844488245248

Not very surprising.  It is a very good idea even if the current solution in Chrome is a 
bit of a prototype since it is not the extension (which BTW is redundant) that needs to 
be vetted and app-stored; it is the native application that does the dirty 
work.

This would IMO be an ideal work-item for WebAppSec.

Anders



Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!

2015-05-05 Thread Austin William Wright
On Mon, May 4, 2015 at 8:52 PM, Lea Verou l...@verou.me wrote:

 Sorry for reviving such an old thread (almost 3 years now!) but I recently
 came across a huge use case for CAS: Semantic data! Namely, Microdata and
 RDFa. They’re both applied using attributes, which makes them super tedious
 to add to existing content.


I like this idea! You might get additional feedback for this from the SWIG
community on the semantic-web list.

GRDDL is (was?) a very similar, but much more complex, concept that uses
RDF/XML and XSLT (not a very well-liked combination by myself or
generally): http://www.w3.org/TR/grddl/

Another application would be many of the applications of ARIA attributes
(surely I can't be the only one who's thought ARIA shouldn't be embedded in
markup since it's not conveying actual data).

In both cases, they're properties annotating/semantically enhancing data,
where cycles generally shouldn't occur. That is if cycles are a problem at
all. CSS doesn't seem to have any issue when it creates pesudo-elements, I
don't forsee too many issues with pesudo-attributes.

That is, I don't see any reason this would need to modify the DOM; but
could instead expose a data DOM that ARIA and RDFa would use; the same
way Web browsers render a visual DOM of sorts containing pesudo-elements.

Austin Wright.