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

[Anne van Kesteren]

On Thu, Jan 22, 2015 at 2:18 AM, Glen Huang  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: Directory Upload Proposal

[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

Microsoft is considering Chrome's Native Messaging

[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: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Ryosuke Niwa]

> On May 4, 2015, at 10:20 PM, Anne van Kesteren  wrote:
> 
>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn  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

Re: :host pseudo-class

[Tab Atkins Jr.]

On Mon, May 4, 2015 at 9:38 PM, Anne van Kesteren  wrote:
> On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr.  wrote:
>> On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren  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: :host pseudo-class

[Tab Atkins Jr.]

On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking  wrote:
> On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron  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)

[Tab Atkins Jr.]

On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa  wrote:
>> On May 4, 2015, at 10:20 PM, Anne van Kesteren  wrote:
>>
>>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn  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: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

[Austin William Wright]

On Mon, May 4, 2015 at 8:52 PM, Lea Verou  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): 

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.

Re: Permissions API vs local APIs

[Jonas Sicking]

On Mon, May 4, 2015 at 10:42 PM, Anne van Kesteren  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: Permissions API vs local APIs

[Mike West]

On Tue, May 5, 2015 at 2:54 PM, Jonas Sicking  wrote:

> On Mon, May 4, 2015 at 10:42 PM, Anne van Kesteren 
> 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 , @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: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Ryosuke Niwa]

> On May 5, 2015, at 11:55 AM, Tab Atkins Jr.  wrote:
> 
> On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa  wrote:
>>> On May 4, 2015, at 10:20 PM, Anne van Kesteren  wrote:
>>> 
 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn  
 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

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

[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: Permissions API vs local APIs

[Anne van Kesteren]

On Wed, May 6, 2015 at 12:32 AM, Mike West  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)

[Anne van Kesteren]

On Wed, May 6, 2015 at 3:22 AM, Ryosuke Niwa  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.  does? That is,  only cares about
 and  elements that are passed to it.


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr.  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/