Re: CSS Variables Draft Proposal

Le 10/02/11 02:22, Tab Atkins Jr. a écrit :

> Requirements
> ------------
>
> **[[Copied from<http://disruptive-innovations.com/zoo/cssvariables/>,
> as they all still hold. ]]**
>
> 1. The definition of a variable and a call to a variable should be
> simple enough so web authors don't have to drastically change their
> existing stylesheets to take advantage of CSS Variables. Use case:
> remove all existing occurrences of a given value in a given stylesheet
> to replace them by a call to a single variable.
>
> 2. The definitions of variables should cross @import boundaries so
> variables can be contained in a standalone stylesheet and imported by
> all stylesheets needing them. Use cases: company-wide graphical
> charter for a set of corporate web sites; easy theming on a single
> template
>
> 3. The value of variable should be modifiable by script. Such a
> modification should instantaneously update the value of all properties
> calling the corresponding variable's value, possibly triggering
> changes in the rendering of the document.
>
> 4. Calls to a variable in the assignment of the value of a property
> should make the corresponding CSS declaration invalid in a
> non-conformant legacy browser, the CSS error handling rules allowing
> then a fallback to a regular CSS Level 2 rule.

5. All variable assignments and calls to variables should be modifiable
    through an extension of the CSS Object Model so stylesheets using
    variables can be loaded, modified and reserialized without loss.

> When producing the set of variables, browsers must track which
> variables depend on which.  If a dependency cycle is detected, all the
> declarations that contributed to the cycle are invalid.  For example,
> in this code:
>
> ~~~~
> @var $foo red;
> @var $bar $foo;
> @var $foo $bar;
> ~~~~
>
> The latter two declarations form a dependency cycle, and so are
> invalid.  A single variable named `$foo` is created, with the value
> `red`.  If you then delete the third rule, the second is no longer
> part of a cycle, so the `$bar` variable is valid and contains the
> value `red` as well.

You said above "all declarations that contributed to the cycle are
invalid". So the TWO last @var assignments are invalid. As a result,
$foo is red and $bar is undefined. But I really don't like this section.
See:

   @var $foo red;
   @var $foo $bar;
   @var $bar $foo;

Two last rules dropped, you say $foo should default to red. But that
will require preserving a stack of variable assignments since red is
lost when |@var $foo $bar;| is parsed... That one becomes invalid
only when the NEXT rule is parsed! Right after second rule, $foo
is assigned through a deferred rule targeting the value of $bar.

I think you have to clarify this section.

>
>
> Changes to CSS Grammar
> ----------------------
>
> To be completed with boring details.
>
>
> Object Model
> ------------
>
> Same as<http://disruptive-innovations.com/zoo/cssvariables/>  for the
> low-level, stylesheet-iterating form.
>
> For use by normal authors, I'll be proposing a new global object on
> `document` named `css`.  `css.vars` will contain a map of vars.  This
> map will reflect all valid vars in the global namespace, with the key
> being the variable's name, suitably transformed (see below), and the
> value being the current value of that variable.

In our (Hyatt and I) spec, variables were on a per-medium basis. That's
not the case of your proposal. I see some pros and some cons. Not sure
I like your choice. I think $foo should be allowed to have one value
for screen and another one for print. Or one for a given media query
and another one for another media query...

More to come later, I have an early meeting.

</Daniel>

Received on Thursday, 10 February 2011 06:32:19 UTC