Re: [XHR] null response prop in case of invalid JSON

[Anne van Kesteren]

On Mon, Apr 25, 2016 at 8:10 PM, Kirill Dmitrenko  wrote:
> I've found in the spec of XHR Level 2 that if a malformed JSON's received 
> from a server, the response property would be set to null. But null is a 
> valid JSON, so, if I understand correctly, there is no way to distinct a 
> malformed JSON response from a response containing only 'null', which is, 
> again, a valid JSON:
>
> $ node -p -e 'JSON.parse("null")'
> null
> $

Use the fetch() API instead. It'll rethrow the exception for this
case: https://fetch.spec.whatwg.org/#fetch-api. Also, "XHR Level 2" is
no longer maintained. You want to look at https://xhr.spec.whatwg.org/
instead (though for this specific case it'll say the same thing).


-- 
https://annevankesteren.nl/

Re: [Custom Elements] Not requiring hyphens in names.

[Anne van Kesteren]

On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea  wrote:
> I really believe that we should be allowed to name our elements with any
> name we wish, and that they should override native elements (that is future
> proof), and that overriding should be on some type of encapsulated basis
> (for example, override within a shadow root and it won't affect other code
> outside the shadow root).

I don't think anyone disagrees with that in principle, but in practice
that would require refactoring huge amounts of code which will
basically not happen anytime soon. Better to iterate in smaller steps.


-- 
https://annevankesteren.nl/

Re: [Web Components] Editor for Custom Elements

[Anne van Kesteren]

On Wed, Apr 6, 2016 at 9:17 PM, Léonie Watson  wrote:
> Which means we're looking for someone (or more than one someone) to edit
> Custom Elements. Web Components are a key part of the Web Platform, so it's
> an interesting time to be part of the group working on Custom Elements (and
> Shadow DOM).

Given that both these specifications are effectively monkey patches
for the DOM and HTML Standards, and Domenic plans on updating those
for Custom Elements, what's the point?


-- 
https://annevankesteren.nl/

Re: Telecon / meeting on first week of April for Web Components

[Anne van Kesteren]

On Tue, Apr 5, 2016 at 6:55 PM, Xiaoqian Wu  wrote:
> I’m unfamiliar with WebEx. If Chaals or someone wants to make a strong push
> to use that, please set up the call and send out instructions for joining.

FYI: we're using Hangouts. If anyone cannot join please tell us on IRC
(#webapps, W3C IRC).


-- 
https://annevankesteren.nl/

Re: Telecon / meeting on first week of April for Web Components

[Anne van Kesteren]

On Tue, Apr 5, 2016 at 12:19 AM, Jan Miksovsky  wrote:
> I have no idea how to settle this question. If everyone else is happy using 
> WebEx, and someone else can set up the video call, I certainly don’t have a 
> problem with that. (My only issue would be if the meeting was restricted to 
> voice only.)

Does WebEx even support video? In any event, per
https://www.w3.org/2006/tools/wiki/InstallingWebEx this would require
Java, which is a major security risk, and it seems the fallback is
audio-only. So it seems better to use Hangouts or some such.


-- 
https://annevankesteren.nl/

Re: Telecon / meeting on first week of April for Web Components

[Anne van Kesteren]

On Wed, Mar 30, 2016 at 11:24 PM, Jan Miksovsky  wrote:
> If everyone could indicate their availability by, say, this Friday, 4/1, we 
> can see what time works best for everyone.

Done, I've assumed that the time was California time, meaning I'm
"available" daily 7-9PM Zurich time.


-- 
https://annevankesteren.nl/

Re: Telecon / meeting on first week of April for Web Components

[Anne van Kesteren]

On Wed, Mar 23, 2016 at 9:45 PM, Ryosuke Niwa  wrote:
>> On Mar 23, 2016, at 6:04 AM, Chaals McCathie Nevile  
>> wrote:
>> I'll attend from Europe. Is there a preferred day, and how long do you 
>> anticipate this being?
>
> I think the first or the second week of April would be good.  We just need to 
> go through each issue and make sure we're on the same page so I'd expect it 
> to be 1-2 hours.

I'm not sure I'm able to attend, but I've been going through all the
issues several times now and adding what I think needs doing (or
resolving it when possible). The issues that are currently blocking
specification work are marked as "needs consensus":

https://github.com/w3c/webcomponents/issues?q=is%3Aissue+is%3Aopen+label%3A%22needs+consensus%22

It would be great if folks could get to those sooner than later.


-- 
https://annevankesteren.nl/

Re: [clipboard] kill onbefore* events?

[Anne van Kesteren]

On Wed, Mar 9, 2016 at 2:29 PM, Hallvord Reiar Michaelsen Steen
 wrote:
> In my personal (and humble) opinion it's not actually a benefit for
> developers to have only one event that will fire a lot and indicate
> lots of different things. I accept that library authors want a
> convenient "point of overview" regarding what happens in the DOM (but
> wasn't mutation observers supposed to do that job?). However, making
> one single event type carry lots of different information and adding
> stuff like clipboardData and/or dataTransfer (because drag-and-drop
> changes the DOM too, right?) to the InputEvent interface seems like we
> force authors to
>
> 1) Write code with lots of if(e.eventType === foo) and
> switch(e.eventType) branching, which is hard to read
> 2) Debug code that gets run a lot all the time - event loops that fire
> often are annoying when debugging

I strongly agree with this. We should not design another
XMLHttpRequest readystatechange event disaster.


-- 
https://annevankesteren.nl/

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Anne van Kesteren]

On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa  wrote:
> Hi,
>
> We propose to change the lifecycle callback to be fired both before invoking 
> author scripts (e.g. for dispatching events) and before returning to author 
> scripts.
>
> Without this change, event listeners that call custom elements' methods would 
> end up seeing inconsistent states during compound DOM operation such as 
> Range.extractContents and editing operations, and we would like to avoid that 
> as much as possible.

These are the events we wanted to try and delay to dispatch around the
same time lifecycle callbacks are supposed to be called?


-- 
https://annevankesteren.nl/

Re: Service worker F2F meeting - 26th Jan - San Francisco

[Anne van Kesteren]

On Mon, Jan 4, 2016 at 5:56 PM, Conrad Irwin  wrote:
> I'd be interested in attending as a relatively mute observer. We've been
> using service workers for a while now, and I'd like to get more involved.

Great, you're in, no need to be mute though.

We have three more seats at this point, allocated on the basis of
first come, first served.

I'd also like to encourage everyone to read through

  https://slightlyoff.github.io/ServiceWorker/spec/service_worker/

and the open issues. That will make it easier to follow the meeting.

As for logistics, the meeting will be 9AM - 5PM at the aforementioned
building, seventh floor (though you'll have to go through reception
most likely, ground floor). We'll go outside for lunch. Snacks are on
the house. There's a promise of regular breaks. Any further questions
can be directed at either Jake or I.


-- 
https://annevankesteren.nl/

Re: Custom elements contentious bits

[Anne van Kesteren]

On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola  wrote:
> A bit ago Jan put together an initial draft of the "contentious bits" for 
> custom elements, in preparation for our January F2F. Today I went through and 
> expanded on the issues he put together, with the result at 
> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits. 
> It morphed into a kind of agenda for the meeting, containing "Previously 
> contentious bits", "Contentious bits", "Other things to work out", and "Other 
> issues worth mentioning".
>
> It would be lovely if other vendors could take a look, and fill in anything 
> they think is missing, or correct any inaccuracies.

So my impression is that Apple is still in favor of synchronous
construction. Talking to developers from Ember.js they care about that
too (to the extent they even think this problem is worthwhile
solving). The "upgrade" problem is a more general problem we also have
with service workers and such. There's some kind of boostrapping thing
that might warrant a more general solution.

Would be great to have some cards on the table.

And with respect to that, Mozilla is interested in shipping Shadow
DOM. We continue to have concerns with regards to lack of integration
with the HTML Standard, but hope those will get resolved. Custom
elements is less of a priority for us at this point, so we're not sure
what to make of this meeting if things are still up in the air.


-- 
https://annevankesteren.nl/

Re: [web components] proposed meetings: 15 dec / 29 jan

[Anne van Kesteren]

On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa  wrote:
> What outstanding problems are you thinking of?

Again, not I, but Hayato Ito raised these. I just happen to agree. He
emailed this list on November 2:

  https://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0149.html


-- 
https://annevankesteren.nl/

Re: [web components] proposed meetings: 15 dec / 29 jan

[Anne van Kesteren]

On Fri, Nov 13, 2015 at 11:32 AM, Chaals McCathie Nevile
 wrote:
> Our proposal is to look for a host on 15 December on the West Coast, for a
> meeting primarily focused on Shadow DOM, and another on 29 January in the
> Bay area for one around Custom Elements. The agenda can be adjusted to take
> account of people who are unable to travel for both of these, moving items
> from one to the other if necessary, since *many* but *not all* people are
> interested in both topics.

As mentioned before, I and others from Mozilla not in the US are
unlikely to make December 15. There's a big Mozilla event the entire
week before and I doubt folks want to keep trucking. But given how far
along Shadow DOM is perhaps attendance is not important. After all,
Hayato Ito stressed in an earlier email that to make the meeting
worthwhile we'd need some new proposals to address the quite hard
outstanding problems and I haven't seen any of those thus far.


-- 
https://annevankesteren.nl/

Re: TPAC Topic: Using ES2015 Modules in HTML

[Anne van Kesteren]

On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa  wrote:
> Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
> October 27th at TPAC?

Pretty sure Tuesday has been reserved for service workers discussion.


-- 
https://annevankesteren.nl/

Re: [web-animations] Should computedTiming return a live object?

[Anne van Kesteren]

On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles  wrote:
> I'd like to change this API, probably to one of the following (listed
> roughly in order of preference). I wonder if anyone else has an opinion
> on this?

I'm curious as to what this maps to closer to the metal. That can help
inform a reasonable low-level API. The other thing I'm wondering about
is whether it's still reasonably to introduce new synchronous layout
getters/setters. I was hoping we'd move away from that at some point.


-- 
https://annevankesteren.nl/

Re: Normative references to Workers.

[Anne van Kesteren]

On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow  wrote:
> On 9/21/15 5:54 AM, Ms2ger wrote:
>> Why?
>
> I think the rationale was mentioned in
> .

Ms2ger made a valid point. Workers is actively being updated (I
submitted two PRs the other day, more to come). If you don't want to
get out-of-sync you won't get to REC in the foreseeable future. It
therefore is likely a waste of time for someone to volunteer to
copy-and-paste text that is unstable.


-- 
https://annevankesteren.nl/

Re: Shadow DOM spec for v1 is ready to be reviewed

[Anne van Kesteren]

On Mon, Sep 7, 2015 at 9:35 AM, Hayato Ito  wrote:
> I think the spec should address these issues and define the well-defined
> behavior clearly. The current spec looks too lazy because it only mention
> the following:
>
>> Window object named properties [HTML] must access the nodes in the
>> document tree.
>
> I think this is not enough to achieve the interoperability among UAs.

Right, for many HTML features this seems problematic. Are you planning
on working on this and provide patches against
https://github.com/whatwg/html? If you think this is too much work let
me know and I'll see what I can to help. I'm trying to decrease the
backlog of HTML somewhat so this is not currently a priority for me,
but it is one of the things Mozilla considers problematic with
shipping Shadow DOM at this point.


>> Then there's the matter of text selection which we're not sure about
>> what to do. Have you folks worked on that?
>
> I've discussed this topic several times in Google, however, this is still an
> unsolved problem.
> We don't have anything which we can upstream to the spec yet.
> In Blink, we've supported only "Copy" for a selection which spans shadow
> boundaries.
> Any ideas are highly welcome.

Given that https://w3c.github.io/selection-api/ is edited by Ryosuke,
I wonder what his thoughts are. This issue must not have gotten past
the Apple team. At Mozilla we don't have a concrete proposal, it's
however something we don't think works well currently and we don't
really know how to move forward here.


-- 
https://annevankesteren.nl/

Re: Shadow DOM spec for v1 is ready to be reviewed

[Anne van Kesteren]

On Fri, Aug 28, 2015 at 8:33 AM, Hayato Ito  wrote:
> - Some of the remaining issues are difficult to address in the Shadow DOM
> spec because it requires non-trivial monkey patches to DOM.  I have a plan
> to upstream the Shadow DOM spec into DOM in the near future. After that, I
> think we can address some of issues by updating DOM spec directly.

That sounds great!

It also seems there's still a number of issues around integration with
HTML. That is, what the effect of HTML elements should be inside
shadow trees. I seem to remember Ian having more detailed notes, but
quickly looking around I only found:

* https://www.w3.org/Bugs/Public/show_bug.cgi?id=27406
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=26952
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=28748

And these don't seem to mention the effects of various algorithms.
E.g., named access on the global object currently finds child browsing
contexts, but I don't think we would want it to return any that are
inside a shadow tree. And should browsing contexts inside shadow trees
have an effect on history?


Then there's the matter of text selection which we're not sure about
what to do. Have you folks worked on that?


-- 
https://annevankesteren.nl/

Re: PSA: publish WD of "WebIDL Level 1"

[Anne van Kesteren]

On Tue, Sep 1, 2015 at 4:23 PM, Ryosuke Niwa  wrote:
> I think you’re missing the point.  The point of these documentation is to 
> know exactly what the patch author was looking at the time he wrote the 
> patch.  If there was a typo in the spec, that’s an important information.
>
> As for diff’ing what has changed, that’s exactly the use case.  In order to 
> know what has changed, you need to know what the old spec was.  The living 
> standard is a total nightmare as far as I’m concerned.

I guess it depends on your workflow. In any event, does what Domenic
suggests and has implemented for https://streams.spec.whatwg.org/
address your concern?


-- 
https://annevankesteren.nl/

Re: PSA: publish WD of "WebIDL Level 1"

[Anne van Kesteren]

On Tue, Sep 1, 2015 at 2:33 AM, Ryosuke Niwa  wrote:
> Let's say we implement some feature based on Web IDL published as of today.  
> I'm going to refer that in my source code commit message.  Future readers of 
> my code has no idea what I was implementing when they look at my commit 
> message in five years if it refers to the living standard that changes over 
> time.

Apart from what Domenic said, IDs should remain stable over time and
other than features getting expanded, they need to remain backwards
compatible, just as your code base. (It also seems like useful
information to know what you've implemented has been refactored or
changed in some way in the corresponding standard, so you can take
steps to update your code.)


-- 
https://annevankesteren.nl/

Re: [worker] Integration of WorkerGlobalScope and AbstractWorker

[Anne van Kesteren]

On Sun, Aug 23, 2015 at 12:23 PM, Bang Seongbeom
 wrote:
> The current spec says that the internal worker scope is WorkerGlobalScope(or
> Dedi-, Shared-), the external is AbstractWorker(or Worker, Shared-.) But it
> destroys consistency with Window object and confuses users with the
> difference of WorkerGlobalScope and AbstractWorker.

Well, I don't think there's much consistency to be gained since it's
quite a bit different. And it's unclear whether consistency with
Window would be good, given all its legacy baggage.


> The global scope Window object can't access to the other Window object
> that's derived from the other origin because of the Same Origin Policy. Like
> this, we can restrict the access by it, not to separate the two objects.

What object would then use to communicate with the other side?


> And it's hard to understand that why can't terminate in WorkerGlobalScope
> and can't close in AbstractWorker. These two methods should be provided
> equally, or not.

Not sure about the rationale for this.


-- 
https://annevankesteren.nl/

Re: Custom elements "Constructor-Dmitry" baseline proposal

[Anne van Kesteren]

Thank you for writing this up. Would be interesting to hear what
Maciej and Ryosuke think.

On Tue, Aug 18, 2015 at 12:19 AM, Domenic Denicola  wrote:
> - Use symbols instead of strings for custom element callbacks.

So the way this is done is that they are publicly available on the
prototype. Does that mean behavior can change during the lifetime?
What does that mean for builtin elements that do not have these
callbacks on their prototype?

Also, we probably need to rename registerElement() due to the
different semantics.

Also, you want to sort the attributes in some way before calling
attributeChanged from upgrades, or we must finally agree on that
attributes are sorted in some deterministic way:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=17871

I also thought the idea was to pass attached/detached their changed
ancestor and perhaps rename them inserted/removed (and no longer scope
them to document change).


-- 
https://annevankesteren.nl/

Re: Copying multi-range selection

[Anne van Kesteren]

On Sat, Aug 15, 2015 at 9:04 PM, Richard Ishida  wrote:
> my question was specifically, why do it in a non-standard way for bidi text?
> (typical scenario is split visual but one range internally)

Which is not great for users, right? Also, as Addison points out, it's
unclear how that would work on a touch screen. The reason it came up
is that with new CSS features, this problem now also affects the LTR
population. Which is kind of a sad state of affairs for that to be the
reason this gets looked at...


Also, while I'm here, thank you Mati, that is a great reply!


-- 
https://annevankesteren.nl/

Re: Copying multi-range selection

[Anne van Kesteren]

On Sat, Aug 15, 2015 at 10:23 AM, Richard Ishida  wrote:
> what's the use case driving this, and where are the requirements coming
> from?
>
> i ask because i'm inclined to think that the circumstances in which this
> would a produce useful results, given the way it carves up the actual
> content, are quite, perhaps extremely, limited.

Well, the web platform "supports" editing, text selection, and
drag-and-drop/copy-and-paste, etc. through various APIs. The question
is how those should work with RTL content.


-- 
https://annevankesteren.nl/

Re: Copying multi-range selection

[Anne van Kesteren]

On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa  wrote:
> We've been recently exploring ways to select bidirectional text and content 
> that uses new CSS layout modes such as flex box in visually contagious manner.
>
> Because visually contagious range of content may not be contagious in DOM 
> order, doing so involves creating a disjoint multi-range selection.  There 
> has been quite a bit of discussion about how we can better expose that to the 
> Web since the current model of exposing a list of Range objects doesn't seem 
> to be working well.
>
> However, another important question I have is how copying such a selected 
> content work?  Do we just stitch together disjoint content?  But that may 
> result in the content being pasted in completely different order.

I copied www-international. Somewhat curious if this problem has been
studied before. It does seem like you would have to add/remove
formatting code points as the context where you paste may be different
from the context where you copied from.


-- 
https://annevankesteren.nl/

Re: Custom Element Action Items?

[Anne van Kesteren]

On Mon, Aug 10, 2015 at 3:17 PM, Wilson Page  wrote:
> I was unable to attend the latest F2F so would like clarification on what
> the takeaway action items were and who is responsible for pushing them
> forward. I don't believe this information was included in the minutes.

I think an interesting list of things to do is
https://gist.github.com/dglazkov/3a709f3f6768b835dab1 which basically
requires some research in implementations.

Part of the argument at the F2F was about whether invoking JavaScript
during DOM mutations was a lost cause or not. Ryosuke made a good case
that it might be, but the Chrome folks were willing to try and
disprove that. (I think everyone is agreed that if we don't have, that
would be better.)

The other argument was about consistency of the world at the time
callbacks are invoked. Whether you can observe children and attributes
during the "created" callback for instance, which if you rely upon
that would result in issues if your component was ever created through
createElement(). If you invoke JavaScript during DOM mutations this is
not a problem. Otherwise it might be, though
https://github.com/w3c/webcomponents/issues/287 is doing some
exploring to see if we can "hide" certain things.

None of this seems like something we'll have resolved soon though :-/


-- 
https://annevankesteren.nl/

Re: [charter] What is the plan for Streams API?

[Anne van Kesteren]

On Mon, Aug 10, 2015 at 2:07 PM, Arthur Barstow  wrote:
> Given Takeshi's status it seems premature to speculate.
>
> The current [TR] is now mostly void of content although it might be good to
> gut it even more as well as to add a clear note that indicates that work has
> stopped and might not resume.
>
> [TR] 

So what are the requirements for getting something in the charter? If
we don't even know what a given draft might contain, how can folks
review the charter?


-- 
https://annevankesteren.nl/

Re: PSA: publish WD of "WebIDL Level 1"

[Anne van Kesteren]

On Fri, Aug 7, 2015 at 6:23 PM, Travis Leithead
 wrote:
> This is, at a minimum, incremental goodness. It's better than leaving the 
> prior L1 published document around--which already tripped up a few folks on 
> my team recently. I strongly +1 it.

If your team looks at the newer L1 they will also trip themselves up.
Anything but https://heycam.github.io/webidl/ is problematic.


-- 
https://annevankesteren.nl/

Re: PSA: publish WD of "WebIDL Level 1"

[Anne van Kesteren]

On Fri, Aug 7, 2015 at 2:45 PM, Arthur Barstow  wrote:
> The L2 version (by Cameron and Boris) has not been published as a TR
> and if there no objections to proceeding as above, I will start working on
> making this all happen.

I still don't understand why L1 is even published. It cannot be
implemented so only furthers confusion.


-- 
https://annevankesteren.nl/

Re: [charter] What is the plan for Streams API?

[Anne van Kesteren]

On Fri, Aug 7, 2015 at 1:56 PM, Arthur Barstow  wrote:
> Given this status, and in the absence of other feedback, I think the Streams
> API should remain in WebApps' charter (at least for now). Then later, the
> work may proceed (if there is still agreement an additional API would be
> useful); otherwise, if there is agreement to stop the work, the work can be
> stopped (and a WG Note published).

What would this additional API do?


-- 
https://annevankesteren.nl/

W3C's version of XMLHttpRequest should be abandoned

[Anne van Kesteren]

According to Art
https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
maintained. It should redirect to https://xhr.spec.whatwg.org/
therefore.

According to Art the plan of record is to still pursue
https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html but
that was last updated more than a year ago. Last "formally" published
a year and a half ago. That causes significant confusion. More
importantly, implementations are implementing the new features in
https://xhr.spec.whatwg.org/ so nobody has much use for a "Level 1".
Especially one that is not layered on top of Fetch and therefore
doesn't even work with service workers.


-- 
https://annevankesteren.nl/

Re: [clipboard] document.execCommand and clipboard actions

[Anne van Kesteren]

On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
 wrote:
> so I hit a bit of an issue: I've written some parts of the clipboard spec
> with the assumption that it will be invoked from a
> document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
> require some extra permission work which no UA but IE has attempted so far).

So you're saying most of this is deployed and used by content?


> Meanwhile, the editing task force has gathered feedback on developing editor
> features from implementors and drawn the conclusion that the current "stuff"
> including contentEditable=true and document.execCommand() is unsalvageable.

It seems that's wrong at least as far as copy/paste is concerned,
given our recent successes in getting Flash replaced by execCommand()
calls.


> Would implementors want to support [a new API]?

I think we should first solve the hard problems around security and
format interoperability. We can always add new APIs once the
underlying primitives are well understood. Doing that before seems
rather dangerous. And as you point, without respect for historical
precedent showing it's a bad idea.


-- 
https://annevankesteren.nl/

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Fri, Jul 17, 2015 at 5:47 PM, Boris Zbarsky  wrote:
> On 7/17/15 10:38 AM, Anne van Kesteren wrote:
>> If I look at "update the image data" step 6 it seems it might be
>> fetched at a later point?
>
> Yes, but in practice the fetch will go ahead, no?  There's nothing to
> prevent it from happening, so it's going to happen once you reach a stable
> state...

True, but either way this doesn't seem like a problem. You can create
a DocumentFragment, insert a new , and then let it be GC'd,
today.


-- 
https://annevankesteren.nl/

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Fri, Jul 17, 2015 at 4:15 PM, Domenic Denicola  wrote:
> From: Anne van Kesteren [mailto:ann...@annevk.nl]
>> It fails atomically, based on the definition of innerHTML.
>
> What if that 512 KiB of HTML contains ? Following 
> definitions, I assume we fire off the network request?

If I look at "update the image data" step 6 it seems it might be
fetched at a later point?


> What if it contains a  where XBaz's constructor does 
> `document.body.innerHTML = "Hello"`? Can the parsing algorithm deal 
> with the (following the definitions, required) re-entrancy?

I think the specification can, since it just invokes the fragment
parser with some parameters and then replaces the contents of XBaz
with the obtained DocumentFragment. Implementations probably can too.
E.g., document.body.innerHTML = "..."  is quite
similar.


-- 
https://annevankesteren.nl/

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 10:36 PM, Domenic Denicola  wrote:
> I have a related question: what happens if the constructor throws?

Right, this is the kind of thing we need to figure out.


> 
> 
> "use strict";
>
> window.throwingMode = true;
>
> class XFoo extends HTMLElement {
> constructor() {
> if (window.throwingMode) {
> throw new Error("uh-oh!");
> }
> }
> }
>
> document.registerElement("x-foo", XFoo);
> 
>
> 
>
> 

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:49 PM, Domenic Denicola  wrote:
> Even if it can be specced/implemented, should it? I.e., why would this be OK 
> where MutationEvents are not?

Apart from the verbosity and performance issues with mutation events,
I think the main problem with mutation events has been the lack of a
clear processing model (and that is true to this day), causing crashes
in user agents:
https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html

In other words, the specification authors invented something, but
didn't do the due diligence of writing down how that invention would
actually impact the overall model. (This is a problem to this day.
E.g., UI events.)

So the main problem with custom constructors seems to be the
processing model, combined with the work of actually implementing and
vetting that.


-- 
https://annevankesteren.nl/

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:03 PM, Domenic Denicola  wrote:
> Ah OK, thanks. Is there any way to get a consensus from Mozilla as a whole, 
> preferably ahead of the F2F?

I think the problem is that nobody has yet tried to figure out what
invariants that would break and how we could solve them. I'm not too
worried about the parser as it already has script synchronization, but
cloneNode(), ranges, and editing, do seem problematic. If there is a
clear processing model, Mozilla might be fine with running JavaScript
during those operations.

I've been a bit too occupied with Fetch et al to put in the hours
myself ahead of the meeting.


-- 
https://annevankesteren.nl/

Re: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:02 PM,   wrote:
> But would just abandoning T[] break anything elsewhere? Is there any value in 
> having it mapped and deprecated?

If specifications were written by a team the size of a browser that
might be reasonable, but it really seems like more trouble than it's
worth.


-- 
https://annevankesteren.nl/

Re: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
 wrote:
> Should we consider keeping T[] in WebIDL, but having it map to FrozenArray<>?

We should just update the relevant specifications. We'll continue to
hit this as IDL still needs to evolve quite a bit.


-- 
https://annevankesteren.nl/

Re: Custom Elements: "createdCallback" & cloning

[Anne van Kesteren]

On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney  wrote:
> Yes. I am trying to interpret this in the context of the esdiscuss thread
> you linked. I'm not sure I understand the problem with private state,
> actually. Private state is allocated for DOM wrappers in Chromium today
> (like Gecko), including Custom Elements; it's not a problem. DOM wrapper
> creation is controlled by the UA, which can arrange for allocating the
> slots.

Sure, but this assumes elements will be backed by something other than
JavaScript forever. Or at the very least that custom elements will
always be able to do less than builtin elements.


> Is there a plan for author classes to be able to have private state or
> something?

Yes, as discussed in that es-discuss thread.


> Thanks. I can understand how editing and Range.cloneContents would use
> cloning. How is it relevant that Range is depended on by Selection?
> Selection may delete things but it does not clone them.

Editing operations operate on selections, but maybe I'm mistaken about
that? Either way, you got the problem.


>> That during cloning certain DOM operations cease to function, basically.
>
> This sounds interesting; it may even be useful for authors to be able to
> assert that between two points they did not modify the DOM.

Short of rewriting ranges and editing, that seems like the only viable
alternative to prototype swizzling, provided you're okay with seeing
upgrades as a distinct problem.


-- 
https://annevankesteren.nl/

Re: Custom Elements: "createdCallback" & cloning

[Anne van Kesteren]

On Sun, Jul 12, 2015 at 9:32 PM, Olli Pettay  wrote:
> Well, this printing case would just clone the final flattened tree without
> the original document knowing any cloning happened.
> (scripts aren't suppose to run in Gecko's static clone documents, which
> print preview on linux and Windows and printing use)
>
> If one needs a special DOM tree for printing, beforeprint event should be
> used to modify the DOM.

Sure, but you'd lose some stuff, e.g. , and presumably custom
elements if they require copying some state, due to the cloning.
(Unless it's doing more than just cloning.)


-- 
https://annevankesteren.nl/

Re: Custom Elements: "createdCallback" & cloning

[Anne van Kesteren]

On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney  wrote:
> I think the most important question here, though, is not constructors or
> prototype swizzling.

I guess that depends on what you want to enable. If you want to
recreate existing elements in terms of Custom Elements, you need
private state.


> - Progressive Enhancement. The author can write more things in markup and
> present them while loading definitions asynchronously. Unlike progressive
> enhancement by finding and replacing nodes in the tree, prototype swizzling
> means that the author is free to detach a subtree, do a setTimeout, and
> reattach it without worrying whether the definition was registered in the
> interim.

How does this not result in the same issues we see with FOUC? It seems
rather problematic for the user to be able to interact with components
that do not actually work, but I might be missing things.


> - Fewer (no?) complications with parsing and cloning. Prototype swizzling
> makes it possible to decouple constructing the tree, allocating the wrapper,
> and running Custom Element initialization. For example, if you have a Custom
> Element in Chromium that does not have a createdCallback, we don't actually
> allocate its wrapper until it's touched (like any Element.) But it would not
> be possible to distinguish whether a user-provided constructor is trivial
> and needs "this."

True true.


> Could you share a list of things that use the cloning algorithm?

In the DOM specification a heavy user is ranges. In turn, selection
heavily depends upon ranges. Which brings us to editing operations
such as cut & copy. None of those algorithms anticipate the DOM
changing around under them. (Though perhaps as long as mutation events
are still supported there are some corner cases there, though the
level of support of those varies.)

In Gecko printing also clones the tree and definitely does not expect
that to have side effects. Note that this would break with prototype
swizzling too. Or at least you'd get a less pretty page when
printing...


> What do you mean by mode switch?

That during cloning certain DOM operations cease to function, basically.


-- 
https://annevankesteren.nl/

Re: Async Image -> ImageData conversion

[Anne van Kesteren]

On Tue, Jul 7, 2015 at 12:24 PM, Ashley Gullen  wrote:
> I'm new to writing specs and when I first looked ReSpec had templates and a
> guide - is there something similar for the HTML standard style spec?

I think you can tweak ReSpec to do the right thing, though most new
specifications are written using
https://github.com/tabatkins/bikeshed/ these days.


> I changed toBlob to use a dictionary (still at
> https://www.scirra.com/labs/specs/imagedata-conversion-extensions.html).

Cool, though you need to actually define the dictionary. can*Type
should probably return an enum.


-- 
https://annevankesteren.nl/

Re: Async Image -> ImageData conversion

[Anne van Kesteren]

On Mon, Jul 6, 2015 at 2:38 PM, Ashley Gullen  wrote:
> I thought it would be more confusing to have separate competing proposals in
> one document? They are more like three revisions of the same document
> anyway, the latest one including all feedback and rationale so far:
> https://www.scirra.com/labs/specs/imagedata-conversion-extensions.html

Sorry, my bad. It seems the other comments still apply though.


-- 
https://annevankesteren.nl/

Re: Async Image -> ImageData conversion

[Anne van Kesteren]

On Fri, Jul 3, 2015 at 1:51 PM, Ashley Gullen  wrote:
> These conversions are covered by what I proposed in my previous email, so I
> drafted another spec with them:
> https://www.scirra.com/labs/specs/imagedata-conversion-extensions.html

Could you please put them all in a single document? That would make it
a bit easier to follow what is being proposed. And perhaps not use
Respec or figure out some way to get them in a style similar to the
original HTML Standard. This non-algorithmic way of describing methods
is error prone.

A new toBlob() should probably also take a dictionary as second
argument rather than the "any" approach.


-- 
https://annevankesteren.nl/

Re: Components F2F

[Anne van Kesteren]

On Thu, Jul 2, 2015 at 8:56 AM, Ryosuke Niwa  wrote:
> Is Google hosting this meeting as well?  Alternatively, would other browser 
> vendors (e.g. Mozilla) willing to host it this time?

If we decide quickly it seems I can reserve a room at Mozilla for 18
people in SF, maybe 22 in MTV. Not sure that's big enough judging from
last meeting, but I don't have the details.


> I'm supposed to write up a document that summaries what we've agreed thus 
> far.  I've been busy with other stuff lately but will try to post it before 
> the meeting.

Excellent!


-- 
https://annevankesteren.nl/

Custom Elements: "createdCallback" & cloning

[Anne van Kesteren]

In the interest of moving forward I tried to more seriously consider
Dmitry's approach. Based on es-discussion discussion
https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors
it seems likely new JavaScript features (such as private state) will
be tied to object creation. This makes the prototype-swizzling design
even less appealing, in my opinion.

Meanwhile, I have not made much progress on the cloning question. As
Domenic pointed out, that would also either require
prototype-swizzling or invoking the constructor, there's not really a
third way. I guess for that to work cloneNode() and various editing
operations would have to become resilient against JavaScript executing
in the middle of them, something that has caused (is causing?) us a
ton of headaches with mutation events. (Or the alternative, have some
kind of mode switch for the DOM which is similarly a large
undertaking.)

Not sure what to do now :-/


-- 
https://annevankesteren.nl/

Components F2F

[Anne van Kesteren]

Can someone update
https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting with a
bit more information? I hear it might be in Mountain View?

Will we have sufficient time to cover both Custom Elements and Shadow
DOM? And could the drafts maybe be updated to cover what has been
agreed to so far? E.g. it seems we have agreement on slots and I think
that was the last major thing from Shadow DOM that needed a solution.
Would be great if we could review a complete document.


-- 
https://annevankesteren.nl/

Re: Async Image -> ImageData conversion

[Anne van Kesteren]

On Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky  wrote:
> The drawback of adding toBlob/toImageData to the various things ImageData
> can be constructed from is that it's a bit more spec complexity, but I don't
> see that as a showstopper, necessarily.

We should probably stick to the pattern of either having factory
methods or putting methods directly on various objects. Or maybe,
change them all to be static methods on the various classes:

  ImageBitmap.create(...)
  ImageData.create(...)
  ...

I would personally prefer this last pattern for creating instances
where we need to go through a promise.


-- 
https://annevankesteren.nl/

Re: URL bugs and next steps

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 6:00 PM, Philippe Le Hegaret  wrote:
> That's great but are we getting the implementations aligned?

Yes, slowly.


> My understanding is that implementations are still differing from the spec
> and we weren't getting them to move. Reasons for that are differing between
> the vendors.

That is probably in part due to the specification having known
outstanding issues and in part because changing URLs is tricky. Even
small changes we made in Gecko have not been without issue. In any
event, it seems somewhat premature to consider meeting over this (if
that's at all warranted, it's all technical) given the state of the
specification and testsuite.


-- 
https://annevankesteren.nl/

Re: URL bugs and next steps

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 4:25 PM, Philippe Le Hegaret  wrote:
> Things haven't been moving at fixing the bugs in the URL specification. Sam
> has circulated a list of issues but did not receive much feedback. I figured
> the best way to understand to make progress would be to have a call so we
> can figure out the path forward and how we're going to fix the specification
> and the implementations.

I'm in the process of fixing bugs and adding tests, actually.


> If you can attend, this would be helpful to make progress.

There's quite a bit of outstanding feedback from various vendors that
can be addressed first, I think. Not sure what you expect to resolve
on this call?


-- 
https://annevankesteren.nl/

Re: [service_worker] Notification constructor

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 12:28 AM, Conrad Irwin  wrote:
> I've been implementing some things with service workers, and it's a little
> bit frustrating to have to use
>
>   self.registration.showNotification("hi!")
>
> instead of the more normal:
>
>   new Notification("hi!")
>
> Is there a technical reason that service workers can't call the Notification
> constructor as usual?

I recommend reading through this thread:

  
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/thread.html#msg60
  
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/thread.html#msg9


> It would be nice for two reasons:
>
> 1. I could use the same wrapper library in-page and in-worker,

If you already have a wrapper library, you could wrap both.


> 2. I'd be able to call .close() on the returned Notification.

There is nothing that prevents that. Though currently you'd need to
get hold of the Notification object through the getNotifications()
method. Perhaps we should also resolve the promise returned by
showNotification() with a Notification object. You might want to file
an issue against the specification for that.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

On Mon, Jun 15, 2015 at 10:45 AM, Bruce Lawson  wrote:
> On 14 June 2015 at 01:41, Patrick H. Lauke  wrote:
>> it makes more sense to work on stylability of standard elements.
>
> I'd like to keep the is="" construct (or better name) in the knowledge
> that it's a stopgap for v1, and put our energies we're currently
> expending debating this into styling standard elements - which is
> currently being considered http://dev.w3.org/csswg/css-forms/

Why should we standardize a stopgap?


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson
 wrote:
> Is there a succinct explanation of why the is= syntax is disliked?

Rather than

  

you want

  

that just gets all the  goodness through composition/inheritance.


Also the fact that you need  to be able to submit
custom elements is something we should fix in the design of .
That is="" can make certain hacks a little simpler is nice, but that's
not enough to justify standardizing it. I have the feeling we're going
in circles though, since the arguments on both sides have been made
repeatedly for the past x years.


-- 
https://annevankesteren.nl/

Re: Writing spec algorithms in ES6?

[Anne van Kesteren]

On Thu, Jun 11, 2015 at 10:41 PM, Boris Zbarsky  wrote:
> On 6/11/15 4:32 PM, Dimitri Glazkov wrote:
>> I noticed that the CSS Color Module Level 4 actually does this, and it
>> seems pretty nice:
>> http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor
>
> I should note that the ES code there produces semantics that don't match the
> IDL in this spec (or is complete nonsense, depending on how literally you
> choose to read it).

I think we should pick the complete nonsense interpretation as we try
to be precise.

If you use IDL you cannot use ES since the pipeline is ES -> IDL ->
prose that operates on IDL values -> IDL -> ES. Skipping IDL
altogether might be okay, but the infrastructure is not there yet, and
it's way more difficult to get things right.


> I would actually prefer some sort of pseudocode that is _not_ JS-looking,
> just so people don't accidentally screw this up.

If we had more resources I could imagine IDL 1) matching ES-syntax
more and 2) define a bunch of abstract operations that specifications
can use to define their features.


-- 
https://annevankesteren.nl/

Re: Clipboard API: remove dangerous formats from mandatory data types

[Anne van Kesteren]

On Wed, Jun 10, 2015 at 2:55 PM, Arthur Barstow  wrote:
> Are you suggesting/proposing new normative requirement(s) in the "spec
> proper" and/or new text in the security/privacy considerations [1]?
>
> https://w3c.github.io/clipboard-apis/#other-security-and-privacy-considerations

The former, the algorithms in the specification should be secure by default.


-- 
https://annevankesteren.nl/

Re: Clipboard API: remove dangerous formats from mandatory data types

[Anne van Kesteren]

On Wed, Jun 10, 2015 at 11:22 AM, Hallvord Reiar Michaelsen Steen
 wrote:
> Developing web browsers and their specs means paranoia should be part of
> your job description.
> It is a concern and I'm not sure how to solve it.

Well we should be able to allow some things here. Either we verify
that it is an image or we only allow images that are exported from
 or some such... But yeah, passing arbitrary bytes seems bad,
there needs to be some amount of validation.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall  wrote:
> - In the time between v1 and v2 (however long that ends up being) we are
> left without any way to solve this problem, assuming we don't come up with
> something else for v1. If developers start using custom elements where they
> would previously have used a native element, this could well result in a
> regression in accessibility for the web as a whole for this period, and we
> will be stuck with the legacy of code written during this period for much
> longer as well.

I don't see how it is a regression compared to the current situation.


> - I realise that to some extent developers already aren't using native
> elements, in part because of the styling issues we've discussed which also
> affect is=. My concern here is that custom elements will further legitimise
> this habit, which we've been making some recent progress in changing - we
> stand to backslide on that effort. Having is= would allow us to roll it into
> the "use native elements where possible" message rather than diluting it
> with "unless you're using a custom element in which case here's a checklist
> which you're not going to look at of everything it should do" until we come
> up with an alternative.

Most examples of custom elements to date are not actually with is="",
simply because custom tag names are much more appealing. The
ergonomics don't back up the message.


> - v1 sets the stage for people to develop habits and expectations about how
> custom elements work. New features tend to be slowly adopted, by both
> browser vendors and (partly as a consequence) developers, so even if we do
> come up with something for v2, it will be even longer before it becomes
> mainstream (and as I mentioned earlier we will still be stuck with code
> written to v1 for much longer again).

I don't see how it will be longer. is="" is not getting acceptance
as-is. So all this would result in is not getting custom elements
across browsers until v2 is done.


> Here's where we differ, because:
> - I don't think it's a wart. I've given this a great deal of thought and I
> keep ending up back at the current syntax when I try to think of reasonable
> alternatives, even assuming we could magically fix all the implementation
> issues with any alternative proposal.

I think if we figured out how the behavior of current elements is
composed and how to address the styling problem we'd be much closer to
an agreement. And I think everyone agrees those need to be solved, so
I'm a bit lost as to why we don't focus on those.


> - I don't think shipping in one browser is "nothing". People (both framework
> authors and web page authors) are already writing code using is=.

Well, I disagree. E.g. Microsoft had a ton of features shipping in
Internet Explorer 5.0 that were used and never ended up as-is (or at
all) in other browsers. In the long run it's pretty close to
"nothing".


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

On Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani
 wrote:
> And I'm still concerned that removing is= would severely harm the cases
> where you need access to special parsing behavior like  and
> 

Re: CORS performance proposal

[Anne van Kesteren]

On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson  wrote:
> The security properties bother me a little.  Alt-Svc is showing us
> that we can't just define a header field like that without some
> serious analysis.

Same goes for a site-wide file. See crossdomain.xml. However, either
coupled with "credentials mode = omit" seems okayish... Mark, do these
CDN requests mention credentials?


-- 
https://annevankesteren.nl/

Re: [webcomponents] How about let's go with slots?

[Anne van Kesteren]

On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov  wrote:
> Given that all vendors agreed that "C" can wait until v2, we could just
> focus on concretizing the "slots" proposal and then put a lid on Shadow DOM
> v1.
>
> What do you think, folks?

This probably works for Mozilla. It would be good to see the proposed
processing model and its implications for an eventual imperative API.
It's somewhat troubling we don't agree on synchronous vs
when-layout-or-event-dispatch-happens.

Also, I suggest we bikeshed the markup in the direction of
slot=some-slot-name and  rather than
content-slot=some-slot-name and .


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky  wrote:
> On 5/8/15 1:42 AM, Elliott Sprehn wrote:
>> That actually seems pretty similar to what we have, ours is in the form
>> of:
>>
>> Node#insertedInto(Node insertionPoint)
>> Node#removedFrom(Node insertionPoint)
>
> To be clear, ours is also in the form of two methods
> (BindToTree/UnbindFromTree) that take various arguments.

The DOM only has insert/remove hooks:

  https://dom.spec.whatwg.org/#concept-node-insert-ext
  https://dom.spec.whatwg.org/#concept-node-remove-ext

So that seems clearly wrong (in the specification)... Are descendants
notified in tree order?

I filed https://github.com/whatwg/dom/issues/34 to track this.


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn  wrote:
> That actually seems pretty similar to what we have, ours is in the form of:
>
> Node#insertedInto(Node insertionPoint)
> Node#removedFrom(Node insertionPoint)
>
> where insertionPoint is the ancestor in the tree where a connection was
> added or removed which may be arbitrarily far up the ancestor chain. From
> that you can figure out all the cases Boris is describing.

Cool. So maybe the DOM specification needs to be updated to have that
model and we should expose that as low-level hook to web developers.


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky  wrote:
> In Gecko, yes.  The set of hooks Gecko builtin elements have today is,
> effectively:
>
> 1)  This element used to not have a parent and now does.
> 2)  This element has an ancestor that used to not have a parent and now
> does.
> 3)  This element used to have a a parent and now does not.
> 4)  This element has an ancestor that used to have a parent and
> now does not.

So that is more granular than what Dominic said Chrome has. I wonder
why there's a difference. Normally at the low-level things are pretty
close (or have a difference like linked list vs array).


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall  wrote:
> I definitely acknowledge is= may not be the ideal solution to the latter
> problem - it definitely has some holes in it, especially when you start
> adding author shadow roots to things - but I think it does have potential.
> I'd really like to be convinced that we either have a reasonable alternative
> solution, or that it's not worth worrying about.

I think it is worth worrying about, but I don't think it's worth
holding up a minimal v1 of Custom Elements for. The way to get
agreement among all parties is to do less. And then take baby steps
from.

The way I look at this is that currently you have nothing, since only
Chrome ships this. There's a chance to get three more browsers if you
make some concessions on the warts. And then hopefully we can iterate
from there in a more cooperative fashion.

(The thread Steve shared about ARIA seemed like an equivalent effort
by the way, to expose some of the semantics of native elements through
simple attributes.)


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
 wrote:
> How are you supposed to tell if one of your ancestors was removed?

Is that a hook builtin elements have today?


-- 
https://annevankesteren.nl/

Re: Making ARIA and native HTML play better together

[Anne van Kesteren]

On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner  wrote:
> Currently ARIA does not do this stuff AFAIK.

Correct. ARIA only exposes strings to AT. We could maybe make it do
more, once we understand what more means, which is basically figuring
out HTML as Custom Elements...


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, May 7, 2015 at 6:02 AM, Hayato Ito  wrote:
> I'm saying:
> - Composed tree is related with CSS.
> - Node distribution should be considered as a part of style concept.

Right, I think Ryosuke and I simply disagree with that assessment. CSS
operates on the composed tree (and forms a render tree from it).
Events operate on the composed tree. Selection operates on the
composed tree (likely, we haven't discussed this much). Content can be
found within the composed tree (not just the light tree, see
composition). It's a lot more than just style.


-- 
https://annevankesteren.nl/

Re: Custom Elements: Upgrade et al

[Anne van Kesteren]

On Thu, May 7, 2015 at 12:23 AM, Ryosuke Niwa  wrote:
> Are you suggesting that cloning my-button will create a new instance of 
> my-button by invoking its constructor?

No, I'm saying there would be another primitive operation, similar to
the extended structured cloning proposed elsewhere, to accomplish
cloning without side effects.


-- 
https://annevankesteren.nl/

Re: Shadow DOM: state of the distribution API

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking  wrote:
> Has at-end-of-microtask been debated rather than 1/2? Synchronous
> always has the downside that the developer has to deal with
> reentrancy.

1/2 are triggered by the component author. Synchronous just means that
they run within the main global when the component author wants them
to. So effectively timing depends on what tools the component author
has. I have tried to argue they should use mutation observers and
thereby effectively get microtask timing, but changing a bunch of
layout APIs to be asynchronous is a tricky thing. We've also discussed
introducing nanotask mutation observers giving you callbacks at the
end of method calls. They would not require reworking layout APIs, but
would require introducing such a nanotask mutation observer API.

And the performance of nanotasks might not be great if you make lots
of mutations that require distribution. (Not tested though.)


-- 
https://annevankesteren.nl/

Re: Permissions API vs local APIs

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:05 PM, Miguel Garcia  wrote:
> Is there a timeline for the permission API in Mozilla?

It shouldn't be much work to add this. The main problem I see is the
list of open issues with the specification.


-- 
https://annevankesteren.nl/

Re: Permissions API vs local APIs

[Anne van Kesteren]

On Wed, May 6, 2015 at 6:34 PM, Miguel Garcia  wrote:
> Notifications has it (as a property instead of a method which is a pain).

Notifications is a special snowflake though since it has a
requestPermission() method too which no other API that requires
permission (e.g. geolocation, fullscreen, pointer lock) has today. The
Notifications API predates a general Permissions API but is otherwise
largely identical.


> I think that once the permissions API has shipped in both Mozilla and Chrome
> we should get future APIs to use it exclusively. Push seems to be a bit
> border line given the timeline so I think we should just implement in both
> places.

Given that Doug seems okay with shipping this as part of the
Permissions API (which won't wait until 2017, at least not the query()
part) I'm led to the opposite conclusion.


-- 
https://annevankesteren.nl/

Re: Permissions API vs local APIs

[Anne van Kesteren]

On Wed, May 6, 2015 at 5:33 PM, Jonas Sicking  wrote:
> I think Mozilla would be fine with taking the permission API as a
> dependency and implement that at the same time. Implementing the
> permission API should be fairly trivial for us.
>
> But we should verify this with the people actually working on the push API.
>
>> On Wed, May 6, 2015 at 10:59 AM, Michael van Ouwerkerk
>>  wrote:
>>> Yes, we wanted to ensure this is in the Push API because that seems to
>>> have more implementation momentum from browser vendors than the Permissions
>>> API. We didn't want developers to do hacky things in the meantime. I agree
>>> that once the Permissions API has critical mass, that should be the single
>>> place for checking permissions.

Martin, Doug?


-- 
https://annevankesteren.nl/

Re: Custom Elements: Upgrade et al

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:59 PM, Dimitri Glazkov  wrote:
> On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola  wrote:
>> Can you explain how you envision cloning to work a bit more? Somehow there
>> will be instances of these elements which are not created by their
>> constructors?
>
> Also, how is it in any way similar to  how  or  work? I am
> pretty sure both of those are constructed during cloning.

The proposal would be to change that. You can construct an instance.
And you can create a second instance either by cloning the first or
constructing a new one.

The difference between  and  is that for  we
also clone private state using this hook:

  https://dom.spec.whatwg.org/#concept-node-clone-ext

 does no such thing.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:46 PM, Léonie Watson  wrote:
> My understanding is that sub-classing would give us the accessibility 
> inheritance we were hoping is= would provide. Apologies if I've missed it 
> somewhere obvious, but is there any information/detail about the proposed 
> sub-classing feature available anywhere?

It should fall out of figuring out HTML as Custom Elements. Apart from
styling which I think we can solve independently to some extent that's
the big elephant in the room.


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:18 PM, Tab Atkins Jr.  wrote:
> On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren  wrote:
>> 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.
>
> And again, it depends on what level of authority you're talking about.
> As far as the outer page is concerned, the  element is empty,
> and ::webkit-range-thumb is a fictitious pseudo-element created solely
> by the platform.  There's no real DOM underlying it, because the
> shadow dom is fully sealed, so anything inside of it is dead.
>
> From the platform's perspective, sure, there's a real element under
> there.  And the platform does get special powers that the page might
> not have.  But the fact that  is implemented with shadow DOM is
> an undetectable implementation detail at the moment.

A) This platform advantage will go away. Isolated shadow DOM is going
to be a thing developers can play with. B) At the F2F there was lots
of talk that even with custom properties, there was still a desire to
support custom pseudo-elements to target actual elements in a way
similar to what (mostly) WebKit/Blink offer today.


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov  wrote:
> This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866.
>
> The way I remember it, the argument went like this: the most common use case
> for this callback is to react to element becoming part of the main document
> (the rough approximation of a nebulous concept "am I useful on the
> screen?"), and making these callbacks be invoked in other cases may just be
> noise for devs.

I see. We know from HTML that a change of parent element might be
significant, e.g. with  or the   element. I'm
inclined to make a proposal here that we change these callbacks to be
the primitives the DOM offers rather than these higher-level
callbacks.


-- 
https://annevankesteren.nl/

Custom Elements: insert/remove callbacks

[Anne van Kesteren]

Open issues are kept track of here:

  https://wiki.whatwg.org/wiki/Custom_Elements

This has come up before, but it came up again at the Extensible Web
Summit so raising hopefully for the last time.

The DOM has insert/remove primitives for nodes. Custom Elements uses
"insertion into a document" and "removal from a document" which are
quite a bit different and higher level. Why should we have different
primitives here?


-- 
https://annevankesteren.nl/

Custom Elements: Upgrade et al

[Anne van Kesteren]

Open issues are kept track of here:

  https://wiki.whatwg.org/wiki/Custom_Elements

I think the most pragmatic way forward here is accepting that
constructing and upgrading need not be tied.

Synchronous constructors map most closely to what browsers do today
for builtin elements and open up the ability for an end tag callback
(which some elements need if you want to polyfill them, e.g. )
and other hooks into the parser.

Synchronous constructors are problematic with cloning. My suggestion
is that cloning becomes a primitive similar to structured cloning and
that for v1 custom elements behave like , not . A clone
for an element also clones its associated shadow root (deep or not).

As to upgrades, we can consider some kind of notification mechanism
for elements created by the parser that gives the developer full
control over how to manipulate them. (Including when registering after
the fact.) Or perhaps libraries evolve around this and create some
kind of JavaScript module-based system for importing and using HTML
elements. In other words, I don't think we need to consider upgrades a
blocker for v1.

I propose we move upgrades to v2 and update the specification to use
synchronous constructors with a cloning primitive that does not
require invoking the constructor.

(By the way, I'm totally willing to help out with the specification
effort once I'm back from vacation in June. Finally get that DOM
integration underway, but that is conditional on cross-vendor buy-in.)


-- 
https://annevankesteren.nl/

Custom Elements: is=""

[Anne van Kesteren]

Open issues are kept track of here:

  https://wiki.whatwg.org/wiki/Custom_Elements

I think we reached rough consensus at the Extensible Web Summit that
is="" does not do much, even for accessibility. Accessibility is
something we need to tackle low-level by figuring out how builtin
elements work:

  https://github.com/domenic/html-as-custom-elements

And we need to tackle it high-level by making it easier to style
builtin elements:

  http://dev.w3.org/csswg/css-forms/

And if the parser functionality provided by is="" is of great value,
we should consider parsing elements with a hyphen in them differently.
Similar to how 

Shadow DOM: state of the distribution API

[Anne van Kesteren]

It seems we have three contenders for the distribution API.

1) Synchronous, no flattening of . A host element's shadow
tree has a set of slots each exposed as a single  element to
the outside. Host elements nested inside that shadow tree can only
reuse slots from the outermost host element.

2) Synchronous, flattening of . Any host element nested
inside a shadow tree can get anything that is being distributed.
(Distributed  elements are unwrapped and not distributed
as-is.)

3) Lazy. A distinct global (similar to the isolated Shadow DOM story)
is responsible for distribution so it cannot observe when distribution
actually happens.

The argument for 1 is that there are no (good?) use cases for 2 and
that descendants can be distributed, not just children. The argument
for 2 is that it can be used to implement  and
 without much difficulty. The argument for 3 is that
distribution is a layout concept (despite also impacting non-UI events
and DOM APIs).

(1/2 also require something akin "nanotask" mutation observers.)

As I said elsewhere it's not clear to me we should couple DOM and
layout. The composed tree is distinct from the render tree. It's also
not clear to me what 3 would look like. No concrete proposal has been
made. What is clear to me given the experience with service workers is
that introducing a new global environment is not simple and would
likely set us back another couple of years.

That leaves 1/2 and although Ryosuke and Tab have taken sides, neither
has really backed up their story. I tried to explore 1 in
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0474.html
but that did not get much traction. So... trying again.


-- 
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/

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: 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: 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/

Permissions API vs local APIs

[Anne van Kesteren]

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.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

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).


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

On Tue, May 5, 2015 at 6:52 AM, Jonas Sicking  wrote:
> 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.

No, :host matches the host element in the light tree that holds the shadow tree.


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

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?

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


-- 
https://annevankesteren.nl/

Re: [components] Isolated Imports and Foreign Custom Elements

[Anne van Kesteren]

On Sat, May 2, 2015 at 12:07 AM, Maciej Stachowiak  wrote:
> It’s already possible to run a constructor from another global object in the 
> non-cross-origin case.

Okay, that makes more sense. I first read it as a suggestion we'd
construct a node using a same-global constructor and then also run the
foreign-global constructor and it didn't really compute.


> I think it may be necessary to do an experimental implementation to work out 
> all the details of how the two-way isolation works.

I have the feeling there's some overlap with compartments:
http://andreasgal.com/2010/10/13/compartments/ Though I guess
non-Gecko implementations still want to avoid going there.


Another thing that might be nice is that if these elements are that
much isolated, perhaps we can consider allowing them to be renamed
them as well, similar to what module systems allow you to do.


-- 
https://annevankesteren.nl/

Re: [components] Isolated Imports and Foreign Custom Elements

[Anne van Kesteren]

On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak  wrote:
> I wrote up a proposal (with input and advice from Ryosuke Niwa) on a
> possible way to extend Web Components to support fully isolated components:
>
> https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
>
> I welcome comments on whether this approach makes sense.

I don't get the bit where you create a node in one global, but run its
constructor in another. That seems rather Frankenstein-esque. Would
love to see more details overall, as the direction this is going in
certainly seems like the kind of thing we want. Allowing a dozen
Facebook Like buttons to appear on a page using only one additional
global.


-- 
https://annevankesteren.nl/

Re: Inheritance Model for Shadow DOM Revisited

[Anne van Kesteren]

On Fri, May 1, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>> On May 1, 2015, at 1:04 AM, Anne van Kesteren  wrote:
>> This is where you directly access superclass' ShadowRoot I assume and
>> modify things?
>
> In the named slot approach, these overridable parts will be exposed to 
> subclasses as an overridable slot. In terms of an imperative API, it means 
> that the superclass has a virtual method (probably with a symbol name) that 
> can get overridden by a subclass. The default implementation of such a 
> virtual method does nothing, and shows the fallback contents of the slot.
>
>>> 3. Fill "holes" superclass provided - e.g. subclass implements abstract 
>>> virtual functions superclass defined to delegate the work.
>>
>> This is the part that looks like it might interact with distribution, no?
>
> With the named slot approach, we can also model this is an abstract method on 
> the superclass that a subclass must implement. The superclass' shadow DOM 
> construction code then calls this function to "fill" the slot.

I think I need to see code in order to grasp this.


-- 
https://annevankesteren.nl/

Shadow DOM Imperative API proposal #1 vs

[Anne van Kesteren]

Wilson Page attempted to implement  (with microtask
observers as a timing solution for the time being) to see whether that
proposal was workable:

  https://gist.github.com/wilsonpage/d5520bd8d22327633e33

Compared to how  is implemented in #2 this looks
rather jarring and we're not even sure whether it's correct.

If someone could confirm whether it's correct or provide a complete
solution I'd like to add it to the overall proposal page so that the
proposals can be more easily compared:

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md

We should also provide a  implementation for the various
solutions to see whether they can meet that proposal. Though I think
as  was originally proposed the solution with #1 would
get equally complex due to having to do recursive unwrapping of
 elements in script. And the solution with #2 would be
equally simple.

(I updated that page quite significantly by the way to clarify #1 a
bit, make #2 more readable, and also added some alternative solutions
to the timing problem.)


-- 
https://annevankesteren.nl/

Re: Inheritance Model for Shadow DOM Revisited

[Anne van Kesteren]

On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa  wrote:
> To start off, I can think of three major ways by which subclass wants to 
> interact with its superclass:
> 1. Replace what superclass shows entirely by its own content - e.g. grab the 
> device context and draw everything by yourself.

So this requires either replacing or removing superclass' ShadowRoot.


> 2. Override parts of superclass' content - e.g. subclass overrides virtual 
> functions superclass provided to draw parts of the component/view.

This is where you directly access superclass' ShadowRoot I assume and
modify things?


> 3. Fill "holes" superclass provided - e.g. subclass implements abstract 
> virtual functions superclass defined to delegate the work.

This is the part that looks like it might interact with distribution, no?


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn  wrote:
> That's still true if you use ::host, what is the thing on the left hand side
> the ::host lives on? I'm not aware of any pseudo element that's not
> connected to another element such that you couldn't write {thing}::pseudo.

::selection? 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.


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

On Fri, May 1, 2015 at 2:07 AM, Tab Atkins Jr.  wrote:
> On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren  wrote:
>> On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr.  
>> wrote:
>>> Pseudo-elements are things that aren't DOM elements, but are created
>>> by Selectors for the purpose of CSS to act like elements.
>>
>> That's not true for e.g. ::-webkit-slider-thumb as I already indicated.
>
> Sure it is.   has no children, and the shadow tree
> is sealed, so the fact that a shadow tree even exists is hidden from
> DOM.  As far as CSS is capable of discerning, there is no thumb
> element, so the pseudo-element makes sense.

That seems rather arbitrary. To the browser it is a DOM element and to
CSS it is too. E.g. at the global level CSS will have to reason about
what it means to override the element's existing styles.


>> My problem is not with the ability to address the host element, but by
>> addressing it through a pseudo-class, which has so far only been used
>> for matching elements in the tree that have a particular internal
>> slot.
>
> I don't understand what distinction you're trying to draw here.  Can
> you elaborate?

A pseudo-class selector is like a class selector. You match an element
based on a particular trait it has. Your suggestion for :host()
however is to make it match an element that cannot otherwise be
matched. That's vastly different semantics


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito  wrote:
> That's the exactly intended behavior in the current spec.
> The timing of distribution is not observable.

Right, but you can synchronously observe whether something is
distributed. The combination of those two things coupled with us not
wanting to introduce new synchronous mutation observers is what
creates problems for an imperative API.

So if we want an imperative API we need to make a tradeoff. Do we care
about offsetTop et al or do we care about microtask-based mutation
observers? I'm inclined to think we care more about the latter, but
the gist I put forward takes a position on neither and leaves it up to
web developers when they want to distribute (if at all).


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, Apr 30, 2015 at 3:00 PM, Domenic Denicola  wrote:
> OK. So the claim that the current spec cannot be interoperably implemented is 
> false?

Well, the wording could be improved for sure. If you're new to this
you might get confused.


> Why can't we say that this distributedCallback must be invoked at the same 
> time that the current spec updates the distribution result? Since it sounds 
> like there is no interop problem with this timing, I don't understand why 
> this wouldn't be an option.

Because then it would be observable when distribution happens and then
it does become a problem. The current specification allows for lazy
distribution. Once distribution is observable while distributing that
is no longer an option.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, Apr 30, 2015 at 2:44 PM, Domenic Denicola  wrote:
> From: Anne van Kesteren 
>>  var x = new Event(eventType)
>>  someNodeThatIsDistributed.addEventListener(eventType, e => 
>> console.log(e.path))
>>  someNodeThatIsDistributed.dispatchEvent(ev);
>
> Can you explain in a bit more detail why this causes interop problems? What 
> browsers would give different results for this code? What would those results 
> be?

This essentially forces distribution to happen since you can observe
the result of distribution this way. Same with element.offsetWidth
etc. And that's not necessarily problematic, but it is problematic if
you want to do an imperative API as I tried to explain in the bit you
did not quote back.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Tue, Apr 28, 2015 at 5:48 AM, Ryosuke Niwa  wrote:
> One thing that worries me about the `distribute` callback approach (a.k.a. 
> Anne's approach) is that it bakes distribution algorithm into the platform 
> without us having thoroughly studied how subclassing will be done upfront.

Agreed. Dimitri saying these are largely orthogonal makes me hopeful,
but I would prefer to see a strawman API for it before fully
committing to the distribute() design on my gist.


> Mozilla tried to solve this problem with XBL, and they seem to think what 
> they have isn't really great.

Actually, I think that we found we needed something. What was
originally in the Shadow DOM specification was sufficient for our
needs I believe, but got removed...


> In that regard, the first approach w/o distribution has an advantage of 
> letting Web developer experiment with the bare minimum and try out which 
> distribution algorithms and mechanisms work best.

Except that you don't have a clear story for how to move to a
declarative syntax later on. And redistribution seems somewhat
essential as it mostly depends on where you put your host element
whether you're subject to it. Making it immaterial where you put your
host element seems important.


-- 
https://annevankesteren.nl/