Re: Better Variables through Custom Properties

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