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

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 

[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

Reply via email to