W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [css-variables] using variables in shorthands

From: Shane Stephens <shans@google.com>
Date: Sun, 11 Mar 2012 20:05:15 +1100
Message-ID: <CAGTfzwTfJyXE31p8hGmo37b9jc4zN=m4YQtHX=824=Q1HhRVeg@mail.gmail.com>
To: Florian Rivoal <florianr@opera.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Hi Florian,

I don't think variables should be able to encode multiple values (like
1em 2em or 1em 2em 3em 4em), because these are a nightmare to type (as
in type check, not type out). So cases 1-3 that you present have an
unambiguous resolution:

{margin: data(foo)} -> {margin-top: data(foo); margin-right:
data(foo); margin-bottom: data(foo); margin-left: data(foo)}
{margin: data(foo) data(bar)} -> {margin-top: data(foo); margin-right:
data(bar); margin-bottom: data(foo); margin-left: data(bar)}
{margin: data(foo) data(bar) data(baz) data(faz)} -> {margin-top:
data(foo); margin-right: data(bar); margin-bottom: data(baz);
margin-left: data(faz)}

The other two cases are somewhat serious :)

Cheers,
    -Shane


On Sat, Mar 10, 2012 at 2:35 AM, Florian Rivoal <florianr@opera.com> wrote:
> Hi,
>
> I am seeing a big issue with variables that I had not noticed before. They
> seem to work very poorly with shorthands.
>
> The specified value of a shorthand is used to determine the specified
> value of the corresponding longhands, and that may be done in different
> ways, but never depends on the cascade. Here are a few examples:
>
> 1) Repeat the value
> {margin:1em} -> {margin-top:1em; margin-right:1em;
> margin-bottom:1em; margin-left:1em}
>
> 2) Dispatch parts of the value
> {margin:1em 2em 3em 4em} -> {margin-top:1em; margin-right:2em;
> margin-bottom:3em; margin-left:4em}
>
> 3) Dispatch & repeat parts of the value
> {margin:1em 2em} -> {margin-top:1em; margin-right:2em; margin-bottom:1em;
> margin-left:2em}
>
> 4) Dispatch to a different longhand depending on the value:
> {background:#ffffff} -> {background-color:#ffffff; background-image:none;
> ...}
> {background:url("foo.png")} -> {background-color:transparent;
> background-image:url("foo.png"); ...}
>
> 5) Map different keywords
> {white-space:pre} -> {text-space-collapse:preserve; text-wrap:none}
>
> When a variable is used as the value of a shorthand, you would need to
> know its value at specified time to be able to set the longhands, but
> variables are resolved at computed time.
>
> There are a couple of ways to try and deal with this:
>
> You could say that using a variable in a shorthand is always invalid, and
> that this declaration should be dropped. This is simple to implement, but
> not overly friendly to authors, especially if you consider that we
> sometimes turn regular properties into shorthands (eg: white-space).
>
> Or you could say that the specified value of all longhands is the same as
> the shorthand's when it involves a variable. That is still simple to
> implement. It wouldn't always work, but sometimes it would. For instance
> 'margin:data(foo)' would mean that every margin-* longhand would also be
> data(foo), which would be what you want if data(foo) later resolves to a
> single length. On the other hand, it wouldn't work if data(foo) resolves
> to two space separated lengths. It would also work for
> background:data(foo) if data(foo) resolves either to a color or an url,
> but not if it resolves to both.
>
> Would authors prefer reliably useless, or unpredictably useful? I am not
> sure they'd be happy with either.
>
> The third alternative I can see is to say that when a shorthand uses a
> variable, the corresponding longhands do not have a specified value (or
> have a magic specified value, maybe called 'unknown'), and get their
> computed value from the computed value of the shorthand. I believe this
> would give the computed / used values that match what the likely intuitive
> understanding of authors. But that would mean profound changes in
> implementations, and is not compatible with CSSOM, since specified styles
> are exposed, so I don't think this is really an option either.
>
> Am I missing something? Does anyone have a better solution? I am left with
> the impression that the variables proposal has a fundamental
> incompatibility with shorthands.
>
>   - Florian
>
Received on Sunday, 11 March 2012 09:05:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:51 GMT