W3C home > Mailing lists > Public > www-style@w3.org > August 2012

RE: [css-om][css3-conditional] spaces, newlines and rule serialization

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Sat, 25 Aug 2012 01:08:14 +0000
To: Glenn Adams <glenn@skynav.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178291BE2E8FD@TK5EX14MBXC227.redmond.corp.microsoft.com>
[Glenn Adams:]

>Not according to my testing [1]. I'm seeing three different behaviors from Safari 6.0, Opera 12.0, and FF 14.0.1 (current 
>downloads). This seems pretty inconsistent, and indicates to me that Web authors are effectively ignoring these differences 
>(by using their own normalization). Given this case, I think we have some leeway to choose which version we think is most 

I think I generally agree. IE9 even changed a large number of serializations to conform to the CSSOM draft of the time and the impact was extremely limited compared to the scope of the change. Longhand .style values are definitely parsed all the time. Shorthand values a lot more rarely, while the parsing of larger serialization construct often involves dedicated libraries or regular expressions that are designed to run across browsers.

But given a decade+ of incompatibility with very limited evidence of impact as well as general agreement about the long-term costs of a string-based API I just wonder why we need to make this a CSSOM priority at the moment. I am definitely in favor of documenting the OM, CSSOM-View, their interfaces and properties, semantics and behaviors. I would love to see interop on what getComputedStyle() returns as well as the serialization of basic data types. How large chunks of cssText serialize is something that can wait for later drafts imo. We should prioritize those things that will affect the larger number of developers, as those present the most opportunities as well as the highest compat risks. 
Received on Saturday, 25 August 2012 01:08:48 UTC

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