Re: [components] Apple's consolidated feedback on Web Components

[Maciej Stachowiak]

> On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak  wrote:
> 
> 
> Hi everyone,
> 
> In preparation for Fridays’ face-to-face, a number of us at Apple (including 
> me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor

I forgot to mention that Gavin Barraclough also contributed to this discussion. 
We also incorporated past feedback from others on the team.

 - Maciej

[components] Apple's consolidated feedback on Web Components

[Maciej Stachowiak]

Hi everyone,

In preparation for Fridays’ face-to-face, a number of us at Apple (including 
me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor) got together to collect our 
thoughts and feedback about the current state of Web Components.

Before going into the changes we propose, we want to reiterate that we think 
the concept of Web Components is great, and we even like many of the specifics. 
We’re considering significant implementation effort, but we have some concerns. 
We think there is a set of targeted changes that would help web developers, and 
allow us to address a broader set of use cases.

With that in mind, here are our key points of feedback, by spec.

I.  Shadow DOM 

A. Closed vs. Open.
1. Add a closed/open flag to createShadowRoot(). The Shadow DOM 
spec now has the notion of an encapsulation flag for closed mode. Yay! 
Unfortunately, there’s no way yet for a Web developer to pass this flag in. 
Open vs. closed has been much discussed, and while the default is contentious, 
we felt there was a rough consensus to at least expose both modes. We think 
this is critical for v1. >
2. The behavior of closed mode should be actually defined. We 
hope this does not need much justification. We think this is critical for v1. 
>
3. We think closed mode should be the default. Alternately, we 
would be ok with a mandatory argument so developers must always explicitly 
choose open or closed. This has been much discussed, so we won’t give further 
rationale here, and can wait for the meeting Friday to debate. 
>

B. Multiple Generations of Shadow DOM
1. We think this should be removed. Discussion can wait for 
debate of "contentious bits", id=28446>
2. We think that the Apple / Component Kitchen "named slot" 
proposal does a better job of addressing the main use cases for this. We think 
it is a superior replacement. 
>
  > 
>

C. Imperative Distribution API
1. We think the imperative distribution API is still worth 
doing. There has been positive feedback from web developers on the concept and 
there isn’t an obvious reason against it. 
>

D. Event Retargeting
1. We agree with making it optional (opt-in or opt-out). We 
don’t feel that strongly, but many web developers have asked for this. The 
default should likely match the default for open vs. closed (no retargeting by 
default if open by default).  
>

E. Renaming
1. If any strongly incompatible changes are made, we suggest 
renaming createShadowRoot. This is to avoid compat problems with content 
written for Chrome’s shipping implementation.


II.  Custom Elements 

A. Insertion/Removal Callbacks
1. We think the current attached/detached callbacks should be 
removed. They don’t match core DOM concepts and insert/remove is a more natural 
bracket. >
2. We think inserted/removed callbacks should be added, for 
alignment with DOM. > 

B. ES6 classes
1. Custom elements should support ES6 classes in a natural way 
- allowing use of the ES6 class constructor instead of a separate callback. We 
believe there is rough consensus on this point. 
>

C. Upgrade
1. We don’t think upgrading should be supported. The tradeoffs 
of different options have been much-discussed. 
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 3:48 PM, Justin Fagnani  wrote:
> 
> On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa  > wrote:
> 
>> On Apr 22, 2015, at 10:16 AM, Justin Fagnani > > wrote:
>> 
>> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa > > wrote:
>> 
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani > > > 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 
>> >  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.

I don't think letting authors of each component choose how to select nodes of 
distributions will increase the inconsistencies between components written by 
different authors and deteriorate the ergonomics of component users.

>> 
>>   
>>   
>>   
>> 
> 
> 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
> 
>> 
>>   
>>   
>>   
>> 
> 
> 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:
>> 
>>   
>>   
>>   
>> 
> 
>  Which is more work for the CE author, but allows this for the user:
> 
>> 
>>   Title
>>   ...
>>   ...
>>   ...
>> 
That's a fair point but it is a feature that the user of components needs to 
explicitly opt-in to use slot-content.  That explicit contract ensures the API 
surface to be limited.  Suppose in the version 1 of this component, it only 
supported "header".  If the version 2 of this component subsequently added the 
support for "footer", it's unclear whether every existing use of "footer" 
element is appropriate for node distribution.  This poses a serious challenge 
for adding new features to your components.  In addition, such an explicit 
contract is a must-have requirement for cross-origin components we (Apple's 
WebKit team) have been advocating for years now.

- 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 
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):
>
> 
>   
> Physics Department
> 
>   
> 
>
> If an instance of this page then says
>
> 
>   Faculty
> 
>

I know you mistakenly used a  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  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:
>
> 
>   
> 
>   Physics Department
>   
> 
>   
> 
>
> 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.  wrote:
>
> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
>
> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>
> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>
>
> 
>
>
> 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.  It's *certainly* irrelevant
> as a response to the text you quoted.
>
> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>
> I don't think defining a slot based on an attribute value is something we'd
> like to sup

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>>> 
>>> 
>> 
>> 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.  It's *certainly* irrelevant
> as a response to the text you quoted.

I find it decidedly relevant given I'm pointing out that attribute-specified 
slots Domenic mentioned isn't what you described.  Since the only venue in 
which attribute-specified slots came up are [1], [2], and [3].  We're 
DEFINITELY NOT interested in filling slots based on values of arbitrary 
attributes.

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

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

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


- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Jan Miksovsky]

Ugh, hit send too fast. In the university site example below, the instance 
should have been written:


  Faculty


–Jan

> On Apr 22, 2015, at 4:40 PM, Jan Miksovsky  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. 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):
> 
> 
>   
> Physics Department
> 
>   
> 
> 
> If an instance of this page then says
> 
> 
>   Faculty
> 
> 
> 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  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:
> 
> 
>   
> 
>   Physics Department
>   
> 
>   
> 
> 
> 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. > > wrote:
>> 
>> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa > > wrote:
>>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. >> > wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa >>> > wrote:
> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  > 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.
 
 
>>> 
>>> 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.  It's *certainly* irrelevant
>> as a response to the text you quoted.
>> 
>>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. >> > wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa >>> > wrote:
> I don't think defining a slot based on an attribute value is something 
> we'd
> like to support.
 
 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the "content-slot" attribute.
>>> 
>>> Distributing elements based on the value of a single well scoped attribute
>>> versus of an arbitrary attribute is A HUGE difference.
>> 
>> Interesting.  Why?  And why do you think the difference is significant
>> enough to justify such a limitation?  You seem to be okay with
>> distributing elements based on the *name* of an arbitrary attribute;
>> can you justify why th

[Bug 28547] New: Remove the support for inherting from builtin subclasses of HTMLElement and SVGElement

[bugzilla]

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

Bug ID: 28547
   Summary: Remove the support for inherting from builtin
subclasses of HTMLElement and SVGElement
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

See https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements

Subclassing existing elements is hard as implementation-wise identity is both
object-based and name / namespace based. Therefore subclassing an existing
element (currently) requires that the name / namespace does not change. See
also DOM: element constructors.

A hack was invented to make this work: . That hack is
not well liked leaving us two options:

We leave this for now and work on this in parallel while stabilizing a smaller
subset of custom elements.
We block on this and delay even more.
(Assuming that not all implementers are suddenly going to be okay with this
hack.)

However, without this hack accessibility for trivial components is harder as
more things have to be done by hand.

Another use case had emerged for the "is" hack: piggy-backing on parser
behaviors. For example, extending  for data binding or as a way to
specify shadow trees in HTML.

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

[Bug 28546] New: document.registerElement should take a template as an argument

[bugzilla]

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

Bug ID: 28546
   Summary: document.registerElement should take a template as an
argument
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0794.html

Given that many important/natural use cases of custom elements involve shadow
DOM, can we add a flag to auto-create shadow DOM for custom elements?

In particular, can we add "template" as the third argument to document.register
so that when a custom element is "instantiated", the specified template is
automatically closed and inserted into a shadow DOM of the custom element.

e.g. using ES6 class syntax:


Hi!


class MyButton extends HTMLElement {
...
}
document.registerElement('my-button', MyButton, myButtonTemplate);


Given that the shadow DOM specification is relatively stable if we constrain
ourselves to only custom elements (i.e. ignoring all builtin elements), adding
this mechanism will allow us to move the custom elements and shadow DOM
specifications forward without risking to expose the general API for attaching
shadow DOM to the Web.

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

[Bug 28545] New: Declarative syntax for custom elements

[bugzilla]

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

Bug ID: 28545
   Summary: Declarative syntax for custom elements
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

See https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html

At some point (perhaps post-V1), there should be a convenient declarative
syntax that combines script and a template to define a custom element.
JavaScript frameworks on top of web components provide something like this.
Perhaps with field experience we can make a standardized common syntax.

Specifically, such a syntax needs to be compatible with an isolated
cross-origin component.

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

[Bug 28544] New: Custom elements should not upgrade elements by setting prototype

[bugzilla]

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

Bug ID: 28544
   Summary: Custom elements should not upgrade elements by setting
prototype
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Discussed here:
https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0158.html
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0083.html

We shouldn't support upgrading of existing elements since it leaves the
corresponding DOM objects with a wrong identity.

This is also not a normal programming model. Even with ES6 modules, we don't
create a dummy modules while modules are loading and later automatically
replace them under the foot.

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

Re: Proposal for changes to manage Shadow DOM content distribution

[Jan Miksovsky]

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


  
Physics Department

  


If an instance of this page then says


  Faculty


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


  

  Physics Department
  

  


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.  wrote:
> 
> On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>>> 
>>> 
>> 
>> 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.  It's *certainly* irrelevant
> as a response to the text you quoted.
> 
>> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
 I don't think defining a slot based on an attribute value is something we'd
 like to support.
>>> 
>>> That is *literally* what your proposal already is, except limited to
>>> only paying attention to the value of the "content-slot" attribute.
>> 
>> Distributing elements based on the value of a single well scoped attribute
>> versus of an arbitrary attribute is A HUGE difference.
> 
> Interesting.  Why?  And why do you think the difference is significant
> enough to justify such a limitation?  You seem to be okay with
> distributing elements based on the *name* of an arbitrary attribute;
> can you justify why that is so much better than using the value that
> you're willing to allow it, but not the other?
> 
> ~TJ

[Bug 28543] New: Custom elements should call user defined constructor synchronously

[bugzilla]

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

Bug ID: 28543
   Summary: Custom elements should call user defined constructor
synchronously
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0731.html

We should make the custom element's constructor be called synchrnously instead
of at the end of the micro-task since that's not consistent with builtin
elements and exposes "unconstructed" elements in some cases; e.g. immediately
after cloning or setting innerHTML.

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

[Bug 28542] New: [Shadow] Replace node distribution mechanism by the named slot proposal

[bugzilla]

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

Bug ID: 28542
   Summary: [Shadow] Replace node distribution mechanism by the
named slot proposal
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Proposed here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0184.html

https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution

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

[Bug 28541] New: Custom elements should use ES6 class constructor

[bugzilla]

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

Bug ID: 28541
   Summary: Custom elements should use ES6 class constructor
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

As discussed, docuemnt.regsiterElement currently replaces the constructor so
that it rips out any static methods defined using the ES6 class syntax.  We
shouldn't do that.

We should preserve the original constructor/class object defiend by the author.

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

RE: Proposal for changes to manage Shadow DOM content distribution

[Travis Leithead]

I like that the light-side DOM elements must opt-in to being redistributed. 
While appearing at first like a hindrance, it does ensure that elements can't 
be arbitrarily re-distributed without their consent. If you imagine allowing 
redistribution into a cross-origin shadow dom, then it becomes somewhat more 
important to be a bit more cautious (or at least declarative). I like the 
cooperative symmetry.

I also like the idea of being able to drop the multiple shadow trees 
requirement. Can this still be accomplished if select="" is not used? I'm still 
grokking the details...

From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Wednesday, April 22, 2015 2:37 PM
To: Justin Fagnani
Cc: Daniel Freedman; WebApps WG; Edward O'Connor; Jan Miksovsky
Subject: Re: Proposal for changes to manage Shadow DOM content distribution


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



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

> On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
> mailto: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  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?

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




  

  

  


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




  

  

  


- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Olli Pettay]

On 04/22/2015 03:54 PM, Tab Atkins Jr. wrote:

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:

On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:

On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.





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.  It's *certainly* irrelevant
as a response to the text you quoted.



FYI, putting attribute into the (attribute) insertion point is something 
XBL[1|2] support.
https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content#Attribute_Forwarding
http://www-archive.mozilla.org/projects/xbl/xbl2.html#forwarding

xbl:text isn't used too often, but used  anyhow,
http://mxr.mozilla.org/mozilla-central/search?string=xbl%3Atext
and xbl:inherits is rather common
http://mxr.mozilla.org/mozilla-central/search?string=xbl%3Ainherits&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central
in Firefox' UI, which after all is mostly created using various components or 
bindings (doesn't matter whether the underlying language is XUL or HTML).



-Olli

Re: Proposal for changes to manage Shadow DOM content distribution

[Hayato Ito]

For the comparison, I've re-written the examples by using " as
function" syntax.

https://gist.github.com/hayatoito/f2df8e10cb8cc551f80c

Can I assume that both have the same power, fundamentally?
(Please ignore that power of the CSS selector here ;)

If both approaches have the (almost) equivalent power, I guess the
technical difficulties to implement these features don't differ so much.
If we could implement the new proposal, I think we could implement
" as function" too.



On Wed, Apr 22, 2015 at 3:56 PM Dimitri Glazkov  wrote:

> FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
> proposal.
>
> It reduces the implementation complexity: all of the selector-checking
> logic in
> http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
> is replaced with (what effectively is) a map lookup.
>
> While some loss of flexibility is a cost, I think it's worth considering
> this trade-off, especially if it is a sticking point for implementers who
> are looking to reduce the overall cost of Shadow DOM implementation.
>
> In fact, if we reach cross-vendor agreement and decide to go with the
> slot-based approach, we probably should avoid adding extra sugar around
> element names and attribute values as slot indicators, and instead double
> down on developing a good imperative API that overcomes the loss of
> flexibility.
>
> :DG<
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Dimitri Glazkov]

FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
proposal.

It reduces the implementation complexity: all of the selector-checking
logic in
http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
is replaced with (what effectively is) a map lookup.

While some loss of flexibility is a cost, I think it's worth considering
this trade-off, especially if it is a sticking point for implementers who
are looking to reduce the overall cost of Shadow DOM implementation.

In fact, if we reach cross-vendor agreement and decide to go with the
slot-based approach, we probably should avoid adding extra sugar around
element names and attribute values as slot indicators, and instead double
down on developing a good imperative API that overcomes the loss of
flexibility.

:DG<

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa  wrote:
> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
>>
>> 
>
> 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.  It's *certainly* irrelevant
as a response to the text you quoted.

> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>>> I don't think defining a slot based on an attribute value is something we'd
>>> like to support.
>>
>> That is *literally* what your proposal already is, except limited to
>> only paying attention to the value of the "content-slot" attribute.
>
> Distributing elements based on the value of a single well scoped attribute
> versus of an arbitrary attribute is A HUGE difference.

Interesting.  Why?  And why do you think the difference is significant
enough to justify such a limitation?  You seem to be okay with
distributing elements based on the *name* of an arbitrary attribute;
can you justify why that is so much better than using the value that
you're willing to allow it, but not the other?

~TJ

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa  wrote:

>
> On Apr 22, 2015, at 10:16 AM, Justin Fagnani 
> wrote:
>
>
>
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:
>
>>
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
>> 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
>>  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:
>
> 
>   
>   
>   
> 
>
> 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
>
> 
>   
>   
>   
> 
>
> 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:


  
  
  


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


  Title
  ...
  ...
  ...



Cheers,
  Justin


- R. Niwa
>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.
> 
> 

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.

> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr.  wrote:
> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>> I don't think defining a slot based on an attribute value is something we'd 
>> like to support.
> 
> That is *literally* what your proposal already is, except limited to
> only paying attention to the value of the "content-slot" attribute.


Distributing elements based on the value of a single well scoped attribute 
versus of an arbitrary attribute is A HUGE difference.

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

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

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

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa  wrote:
>> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.



> I don't think defining a slot based on an attribute value is something we'd 
> like to support.

That is *literally* what your proposal already is, except limited to
only paying attention to the value of the "content-slot" attribute.

~TJ

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 10:16 AM, Justin Fagnani  wrote:
> 
> 
> 
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  > wrote:
> 
> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani  > > 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  > 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?

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

> 
>   
>   
>   
> 
- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

I don't think defining a slot based on an attribute value is something we'd 
like to support.

> On Apr 22, 2015, at 10:21 AM, Justin Fagnani  wrote:
> 
> 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  > wrote:
> 
> 
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  > wrote:
> 
> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani  > > 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  > 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:
> 
> 
>   
>   
>   
> 
> Cheers,
>   Justin
>  
> 
> 
> - R. Niwa
> 
> 
> 

Re: Proposal for changes to manage Shadow DOM content distribution

[Ryosuke Niwa]

> On Apr 22, 2015, at 8:52 AM, Domenic Denicola  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.

- R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Erik Bryn]

FWIW, we're working to implement what we call named blocks in Ember.js and
believe this proposal aligns very closely to what our users have been
asking us to build for them.

- Erik

On Wednesday, April 22, 2015, Tab Atkins Jr.  wrote:

> This is literally reinventing Selectors at this point.  The solution
> to "we don't think it's worth implementing *all* of Selectors" is to
> define a subset of supported Selectors, not to define a brand new
> mechanism that's equivalent to selectors but with a new syntax.
>
> On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani
> > wrote:
> > 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  > 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
> >>> >  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:
> >>
> >> 
> >>   
> >>   
> >>   
> >> 
> >>
> >> Cheers,
> >>   Justin
> >>
> >>>
> >>>
> >>>
> >>> - R. Niwa
> >>>
> >>
> >
>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

This is literally reinventing Selectors at this point.  The solution
to "we don't think it's worth implementing *all* of Selectors" is to
define a subset of supported Selectors, not to define a brand new
mechanism that's equivalent to selectors but with a new syntax.

On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani
 wrote:
> 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 
> wrote:
>>
>>
>>
>> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:
>>>
>>>
>>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
>>> > 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
>>> >  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:
>>
>> 
>>   
>>   
>>   
>> 
>>
>> Cheers,
>>   Justin
>>
>>>
>>>
>>>
>>> - R. Niwa
>>>
>>
>

[Bug 28539] New: [Shadow]: Typos Spefifies and Speficies

[bugzilla]

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

Bug ID: 28539
   Summary: [Shadow]: Typos Spefifies and Speficies
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: phil...@opera.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

In
http://w3c.github.io/webcomponents/spec/shadow/#dictionary-shadowrootinit-members

Should be Specifies

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

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

>
>
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:
>
>>
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
>> 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
>>  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:
>
> 
>   
>   
>   
> 
>
> Cheers,
>   Justin
>
>
>>
>>
>> - R. Niwa
>>
>>
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Justin Fagnani]

On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa  wrote:

>
> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
> 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
>  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:


  
  
  


Cheers,
  Justin


>
>
> - R. Niwa
>
>

RE: Proposal for changes to manage Shadow DOM content distribution

[Domenic Denicola]

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?

Proposed W3C CG - The Extended Web

[Anders Rundgren]

https://www.w3.org/community/blog/2015/04/19/proposed-group-the-extended-web-community-group/

Since the CG description is free from "political" stuff, I included it here :-)

Most of the things exposed in the system-level (native) APIs of Android, iOS, 
Windows, etc. could indeed be provided in web-browsers.  However, the cost and 
time that this would take as well as the ever-increasing speed of native OS and 
related hardware developments make this unrealistic except for a rather modest 
set of well-scoped APIs.  It has also proven to be considerably harder dealing 
with untrusted web-code than originally thought.

"The Extended Web CG" is about *COMBINING the power of the two worlds* which is a bit 
nicer than the current "Platform War" (which like regular wars doesn't really make 
anybody happy).

To achieve that, The Extended Web CG is dedicated developing a *secure link* 
between the Open [untrusted] Web and the Native [trusted] layer, independently 
of how the latter is expressed.  The current idea is building on an *enhanced 
version* of Chrome's Native Messaging:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/
http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html

The single most important feature of Native Messaging is that it offers *a way 
for third-parties to innovate* in areas ranging from Secure Web-payments to 
Streaming Media-services as well as one-of-a-kind vendor-specific solutions 
like Remote Diagnostics for PCs.

FWIW, it seems that the core concept (talking securely with a web-page), could, and with 
relative ease (fingers crossed...), also include mobile devices connected to a web-page 
through an NFC/Bluetooth(BLE) "combo" link:
https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf
A defensive publication has recently been submitted for this proposal.

Anders Rundgren
convener/"firestarter"

https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf

Re: Proposal for changes to manage Shadow DOM content distribution

[Brian Kardell]

On Apr 21, 2015 10:29 PM, "Ryosuke Niwa"  wrote:
>
>
>> On Apr 21, 2015, at 10:17 PM, Brian Kardell  wrote:
>>
>> On Apr 21, 2015 8:22 PM, "Ryosuke Niwa"  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
>> >
>>
>> I just wanted to note that a month or two I tried to assume nothing and
come up with a bare essentials concept which involved named slots.  Is
there a proposed a way to project from an attribute value into content or
from attribute to attribute..?
>>
>> In other words, if I had . Can I map blah into a
slot or identify an attribute value in my template *as* a slot?
>
> Not at the moment but I could imagine that such a feature could be easily
added. e.g.
>
> 
>
> 
> 
>   
> 
>
> - R. Niwa
>

For the record, I'd love to see that discussed as part of a real proposal
because I think it's pretty useful - you can see lots of things essentially
trying to do custom elements in the wild with a similar need and it
honestly seems easier than element based slots technically speaking so it
would be a shame to lack it.