RE: [css-syntax] value grammar, <value> type and browser implementations

> It looks to me like the only things forbidden inside of a block
> inside of a value by
> http://www.w3.org/TR/CSS21/syndata.html#tokenization are:
> 1. unmatched }, ], and )
> 2. {, [, and ( without a matching pair later
> 3. BAD_STRING, BAD_URI, and BAD_COMMENT
>
> Is the intent of your comment to suggest that (2) and (3), that is,
> opening constructs that don't have a matching closing construct,
> should be allowed within value?
> 
> Or are there other differences that I'm missing?

I was actually working with a wrong grammar in mind (confused block and ruleset, for some reason), resulting in mistakes in some of my examples. {a} and {;;} are indeed valid values.


However, my initial problem is that Webkit and Trident actually reject valid custom properties declarations for some reason (I guess they parse the values according to CSS 2.1 but actually validate them against the informative grammar found in Appendix G [1]). This is my initial and most important concern, and we should probably to get that right. If FireFox only checks that the open-close tokens have a match, it seems fine to me.


My take is: we should accept any value as long as it doesn't contain any ';' and '}' at top-level, because those tokens are used to close the value production. I'm not against allowing unmatched closing tokens (your (1)) for instance. I believe Tab has the same general point of view, so I'm fine letting Tab resolve the problem the way he intended. 


I just have one other question, and this time about serialization. It's fine if browser do accept any value, but is there any spec that says how the 'element.style.myCustomProperty' will be serialized if it contains a particular input? Is it kept as-is or is it reserialized the same way JSCSSP is doing?

For info, JSCSSP is returning '{ a : a }' from a '{a:a}' input (so it separates each token by a whitespace even if it is not necessary, and doesn't preserve white spaces). I must say I've a preference for 'serialized as in input' but I can understand browser prefer to keep tokens only and reserialize back the entry each time it's requested.


[1] http://www.w3.org/TR/CSS2/grammar.html

Received on Wednesday, 6 February 2013 10:26:01 UTC