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