Re: [css-variables] CSS Custom Properties L1

| First, I agree with calling this module Custom Properties rather than
| Variables, to mark the distance from preprocessor variables and the
| similarity with other properties (declarations, inheritance, ...)
|
| Other parts of the proposal should be discussed separately. I don’t want
| a change that might have been accepted to be rejected just because it
| was proposed together with other changes that were rejected.

That's a fair point. However, it was pointed out that a more coherent 
proposal may help to get there. Brian and I surely wouldn't reject any 
change in the official spec that goes in the direction of the ideas we 
promote. This is clearly not a 'take-all-or-dismiss' proposal.



| I think that [token stream] is useful not only here, but also at the
| boundaries between:
|
| * css3-syntax and selectors
| * css3-syntax and css3-values (and the value definition of each property)

This is the reason why it was initially introduced. However, this is not a 
'sexy' concept ^_^



| The concept of "provider" was unclear to me until I read the two
| examples of '$' and '$parent'. (Even in the actual text, not just in
| this diff!) Maybe another name would be better but I don’t know which,
| sorry.

The whole prose is maybe the issue here. I actually made that change today 
in response to a Brian comment; the previous prose was even worse. This part 
still has to mature.



| border: green solid; /* valid */
| border: green red; /* invalid */
| border: $(my-color, green) solid; /* valid if the fallback is used */
| border: $(my-color, green) $(my-style, solid); /* ??? */
|
| Is there a combinatorial explosion of the number of
| fallback/non-fallback combinations that need to be checked?

No. The only checked combination *at declaration time* is the fallback one. 
The actual value of the reference is unknown until computation time, so it 
can't check anything else. There's also a note saying that if any reference 
don't provide a fallback, the declaration is automatically valid since it 
can't be checked.

Validation *at computation time* is handled by the corresponding section of 
the spec, and only take in consideration the final value of the property. 
This has not changed compared with the current draft.



| In other words, the computed value of any property must be
| compatible/valid as a specified value. This starts to matter if the
| restriction on references is lifted.

Good question. I would argue that any CSS value should match the <value> 
type already. If however it wouldn't be the case, I think the prose says the 
token stream is invalid. If the problem is that it could break author 
expectation, I would say that this is unfortunate and should be fixed in the 
corresponding spec.

Please also note that "When inheritance occurs, elements inherit computed 
values. The computed value from the parent element becomes both the 
specified value and the computed value on the child" which set a precedent.



| * Make the parentheses optional when there is no fallback
| * Maybe drop providers and hard-code $parent as special function?

We used it initially but rejected it as you cannot know if 'parent' is a 
function name of an identifier following the $ sign before time. However, it 
could be specified that if there's a parenthese after the identifier, it is 
a provider and if there's no, this is a shortcut for the default provider. 
But this is ugly.

I actually like the $() syntax because this is not so complex to type and if 
you need to add a fallback value later one, this is as easy as inserting it. 
You don't need to add the parentheses in addition. But this is something I 
saw after the change was made to our spec, actually.



| The current draft is more consistent:
| $foo   var($foo, fallback)   parent-var($foo, fallback)

This not consistant at all. Imagine the following case :

{
    my-x: 3;
    my-y: calc($my-x * 3);
    my-z: var($my-x, 3);
}

Also, the $ symbol is used in conjunction with braces in languages like PHP, 
BASH and POWERSHELL when more options are needed, which is the philosophy 
here.



| [about $declared(...)]
|
| If being inherited or not is not intrisic to the property, it becomes
| required for UAs to keep around all "cascade values" as well as
|specified values. (Using CSS21:6.1 terminology.) This may have a
|non-trivial memory cost.

I honestly don't know. This is too far in the implementation level for me.



| [about $attr()]
|
| So the attribute value would go through the CSS tokenizer? It could have
| comments, backslash-escapes and everything?

This is the idea. However, it don't have to go through the full tokenizer 
because, to be valid, the stream has to conform to the <value> type.

Received on Thursday, 21 June 2012 20:32:29 UTC