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

[Justin Fagnani]

On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren  wrote:

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

The implied key point here is that we can relax restrictions in the future,
but it's difficult-to-impossible to tighten restrictions.



>
> --
> https://annevankesteren.nl/
>
>

Re: Callback when an event handler has been added to a custom element

[Justin Fagnani]

You can also override addEventListener/removeEventListener on your element.
My concern with that, and possibly an event listener change callback, is
that it only works reliably for non-bubbling events.

On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> Interesting. Alternatively, you can add .onwhatever handlers, as well as
> define your own overload of addEventListener (which will be called instead
> of the EventTarget.addEventListener method). That way you can capture all
> attempts at setting events on your element.
>
> -Original Message-
> From: Mitar [mailto:mmi...@gmail.com]
> Sent: Thursday, November 5, 2015 4:05 PM
> To: public-webapps 
> Subject: Callback when an event handler has been added to a custom element
>
> Hi!
>
> We are using message ports to communicate with our logic and are wrapping
> the API into a custom element. The issue is that we would like to call
> start on a message port only after user has registered an event handler on
> the custom element instance. But it seems there is no way to get a callback
> when an event handler is added.
>
> So I am suggesting that there should be a callback every time an event
> listener is added to a custom element (and possibly one when removed).
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
>

Re: Callback when an event handler has been added to a custom element

[Justin Fagnani]

On Fri, Nov 6, 2015 at 12:44 PM, Olli Pettay <o...@pettay.fi> wrote:

> On 11/06/2015 09:28 PM, Justin Fagnani wrote:
>
>> You can also override addEventListener/removeEventListener on your
>> element. My concern with that, and possibly an event listener change
>> callback, is
>> that it only works reliably for non-bubbling events.
>>
> How even with those? One could just add capturing event listener higher up
> in the tree.
>

Good point. I forgot that capturing works with non-bubbling events :(


> You need to override addEventListener on EventTarget, and also relevant
> onfoo EventHandler setters on Window and Document and *Element prototypes,
> but unfortunately even that doesn't catch onfoo content attributes ( onclick="doSomething">). But one could use MutationObserver then to
> observe changes to DOM.
>
>
> -Olli
>
>
>
>> On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead <
>> travis.leith...@microsoft.com <mailto:travis.leith...@microsoft.com>>
>> wrote:
>>
>> Interesting. Alternatively, you can add .onwhatever handlers, as well
>> as define your own overload of addEventListener (which will be called
>> instead of the EventTarget.addEventListener method). That way you can
>> capture all attempts at setting events on your element.
>>
>> -Original Message-
>> From: Mitar [mailto:mmi...@gmail.com <mailto:mmi...@gmail.com>]
>> Sent: Thursday, November 5, 2015 4:05 PM
>> To: public-webapps <public-webapps@w3.org > public-webapps@w3.org>>
>> Subject: Callback when an event handler has been added to a custom
>> element
>>
>> Hi!
>>
>> We are using message ports to communicate with our logic and are
>> wrapping the API into a custom element. The issue is that we would like to
>> call
>> start on a message port only after user has registered an event
>> handler on the custom element instance. But it seems there is no way to get
>> a
>> callback when an event handler is added.
>>
>> So I am suggesting that there should be a callback every time an
>> event listener is added to a custom element (and possibly one when removed).
>>
>>
>> Mitar
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
>>
>>
>

Re: Custom Elements: is=

[Justin Fagnani]

We also have an extension of form which collects values from both native
and custom inputs.

On Thu, Jun 11, 2015 at 1:41 PM, Joshua Peek j...@joshpeek.com wrote:

 GitHub has been using tag extensions in a few places for progressive
 enhancement. Form and button elements have been the most useful things
 to extend the behavior of. is= syntax aside, I do agree extending
 complex native element prototypes in general has alot of associated
 undefined behavior. If is= is going to be dropped, we'll probably
 revert back to annotating these elements with special class names or
 data- attributes and avoid custom elements for these use cases.

 On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall aboxh...@google.com wrote:
 
  On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl
 wrote:
 
  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.
 
 
  Exactly: this describes the current situation, which I think is
  unsatisfactory.
 
   - 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.
 
 
  Polymer have a whole suite of elements which use is=:
  https://elements.polymer-project.org/browse?package=gold-elements
 
  When you refer to ergonomics, are you talking purely about the syntax?
 Or
  about the set of issues involved in using native elements compared to
 (lower
  case c) custom elements: essentially, whether or not you're ceding some
  control over styling and behaviour to the browser?
 
   - 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.
 
 
  I think Dimitri responded to this better than I could.
 
 
   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 agree that those problems need to be solved (in particular, the styling
  issue also comes into play when using is=), but I think that these are
  multiple pieces of the same puzzle.
 
  The primitives are critical for creating novel types of elements, which
  won't be able to benefit from type extensions in any case. Styling is
  critical for getting people to use native elements with or without type
  extensions.
 
  Allowing developers to extend native types means that users benefit from
 not
  relying on custom element developers who just want to create a button
 with
  some fancy rendering (beyond what can be achieved using CSS alone), or
  custom behaviour, remembering to re-implement all of the accessibility
  affordances which are built in to an HTML button. It also means that
  developers benefit from not having to do the extra legwork for
  accessibility.
 
  We see time after time after time that accessibility 

Re: Custom Elements: is=

[Justin Fagnani]

On Jun 9, 2015 8:45 AM, Dimitri Glazkov dglaz...@google.com wrote:

 On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl
wrote:


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


 I sort of assumes that the reason for this discussion is to get everyone
on the same page regarding type extension and hope to arrive at better
acceptance.

 Arguing that something isn't getting acceptance when the purpose of
discussion is attempting to gain the said acceptance seems a bit circular.

 Other than that, please do continue this conversation! :)

I'll also note that a large fraction of Polymer elements and Polymer using
pages, thus a large fraction of existing custom elements and use, uses is=,
via template is=dom-repeat / dom-if / dom-bind and style
is=custom-style. So as far as current custom elements are concerned, is=
is accepted.


 :DG

Re: Custom Elements: is=

[Justin Fagnani]

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.

On Mon, Jun 8, 2015 at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:

 Did anyone have any further thoughts on this? My concerns haven't changed.

 On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote:

 On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 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.


 I can definitely see that logic.

 My concerns with this in practice are:

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

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


 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.


 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 don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.


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


 Thanks for the pointer - I followed up on that thread with some thoughts
 on that proposal.

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

[Justin Fagnani]

On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola d...@domenic.me wrote:

  In case it wasn't clear, named slots vs. tag names is purely a bikeshed
 color (but an important one, in the syntax is UI sense). None of the
 details of how the proposal works change at all.

They're not equivalent, because any element can have the right content-slot
value, but with tag names, only one (or maybe N) names would be supported.

 If you already knew that but still prefer content-slot attributes, then I
 guess we just disagree. But it wasn't clear.

I greatly prefer select, but this is a compromise to enable progress.




  From: Elliott Sprehn
 Sent: Monday, May 18, 21:03
 Subject: Re: [webcomponents] How about let's go with slots?
 To: Justin Fagnani
 Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov,
 Scott Miles, Ryosuke Niwa, Edward O'Connor, Anne van Kesteren, Travis
 Leithead, Maciej Stachowiak, Arron Eicholz, Alex Russell, public-webapps

 I'd like this API to stay simple for v1 and support only named slots and
 not tag names. I believe we can explain what details does with the
 imperative API in v2.

 On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani justinfagn...@google.com
 wrote:

  On Mon, May 18, 2015 at 4:58 PM, Philip Walton phi...@philipwalton.com
 wrote:

  Pardon my question if this has been discussed elsewhere, but it's not
 clear from my reading of the slots proposal whether they would be allowed
 to target elements that are not direct children of the component.

 I believe the with the `select` attribute this was implicitly required
 because only compound selectors were supported (i.e. no child or descendent
 combinators) [1].

  I think the actually issue is that you might have fights over who gets
 to redistribute an element. Given

 my-el-1

   my-el-2

 div content-slot=foo/div

   /my-el-2

 /my-el-1

 If both my-el-1 and my-el-2 have foo slots, who wins? What if the winner
 by whatever rules adds a clashing slot name in a future update?

 I mentioned in this in Imperative API thread, but I think the least
 surprising way forward for distributing non-children is to allow nodes to
 cooperate on distribution, so a element could send its distributed nodes to
 an ancestor:
 https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html




 Would named slots be able to target elements farther down in the tree?



 [1]
 http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select

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

[Justin Fagnani]

On Mon, May 18, 2015 at 4:58 PM, Philip Walton phi...@philipwalton.com
wrote:

 Pardon my question if this has been discussed elsewhere, but it's not
 clear from my reading of the slots proposal whether they would be allowed
 to target elements that are not direct children of the component.

 I believe the with the `select` attribute this was implicitly required
 because only compound selectors were supported (i.e. no child or descendent
 combinators) [1].


I think the actually issue is that you might have fights over who gets to
redistribute an element. Given

my-el-1
  my-el-2
div content-slot=foo/div
  /my-el-2
/my-el-1

If both my-el-1 and my-el-2 have foo slots, who wins? What if the winner
by whatever rules adds a clashing slot name in a future update?

I mentioned in this in Imperative API thread, but I think the least
surprising way forward for distributing non-children is to allow nodes to
cooperate on distribution, so a element could send its distributed nodes to
an ancestor:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html




 Would named slots be able to target elements farther down in the tree?


 [1]
 http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select

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

[Justin Fagnani]

Like we pointed out in the previous thread, adding enough special cases to
slots leads to select.

At this point we're much more interested in agreeing on something rather
than nothing.

On Mon, May 18, 2015 at 3:58 PM, Domenic Denicola d...@domenic.me wrote:

 I was thinking opposed. I don’t see any reason to invent two ways to do
 the same thing.

 If we do support content-slot then I think we should allow detailsdiv
 content-slot=summary.../div.../details and a few others.

Re: Custom Elements: is=

[Justin Fagnani]

If I'm understanding your proposal correctly, wouldn't this limit any
document to have a single subclass per native element?

How would you express:

button is=my-fancy-buttonMe/button
button is=your-fancy-buttonYou/button

-Justin

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead 
travis.leith...@microsoft.com wrote:

 The 'is' attribute is only a declarative marker; it's the indicator that
 the native element has a [potential] custom prototype and hierarchy, right?

 I don't mean to drudge up past history and decisions already laid to rest,
 but if subclassing native elements is a good compromise until we get to the
 underlying behaviors that make up native HTML elements, why should we limit
 registerElement to hyphenated custom element names?

 In other words, why not simplify by:
 1. Allow any localName to be used by registerElement. (This would imply
 the HTML namespace by default; we can later add registerElementNS if needed
 :)
 2.  Drop the 'extends' member from the ElementRegistrationOptions
 dictionary.

 With this simplification, serializing elements wouldn't include any sign
 that they are 'customized' in any way (as is done with 'is' today). I don't
 see this as a problem, since web devs today can already do this, but
 without the help of the parser.

 It always seemed weird to me that 'prototype' of
 ElementRegistrationOptions can inherit from anything (including null), and
 be completely disassociated from the localName provided in 'extends'.

 If we drop support for 'is' in v1, then we can consider later bringing
 back subclassing in v2 without introducing 'extends' in the
 ElementRegistrationOptions or the 'is' attribute.

 If we opt to keep the feature, I'd like to see it simplified as described
 above.

 (In general: I'd also like to see a 'constructor' property added
 automatically to the prototype so that you can always get to the native
 constructor function from script even if you don't save the return value of
 registerElement.)


  On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
  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.

 We (Apple) support this proposal.

 - R. Niwa

Re: Custom Elements: is=

[Justin Fagnani]

On Fri, May 8, 2015 at 1:10 PM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  Yes, I think you are understanding correctly, and it appears this would
 be a side-effect J. You have the same problem with two implementations of
 x-button though the pool of custom element names is going to be larger.



 Do you think this will be a problem in practice?


Definitely.

Custom element names will hopefully fall into self-organized namespaces,
for instance the Polymer team is putting out element collections, like
iron-* and paper-* and we very well might have both iron-button and
paper-button. There would be no chance for that with native element
extensions without is=.




 *From:* Justin Fagnani [mailto:justinfagn...@google.com]
 *Sent:* Friday, May 8, 2015 1:06 PM
 *To:* Travis Leithead
 *Cc:* Ryosuke Niwa; Anne van Kesteren; WebApps WG
 *Subject:* Re: Custom Elements: is=



 If I'm understanding your proposal correctly, wouldn't this limit any
 document to have a single subclass per native element?



 How would you express:



 button is=my-fancy-buttonMe/button

 button is=your-fancy-buttonYou/button



 -Justin



 On Fri, May 8, 2015 at 12:56 PM, Travis Leithead 
 travis.leith...@microsoft.com wrote:

 The 'is' attribute is only a declarative marker; it's the indicator that
 the native element has a [potential] custom prototype and hierarchy, right?

 I don't mean to drudge up past history and decisions already laid to rest,
 but if subclassing native elements is a good compromise until we get to the
 underlying behaviors that make up native HTML elements, why should we limit
 registerElement to hyphenated custom element names?

 In other words, why not simplify by:
 1. Allow any localName to be used by registerElement. (This would imply
 the HTML namespace by default; we can later add registerElementNS if needed
 :)
 2.  Drop the 'extends' member from the ElementRegistrationOptions
 dictionary.

 With this simplification, serializing elements wouldn't include any sign
 that they are 'customized' in any way (as is done with 'is' today). I don't
 see this as a problem, since web devs today can already do this, but
 without the help of the parser.

 It always seemed weird to me that 'prototype' of
 ElementRegistrationOptions can inherit from anything (including null), and
 be completely disassociated from the localName provided in 'extends'.

 If we drop support for 'is' in v1, then we can consider later bringing
 back subclassing in v2 without introducing 'extends' in the
 ElementRegistrationOptions or the 'is' attribute.

 If we opt to keep the feature, I'd like to see it simplified as described
 above.

 (In general: I'd also like to see a 'constructor' property added
 automatically to the prototype so that you can always get to the native
 constructor function from script even if you don't save the return value of
 registerElement.)



  On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
  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.

 We (Apple) support this proposal.

 - R. Niwa

Re: Custom Elements: insert/remove callbacks

[Justin Fagnani]

On Wed, May 6, 2015 at 8:25 AM, Anne van Kesteren ann...@annevk.nl wrote:

 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.


How are you supposed to tell if one of your ancestors was removed?





 --
 https://annevankesteren.nl/

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

[Justin Fagnani]

Here's one case of redistribution:
https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122

Any time you see content inside a custom element it's potentially
redistribution. Here there's on that is (line 122), and one that could be
(line 116), and one that definitely isn't (line 106).

I personally think that Hayato's analogy to function parameters is very
motivating. Arguing from use-cases at this point is going to miss many
things because so far we've focused on the most simple of components, are
having to rewrite them for Polymer 0.8, and haven't seen the variety and
complexity of cases that will evolve naturally from the community. General
expressiveness is extremely important when you don't have an option to work
around it - redistribution is one of these cases.

Cheers,
  Justin


On Wed, Apr 29, 2015 at 4:57 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:

 On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa rn...@apple.com wrote:
  On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
  On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com
 wrote:
  On Mon, Apr 27, 2015 at 8:48 PM, 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.
 
  Mozilla tried to solve this problem with XBS, and they seem to think
 what
  they have isn't really great. Google has spent multiple years working
 on
  this problem but they come around to say their solution, multiple
  generations of shadow DOM, may not be as great as they thought it
 would be.
  Given that, I'm quite terrified of making the same mistake in
 spec'ing how
  distribution works and later regretting it.
 
  At least the way I understand it, multiple shadow roots per element and
  distributions are largely orthogonal bits of machinery that solve
 largely
  orthogonal problems.
 
  Yes.  Distribution is mainly about making composition of components
  work seamlessly, so you can easily pass elements from your light dom
  into some components you're using inside your shadow dom.  Without
  distribution, you're stuck with either:
 
  As I clarified my point in another email, neither I nor anyone else is
 questioning the value of the first-degree of node distribution from the
 light DOM into insertion points of a shadow DOM.  What I'm questioning is
 the value of the capability to selectively re-distribute those nodes in a
 tree with nested shadow DOMs.
 
  * components have to be explicitly written with the expectation of
  being composed into other components, writing their own content
  select *to target the content elements of the outer shadow*, which
  is also extremely terribad.
 
  Could you give me a concrete use case in which such inspection of
 content elements in the light DOM is required without multiple generations
 of shadow DOM?  In all the use cases I've studied without multiple
 generations of shadow DOM, none required the ability to filter nodes inside
 a content element.
 
  Distribution makes composition *work*, in a fundamental way.  Without
 it, you simply don't have the ability to use components inside of
 components except in special cases.
 
  Could you give us a concrete example in which selective re-distribution
 of nodes are required? That'll settle this discussion/question altogether.

 I'll let a Polymer person provide a concrete example, as they're the
 ones that originally brought up redistribution and convinced us it was
 needed, but imagine literally any component that uses more than one
 content (so you can't get away with just distributing the content
 element itself), being used inside of some other component that wants
 to pass some of its light-dom children to the nested component.

 Without redistribution, you can only nest components (using one
 component inside the shadow dom of another) if you either provide
 contents directly to the nested component (no content) or the nested
 component only has a single distribution point in its own shadow.

 ~TJ

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

[Justin Fagnani]

On Tue, Apr 28, 2015 at 4:32 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:

 On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
 IMO, the appeal of this proposal is that it's a small change to the
 current spec and avoids changing user expectations about the state of the
 dom and can explain the two declarative proposals for distribution.

 It seems like with this API, we’d have to make O(n^k) calls where n is the
 number of distribution candidates and k is the number of insertion points,
 and that’s bad.  Or am I misunderstanding your design?


 I think you've understood the proposed design. As you noted, the cost is
 actually O(n*k). In our use cases, k is generally very small.


 I don't think we want to introduce O(nk) algorithm. Pretty much every
 browser optimization we implement these days are removing O(n^2) algorithms
 in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because
 we can't even theoretically optimize it away.


 You're aware, obviously, that O(n^2) is a far different beast than
 O(nk).  If k is generally small, which it is, O(nk) is basically just
 O(n) with a constant factor applied.


 To make it clear: I'm not trying to troll Ryosuke here.

 He argued that we don't want to add new O(n^2) algorithms if we can
 help it, and that we prefer O(n).  (Uncontroversial.)

 He then further said that an O(nk) algorithm is sufficiently close to
 O(n^2) that he'd similarly like to avoid it.  I'm trying to
 reiterate/expand on Steve's message here, that the k value in question
 is usually very small, relative to the value of n, so in practice this
 O(nk) is more similar to O(n) than O(n^2), and Ryosuke's aversion to
 new O(n^2) algorithms may be mistargeted here.


 Thanks for clarification. Just as Justin pointed out [1], one of the most
 important use case of imperative API is to dynamically insert as many
 insertion points as needed to wrap each distributed node.  In such a use
 case, this algorithm DOES result in O(n^2).


I think I said it was a possibility opened by an imperative API, but I
thought it would be very rare (as will be any modification of the shadow
root in the distribution callback). I think that accomplishing decoration
by inserting an insertion point per distributed node is probably a
degenerate case and it would be better if we supported decoration, but that
seems like a v2+ type feature.

-Justin



 In fact, it could even result in O(n^3) behavior depending on how we spec
 it.  If the user code had dynamically inserted insertion points one by one
 and UA invoked this callback function for each insertion point and each
 node.  If we didn't, then author needs a mechanism to let UA know that the
 condition by which insertion points select a node has changed and it needs
 to re-distribute all the nodes again.

 - R. Niwa

 [1]
 https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html

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

[Justin Fagnani]

On Mon, Apr 27, 2015 at 1:01 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani
 justinfagn...@google.com wrote:
  I really don't think the platform needs to do anything to support
  subclassing since it can be done so easily at the library level now that
  multiple generations of shadow roots are gone. As long as a subclass and
  base class can cooperate to produce a single shadow root with insertion
  points, the platform doesn't need to know how they did it.

 So a) this is only if they cooperate


In reality, base and sub class are going to have to cooperate. There's no
style or dom isolation between the two anymore, and lifecycle callbacks,
templating, and data binding already make them pretty entangled.


 and the superclass does not want
 to keep its tree and distribution logic hidden


A separate hidden tree per class sounds very much like multiple generations
of shadow trees, and we just killed that... This is one of my concerns
about the inheritance part of the slots proposal: it appeared to give new
significance to template tags which essentially turn them into multiple
shadow roots, just without the style isolation.


 and b) if we want to
 eventually add declarative functionality we'll need to explain it
 somehow. Seems better that we know upfront how that will work.


I think this is a case where the frameworks would lead and the platform, if
it ever decided to, could integrate the best approach - much like data
binding.

I imagine that frameworks will create declarative forms of distribution and
template inheritance that work something like the current system, or the
slots proposal (or other template systems with inheritance like Jinja). I
don't even think a platform-based solution won't be any faster in the
common case because the frameworks can pre-compute the concrete template
(including distribution points and bindings) from the entire inheritance
hierarchy up front, and stamp out the same thing per instance.

Cheers,
  Justin




 --
 https://annevankesteren.nl/

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

[Justin Fagnani]

On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren ann...@annevk.nl
wrote:

 On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote:
  One major drawback of this API is computing insertionList is expensive
  because we'd have to either (where n is the number of nodes in the shadow
  DOM):
 
  Maintain an ordered list of insertion points, which results in O(n)
  algorithm to run whenever a content element is inserted or removed.


I don't expect shadow roots to be modified that much. We certainly don't
see it now, though the imperative API opens up some new possibilities like
calculating a grouping of child nodes and generating a content tag per
group, or even generating a content tag per child to perform decoration.
I still think those would be very rare cases.


  Lazily compute the ordered list of insertion points when `distribute`
  callback is about to get called in O(n).

 The alternative is not exposing it and letting developers get hold of
 the slots. The rationale for letting the browser do it is because you
 need the slots either way and the browser should be able to optimize
 better.


  If we wanted to allow non-direct child descendent (e.g. grand child
 node) of
  the host to be distributed, then we'd also need O(m) algorithm where m is
  the number of under the host element.  It might be okay to carry on the
  current restraint that only direct child of shadow host can be
 distributed
  into insertion points but I can't think of a good reason as to why such a
  restriction is desirable.


The main reason is that you know that only a direct parent of a node can
distribute it. Otherwise any ancestor could distribute a node, and in
addition to probably being confusing and fragile, you have to define who
wins when multiple ancestors try to.

There are cases where you really want to group element logically by one
tree structure and visually by another, like tabs. I think an alternative
approach to distributing arbitrary descendants would be to see if nodes can
cooperate on distribution so that a node could pass its direct children to
another node's insertion point. The direct child restriction would still be
there, so you always know who's responsible, but you can get the same
effect as distributing descendants for a cooperating sets of elements.


 So you mean that we'd turn distributionList into a subtree? I.e. you
 can pass all descendants of a host element to add()? I remember Yehuda
 making the point that this was desirable to him.

 The other thing I would like to explore is what an API would look like
 that does the subclassing as well. Even though we deferred that to v2
 I got the impression talking to some folks after the meeting that
 there might be more common ground than I thought.


I really don't think the platform needs to do anything to support
subclassing since it can be done so easily at the library level now that
multiple generations of shadow roots are gone. As long as a subclass and
base class can cooperate to produce a single shadow root with insertion
points, the platform doesn't need to know how they did it.

Cheers,
  Justin



 As for the points before about mutation observers. I kind of like just
 having distribute() for v1 since it allows maximum flexibility. I
 would be okay with having an option that is either optin or optout
 that does the observing automatically, though I guess if we move from
 children to descendants that gets more expensive.


 --
 https://annevankesteren.nl/

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com
 wrote:
 
  I do want the ability to redirect distributed nodes into a holes in the
 base template, so that part is welcome to me. However, my first reaction to
 the slot idea is that forcing users to add the content-slot attribute on
 children significantly impairs the DOM API surface area of custom elements.
 
  For the single-level distribution case, how is this different from
 content select=[content-slot=name] except that content select can
 distribute based on features of the children that might already exist, like
 tag names or an attribute?

 At the conceptual level, they're equivalent.  However, we didn't find the
 extra flexibility of using CSS selectors compelling as we mentioned in our
 proposal [1].


I personally would like to see more power, especially positional selectors.
Some components would be better off selecting their first child, rather
than requiring a class.


 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


Point 4 is interesting, because unless I'm missing something (which could
be!) it's incorrect. You can create selectors with :not() that exclude the
content selectors that come after in document order. I would rewrite the
example as:

template
  content select=.header/content
  content select=:not(.footer)/content
  content select=.footer/content
/template

Cheers,
  Justin




 - R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

Another technique I've seen used is compound selectors, which could be used
to migrate from one selector to another while preserving backwards
compatibility, or to provide some nice default distributions that are also
accessible via a class or attribute (ie, select=header, .header).

Could slots have multiple names to support something like this?

On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com
wrote:



 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com
 wrote:
 
  I do want the ability to redirect distributed nodes into a holes in the
 base template, so that part is welcome to me. However, my first reaction to
 the slot idea is that forcing users to add the content-slot attribute on
 children significantly impairs the DOM API surface area of custom elements.
 
  For the single-level distribution case, how is this different from
 content select=[content-slot=name] except that content select can
 distribute based on features of the children that might already exist, like
 tag names or an attribute?

 At the conceptual level, they're equivalent.  However, we didn't find the
 extra flexibility of using CSS selectors compelling as we mentioned in our
 proposal [1].


 I personally would like to see more power, especially positional
 selectors. Some components would be better off selecting their first child,
 rather than requiring a class.


 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


 Point 4 is interesting, because unless I'm missing something (which could
 be!) it's incorrect. You can create selectors with :not() that exclude the
 content selectors that come after in document order. I would rewrite the
 example as:

 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template

 Cheers,
   Justin




 - R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen
wrote:

 Hi Tab,

 Thanks for your feedback!

 A primary motivation for proposing names instead of CSS selectors to
 control distribution is to enable subclassing. We think it’s important for
 a subclass to be able to override a base class insertion point.


I understand this motivation and think it's a great point that hasn't (yet)
received enough attention...

But I think we would give up to much user ergonomics in exchange for it
under this proposal. I think we can relatively easily add the ability to
redirect nodes into distribution points of base classes to the existing
system which gives some control to authors on how to select nodes for
distribution.


 That seems easier to achieve with a name. It lets content insertion points
 behave like named DOM-valued component parameters that can be overridden by
 subclasses.

 To use an example, consider the page template component example at
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
 The image shows a page template for a large university web site. In this
 example, a base page template class defines a header slot. A university
 department wants to create a subclass of this template that partially
 populates some of the base class’ slots. In this case, it may want to add
 the department name to the header slot, then redefine an insertion point
 with the name that lets an individual page in that department add
 additional text to the header.

 The physics department page template subclass could then write something
 like this (following the proposal's syntax):

 template
   div content-slot=“header”
 Physics Department
 content slot=“header”/content
   /div
 template

 If an instance of this page then says

 physics-department-page
   headerFaculty/header
 /physics-department-page


I know you mistakenly used a header tag rather than content-slot here,
but I think it shows my point: this here (using header tags) might be the
better API, and I feel that the element author should be able to offer it
instead of forcing users to add content-slot attributes everywhere.

I think this proposal targets custom element subclassers at the expense of
custom element users. Yes, subclassers might need fine-grained control over
routing children and distributed nodes into base class distribution points.
But should end-users have to use the same API surface for that? For custom
elements to be successful we don't just need to appeal to element authors,
but in turn to their users.

Cheers,
  Justin


then the rendered result shows “Physics Department Faculty” in the base
 template header.

 This is analogous to what typical OOP languages enable when a subclass
 overrides a base class property. In such languages, the subclass simply
 defines a property with the same name as a base class property. The
 subclass’ property implementation can invoke the base class property
 implementation if it wants. The model is fairly easy to understand and
 implement, because the properties are always identified by name.

 A similar result could theoretically be achieved with CSS selectors, but
 the approach feels looser and a bit unwieldy, particularly if there are not
 rigid conventions about how the content select clauses are written.
 Assuming it were possible to reproject into a base class’ shadow — and
 that’s not actually possible today — you’d have to write something like:

 template
   shadow
 div class=“header”
   Physics Department
   content select=“.header/content
 /div
   /shadow
 /template

 So that approach could be made to work, but to me at least, feels harder,
 especially if the base class is using complex CSS selectors.

 –Jan

 On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:

 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?


 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.


 content select=[my-attr='the slot value']


 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing
 an
 element based on an attribute value.


 Oh, interesting.  That appears to be a complete non-sequitur, tho, as
 no one has asked for anything like that.  

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com
 wrote:



 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com
 wrote:
 
  I do want the ability to redirect distributed nodes into a holes in the
 base template, so that part is welcome to me. However, my first reaction to
 the slot idea is that forcing users to add the content-slot attribute on
 children significantly impairs the DOM API surface area of custom elements.
 
  For the single-level distribution case, how is this different from
 content select=[content-slot=name] except that content select can
 distribute based on features of the children that might already exist, like
 tag names or an attribute?

 At the conceptual level, they're equivalent.  However, we didn't find the
 extra flexibility of using CSS selectors compelling as we mentioned in our
 proposal [1].


 I personally would like to see more power, especially positional
 selectors. Some components would be better off selecting their first child,
 rather than requiring a class.


 What are concrete use cases that require such flexibility?


Require is a strong word :) but the case I recently experienced was a panel
with a header. It always expects one child for the header and the rest for
content. There are several ways to do this, and one would be to select the
first child into one distribution point and the rest into another. Another
way is to use attributes, classes or a specific set of tag names. The key
for me here is that you give the custom element author a choice on how to
shape their API.




 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


 Point 4 is interesting, because unless I'm missing something (which could
 be!) it's incorrect. You can create selectors with :not() that exclude the
 content selectors that come after in document order. I would rewrite the
 example as:

 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template

 Our point wasn't so much that it's not achievable.  With enough hackeries
 and techniques, we can.  The problem is the developer ergonomics of
 content element with select attribute with common real world use cases.
 For example, the above code is a lot more verbose and less intuitive than

 template
   content slot=header/content
   content/content
   content slot=footer/content
 /template

 This is true, but it's a trade off for custom element *authoring* brevity
vs custom element *use* brevity (and authoring expressiveness). I'd
personally rather optimize for custom element user ergonomics, and give
custom element authors the power to make their elements easy and convenient.

Continuing this example I would actually make the selectors more complex
because we have these nice semantic elements in html5:

template
  content select=header, .header/content
  content select=:not(footer, .footer)/content
  content select=footer, .footer/content
/template

 Which is more work for the CE author, but allows this for the user:

my-element
  headerTitle/header
  p.../p
  p.../p
  footer.../footer
/my-element


Cheers,
  Justin


- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

I do want the ability to redirect distributed nodes into a holes in the
base template, so that part is welcome to me. However, my first reaction to
the slot idea is that forcing users to add the content-slot attribute on
children significantly impairs the DOM API surface area of custom elements.

For the single-level distribution case, how is this different from content
select=[content-slot=name] except that content select can distribute
based on features of the children that might already exist, like tag names
or an attribute?

Cheers,
  Justin


On Tue, Apr 21, 2015 at 9:57 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote:

 Hi Ryosuke,

 I want to start by thanking you, Ted, and Jan for taking the time to make
 this proposal.

 I read through the proposal, and had a quick question about how
 redistribution should work with this slot concept.
 I created a quick date-range-combo-box example that would take two date
 inputs (start date and end date) and distribute them through the example
 date-combo-box, but I found myself stuck.
 I can't name the two date inputs with the same slot or they will end up in
 only one of the date-combo-box content elements, but date-combo-box
 only takes inputs with slot inputElement.

 How should this work?

 I drafted a quick gist to illustrate this:
 https://gist.github.com/azakus/676590eb4d5b07b94428


 !-- instance --
 date-range-combo-box
   input type=date content-slot=start!-- (1) --
   input type=date content-slot=end!-- (2) --
 /date-range-combo-box

 !— implementation of date-range-combo-box --
 template
   shadow
 date-combo-box!-- (3) --
!--
How can input[content-slot=start] end up in the content 
 slot=inputElement
in the date-combo-box ?
--
   content slot=start/content
 /date-combo-box
 date-combo-box!-- (4) --
   content slot=end/content
 /date-combo-box
   /shadow
 /template


 Am I right in assuming that you want to re-distribute (1) into (3)'s and
 (2) into (4)'s inputElements?  If so, I'd imagine one possible syntax is as
 follows:

 template
   shadow
 date-combo-box!-- (3) --
   content slot=start content-slot=inputElement/content
 /date-combo-box
 date-combo-box!-- (4) --
   content slot=end content-slot=inputElement/content
 /date-combo-box
   /shadow
 /template


 Here, the content elements are both creating slots and fulfilling slots.

 - R. Niwa

 On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com wrote:

 Hi all,

 Following WebApps discussion last year [1] and earlier this year [2]
 about template transclusions and inheritance in shadow DOM, Jan Miksovsky
 at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
 a meeting where we came up with changes to the way shadow DOM distributes
 nodes to better fit real world use cases.

 After studying various real world use of web component APIs as well as
 exiting GUI frameworks, we noticed that selector based node distribution as
 currently spec'ed doesn't address common use cases and the extra
 flexibility CSS selectors offers isn't needed in practice.  Instead, we
 propose named insertion slots that could be filled with the contents in
 the original DOM as well as contents in subclasses.  Because the proposal
 uses the same slot filling mechanism for content distributions and
 inheritance transclusions, it eliminates the need for multiple shadow
 roots.

 Please take a look at our proposal at
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

 [1]
 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
 [2]
 https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html

Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Justin Fagnani]

On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  From: Justin Fagnani [mailto:justinfagn...@google.com]
  Elements expose this “shadow node list” via APIs that are very similar
 to
  existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(),
  removeShadowChild(), replaceShadowChild(), shadowChildren[],
 shadowChildNodes[].
 
 This part seems like a big step back to me. Shadow roots being actual
 nodes means
 that existing code and knowledge work against them.

 existing code and knowledge work against them -- I'm not sure you
 understood correctly.


No, I think I understood :)

ShadorRoot extends DocumentFragment, and thus Node and has all the API yo
would expect like querySelector(), qsA(), childNodes(), textContent,
appendChild(), cloneNode(), insertBefore(), etc... You can pass a
ShadowRoot to any API expecting a node. For instance, deep traversal though
shadow trees only requires updating normal traversal to crawl into shadows,
it doesn't require teaching it a multitude of shadow*() methods.


 Nodes in the shadow child list wouldn't show up in the childNodes list,
 nor in any of the
 node traversal APIs (e.g., not visible to qSA, nextSibling,
 previousSibling, children, childNodes,
 ect.

 Trivially speaking, if you wanted to hide two divs that implement a stack
 panel and have some
 element render it, you'd just do:
 element.appendShadowChild(document.createElement('div'))
 element.appendShadowChild(document.createElement('div'))

 Those divs would not be discoverable by any traditional DOM APIs (they
 would now be on the
 shadow side), and the only way to see/use them would be to use the new
 element.shadowChildren
 collection.


As in the current API where the only way to see shadow children is by
accessing a shadow root. Your examples become:
element.shadowRoot.appendChild(document.createElement('div'))
element.shadowRoot.appendChild(document.createElement('div'))

Or things like: function writeDivSoup(container){...}, which will work as
writeDivSoup(element.shadowRoot)


 But perhaps I'm misunderstanding your point.

 The API surface that you'd have to duplicate with shadow*() methods would
 be quite large.

 That's true. Actually, I think the list above is probably about it.


querySelector(), find() and friends are important. Plus, speaking of find()
what about additions to Node and DocumentFragment in the future? Do you
keep just adding things like queryShadowSelector() and shadowFind()?

Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Justin Fagnani]

On Thu, Mar 26, 2015 at 10:53 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  Hi folks,



 Today’s ShadowDOM model is designed around only adding shadow roots to
 element in the ‘light side’. I assume this is intentional, but was hoping
 someone could describe why this design was chosen? Or said another way, if
 there was an imperative API to _*remove*_ a shadow DOM, would that
 symmetry be bad?



 In full transparency, I’m thinking about potential solutions for a
 simplified shadow dom, and it occurs to me that it can’t get much simpler
 than the following:

 ·Elements only [ever] have one “shadow side” which is essentially
 a secondary child node list. Whenever anything’s in this list the Element
 renders that content instead of its “light” children. (Or maybe there’s a
 switch to tell the element which side to render: light or dark?)

 ·Elements expose this “shadow node list” via APIs that are very
 similar to existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(), removeShadowChild(), replaceShadowChild(),
 shadowChildren[], shadowChildNodes[].

This part seems like a big step back to me. Shadow roots being actual nodes
means that existing code and knowledge work against them. The API surface
that you'd have to duplicate with shadow*() methods would be quite large.

 ·No special Event swizzling, no security boundary, no alternate
 script engine, no intermediate shadow root object,  etc. This minimalist
 approach only provides node ‘hiding’ and potentially an alternate rendering
 path.

 ·Another feature could then provide the stronger “component”
 boundary, specifically the javascript global scope isolation. This
 delineation may more closely match the division we are seeing between the
 “React-like” scenarios and more robust component-kitchen-style custom
 element deployments.

Range.getClientRanges()?

[Justin Fagnani]

When using Ranges to try to navigate content, I'm finding that it would be
useful to be able to decompose a Range in sub-Ranges that correspond to the
rects returned from getClientRects(). In particular, this would make it
easier to find line-breaks.

Thoughts?

Cheers,
  Justin