- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 May 2018 16:32:04 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Unknown URL Fragment IDs in @font-face`, and agreed to the following: * `RESOLVED: if you have a fragID in @font-face src, and you don't` * `RESOLVED: If fragID is valid, but not found in the resource, skip as if couldn't load resource` * `RESOLVED: Add format() signifier for font collections, similar to variations` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Unknown URL Fragment IDs in @font-face<br> <fantasai> myles: You can have a font collection file, has several fonts in it<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/2566<br> <fantasai> myles: Individual fonts are identified with fragID<br> <fantasai> myles: If that name of the font doesn't exist in the file, what do we do?<br> <fantasai> myles: One is we throw out the whole URL, the whole URL is invalid<br> <fantasai> myles: The image() function does this<br> <fantasai> myles: Alternately, throw out just the fragID, use the URL as if it didn't have one<br> <fantasai> myles: Ends up pointing at first item in the collection<br> <fantasai> myles: In that case, if you click on document navigation to a missing fragID, you go to the top<br> <fantasai> myles: So we have precedent for both behaviors<br> <fantasai> myles: Today for browsers that don't understand, they will just use the first item in the collection<br> <fantasai> myles: regardless of fragID<br> <fantasai> myles: So already some places where we have this behavior<br> <fantasai> florian: Thing you mentioned last, in terms of what browsers do<br> <fantasai> florian: when they don't support this<br> <fantasai> florian: hints at consistency with that<br> <fantasai> florian: Won't have browser showing different fonts for non-obvious reasons<br> <fantasai> fantasai: But you'll have that already if fragID is valid<br> <fantasai> myles: If fragID is valid, new browsers will show ID's font, old browsers will show first font<br> <fantasai> myles: if fragID is invalid, then one of the options will make the new browsers have same behavior has same behavior<br> <fantasai> dbaron: One thing to think about is how similar are the fonts in the collection?<br> <fantasai> dbaron: If they're likely to be similar, then falling back to another font in the collection seems reasonable<br> <fantasai> florian: Especially browsers can be consistent with older browsers<br> <Rossen_> fantasai: concenred about the what if there'/s fragment id format that doesn't understand if it's useful as the next thing of the list?<br> <Rossen_> Say a frag id in a collection that it's not in the system, and the browser can't load it sisnce it doesn't understand it forx ex, an open type... can it fall down the list further<br> <Rossen_> florian: if the browser understands the syntax it would be good to fall back but if it doesn't..?<br> <fantasai> florian: Can we do both? If the format of the fragID is invalid, it treats as invalid, but if the fragID is missing then it loads and tries to find it and falls back to first font or whatever it can do<br> <fantasai> TabAtkins: What Florian said, about falling back to first font, that's very specific to collections<br> <fantasai> TabAtkins: It's not a behavior we can bake into general behavior for fragIDs<br> <fantasai> myles: Yeah, platform has different behaviors<br> <fantasai> TabAtkins: There's a different consideration for fragID you understand but can't find, and fragID you don't understand.<br> <fantasai> myles: These fragIDs are names, they're just strings<br> <fantasai> TabAtkins: That's assuming fragID sntax for truetype collections is the only format that will exist<br> <fantasai> myles: Two collection formats, both have this syntax<br> <fantasai> astearns: I thought we'd already established that browser that don't understand fragment syntax will use the URL as if it wasn't there<br> <fantasai> TabAtkins: We didn't establish that, it's just the current behavior of browsers<br> <Rossen_> q?<br> <fantasai> astearns: Any other comments?<br> <fantasai> florian: Can we distinguish?<br> <fantasai> florian: For collections is *any* string accepted, regardless of syntax e.g. parens and stuff included?<br> <fantasai> myles: Any string<br> <astearns> ack liam<br> <Zakim> liam, you wanted to ask about fallback when the vf is used in multiple @font-face rules (bold, italic) when it understands the 1st font<br> <fantasai> liam: Reason to use collections is to save bandwidth<br> <fantasai> liam: Can use it in a dozen different @font-face rules<br> <fantasai> liam: Need it to be first in your src list, can't save bandwidth if browser loads other things first<br> <TabAtkins> Per https://tools.ietf.org/html/rfc8081#section-4.2 the fragment is *not* an arbitrary string, it does a useful subsetting of "name-like" syntax, explicitly excluding things that might be functions/etc<br> <fantasai> liam: If bold-italic is first and regular is second<br> <fantasai> liam: It means your whole page will be bold-italic if you didn't understand the fragID<br> <fantasai> liam: and that's very unlikely to be acceptable<br> <TabAtkins> So `font.ttf#foo(bar)` is *not* a valid way to select a font from a collection. It's an unknown fragment.<br> <fantasai> liam: Seems no way to do fallback here, have the browser only download the object when you want it to<br> <fantasai> liam: You should ignore the font if you don't understand the fragID syntax<br> <fantasai> myles: So in today's browser, that's what would occur<br> <fantasai> myles: In new browsers you get good behavior, old browsers you get the bad behavior<br> <liam> [right]<br> <fantasai> florian: Do we have any data on whether this syntax is used?<br> <myles> q?<br> <fantasai> myles: It's not supported in browsers, who would use it?<br> <fantasai> florian: If an author is accidentally using fragID, expecting it to not work<br> <fantasai> myles: Don't have any data on that<br> <fantasai> liam: If font collections had a different font format that you could use in the font-face rule<br> <fantasai> liam: and browsers that didn't understand them would skip them, that would solve the font fallback problem<br> <fantasai> myles: In Berlin we specced a new format identifier syntax<br> <fantasai> myles: we could add a new keyword for these<br> <florian> myles, that sounds like a good idea.<br> <fantasai> myles: We can use the pre-existing resolutionto extend the format function to support collections<br> <fantasai> myles: Different issue, but would allow for correct fallback behavior that you've described<br> <fantasai> astearns: That sounds like a good idea.<br> <fantasai> astearns: If you support collections, use this one.<br> <fantasai> astearns: In browsers that don't support collections, whole bit would be thrown out<br> <fantasai> myles: So, we extend format() function to indicate collections<br> <fantasai> myles: and then fallback to first font if fragID is not found<br> <Rossen_> fantasai: given we don't need to worry about consistency between existing supported browsers and those who don't support it,<br> <Rossen_> it seem better if instead of picking the first font we fallback to the next one like the image()<br> <Rossen_> picking the first one makes it easier for the authors to notice the err<br> <TabAtkins> q+<br> <fantasai> myles: But that's opposite of what liam said, he said it'd be really obvious<br> <fantasai> fantasai: But if Medium loaded instead of Book, you're unlikely to notice<br> <fantasai> dbaron: ...<br> <fantasai> TabAtkins: Concern it's not just about collections<br> <dbaron> s/.../seems like this might manifest as an issue of the form "bold and italic don't work"/<br> <fantasai> TabAtkins: But fragIDs in general<br> <dbaron> myles (before Tab): you'd get synthetic bold/italic<br> <fantasai> TabAtkins: There *are* limitations on what you can use as a name<br> <fantasai> TabAtkins: E.g. functional notation is reserved for potential future use<br> <fantasai> TabAtkins: Today we would load something using such a future syntax by loading the first font<br> <fantasai> TabAtkins: That's not good<br> <TabAtkins> Repeating from earlier: So `font.ttf#foo(bar)` is *not* a valid way to select a font from a collection. It's an unknown fragment.<br> <fantasai> fantasai: I agree ith Tab<br> <fantasai> florian: I would like to agree with Tab, but if on the font format side the fragID can be any string but on our side it's more restrited, isn't that a problem?<br> <fantasai> TabAtkins: The standard for this excludes fragments like #foo(bar)<br> <fantasai> TabAtkins: Allowed syntax is things that look like names<br> <fantasai> florian: OK, then I agree with you<br> <fantasai> TabAtkins: RFC8081<br> <fantasai> TabAtkins: https://tools.ietf.org/html/rfc8081#section-4.2<br> <fantasai> astearns: Getting to half an hour<br> <fantasai> astearns: Should at least spec the collections into format()<br> <fantasai> astearns: And maybe come back to it?<br> <fantasai> myles: More important to have resolution than on a particular resolution, so happy to do the ignore unknown/unfound URLs<br> <fantasai> astearns: For cases where browser understands fragment and can't find it, browser goes to next in the list?<br> <fantasai> astearns: Or browser doesn't understand fragID, skips downloading<br> <fantasai> fantasai summarizes<br> <fantasai> astearns: So, if you have a fragID in @font-face src, and you don't understand the fragID syntax, you don't download the font.<br> <liam> +1<br> <fantasai> RESOLVED: if you have a fragID in @font-face src, and you don't<br> <fantasai> understand the fragID syntax, you don't download the font.<br> <fantasai> astearns: If you do understand the fragID, we will download the font, and if ID'd thing not found, move on to next one (as if couldn't load)<br> <fantasai> RESOLVED: If fragID is valid, but not found in the resource, skip as if couldn't load resource<br> <fantasai> astearns: Add format() signifier for collections, similar to variations<br> <fantasai> RESOLVED: Add format() signifier for font collections, similar to variations<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/2566<br> <myles> github: https://github.com/w3c/csswg-drafts/issues/520<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/2566<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2566#issuecomment-387798269 using your GitHub account
Received on Wednesday, 9 May 2018 16:32:14 UTC