Re: CSS Variables

Le 06/02/11 01:34, Tab Atkins Jr. a écrit :

> theming webpages and webapps, both large and small.  I and some other
> Chrome engineers have put together a proposal for variables that is
> very similar in nature to what glazou proposed in
> <http://disruptive-innovations.com/zoo/cssvariables/>  (the syntax is a
> bit different, but that's mostly a bikeshedding detail).

Hyatt and glazou, to be more precise.

> 1. Variables are mutable.  You can have multiple declarations of the
> same variable in a stylesheet, and the last one wins, per normal CSS
> tradition.  You can change variables using the CSSOM, and the updated
> value will flow through all the uses of the var.

Please detail how variables are affected by media declarations. What
are the values here for color and background-color on a screen ?

   @var $foo red;
   @media screen {
     @var $foo yellow;
     color: $foo;
   }
   @media screen, print {
     @var $foo blue;
     background-color: $foo;
   }


> 2. Variables are document-global.  Once defined, they can be used in
> any stylesheet on the page, preceding or following, @import'd or just
> linked in separately.

Fine by me. It will make web authors' life easier since they'll be
able to link to a "corporate" or global stylesheet and use the
defined variables w/o having to replicate the assignments in their
own stylesheet. Any other option is from my perspective a no-go.
But please understand it adds a cycle to style engines if a variable
is used but not defined yet in a stylesheet... The style engine will
need to cycle if the variable assignments happen AFTER the variables
are used.

> 3. Variables respond in the obvious way to dynamic changes.  Adding a
> var (whether through the CSSOM variable map, adding a new @var rule
> directly to a stylesheet via the CSSOM, or adding a new stylesheet to
> the document) enables use of that var everywhere.  If a var is used
> before it's defined, adding a definition later will make all uses
> suddenly work.  Removing vars with any method will either fall back to
> a previous definition for that name, if one exists, or just make all
> usage of that variable invalid.
>
>
>
> The syntax isn't complex.  What we're going with so far is this:
>
> @var $foo red;

I don't understand that $ at all and I think it is useless. Just make
the first parameter following @var an ident and that's enough. Using
$var to ACCESS a variable is fine, modulo the impact on parsing. I admit
I haven't thought at it yet. Thinking out loud, I think the var()
notation is better because more conformant to CSS's common practice.
It will also be easier to implement.
I don't think the preprocessing-on-server-side argument is a good one.
The purpose of a Variables spec is to obsolete such preprocessing
anyway.

> The @var rule declares a single variable, taking a name and then
> arbitrary CSS as a value.  The var name must start with a $ character,
> so we can use $ as an unambiguous indicator in the content that a
> variable is being used.
>
>
> CSSOM access is done through the global vars map, like so:
>
> console.log(css.vars.foo); // logs "red", given the above
> css.vars.foo = "blue"; // Everywhere $foo is used is now "blue".

That's where it becomes tricky. So you're suggesting a new global
object called "css". It's then "window.css"... I think "document.css"
is more reasonable, for many reasons. Anyway.

You will have to detail how document.css.vars is populated. Example:
I set a variable through |document.css.vars.foo = "blue"| and THEN
add a document a link element loading a stylesheet itself defining
the foo variable. I suppose your answer will be "no problem, the
stylesheet will override the dynamic assignment". Ok, but it has
to be specified.

You will also have to clearly detail the security considerations.
What happens if I set a variable in my stylesheet to a string containing
eval() of some JS, for instance (just thinking out loud).

The assigned value of a variable has probably to be a term (Cf. CSS
grammar) or a white-space separated list of terms.

> This example supposes that there is a global css object defined on
> document (also on window, forwarding to document.css) that gives

Not sure this forward is needed or even reasonable.

> I believe this model of interaction is enormously simpler than what
> was in glazou's proposal, which would require a script to grovel
> through all the rules in all stylesheets to find var rules, and use
> verbosely-named functions to alter them.

The model in our (Hyatt and myself) proposal is **absolutely** needed
for authoring tools. If variables can be accessed but not authored,
you'll create massive issues for web authoring tools. We **must** have
a way to create/edit @var rules in the CSS OM of a given stylesheet.
I will not accept a proposal that's not meeting this requirement, sorry.

> This model is also easily extensible for when we get the CSSOM
> improvements that allow type-based manipulation of values.  To enable
> the CSSColor interface on a var, for example, declare it like so:
>
> @var color $foo red;
>
> Or set it in script like so:
>
> css.vars.foo = new CSSColor("red");
> // strawman syntax, don't pay any attention

Hmmm... No need to bloat the global namespace here. Isn't

   document.css.vars.foo = new document.css.Values.Color("red");

better? You can even used that to translate "red" into rgb() or #
notations if the string is needed.

Let me conclude : your proposal is made of two things. First a new
proposal for Variables. I find it incomplete since it does not address
authoring tools' requirements. Second, a massive change of the CSS OM
(and I welcome that since the current one is a mess) that requires a
lengthy spec. Not a problem, but we need something well architectured
here. I'm fine with your "document.css" but we probably need to write
down the requirements before designing anything. I am willing to help
here.

</Daniel>

Received on Sunday, 6 February 2011 11:33:31 UTC