Re: Better Variables through Custom Properties

On Wed, Oct 26, 2011 at 11:41 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Monday 2011-10-24 16:39 -0700, Tab Atkins Jr. wrote:
>> Here's the same example, using a slight variant on Roland's suggested grammar:
>>
>> :root {
>>   data-main-color: #06c;
>>   data-accent-color: #006;
>> }
>> h1 {
>>   color: data(main-color);
>>   border-left: thick solid data(accent-color);
>> }
>>
>> In this simple case, two custom properties are set on the root
>> element.  They inherit down to the h1, where they are referenced with
>> the data() function.  Here I'm assuming that properties prefixed with
>> "data-" are "custom properties", which are valid but defined to be
>> meaningless, similar to the data-* attributes in HTML.
>
> Do all data-* properties inherit by default, or is there any
> provision for such properties that do not?  (I'm not sure if there
> needs to be; I'm just trying to understand what the model you're
> proposing is.)

My intention is that they all inherit by default.

I can think of two use-cases that non-inherited variables could help
with, though:

1. Use them as "local" variables for breaking up long expressions of
nested functions.  This is similar to the same situation in actual
programming languages when it is sometimes more readable to break an
expression apart into multiple temporary variables for readability.

2. Use them to avoid the already-noted problem that "donut"-style
components (like a message box, which can contain arbitrary content
that doesn't need to know it's inside a message box) can pollute the
variable space for their contents.  A careful author can use only
"local" variables and use the 'inherit' keyword to manually inherit
the values through their component.  The contents wouldn't receive the
local variable's value unless they explicitly asked for it via the
'inherit' keyword.  This requires non-inherited properties to exist in
a different "namespace" than normal data-* properties, like "local-*"
or something (which I expect we'd do anyway, since that's the cleanest
way to indicate a different behavior).

Neither of these cases are very strong, though, and I'm inclined to
defer handling them to a later level of Variables.

~TJ

Received on Wednesday, 26 October 2011 18:58:46 UTC