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

On Fri, Jan 30, 2015 at 3:07 AM, Simon Pieters <simonp@opera.com> wrote:
> On Thu, 29 Jan 2015 20:03:24 +0100, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> 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.
>
>
> Yes, but they're stored differently in at least some implementations. If we
> say that 'opacity' can only be serialized up to three digits, it will not be
> equivalent to rgba() since 'opacity' will be able to serialize 1001
> different values but rgba() only 256.
>
> We could limit to 6 digits like IE/Gecko but say that values less than
> 0.0000005 must serialize as 0, which avoids serializing sci-not (and
> limiting digits there), and so masks all(?) float->double rounding errors.
>
> Possibly the spec could have different strategies depending on how it's
> stored, and not tie it to rgba() vs. opacity.

I don't think the difference between representing 256 and 1001 values
is significant.  I'm fine with the algorithm popping out slightly
different results.  Or else we can specify that <alphavalue> is
converted to a byte for the purpose of serializing, if we really want
to be identical.

Letting opacity go to 6 digits just because it's capable of accurately
representing that many doesn't seem very useful.  That much precision
is never useful in the first place; you can only barely tell the
difference between .01 increments, let alone .001 increments.

But this also isn't very important, and so matching IE/Gecko is fine.

~TJ

Received on Friday, 30 January 2015 19:16:42 UTC