- From: Florian Rivoal <florian@rivoal.net>
- Date: Wed, 13 Apr 2016 09:31:00 +0900
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
> On Apr 13, 2016, at 07:09, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > On Tue, Apr 12, 2016 at 2:27 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >> Given unicode-range is already shipping >> http://caniuse.com/#feat=font-unicode-range >> I think #3 is a non-starter. > > You might have misread - #3 is explicitly backwards-compatible. It > requires UAs to support the old syntax, it just doesn't describe how > they would do so. As a UA implementor who has this on the roadmap, I don't like having a spec telling us to do something, without telling us how. All UAs would probably do fine at supporting the old syntax when it is correctly used, but I am much less confident that we'd all pick the same logic for error handling, and it is important that we all react the same way in the face of unknown/incorrect syntax. >> I would imagine that reparsing unicode-range tokens in order to make >> the selectors work would be easier than doing #1, no? Hanging onto >> unicode-range tokens would be a lot less memory than hanging onto >> numbers and dimensions, given they're used so rarely. > > Yeah, it just means we have to reparse them everywhere *except* unicode-range. Right, this feels ugly and error prone. - Florian
Received on Wednesday, 13 April 2016 00:31:30 UTC