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

[Jan Miksovsky]

Thanks to everyone who participated in the call. (Special thanks to those 
calling from Tokyo!)

Minutes for the meeting are at 
https://www.w3.org/2016/04/05-webapps-minutes.html 
.

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

[Jan Miksovsky]

I’m unfamiliar with WebEx. If Chaals or someone wants to make a strong push to 
use that, please set up the call and send out instructions for joining.

Baring that, I propose the default meeting location is on Google Hangouts: 
https://hangouts.google.com/call/rwiluf6hlbhkzf4566hq4biedye 
. If we go ahead 
with Hangouts and Chaals can’t join, I’ll volunteer to act as scribe, at least 
for the beginning.

I’m on the IRC channel gave (irc://irc.w3.org/#public-webapps 
) if anyone wants to discuss pre-call 
logistics.

As a reminder: the proposed agenda for the meeting is to go through the “needs 
consensus” items posted at 
https://github.com/w3c/webcomponents/issues?q=is%3Aissue+is%3Aopen+label%3A%22needs+consensus%22
 
.
 It sounds like it would be good to resolve pending Shadow DOM issues before 
tackling Custom Elements issues.

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

[Jan Miksovsky]

I never use WebEx, and had proposed Google Hangouts only because I thought it 
was ubiquitous (and free).

I have no idea how to settle this question. If everyone else is happy using 
WebEx, and someone else can set up the video call, I certainly don’t have a 
problem with that. (My only issue would be if the meeting was restricted to 
voice only.)

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

[Jan Miksovsky]

It looks like the best date/time for everyone is this coming Tuesday, April 5, 
10:00 am – 12:00 pm PDT.

Thanks for everyone who participated in the poll. I was not able to find a time 
when everyone could join, but it appears that we have representation from 
Apple, Google, and Mozilla, so I think we’re in good shape.

The Google Hangout for the event will be 
https://hangouts.google.com/call/rwiluf6hlbhkzf4566hq4biedye.

Chaals: Thanks for the reminder about minutes. I can help out with some of the 
scribe duties; if you’re able to make the call, you and I could trade off that 
role. I can’t remember the IRC channel we used for past F2F meetings; please 
share. If memory serves, there are also some conventions for flagging action 
items, etc. — can you point me at some summary of those? (Alternatively: With 
Google Hangouts, if it’s better to use Hangouts’ own chat system, we could use 
that instead.)

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

[Jan Miksovsky]

It sounds like there’s general interest in making this happen, so I went ahead 
and set up a Doodle poll for this: http://doodle.com/poll/z7qvrafbxw4zyit9.

(Chaals: I just noticed you offered to do that as well, but since I’d already 
set it up, I thought I’d sent it out. Hope that’s okay.)

If everyone could indicate their availability by, say, this Friday, 4/1, we can 
see what time works best for everyone.

–Jan

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:

physics-department-page
  span content-slot=“headerFaculty/span
/physics-department-page

–Jan

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

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

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.  It's *certainly* irrelevant
 as a response to the text you quoted.
 
 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:
 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: Base Template (Was Re: Minimum viable custom elements)

[Jan Miksovsky]

Dimitri: Okay, I can follow up with Ryosuke. I’m happy to share our thoughts 
and needs for subclassing components.

Anne/Steve: I’d originally indicated that this technique couldn't be applied to 
extending native HTML elements. Since the two of your seemed interested in 
that, I spent some time tinkering with the idea, and it turns out that this 
technique can be made to work for that situation. I’ve posted a quick demo 
(http://janmiksovsky.github.io/base-template/extendButton.html 
http://janmiksovsky.github.io/base-template/extendButton.html) showing 
subclassing of a standard HTML button element. This works best under native 
Shadow DOM. Under polyfilled Shadow DOM, base class styles can’t (yet?) be 
inherited.

Anyway, I mention this in case it opens up some ideas. Thanks for the 
inspiration!

Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

[Jan Miksovsky]

I just saw Dimitri's reference to my “Filling slots in shadow” blog posts from 
a while back, so I thought I’d follow up with the experiences I’ve had I wrote 
it.

First, I remain convinced that it will be very helpful for Shadow DOM to 
provide a feature like this that allows for parent and child classes to 
cooperatively contribute elements to the same component. This is a key feature 
that enables well-factored user interface components. I started a company 
earlier this year that is building a site entirely on web components, and we’ve 
already hit the limitations of what’s possible without this feature.

Second, my colleagues and I found the pre-existing proposal to let authors 
reproject content into shadow to be an elegant solution to this problem. 
During the brief window when this feature was available in Chrome Canary, we 
quickly made use of it. It felt like a very natural extension of the Shadow DOM 
tree composition concepts we had already learned. That is, in our experience, 
the conceptual load introduced by this feature was low. To the extent the 
developer experience weighs in any decision here, we were completely fine with 
the approach of placing content insertion points inside shadow elements.

Third, we feel a modest amount of impatience to see this feature implemented in 
Chrome again, and for other browsers to adopt this feature as it existed in 
Chrome. It was meeting our needs, and seeing it (even temporarily) removed felt 
like a step backwards. We’re concerned that lack of a solution here will 
discourage people from applying subclassing as a means to factor user interface 
behavior into parent/child component class relationships.

Finally, even given all the above, we view it as more important that all the 
mainstream browsers implement the more fundamental aspects of Shadow DOM with 
all due speed. Our company and its customers are entirely dependent upon web 
components that use Shadow DOM, and while we can rely upon the Polymer library 
for cross-browser compatibility, there is a considerable different in 
performance between native and polyfilled Shadow DOM features. We test on a 
variety of browsers and devices, and while we can run on Mobile Safari or IE, 
performance on those platforms is barely acceptable. We would rather see the 
basics of Shadow DOM be native now, and live without defined semantics for 
parent/child contributions to shadow trees, than wait indefinitely for that 
feature before seeing native implementations of the basics.

I feel like something of an industry outsider in discussions related to web 
standards, and appreciate the range of scenarios those working on standards 
must consider as they debate proposals for changes. I trust the smart folks at 
Apple, Google, and elsewhere to make the right decision here. All I can offer 
here is my company's own practical experience in this domain. For our part, we 
would be very happy to see a solution adopted in the standard that follows the 
general lines of allowing reprojection of content into shadow elements, but 
in the meantime are primarily concerned with seeing native Shadow DOM 
implementations across all browsers.

–Jan