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
bangseongb...@hotmail.com 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 d...@domenic.me 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 ish...@w3.org 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 ish...@w3.org 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 rn...@apple.com 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 wilsonp...@me.com 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 art.bars...@gmail.com 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] http://www.w3.org/TR/streams-api/

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
travis.leith...@microsoft.com 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 art.bars...@gmail.com 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 art.bars...@gmail.com 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
hst...@mozilla.com 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 4:15 PM, Domenic Denicola d...@domenic.me 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 img src=foo.png? 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 x-baz/x-baz where XBaz's constructor does 
 `document.body.innerHTML = pHello/p`? 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., scriptdocument.body.innerHTML = ... /script is quite
similar.


-- 
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 bzbar...@mit.edu 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 img, and then let it be GC'd,
today.


-- 
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 d...@domenic.me wrote:
 I have a related question: what happens if the constructor throws?

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


 !DOCTYPE html
 script
 use strict;

 window.throwingMode = true;

 class XFoo extends HTMLElement {
 constructor() {
 if (window.throwingMode) {
 throw new Error(uh-oh!);
 }
 }
 }

 document.registerElement(x-foo, XFoo);
 /script

 x-foo/x-foo

 script
 use strict;

 // What does the DOM tree look like here? Is an x-foo present in some form?
 // HTMLUnknownElement maybe? Just removed from existence?

I guess if the constructor doesn't return an instance but an
exception, we'd rethrow the exception (ends up at window.onerror). We
could have fallback for creating an element anyway, but I'm not sure
that's necessary.


 // This will presumably throw:
 document.body.innerHTML = x-foo/x-foo;

That makes sense. Provided we don't offer fallback instance creation
for the parser case.


 // But will it wipe out body first?

Based on 
https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html#widl-Element-innerHTML
I'd say no. Fragment parsing fails, so we never reach replace all.


 // What about
 document.body.innerHTML = [512 KiB of normal HTML] x-foo/x-foo;
 // ? does the HTML make it in, or does the operation fail atomically, or 
 something else?

It fails atomically, based on the definition of innerHTML.


 // Now let's try something weirder.
 // Assume x-bar / XBar is a well-behaved custom element.

 window.throwingMode = false;
 const el = document.createElement(div);
 el.innerHTML = 
 pa/px-bar/x-barx-foob/x-foopb/px-bar/x-bar;

 window.throwingMode = true;
 el.cloneNode(true); // this will throw, presumably...
 // ... but does the XBar constructor run or not?
 // ... if so, how many times?

If we decide to rethrow, it would only be invoked once. However, given
the other algorithms that use cloneNode(), it's not clear that
throwing is acceptable or what that means when you copy something as a
user (though maybe you just end up copying nothing at all, doesn't
seem too bad).


-- 
https://annevankesteren.nl/

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:49 PM, Domenic Denicola d...@domenic.me 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 d...@domenic.me 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 5:45 PM, Travis Leithead
travis.leith...@microsoft.com 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: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:02 PM,  cha...@yandex-team.ru 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: Custom Elements: createdCallback cloning

[Anne van Kesteren]

On Sun, Jul 12, 2015 at 9:32 PM, Olli Pettay o...@pettay.fi 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. canvas, 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 Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com 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 Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com 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 Mon, Jul 6, 2015 at 2:38 PM, Ashley Gullen ash...@scirra.com 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 Tue, Jul 7, 2015 at 12:24 PM, Ashley Gullen ash...@scirra.com 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 Fri, Jul 3, 2015 at 1:51 PM, Ashley Gullen ash...@scirra.com 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 rn...@apple.com 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 bzbar...@mit.edu 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 p...@w3.org 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 p...@w3.org 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: Custom Elements: is=

[Anne van Kesteren]

On Mon, Jun 15, 2015 at 10:45 AM, Bruce Lawson bru...@opera.com wrote:
 On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk 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: [service_worker] Notification constructor

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 12:28 AM, Conrad Irwin conrad.ir...@gmail.com 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 Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson
lwat...@paciellogroup.com wrote:
 Is there a succinct explanation of why the is= syntax is disliked?

Rather than

  button is=my-button/button

you want

  my-button/my-button

that just gets all the button goodness through composition/inheritance.


Also the fact that you need form is=my-form to be able to submit
custom elements is something we should fix in the design of form.
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 bzbar...@mit.edu 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 art.bars...@gmail.com 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
hst...@mozilla.com 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
canvas 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 Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani
justinfagn...@google.com wrote:
 And I'm still concerned that removing is= would severely harm the cases
 where you need access to special parsing behavior like template and
 style.

With synchronous constructors you could imagine setting the parsing
policy in the constructor (as `this[Element.parsingPolicy] = x` or
some such). I wouldn't want to do that for v1, but it opens up that
possibility of making the HTML parser hackable.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=

[Anne van Kesteren]

On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com 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: CORS performance proposal

[Anne van Kesteren]

On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson martin.thom...@gmail.com 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 dglaz...@google.com 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 slot name=some-slot-name rather than
content-slot=some-slot-name and content slot=some-slot-name.


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu 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 Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
justinfagn...@google.com 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 faulkner.st...@gmail.com 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: Custom Elements: is=

[Anne van Kesteren]

On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com 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 Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org 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 bzbar...@mit.edu 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: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Anne van Kesteren]

On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org 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/

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 content. A host element's shadow
tree has a set of slots each exposed as a single content element to
the outside. Host elements nested inside that shadow tree can only
reuse slots from the outermost host element.

2) Synchronous, flattening of content. Any host element nested
inside a shadow tree can get anything that is being distributed.
(Distributed content 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 content select and
content slot 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/

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: 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 script and template are allowed pretty much
everywhere.

Therefore, I propose that we move subclassing of builtin elements to
v2, remove is= from the specification, and potentially open an issue
on HTML parser changes.


-- 
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. module)
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 canvas, not input. 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/

Re: Permissions API vs local APIs

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:05 PM, Miguel Garcia migu...@chromium.org 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 migu...@chromium.org 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: Shadow DOM: state of the distribution API

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking jo...@sicking.cc 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: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov dglaz...@google.com 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 picture or the details  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/

Re: :host pseudo-class

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl 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 input 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 input 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: is=

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:46 PM, Léonie Watson lwat...@paciellogroup.com 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: Custom Elements: Upgrade et al

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:59 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me 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 canvas or input 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 canvas and input is that for input we
also clone private state using this hook:

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

canvas does no such thing.


-- 
https://annevankesteren.nl/

Re: Custom Elements: Upgrade et al

[Anne van Kesteren]

On Thu, May 7, 2015 at 12:23 AM, Ryosuke Niwa rn...@apple.com 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: Permissions API vs local APIs

[Anne van Kesteren]

On Wed, May 6, 2015 at 5:33 PM, Jonas Sicking jo...@sicking.cc 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
 mvanouwerk...@google.com 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: Permissions API vs local APIs

[Anne van Kesteren]

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

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


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

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

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


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

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

Why?

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


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

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

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

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

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


-- 
https://annevankesteren.nl/

Re: [components] Isolated Imports and Foreign Custom Elements

[Anne van Kesteren]

On Sat, May 2, 2015 at 12:07 AM, Maciej Stachowiak m...@apple.com 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: :host pseudo-class

[Anne van Kesteren]

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

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

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

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


-- 
https://annevankesteren.nl/

Re: :host pseudo-class

[Anne van Kesteren]

On Tue, May 5, 2015 at 6:52 AM, Jonas Sicking jo...@sicking.cc 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: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Anne van Kesteren]

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

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


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

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


-- 
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 m...@apple.com 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 rn...@apple.com wrote:
 On May 1, 2015, at 1:04 AM, Anne van Kesteren ann...@annevk.nl 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/

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

[Anne van Kesteren]

On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote:
 I’m writing any kind of component that creates a shadow DOM, I’d just keep 
 references to all my insertion points instead of querying them each time I 
 need to distribute nodes.

I guess that is true if you know you're not going to modify your
insertion points or shadow tree. I would be happy to update the gist
to exclude this parameter and instead use something like

  shadow.querySelector(content)

somewhere. It doesn't seem important.


 Another important use case to consider is adding insertion points given the 
 list of nodes to distribute.  For example, you may want to “wrap” each node 
 you distribute by an element.  That requires the component author to know the 
 number of nodes to distribute upfront and then dynamically create as many 
 insertion points as needed.

That seems doable.


 So you mean that we'd turn distributionList into a subtree?

 Consider table-chart component which coverts a table element into a chart 
 with each column represented as a line graph in the chart. The user of this 
 component will wrap a regular table element with table-chart element to 
 construct a shadow DOM:

 ```html
 table-chart
   table
 ...
   td data-value=“253” data-delta=5253 ± 5/td
 ...
   /table
 /table-chart
 ```

 Now, suppose I wanted to show a tooltip with the value in the chart. One 
 obvious way to accomplish this would be distributing the td corresponding to 
 the currently selected point into the tooltip. But this requires us allowing 
 non-direct child nodes to be distributed.

So if we did that, distributionList would become distributionRoot. And
whenever add() is invoked any node that is not a descendant of
distributionRoot or is a descendant of a node already add()'d would
throw? It seems that would get us a bit more complexity than the
current algorithm...


 The other thing I would like to explore is what an API would look like
 that does the subclassing as well.

 For the slot approach, we can model the act of filling a slot as if attaching 
 a shadow root to the slot and the slot content going into the shadow DOM for 
 both content distribution and filling of slots by subclasses.

 Now we can do this in either of the following two strategies:
 1. Superclass wants to see a list of slot contents from subclasses.
 2. Each subclass overrides previous distribution done by superclass by 
 inspecting insertion points in the shadow DOM and modifying them as needed.

With the existence of closed shadow trees, it seems like you'd want to
allow for the superclass to not have to share its details with the
subclass.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, Apr 30, 2015 at 2:30 PM, Domenic Denicola d...@domenic.me wrote:
 Can someone point me to the part of the spec that is problematic? That is,
 where is the line that says UAs may run this algorithm at any time? I am
 not sure what to Ctrl+F for.

At the end of section 3.4 it states If any condition which affects
the distribution result changes, the distribution result must be
updated before any use of the distribution result. which basically
means you can't make use of a dirty tree.


 Secondly, could someone produce a code snippet that would cause such interop
 problems, given the current spec?

  var x = new Event(eventType)
  someNodeThatIsDistributed.addEventListener(eventType, e =
console.log(e.path))
  someNodeThatIsDistributed.dispatchEvent(ev);


 Finally, assuming we have such an example, would there be a way to tighten
 the spec language such that we don't need to specify e.g. when style
 recalculation happens, but instead specify constraints? Like offsetTop must
 always reflect the redistributions or something.

That is what the specification currently does and what prevents us
from defining an imperative API. For an imperative API it is
imperative (mahaha) that we get the timing with respect to tasks
right. (Or as per my proposal, leave timing up to developers.)


-- 
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 hay...@chromium.org 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 Tue, Apr 28, 2015 at 12:31 AM, Hayato Ito hay...@chromium.org wrote:
 I think there are a lot of user operations where distribution must be
 updated before returning the meaningful result synchronously.
 Unless distribution result is correctly updated, users would take the dirty
 result.

 For example:
 - element.offsetWidth:  Style resolution requires distribution. We must
 update distribution, if it's dirty, before calculation offsetWidth
 synchronously.
 - event dispatching: event path requires distribution because it needs a
 composed tree.

 Can the current HTML/DOM specs are rich enough to explain the timing when
 the imperative APIs should be run in these cases?

The imperative API I proposed leaves the timing up to whenever
distribute() is invoked by the developer. Currently at best that can
be done from mutation observers. And I think that's fine for v1.
element.offsetWidth et al are bad APIs that we should not accommodate
for. The results they return will be deterministic, but they should
not cause further side effects such as distribution and therefore the
results might appear incorrect I suppose depending on what point of
view you have.

We discussed this point at the meeting.


 For me, the imperative APIs for distribution sounds very similar to the
 imperative APIs for style resolution. The difficulties of both problems
 might be similar.

Only if you insist on coupling them are they similar. And only if you
insist on semantics that are identical to content select. This is
the very reason why content select is not acceptable as it would
require solving that problem. Whereas an imperative API free of the
warts of element.offsetWidth would not have to.


-- 
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 rn...@apple.com 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/

Re: Inheritance Model for Shadow DOM Revisited

[Anne van Kesteren]

On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote:
 The problem with shadow as function is that the superclass implicitly 
 selects nodes based on a CSS selector so unless the nodes a subclass wants to 
 insert matches exactly what the author of superclass considered, the subclass 
 won't be able to override it. e.g. if the superclass had an insertion point 
 with select=input.foo, then it's not possible for a subclass to then 
 override it with, for example, an input element wrapped in a span.

So what if we flipped this as well and came up with an imperative API
for shadow as a function. I.e. shadow as an actual function?
Would that give us agreement?

It'd be great to have something like this available.


-- 
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 d...@domenic.me wrote:
 From: Anne van Kesteren ann...@annevk.nl
  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: :host pseudo-class

[Anne van Kesteren]

On Fri, May 1, 2015 at 2:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com 
 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.  input type=range 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: :host pseudo-class

[Anne van Kesteren]

On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn espr...@chromium.org 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/