W3C home > Mailing lists > Public > www-style@w3.org > January 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 29 Jan 2015 11:03:24 -0800
Message-ID: <CAAWBYDBAX-3GWeTpr-BFU8fYZnkL3f4RGwxcuqSfES7wQi=Ndw@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: www-style list <www-style@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Jan 29, 2015 at 3:43 AM, Simon Pieters <simonp@opera.com> wrote:
>>> 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.
>
> OK. Presto serializes at most 2 digits. Are people OK with that? Or is the
> Gecko/IE approach better?

I'd prefer rgba() alpha and 'opacity' to serialize the same way.  They
both use <alphavalue>, after all.

>>> == 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".
>
> OK. Why?

Because it requires more storage.  You have to remember whether it was
specified with a keyword or not.  In my preferred solutions, you can
always store it as a percentage, and then, if you're required to
serialize as keywords when possible, just do a check at serialization
time for that.

Also:

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

~TJ
Received on Thursday, 29 January 2015 19:04:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:57 UTC