- From: Brian Kardell <bkardell@gmail.com>
- Date: Tue, 25 Oct 2011 13:41:06 -0400
- To: Roland Steiner <rolandsteiner@google.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
I take it from Tab's "similar to the data-* attributes in HTML" that these are not HTML data attributes and would not be exposed in a writable way via DOM/script? On Tue, Oct 25, 2011 at 1:32 PM, Roland Steiner <rolandsteiner@google.com> wrote: > 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:41:34 UTC