15:58:59 <RRSAgent> RRSAgent has joined #css
15:58:59 <RRSAgent> logging to https://www.w3.org/2021/09/15-css-irc
15:59:02 <Zakim> RRSAgent, make logs Public
15:59:02 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:27 <jfkthame> jfkthame has joined #css
16:00:44 <jensimmons> present+
16:00:46 <rachelandrew> present+
16:00:48 <drott> present+
16:00:58 <Morgan> present+
16:01:06 <smfr> smfr has joined #css
16:01:09 <tantek> tantek has joined #css
16:01:15 <jfkthame> present+
16:01:15 <smfr> present+
16:01:16 <miriam> present+
16:01:27 <TYLin> present+
16:01:53 <dholbert> dholbert has joined #css
16:02:05 <chrishtr> present+
16:02:20 <cbiesinger> present+
16:03:06 <alisonmaher> alisonmaher has joined #css
16:03:08 <dandclark> present+
16:03:12 <alisonmaher> present+
16:03:22 <lea> lea has joined #css
16:03:27 <chris> chris has joined #css
16:03:29 <ffiori> ffiori has joined #css
16:03:38 <fantasai> scribenick: fantasai
16:03:41 <dlibby> dlibby has joined #css
16:03:44 <lea> present+
16:03:51 <oriol> oriol has joined #css
16:03:56 <dlibby> present+
16:04:06 <fantasai> Topic: Nesting @supports inside @font-face / font tech queries
16:04:11 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6520
16:04:34 <fantasai> chris: Basic problem is that we need a way to ensure that only one of the possible options works
16:04:50 <fantasai> chris: if you have unicode-range and a character outside that range, all the others will be loaded to see if it has that char
16:04:58 <fantasai> chris: so this has been paired with another issue
16:05:07 <fantasai> chris: It seems we need to discuss together
16:05:07 <oriol> present+
16:05:43 <TabAtkins> present+
16:05:51 <bkardell_> bkardell_ has joined #css
16:06:22 <bkardell_> present+
16:06:22 <fantasai> lea: Looks like primary problem with using @supports is that pattern
16:06:29 <bkardell_> present+
16:06:32 <fantasai> lea: of older code being unwrapped, but wrapping new code in @supports
16:06:37 <fantasai> lea: but that doesn't work well with @font-face
16:06:40 <chris> present+
16:06:46 <fantasai> lea: because the second rule doesn't override the first rule
16:06:53 <fantasai> lea: they combine to form a single family
16:07:05 <fantasai> lea: although normally only second font is used
16:07:14 <chris> q+ to add that the existing format overload does have the "only one wins" characteristic
16:07:18 <fantasai> lea: if browser encounters character not in the second, it will download the first to check if it is there
16:07:39 <fantasai> lea: so for this we would need an else condition
16:07:55 <fantasai> lea: so that we never have both @font-face rules in effect at the same time
16:08:10 <fantasai> lea: There's a proposal from Tab to combine feature queries and media queries, and has else
16:08:14 <drott> q+
16:08:18 <fantasai> lea: Tab suspects it's easy to implement
16:08:23 <dholbert> present+
16:08:33 <fantasai> lea: if this can be implemented together with font-technology(), that would be nice
16:08:41 <fantasai> lea: concern that if implement without it, we'll have this problematic pattern
16:08:47 <astearns> ack chris
16:08:47 <Zakim> chris, you wanted to add that the existing format overload does have the "only one wins" characteristic
16:09:22 <fantasai> chris: Overloading the format string does have this benefit of combining the conditionals properly
16:09:25 <lea> q?
16:09:30 <fantasai> chris: if we don't rapidly converge, we'll be stuck with that
16:09:47 <fantasai> astearns: So you're concerned to get if/else quickly so that practice doesn't ossify into bad syntax
16:10:04 <fantasai> chris: people will just ship what's in the spec now
16:10:16 <fantasai> myles: I thought we would remove the complicated resource grammar
16:10:23 <GameMaker> GameMaker has joined #css
16:10:27 <GameMaker> present+
16:10:37 <astearns> ack drott
16:10:54 <fantasai> drott: I spoke to implementers, to Anders and Rune who are familiar with our CSS code
16:11:04 <fantasai> drott: They have no immediate concerns with the when/else proposal
16:11:10 <fantasai> drott: Which brings my question of timing
16:11:15 <chris> \0/ to no concerns!
16:11:16 <fantasai> drott: I'm also supportive of removing the syntax in the spec now
16:11:27 <fantasai> drott: but eager to have something to enable font tech feature testing atm
16:12:01 <sideshowbarker> sideshowbarker has left #css
16:12:01 <fantasai> drott: We're supportive of the when/else proposal, but it would be better to have font tech queries soon and maybe when/else as an upgrade path
16:12:09 <emilio> present+
16:12:36 <fantasai> astearns: Is it possible to have a font-tech syntax in the @font-face that would handle the conditional?
16:12:46 <fantasai> drott: Current feature in spec is encapsulated in src descriptor
16:12:53 <fantasai> drott: in the format() function
16:13:07 <fantasai> drott: Authors can order it by most advanced tech, and then the UA will pick the one that it supports
16:13:16 <fantasai> drott: In current proposal, without @else we have an accumulation of fonts into the family
16:13:20 <lea> astearns: https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing
16:13:29 <lea> ^ that is the current syntax
16:13:50 <fantasai> astearns: Would it be possible to have a limited state for this font technology where you could put it into your @font-face and have a font face exist if the font technology was supported, but have it not exist if it wasn't
16:13:58 <fantasai> astearns: no fallback, just make this font face if the tech is supported
16:14:10 <fantasai> drott: You could use different families
16:14:19 <fantasai> lea: If you don't want fallback, that's fine. You just make an @font-face
16:14:32 <fantasai> astearns: so wanted to remove things from spec, remove the current syntax
16:14:37 <fantasai> astearns: in favor of clearer if/else
16:14:43 <fantasai> astearns: but people still want conditional on font
16:14:49 <fantasai> astearns: and it would be nice to have that font tech
16:14:58 <fantasai> chris: we need to do both
16:15:02 <fantasai> chris: for a solution
16:15:26 <drott> fantasai: I think we had previous notes on this, can't find it
16:16:20 <drott> fantasai: it was basically: we should have both, the font-technology function in @supports, and the ability to query the tech in the format function, and they should share the syntax. And the syntax should be simpler.
16:16:23 <astearns> s/would handle the conditional/would not handle the conditional with fallback/
16:17:09 <chris> q+
16:17:11 <drott> fantasai: for @supports, you might want to query not only if it's color, but you might want to query for format
16:17:35 <drott> fantasai: I would simplify the syntax of the font-technology function.
16:17:36 <drott> q+
16:18:07 <drott> fantasai: In a way to remove the sub functions, and just have a list of keywords, for example font-format-...
16:18:36 <fantasai> fantasai: ....
16:19:03 <fantasai> drott: I think you did post it somewhere, I had updated my pull request to flatten it...
16:19:11 <fantasai> chris: ...
16:19:38 <drott> q-
16:19:57 <lea> q?
16:19:59 <lea> q+
16:20:02 <fantasai> chris: The format shouldn't be the orphan that gets left behind that you have to do in src, it should be same conditional thing that we do in font-technology
16:20:12 <fantasai> chris: so if woff5 comes along, we can also put that in this new shiny syntax
16:20:13 <astearns> ack chris
16:20:30 <drott> fantasai: it should be the same function, for format and font technology
16:20:37 <sanketj> sanketj has joined #css
16:20:48 <chris> I don't really like calling it font-format
16:20:54 <fantasai> lea: If I understand correctly, a format should also have been a condition in @supports
16:21:00 <chris> yes exactly lea
16:21:06 <fantasai> lea: if designing today that's how we would do that
16:21:14 <fantasai> lea: only reason we have format function is that it's legacy
16:21:44 <chris> we can't get *rid* of the format legacy though, so it has to remain in the spec
16:21:47 <fantasai> lea: so I think what Chris is saying is that we also need to be adding a font-format() function into @supports so that authors can combine @font-technology queries
16:22:09 <fantasai> lea: whereas what fantasai is saying is to have only format() function, and have it allowed both in src and @supports
16:22:34 <fantasai> s/chris: .../lea: I think that was my proposal to flatten from color() to color-/
16:22:55 <fantasai> astearns: So we're looking for a way to express simper supports queries in @font-face rules
16:23:12 <fantasai> astearns: and remove fallback ability
16:23:20 <drott> fantasai: I think we're not aiming to remove fallback
16:23:43 <fantasai> chris: The things that drott proposed, it would be helpful to allow that as a direct query in @supports conditions
16:23:57 <fantasai> myles: I think adding that should be blocked on having some way of solving the problem that jfkthame described
16:24:00 <drott> q+
16:24:05 <astearns> ack lea
16:24:06 <fantasai> astearns: ?
16:24:18 <fantasai> lea: No way to do else, so authors will need to negate their queries
16:24:23 <fantasai> lea: and it would get very verbose and complicated
16:24:29 <fantasai> myles: not even sure if it's possible
16:24:42 <fantasai> myles: because there's a third value here, not just supported or not supported, but also case of "browser doesn't know what you're talking about"
16:25:04 <fantasai> chris: So need a resolution on proposal, but also how do we move forward on Tab's draft
16:25:09 <fantasai> chris: Can we adopt it as an ED?
16:25:19 <fantasai> myles: We should split this font-specific issue
16:25:24 <fantasai> myles: one piece blocked on else rule and one that isn't
16:25:27 <drott> q?
16:25:30 <fantasai> myles: and discuss else rule in its own CSSWG issue
16:25:36 <astearns> ack drott
16:25:51 <fantasai> drott: I discussed this issue with jfkthame offline. I think he's here?
16:26:00 <chris> this is its issue: https://github.com/w3c/csswg-drafts/issues/112
16:26:00 <fantasai> drott: In our question, jfkthame expressed some flexibility regarding timing
16:26:23 <fantasai> drott: I'd like to emphasize what chris was saying earlier, if we move the supports syntax from CSS as it is now, then we don't have anything to do feature testing
16:26:32 <fantasai> drott: I consider @supports an upgrade path
16:26:49 <fantasai> myles: I've heard some people say they want to remove unimplemented flexbility in the spec now, and others don't want to remove it but to reformulate to make it simpler
16:26:53 <fantasai> myles: either one is reasonable to me
16:27:10 <fantasai> lea: which part is blocked on what?
16:27:41 <fantasai> myles: If we want to keep the unimplemented features of the format() in src, we wouldn't need to be blocked on else
16:27:52 <TabAtkins> It is true that `@supports unknown-font-thing() {...} @support not (unknown-font-thing()) {...}` will fail to match both of them (the first is unknown, treated as false; the second is negated unknown, which is still unknown and thus treated as false)
16:28:02 <fantasai> lea: the problem with that is that we don't want microsyntaxes
16:28:07 <TabAtkins> whereas `@support unknown-font-thing() {...} @else {...}` would match one or the other, guaranteed.
16:28:11 <lea> q+
16:28:20 <astearns> ack lea
16:28:28 <fantasai> lea: Important point from the issue drott raised hasn't be raised yet
16:28:37 <fantasai> lea: else is syntactic sugar for negation
16:28:43 <fantasai> lea: but another way to work around is to use unicode-range
16:28:59 <fantasai> lea: drott mentioned that most font-face rules are generated, and have unicode-range alreay
16:29:02 <fantasai> lea: which means this isn't a problem
16:29:10 <fantasai> myles: unicode-range is an orthogonal feature
16:29:20 <TabAtkins> Oh wait, sorry, I was wrong - @supports doesn't use the unknown value.
16:29:23 <fantasai> myles: if author is trying to use fancy syntax that is / isn't supported
16:29:24 <TabAtkins> We resolved on that a bit ago.
16:29:34 <fantasai> myles: both @font-face rule and fallback will have the same unicode-range
16:29:35 <TabAtkins> Unknown things are just false in @supports.
16:29:38 <fantasai> myles: so the problem still applies
16:29:57 <fantasai> lea: Problem is if the character is not included in the range
16:30:13 <fantasai> myles: problem that I'm concerned about is that character is inside the unicode-range block, but not supported by the font's CMAP table
16:30:20 <fantasai> myles: in that case the browser will download both fonts serially
16:30:34 <fantasai> drott: Should have unicode-range identical to CMAP
16:30:46 <TabAtkins> So my statement above was wrong - both are equivalent, and you'll definitely select one or the other. (We use unknown for @media, where the browser very well *might* match an unknown query once it starts supporting it; a browser that doesn't understand a feature, by definition, doesn't support it, so that's a safe `false`.)
16:31:14 <drott> fantasai: Lea was concerned about multiple different microsyntaxes. My proposal doesn't do that. Format function, should have identical syntax, whether it's in src: or in @supports.
16:31:21 <lea> q+
16:31:26 <astearns> ack fantasai
16:31:37 <drott> fantasai: If that's the case, we can ship src: first - ship @supports version later.
16:31:39 <drott> q+
16:31:43 <astearns> ack lea
16:31:47 <fantasai> lea: There's another unexplored option
16:31:56 <fantasai> lea: what if we had an inline conditional function that does supports queries
16:32:24 <fantasai> lea: A supports() or supports-if() function to put inside any value
16:32:36 <fantasai> astearns: I think it would be a good idea to write down what you're suggesting, Lea
16:32:52 <fantasai> astearns: but getting a proliferation of options, unsure we can get to resolution on anything specific today
16:32:53 <astearns> ack drott
16:33:17 <fantasai> astearns: I think we can resolve at least that we would like to work on the if/else syntax
16:33:33 <fantasai> TabAtkins: Adopt as an ED in the WG? Currently draft in my personal repo
16:33:33 <lea> +1 to working on @else proposal
16:33:40 <jfkthame> +1
16:33:40 <fantasai> astearns: resolution would be to adopt, yes
16:33:55 <fantasai> fantasai: so that would be css-conditional-3?
16:33:57 <fantasai> TabAtkins: sure
16:33:58 <drott> q+
16:34:06 <astearns> ack drott
16:34:18 <fantasai> drott: potentially add any resolution, then idea would be to have a font-tech function to combine with that?
16:34:47 <TabAtkins> I also was udner the impression that Conditional started with 1.
16:34:57 <fantasai> dbaron[m]: I think conditional-3 is already advanced
16:34:58 <drott> +1 to that.
16:35:06 <fantasai> fantasai: oh, I meant whatever's next
16:35:36 <drott> sorry, fantasai, I did not capture what you said.
16:35:44 <fantasai> RESOLVED: Adopt if/else as next level of css-conditional
16:36:16 <fantasai> astearns: So question of current font-technology draft and reworking them with existence of if/else in mind
16:36:24 <fantasai> astearns: so take back to issue to determine what changes, if any, need to be made
16:36:27 <fantasai> chris: I don't see a dependency there
16:36:33 <fantasai> chris: I think we can adopt PR as-is
16:36:39 <drott> +1 as well
16:36:41 <fantasai> lea: +1
16:36:46 <fantasai> lea: this is something useful immediately
16:36:49 <TabAtkins> +1
16:36:53 <drott> zes
16:36:58 <fantasai> astearns: Adopting PR will resolve the issue?
16:37:01 <drott> s/zes/yes
16:37:01 <fantasai> lea: the bulk of it
16:37:16 <fantasai> astearns: And we can open new more tightly constrianed issues
16:37:40 <fantasai> astearns: So proposed resolution?
16:38:04 <fantasai> drott: Adds font-technology() function to @supports, which has a flat list of font technologies and options, which can be used inside an @supports rule
16:38:19 <drott> https://github.com/drott/csswg-drafts/commit/62cfd95a5f52604c952e4aa37be6e4d6386f88f5
16:38:22 <fantasai> myles: the @else rule should make it clear that it works with this new query inside @supports
16:38:28 <fantasai> myles: either explicitly or implicitly
16:38:45 <bradk> bradk has joined #css
16:38:46 <fantasai> myles: And i'd ask implementers not to implement font-technology() without @else
16:38:59 <fantasai> myles: because if you oonly give ability to do it wrong, people will do it wrong
16:39:02 <fantasai> lea: why?
16:39:04 <dbaron[m]> That request to implementers should be in the spec.
16:39:10 <fantasai> myles: because @else is the solution to this problem, so one depends on the other
16:39:11 <jensimmons> +1 to myles
16:39:26 <lea> s/lea: why?/lea: they can still do it right, it's just tedious/
16:39:38 <drott> fantasai: I am not sure, I agree with this particular PR.
16:39:59 <dbaron[m]> s/sure,/sure/
16:40:14 <drott> fantasai: I think the function should have identical syntax to what we should have in src:.
16:40:19 <drott> q+
16:40:28 <bradk> present+
16:40:51 <drott> fantasai: one question I have: font-technology - would this be allowed to be queries in src:?
16:41:01 <drott> s/queried/queries
16:41:10 <drott> s/queried/queries/
16:41:37 <fantasai> astearns: I think we should merge it in and take separate issues
16:41:44 <fantasai> chris: I edit both specs anyway
16:41:51 <drott> +1 to that, if we can have the font-technology PR
16:41:53 <fantasai> myles: but if we're making src less flexible than it is to day (in ths spec)
16:42:00 <astearns> ack drott
16:42:37 <fantasai> fantasai: happy to do so, as long as we can work on it and not just ship what's in the PR
16:42:46 <chris> @drott I see the PR on your fork repo but not the one on the csswg repo
16:42:53 <fantasai> myles: I think it's OK to resolve this, I think fantasai's idea about making them match makes sense to me
16:43:08 <fantasai> myles: I think making them match gives drott a path to implementing that doesn't rely on us standadizing a big new feature
16:43:12 <fantasai> myles: so I think that's the best path forward
16:43:32 <fantasai> astearns: we're not got to solve everything today
16:43:41 <fantasai> astearns: so let's merge the PR and file more issues
16:43:43 <drott> +1
16:43:45 <lea> +1
16:43:49 <chris> +1
16:43:50 <fantasai> astearns: any objections?
16:43:58 <fantasai> RESOLVED: Accept the PR
16:44:22 <chris> :)
16:44:27 <fantasai> myles: Can we add a note to the PR to say "don't implement this yet, implement this other thing first"
16:44:31 <fantasai> astearns: open an issue
16:44:46 <fantasai> Topic: multicol
16:45:15 <rachelandrew> https://docs.google.com/document/d/1VH00m6Kye7GyagkHFrOLh4MsR9HAj2XN_qqg209IOUE/edit?usp=sharing
16:45:16 <fantasai> rachelandrew: We've been doing a bunch of work from css-multicol-1, took it from CR to WD to work on it
16:45:25 <fantasai> rachelandrew: That's my notes on preparing to take back to CR
16:45:40 <fantasai> rachelandrew: I've had horizontal review from everyone except security, who hasn't responded since 12 May
16:45:43 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6612
16:45:45 <fantasai> rachelandrew: but don't expect any issues
16:45:51 <fantasai> rachelandrew: obviously we have wide implementation of this spec already
16:45:55 <fantasai> rachelandrew: after CR need to sort out test suite
16:46:11 <fantasai> rachelandrew: There's a column which details the larger changes that I don't think have tests yet, but need to check since browser vendors have been doing work
16:46:20 <fantasai> rachelandrew: so would like to get approval to move to CR
16:46:22 <fantasai> +1
16:46:28 <florian> +1
16:46:31 <rachelandrew> will do
16:46:49 <fantasai> astearns: any objections?
16:46:57 <fantasai> RESOLVED: Transition css-multicol-1 back to CR
16:47:00 <fantasai> \^_^/
16:47:14 <jensimmons> yay!! I know it's been a ton of work...
16:47:19 <fantasai> Topic: css-background-3
16:47:25 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6586
16:47:44 <drott> chris: > @drott I see the PR on your fork repo but not the one on the csswg repo I'll turn it into a PR visible on the CSSWG repo.
16:47:45 <fantasai> smfr: Spec allows specifying a corner and an offset from that corner
16:47:53 <fantasai> smfr: spec doesn't specify
16:47:58 <fantasai> smfr: WebKit serializes as inputted
16:48:02 <fantasai> smfr: Gecko serializes calc()
16:48:26 <drott> fantasai: we already did discuss this - that's the way the serialized value is the way it is.
16:48:53 <drott> fantasai: you could possibly map the values of varying percentages to keywords.
16:48:56 <fantasai> s/serialized/computed/
16:49:27 <myles> myles has joined #css
16:49:30 <drott> fantasai: it's said that it's a length/percentag value per axis. there's no way to distinguish if somebody specified calc() of a value
16:49:48 <drott> fantasai: we had discussed this before: main concern would be: in the future we would have logical keywords
16:50:03 <drott> fantasai: with that, the computed value for background-position would become more complicated
16:50:34 <drott> fantasai: i don't have a strong opinion on it because of what we plan for in the future.
16:51:31 <fantasai> fantasai: spec is clear, in the "computed value" line
16:51:35 <emilio> I agree this falls from the "Computed Value" definition
16:52:00 <fantasai> TabAtkins: Since it confused some people, maybe a note to highlight that this information is lost would be helpful
16:52:35 <fantasai> smfr: I just wanted to follow link to where it's clear...
16:53:00 <fantasai> TabAtkins: as a combination of lengths and percentages, you'd have to use calc()
16:53:19 <fantasai> dbaron[m]: other principle is use most backwards-compatible syntax, and at least in Gecko calc() predated the background-position extended syntax
16:53:45 <fantasai> astearns: Suggest closing issue by adding a note to css-backgrounds-3 and maybe also values and units
16:53:48 <fantasai> smfr: wfm
16:53:59 <fantasai> RESOLVED: Add a note
16:54:15 <fantasai> astearns: no normative change, but we will explain why
16:54:27 <fantasai> Topic: Serialization of empty url()
16:54:33 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6447
16:54:47 <fantasai> smfr: CSS Values talks about empty URLs and how we avoid normal behavior of resolving against stylesheet URL
16:54:51 <fantasai> smfr: empty treated as involved
16:55:05 <fantasai> smfr: and we introduced "about:invalid" as a URL
16:55:10 <fantasai> smfr: which is what Gecko serializes
16:55:18 <fantasai> smfr: ??? serializes the resolved URL which is wrong
16:55:24 <fantasai> smfr: but I think empty URLs serialize as such
16:55:38 <fantasai> TabAtkins: That was my intention, and I'm happy to adjust spec to make it clearer
16:55:47 <fantasai> smfr: Also do we serialize as url() or url("")
16:55:54 <fantasai> TabAtkins: I think completely empty URL, is that even valid?
16:56:24 <fantasai> fantasai: it is valid, just tested
16:56:26 <drott> fantasai: it is valid, i just tested
16:56:32 <fantasai> TabAtkins: That would be a serialization nobody uses
16:56:44 <fantasai> TabAtkins: so I lean toward url("") because at least one browser is doing that currently
16:56:51 <fantasai> emilio: Who?
16:56:55 <fantasai> TabAtkins: whoever is passing that test
16:57:04 <fantasai> emilio: smfr updated the test to use empty string
16:57:14 <fantasai> emilio: but Firefox serializes as about:invalid and I don't know what WebKit and Blink do
16:57:23 <smfr> https://wpt.fyi/results/css/css-values/urls/empty.html?label=experimental&label=master&aligned
16:57:46 <fantasai> TabAtkins: nevermind, nobody passes that
16:57:55 <fantasai> smfr: Test expect everything becomes quoted
16:58:21 <fantasai> TabAtkins: let me see if CSSOM specifies anything
16:58:33 <fantasai> TabAtkins: yes, CSSOM expects all URL functions to contain a string
16:58:39 <emilio> https://drafts.csswg.org/cssom/#serialize-a-url
16:58:41 <fantasai> TabAtkins: regardless of whether inputted with or without quotes
16:58:47 <TabAtkins> https://drafts.csswg.org/cssom/#serialize-a-url
16:58:55 <fantasai> TabAtkins: so for consistency, empty url() should also serialize with quotes
16:59:05 <fantasai> astearns: so proposed resolution is to make this test valid, using quoted empty string?
16:59:16 <fantasai> emilio: before we resolve, I wanted to make an argument for url()
16:59:28 <fantasai> emilio: if you consider invalid URL not a URL
16:59:33 <fantasai> emilio: but I'm fine
16:59:52 <fantasai> astearns: If you're fine with the explicitly quoted empty string, I think it makes much more sense, it's consistent
16:59:56 <fantasai> astearns: any objections?
17:00:05 <fantasai> RESOLVED: serialize as url("")
17:01:06 <TabAtkins> myles: I didn't quite catch it, but is your reasoning about wanting @else *before/alongside* font-supports() becuase of the "unknown value" issue making negation hard?
17:02:53 <emeyer> emeyer has left #css
17:05:38 <lea> TabAtkins: am I reading your draft right that @else can also directly follow an @supports or @media, and not just an @if?
17:05:45 <TabAtkins> yes
17:06:13 <astearns> zakim, end meeting
17:06:13 <Zakim> As of this point the attendees have been jensimmons, rachelandrew, drott, Morgan, jfkthame, smfr, miriam, TYLin, chrishtr, cbiesinger, dandclark, alisonmaher, lea, dlibby, oriol,
17:06:16 <Zakim> ... TabAtkins, bkardell_, chris, dholbert, GameMaker, emilio, bradk
17:06:16 <Zakim> RRSAgent, please draft minutes v2
17:06:16 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/15-css-minutes.html Zakim
17:06:18 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:06:22 <Zakim> Zakim has left #css
17:06:27 <TabAtkins> I didn't want @if to be "the new conditional rule" replacing all the others
17:06:48 <TabAtkins> it's just needed to get else-chaining working properly when you're querying across feature sets
17:08:18 <gsnedders> gsnedders has joined #css
17:08:28 <plinss> plinss has joined #css
17:08:28 <dbaron[m]> dbaron[m] has joined #css
17:09:02 <myles> @TabAtkins: how would someone use @supports without @else to use a color font on a browser that supports it, but use a fallback font instead if the browser doesn't?
17:09:35 <TabAtkins> I said up above (in IRC, not on phone) - @supports doesn't use the unknown value. Unknown things are just false, so you can negate them normally.
17:10:21 <TabAtkins> Or I should say, *unrecognized* things are false, to avoid confusion. ^_^
17:11:44 <myles> @TabAtkins: so if the author says "@supports colorfonts { @font-face { colorfont } } @supports not colorfonts { @font-face { notcolorfont } }" you're saying that this will work?
17:11:56 <TabAtkins> yup
17:12:07 <TabAtkins> at least per spec!
17:13:03 <TabAtkins> (well, that exact syntax actually violates the grammar so both would be thrown out as invalid rules, but wrap those suckers in parens or turn them into functions and you're golden)
17:17:05 <lea> That's nice, I was going to suggest it actually
17:17:49 <lea> oh wait, you're replying to Myles, not me
17:18:29 <lea> reading higher up, comment still applies though, nice nice :)
17:20:24 <myles> @TabAtkins: yeah, when this topic first came up to the WG i asked if this was possible and the WG said no
17:21:02 <TabAtkins> Yeah, I think that's what prompted us to decide that @supports doesn't use the unknown bool
17:22:06 <TabAtkins> Because if a browser doesn't understand a syntax, it doesn't understand the feature (and the chance of disconnect when a specialized supports syntax is added well after a feature is implemented was considered not worth worrying about)
17:22:19 <myles> https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-905712330
17:22:22 <TabAtkins> (I could be misremembering the ordering tho)
17:22:30 <myles> @TabAtkins: <TabAtkins> myles: One question - if an author uses @supports, is there a way to say "else"? | <TabAtkins> myles: If there's not a way to do that... @font-faces join together to form a family, rather than overriding
17:23:24 <TabAtkins> yeah, i misremembered during that meeting, sorry
17:40:12 <castastrophe> castastrophe has joined #css
17:59:00 <liam> liam has joined #css
18:39:35 <Seirdy> Seirdy has joined #css
19:23:16 <projector> projector has joined #css
19:23:47 <leaverou> leaverou has joined #css
19:24:17 <Rossen> Rossen has joined #css
19:24:47 <shans> shans has joined #css
19:25:18 <sylvaing> sylvaing has joined #css
20:05:48 <GameMake_> GameMake_ has joined #css
20:15:15 <freeworld> freeworld has joined #css
20:35:36 <castastrophe_> castastrophe_ has joined #css
20:58:15 <jfkthame> jfkthame has joined #css
21:45:38 <jfkthame> jfkthame has joined #css
22:13:02 <bkardell_> bkardell_ has joined #css
23:52:27 <castastrophe_> castastrophe_ has joined #css