- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Oct 2021 16:00:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `fonts, continued (beginning of log missing)`, and agreed to the following: * `RESOLVED: Modify src to allow for font-tech detection per URL` * `RESOLVED: Same syntax available in src, will be available also in @supports, possibly with a font- prefix` * `RESOLVED: remove "supports <font-technology>#"` * `RESOLVED: add technology() and open bikeshedding issue` * `RESOLVED: Add font-technology() and font-format() to @supports` <details><summary>The full IRC log of that discussion</summary> <dbaron> topic: fonts, continued (beginning of log missing)<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/6520<br> <lea> q?<br> <fantasai> astearns: jfkthame is suggesting to re-use format() not add new function<br> <fantasai> jfkthame: ...<br> <fantasai> chris: Because existing format function requires a font format<br> <fantasai> jfkthame: I don't see why not<br> <fantasai> jfkthame: would work just the same as not specifying format function at all<br> <fantasai> jfkthame: except now filtered by the tech keywords you just expressed<br> <lea> q+<br> <fantasai> drott: Currently state of format() is quite messy and not quite inteorp<br> <florian> q- later<br> <fantasai> drott: Some accept strings, some keywords, some both<br> <fantasai> drott: New function we have the potential of cleaning that up a bit<br> <drott> q-<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about fallback in legacy browsers and to<br> <drott> q+<br> <fantasai> fantasai: One point about format() is it wouldn't invalidate src declaration in older browsers<br> <fantasai> fantasai: whereas a new function would<br> <fantasai> fantasai: As for jfkthame's proposal, I think it would work<br> <fantasai> fantasai: it would mean that the font-tech keywords would be in the same namespace as any format keywords, so you'd have to be careful to avoid name clashes<br> <fantasai> fantasai: but otherwise seems easily parsable<br> <drott> q-<br> <fantasai> astearns: One argument against format() is that then we can't use the same syntax in @supports, as context is lost has to be font-format()<br> <astearns> ack PeterCon<br> <fantasai> PeterCon: Might be edge case, but different tech ...<br> <fantasai> PeterCon: Variations technology is binary, font is either variable or not<br> <fantasai> PeterCon: feature capabilities are mutually exclusive<br> <TabAtkins> I think `@supports font-format()` works fine - the connection to @font-face's format() seems clear that you're qualifying it now that it's in a more generic context.<br> <fantasai> PeterCon: Font could have either AAT or Graphite, but impl only wants to use one or the other<br> <fantasai> PeterCon: If the font has both, perhaps author prefers one or other<br> <fantasai> PeterCon: So may want to specify which<br> <fantasai> PeterCon: In a fallback case, they might tolerate the second choice and not the first<br> <fantasai> PeterCon: Color tech is potentially complementary<br> <fantasai> PeterCon: Font might have both and use it for different glyphs<br> <fantasai> PeterCon: iN that case, might be happy to have both<br> <fantasai> PeterCon: An author potentially might say, I want to use this font but only use the ?? color list, not any of color-v0<br> <myles> q+<br> <fantasai> PeterCon: Idk if these are too edge case to worry about<br> <fantasai> drott: I don't think necessarily that we want to describe which part of font to use<br> <fantasai> drott: this is just syntax for ???<br> <fantasai> drott: I don't think we have tools for choosing the tech, that would be a separate thing<br> <fantasai> myles: ...<br> <drott> s/ ???/selection \/ download choice/<br> <fantasai> myles: It's not a subsetting feature<br> <chris> s/?? color/sbix color/<br> <astearns> ack lea<br> <fantasai> lea: It occurred to me that format wasn't originally for feature description, but to meta describe the URL<br> <fantasai> lea: This is a woff font, this is opentype<br> <fantasai> lea: [something about calling something woff but getting an opentype and whether it opens it or rejects]<br> <fantasai> myles: I think it's specced<br> <chris> format was added because we did not (at the time) have font MIME types<br> <fantasai> myles: If browser has already downloaded font, why should not use it?<br> <fantasai> lea: I thought it was defined to describe the resource<br> <chris> q?<br> <astearns> ack florian<br> <fantasai> lea: but maybe it was defined as feature detection?<br> <fantasai> fantasai: kinda was<br> <fantasai> florian: fantasai noted that putting both tech keyword would share namespace<br> <fantasai> florian: could have some syntax to divide, e.g. "with color-v1"<br> <fantasai> florian: Issue<br> <fantasai> florian: We say space-separated list is "and" not "or"<br> <fantasai> florian: fine, but might be two different meanings for "and"<br> <myles> [ ( woff | opentype | svg)? WITH [variations, color-sbix, opentype-features]# ]<br> <fantasai> florian: Do you support this and that?<br> <fantasai> florian: do you support both in the same file?<br> <fantasai> florian: slightly different question<br> <fantasai> florian: just to make sure this is forward proof might need to think about it<br> <astearns> q?<br> <astearns> ack myles<br> <fantasai> myles: Right now there's nothing in CSS that lets you say "use this part of the font, but not the other"<br> <fantasai> myles: I think that's good, because I don't think it's implementable<br> <fantasai> myles: I don't think we should add a feature that let's you ignore certain tables<br> <fantasai> fantasai: If we were to do so, I think it wouldn't be in src, should be its own descriptor<br> <drott> fantasai: if we would do that, it should be outside src descriptor<br> <fantasai> astearns: It sounds to me that we do have consensus to modify src descriptor to add font-tech detection somehow<br> <florian> Myles' sample syntax higher up is what I mean, except for the comas (and with an allowance for bikesheding the keyword WITH)<br> <fantasai> myles: Tab said something in IRC that made a lot of sense<br> <fantasai> myles: Could do jfkthame's idea for extending format()<br> <fantasai> myles: and have the same value syntax but different function name in @supports<br> <fantasai> fantasai: Yes, that was my proposal in the issue (using format() and font-format())<br> <florian> q?<br> <florian> q+<br> <fantasai> chris: Or we could use font-technology(), I'd prefer that<br> <fantasai> chris: but won't stand in the way<br> <lea> +1 to chris's point<br> <fantasai> chris: I think it's poor design to ???<br> <drott> s/???/throw it all in the format descriptor/<br> <fantasai> myles: I think if we're adding tech queries to @supports, should also allow format queries. So if we want distinct functions, then should have both in @supports<br> <drott> s/descriptor/function/<br> <fantasai> florian: Did anyone address fantasai's point about dropping the src descriptor if adding new function<br> <fantasai> florian: My understanding is if we extend format() will be OK, if add new function will throw out entire src declaration<br> <fantasai> myles: I'm not sure that distinction is true, thinking to how we parse src ...<br> <fantasai> myles: if you put format(keyword keyword) maybe it gets dropped entirely<br> <fantasai> florian: could put it all inside one string?<br> <fantasai> [no that's terrible]<br> <fantasai> myles: You do that by having two declarations<br> <fantasai> chris: Dropping one item in list is OK, dropping entire declaration is a bit of a problem<br> <fantasai> florian: If space-separated keywords in format(), do we drop the entire declaration or treat as unknown format?<br> <astearns> ack florian<br> <fantasai> chris: Unknown format<br> <fantasai> florian: probably should check implementations<br> <fantasai> lea: In my test seems like entire descriptor is dropped<br> <fantasai> florian: that's sad<br> <fantasai> lea: So I think we should use a new function<br> <fantasai> astearns: I think we can resolve that we add font-tech detection to src descriptor<br> <fantasai> astearns: is that the case? anyone arguing against and only wants @supports?<br> <lea> FYI to test I was using this: https://codepen.io/leaverou/pen/c02cfbe57388cca2399ee427c58e9f19 and checking what requests are sent to my localhost<br> <fantasai> RESOLVED: Modify src to allow for font-tech detection per URL<br> <fantasai> astearns: Next, can we decide on whether we're extending format() or adding new function?<br> <fantasai> lea: I just tested chrome<br> <fantasai> [fussing with the test]<br> <fantasai> florian: Another thing we can resolved, whichever form we add to add to src descriptor, we will expose that to @supports, possibly with font- prefix<br> <lea> Just tested Firefox, same<br> <fantasai> astearns: objections to that?<br> <fantasai> RESOLVED: Same syntax available in src, will be available also in @supports, possibly with a font- prefix<br> <drott> slight preference for font-technology<br> <fantasai> florian: ...<br> <lea> slight preference for font-tech as well<br> <fantasai> chris: Spec doesn't say, but fine to add that<br> <fantasai> astearns: I have a slight preference for a separate function, mainly because it makes the microsyntax we're adding slightly more clear<br> <fantasai> astearns: font-tech is not a format, and having two separate names for what you're specifying is very slightly better<br> <fantasai> myles: I'd like to hear from jfkthame<br> <florian> s/.../if we were to go for two functions, would both format and the new function be allowed in @support/<br> <drott> also solves migrating away from messy state of what format() is<br> <fantasai> jfkthame: I don't have a strong view one way or other, particularly if we don't get a forward-compat benefit from using format()<br> <drott> q+<br> <fantasai> jfkthame: To my mind these are very similar feature support queries, whether feature of a particular format or feature of a particular technology with the font<br> <astearns> ack drott<br> <fantasai> jfkthame: if people wnat to separate them, it's OK with me<br> <fantasai> drott: Do we remove the current ???<br> <fantasai> lea: yes<br> <fantasai> chris: Yes, that should all go<br> <fantasai> astearns: So we will add a font-technology() function with some amount of the keywords we've discussed<br> <fantasai> RESOLVED: remove "supports <font-technology>#"<br> <fantasai> florian: if we add format() to @supports, we have to add a font- prefix<br> <fantasai> florian: so shouldn't it be removed from font-technology() within src?<br> <fantasai> chris: Yes, let's be consistent<br> <fantasai> +1<br> <jfkthame> +1<br> <fantasai> lea: I thought one of the benefits was to be the same<br> <fantasai> astearns: but consistency is probably preferale<br> <fantasai> astearns: Any objections to technology()?<br> <florian> tech? capability?<br> <fantasai> fantasai: No, but I would prefer a shorter name if we can find one<br> <fantasai> lea: yes, please<br> <fantasai> RESOLVED: add technology() and open bikeshedding issue<br> <lea> given that Chrome needs to ship this soon, if we don't bikeshed soon, it's just de facto font-technology<br> <fantasai> RESOLVED: Add font-technology() and font-format() to @supports<br> <fantasai> with same syntax within the parentheses<br> <fantasai> drott: do we need both?<br> <florian> q+<br> <fantasai> astearns: prefer to add now, if ppl have objections can remove in the future, but seemed there were some use cases<br> <fantasai> florian: Point about "and" having two meanings, is it a concern?<br> <astearns> ack florian<br> <lea> what if we just add format-* keywords to font-technology()?<br> <fantasai> fantasai: You're "and"-ing over a single font file...<br> <fantasai> myles: The question is what if browser supports two different technologies, but not in the same font<br> <fantasai> florian: I guess you just choke on trying the use the download, which is wasteful but maybe not an issue<br> <fantasai> PeterCon: The example you gave was variable font with SVG table<br> <fantasai> PeterCon: likelihood of creating such a font is not great<br> <fantasai> myles: there's no way to describe variableness in SVG<br> <fantasai> Meeting closed.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-947810568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 October 2021 16:00:32 UTC