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

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.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)