W3C home > Mailing lists > Public > www-style@w3.org > May 2015

Re: [css-variables] var() for non-custom properties

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 22 May 2015 09:16:39 -0700
Message-ID: <CAAWBYDB=ajaRZ3t3V37KrAsCXtjHETmCO16Yzv6-P4CP7VKyAg@mail.gmail.com>
To: Fran├žois REMY <francois.remy.dev@outlook.com>
Cc: Bang Seongbeom <bangseongbeom@hotmail.com>, "www-style@w3.org" <www-style@w3.org>
On Fri, May 22, 2015 at 7:21 AM, Fran├žois REMY
<francois.remy.dev@outlook.com> wrote:
>> Is there some reason that var() can not be used for non-custom properties?
> It depends. If you want to use the computed value of a property, you'll be
> out of luck, because that would create inadvertent cycles. Think about:
>     ELEMENT {
>         width: var(padding-left);
>         padding-left: 50% /* of the width */;
>     }
> If you want the specified value, the previous example would work but provide
> the surprising
>     ELEMENT {
>         width: 50%;
>         padding-left: 50% /* so 25% of parent bfc's width*/;
>     }

Yes, this is the main reason we don't and won't allow this.

>> Except shorthand, it would be a good idea.
> And this is the second issue.
>     ELEMENT {
>         border-left-width: 10px; /*overriden*/
>         border-width: 5px;
>         width: var(border-left-width); /* would have to be 5px, but that
> means we resolved border-width. okay, hold on */
>     }
> Not let's suppose that we did this instead:
>     ELEMENT {
>         border-width: 5px;
>         border-left-width: 10px;
>         width: var(border-width); /* even if this was valid, this means we
> have to reconstruct the shorthand, which is hard */
>     }
> Now the issue is that any propery can become a shorthand at some point. See
> for instance display which could have been divided into "display-inside" and
> "display-outside" and that would make old code break if the browser engine
> doesn't do a lot of work to make things up for it.

This isn't really an issue.  Shorthands are expanded at declared-value
time, right at the very beginning.  Reconstructing a shorthand from
longhands isn't always possible, which is an issue, but resolving a
longhand that has been specified multiple times, some by the explicit
longhand and some by shorthands, isn't problematic.

> That why it was ruled out. Even if this is possible in theory, this requires
> too much work to be worked out by browser vendors. Just do this instead:
>     * {  border-width: var(--border-width)  }
>     ELEMENT {
>         --border-width: 5px
>         width: var(--border-width);
>     }

Yes, this is the recommended practice.  Just move the property value
into a variable, and then use that in both places.  That avoids all
possible problems and is possible today.

>> We're already using a similar mechanism such as var() for non-custom
>> property; currentcolor.
> We should definitely introduce more keywords like this for things that could
> be safely expressed this way. I would love to have currentBackgroundColor
> for instance.

The issue is "safely"; we want to avoid computed-value dependencies
when possible.  Color stuff probably is generally safe, but there's
also not a ton of value over just using a variable in both
background-color and whatever you want to share background-color with.

Received on Friday, 22 May 2015 16:17:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC