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 l...@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).
[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
