W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Proposal for changes to manage Shadow DOM content distribution

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 22 Apr 2015 15:54:39 -0700
Message-ID: <CAAWBYDApLy7+C=mBP_bBWFB=6A7j07EOxvpepid9KZui8S-N4w@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Domenic Denicola <d@domenic.me>, Brian Kardell <bkardell@gmail.com>, "Edward O&amp,#39 Connor" <eoconnor@apple.com>, Jan Miksovsky <jan@component.kitchen>, WebApps WG <public-webapps@w3.org>
On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa <rniwa@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. <jackalmage@gmail.com> wrote:
>> On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa <rniwa@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?

Received on Wednesday, 22 April 2015 22:55:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC