RE: background shorthand serialization issues

> From: L. David Baron [mailto:dbaron@dbaron.org]
> Sent: Wednesday, June 16, 2010 12:16 PM


> I don't think this is really what we want to specify.  (It's also
> the first I've heard of this.)  It adds semantics to something that
> previously didn't matter.
> 
> It might make sense to specify it that way for "future" drafts.
> However, before specifying it that way for existing ones we should
> compare to existing implementation behavior and to the results we
> think are preferred.

Using the one value ordering that is written down in an authoritative
document seems a natural guideline in the absence of any other but I I'm not 
comfortable specifying this either. I don't think the arbitrary order or a 
syntax definition should be coupled to OM serialization, especially when the 
former specifies that any order is allowed. 

Nor am I so clear on the scenarios and benefits. I understand it'd be nice for 
Javascript developers to know what kind of value format to expect for a given 
CSS property across browsers but unless we were close enough to interop across 
a wide range of properties and implementations to justify the short-term reward, 
I'd be more interested in discussing an OM that does not require web authors to 
parse "100px" to add 50px before serializing back to a string. As browsers have 
already parsed these values, returning strings to web apps just so they can reparse 
them seems increasingly painful.

Anne started that discussion at the last TPAC by building on an older proposal
from Hixie. I'd love to hear more about this at the next f2f and see if we can
come up with a plan to make progress ? 

(And if there are other significant benefits to normalizing OM property serialization 
- including for shorthands - my apologies if I missed or misunderstood them)

Received on Wednesday, 16 June 2010 19:56:13 UTC