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

[Austin William Wright]

On Mon, May 4, 2015 at 8:52 PM, Lea Verou  wrote:

> Sorry for reviving such an old thread (almost 3 years now!) but I recently
> came across a huge use case for CAS: Semantic data! Namely, Microdata and
> RDFa. They’re both applied using attributes, which makes them super tedious
> to add to existing content.
>

I like this idea! You might get additional feedback for this from the SWIG
community on the semantic-web list.

GRDDL is (was?) a very similar, but much more complex, concept that uses
RDF/XML and XSLT (not a very well-liked combination by myself or
generally): 

Another application would be many of the applications of ARIA attributes
(surely I can't be the only one who's thought ARIA shouldn't be embedded in
markup since it's not conveying actual data).

In both cases, they're properties annotating/semantically enhancing data,
where cycles generally shouldn't occur. That is if cycles are a problem at
all. CSS doesn't seem to have any issue when it creates pesudo-elements, I
don't forsee too many issues with pesudo-attributes.

That is, I don't see any reason this would need to modify the DOM; but
could instead expose a "data DOM" that ARIA and RDFa would use; the same
way Web browsers render a "visual DOM" of sorts containing pesudo-elements.

Austin Wright.

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

[Tab Atkins Jr.]

On Fri, Oct 5, 2012 at 4:22 AM, Henri Sivonen  wrote:
> On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr.  wrote:
>> Similarly, some of the a11y folks have recently been talking about
>> applying aria-* attributes via CSS, again, because it's just so much
>> more convenient.
>
> What's the rationale for this radical change of mind? Back when ARIA
> was introduced, the a11y wanted to specifically avoid the introduction
> of reflecting DOM properties for the ARIA attributes in order to force
> authors to use setAttribute() so that JAWS could retrieve the ARIA
> data via COM in ARIA-unaware legacy IE.
>
> If the a11y folks were so serious about being compatible with IE7 a
> few years ago, why isn't there now similar concern that applying ARIA
> by a new mechanism would leave behind IE10 and earlier, which,
> presumably, currently have the same sort of expected enterprise
> lifespan as IE7 had when aria was introduced?

I have no idea.  However, it seems irrelevant for my proposal - as
currently specified, CAS desugars into setAttribute calls.

~TJ

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

[Henri Sivonen]

On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr.  wrote:
> Similarly, some of the a11y folks have recently been talking about
> applying aria-* attributes via CSS, again, because it's just so much
> more convenient.

What's the rationale for this radical change of mind? Back when ARIA
was introduced, the a11y wanted to specifically avoid the introduction
of reflecting DOM properties for the ARIA attributes in order to force
authors to use setAttribute() so that JAWS could retrieve the ARIA
data via COM in ARIA-unaware legacy IE.

If the a11y folks were so serious about being compatible with IE7 a
few years ago, why isn't there now similar concern that applying ARIA
by a new mechanism would leave behind IE10 and earlier, which,
presumably, currently have the same sort of expected enterprise
lifespan as IE7 had when aria was introduced?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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

[Glenn Maynard]

This can be implemented in script using mutation observers (provided the
"parser-inserted elements" question shakes out in the right direction,
which seems a prerequisite for any robust use of that API), right?

-- 
Glenn Maynard

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

[Maciej Stachowiak]

On Aug 27, 2012, at 2:07 PM, Tab Atkins Jr.  wrote:

> 
> 
> 
>> 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 doubt we would be able to actually reuse the CSS parser, at least at the code 
level, at least for WebKit. To give some examples of issues that arise:

- The CSS parser has specific knowledge of all the CSS properties we recognize 
and their value syntax. 
- It has no provision for catchall recognition of all other property names with 
a quoted string value.
- There are some CSS properties that have the same name as meaningful HTML 
attributes.

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

I think your assumption is that it's possible to reuse the CSS parser is 
incorrect, at least for strong values of "reuse".

Regards,
Maciej

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

[Tab Atkins Jr.]

On Wed, Aug 22, 2012 at 6:32 PM, Maciej Stachowiak  wrote:
> On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr.  wrote:
>> On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell  wrote:
>>> On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr.  
>>> 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

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

[Maciej Stachowiak]

On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr.  wrote:

> On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell  wrote:
>> On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr.  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.


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.

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

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.

Regards,
Maciej

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

[Tab Atkins Jr.]

On Wed, Aug 22, 2012 at 9:20 AM, Bronislav Klučka
 wrote:
> On 22.8.2012 1:13, Tab Atkins Jr. wrote:
>> Actually, the two should be identical, because CAS is applied as a
>> mutation observer, rather than synchronously.  As long as those
>> statements appear in the same microtask, they'll have the same
>> behavior regardless of order (CAS will always get to override them).
>
> Which does not correspond to CSS behavior and may be cofusing, any changes
> would require something like
>
> var div = createMyDiv();
> parentNode.appendChild(div);
> setTimeout(function(div) {div.className = 'foo';}, 0, div);
>
> that's weird.

Why do you think that's required?  All it would do is clobber the
class attribute in case CAS had set it to something else.  Setting a
class via CAS doesn't seem like a great idea in the first place.  If
you really do want to, you can just get CAS to either not clobber the
attribute (if I address the "add to the existing value" use-case that
I've outlined on my blog ) or else
just exclude .foo elements from getting their class clobbered with a
":not(.foo)" in the selector.


> How about this: element is created with all attributes marked as clean, any
> settings (input.value = 5; input.setAttribute('value', 5); delete
> input.value; input.removeAttribute('value')) would mark such property as
> dirty, and inserting new element into DOM would trigger task, that would set
> up all properties based on DOM document's CAS except dirty ones. In such
> case, no ambiguity would occure.
>
> Browsers are able to do it for CSS, should be able to do it for CAS

Browsers are able to do it for CSS with a lot of complexity.
Complexity sometimes translates to "powerful and awesome", but always
translates to "slower".  In this case, I don't think the large helping
of additional complexity is worth the minor benefit.

~TJ

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

[Tab Atkins Jr.]

On Wed, Aug 22, 2012 at 9:11 AM, Dimitri Glazkov  wrote:
> Yes, but... One of the problems with the "is" attribute is that it's
> magic: only the parser reacts to it, and changing it does not do
> anything. I was hoping for some special notation that clearly made it
> not an attribute, so that at least the magic is confined to CAS, and
> does not extend to weird attribute behavior.

If it's getting applied by CAS, it does so in a microtask after it was
added to the DOM.  If anything *can* influence the identity of the
element at that point, it might as well be an attribute - making it
special doesn't gain us anything.

(Anyway, could we move this discussion to a separate thread?  It's
more about "how do we trigger custom elements" than about CAS.)

~TJ

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

[Bronislav Klučka]

On 22.8.2012 1:13, Tab Atkins Jr. wrote:

On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard  wrote:

FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say "#myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; }" or "a { rel:
noreferrer; }" would be great.

Having it not apply changes dynamically seems weird, since it looks and
feels like CSS.  It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:

var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = "foo"; // and we override them

var div = createMyDiv();
div.className = "foo"; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten

Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, "document.documentElement.appendChild(parentNode)"
happens before or after.

Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously.  As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).

~TJ

Which does not correspond to CSS behavior and may be cofusing, any 
changes would require something like


var div = createMyDiv();
parentNode.appendChild(div);
setTimeout(function(div) {div.className = 'foo';}, 0, div);
that's weird.

How about this: element is created with all attributes marked as clean, 
any settings (input.value = 5; input.setAttribute('value', 5); delete 
input.value; input.removeAttribute('value')) would mark such property as 
dirty, and inserting new element into DOM would trigger task, that would 
set up all properties based on DOM document's CAS except dirty ones. In 
such case, no ambiguity would occure.


Browsers are able to do it for CSS, should be able to do it for CAS

Brona.




--

s pozdravem
 Bronislav Klučka


http://www.bauglir.com 

http://www.bauglir.com
bronislav.klu...@bauglir.com  

  * webové aplikace
  * software na zakázku

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

[Dimitri Glazkov]

Yes, but... One of the problems with the "is" attribute is that it's
magic: only the parser reacts to it, and changing it does not do
anything. I was hoping for some special notation that clearly made it
not an attribute, so that at least the magic is confined to CAS, and
does not extend to weird attribute behavior.

:DG<

On Wed, Aug 22, 2012 at 12:09 AM, Tab Atkins Jr.  wrote:
> On Tue, Aug 21, 2012 at 5:48 PM, Dimitri Glazkov  wrote:
>> Can we extend this to custom DOM element registration somehow?
>>
>> ul.news>li {
>>  identity: x-news-item;
>> }
>>
>> or maybe even:
>>
>> ul.news>li {
>> identity: url(//example.com/test/news.html#news-item);
>> }
>
> If that's an attribute on the element, sure!
>
> ul.news > li { is: x-news-item; }
>
> ^_^
>
> ~TJ

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 5:48 PM, Dimitri Glazkov  wrote:
> Can we extend this to custom DOM element registration somehow?
>
> ul.news>li {
>  identity: x-news-item;
> }
>
> or maybe even:
>
> ul.news>li {
> identity: url(//example.com/test/news.html#news-item);
> }

If that's an attribute on the element, sure!

ul.news > li { is: x-news-item; }

^_^

~TJ

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

[Dimitri Glazkov]

Can we extend this to custom DOM element registration somehow?

ul.news>li {
 identity: x-news-item;
}

or maybe even:

ul.news>li {
identity: url(//example.com/test/news.html#news-item);
}

:DG<

On Tue, Aug 21, 2012 at 4:13 PM, Tab Atkins Jr.  wrote:
> On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard  wrote:
>> FWIW, while I don't find the idea of attaching event listeners this way too
>> interesting (maybe I could be convinced, but event capturing is already
>> convenient for most of these examples), being able to say "#myform input {
>> autocomplete: off; autocorrect: off; autocapitalize: off; }" or "a { rel:
>> noreferrer; }" would be great.
>>
>> Having it not apply changes dynamically seems weird, since it looks and
>> feels like CSS.  It'd mean these two things--which look intuitively the
>> same, and behave the same with CSS--would be very different when parentNode
>> is in the document:
>>
>> var div = createMyDiv();
>> parentNode.appendChild(div); // our attributes are applied
>> div.className = "foo"; // and we override them
>>
>> var div = createMyDiv();
>> div.className = "foo"; // we set an attribute
>> parentNode.appendChild(div); // and it gets overwritten
>>
>> Also, the behavior of the latter is different depending on whether
>> parentNode is within a document or not, so it's now also dependent on
>> whether, for example, "document.documentElement.appendChild(parentNode)"
>> happens before or after.
>
> Actually, the two should be identical, because CAS is applied as a
> mutation observer, rather than synchronously.  As long as those
> statements appear in the same microtask, they'll have the same
> behavior regardless of order (CAS will always get to override them).
>
> ~TJ
>

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard  wrote:
> FWIW, while I don't find the idea of attaching event listeners this way too
> interesting (maybe I could be convinced, but event capturing is already
> convenient for most of these examples), being able to say "#myform input {
> autocomplete: off; autocorrect: off; autocapitalize: off; }" or "a { rel:
> noreferrer; }" would be great.
>
> Having it not apply changes dynamically seems weird, since it looks and
> feels like CSS.  It'd mean these two things--which look intuitively the
> same, and behave the same with CSS--would be very different when parentNode
> is in the document:
>
> var div = createMyDiv();
> parentNode.appendChild(div); // our attributes are applied
> div.className = "foo"; // and we override them
>
> var div = createMyDiv();
> div.className = "foo"; // we set an attribute
> parentNode.appendChild(div); // and it gets overwritten
>
> Also, the behavior of the latter is different depending on whether
> parentNode is within a document or not, so it's now also dependent on
> whether, for example, "document.documentElement.appendChild(parentNode)"
> happens before or after.

Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously.  As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).

~TJ

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

[Lea Verou]

Ah, right, mea culpa. 
There’s still the option of restricting attribute selectors altogether or just 
not responding to attribute changes, but doing so for other kinds of changes. 
Of course being dynamic in some ways but not others will make it harder to 
teach and learn, but I believe the tradeoff is worth it.

Lea Verou
W3C developer relations
http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou



On Aug 21, 2012, at 15:59, Tab Atkins Jr. wrote:

> On Tue, Aug 21, 2012 at 3:51 PM, Lea Verou  wrote:
>> I *love* this idea!!
>> However, I’m afraid that in all these cases, ”it’s so much more convenient” 
>> precisely due to the dynamic nature of CSS, so you don’t have to bind event 
>> handlers to cater to document changes etc. I think this proposal would be 
>> much more useful if it was dynamic in at least *some* ways.
>> 
>> I'm probably missing something here, but there are many algorithms to 
>> prevent cycle detection. There are even other technologies in the open web 
>> stack which could result to circular relationships. For example, let me 
>> quote CSS Image Values 4 [1]:
>>> The ‘element()’ function can produce nonsensical circular relationships, 
>>> such as an element using itself as its own background. These relationships 
>>> can be easily and reliably detected and resolved, however, by keeping track 
>>> of a dependency graph and using common cycle-detection algorithms.
>> 
>> Dropping dynamicity altogether because of a few edge cases doesn't sound 
>> like a good idea. Why not just disallow these cases from triggering it? For 
>> example, maybe we could define CAS not to be dynamic for changes made 
>> through CAS? What other cycles are there?
>> If such a thing is not possible or too slow, I think restricting the set of 
>> allowed selectors like Ojan suggested, would be a more acceptable tradeoff 
>> than making the whole thing static.
> 
> The biggest problem with making this more dynamic is that it means you
> have to carry around *two* versions of each attribute - the "native"
> value and the "CAS-applied" value, so that you can "undo" the CAS when
> the selector no longer matches.  This makes all attribute changes
> slower, and all DOM nodes roughly twice as large (or just more
> complex, if they generate the CAS version only when necessary).
> 
> [snip]
> 
> It's just a lot of complication for very little benefit, I think.  The
> vast majority of cases should be okay with just setting attributes
> when an element arrives in the DOM.
> 
> ~TJ
> 

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

[Glenn Maynard]

FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say "#myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; }" or "a { rel:
noreferrer; }" would be great.

Having it not apply changes dynamically seems weird, since it looks and
feels like CSS.  It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:

var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = "foo"; // and we override them

var div = createMyDiv();
div.className = "foo"; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten

Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, "document.documentElement.appendChild(parentNode)"
happens before or after.

-- 
Glenn Maynard

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 3:54 PM, Brian Kardell  wrote:
> On Aug 21, 2012 6:49 PM, "Tab Atkins Jr."  wrote:
>> On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell  wrote:
>>> In other
>>> words,
>>> what is preventing you from writing...
>>>
>>> .foo .bar{
>>> onclick: listen(create a .bar and attach it as a child of
>>> evt.target);
>>> }
>>
>> Nothing prevents you from writing that.  That's not problematic at
>> all, though.  When you click on a .bar, it creates a sibling .bar and
>> gives it the same onclick.  I think you've confused yourself into
>> thinking this is an infinite loop - it's not.
>>
>> Since you can't create a mutation observer with an attribute, I don't
>> think you can infinite-loop yourself at all.  Even if you could, it's
>> no more troublesome than the same possibility in pure JS.
>
> You are right, I was thinking that :)  I blame it on doing this all on my
> cell phone.  Ok.  If you click on the inner foo, now both will fire unless
> you pop the bubble, right?  That is probably fine.

Sure.  That's exactly what you wrote, so that's what we do.

> Do you need the quotes
> if you do it inside a type fn like listen?  Could we not parse around that?

I'd prefer not trying to do that.  Wouldn't we have to do JS parsing
in there?  String is easy, because you can just use CSS rules.

~TJ

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 3:52 PM, Rick Waldron  wrote:
> On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. 
> wrote:
>> On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron 
>> > 3. Where did "evt" come from?
>>
>> Isn't that one of the magically-defined variables in inline event
>> handlers?  If not, swap it out with whatever the correct equivalent
>> is.
>
> Nope? (Maybe in 1990's? :D )

Ah, right, it's an old SVG-ism.  However, "event" is automatically
defined in inline event handlers.

~TJ

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 3:51 PM, Lea Verou  wrote:
> I *love* this idea!!
> However, I’m afraid that in all these cases, ”it’s so much more convenient” 
> precisely due to the dynamic nature of CSS, so you don’t have to bind event 
> handlers to cater to document changes etc. I think this proposal would be 
> much more useful if it was dynamic in at least *some* ways.
>
> I'm probably missing something here, but there are many algorithms to prevent 
> cycle detection. There are even other technologies in the open web stack 
> which could result to circular relationships. For example, let me quote CSS 
> Image Values 4 [1]:
>> The ‘element()’ function can produce nonsensical circular relationships, 
>> such as an element using itself as its own background. These relationships 
>> can be easily and reliably detected and resolved, however, by keeping track 
>> of a dependency graph and using common cycle-detection algorithms.
>
> Dropping dynamicity altogether because of a few edge cases doesn't sound like 
> a good idea. Why not just disallow these cases from triggering it? For 
> example, maybe we could define CAS not to be dynamic for changes made through 
> CAS? What other cycles are there?
> If such a thing is not possible or too slow, I think restricting the set of 
> allowed selectors like Ojan suggested, would be a more acceptable tradeoff 
> than making the whole thing static.

The biggest problem with making this more dynamic is that it means you
have to carry around *two* versions of each attribute - the "native"
value and the "CAS-applied" value, so that you can "undo" the CAS when
the selector no longer matches.  This makes all attribute changes
slower, and all DOM nodes roughly twice as large (or just more
complex, if they generate the CAS version only when necessary).

It also means we need to define which version "wins".  It's less than
obvious what the correct answer should be if, later in the document's
life, a script does an explicit setAttribute().  Is this changing the
native value (and thus is ignored if CAS is already setting that
attribute)?  Or is it setting the attribute in a higher-specificity
way, similar to setting el.style versus normal CSS?  No matter which
one you choose, you might be wrong!

It's just a lot of complication for very little benefit, I think.  The
vast majority of cases should be okay with just setting attributes
when an element arrives in the DOM.

~TJ

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

[Brian Kardell]

On Aug 21, 2012 6:49 PM, "Tab Atkins Jr."  wrote:
>
> On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell  wrote:
> > On Aug 21, 2012 6:18 PM, "Tab Atkins Jr."  wrote:
> >> So, in my current proposal, you can just set an onfoo attribute:
> >>
> >> ul.special > li {
> >>   onclick: "alert('You clicked me!');
> >> evt.target.classlist.add('clicked');";
> >> }
> >>
> >> Here's a suggestion for a similar API that would invoke
> >> addEventListener instead of setAttribute:
> >>
> >> ul.special > li {
> >>   onclick: listen("alert('You clicked me!');
> >> evt.target.classlist.add('clicked');");
> >> }
> >
> > This feels a lot like netscape's old actionsheets proposal.  Doesn't it
> > create the same footgun I mentioned above though?  Would you be blocked
off
> > from accessing dom in those handlers? Or are the read only (you may
remember
> > you, borris and I discussed how that might work last year)  In other
words,
> > what is preventing you from writing...
> >
> > .foo .bar{
> > onclick: listen(create a .bar and attach it as a child of
evt.target);
> > }
>
> Nothing prevents you from writing that.  That's not problematic at
> all, though.  When you click on a .bar, it creates a sibling .bar and
> gives it the same onclick.  I think you've confused yourself into
> thinking this is an infinite loop - it's not.
>
> Since you can't create a mutation observer with an attribute, I don't
> think you can infinite-loop yourself at all.  Even if you could, it's
> no more troublesome than the same possibility in pure JS.
>
> ~TJ

You are right, I was thinking that :)  I blame it on doing this all on my
cell phone.  Ok.  If you click on the inner foo, now both will fire unless
you pop the bubble, right?  That is probably fine.  Do you need the quotes
if you do it inside a type fn like listen?  Could we not parse around
that?

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

[Rick Waldron]

On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. wrote:

> On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron 
> wrote:
> > On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. 
> > wrote:
> >> ul.special > li {
> >>   onclick: "alert('You clicked me!');
> >> evt.target.classlist.add('clicked');";
> >> }
> >
> >
> > This is certainly interesting, but...
> >
> > 1. It's a string that will have to be eval'ed, right? In what scope? Does
> > this get wrapped in a function expression?
>
> No, it's a string that gets passed as an argument to setAttribute()
> (or the moral equivalent of such).  Any eval'ing that happens is just
> part of the normal way that onfoo attributes are handled.
>

Ah-ha, I was thinking of this a bit too "script literally"

>
>
> > 2. Using inline attributes that match up to node.onfoo will pave over
> each
> > other... if some other style sheet is introduced, by some third party
> widget
> > that happens to have
> >
> > ul.special > li {
> >   onclick: "alert('busted')";
> > }
> >
> > ...Bummer?
>
> Yes.  That's why I just suggested the listen() function, which would
> invoke addEventListener instead of setAttribute.
>
> This *would* require a little bit more detail about evaling the
> string.  I suppose it should just be passed through the Function
> constructor in the global scope before being passed to aEL.
>
>
> > 3. Where did "evt" come from?
>
> Isn't that one of the magically-defined variables in inline event
> handlers?  If not, swap it out with whatever the correct equivalent
> is.
>

Nope? (Maybe in 1990's? :D )




>
>
> >> Here's a suggestion for a similar API that would invoke
> >> addEventListener instead of setAttribute:
> >>
> >> ul.special > li {
> >>   onclick: listen("alert('You clicked me!');
> >> evt.target.classlist.add('clicked');");
> >> }
> >
> > How do we know where the body ends?
>
> Do you mean the function body?  It's a string.  The end is well-defined.
> ^_^
>

Yep, function body.

The string broke over two lines and tricked my eyes and brain. ;)


Rick



>
> ~TJ
>

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

[Lea Verou]

I *love* this idea!!
However, I’m afraid that in all these cases, ”it’s so much more convenient” 
precisely due to the dynamic nature of CSS, so you don’t have to bind event 
handlers to cater to document changes etc. I think this proposal would be much 
more useful if it was dynamic in at least *some* ways. 

I'm probably missing something here, but there are many algorithms to prevent 
cycle detection. There are even other technologies in the open web stack which 
could result to circular relationships. For example, let me quote CSS Image 
Values 4 [1]:
> The ‘element()’ function can produce nonsensical circular relationships, such 
> as an element using itself as its own background. These relationships can be 
> easily and reliably detected and resolved, however, by keeping track of a 
> dependency graph and using common cycle-detection algorithms.

Dropping dynamicity altogether because of a few edge cases doesn't sound like a 
good idea. Why not just disallow these cases from triggering it? For example, 
maybe we could define CAS not to be dynamic for changes made through CAS? What 
other cycles are there?
If such a thing is not possible or too slow, I think restricting the set of 
allowed selectors like Ojan suggested, would be a more acceptable tradeoff than 
making the whole thing static.

[1]: http://dev.w3.org/csswg/css4-images/#element-cycles

Lea Verou
W3C developer relations
http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou


On Aug 21, 2012, at 11:17, Tab Atkins Jr. wrote:

> I recently participated in an internal thread at Google where it was
> proposed to move a (webkit-specific) feature from an attribute to a
> CSS property, because applying it via a property is *much* more
> convenient.
> 
> [snip]
> 
> Thoughts?  I tried to make this as simple as possible while still
> being useful, so that it's easy to implement and to understand.
> Hopefully I succeeded!
> 
> ~TJ
> 

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell  wrote:
> On Aug 21, 2012 6:18 PM, "Tab Atkins Jr."  wrote:
>> So, in my current proposal, you can just set an onfoo attribute:
>>
>> ul.special > li {
>>   onclick: "alert('You clicked me!');
>> evt.target.classlist.add('clicked');";
>> }
>>
>> Here's a suggestion for a similar API that would invoke
>> addEventListener instead of setAttribute:
>>
>> ul.special > li {
>>   onclick: listen("alert('You clicked me!');
>> evt.target.classlist.add('clicked');");
>> }
>
> This feels a lot like netscape's old actionsheets proposal.  Doesn't it
> create the same footgun I mentioned above though?  Would you be blocked off
> from accessing dom in those handlers? Or are the read only (you may remember
> you, borris and I discussed how that might work last year)  In other words,
> what is preventing you from writing...
>
> .foo .bar{
> onclick: listen(create a .bar and attach it as a child of evt.target);
> }

Nothing prevents you from writing that.  That's not problematic at
all, though.  When you click on a .bar, it creates a sibling .bar and
gives it the same onclick.  I think you've confused yourself into
thinking this is an infinite loop - it's not.

Since you can't create a mutation observer with an attribute, I don't
think you can infinite-loop yourself at all.  Even if you could, it's
no more troublesome than the same possibility in pure JS.

~TJ

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

[Brian Kardell]

On Aug 21, 2012 6:18 PM, "Tab Atkins Jr."  wrote:
>
> On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell  wrote:
> > On Aug 21, 2012 5:40 PM, "Tab Atkins Jr."  wrote:
> >> On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai  wrote:
> >>> On a somewhat unrelated note, could we somehow also incorporate jquery
> >>> style
> >>> live event handlers here? See previous www-dom discussion about this:
.
> >>> I
> >>> suppose we'd still just want listen/unlisten(selector, handler)
methods,
> >>> but
> >>> they'd get applied at the same time as cascaded attributes. Although,
we
> >>> might want to apply those on attribute changes as well.
> >>
> >> Using CAS to apply an "onfoo" attribute is nearly the same (use a
> >> string value to pass the function, obviously).  It'll only allow a
> >> single listener to be applied, though.
> >>
> >> If it's considered worthwhile, we can magic up this case a bit.  CAS
> >> properties don't accept functions normally (or rather, as I have it
> >> defined in the OP, it would just accept a FUNCTION token, which is
> >> just the function name and opening paren, but I should tighten up that
> >> definition).  We could have a magic function like listen()
> >> that, when used on an onfoo attribute (more generally, on a
> >> host-language-defined "event listener" attribute) does an
> >> addEventListener() call rather than a setAttribute() call.
> >
> > Can you give some pseudo code or something that is relatively close to
what
> > you mean here?  I'm not entirely sure I follow.
>
> Sure!
>
> So, in my current proposal, you can just set an onfoo attribute:
>
> ul.special > li {
>   onclick: "alert('You clicked me!');
evt.target.classlist.add('clicked');";
> }
>
> Here's a suggestion for a similar API that would invoke
> addEventListener instead of setAttribute:
>
> ul.special > li {
>   onclick: listen("alert('You clicked me!');
> evt.target.classlist.add('clicked');");
> }
>
> ~TJ

This feels a lot like netscape's old actionsheets proposal.  Doesn't it
create the same footgun I mentioned above though?  Would you be blocked off
from accessing dom in those handlers? Or are the read only (you may
remember you, borris and I discussed how that might work last year)  In
other words, what is preventing you from writing...

.foo .bar{
onclick: listen(create a .bar and attach it as a child of evt.target);
}

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron  wrote:
> On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. 
> wrote:
>> ul.special > li {
>>   onclick: "alert('You clicked me!');
>> evt.target.classlist.add('clicked');";
>> }
>
>
> This is certainly interesting, but...
>
> 1. It's a string that will have to be eval'ed, right? In what scope? Does
> this get wrapped in a function expression?

No, it's a string that gets passed as an argument to setAttribute()
(or the moral equivalent of such).  Any eval'ing that happens is just
part of the normal way that onfoo attributes are handled.


> 2. Using inline attributes that match up to node.onfoo will pave over each
> other... if some other style sheet is introduced, by some third party widget
> that happens to have
>
> ul.special > li {
>   onclick: "alert('busted')";
> }
>
> ...Bummer?

Yes.  That's why I just suggested the listen() function, which would
invoke addEventListener instead of setAttribute.

This *would* require a little bit more detail about evaling the
string.  I suppose it should just be passed through the Function
constructor in the global scope before being passed to aEL.


> 3. Where did "evt" come from?

Isn't that one of the magically-defined variables in inline event
handlers?  If not, swap it out with whatever the correct equivalent
is.


>> Here's a suggestion for a similar API that would invoke
>> addEventListener instead of setAttribute:
>>
>> ul.special > li {
>>   onclick: listen("alert('You clicked me!');
>> evt.target.classlist.add('clicked');");
>> }
>
> How do we know where the body ends?

Do you mean the function body?  It's a string.  The end is well-defined. ^_^

~TJ

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

[Rick Waldron]

Comments inline...

On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. wrote:

> On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell  wrote:
> > On Aug 21, 2012 5:40 PM, "Tab Atkins Jr."  wrote:
> >> On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai  wrote:
> >>> On a somewhat unrelated note, could we somehow also incorporate jquery
> >>> style
> >>> live event handlers here? See previous www-dom discussion about this: .
> >>> I
> >>> suppose we'd still just want listen/unlisten(selector, handler)
> methods,
> >>> but
> >>> they'd get applied at the same time as cascaded attributes. Although,
> we
> >>> might want to apply those on attribute changes as well.
> >>
> >> Using CAS to apply an "onfoo" attribute is nearly the same (use a
> >> string value to pass the function, obviously).  It'll only allow a
> >> single listener to be applied, though.
> >>
> >> If it's considered worthwhile, we can magic up this case a bit.  CAS
> >> properties don't accept functions normally (or rather, as I have it
> >> defined in the OP, it would just accept a FUNCTION token, which is
> >> just the function name and opening paren, but I should tighten up that
> >> definition).  We could have a magic function like listen()
> >> that, when used on an onfoo attribute (more generally, on a
> >> host-language-defined "event listener" attribute) does an
> >> addEventListener() call rather than a setAttribute() call.
> >
> > Can you give some pseudo code or something that is relatively close to
> what
> > you mean here?  I'm not entirely sure I follow.
>
> Sure!
>
> So, in my current proposal, you can just set an onfoo attribute:
>



>
> ul.special > li {
>   onclick: "alert('You clicked me!');
> evt.target.classlist.add('clicked');";
> }
>

This is certainly interesting, but...

1. It's a string that will have to be eval'ed, right? In what scope? Does
this get wrapped in a function expression?
2. Using inline attributes that match up to node.onfoo will pave over each
other... if some other style sheet is introduced, by some third party
widget that happens to have

ul.special > li {
  onclick: "alert('busted')";
}

...Bummer?

3. Where did "evt" come from?


> Here's a suggestion for a similar API that would invoke
> addEventListener instead of setAttribute:
>
> ul.special > li {
>   onclick: listen("alert('You clicked me!');
> evt.target.classlist.add('clicked');");
> }
>

How do we know where the body ends?


>
> ~TJ
>


Thanks in advance! :)

Rick

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell  wrote:
> On Aug 21, 2012 5:40 PM, "Tab Atkins Jr."  wrote:
>> On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai  wrote:
>>> On a somewhat unrelated note, could we somehow also incorporate jquery
>>> style
>>> live event handlers here? See previous www-dom discussion about this: .
>>> I
>>> suppose we'd still just want listen/unlisten(selector, handler) methods,
>>> but
>>> they'd get applied at the same time as cascaded attributes. Although, we
>>> might want to apply those on attribute changes as well.
>>
>> Using CAS to apply an "onfoo" attribute is nearly the same (use a
>> string value to pass the function, obviously).  It'll only allow a
>> single listener to be applied, though.
>>
>> If it's considered worthwhile, we can magic up this case a bit.  CAS
>> properties don't accept functions normally (or rather, as I have it
>> defined in the OP, it would just accept a FUNCTION token, which is
>> just the function name and opening paren, but I should tighten up that
>> definition).  We could have a magic function like listen()
>> that, when used on an onfoo attribute (more generally, on a
>> host-language-defined "event listener" attribute) does an
>> addEventListener() call rather than a setAttribute() call.
>
> Can you give some pseudo code or something that is relatively close to what
> you mean here?  I'm not entirely sure I follow.

Sure!

So, in my current proposal, you can just set an onfoo attribute:

ul.special > li {
  onclick: "alert('You clicked me!'); evt.target.classlist.add('clicked');";
}

Here's a suggestion for a similar API that would invoke
addEventListener instead of setAttribute:

ul.special > li {
  onclick: listen("alert('You clicked me!');
evt.target.classlist.add('clicked');");
}

~TJ

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

[Brian Kardell]

On Aug 21, 2012 5:40 PM, "Tab Atkins Jr."  wrote:
>
> On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai  wrote:
> > On a somewhat unrelated note, could we somehow also incorporate jquery
style
> > live event handlers here? See previous www-dom discussion about this: .
I
> > suppose we'd still just want listen/unlisten(selector, handler)
methods, but
> > they'd get applied at the same time as cascaded attributes. Although, we
> > might want to apply those on attribute changes as well.
>
> Using CAS to apply an "onfoo" attribute is nearly the same (use a
> string value to pass the function, obviously).  It'll only allow a
> single listener to be applied, though.
>
> If it's considered worthwhile, we can magic up this case a bit.  CAS
> properties don't accept functions normally (or rather, as I have it
> defined in the OP, it would just accept a FUNCTION token, which is
> just the function name and opening paren, but I should tighten up that
> definition).  We could have a magic function like listen()
> that, when used on an onfoo attribute (more generally, on a
> host-language-defined "event listener" attribute) does an
> addEventListener() call rather than a setAttribute() call.
>
> ~TJ
>

Can you give some pseudo code or something that is relatively close to what
you mean here?  I'm not entirely sure I follow.

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai  wrote:
> On a somewhat unrelated note, could we somehow also incorporate jquery style
> live event handlers here? See previous www-dom discussion about this: . I
> suppose we'd still just want listen/unlisten(selector, handler) methods, but
> they'd get applied at the same time as cascaded attributes. Although, we
> might want to apply those on attribute changes as well.

Using CAS to apply an "onfoo" attribute is nearly the same (use a
string value to pass the function, obviously).  It'll only allow a
single listener to be applied, though.

If it's considered worthwhile, we can magic up this case a bit.  CAS
properties don't accept functions normally (or rather, as I have it
defined in the OP, it would just accept a FUNCTION token, which is
just the function name and opening paren, but I should tighten up that
definition).  We could have a magic function like listen()
that, when used on an onfoo attribute (more generally, on a
host-language-defined "event listener" attribute) does an
addEventListener() call rather than a setAttribute() call.

~TJ

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

[Ojan Vafai]

On Tue, Aug 21, 2012 at 1:58 PM, Tab Atkins Jr. wrote:

> On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai  wrote:
> > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. 
> > wrote:
> >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
> >> > Meh. I think this loses most of the "CSS is so much more convenient"
> >> > benefits. It's mainly the fact that you don't have to worry about
> >> > whether
> >> > the nodes exist yet that makes CSS more convenient.
> >>
> >> Note that this benefit is preserved.  Moving or inserting an element
> >> in the DOM should apply CAS to it.
> >>
> >> The only thing we're really losing in the dynamic-ness is that other
> >> types of mutations to the DOM don't change what CAS does, and some of
> >> the dynamic selectors like :hover don't do anything.
> >
> >
> > Ah, I missed the "plus a mutation observer that reruns the mutations on
> any
> > nodes added to the document" bit. Ok, so this timing is very specific
> then.
> > It would get applied at the microtask time, not at the time the DOM was
> > modified. Would it get applied before or after mutation observers get
> > called? Seems like you'd want it to execute first. Calling it after
> mutation
> > observers would require an extra delivery of mutations after the
> attributes
> > are applied, which seems silly.
>
> I presume there's an ordering of mutation observers, such that ones
> defined earlier in document history get the notifications first, or
> somesuch?


Correct.


>  If so, CAS should indeed run before any author-defined
> observers.


On a somewhat unrelated note, could we somehow also incorporate jquery
style live event handlers here? See previous www-dom discussion about this:
. I suppose we'd still just want listen/unlisten(selector, handler)
methods, but they'd get applied at the same time as cascaded attributes.
Although, we might want to apply those on attribute changes as well.

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 2:20 PM, Travis Leithead
 wrote:
>> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
>> On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai  wrote:
>> > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. 
>> > wrote:
>> >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai 
>> wrote:
>> >> > Meh. I think this loses most of the "CSS is so much more convenient"
>> >> > benefits. It's mainly the fact that you don't have to worry about
>> >> > whether the nodes exist yet that makes CSS more convenient.
>> >>
>> >> Note that this benefit is preserved.  Moving or inserting an element
>> >> in the DOM should apply CAS to it.
>> >>
>> >> The only thing we're really losing in the dynamic-ness is that other
>> >> types of mutations to the DOM don't change what CAS does, and some of
>> >> the dynamic selectors like :hover don't do anything.
>> >
>> >
>> > Ah, I missed the "plus a mutation observer that reruns the mutations
>> > on any nodes added to the document" bit. Ok, so this timing is very 
>> > specific
>> then.
>> > It would get applied at the microtask time, not at the time the DOM
>> > was modified. Would it get applied before or after mutation observers
>> > get called? Seems like you'd want it to execute first. Calling it
>> > after mutation observers would require an extra delivery of mutations
>> > after the attributes are applied, which seems silly.
>>
>> I presume there's an ordering of mutation observers, such that ones defined
>> earlier in document history get the notifications first, or somesuch?  If so,
>> CAS should indeed run before any author-defined observers.
>
> So this can basically be completely authored as a script library using 
> existing or soon-to-be-implemented technologies? You just need a CAS JS 
> parser, CAS JS rule engine, and mutation observers? Tab, you should just 
> supply an implementation of this. :)

I could, yes.  ^_^  However, "you can just do it as a library" isn't
an argument against adding a feature to the platform, if the feature
is sufficiently useful.

~TJ

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

[Travis Leithead]

> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
> 
> On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai  wrote:
> > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. 
> > wrote:
> >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai 
> wrote:
> >> > Meh. I think this loses most of the "CSS is so much more convenient"
> >> > benefits. It's mainly the fact that you don't have to worry about
> >> > whether the nodes exist yet that makes CSS more convenient.
> >>
> >> Note that this benefit is preserved.  Moving or inserting an element
> >> in the DOM should apply CAS to it.
> >>
> >> The only thing we're really losing in the dynamic-ness is that other
> >> types of mutations to the DOM don't change what CAS does, and some of
> >> the dynamic selectors like :hover don't do anything.
> >
> >
> > Ah, I missed the "plus a mutation observer that reruns the mutations
> > on any nodes added to the document" bit. Ok, so this timing is very specific
> then.
> > It would get applied at the microtask time, not at the time the DOM
> > was modified. Would it get applied before or after mutation observers
> > get called? Seems like you'd want it to execute first. Calling it
> > after mutation observers would require an extra delivery of mutations
> > after the attributes are applied, which seems silly.
> 
> I presume there's an ordering of mutation observers, such that ones defined
> earlier in document history get the notifications first, or somesuch?  If so,
> CAS should indeed run before any author-defined observers.

So this can basically be completely authored as a script library using existing 
or soon-to-be-implemented technologies? You just need a CAS JS parser, CAS JS 
rule engine, and mutation observers? Tab, you should just supply an 
implementation of this. :)

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell  wrote:
> On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr.  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.

~TJ

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai  wrote:
> On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. 
> wrote:
>> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
>> > Meh. I think this loses most of the "CSS is so much more convenient"
>> > benefits. It's mainly the fact that you don't have to worry about
>> > whether
>> > the nodes exist yet that makes CSS more convenient.
>>
>> Note that this benefit is preserved.  Moving or inserting an element
>> in the DOM should apply CAS to it.
>>
>> The only thing we're really losing in the dynamic-ness is that other
>> types of mutations to the DOM don't change what CAS does, and some of
>> the dynamic selectors like :hover don't do anything.
>
>
> Ah, I missed the "plus a mutation observer that reruns the mutations on any
> nodes added to the document" bit. Ok, so this timing is very specific then.
> It would get applied at the microtask time, not at the time the DOM was
> modified. Would it get applied before or after mutation observers get
> called? Seems like you'd want it to execute first. Calling it after mutation
> observers would require an extra delivery of mutations after the attributes
> are applied, which seems silly.

I presume there's an ordering of mutation observers, such that ones
defined earlier in document history get the notifications first, or
somesuch?  If so, CAS should indeed run before any author-defined
observers.

~TJ

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

[Ojan Vafai]

On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. wrote:

> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
> > Meh. I think this loses most of the "CSS is so much more convenient"
> > benefits. It's mainly the fact that you don't have to worry about whether
> > the nodes exist yet that makes CSS more convenient.
>
> Note that this benefit is preserved.  Moving or inserting an element
> in the DOM should apply CAS to it.
>
> The only thing we're really losing in the dynamic-ness is that other
> types of mutations to the DOM don't change what CAS does, and some of
> the dynamic selectors like :hover don't do anything.
>

Ah, I missed the "plus a mutation observer that reruns the mutations on any
nodes added to the document" bit. Ok, so this timing is very specific then.
It would get applied at the microtask time, not at the time the DOM was
modified. Would it get applied before or after mutation observers get
called? Seems like you'd want it to execute first. Calling it after
mutation observers would require an extra delivery of mutations after the
attributes are applied, which seems silly.

> That said, I share your worry that having this be dynamic would slow down
> > DOM modification too much.
> >
> > What if we only allowed a restricted set of selectors and made these
> sheets
> > dynamic instead? Simple, non-pseudo selectors have information that is
> all
> > local to the node itself (e.g. can be applied before the node is in the
> > DOM). Maybe even just restrict it to IDs and classes. I think that would
> > meet the majority use-case much better.
>
> I think that being able to use complex selectors is a sufficiently
> large use-case that we should keep it.
>
> > Alternately, what if these applied the attributes asynchronously (e.g.
> right
> > before style resolution)?
>
> Can you elaborate?
>
> ~TJ
>

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

[Brian Kardell]

On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr.  wrote:
> On Tue, Aug 21, 2012 at 1:30 PM, Brian Kardell  wrote:
>> On Aug 21, 2012 4:03 PM, "Tab Atkins Jr."  wrote:
>>> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
 Meh. I think this loses most of the "CSS is so much more convenient"
 benefits. It's mainly the fact that you don't have to worry about
 whether
 the nodes exist yet that makes CSS more convenient.
>>>
>>> Note that this benefit is preserved.  Moving or inserting an element
>>> in the DOM should apply CAS to it.
>>>
>>> The only thing we're really losing in the dynamic-ness is that other
>>> types of mutations to the DOM don't change what CAS does, and some of
>>> the dynamic selectors like :hover don't do anything.
>>>
>>
>> So if I had a selector .foo .bar and then some script inserted a .bar inside
>> a .foo - that would work... but if I added a .bar class to some existing
>> child of .foo it would not...is that right?
>
> Correct.  If we applied CAS on attribute changes, we'd have... problems.
>
> ~TJ

Because you could do something like:

.foo[x=123]{ x:  234; }
.foo[x=234]{ x:  123; }

?

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 1:30 PM, Brian Kardell  wrote:
> On Aug 21, 2012 4:03 PM, "Tab Atkins Jr."  wrote:
>> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
>>> Meh. I think this loses most of the "CSS is so much more convenient"
>>> benefits. It's mainly the fact that you don't have to worry about
>>> whether
>>> the nodes exist yet that makes CSS more convenient.
>>
>> Note that this benefit is preserved.  Moving or inserting an element
>> in the DOM should apply CAS to it.
>>
>> The only thing we're really losing in the dynamic-ness is that other
>> types of mutations to the DOM don't change what CAS does, and some of
>> the dynamic selectors like :hover don't do anything.
>>
>
> So if I had a selector .foo .bar and then some script inserted a .bar inside
> a .foo - that would work... but if I added a .bar class to some existing
> child of .foo it would not...is that right?

Correct.  If we applied CAS on attribute changes, we'd have... problems.

~TJ

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

[Brian Kardell]

On Aug 21, 2012 4:03 PM, "Tab Atkins Jr."  wrote:
>
> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
> > Meh. I think this loses most of the "CSS is so much more convenient"
> > benefits. It's mainly the fact that you don't have to worry about
whether
> > the nodes exist yet that makes CSS more convenient.
>
> Note that this benefit is preserved.  Moving or inserting an element
> in the DOM should apply CAS to it.
>
> The only thing we're really losing in the dynamic-ness is that other
> types of mutations to the DOM don't change what CAS does, and some of
> the dynamic selectors like :hover don't do anything.
>

So if I had a selector .foo .bar and then some script inserted a .bar
inside a .foo - that would work... but if I added a .bar class to some
existing child of .foo it would not...is that right?

> > That said, I share your worry that having this be dynamic would slow
down
> > DOM modification too much.
> >
> > What if we only allowed a restricted set of selectors and made these
sheets
> > dynamic instead? Simple, non-pseudo selectors have information that is
all
> > local to the node itself (e.g. can be applied before the node is in the
> > DOM). Maybe even just restrict it to IDs and classes. I think that would
> > meet the majority use-case much better.
>
> I think that being able to use complex selectors is a sufficiently
> large use-case that we should keep it.
>
> > Alternately, what if these applied the attributes asynchronously (e.g.
right
> > before style resolution)?
>
> Can you elaborate?
>
> ~TJ
>

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

[Tab Atkins Jr.]

On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai  wrote:
> Meh. I think this loses most of the "CSS is so much more convenient"
> benefits. It's mainly the fact that you don't have to worry about whether
> the nodes exist yet that makes CSS more convenient.

Note that this benefit is preserved.  Moving or inserting an element
in the DOM should apply CAS to it.

The only thing we're really losing in the dynamic-ness is that other
types of mutations to the DOM don't change what CAS does, and some of
the dynamic selectors like :hover don't do anything.

> That said, I share your worry that having this be dynamic would slow down
> DOM modification too much.
>
> What if we only allowed a restricted set of selectors and made these sheets
> dynamic instead? Simple, non-pseudo selectors have information that is all
> local to the node itself (e.g. can be applied before the node is in the
> DOM). Maybe even just restrict it to IDs and classes. I think that would
> meet the majority use-case much better.

I think that being able to use complex selectors is a sufficiently
large use-case that we should keep it.

> Alternately, what if these applied the attributes asynchronously (e.g. right
> before style resolution)?

Can you elaborate?

~TJ

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

[Ojan Vafai]

On Tue, Aug 21, 2012 at 11:17 AM, Tab Atkins Jr. wrote:

> I recently participated in an internal thread at Google where it was
> proposed to move a (webkit-specific) feature from an attribute to a
> CSS property, because applying it via a property is *much* more
> convenient.
>
> Similarly, some of the a11y folks have recently been talking about
> applying aria-* attributes via CSS, again, because it's just so much
> more convenient.
>
> I think there are probably a lot of examples of this, where something
> definitely belongs in an attribute, but it would just be so *nice* to
> set it with something like CSS, where you declare it once and
> everything just works.  For example, inline event handlers!
>
> Given all this, I have a proposal for a method of doing that.  It's
> very similar to CSS and gives most of the benefits, but should avoid
> some pitfalls that have sunk similar proposals in the past.
>
> Cascading Attribute Sheets
> ===
>
> CAS is a language using the same basic syntax of CSS, meant for easily
> applying attributes to an HTML page.
>
> To use it, include a CAS file using 

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

[Tab Atkins Jr.]

I recently participated in an internal thread at Google where it was
proposed to move a (webkit-specific) feature from an attribute to a
CSS property, because applying it via a property is *much* more
convenient.

Similarly, some of the a11y folks have recently been talking about
applying aria-* attributes via CSS, again, because it's just so much
more convenient.

I think there are probably a lot of examples of this, where something
definitely belongs in an attribute, but it would just be so *nice* to
set it with something like CSS, where you declare it once and
everything just works.  For example, inline event handlers!

Given all this, I have a proposal for a method of doing that.  It's
very similar to CSS and gives most of the benefits, but should avoid
some pitfalls that have sunk similar proposals in the past.

Cascading Attribute Sheets
===

CAS is a language using the same basic syntax of CSS, meant for easily
applying attributes to an HTML page.

To use it, include a CAS file using