- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Tue, 24 Jun 2008 23:27:58 +0200
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, www-style list <www-style@w3.org>
Håkon Wium Lie wrote:
> Also sprach Maciej Stachowiak:
>
> > >>> style sheet 1: @variable { X: 10px }
> > >>> style sheet 2: @variable { X: none }
> > >>> style sheet 3: div { width: var(X) }
>
> > Your above situation is analogous to the following:
> >
> > style sheet 1: div.someclass { width: 30px; }
> > style sheet 2: div#someid { width: 10px; }
> > style sheet 3: div { width: 20px; }
>
> It's different because because the validity of the declarations is
> known at parse-time. Invalid declarations should be dropped, and not
> be visible in the DOM.
Both are perfectly valid Håkon...
The extended grammar for CSS variables says that width can take for
argument the new functional notation var(<arg>) where <arg> is an
ident. That's the case... You are speaking of an extra rule *outside*
of the CSS parser *or* you are saying the declaration of a variable
extends the CSS parser. If you have the latter in mind, that's certainly
a first in twelve years of CSS right ?
The problem you described is precisely like setting a illegal value
for a given property through the DOM : elt.style.visibility = "glass".
No, seriously, nobody here thinks of making the parser extensible by
variables declarations. So the rules above _are_ all valid and the only
option is value resolution after parsing. If you don't do that, then
you have constants, not variables. Because you will never be able to
assign again the variable's value since it's evaluated at parse time !
</Daniel>
Received on Tuesday, 24 June 2008 21:28:40 UTC