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

[css-variables] using variables in shorthands

From: Florian Rivoal <florianr@opera.com>
Date: Fri, 09 Mar 2012 16:35:57 +0100
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.wawtl7gd4p7avi@eeeflorian>
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 Friday, 9 March 2012 15:32:06 GMT

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