Re: [css3-variables] review comments on latest draft

On Mon, May 21, 2012 at 10:56 PM, John Daggett <jdaggett@mozilla.com> wrote:
> Looking over the CSS Variables ED again, I have a few questions/comments.
>
> * var-foo, var(foo) syntax
>
> The more and more I look at this, I think the choice of the prefix-
> syntax is not a good one.  All CSS properties are named as
> indivisible, hyphen-separated entities, I don't think making a syntax
> where properties with a given prefix are magically separable is a
> great idea.

Yes, given my desired change of using "$foo" as the var use syntax,
I'd like to sync this with the definition syntax and use "$foo: blue;"
as well.


> * variable names
>
> You don't really define what the set of possible identifiers is allowed to be.
> For example, are the variables definitions/uses below valid?
>
>  var-inherit: red;
>  var-initial: larger;

Tricky.  Depends on exactly what syntax we end up with.  Under the
current "var-foo / var(foo)" regime, I'd want to disallow those names.
 Under the "$foo everywhere" regime, they're perfectly fine.

>  var-\-\-foo: red;  /* tossed as invalid? */
>  color: var(\-\-foo);

"\-\-foo" is a legit identifier.  Nothing wrong with those.


> Given the variable with the invalid ident syntax above, are these the
> two declarations below equivalent?  Just to be especially evil...
>
>  font-family: bar var(\-\-foo); /* doesn't match var ( ident ) syntax */
>  font-family: "bar var(--foo)";

"\-\-foo" is an ident, but "--foo" isn't (it produces a DELIM followed
by an IDENT).


> * variable value definition
>
> I think you explicitly need to define what 'initial' and 'inherit'
> mean in the context of var-* properties.  Are they simple values
> assigned to that variable or are they the standard keywords with their
> normal meaning?
>
>  p {
>    var-family: sans-serif;
>    font-family: cursive;
>  }
>  span { var-family: inherit; }
>
>  p > span { font-family: var(family); }
>
> Do spans with paragraph elements use sans-serif or cursive?

Yeah, I probably need to make this clearer.  I lean toward keeping the
general rule of "variables aren't interpreted at all except to replace
other var references", so they aren't replaced at specified-value
time.  Then, when they get expanded into a property, they'll have
already missed the expansion opportunity (initial/inherit expansion
happens at specified-value time, variable expansion happens at
computed-value time), so it just makes the property invalid.


>> The valid possible values of a variable property are almost
>> completely unrestricted. A variable property can contain anything
>> that is valid according to the value production in the CSS Core
>> Grammar. The values do not have to correspond to any existing CSS
>> values, as they are not evaluated except to replace variables
>> occurring within them until they are actually referenced in a normal
>> property with a variable.
>
> So are user agents required to do some form of validation on these
> values?  And is the value production really the one you want to use
> here, that allows all sorts of stuff that I can't see being valid
> anywhere at use time.

I've updated the draft with my proposal for the var syntax.  It's
pretty simple, and allows every CSS value, and plenty of non-CSS
values (for the JS-based use-cases).


>> This specification reserves the use of all function tokens starting
>> with the prefix "var" within variable properties. Authors must not
>> use any such functions except as defined in this specification or
>> future updates. If a variable property contains such a function, it
>> must match the grammar defined in this specification or future
>> updates; the use of such a function that does not follow the
>> grammar, or that utilizes such a function that is not yet defined,
>> makes the variable property invalid and it must be ignored.
>
> Er, how do I construct something today that follows something in the
> future?  Time travel required? ;)
>
> Are you saying here that this spec effectively disallows the use of
> var-xxx as an identifier?  How would an author "use any such function"
> in today's CSS (as opposed to some future version of CSS)?

Yeah, it reserves that class of function names, but not general identifiers.

Using a function of that form that's currently undefined in CSS would
be a syntax error *anyway* in a regular property.  I'm just making it
explicitly invalid in a variable property as well.


> I also think you need to define the value declaration in terms of CSS
> tokens, since this is effectively a way of substituting CSS tokens from
> one place to another.
>
> For example, are escaped entities passed through?
>
>  var-optical-size: \10pt;
>  font-family: Modern var(optical-size); /* invalid? */

Yup, done now.  That escape sequence produces an IDENT, not a DIMENSION.


> * value use
>
>> A variable can be used anywhere a value is expected in CSS.
>> Variables can not be used as property names, selectors, or anything
>> else besides property values - doing so either produces an invalid
>> value or, in some situations like the attribute value of an
>> attribute selector, a valid value that nonetheless has no relation
>> to the variable of that name.
>
> I think you mean to restrict this to values within style rules, no?
> For example, the syntax below is invalid, right?
>
>  @font-face {
>    font-family: test;
>    src: var(foo);
>  }

Yes, sloppy wording on my part.


> * invalid variables
>
>> When a variable property has its initial value, a ‘var()’ function
>> referencing that property represents an invalid variable. Using an
>> invalid variable in a property value makes the declaration invalid
>> at computed-value time.
>>
>> A declaration that is invalid at computed-value time results from
>> either using an invalid variable in a property value, or using a
>> valid variable that produces an invalid declaration when it is
>> substituted in. When this happens, the declaration must compute to
>> the property's initial value.
>
> This ends up changing CSS semantics in some fairly subtle ways which I
> think you should explicitly note.  Specifically, invalid declarations
> with variables behave differently from invalid declarations without:
>
> /* without variables */
>
> p        { color: blue; }
> p > span { color: 3px;  }  /* invalid ==> color == blue */
>
> /* with variables */
>
> :root    { var-span-color: 3px; }
> p        { color: blue; }
> p > span { color: var(span-color); }  /* invalid ==> color == black */

Makes sense.  I'm cool with changing the behavior to be either initial
or inherit based on the property.


> * CSSOM
>
>> Variable properties are ordinary properties, and can be read or
>> modified using all of the existing CSSOM APIs for reading or
>> modifying properties.
>
> So getPropertyValue returns what value for "var-foo" if 'var-foo' is
> never declared?  It *always* returns 'invalid' for var-* if the
> variable hasn't been defined?

Yes.

~TJ

Received on Friday, 25 May 2012 18:30:36 UTC