Re: [cssom] Serializing non-opaque colors, background-position keywords

On Wed, Jan 28, 2015 at 2:10 AM, Simon Pieters <simonp@opera.com> wrote:
> Hello!
>
> Josh Matthews contributed some CSSOM serialization tests for
> web-platform-tests which uncovered some issues:
>
> https://critic.hoppipolla.co.uk/r/3307
> http://w3c-test.org/submissions/1427/cssom/serialize-values.html (remove
> submissions/1427/ if this 404s)
>
> The CSSOM spec needs work in general around serialization, so these aren't
> questions of "what does the spec say now?" but rather "what do we want the
> spec to say?".
>
> == Non-opaque colors ==
>
> How should color: rgba(5, 7, 10, 0.9) be serialized? Gecko round-trips alpha
> as 0.9 but Blink makes it 0.901961. I think Gecko faithfully round-trips two
> decimals for colors. Should we specify Gecko's behavior of rounding to a
> "nicer" number?

We store alpha with the same resolution as the other channels, as a single byte.

We could maybe round to the nearest .01 for serialization (which will
always round-trip values of that precision), but I doubt we'd want to
expand our precision, as it currently allows us to store a complete
color in an int32.

(Or we could do what Boris suggests, and return two or three digits, depending.)

> Similarly for 'opacity' (although that is represented with higher precision
> I think).

I would be totally fine with specifying that opacity must be
serialized with 2 or 3 digits.

> == background-position keywords ==
>
> How should background-position: 0% top be serialized? For element.style,
> Gecko round-trips keywords, Blink converts to percentages. For
> getComputedStyle, both convert to percentages. I think the spec for
> background-position says keywords compute to percentages.

I'm fine with either percentages or keywords, as long as we don't have
to remember which was specified and return it.  In other words, I'm
okay if "top" always becomes 0%, or 0% always becomes "top" (or
"left", whatever), but I'm not okay with 0% becoming 0% and "top"
becoming "top".

I lean slightly towards percentages, though, as that means the
serialization doesn't suddenly change at a few magic values.

~TJ

Received on Wednesday, 28 January 2015 18:53:44 UTC