- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Apr 2018 14:20:04 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Fonts l4 super-format()`, and agreed to the following resolutions:
* `RESOLVED: Parse the value of src throwing out invalid parts like media queries and not like selectors. aka You split on the commas and throw out the pieces you don't understand not the whole thing.`
* `RESOLVED: use this: format(<string> [supports (list from spec)#]?)`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Fonts l4 super-format()<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/633<br>
<dael> myles: There has been much movement in typography industry in the last several years. There are many features fonts can opt into now. One of the tenants of this new world where fonts can have technology inside is browsers that don't support a technology should not trigger downloading a font with that inside.<br>
<dael> myles: In @font-face rules in the past this was done with the format function with the source description.<br>
<dael> myles: Inside the format function it accepts a string. now that we have 3 optional technology we prob shouldn't generate a bunch of strings with tokens. There should be a way for an @font-face to associate a URL with a set of requirements where only if browser fits requirements they should use this.<br>
<dael> myles: That's the issue. We don't have an opinion as to which proposal to do this should be picked. There's one we seem to be zeroing in on in the issue<br>
<dael> ChrisL: We have the format specifier and we don't want the combinatorial thing where we add more things and it explodes. So wexpand the format specifier to that it has a string of what it requires. So exising browser can reject that font. That seems to be where the thread is ending.<br>
<dael> myles: Proposal is do we extend format to extend this.<br>
<dael> Vlad: Hypothetical. Open type font that supports regular + color glyphs + variations. If you can't use color the font provides you the downgrade.<br>
<ChrisL> so for example `format("opentype", requires variations, requires color)`<br>
<dael> myles: Yes. All of these technologies are created such that they are opt in and the browser can still use the font file. Tht's great for backwards compat but these new tech can add significant space in the font file.<br>
<dael> myles: In the case of color glyphs it's a lot. It would be great if browsers didn't have to download more data then needed.<br>
<dael> florian: Is this also avoid the case od a browser choosing to download a variable font when they don't suppor that instead of downloading other fonts.<br>
<dael> astearns: I thought that was correct. Browsers that don't support variable fonts will not download a font with that tag. DOesn't matter if the font in the declarion supports variables, but it's a tag for only if the browser supports variables.<br>
<dael> florian: So fold variable into the rest.<br>
<dael> myles: yes.<br>
<dael> fremy: WE shipped variables and color fonts so if we add this our existing impl will not recognize the new required flags because it doesn't think we know the font. Would have better to think of this before.<br>
<dael> ChrisL: That is why the thread started in 2016.<br>
<dael> myles: We've got the same problem.<br>
<dael> myles: There is a proposal. Is there feedback on it?<br>
<dael> fantasai: Which proposal?<br>
<dael> ChrisL: It's in IRC<br>
<dael> ChrisL: So for that example: `format("opentype", requires variations, requires color)` you have to support both.<br>
<dael> fantasai: ameliaBR suggested using the names of the font<br>
<dael> myles: One feature can have many tables so you need one representitive table<br>
<dael> fantasai: We do that for @supports anyone<br>
<astearns> s/names of the/names of the tables of the<br>
<dael> ChrisL: For variable fonts there's one table for every table that exists so you ave to list a ton<br>
<dael> fantasai: You use one as a proxy for the rest. You use @supports display:grid and I assume the rest<br>
<dael> Jason: Font tables aren't something that users commonly know.<br>
<dael> Jason: I think the concernw ould be that people who know about font format technology might know the tables exist but most font users don't. If we're going to pick a table we might as well pick a keyword as the thing which is more understandable to users of fonts.<br>
<dael> ChrisL: Think so, yes.<br>
<dael> myles: There are 4 popular color font formats and they're all competing. Some browsers support some. Edge does all. It kinda matters.<br>
<jpamental> Just chiming in that the Jason mentioned above is me<br>
<dael> myles: That's a situation where the table matters. Variations is different. I think keywords is a good pick so you can say I support variations.<br>
<dael> eae: You don't want to download the font 4 times that has the same variation.<br>
<dael> ChrisL: It's all open type.<br>
<dael> fantasai: There's a few situations where you need more then does it support.<br>
<dael> Vlad: Can you desc an example where this functionality is needed?<br>
<dael> myles: I don't want to download font files....<br>
<dael> Vlad: You're a user and you want color glyphs or nothing at all. Is that the case?<br>
<dael> astearns: Author intent is I was the display color glyphs in this font if I'm in a browser that supports it. If I'm in a browser that doesn't support it I want to download only the smaller font so I get it faster.<br>
<dael> ChrisL: These are subsetted fonts. You've got one that does svg one that does spix.<br>
<dael> myles: It's up the the author but yes.<br>
<dael> Rick: Same hting happens with variable fonts. I could have a bold weight and a light weight and I want to sort them out.<br>
<dael> astearns: I prefer the keywords. Since there are 4 color font flavors do we need for keywords<br>
<dael> many: yes<br>
<dael> myles: And there will be variations and features<br>
<dael> TabAtkins: If a color wins we'll add color as an alis to it.<br>
<dael> fantasai: You might want references to open type tables for the future. Let's say there's an open type table where support is necessary to use this crazy script.<br>
<dael> fantasai: WE can have keywords for the most common things, but might also want to support the more specific cases.<br>
<TabAtkins> `requires variations, requires table "YOLO"<br>
<TabAtkins> `requires variations, requires table "YOLO"<br>
<astearns> `supports`: keyword | "XXXX"<br>
<TabAtkins> `requires variations, requires table "YOLO"`<br>
<dael> astearns: You mean ^?<br>
<dael> astearns: Arbitrary 4 letter strings which you can put for supportsand you check if browser does anything?<br>
<dael> myles: We can have a feature keyed off a specific table but we shouldn't have that many variations. We can have both.<br>
<dael> ChrisL: should use it for open type features?<br>
<dael> fantasai: Interesting point.<br>
<dael> astearns: Since this issue has been open for years can we do keywords for now and extend later as we find use cases? Particularly if there's a language thing with shaping tables where if a table to load a font in some browsers is the useful thing.<br>
<dael> fantasai: One of the reasons you don' want to defer is if you add it later the brwosers will throw out hte entire declaration So you either define a subset and say we may extend in the future.<br>
<dael> ChrisL: It's important to not throw out the whole declaration.<br>
<dael> fremy: Can't we use string and say we split by slash?<br>
<dael> myles: A micro syntax? It's not good of OMs.<br>
<dael> ChrisL: You said it was backwards compat if you use slash?<br>
<dael> myles: Browsers would look at the format scring and parse.<br>
<dael> fantasai: Micro syntax is more complicated if we extend.<br>
<dael> fremy: If we do this it still works in previous browsers. They'll still parse it. If we require something we'll remove all the fonts in src because if you do something inside the string we don't know.<br>
<dael> TabAtkins: Download source twice. Source for simpliest and second for requires.<br>
<dael> fantasai: Shouldn't we use supports to be consistant?<br>
<dael> myles: browser-support font-files<br>
<dael> fremy: Can't you check if the browser supports font varients?<br>
<dael> myles: It doesn't work for color fonts because the css support for palettes is across types of formats<br>
<dael> TabAtkins: Should we be careful with how we define to add more features. If we say it supports custom ident.<br>
<dael> myles: Syntax isn't a | b | c it's just custom ident?<br>
<dael> TabAtkins: WE'll say these are defined custom idents and if you see one you don't know you don't support it.<br>
<dael> fantasai: I think more general and the values are comma sep but if you don't understand any part of it it throws that part out. It's a change to parsing that opens the whole relmn of possibilities in the future.<br>
<dael> TabAtkins: Yeah. Only poss. backwards compat is if people add nonsense in their source and expect it not to download this will jsut htrow away the nonsense.<br>
<dael> astearns: Does that exist?<br>
<dael> TabAtkins: No.<br>
<dael> fantasai: I'd say we resolve on that.<br>
<dael> fantasai: Prop: The values of the src descriptor, the entire declaration is not thrown out if any comma separated section is invalid<br>
<dael> myles: Parsing is chop it into commas, run parse on each piece, and if that piece doesn't parse throw it out.<br>
<dael> fantasai: Like MQ not like selectors.<br>
<dael> TabAtkins: The grammar would have to be like custom properties, that's less good.<br>
<dael> astearns: Objections to not throwing out a source descriptor if a comma separated piece does not parse<br>
<dael> fremy: Inside a function we can extend, right?<br>
<dael> fantasai: This is broader.<br>
<TabAtkins> TabAtkins: So I'll need to put together some prose to handle that in the grammar.<br>
<dael> RESOLVED: Parse the value of src throwing out invalid parts like media queries and not like selectors. aka You split on the commas and throw out the pieces you don't understand not the whole thing.<br>
<fantasai> Like Media Queries, not like Selectors<br>
<TabAtkins> (unfortunately) not like Selectors<br>
<dael> fantasai: Now people can impl that while we figure out the rest.<br>
<astearns> (fortunately) not like (unfortunate) Selectors<br>
<dael> myles: Now we have that we don't need the string thing. We can just use keywords.<br>
<dael> fantasai: That's a different problem. If you just have keywords that are predefined.<br>
<dael> myles: got it<br>
<myles> format("opentype", [requires custom-ident]#)<br>
<fantasai> s/predefined/predefined, then you can only query predefined things/<br>
<dael> myles: Proposal #2 is ^<br>
<myles> format(DOMString, [requires custom-ident]#)<br>
<dael> astearns: Extending source descriptor to a comma sep list of requirest custom ident<br>
<dael> TabAtkins: not requires<br>
<dael> ChrisL: When I type that out I'll have commas?<br>
<dael> myles: Yes.<br>
<dael> TabAtkins: No requires is no commas.<br>
<fantasai> format(<string>, [requires <custom-ident>#)<br>
<dael> fantasai: This is what you meant ^<br>
<fantasai> format(<string>, [requires <custom-ident>]#)<br>
<ChrisL> almost<br>
<dael> myles: You missed the square bracket<br>
<dael> TabAtkins: With the resolution we don't need the custom-ident business.<br>
<dael> ChrisL: So I can put inherit and stuff in there?<br>
<dael> myles: It's all inside the one format string...I guess that's okay.<br>
<dael> TabAtkins: With the resolution if we mint a brand new requires keyword tomorrow and someone uses it for browsers that don't know it that chunk of the source will be thrown out.<br>
<dael> astearns: If you put in "requires color-something"...oh!<br>
<dael> myles: it goes on to the next source.<br>
<dael> astearns: You break up things between commas which reduces to the things you know.<br>
<ChrisL> so there is an implicit AND, on the requires<br>
<dael> TabAtkins: Source splits on commas and only checks individual pieces<br>
<dael> astearns: Got it.<br>
<dael> myles: I think we're okay.<br>
<dael> fantasai: Do you need requires word?<br>
<Joel> Hi there!I'm Joël from Fontself, I'm really interested about OpenType-SVG / Color fonts<br>
<Joel> My colleagues Mohamed and Franz will be at TypoLabs<br>
<dael> astearns: I like an indication of what this is about. I liked supports better.<br>
<dael> TabAtkins: Open type is written as a string. We can't restrict it because it's an extern source. That's why tables as a string. If we define it's an ident.<br>
<dael> myles: Authors won't understand.<br>
<Joel> Their flight was cancelled at the last minute, they will be in Berlin tonight ;-)<br>
<dael> myles: I think I'm with astearns that having a keyword would be helpful.<br>
<dael> fantasai: Put with many things you have to write it many times.<br>
<dael> astearns: Ties in the supports.<br>
<dael> fantasai: prefer if you don't have to repeat it.<br>
<dael> myles: can you write the grammar so that we don't have to repeat?<br>
<fantasai> format(<string> supports <custom-ident>#)<br>
<dael> fantasai: There ^<br>
<fantasai> format(<string> [supports <custom-ident>#]?)<br>
<dael> myles: Looks like supports is required, though.<br>
<dael> fantasai: there ^<br>
<dael> myles: And a comma<br>
<dael> fantasai: Getting rid of the comma<br>
<dael> TabAtkins: If we're removing supports no commas.<br>
<dael> myles: Okay.<br>
<dael> [everyone argues about commas]<br>
<astearns> (which is a recurring theme)<br>
<dael> ChrisL: The longest github thread ever was about using commas in the color function.<br>
<myles> astearns: proposal: format(<string> [supports <custom-ident>#]?)<br>
<dael> astearns: We have a proposed syntax. Anything more to change/fix or shall we resolve?<br>
<TabAtkins> (It's not gonna be <custom-ident> now.)<br>
<dael> TabAtkins: Custom-ident can be a normal grammar thing.<br>
<dael> ChrisL: So we give an explicit list and if we extend in the future that's fine.<br>
<dael> fantasai: Yes.<br>
<Joel> Btw we think a @supports for color fonts will be needed, especially at the beginning. ie: If you want to use a color font only if it's supported and style it differently.<br>
<dael> astearns: Objections to format(<string> [supports (list from spec)#]?)<br>
<astearns> Joel: that's what we just resolved on<br>
<dael> RESOLVED: use this: format(<string> [supports (list from spec)#]?)<br>
<fantasai> format(<string> [supports <feature-name>#]?)<br>
<Joel> Great!<br>
<fantasai> where <feature-name> is a keyword<br>
<dael> astearns: Someone on irc mentioned @support for color fonts will be needed. Do we have an @support?<br>
<astearns> Joel: sorry, I was wrong. we'll still need to figure it out<br>
<Joel> Ok :)<br>
<astearns> we'll file an issue<br>
<dael> myles: No.I think that should be an issue and we should discuss it.<br>
<dael> fantasai: For @supports you can use the same function as is here.<br>
<dael> myles: WE should do use case research<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/633#issuecomment-380469287 using your GitHub account
Received on Wednesday, 11 April 2018 14:20:06 UTC