On 04/22/2015 03:54 PM, Tab Atkins Jr. 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.

FYI, putting attribute into the (attribute) insertion point is something 
XBL[1|2] support.

xbl:text isn't used too often, but used  anyhow,
and xbl:inherits is rather common
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).


Reply via email to