- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 25 Oct 2011 12:45:27 -0700
- To: Roland Steiner <rolandsteiner@google.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
On Tue, Oct 25, 2011 at 10:32 AM, Roland Steiner <rolandsteiner@google.com> wrote: > Of course having both options is the most flexible approach. That said, I'm > not entirely sure I agree with the above. It seems to me that if you have to > use wrappers to stage variables, you're doing it wrong (tm). There are only > 3 cases where re-using a "local" variable seems necessary to me: > - accessing layout-dependent values for the current element > - using a variable to contain a complicated calc() expression to be used in > multiple other places > - at :root > The first is not an issue if we don't allow arbitrary properties to be used > with data() - and I agree this is a reasonable and necessary restriction if > data() accesses the current value rather than the inherited. The other 2 I'm > not sure are all that are all that problematic. E.g., one could use :root to > stage "global" variables and <body> to stage derived variables. 1. You can only do that if you only have a single layer of dependency. Multiple layers require you to add wrappers to your HTML, which is horribad. (Adding wrappers for layout purposes is one thing. Adding wrappers *so you can derive variables* is beyond the pale.) 2. You are also unable to use the derived values on <body>, since you're establishing them on <body>, and won't be able to use them until they inherit into the children. 3. This is more problematic on components, because you aren't guaranteed to have a "useless root" like <html> is - you'll probably want to use your root element for useful things, but you're not allowed to use any of your variables there (they have to wait for the children). 4. Similarly, setting variables in @style is less useful - you have to set them on the parent of the element you care about instead. All in all, normal use of variables would be significantly less convenient if you could only access the inherited value. It would also make it likely that people add dummy elements to their HTML for the purpose of handling variables, which is all kinds of layer-violating silliness. > 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> > I'd argue it should be green, but that means local "helper variables" are > not all that reliable. This is *exactly* what you want - being able to use the cascade is a decent part of the appeal of this approach. Note that with your approach it's impossible to do something similar unless there's a wrapper you can target instead. ~TJ
Received on Tuesday, 25 October 2011 19:46:19 UTC