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
>
