16:53:48 <RRSAgent> RRSAgent has joined #css
16:53:52 <RRSAgent> logging to https://www.w3.org/2024/11/13-css-irc
16:53:52 <Zakim> RRSAgent, make logs Public
16:53:53 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:56:05 <stepheckles> stepheckles has joined #css
16:56:14 <SebastianZ> SebastianZ has joined #css
16:56:31 <moonira> moonira has joined #css
16:57:11 <stepheckles> present+
16:57:23 <joshtumath> joshtumath has joined #css
16:58:02 <castastrophe> castastrophe has joined #css
16:58:07 <castastrophe> present+
16:58:45 <romain> romain has joined #css
16:58:57 <PaulG> PaulG has joined #css
16:59:07 <PaulG> present+
16:59:17 <SebastianZ> present+
17:00:13 <romain> present+
17:00:21 <joshtumath> present+
17:00:36 <ydaniv> ydaniv has joined #css
17:01:02 <kbabbitt> kbabbitt has joined #css
17:01:19 <noamr> noamr has joined #css
17:02:01 <noamr> present+
17:02:09 <kbabbitt> present+
17:02:13 <dholbert> dholbert has joined #css
17:02:13 <fantasai> present+
17:02:17 <dholbert> present+
17:02:17 <gfaujdar> gfaujdar has joined #css
17:02:20 <oriol> oriol has joined #css
17:02:27 <TabAtkins> present+
17:02:33 <ydaniv> present+
17:02:38 <schenney> schenney has joined #css
17:02:40 <kizu> kizu has joined #css
17:02:44 <schenney> present+
17:02:50 <moonira> present+
17:02:53 <kizu> present+
17:02:59 <fantasai> Topic: Administrative
17:03:01 <TabAtkins> ScribeNick: TabAtkins
17:03:11 <smfr> smfr has joined #css
17:03:19 <gfaujdar> present+
17:03:23 <ChrisL> present+
17:03:26 <jfkthame> jfkthame has joined #css
17:03:31 <oriol> present+
17:03:37 <fantasai> Subtopic: F2F Scheduling
17:03:39 <jfkthame> present+
17:03:45 <fantasai> -> https://app.rallly.co/invite/ShjWRuGtqnQG
17:03:51 <TabAtkins> Rossen0: reminder about the poll for the Winter f2f
17:04:23 <TabAtkins> fantasai: I think we should be able to close the poll next Wednesday, we ahve al ot of answers
17:04:30 <TabAtkins> fantasai: leading candidates are feb 6 and march 13 weeks
17:04:31 <stepheckles> stepheckles has joined #css
17:05:07 <emilio> present+
17:05:17 <lea> lea has joined #css
17:05:24 <fantasai> ... and feb 20th
17:05:41 <fantasai> Subtopic: Publication Requests
17:05:53 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2461115768
17:06:10 <TabAtkins> ChrisL: bot takes off agenda+ when we discuss one, so we'd missed a few
17:06:21 <TabAtkins> Rossen0: first is View Transitions 2, new WD
17:06:52 <fantasai> https://drafts.csswg.org/css-view-transitions-2/#changes
17:06:52 <TabAtkins> fantasai: I think for a bunch of these, there's been enough changes to make sure everyone's on board
17:06:52 <Rossen0> https://github.com/w3c/csswg-drafts/commits/main/css-view-transitions-2/Overview.bs
17:07:00 <fantasai> -> https://drafts.csswg.org/css-view-transitions-2/#changes
17:07:00 <TabAtkins> Rossen0: here's the change log
17:07:23 <ChrisL> +1
17:07:54 <miriam> present+
17:07:55 <noamr> ack fantasai
17:08:19 <fantasai> +1 to publishing
17:08:24 <TabAtkins> +1 to publish
17:08:44 <TabAtkins> RESOLVED: Publish new WD of View Transitions 2
17:08:58 <TabAtkins> Rossen0: next is Pseudo 4
17:09:07 <fantasai> -> https://drafts.csswg.org/css-pseudo-4/#changes
17:09:18 <TabAtkins> ChrisL: dglazman is listed as an editor and he's no longer in the WG
17:09:33 <TabAtkins> Rossen0: think we should just move him to former editor as we repub
17:09:42 <TabAtkins> fantasai: change log isn't as long as it looks
17:09:46 <TabAtkins> fantasai: 8 items
17:10:06 <TabAtkins> fantasai: changes are defining "element-backed" and "fully-stylable" pseudo-elements
17:10:20 <TabAtkins> fantasai: a bunch of reworking of what proeprties apply to highlight pseudos and how they cascad/einherit
17:10:26 <TabAtkins> fantasai: added search-text and details-content
17:10:58 <TabAtkins> stephan?: i think i had some open PRs...
17:11:02 <TabAtkins> fantasai: i believe i merged them
17:11:18 <TabAtkins> s/stephan\?/szager/
17:11:22 <TabAtkins> fantasai: i'll handle publication
17:11:33 <TabAtkins> Rossen0: objections to repub?
17:12:03 <TabAtkins> RESOLVED: Repub Pseudo 4, move glazman to former editor
17:12:21 <schenney> Big thanks for this one.
17:12:30 <ChrisL> https://drafts.csswg.org/css-nesting/#changes
17:12:43 <TabAtkins> Rossen0: link to changes in IRC
17:12:50 <fantasai> -> https://drafts.csswg.org/css-nesting/#changes
17:12:56 <flackr> present+
17:13:55 <TabAtkins> [discussion on the last two bullet points of change slist being confusing, sicne they affect each other]
17:14:09 <TabAtkins> Rossen0: objections to publishing?
17:14:20 <fantasai> [should merge them so that the changes list reflects diff against last WD]
17:14:21 <TabAtkins> RESOLVED: Publish new WD of Nesting
17:14:33 <fantasai> Topic: CSS Snapshot
17:14:59 <TabAtkins> github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/9770
17:14:59 <github-bot> Subtopic: [css-2024] Add specs to Official Definition
17:14:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9770.
17:15:32 <alisonmaher> alisonmaher has joined #css
17:15:33 <Rossen0> ack fantasai
17:15:36 <alisonmaher> present+
17:15:42 <TabAtkins> fantasai: high-level comment. reason for the snapshot was becasue the status of our specs didn't alway sreflect the actual stability
17:15:48 <TabAtkins> fantasai: we'd have a WD that's basically a Rec, etc
17:15:54 <TabAtkins> fantasai: was confuising, people didn't know stability
17:16:05 <TabAtkins> fantasai: what we ended up with in the snapshot is 3 lists, i think i'm gonna propose 4 lists
17:16:30 <TabAtkins> fantasai: we've got "official definition", that's the list of "these are (basically) Recs". some actually Recs, others are same stability level, just waiting on some bugfixes or minor issues
17:16:40 <TabAtkins> fantasai: usually blocker is missing an impl report
17:16:59 <TabAtkins> fantasai: then we have two lists, one is "these are pretty stable, maybe not enough impl experience, but not really changing"
17:17:12 <TabAtkins> fantasai: and "spec is a mess but impls are shipping and roughly interoperable"
17:17:17 <TabAtkins> fantasai: poster child is Transitions & Animations
17:17:26 <TabAtkins> fantasai: tons of issues, but people wer eshipping and they were widely used
17:17:44 <TabAtkins> fantasai: so we have Rec-levle, CR-level with limited impl, and CR-level impl with limited spec
17:18:05 <TabAtkins> fantasai: might want a fourth list of "spec is pretty stable, largely implemented, largely reliable for use"
17:18:26 <TabAtkins> fantasai: probably a lot of our specs should be there
17:18:55 <TabAtkins> fantasai: so i propose we add this new list as the second list (in order) in the snapshot
17:19:31 <TabAtkins> florian: altho it's more things, i do think it's simpler overall. too many things that don't fit well in any of our three categories
17:19:31 <dbaron> does this mean there are now 2 axes rather than 1?
17:20:03 <TabAtkins> ChrisL: i think it makes sense to go thru what Sebastian has done, then go thru th enew category. would rather see that in an ED and then we can move around
17:20:19 <TabAtkins> florian: I might be opposed to some of the moves, becuase it's the wrong place; the right place will be the new category
17:20:25 <TabAtkins> fantasai: yeah that's why i brought it up too
17:20:54 <TabAtkins> dbaron: does this new category mean we're classifying on 2 rather than 1 axis? if so, what?
17:21:03 <TabAtkins> fantasai: we've always been categorizing, just missing this quadrant
17:21:09 <TabAtkins> fantasai: how stable is spec, how stable is impl
17:21:34 <TabAtkins> florian: we had "both great", "impl good, spec bad", and "spec good, impl not". didn't have "both good (but not done)"
17:22:12 <TabAtkins> fantasai: rough interop was "we have interop but spec doesn't reflect that"
17:22:24 <TabAtkins> fantasai: we just need one where we ahve interop and spec does roughly match
17:22:51 <TabAtkins> dbaron: so we had a category for "impl 1, spec 1", "impl 1, spec 0", and "impl 0, spec 1". this new one is "impl 1/2, spec 1/2"
17:23:05 <TabAtkins> fantasai: roughly, yeah. (quibble on the exact numbers, but idea is right)
17:23:25 <TabAtkins> Rossen0: so it fits the model. my proposal is we go thru the list of specs we have currently here.
17:24:48 <TabAtkins> SebastianZ: first is MQ4, current is CRD, last published 2021
17:25:02 <TabAtkins> SebastianZ: lots of tests for this spec, interop is very good
17:25:09 <TabAtkins> SebastianZ: 98%
17:25:17 <TabAtkins> SebastianZ: but still some open gh issues
17:25:38 <TabAtkins> florian: i suspect it's really good in terms of syntax, but MQs are notably hard to test
17:25:54 <TabAtkins> florian: i suspect there are still quite a few media features that are good ideas but not particularly tested or implemented
17:26:12 <TabAtkins> florian: i'm unsure, for example, of overflow-block/inline, unsure about how close reality is for the hover/pointer ones
17:26:13 <fantasai> 4 categories: REC-like, reliable spec + implementation, low-experience CR, implemented + badly specced
17:26:25 <fantasai> s/implemented/shipping/
17:26:31 <TabAtkins> SebastianZ: we'd need to check on that, i was just collecting data around open issues and tests
17:26:38 <TabAtkins> SebastianZ: didn't check every feature in those specs
17:26:53 <TabAtkins> florian: i know for a long time we were lackign impl and coverage for some features. we might have improved, just not sure where we are now.
17:27:08 <TabAtkins> ChrisL: i noticed mq4 doesn't have wpt annotations, that would have helped
17:27:12 <fantasai> A) REC-like; B) reliable spec + implementations; C) low-experience CR; D) shipping + badly specced
17:27:26 <TabAtkins> florian: for MQ syntax we should have this, no question. but many media features are basically not testable in an autoamtic manner
17:27:36 <TabAtkins> florian: so not just lacking annotation, lacking *tests*
17:27:48 <TabAtkins> florian: it's "run this on a device with these cahracteristics, and see if it works"
17:28:00 <TabAtkins> dbaron: in theory we might eventually want to show that there *is* some impl or device that does each value
17:28:14 <TabAtkins> florian: i know we weren't there for a long time, might have gotten there while i wasn't looking
17:28:28 <TabAtkins> florian: also i'm listed as a co-editor, and i don't dislike that, but i'm no longer sponsored for it
17:29:00 <TabAtkins> florian: i just suspect that until we can properly audit, we can't move it.
17:29:05 <TabAtkins> florian: suspect it's good but can't show it
17:29:14 <TabAtkins> fantasai: we *could* move it into the new category, reliable spec + impls
17:29:19 <TabAtkins> florian: maybe. parts of it at least
17:29:27 <TabAtkins> fantasai: i'm fine either way
17:29:52 <TabAtkins> SebastianZ: two options, one is to defer it, and add wpt tests so we can see what's covered and what still needs coverage
17:29:55 <TabAtkins> SebastianZ: other is to add it to th enew list
17:30:01 <TabAtkins> SebastianZ: no strong opinion
17:30:18 <TabAtkins> Rossen0: just saying that having 98% interop on what's already tests is great
17:30:25 <TabAtkins> fantasai: but if it's jsut testing parsing that's not much
17:30:36 <TabAtkins> Rossen0: if there are missing tests, that's on us
17:30:47 <TabAtkins> Rossen0: if i'm being a neutral observer, it seems like a spec tha'ts moving along well
17:31:00 <TabAtkins> Rossen0: whatever's put in a test case impls are doing, that's great
17:31:50 <TabAtkins> florian: i don't know if that's useful, the tests aren't a bar *we* set, they're mostly written by the impls
17:32:01 <TabAtkins> florian: passing a lot of tests without evaluating coverage, i don't know if it's saying anything useful
17:32:15 <jensimmomns> jensimmomns has joined #css
17:32:32 <TabAtkins> florian: recentlyw e almost pushed Scrollbars to rec, everyone had super high test rates despite Safari not implementing it *at all*
17:32:33 <jensimmons> jensimmons has joined #css
17:32:57 <TabAtkins> Rossen0: I get that, but if you're an editor and not seeing enough coverage, we can say that and outline what parts aren't covered
17:33:16 <TabAtkins> florian: for MQ4 i'm saying this was the case a few years ago, last I checked. if somebody fixed it more recently I dunno.
17:33:27 <TabAtkins> Rossen0: so I'm looking at Sebastian as someone who's looked at this more recently
17:33:36 <TabAtkins> SebastianZ: i didn't check all the features, i checked a few in each spec
17:33:47 <TabAtkins> SebastianZ: that's why i put it on th elist to add it to the official definition
17:34:14 <TabAtkins> fantasai: i think unless we have some evidence that the behavior is implemented correctly (not just parsing and OM), we can't reasonably put it in rec-like section
17:34:25 <TabAtkins> florian: i just checked - some features that didn't have tests before still don't
17:34:34 <TabAtkins> Rossen0: so are we moving at all? or leaving it?
17:34:54 <TabAtkins> florian: we could move it to the new bucket, it has some sections that are stable but some that aren't. so either leave it or put it in th enew bucket
17:35:04 <TabAtkins> Rossen0: so here's ane xample of a spec which'll have the new bucket
17:35:58 <TabAtkins> SebastianZ: let's still continue on this one
17:36:17 <TabAtkins> fantasai: next is SCroll Snap, i think this is meaningfully implemented everywhere. not 100% interop, and some minor issues.
17:36:45 <TabAtkins> fantasai: i'd say this should move either into the "reliable CR" section, and probably next year if we resovle the remaining issues we can put it in "reliable Rec" section
17:36:59 <TabAtkins> Rossen: so scroll snap should move to "reliable CR" new bucket?
17:37:16 <TabAtkins> Rossen0: we have two candidates already, let's just resolve on the new bucket
17:37:21 <TabAtkins> ChrisL: let's
17:37:44 <TabAtkins> Rossen0: anyone objecting to adding this new bucket?
17:37:53 <TabAtkins> fantasai: I'll call it "reliable CR" as shorthand, work on wording later
17:37:56 <fantasai> A) REC-like; B) reliable spec + implementations; C) low-experience CR; D) shipping + badly specced
17:38:14 <TabAtkins> SebastianZ: no objection, just wondering if some specs in A would fit into B instead
17:38:31 <DavidA> DavidA has joined #css
17:38:33 <TabAtkins> Rossen0: we can see what goes in it once we have it
17:38:46 <TabAtkins> RESOLVED: Add new category, shorthanded as "reliable CR"
17:39:20 <TabAtkins> Rossen0: with that, we'll add MQ4 and Scroll Snap to "reliable CR". objections?
17:39:30 <TabAtkins> RESOLVED: add MQ4 and Scroll Snap to "reliable CR"
17:39:47 <TabAtkins> florian: i'd argue Scrollbars 1 goes in "reliable CR" too. Very small spec.
17:40:11 <TabAtkins> florian: Like I mentioned, Safari has great pass rates but they're going down as tests are reviewed and made to actually fail when not supported
17:40:17 <TabAtkins> ChrisL: so we don't know how well it's implemented?
17:40:25 <TabAtkins> florian: there are impls, and th ekey aspects do work in chrome and firefox
17:40:41 <TabAtkins> florian: details are little more iffy, many have been recently fixed. test suit needs a little work
17:40:58 <TabAtkins> florian: better than a CR with no impl, but not Rec. we could leave it where it is if we're not sure.
17:41:05 <TabAtkins> fantasai: seems to have a usable level of interop
17:41:13 <TabAtkins> florian: there are corner cases, but the core of it works in two browsers
17:41:23 <TabAtkins> Rossen0: any objections to moving it?
17:41:44 <TabAtkins> RESOLVED: Move Scrollbars to "reliable CR"
17:41:52 <TabAtkins> fantasai: Grid 1 and 2 should also move to "reliable CR"
17:41:57 <TabAtkins> Agreed
17:42:21 <TabAtkins> fantasai: spec needs an update, that's on me. after that it's very stable, we have very few issues agaisnt Grid.
17:42:27 <TabAtkins> Rossen0: i think that sounds reasonable. objections?
17:42:48 <TabAtkins> SebastianZ: just wondering, we have 12k tests on this spec, 92% interop
17:42:56 <TabAtkins> SebastianZ: dont' you think that verifies it to go official?
17:43:12 <TabAtkins> fantasai: I'll propose doing that as soon as I publish an update, spec is out of date now. if I get that befor ened of year we can move it
17:43:23 <TabAtkins> Rossen0: objections?
17:43:39 <TabAtkins> RESOLVED: Move Grid 1 and 2 to "reliable CR"
17:44:02 <TabAtkins> Rossen0: are there more to discuss before we move on?
17:44:04 <TabAtkins> florian: a bunch
17:44:11 <TabAtkins> fantasai: we should triage and come back with a batch resolution
17:44:20 <TabAtkins> SebastianZ: i'd like the editors of the specs to post their opinions
17:45:01 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/11035#issuecomment-2471871211
17:45:01 <github-bot> Topic: [css-values-5] attr() and forwards compatible parsing
17:45:01 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11035.
17:45:12 <fantasai> Scribenick: fantasai
17:45:43 <fantasai> TabAtkins: We switched attr() to use type definition syntax, similar to variables
17:45:52 <fantasai> TabAtkins: But working through that, we lost some abilities
17:46:00 <lea> present+
17:46:03 <fantasai> TabAtkins: for example, saying the attr is a number representing px values
17:46:03 <moonira> moonira has joined #css
17:46:10 <fantasai> TabAtkins: It started to get too complicated for common cases
17:46:20 <fantasai> TabAtkins: For grammar ambiguity reasons, we suggest to wrap in type() function
17:46:25 <fantasai> TabAtkins: and end up with a lot for simple cases.
17:46:36 <fantasai> TabAtkins: Suggestion is to keep the <syntax> argument, but wrapped in type()
17:46:45 <fantasai> TabAtkins: but for two cases we have an easier way to specify
17:47:03 <fantasai> TabAtkins: for default behavior of treating attr value as a string, we introduce a keyword (string) so you can say so explicitly
17:47:19 <fantasai> TabAtkins: and secondly, add all units as keywords, which parse as a number and attach that unit
17:47:34 <fantasai> TabAtkins: this does slightly reduce the power of the syntax compared to before, since can't mix this behavior with other values
17:47:49 <fantasai> TabAtkins: but I think it's OK, not a high-value use case right now; can evaluate later or add to <syntax> production
17:48:06 <fantasai> TabAtkins: but instead of type(<number px>) can just write px, much simpler
17:48:14 <fantasai> TabAtkins: so proposal is
17:48:19 <fantasai> 1. Add type() wrapper around <syntax>
17:48:28 <Rossen0> q?
17:48:28 <kizu> +1 to the proposal
17:48:30 <fantasai> 2. Introduce string keyword for explicitly indicating string parsing
17:48:33 <chrishtr> +1
17:48:42 <fantasai> 3. Add all units to attach to a <number>
17:48:59 <noamr7> noamr7 has joined #css
17:49:06 <smfr> smfr has joined #css
17:49:27 <lea> I don't understand the proposed options
17:50:03 <TabAtkins> attr(foo type(<length>))
17:50:09 <TabAtkins> attr(foo string) (deffault behavior)
17:50:13 <fantasai> attr(attributename [ type(<syntax>) | string | <unit> ], fallback)
17:50:21 <TabAtkins> attr(foo type(*))
17:50:37 <fantasai> lea: can you parse in a token stream?
17:50:46 <fantasai> TabAtkins: yes, use * just like in custom properties
17:51:22 <ydaniv> +1
17:51:27 <fantasai> lea: what's without the proposal?
17:51:36 <fantasai> attr(attributename <syntax>, fallback)
17:51:53 <fantasai> TabAtkins: wanted to wrap type() because <syntax> would make parsing complicated if we add anything in the future
17:52:06 <fantasai> lea: could we use keyword instead of type()?
17:52:14 <florian> wfm
17:52:18 <fantasai> TabAtkins: using type() because that's what we do in custom functions
17:52:27 <fantasai> TabAtkins: thought about using 'as' but consistency is good
17:52:38 <fantasai> lea: no way to use 'as' in functions? presumably want to know where the syntax terminates
17:52:47 <fantasai> TabAtkins: yes, and in some cases if you want to accept several keywords...
17:52:54 <fantasai> TabAtkins: having type() wrapper makes it clearer
17:52:56 <lea> +1
17:52:58 <TabAtkins> attr(foo type(one | two | three))
17:53:01 <oriol> +1
17:53:06 <fantasai> wfm
17:53:22 <fantasai> Rossen0: Anyone else? Any objections?
17:53:51 <fantasai> RESOLVED: Accept proposal to use type(<syntax>), add string, and add units as keywords.
17:54:28 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/10649#issuecomment-2426552611
17:54:28 <github-bot> Topic: [css-shapes-2] `curve to` keyword `using` seems a bit off
17:54:28 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10649.
17:54:33 <fantasai> Summary at https://github.com/w3c/csswg-drafts/issues/10649#issuecomment-2471826022
17:54:39 <TabAtkins> smfr: propsoed syntax for the shape() function
17:54:43 <TabAtkins> smfr: we've talked about this before, it's a tweak
17:54:57 <TabAtkins> smfr: settled on using `with` for the control points. if you specify two control points, separate with a slah.
17:55:14 <TabAtkins> smfr: big addition is using keywords for absolute points, like `curve to top left`, it feels very natural
17:55:19 <TabAtkins> smfr: hline/vline also take those keywords
17:55:35 <TabAtkins> smfr: and new addition, can specify the control points are realtive to the start or end of segment, using "from start" or "from end" syntax
17:55:51 <TabAtkins> smfr: had an open question - arbityrary order of control points and destination points?
17:56:05 <TabAtkins> smfr: so youc ould say `curve ... with ... to...` or `curve ... to ... with ...`
17:56:10 <fantasai> full proposed grammar at https://github.com/w3c/csswg-drafts/issues/10649#issuecomment-2426552611
17:56:17 <TabAtkins> Rossen0: this feels a lot better than the basic shapes syntax before
17:56:27 <fantasai> +1 to the proposal and +1 to allowing reordering
17:56:27 <TabAtkins> +1 to me, I've reviewed all the changes
17:56:41 <noamr7> +1
17:56:42 <TabAtkins> smfr: there's a chunk of wpt already. spec doesn't reflect arbitrary ordering yet, i'll fix that
17:56:51 <TabAtkins> Rossen0: objections?
17:57:11 <TabAtkins> RESOLVED: Accept the changes to the shape() grammar
17:57:15 <github-bot> Topic: [css-backgrounds-4] default background-origin for `border-area` in shorthand
17:57:37 <TabAtkins> fantasai: in the bg shorthand if you specify a single keyword like 'border-box', it sets both clip and origin to that keyword
17:57:45 <TabAtkins> fantasai: but 'border-area' keyword is only valid for clip, not origin
17:57:59 <TabAtkins> fantasai: want to clarify that in that case, origin defaults to border-box
17:57:59 <TabAtkins> +1 to this from me
17:58:12 <kizu> +1, makes sense
17:58:14 <oriol> +1
17:58:20 <TabAtkins> Rossen0: objections?
17:58:54 <smfr> smfr has joined #css
17:58:56 <fantasai> background: ... border-area;
17:59:24 <emilio> A bit unfortunate that it's different from background: ...; background-clip: border-area
17:59:27 <emilio> But yeah
17:59:30 <TabAtkins> RESOLVED: Using 'border-area' in the background shorthand (and omitting origin) defaults the origin to border-box
17:59:49 <TabAtkins> fantasai: second, do we want some way to make things default if you specify the longhand?
18:00:15 <TabAtkins> fantasai: argument for, it's unfortuante/confusing to get it set to the "wrong" value
18:00:22 <smfr> present+
18:00:23 <TabAtkins> fantasai: argument against, it's not something we're currnetly doing
18:00:32 <emilio> present+
18:00:34 <TabAtkins> Rossen0: okay, will leave that part of the discussion
18:00:35 <fantasai> for other values of background-clip (though maybe we should have)
18:00:39 <TabAtkins> github-bot, end topic
18:00:41 <emilio> Of course the next thing fantasai says addresses my concern ;)
18:00:59 <Rossen0> Zakim, end meeting
18:00:59 <Zakim> As of this point the attendees have been stepheckles, castastrophe, PaulG, SebastianZ, romain, joshtumath, noamr, kbabbitt, fantasai, dholbert, TabAtkins, ydaniv, schenney,
18:01:02 <Zakim> ... moonira, kizu, gfaujdar, ChrisL, oriol, jfkthame, emilio, miriam, flackr, alisonmaher, lea, smfr
18:01:02 <Zakim> RRSAgent, please draft minutes v2
18:01:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/13-css-minutes.html Zakim
18:01:11 <Zakim> I am happy to have been of service, Rossen0; please remember to excuse RRSAgent.  Goodbye
18:01:11 <Zakim> Zakim has left #css
18:03:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/13-css-minutes.html fantasai
18:05:02 <fantasai> Probably several ways we could go about that...
18:05:07 <fantasai> 1. Do nothing. :) Easiest option.
18:05:30 <fantasai> 2. Create an auto value for background-origin that maps to border-box if clip is border-area; and to content-box otherwise. Most backwards-compatible option.
18:06:04 <fantasai> 3. Create auto values for both background-origin and background-clip. If both are auto, map to content-box/border-box (initial values). Otherwise auto maps to the other property's value.
18:06:15 <fantasai> That one is a bit risky, we'd have to evaluate compat.
18:06:51 <fantasai> But it makes for a nicer system. Would have been nice if we had it originally. :)
18:13:25 <TabAtkins> emilio, not using the shorthand *today* produces different behavior
18:14:01 <emilio> Oh?
18:14:20 <emilio> Alright then, shrug
18:19:17 <fantasai> emilio: reminder to answer https://rallly.co/invite/ShjWRuGtqnQG :) ;)
18:19:29 <fantasai> you're an MVP for CSSWG meetings
18:19:31 <fantasai> :P
18:28:25 <emilio> fantasai: Done, I hadn't replied because I think all dates are fine with me, but yeah best to make that explicit :)
18:30:27 <fantasai> 100% that's helpful yes :)
18:39:30 <antonp> antonp has joined #css
18:39:42 <antonp1> antonp1 has joined #css
18:52:46 <antonp> antonp has joined #css
19:10:08 <antonp> antonp has joined #css
20:59:47 <projecto-> projecto- has joined #css
21:00:17 <leaverou_> leaverou_ has joined #css
21:01:17 <Rossen-> Rossen- has joined #css
21:01:48 <shans_> shans_ has joined #css
21:02:18 <sylvaing_> sylvaing_ has joined #css