RE: [css-variables] var() for non-custom properties

> De : Lea Verou [mailto:lea@verou.me]
> 
> Letting implementation complexity leak into the UI is a common antipattern
> and this is exactly what’s happening here.
>
> ...
> 
> *ALL* cycles can be detected by “keeping track of a dependency graph and
> using common cycle-detection algorithms”. Worst case scenario, we can just
> be very aggressive about what depends on what and it’s still better than
> rejecting entire features that are needed by thousands of authors daily on
> the grounds of “but if used nonsensically it could result in a cycle and then
> the world would explode!!!11”.

Yes, they can. I was (and still am) also in favor of this but I can recognize the extra work for browser vendors is more than just detecting cycles. Browser codes is highly optimized and those optimizations come in the way of making changes to existing things easily. It's a price of the attempts to make browser fasts.

I care about CSS Custom Properties enough to understand that if we ask too much, they'll never land. And I want them to land. So I guess we should compromise. My (personal) opinion is that we can always revisit this later.



> Not to mention that using variables, besides being an ugly solution, is not an
> option when you want to reference CSS you do not control.

True



> Potential cycles come up all the time with any reasonable styling mechanism
> that supports the kinds of constraints needed by real designs. Maybe it’s
> time to devise a way of dealing with them when they actually occur or at
> least have a real chance of occurring.
> 
> The ripple effects of avoiding cycles like the plague accounts for most of the
> utter puzzlement people feel when dealing with CSS even in their first few
> lines of CSS code. I’m sure we can do better.

Received on Saturday, 23 May 2015 10:03:50 UTC