Re: Better Variables through Custom Properties

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