- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 25 Oct 2011 14:11:28 -0700
- To: Roland Steiner <rolandsteiner@google.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
On Tue, Oct 25, 2011 at 2:03 PM, Roland Steiner <rolandsteiner@google.com> wrote: >> > OTOH, with the current value you also have this question: >> > .x { >> > data-foo: red; >> > data-bar: data(foo); >> > color: data(bar); >> > } >> > #y { >> > data-foo: green; >> > } >> > <div class=x id=y> Red or Green? </div> [snip] > I'd contend you *don't need* this. But what I wanted to get at with this > example is an implementation issue: you couldn't just apply and overwrite > properties in ascending cascade order - this would leave the text red in > above example. That's not true. The computed value of data-foo on that element is "green". The computed value of data-bar depends on the computed value of data-foo, and thus is also "green". Finally, the computed value of color depends on the computed value of data-bar, and thus is also "green". You're imagining some weird sort of application that doesn't use the cascade and depends on the order in which you specify things (more than the cascade normally does). No property in CSS works like that. In other words, the example should work *exactly like* the following: .x { font-size: 10px; width: 1em; } #y { font-size: 20px; } <div class=x id=y>10px or 20px wide?</div> Resolving computed-value dependencies is already present and quite normal. The only wrinkle is that the custom data properties allow circular dependencies, so we have to specify explicitly how to handle that. Otherwise, they're exactly the same as any other value or unit that depends on the value of some other property. ~TJ ~TJ
Received on Tuesday, 25 October 2011 21:12:16 UTC