15:01:05 <RRSAgent> RRSAgent has joined #css
15:01:05 <RRSAgent> logging to https://www.w3.org/2021/10/20-css-irc
15:01:07 <Zakim> RRSAgent, make logs Public
15:01:09 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:01:17 <chris> present+
15:01:21 <dbaron> dbaron has joined #css
15:01:41 <lea> lea has joined #css
15:02:01 <duga> duga has joined #css
15:02:08 <chris> github: https://github.com/w3c/csswg-drafts/issues/6520
15:02:17 <chris> topic: Fonts
15:02:19 <chris> github: https://github.com/w3c/csswg-drafts/issues/6520
15:02:21 <bkardell_> bkardell_ has joined #css
15:02:50 <lea> present+
15:03:12 <emeyer> emeyer has joined #css
15:03:34 <emeyer> emeyer has left #css
15:04:01 <miriam> present+
15:04:07 <drott> present+
15:05:10 <jfkthame> present+
15:05:10 <myles> myles has joined #css
15:05:18 <dbaron> Present+
15:05:28 <PeterCon> PeterCon has joined #css
15:05:48 <fantasai> Scribenick: fantasai
15:06:20 <fantasai> drott: Thanks for attending extra slot
15:06:29 <fantasai> drott: Asked earlier what's my hope for the meeting,
15:06:46 <fantasai> drott: want to resolve on way forward for conditions for font tech
15:06:48 <fantasai> drott: ...
15:06:57 <fantasai> drott: To some extent having a more complete solution would help
15:07:02 <fantasai> drott: We discussed various syntax proposals
15:07:07 <Vlad> Vlad has joined #css
15:07:10 <fantasai> drott: And we have a font-technology() or font-format()
15:07:11 <astearns> github: https://github.com/w3c/csswg-drafts/issues/6520
15:07:20 <fantasai> drott: Currently discussing whether we need to update the src descriptor and existing format syntax
15:07:22 <astearns> topic: font feature detection
15:07:24 <astearns> github: https://github.com/w3c/csswg-drafts/issues/6520
15:07:27 <fantasai> drott: or whether to remove that
15:08:26 <fantasai> myles: Break topic down into a few pieces
15:08:33 <fantasai> myles: One is what grammar to type to describe different font tech
15:08:44 <fantasai> myles: Second piece is how CSS authors will choose fallback
15:09:01 <fantasai> astearns: By what grammar, are you talking about both src and @support syntax or one or the other?
15:09:10 <fantasai> myles: I think I agree with fantasai that they should probably match
15:09:16 <fantasai> myles: though maybe could be convinced otherwise
15:09:24 <fantasai> chris: Constraints are quite different
15:09:26 <eeeps> eeeps has joined #css
15:09:29 <lea> q?
15:09:30 <fantasai> chris: in src syntax
15:09:34 <lea> q+
15:09:50 <fantasai> 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?
15:09:57 <fantasai> chris: or do we want to just drop that feature?
15:10:01 <fantasai> chris: Have gone back and forth on that decision
15:10:07 <astearns> ack lea
15:10:13 <drott> +1
15:10:14 <fantasai> lea: I don't think anyone thinks we should have both and they should not match
15:10:17 <fantasai> lea: question is should we have both
15:10:22 <fantasai> myles: so let's talk about fallback first
15:10:38 <fantasai> drott: So discuss whether we still want the src descriptor syntax
15:10:55 <fantasai> myles: reason to have it is for fallback, so if want to not have it have to describe how fallback would work
15:11:16 <fantasai> astearns: src descriptor syntax is a release valve, so can have fallback, until @supports path can properly support fallback
15:11:50 <fantasai> myles: If we can achieve correct fallback without src descriptor, then great. But I don't think anyone has demonstrated yet
15:11:55 <emilio> present+
15:11:56 <chris> q+
15:11:57 <lea> q?
15:11:57 <fantasai> lea: can't you use @supports not ... ?
15:12:13 <astearns> fantasai: two reasons to have src
15:12:24 <astearns> fantasai: first ??
15:12:43 <astearns> fantasai: second if you only want to change the file you’re specifying, it’s a lot simpler
15:12:49 <nigel> nigel has joined #css
15:13:07 <astearns> fantasai: @supports is way too verbose just for file swapping
15:13:18 <chris> q?
15:13:24 <fantasai> fantasai: because you'd have to duplicate the entire @font-face rule and all its descriptors
15:13:25 <astearns> ack fantasai
15:13:25 <Zakim> fantasai, you wanted to mention convenience of src also
15:13:32 <fantasai> fantasai: even though the only difference is within src
15:13:34 <jfkthame> +1
15:13:40 <fantasai> chris: src is a way to provide URL
15:13:48 <fantasai> chris: in early days there were many incompatible formats for fonts
15:13:56 <fantasai> chris: since then, basically opentype and truetype have to be treated the same
15:14:09 <fantasai> chris: woff1 and woff2 are ways of bringing them up
15:14:18 <fantasai> chris: Can't  ...
15:14:45 <fantasai> chris: existing browsers will not fetch that URL if there's additional keywords in format()
15:15:04 <myles> fantasai: No one is arguing we shouldn't have @supports. I'm arguing we should also have src:
15:15:25 <myles> chris: I'm arguing it doesn't do the job
15:15:25 <myles> fantasai: if the job is chanigng the URL you're downloading, then it does
15:15:40 <lea> q+
15:15:45 <fantasai> chris: If I want you to download A if you support Graphite and B if you support OpenType Layout
15:15:47 <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
15:15:48 <astearns> ack chris
15:16:13 <myles> fantasai: We could add a star. but that's weird for e.g. postscript fonts
15:16:18 <astearns> ack lea
15:16:18 <fantasai> chris: I have to put a font format into the function as well, e.g. woff2
15:16:36 <fantasai> lea: If we add keywords to the format(), browsers that don't recognize the syntax won't download the URL, right?
15:16:48 <fantasai> chris: Yes
15:16:53 <fantasai> chris: but we're still requiring the format
15:17:07 <lea> q+
15:17:25 <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
15:17:33 <fantasai> chris: I don't want to have to care about the format
15:17:40 <fantasai> lea: Can't we make the format optional?
15:17:52 <fantasai> chris: That's why asking for font-technology()
15:17:59 <fantasai> chris: Format and tech are somewhat orthogonal
15:18:19 <fantasai> myles: I'm 90% sure that the format function is optional
15:18:21 <fantasai> lea: Yes
15:18:31 <fantasai> lea: but if you use format() you also need to provide a format specifier
15:18:40 <fantasai> myles: So maybe we need a simlink function
15:18:58 <fantasai> chris: That was what was originally proposed, a supports() function separate from format()
15:19:04 <lea> q?
15:19:05 <myles> s/simlink/sibling/
15:19:06 <chris> s/simlink/sibling
15:19:07 <fantasai> lea: an inline supports() function would be useful for way more things
15:19:17 <fantasai> lea: Any time using @supports for a small value
15:19:33 <fantasai> florian: I thought it was more specific than that, but a supports function similar to format() and specific to font
15:19:37 <fantasai> lea: but why not?
15:19:59 <chris> supports-font-technology-fn https://drafts.csswg.org/css-conditional-4/#at-supports-ext
15:20:12 <lea> q+
15:20:16 <drott> +1 to keeping focus on the font selection problem at hand
15:20:18 <fantasai> astearns: From what I'm hearing, a sibling supports function could work
15:20:36 <fantasai> astearns: Chris, you would not be as opposed to adding that?
15:20:41 <fantasai> chris: no
15:20:58 <fantasai> myles: So proposal, to recap, is a function like font-technology() that takes a set of half a dozen keywords
15:21:09 <chris> https://drafts.csswg.org/css-fonts-4/#font-face-src-requirement-types
15:21:11 <lea> q?
15:21:15 <fantasai> myles: which are things like 'variations' 'aat' 'opentype-shaping' and that function could go into each clause of src
15:21:22 <chris> <font-technology> = [ features-opentype | features-aat | features-graphite                     | color-colrv0 | color-colrv1 | color-svg | color-sbix | color-cbdt                     | variations | palettes | incremental ]
15:21:22 <fantasai> myles: and it could go into @supports
15:21:28 <fantasai> s/supports/supports condition/
15:21:38 <astearns> ack lea
15:21:47 <PeterCon> q+
15:21:57 <fantasai> lea: I think a general feature is on topic, because original issue was "don't invent new microsyntaxes"
15:22:04 <fantasai> lea: Could someone type in an example syntax in IRC?
15:22:13 <fantasai> florian: Chris typed list of values into IRC
15:22:22 <drott> q+
15:22:26 <fantasai> florian: they would go into a function font-technology() which could go either into src or @supports
15:22:33 <fantasai> lea: what's syntax of src though?
15:22:38 <astearns> ack PeterCon
15:22:46 <fantasai> PeterCon: Are there any examples of this proposal already?
15:22:56 <myles> src: url(mycoolfont.opentype) fonttechnology(color-colrv1), url(myfallbackfont.otf);
15:23:02 <astearns> ack Domenic
15:23:06 <astearns> ack drott
15:23:13 <fantasai> drott: I think so far we said it would be a sibling function
15:23:25 <myles> s/.opentype/.otf/
15:23:27 <fantasai> drott: so it wouldn't require you to write format(...) but would be at same level as format
15:23:35 <chris> src: url("trickster-COLRv1.otf") font-technology(color-COLRv1)
15:23:45 <fantasai> drott: but flatten the list of keywords out
15:23:51 <fantasai> drott: and wouldn't care about the container format in this case, right?
15:24:15 <fantasai> myles: I was the one that invented deeply nested function syntax, and it wasn't anything particularly intentional, just how I thought about it
15:24:31 <PeterCon> q+
15:24:35 <fantasai> lea: If we do keep that name, can we bikeshed it so it's shorter? That is extremely long to type
15:24:38 <fantasai> +1
15:24:51 <fantasai> florian: Could it be font-feature()?
15:25:01 <fantasai> myles: If the question is "can we bikeshed something" the answer is obviously yes
15:25:08 <fantasai> chris: features is a subset of font tech
15:25:14 <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
15:25:17 <lea> maybe font-tech()?
15:25:20 <astearns> ack PeterCon
15:25:24 <fantasai> PeterCon: ...
15:25:27 <fantasai> PeterCon: could combine them
15:25:33 <fantasai> PeterCon: I want AAT features and SVG Color
15:25:37 <jfkthame> q+
15:25:37 <TabAtkins> We generally avoid abbreviations or shortenings unless they're *super* common in context.
15:25:38 <fantasai> myles: Would use spaces in function
15:25:54 <fantasai> myles: e.g. font-tech(aat svcolor)
15:25:55 <chris> src: url("trickster-COLRv1.otf") font-technology(color-SVG features-aat)
15:25:57 <fantasai> florian: ...
15:26:04 <fantasai> lea: If you want complex logic, can use @supports
15:26:30 <fantasai> drott: In usage of @supports, if you don't want to have several arguments to font-tech()
15:26:42 <fantasai> drott: boolean logic combination at the outer layer of @supports
15:26:48 <fantasai> lea: I think supporting a space-separated list would make sense
15:26:50 <fantasai> +1
15:26:54 <PeterCon> q+
15:26:56 <fantasai> I thought that was what we mant
15:26:59 <fantasai> s/mant/meant
15:27:11 <fantasai> chris: Space-separated list has implicit "and", which we would need to be clear about
15:27:25 <fantasai> chris: If you have a font with gradients, color-v1, variations, etc. can say support all of it
15:27:35 <astearns> ack jfkthame
15:27:36 <florian> s/.../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/
15:27:38 <florian> q+
15:27:48 <lea> TabAtkins: I'm aware, but "tech" for technology is quite established in natural language
15:27:50 <fantasai> 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
15:27:57 <drott> q+
15:28:03 <fantasai> jfkthame: Browsers that don't know about them so will ignore properly
15:28:10 <fantasai> myles: Have to consider combinatorial explosion
15:28:21 <fantasai> myles: It started with variations work, where I added woff2-variations opentype2-variations
15:28:24 <fantasai> myles: also adding color
15:28:32 <fantasai> myles: end up with massively long hyphen strings that are order-sensitive
15:28:44 <github-bot> github-bot has joined #css
15:28:46 <fantasai> jfkthame: The mistake was hyphens. Should have just put spaces, just like we're talking about now
15:28:58 <dbaron> topic: fonts, continued (beginning of log missing)
15:29:12 <dbaron> github: https://github.com/w3c/csswg-drafts/issues/6520
15:29:13 <lea> q?
15:29:22 <fantasai> astearns: jfkthame is suggesting to re-use format() not add new function
15:29:24 <fantasai> jfkthame: ...
15:29:31 <fantasai> chris: Because existing format function requires a font format
15:29:42 <fantasai> jfkthame: I don't see why not
15:29:49 <fantasai> jfkthame: would work just the same as not specifying format function at all
15:29:57 <fantasai> jfkthame: except now filtered by the tech keywords you just expressed
15:30:05 <lea> q+
15:30:13 <fantasai> drott: Currently state of format() is quite messy and not quite inteorp
15:30:14 <florian> q- later
15:30:18 <fantasai> drott: Some accept strings, some keywords, some both
15:30:25 <fantasai> drott: New function we have the potential of cleaning that up a bit
15:30:35 <drott> q-
15:30:38 <astearns> ack fantasai
15:30:38 <Zakim> fantasai, you wanted to ask about fallback in legacy browsers and to
15:30:53 <jensimmons> jensimmons has joined #css
15:31:05 <dino> dino has joined #css
15:32:07 <drott> q+
15:33:09 <fantasai> fantasai: One point about format() is it wouldn't invalidate src declaration in older browsers
15:33:16 <fantasai> fantasai: whereas a new function would
15:33:25 <fantasai> fantasai: As for jfkthame's proposal, I think it would work
15:33:43 <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
15:33:51 <fantasai> fantasai: but otherwise seems easily parsable
15:34:01 <plinss> present+
15:34:15 <Vlad> present+
15:34:20 <drott> q-
15:34:26 <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()
15:34:32 <astearns> ack PeterCon
15:34:44 <fantasai> PeterCon: Might be edge case, but different tech ...
15:34:54 <fantasai> PeterCon: Variations technology is binary, font is either variable or not
15:35:01 <fantasai> PeterCon: feature capabilities are mutually exclusive
15:35:04 <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.
15:35:13 <fantasai> PeterCon: Font could have either AAT or Graphite, but impl only wants to use one or the other
15:35:21 <fantasai> PeterCon: If the font has both, perhaps author prefers one or other
15:35:24 <fantasai> PeterCon: So may want to specify which
15:35:38 <fantasai> PeterCon: In a fallback case, they might tolerate the second choice and not the first
15:35:44 <fantasai> PeterCon: Color tech is potentially complementary
15:35:52 <fantasai> PeterCon: Font might have both and use it for different glyphs
15:36:05 <fantasai> PeterCon: iN that case, might be happy to have both
15:36:28 <fantasai> PeterCon: An author potentially might say, I want to use this font but only use the ?? color list, not any of color-v0
15:36:34 <myles> q+
15:36:35 <fantasai> PeterCon: Idk if these are too edge case to worry about
15:36:47 <fantasai> drott: I don't think necessarily that we want to describe which part of font to use
15:36:51 <fantasai> drott: this is just syntax for ???
15:37:07 <jensimmons> present+
15:37:09 <fantasai> drott: I don't think we have tools for choosing the tech, that would be a separate thing
15:37:31 <fantasai> myles: ...
15:37:33 <drott> s/ ???/selection \/ download choice/
15:37:38 <fantasai> myles: It's not a subsetting feature
15:37:39 <chris> s/?? color/sbix color/
15:37:41 <astearns> ack lea
15:37:50 <fantasai> lea: It occurred to me that format wasn't originally for feature description, but to meta describe the URL
15:37:56 <fantasai> lea: This is a woff font, this is opentype
15:38:18 <fantasai> lea: [something about calling something woff but getting an opentype and whether it opens it or rejects]
15:38:26 <fantasai> myles: I think it's specced
15:38:33 <chris> format was added because we did not (at the time) have font MIME types
15:38:35 <fantasai> myles: If browser has already downloaded font, why should not use it?
15:38:50 <fantasai> lea: I thought it was defined to describe the resource
15:39:00 <chris> q?
15:39:03 <astearns> ack florian
15:39:06 <fantasai> lea: but maybe it was defined as feature detection?
15:39:13 <fantasai> fantasai: kinda was
15:39:27 <fantasai> florian: fantasai noted that putting both tech keyword would share namespace
15:39:42 <fantasai> florian: could have some syntax to divide, e.g. "with color-v1"
15:39:46 <fantasai> florian: Issue
15:39:53 <fantasai> florian: We say space-separated list is "and" not "or"
15:40:04 <fantasai> florian: fine, but might be two different meanings for "and"
15:40:11 <myles> [ ( woff | opentype | svg)? WITH [variations, color-sbix, opentype-features]# ]
15:40:15 <fantasai> florian: Do you support this and that?
15:40:20 <fantasai> florian: do you support both in the same file?
15:40:23 <fantasai> florian: slightly different question
15:40:33 <fantasai> florian: just to make sure this is forward proof might need to think about it
15:40:52 <astearns> q?
15:40:59 <astearns> ack myles
15:41:18 <fantasai> myles: Right now there's nothing in CSS that lets you say "use this part of the font, but not the other"
15:41:24 <fantasai> myles: I think that's good, because I don't think it's implementable
15:41:31 <fantasai> myles: I don't think we should add a feature that let's you ignore certain tables
15:41:52 <fantasai> fantasai: If we were to do so, I think it wouldn't be in src, should be its own descriptor
15:41:52 <drott> fantasai: if we would do that, it should be outside src descriptor
15:42:17 <fantasai> astearns: It sounds to me that we do have consensus to modify src descriptor to add font-tech detection somehow
15:42:26 <florian> Myles' sample syntax higher up is what I mean, except for the comas (and with an allowance for bikesheding the keyword WITH)
15:42:31 <fantasai> myles: Tab said something in IRC that made a lot of sense
15:42:40 <fantasai> myles: Could do jfkthame's idea for extending format()
15:42:59 <fantasai> myles: and have the same value syntax but different function name in @supports
15:43:13 <fantasai> fantasai: Yes, that was my proposal in the issue (using format() and font-format())
15:43:15 <florian> q?
15:43:17 <florian> q+
15:43:23 <fantasai> chris: Or we could use font-technology(), I'd prefer that
15:43:27 <fantasai> chris: but won't stand in the way
15:43:28 <lea> +1 to chris's point
15:43:32 <fantasai> chris: I think it's poor design to ???
15:43:56 <drott> s/???/throw it all in the format descriptor/
15:43:58 <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
15:44:06 <drott> s/descriptor/function/
15:44:19 <fantasai> florian: Did anyone address fantasai's point about dropping the src descriptor if adding new function
15:44:38 <fantasai> florian: My understanding is if we extend format() will be OK, if add new function will throw out entire src declaration
15:44:51 <fantasai> myles: I'm not sure that distinction is true, thinking to how we parse src ...
15:45:11 <fantasai> myles: if you put format(keyword keyword) maybe it gets dropped entirely
15:45:21 <fantasai> florian: could put it all inside one string?
15:45:27 <fantasai> [no that's terrible]
15:45:35 <fantasai> myles: You do that by having two declarations
15:45:46 <fantasai> chris: Dropping one item in list is OK, dropping entire declaration is a bit of a problem
15:46:08 <fantasai> florian: If space-separated keywords in format(), do we drop the entire declaration or treat as unknown format?
15:46:13 <astearns> ack florian
15:46:19 <fantasai> chris: Unknown format
15:46:26 <fantasai> florian: probably should check implementations
15:46:33 <fantasai> lea: In my test seems like entire descriptor is dropped
15:46:34 <fantasai> florian: that's sad
15:46:49 <fantasai> lea: So I think we should use a new function
15:47:14 <fantasai> astearns: I think we can resolve that we add font-tech detection to src descriptor
15:47:30 <fantasai> astearns: is that the case? anyone arguing against and only wants @supports?
15:47:34 <lea> FYI to test I was using this: https://codepen.io/leaverou/pen/c02cfbe57388cca2399ee427c58e9f19 and checking what requests are sent to my localhost
15:47:50 <fantasai> RESOLVED: Modify src to allow for font-tech detection per URL
15:48:04 <fantasai> astearns: Next, can we decide on whether we're extending format() or adding new function?
15:48:09 <fantasai> lea: I just tested chrome
15:48:42 <fantasai> [fussing with the test]
15:49:12 <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
15:49:28 <lea> Just tested Firefox, same
15:49:37 <fantasai> astearns: objections to that?
15:50:03 <fantasai> RESOLVED: Same syntax available in src, will be available also in @supports, possibly with a font- prefix
15:50:10 <drott> slight preference for font-technology
15:50:17 <fantasai> florian: ...
15:50:21 <lea> slight preference for font-tech as well
15:50:25 <fantasai> chris: Spec doesn't say, but fine to add that
15:50:43 <fantasai> astearns: I have a slight preference for a separate function, mainly because it makes the microsyntax we're adding slightly more clear
15:50:55 <fantasai> astearns: font-tech is not a format, and having two separate names for what you're specifying is very slightly better
15:50:59 <fantasai> myles: I'd like to hear from jfkthame
15:51:02 <florian> s/.../if we were to go for two functions, would both format and the new function be allowed in @support/
15:51:10 <drott> also solves migrating away from messy state of what format() is
15:51:44 <Rossen_> Rossen_ has joined #css
15:52:08 <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()
15:52:22 <drott> q+
15:52:32 <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
15:52:35 <astearns> ack drott
15:52:40 <fantasai> jfkthame: if people wnat to separate them, it's OK with me
15:52:56 <fantasai> drott: Do we remove the current ???
15:52:59 <fantasai> lea: yes
15:53:11 <fantasai> chris: Yes, that should all go
15:53:30 <fantasai> astearns: So we will add a font-technology() function with some amount of the keywords we've discussed
15:53:42 <fantasai> RESOLVED: remove "supports <font-technology>#"
15:53:57 <fantasai> florian: if we add format() to @supports, we have to add a font- prefix
15:54:09 <fantasai> florian: so shouldn't it be removed from font-technology() within src?
15:54:13 <fantasai> chris: Yes, let's be consistent
15:54:14 <fantasai> +1
15:54:16 <jfkthame> +1
15:54:24 <fantasai> lea: I thought one of the benefits was to be the same
15:54:31 <fantasai> astearns: but consistency is probably preferale
15:55:16 <fantasai> astearns: Any objections to technology()?
15:55:25 <florian> tech? capability?
15:55:27 <fantasai> fantasai: No, but I would prefer a shorter name if we can find one
15:55:29 <fantasai> lea: yes, please
15:55:39 <fantasai> RESOLVED: add technology() and open bikeshedding issue
15:55:45 <lea> given that Chrome needs to ship this soon, if we don't bikeshed soon, it's just de facto font-technology
15:56:33 <fantasai> RESOLVED: Add font-technology() and font-format() to @supports
15:56:45 <fantasai> with same syntax within the parentheses
15:56:55 <fantasai> drott: do we need both?
15:57:06 <florian> q+
15:57:09 <fantasai> astearns: prefer to add now, if ppl have objections can remove in the future, but seemed there were some use cases
15:57:55 <fantasai> florian: Point about "and" having two meanings, is it a concern?
15:58:12 <Morgan> Morgan has joined #css
15:58:14 <astearns> ack florian
15:58:16 <lea> what if we just add format-* keywords to font-technology()?
15:58:33 <fantasai> fantasai: You're "and"-ing over a single font file...
15:58:36 <Francis_Storr> Francis_Storr has joined #css
15:58:47 <fantasai> myles: The question is what if browser supports two different technologies, but not in the same font
15:59:05 <fantasai> florian: I guess you just choke on trying the use the download, which is wasteful but maybe not an issue
15:59:07 <dholbert> dholbert has joined #css
15:59:14 <fantasai> PeterCon: The example you gave was variable font with SVG table
15:59:21 <fantasai> PeterCon: likelihood of creating such a font is not great
15:59:31 <fantasai> myles: there's no way to describe variableness in SVG
16:00:03 <fantasai> Meeting closed.
16:00:24 <astearns> topic: none
16:00:49 <chris> now to try and find the "join meeting" button for the APA meeting
16:02:09 <nigel> nigel has joined #css
16:02:25 <Gottfried> Gottfried has joined #css
16:02:36 <astearns> zakim, end meeting
16:02:36 <Zakim> As of this point the attendees have been chris, lea, miriam, drott, jfkthame, dbaron, emilio, plinss, Vlad, jensimmons
16:02:38 <Zakim> RRSAgent, please draft minutes v2
16:02:38 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/20-css-minutes.html Zakim
16:02:41 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
16:02:46 <Zakim> Zakim has left #css
16:02:57 <jfkthame> jfkthame has left #css
16:03:05 <dholbert> is this next hour's meeting happening in regular csswg webex location?
16:03:33 <astearns> dholbert: no, in the TPAC session setting (Zoom)
16:03:35 <dholbert> (3 of us there right now, not sure if other folks are hopping on shortly or if we're in wrong spot)
16:03:36 <dholbert> aha
16:03:43 <astearns> there’s a message on the private list about connecting
16:03:57 <kzms2> kzms2 has joined #css
16:04:03 <astearns> https://www.irccloud.com/pastebin/iPpHqBPL/
16:04:38 <Morgan> Morgan has left #css
16:06:18 <dbaron> joint meeting with a11y using IRC #cssa11y, using the TPAC Zoom setup, logs at https://www.w3.org/2021/10/20-cssa11y-irc
16:07:48 <jensimmons> present+
16:13:51 <emilio> Hmm, I don't see a Join button for the tpac session even though I was registered... what am I doing wrong? :-)
16:16:46 <smfr> smfr has joined #css
16:20:05 <nigel> nigel has joined #css
16:32:44 <tantek> present+
16:36:59 <nigel> nigel has joined #css
17:01:22 <GameMaker> GameMaker has joined #css
17:42:11 <emeyer> emeyer has joined #css
18:22:23 <nigel> nigel has joined #css
18:54:23 <emeyer> emeyer has joined #css
18:55:20 <emeyer> emeyer has left #css
20:23:12 <nigel> nigel has joined #css
20:46:44 <jensimmons> jensimmons has joined #css
20:51:20 <emeyer> emeyer has joined #css
20:51:46 <emeyer> emeyer has left #css
22:24:49 <nigel> nigel has joined #css