- From: Roland Steiner <rolandsteiner@google.com>
- Date: Tue, 25 Oct 2011 10:32:33 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
- Message-ID: <CACFPSpj88vJYuU1aYq9fj+nPMK+0W-1qV4DBmpMEVtbV4-feWQ@mail.gmail.com>
On Tue, Oct 25, 2011 at 09:56, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Oct 25, 2011 at 9:45 AM, Roland Steiner > <rolandsteiner@google.com> wrote: > > On Mon, Oct 24, 2011 at 23:30, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > >> Another thought occurs to me. Since I already want to allow variables > >> referring to other variables, for use in various functions and > >> whatnot, it seems like it would be incredibly useful to also allow you > >> to invoke the *inherited* value of a variable. This would allow for > >> some *really* useful effects, such as building up an increasing value > >> as you descend the DOM: > >> > >> :root { > >> data-indent: 10px; > >> } > >> ul { > >> data-indent: calc( parent-data(indent) + 10px ); > >> } > > > > This is actually the default I envisioned and described for apply(). IMHO > > it's more general than using the current value: it avoids circular > > dependencies, allows for easy swapping of values without "helper > > properties", etc. > > The downside that one couldn't use the current value inside the same rule > > block isn't a big drawback IMHO. Rather than > > > > :root { > > data-foo: red; > > data-bar: linear-gradient(transparent, data(foo)); > > } > > > > you'd have to duplicate 'red' in both lines, or use another, > > previously-defined variable. > > Duplicating red is called "not using a variable". It means that when > you update your color in one spot, you have to update it in another > spot as well, which is somewhat the opposite of what we're trying to > accomplish. > > It also means that, if you *do* want variables built on variables, you > have to put the secondary variable at a lower level in the tree. > Further, it means that in order to *use* a variable, it must be > already declared further up the tree. Both of these make the > component use-cases more difficult than necessary, possibly > necessitating the use of extra HTML wrapping elements just so you have > enough levels to set up your variables. This is all kinds of bad. > 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. 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. - Roland
Received on Tuesday, 25 October 2011 17:33:19 UTC