Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Wed, Aug 22, 2012 at 6:32 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell <bkardell@gmail.com> wrote:
>>> On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> Correct.  If we applied CAS on attribute changes, we'd have... problems.
>>>
>>> Because you could do something like:
>>>
>>> .foo[x=123]{ x:  234; }
>>> .foo[x=234]{ x:  123; }
>>>
>>> ?
>>
>> Precisely.  Any way around this problem pulls in a lot more complexity
>> that I don't think is worthwhile.
>
> I suspect it's actually pretty simple to fix. Ban attribute selectors, and forbid setting the class or id attributes using this language.

It's not that simple.  ^_^  You can set the 'checked' attribute, which
activates the :checked pseudo.  You can do various things with form
inputs (setting 'required' or 'pattern', setting 'value', setting
'disabled' or 'readonly'), which activate the various input
pseudoclasses.  Looking to the future, the reference and column
combinators also respond to attributes in various ways.


> I have mixed feelings about this proposal overall, but I think it's a little weird to use CSS property syntax instead of markup-like attribute syntax to set attributes. I think this makes the syntax confusingly similar to CSS even though proposed behavior is quite different. Something like this might make more sense:
>
> img.placeholder {
>     src="/images/1x1.gif"
>     alt=""
> }
>
> In other words, make attribute setting look like attribute syntax.

This is similar to the discussions about monocle-mustache in JS.  I
prefer being able to simple re-use the existing CSS parser, but I'm
not completely wedded to it.  I'd need some strong opinions from more
relevant parties to switch over, though.


> I also think the proposed semi-dynamic behavior of applying only at DOM insertion time but otherwise being static is super confusing.

Opinions can differ.  I think this captures at least 90% of the
use-cases for it, and it's simple to explain, which should help offset
the minor confusion.


> And finally, I'm skeptical whether the convenience here is worth adding a whole new language to the Web Platform technology stack. It is literally just convenience / syntactic sugar. I'm not sure that rises to the high bar needed to add an additional language to the Web Platform.

Yeah, this is the major hurdle for this.  My hope is that, by reusing
the CSS parser and restricting all the expensive parts of CSS
(dynamicness, remembering where a value came from, etc.), I can pull
the bar down low enough for this to make it.

It is just sugar, but it's *useful* sugar, as evidenced by the fact
that people keep trying to push content attributes into CSS.  With
something like this, we can avoid discussions like "can we put aria
things into CSS?" entirely, because they'll already be handled.

~TJ

Received on Monday, 27 August 2012 21:08:07 UTC