- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 8 Sep 2015 11:54:10 -0700
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style list <www-style@w3.org>
On Sun, Sep 6, 2015 at 5:46 PM, John Daggett <jdaggett@mozilla.com> wrote: > Tab Atkins wrote: >> It looks like Chrome and Firefox both implement the old DOM L2 Style >> definition. Can we just accept that and converge on that definition? >> The current spec appears to be fiction. > > It doesn't work to use the old DOM L2 Style decl because it doesn't > include unicode-range and you end up with weird font shorthand issues > that shouldn't exist. So, no, using the old definition is not > appropriate. Additionally, the parsing of the 'family' name is > different, since for the @font-face rule it's a single value and not a > list of names. Same for 'weight', the parsing is different. > > The mutation of @font-face rules in Firefox doesn't really work anyways. > I originally wanted to make this read-only but either you or Daniel said > it should be mutable. > > So I think this is simply a matter of an unimplemented but necessary > feature (as are many OM interfaces within CSS). It would be great if you > could push to get this changed within Chrome and I can suggest that > Firefox matches that. The .style object in Chrome has a unicodeRange property. I know there are serious issues with reusing the style object. I'm not arguing about the technical purity of this. I'm saying that all browsers that I've tested have a particular API shape, and it's fairly likely that sites depend on that shape, so we should probably accept that and just deal with the fallout. If you think it's possible to change the API shape to match the Fonts 3 draft, I encourage you to try it out in Firefox and report back; we'd be happy to match if it was compatible. But let's do this soon, please; I don't want Font Loading to match fiction. ~TJ
Received on Tuesday, 8 September 2015 18:54:56 UTC