- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Sep 2017 00:03:23 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `@font-face unicode-range and first available font`, and agreed to the following resolutions: * `RESOLVED: Change spec text to read first available font that would match the U+0020 (space) character` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: @font-face unicode-range and first available font<br> <dael> Github: https://github.com/w3c/csswg-drafts/issues/1765<br> <dael> myles: fremy do you want to take this?<br> <dael> fremy: Basically one dev on our team impl unicode range for font face and realized if you want to follow spec you compute based on first available font tha tmatches any character. So any font could be that and you need to download every font which defeats the purpose. All browsers only care about hte space character. Proposal is to reflect that in spec so first available fon tis the one that would match the space character<br> <dael> fremy: Shouldn't be controversial.<br> <dael> fantasai: I don't think intention is first fon tot match every character, it's any character. So if the font has that character in it. The impl seem to be using the space.<br> <dael> myles: The spec says "any characteR" or proposal is to change to read "thhe spacce character"<br> <dael> fremy: Correct.<br> <dael> myles: Fine with us.<br> <dael> s/or/so<br> <fantasai> s/space/space assuming that a font that includes any glyphs at all will at least has one for U+0020/<br> <dael> TabAtkins: It implies first font that doesn't have a unicode range or has one so that doesn't mean anything how it's written. So, sure. If space is what people are relying on it's not a bad choice.<br> <dael> Rossen_: Do we have a proposal?<br> <dael> fremy: Proposal is the first available font that would match the U+0020 (space) character<br> <dael> Rossen_: Webkit is fine it sounded like. Obj to this proposed change?<br> <dael> myles: Not an obj, but this text is in both fonts 3 and 4 so this will go into both.<br> <dael> fantasai: I'm not sure that is actually the issue. It seems to be a side effect.<br> <dael> Rossen_: What is the actual issue?<br> <dael> fantasai: I think the interesting thing here is that...<br> <dael> fantasai: The issue is talking about a font that has glyphs that don't match its unicode range so it has no glyphs that will be used, but i'ts used as first available font. Should that font not be used in the font list because it will never be used.<br> <dael> fremy: Main reason is we don't want to change the font unit when we change the font. It does not depend on contents.<br> <dael> fantasai: Question is regardless of the content you define a font that doesn't have any glyphs. The overlap is 0 glyphs. No soace, no character. Should that be used for the definition and that's not clear.<br> <dael> TabAtkins: Problem is you have to then download fonts speculatively. And that's an author error. If you say it covers a certain range we should believe you.<br> <dael> fantasai: If that's the case and we're saying we'll base on unicode range, if we change this definition the unicode range has picked out hte characters that don't use the space so you wouldn't use the test font.<br> <dael> TabAtkins: But browsers do that.<br> <dael> fantasai: Edge and chrome are different.<br> <dael> TabAtkins: Blink and webkit are same.<br> <dael> fremy: Edge doesn't support unicode range right now. When we tried to fix we ran into this.<br> <dael> Rossen_: I'm going to go back to proposed resolution and as if there are any alternative proposals and, if not, we can take that text to both fonts 3 and 4. Which means 3 resets CR<br> <dael> fantasai: Do we have anyone from Mozilla or results from them?<br> <dael> Rossen_: Sounds quiet.<br> <dael> Rossen_: I don't think we have anyone.<br> <dael> fantasai: I'd suggest we get feedback.<br> <dael> Rossen_: We can resolve tentatively.<br> <dael> Rossen_: We have 3 impl. We can take a resolution and go back if there's more evidence.<br> <dael> fremy: On the text case FF behaes same as chrome and safari.<br> <dael> Rossen_: Objections to changing text to read "first available font that would match the U+0020 (space) character"<br> <dael> fantasai: I'm getting different results on FF then on chrome<br> <dael> fantasai: In FF all 3 red boxes are same height. Chrome has the middle shorter.<br> <nainar> shans, ericwilligers and I had to drop out. We have another meeting. Thanks everyone!<br> <dael> Rossen_: Linux?<br> <dael> fantasai: Yes.<br> <dael> fremy: On windows it's the same. If it's not ariel then the test case doesn't work.<br> <dael> fantasai: I think it would be good to find out what mozilla is doing.<br> <fantasai> I have Arial installed<br> <dael> Rossen_: Mozilla will have the ability to re-raise. In the presense of new information we can reconsider.<br> <dael> RESOLVED: Change spec text to read first available font that would match the U+0020 (space) character<br> <Rossen_> https://github.com/w3c/csswg-drafts/issues/1777<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1765#issuecomment-327644757 using your GitHub account
Received on Thursday, 7 September 2017 00:04:53 UTC