Re: [css-syntax] Dropping <number-token> representation, and its effects on <urange>

On Thu, 20 Nov 2014 02:52:34 +0100, L. David Baron <dbaron@dbaron.org>  
wrote:

> On Wednesday 2014-11-19 12:28 -0800, Tab Atkins Jr. wrote:
>> In the telcon today, dbaron expressed concern that the definition of
>> <urange> requires looking at the "representation" of <number-token>s
>> and <dimension-token>s.  (The "representation" of a numeric token is
>> the actual text used to write the number, including leading 0s,
>> leading + sign, original base and  exponent when using scientific
>> notation, etc.)
>>
>> I pointed out that storing the representation of numeric tokens is
>> already required, in order to implement the <quirky-color> production
>> from the Quirks Mode spec
>> <https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk>.  IE's
>> behavior distinguishes between "color: 123;" and "color: 000123;", but
>> FF/WK/Blink don't; both are treated as #000123, so we can maybe change
>> the Quirks Mode spec to not require the representation.
>>
>> So, that leaves us with three possible resolutions to the <urange>  
>> thing.
>>
>> 1. Leave it as it is.  This requires storing the representation on
>> every numeric token, which is a memory cost, but it lets us parse
>> <urange> precisely.  (The cost might not be as bad as all that.  If
>> you only store the representation when it's "non-obvious" (leading +
>> sign, leading 0, scinot) then the memory cost is *most* of the time
>> just a single null pointer per numeric token.  You can regenerate the
>> representation on the fly from "obvious" forms, so a helper function
>> can be used to make representation-retrieval easy when it's
>> necessary.)
>
> I'm ok with this, and I think I prefer it at this point.

Are you also OK with how the hashless hex color quirk is specified? Or  
would you prefer the spec to align more with Gecko/WebKit/Blink?

-- 
Simon Pieters
Opera Software

Received on Thursday, 20 November 2014 09:14:48 UTC