Ugh, hit send too fast. In the university site example below, the instance should have been written:
<physics-department-page> <span content-slot=“header">Faculty</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> > <header>Faculty</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. 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 >
