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   , 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: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).