RE: [CSSOM] some feedback on serialization

> 6.6.2
> # <angle>
> # The number of degrees serialized as per <number> followed by the
> literal string "deg".
> # <length>
> # A length of zero is represented by the literal string "0px".
> # <time>
> # The time in seconds serialized as per <number> followed by the
> literal string "s".
> 
> I think this is a bad idea.
> 
> If the input has units, then the original units should be retained in
> the serialized output.
> If the input does not have units, then there should be no units in the
> serialized output.
> 
> 6.6.2.1
> # Before			After
> # color: rgb(18, 52, 86)		color: #123456
> # color: rgba(000001, 0, 0, 1)	color: #000000
> Once again preserving the authored value is strongly preferred, IMO.
> 
> Also, rgba should serialize as hash-prefixed six-digit hex when the
> alpha channel happens to be 1 but something else when the alpha channel
> is not 1?  AT best it's confusing.

One more note on these...

Forcing a specific unit on output is lossy, which is even more undesirable.

Angle:
Converting from turns to degrees can grow the value's string length such that it's no longer round-trippable.
Converting from radians to degrees can introduce all kinds of interesting round-tripping effects due to the "*180/PI" operation.

Color:
The value rgb(1%, 50%, 1%) is equivalent to rgb(2.55, 127.5, 2.55) which either becomes rgb(2, 127, 2) or rgb(3, 128, 3).  Either way, it's lossy.

Unfortunately there is no grammar in section 4.2.1 of http://www.w3.org/TR/css3-color/#rgb-color so now (after re-reviewing) I'm not as certain that the parameters to rgb and rgba have to be integers.  If they can include a decimal portion, then this issue vanishes.


While we're on the topic, it would also be good for the CSS3 color spec to make it absolutely clear if this should be rejected at parse time or not...
	rgb(1000%, 10000%, 100000%)
... and if valid how it should render.

>From the REC discussion around gamut, I get the vague notion that
	rgb(2550, 25500, 255000)
should be accepted and -- in most cases that I'll ever see (commodity/consumer monitors) it will be rendered the same as
	rgb(255, 255, 255)
but it's not totally clear to me that (a) that is fact or that (b) the % flavor example above should render the same.

If red, green, and blue channel values above 255 (and percentages value above 100%) should be rejected, I think that should be clearer in the spec.  If they *shouldn't* be rejected, then I have no idea how CSSOM expects to serialize...
	rgb(2550, 25500, 25000)
... into hash-prefixed six-digit hex.

Received on Friday, 19 August 2011 17:16:49 UTC