- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 20 Nov 2014 10:14:50 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
- Cc: "www-style list" <www-style@w3.org>
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