Meeting minutes
<chris> github: https://
Fonts
<chris> github: https://
drott: Thanks for attending extra slot
drott: Asked earlier what's my hope for the meeting,
drott: want to resolve on way forward for conditions for font tech
drott: ...
drott: To some extent having a more complete solution would help
drott: We discussed various syntax proposals
drott: And we have a font-technology() or font-format()
<astearns> github: https://
drott: Currently discussing whether we need to update the src descriptor and existing format syntax
font feature detection
<astearns> github: https://
drott: or whether to remove that
myles: Break topic down into a few pieces
myles: One is what grammar to type to describe different font tech
myles: Second piece is how CSS authors will choose fallback
astearns: By what grammar, are you talking about both src and @support syntax or one or the other?
myles: I think I agree with fantasai that they should probably match
myles: though maybe could be convinced otherwise
chris: Constraints are quite different
chris: in src syntax
chris: So it seems to me that we've got this in Conditional 4, do we also want to keep as part of the src string?
chris: or do we want to just drop that feature?
chris: Have gone back and forth on that decision
<drott> +1
lea: I don't think anyone thinks we should have both and they should not match
lea: question is should we have both
myles: so let's talk about fallback first
drott: So discuss whether we still want the src descriptor syntax
myles: reason to have it is for fallback, so if want to not have it have to describe how fallback would work
astearns: src descriptor syntax is a release valve, so can have fallback, until @supports path can properly support fallback
myles: If we can achieve correct fallback without src descriptor, then great. But I don't think anyone has demonstrated yet
lea: can't you use @supports not ... ?
<astearns> fantasai: two reasons to have src
<astearns> fantasai: first ??
<astearns> fantasai: second if you only want to change the file you’re specifying, it’s a lot simpler
<astearns> fantasai: @supports is way too verbose just for file swapping
fantasai: because you'd have to duplicate the entire @font-face rule and all its descriptors
<Zakim> fantasai, you wanted to mention convenience of src also
fantasai: even though the only difference is within src
<jfkthame> +1
chris: src is a way to provide URL
chris: in early days there were many incompatible formats for fonts
chris: since then, basically opentype and truetype have to be treated the same
chris: woff1 and woff2 are ways of bringing them up
chris: Can't ...
chris: existing browsers will not fetch that URL if there's additional keywords in format()
<myles> fantasai: No one is arguing we shouldn't have @supports. I'm arguing we should also have src:
<myles> chris: I'm arguing it doesn't do the job
<myles> fantasai: if the job is chanigng the URL you're downloading, then it does
chris: If I want you to download A if you support Graphite and B if you support OpenType Layout
<myles> chris: If i want to download URL A if you support graphite, and URL B if you suppport AAT, you can't do that using the src: descriptro
<myles> fantasai: We could add a star. but that's weird for e.g. postscript fonts
chris: I have to put a font format into the function as well, e.g. woff2
lea: If we add keywords to the format(), browsers that don't recognize the syntax won't download the URL, right?
chris: Yes
chris: but we're still requiring the format
<myles> fantasai: I don't think it's a problem to type the format string. if you want to type more than that, you can use @supports
chris: I don't want to have to care about the format
lea: Can't we make the format optional?
chris: That's why asking for font-technology()
chris: Format and tech are somewhat orthogonal
myles: I'm 90% sure that the format function is optional
lea: Yes
lea: but if you use format() you also need to provide a format specifier
myles: So maybe we need a sibling function
chris: That was what was originally proposed, a supports() function separate from format()
<chris> s/simlink/sibling
lea: an inline supports() function would be useful for way more things
lea: Any time using @supports for a small value
florian: I thought it was more specific than that, but a supports function similar to format() and specific to font
lea: but why not?
<chris> supports-font-technology-fn https://
<drott> +1 to keeping focus on the font selection problem at hand
astearns: From what I'm hearing, a sibling supports function could work
astearns: Chris, you would not be as opposed to adding that?
chris: no
myles: So proposal, to recap, is a function like font-technology() that takes a set of half a dozen keywords
<chris> https://
myles: which are things like 'variations' 'aat' 'opentype-shaping' and that function could go into each clause of src
<chris> <font-technology> = [ features-opentype | features-aat | features-graphite | color-colrv0 | color-colrv1 | color-svg | color-sbix | color-cbdt | variations | palettes | incremental ]
myles: and it could go into @supports condition
lea: I think a general feature is on topic, because original issue was "don't invent new microsyntaxes"
lea: Could someone type in an example syntax in IRC?
florian: Chris typed list of values into IRC
florian: they would go into a function font-technology() which could go either into src or @supports
lea: what's syntax of src though?
PeterCon: Are there any examples of this proposal already?
<myles> src: url(mycoolfont.otf) fonttechnology(color-colrv1), url(myfallbackfont.otf);
drott: I think so far we said it would be a sibling function
drott: so it wouldn't require you to write format(...) but would be at same level as format
<chris> src: url("trickster-COLRv1.otf") font-technology(color-COLRv1)
drott: but flatten the list of keywords out
drott: and wouldn't care about the container format in this case, right?
myles: I was the one that invented deeply nested function syntax, and it wasn't anything particularly intentional, just how I thought about it
lea: If we do keep that name, can we bikeshed it so it's shorter? That is extremely long to type
+1
florian: Could it be font-feature()?
myles: If the question is "can we bikeshed something" the answer is obviously yes
chris: features is a subset of font tech
<lea> TabAtkins had recommended font() at some point, but I guess if we also use that in src that wouldn't make a lot of sense
<lea> maybe font-tech()?
PeterCon: ...
PeterCon: could combine them
PeterCon: I want AAT features and SVG Color
<TabAtkins> We generally avoid abbreviations or shortenings unless they're *super* common in context.
myles: Would use spaces in function
myles: e.g. font-tech(aat svcolor)
<chris> src: url("trickster-COLRv1.otf") font-technology(color-SVG features-aat)
florian: you'd just list the capabilities with spaces separators, and there's no need to deal with incompatibilities, and browsers can just ignore incompatible combos
lea: If you want complex logic, can use @supports
drott: In usage of @supports, if you don't want to have several arguments to font-tech()
drott: boolean logic combination at the outer layer of @supports
lea: I think supporting a space-separated list would make sense
+1
I thought that was what we meant
chris: Space-separated list has implicit "and", which we would need to be clear about
chris: If you have a font with gradients, color-v1, variations, etc. can say support all of it
<lea> TabAtkins: I'm aware, but "tech" for technology is quite established in natural language
jfkthame: What's not clear to me atm is why it doesn't work just as well to simply define these new keywords in the existing format() function
jfkthame: Browsers that don't know about them so will ignore properly
myles: Have to consider combinatorial explosion
myles: It started with variations work, where I added woff2-variations opentype2-variations
myles: also adding color
myles: end up with massively long hyphen strings that are order-sensitive
jfkthame: The mistake was hyphens. Should have just put spaces, just like we're talking about now
fonts, continued (beginning of log missing)
<dbaron> github: https://
astearns: jfkthame is suggesting to re-use format() not add new function
jfkthame: ...
chris: Because existing format function requires a font format
jfkthame: I don't see why not
jfkthame: would work just the same as not specifying format function at all
jfkthame: except now filtered by the tech keywords you just expressed
drott: Currently state of format() is quite messy and not quite inteorp
drott: Some accept strings, some keywords, some both
drott: New function we have the potential of cleaning that up a bit
<Zakim> fantasai, you wanted to ask about fallback in legacy browsers and to
fantasai: One point about format() is it wouldn't invalidate src declaration in older browsers
fantasai: whereas a new function would
fantasai: As for jfkthame's proposal, I think it would work
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
fantasai: but otherwise seems easily parsable
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()
PeterCon: Might be edge case, but different tech ...
PeterCon: Variations technology is binary, font is either variable or not
PeterCon: feature capabilities are mutually exclusive
<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.
PeterCon: Font could have either AAT or Graphite, but impl only wants to use one or the other
PeterCon: If the font has both, perhaps author prefers one or other
PeterCon: So may want to specify which
PeterCon: In a fallback case, they might tolerate the second choice and not the first
PeterCon: Color tech is potentially complementary
PeterCon: Font might have both and use it for different glyphs
PeterCon: iN that case, might be happy to have both
PeterCon: An author potentially might say, I want to use this font but only use the sbix color list, not any of color-v0
PeterCon: Idk if these are too edge case to worry about
drott: I don't think necessarily that we want to describe which part of font to use
drott: this is just syntax forselection \/ download choice
drott: I don't think we have tools for choosing the tech, that would be a separate thing
myles: ...
myles: It's not a subsetting feature
lea: It occurred to me that format wasn't originally for feature description, but to meta describe the URL
lea: This is a woff font, this is opentype
lea: [something about calling something woff but getting an opentype and whether it opens it or rejects]
myles: I think it's specced
<chris> format was added because we did not (at the time) have font MIME types
myles: If browser has already downloaded font, why should not use it?
lea: I thought it was defined to describe the resource
lea: but maybe it was defined as feature detection?
fantasai: kinda was
florian: fantasai noted that putting both tech keyword would share namespace
florian: could have some syntax to divide, e.g. "with color-v1"
florian: Issue
florian: We say space-separated list is "and" not "or"
florian: fine, but might be two different meanings for "and"
<myles> [ ( woff | opentype | svg)? WITH [variations, color-sbix, opentype-features]# ]
florian: Do you support this and that?
florian: do you support both in the same file?
florian: slightly different question
florian: just to make sure this is forward proof might need to think about it
myles: Right now there's nothing in CSS that lets you say "use this part of the font, but not the other"
myles: I think that's good, because I don't think it's implementable
myles: I don't think we should add a feature that let's you ignore certain tables
fantasai: If we were to do so, I think it wouldn't be in src, should be its own descriptor
<drott> fantasai: if we would do that, it should be outside src descriptor
astearns: It sounds to me that we do have consensus to modify src descriptor to add font-tech detection somehow
<florian> Myles' sample syntax higher up is what I mean, except for the comas (and with an allowance for bikesheding the keyword WITH)
myles: Tab said something in IRC that made a lot of sense
myles: Could do jfkthame's idea for extending format()
myles: and have the same value syntax but different function name in @supports
fantasai: Yes, that was my proposal in the issue (using format() and font-format())
chris: Or we could use font-technology(), I'd prefer that
chris: but won't stand in the way
<lea> +1 to chris's point
chris: I think it's poor design to throw it all in the format function
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
florian: Did anyone address fantasai's point about dropping the src descriptor if adding new function
florian: My understanding is if we extend format() will be OK, if add new function will throw out entire src declaration
myles: I'm not sure that distinction is true, thinking to how we parse src ...
myles: if you put format(keyword keyword) maybe it gets dropped entirely
florian: could put it all inside one string?
[no that's terrible]
myles: You do that by having two declarations
chris: Dropping one item in list is OK, dropping entire declaration is a bit of a problem
florian: If space-separated keywords in format(), do we drop the entire declaration or treat as unknown format?
chris: Unknown format
florian: probably should check implementations
lea: In my test seems like entire descriptor is dropped
florian: that's sad
lea: So I think we should use a new function
astearns: I think we can resolve that we add font-tech detection to src descriptor
astearns: is that the case? anyone arguing against and only wants @supports?
<lea> FYI to test I was using this: https://
Resolution: Modify src to allow for font-tech detection per URL
astearns: Next, can we decide on whether we're extending format() or adding new function?
lea: I just tested chrome
[fussing with the test]
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
<lea> Just tested Firefox, same
astearns: objections to that?
Resolution: Same syntax available in src, will be available also in @supports, possibly with a font- prefix
<drott> slight preference for font-technology
florian: if we were to go for two functions, would both format and the new function be allowed in @support
<lea> slight preference for font-tech as well
chris: Spec doesn't say, but fine to add that
astearns: I have a slight preference for a separate function, mainly because it makes the microsyntax we're adding slightly more clear
astearns: font-tech is not a format, and having two separate names for what you're specifying is very slightly better
myles: I'd like to hear from jfkthame
<drott> also solves migrating away from messy state of what format() is
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()
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
jfkthame: if people wnat to separate them, it's OK with me
drott: Do we remove the current ???
lea: yes
chris: Yes, that should all go
astearns: So we will add a font-technology() function with some amount of the keywords we've discussed
Resolution: remove "supports <font-technology>#"
florian: if we add format() to @supports, we have to add a font- prefix
florian: so shouldn't it be removed from font-technology() within src?
chris: Yes, let's be consistent
+1
<jfkthame> +1
lea: I thought one of the benefits was to be the same
astearns: but consistency is probably preferale
astearns: Any objections to technology()?
<florian> tech? capability?
fantasai: No, but I would prefer a shorter name if we can find one
lea: yes, please
Resolution: add technology() and open bikeshedding issue
<lea> given that Chrome needs to ship this soon, if we don't bikeshed soon, it's just de facto font-technology
Resolution: Add font-technology() and font-format() to @supports
with same syntax within the parentheses
drott: do we need both?
astearns: prefer to add now, if ppl have objections can remove in the future, but seemed there were some use cases
florian: Point about "and" having two meanings, is it a concern?
<lea> what if we just add format-* keywords to font-technology()?
fantasai: You're "and"-ing over a single font file...
myles: The question is what if browser supports two different technologies, but not in the same font
florian: I guess you just choke on trying the use the download, which is wasteful but maybe not an issue
PeterCon: The example you gave was variable font with SVG table
PeterCon: likelihood of creating such a font is not great
myles: there's no way to describe variableness in SVG
Meeting closed.
none
<chris> now to try and find the "join meeting" button for the APA meeting