W3C home > Mailing lists > Public > www-style@w3.org > February 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 Feb 2013 09:14:54 -0700
Message-ID: <CAAWBYDA8rEC2QuqCD7wmDsOQvfd6Genehhk7GwhPBLuOJMM4vA@mail.gmail.com>
To: Fran├žois REMY <francois.remy.dev@outlook.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, Simon Sapin <simon.sapin@kozea.fr>, www-style list <www-style@w3.org>
On Wed, Feb 6, 2013 at 3:25 AM, Fran├žois REMY
<francois.remy.dev@outlook.com> wrote:
> 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 correct - the actual grammar we use to parse CSS is a
bastardized version of Appendix G.  David's written a bunch of tests
which we fail and will continue to do so until we fix our parser.

> 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?

Serialization is undefined. :/

> 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.

Yes, we don't keep around the original text, for good reason. But
JSCSSP's serializer seems slightly wrong.  Unfortunately, it's in a
way that doesn't matter for anything that isn't a custom property. ^_^

Received on Wednesday, 6 February 2013 16:15:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC