W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

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

From: Lea Verou <lea@verou.me>
Date: Mon, 4 May 2015 23:52:04 -0400
Cc: Lea Verou <lea@w3.org>, public-webapps <public-webapps@w3.org>
Message-Id: <F65C9FD8-ADEE-457B-887D-6BC354B4E92E@verou.me>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
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. 

> On Aug 21, 2012, at 18:59, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 3:51 PM, Lea Verou <lea@w3.org> 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
Received on Tuesday, 5 May 2015 03:52:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC