Re: Better Variables through Custom Properties

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