15:57:53 <RRSAgent> RRSAgent has joined #css
15:57:57 <RRSAgent> logging to https://www.w3.org/2025/03/12-css-irc
15:57:57 <Zakim> RRSAgent, make logs Public
15:57:58 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:25 <bkardell_> bkardell_ has joined #css
15:59:40 <JoshT> JoshT has joined #css
15:59:52 <jfkthame> jfkthame has joined #css
16:00:58 <emeyer> emeyer has joined #css
16:01:03 <alisonmaher> alisonmaher has joined #css
16:01:09 <alisonmaher> present+
16:01:19 <JoshT> present+
16:01:26 <bkardell_> present+
16:01:40 <bradk> bradk has joined #css
16:01:46 <PaulG> PaulG has joined #css
16:01:52 <dholbert> dholbert has joined #css
16:02:03 <castastrophe> castastrophe has joined #css
16:02:12 <oriol> present+
16:02:17 <weinig> present+
16:02:27 <kizu> kizu has joined #css
16:02:33 <kizu> present+
16:02:38 <kbabbitt> kbabbitt has joined #css
16:02:42 <kbabbitt> present+
16:02:45 <vmpstr> present+
16:02:48 <fantasai> present+
16:03:16 <TabAtkins> ScribeNick: TabAtkins
16:03:39 <bradk> bradk has joined #css
16:03:45 <TabAtkins> fantasai: Tim wanted to publish a FPWD of Forms?
16:03:51 <TabAtkins> astearns: yup, people should weigh in on the issue
16:03:51 <jfkthame> present+
16:03:57 <bradk> present+
16:03:59 <ydaniv> ydaniv has joined #css
16:03:59 <TabAtkins> astearns: will take it up next week
16:04:02 <dholbert> present+
16:04:08 <fantasai> https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2715192840
16:04:10 <miriam> present+
16:04:14 <ydaniv> present+
16:04:19 <TabAtkins> astearns: maybe should have co-editors?
16:04:27 <TabAtkins> fantasai: I think jarhar has been co-editing, functionally speaking
16:04:29 <noamr> noamr has joined #css
16:04:54 <TabAtkins> astearns: Luke would be a possibility too, they've been doing PRs. I'll get some co-editors together for next week.
16:05:02 <astearns> https://wiki.csswg.org/planning/newyork-2025#new-york-f2f-april-2025
16:05:02 <TabAtkins> astearns: First - register for NY meeting
16:05:17 <TabAtkins> astearns: Attending in-person *or* virtually, put availability in the wiki so I can construct the agenda
16:05:33 <flackr> present+
16:05:45 <castastrophe> present+
16:05:47 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11614
16:05:47 <github-bot> Topic: [css-view-transitions-2] view-transition-name: auto when matching id should namespace
16:05:47 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11614.
16:06:03 <TabAtkins> vmpstr: we added v-t-name:auto
16:06:17 <TabAtkins> vmpstr: matches the VT name based on the element's ID attribute, and acts as match-element otherwise
16:06:25 <TabAtkins> vmpstr: this name isn't exposed anywhere, it's "auto" in serializations
16:06:46 <TabAtkins> vmpstr: but wanted to clarify that the ID ident shouldn't match another VT that specifies a manual ident that happens tob e the same
16:07:09 <TabAtkins> vmpstr: Like `v-t-name: foo` on one  element and `v-t-name:auto` on an element with id="foo" shouldn't match
16:07:15 <TabAtkins> astearns: looks like there's agreement in the thread
16:07:18 <TabAtkins> sounds fine to me
16:07:33 <TabAtkins> astearns: anyone in the room actually want the behavior we're prohibiting?
16:07:44 <TabAtkins> no opinion either way, really, happy to defer to editors
16:07:45 <bkardell_> makes sense
16:08:09 <noamr> +1
16:08:12 <TabAtkins> fantasai: I thought that's what we'd adopted originally, that the ID would only be used to link elements together, not something exposeable to other CSS. So this makes sense to me.
16:08:43 <TabAtkins> vmpstr: proposed: v-t-name:auto will never match an explicit v-t-name:<ident>
16:08:49 <TabAtkins> astearns: any objections?
16:09:03 <bfeigel> bfeigel has joined #CSS
16:09:10 <TabAtkins> RESOLVED: v-t-name:auto never matches an explicit v-t-name:<ident>
16:09:23 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10860
16:09:24 <github-bot> Topic: [css-align][css-anchor-position] Default safety and fixpos
16:09:24 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10860.
16:10:19 <noamr> TabAtkins: a corner case in anchor positioning, common in certain situations. original containing block, plus "safety". If something overflows the containing block it can still overflow until its original containing block
16:10:48 <noamr> TabAtkins: the problem is that for fixed positining you'd get some bad behavior, because the original containing block is the viewport. if you scroll a bit you'd get bad overflowing behavior
16:11:25 <noamr> TabAtkins: proposing to always to default a fixed pos element to unsafe element, rather than default to the medium safety
16:11:53 <noamr> TabAtkins: this shouldn't have real effects to users of the feature, the element should remain on screen when possible, but it's a bit of a tweak
16:12:17 <noamr> astearns: is this modifiable by the author?
16:12:31 <noamr> TabAtkins: this is just the default behavior if you don't say safe/unsafe on one of the alignment keywords
16:12:53 <noamr> TabAtkins: we shouldn't have the default do the wrong thing for common scenarios. We just propose to change the default safety
16:13:10 <noamr> fantasai: re-adjust it to be as if it was safe?
16:13:48 <noamr> TabAtkins: the medium safety is correct but can't be implemented. current definition of medium safety rely on layout information but not on scroll information
16:14:25 <noamr> TabAtkins: anchor position can respond to scrolling. in order to do the medium safety, it can't work in the way defined in the space. We need to define it as unsafe in the layout and then correct it using the scroll adjustment behavior
16:14:53 <noamr> TabAtkins: rather than layout time behavior creating the medium safety, it needs to be created by scroll adjustment, in order to be compositable
16:15:10 <fantasai> https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2430366312
16:15:14 <fantasai> This never got resolved either
16:15:54 <noamr> fantasai: I am glad that we're not changing the user observable behavior; no opinion about how we get there
16:17:01 <TabAtkins> proposed: change the way medium-safety alignment is handled to instead invoke the scroll adjustment machinery when handling an anchorpos fixpos element
16:17:11 <bradk> bradk has joined #css
16:17:55 <TabAtkins> (note to the above IRC-only comment; the resolution was in the preceding comment, the edits were for that)
16:18:16 <TabAtkins> RESOLVED: change the way medium-safety alignment is handled to instead invoke the scroll adjustment machinery when handling an anchorpos fixpos element
16:18:22 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10803
16:18:22 <github-bot> Topic: [css-text-4] [text-autospace] Spacing across element boundaries for BiDi content
16:18:22 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10803.
16:18:54 <TabAtkins> fantasai: so text-autospace inserts spaces between "changes" in a script
16:19:07 <TabAtkins> fantasai: if you ahve chinese with a little englihs, there should be some gap around the english otherwise it feels cramped
16:19:13 <TabAtkins> fantasai: q is what to do with bidi text
16:19:26 <TabAtkins> fantasai: we dont' insert space between chinese text and a *symbol*, only between chinese text and a letter
16:19:37 <TabAtkins> fantasai: so if you had a stretch of rtl text, like hebrew that ends with a symbol
16:19:46 <TabAtkins> fantasai: and you give it a direction so it all flips
16:20:14 <TabAtkins> fantasai: so symbol is on the left, hebrew letters on the right
16:20:22 <TabAtkins> fantasai: chinese text before and after
16:20:50 <TabAtkins> fantasai: if you insert space before reordering, you'll put it on the left side, which ends up between the chinese text and the symbol, while the hebrew and chinese dont' get a space
16:21:08 <TabAtkins> fantasai: so correct answer is to manage the sapce in visual order, after bidi reordering
16:21:32 <TabAtkins> fantasai: this is challenging, it interacts with linebreaking in awkward ways. hard to get perfectly right without maybe some backtracking
16:21:45 <TabAtkins> fantasai: so i think th e correct answer is visual spacing
16:21:47 <sgill> sgill has joined #css
16:21:54 <TabAtkins> fantasai: for practicual purposes, might tolerate getting it wrong in some complex cases
16:21:57 <sgill> present+
16:22:03 <TabAtkins> florian: do we need to spec the allowance for getting it wrong?
16:22:15 <TabAtkins> florian: or jsut spec the right thing and expect people to get it wrong sometimes, but they should still try?
16:22:18 <TabAtkins> fantasai: i'm not sure
16:22:35 <TabAtkins> fantasai: i think it's important to maek sure we get right - if both sides require spacing, it's done correctly, never get double space on one side
16:22:40 <TabAtkins> fantasai: that's minimum bar
16:23:07 <TabAtkins> astearns: I think we should specify what we want to see, without allowance, and only do that "getting it wrong is allowed" part if we have to
16:23:10 <TabAtkins> fantasai: i think that's reasonable.
16:23:21 <TabAtkins> fantasai: if authors are running into problems with certain cases, they can complain, and then we'll know those cases matter.
16:23:36 <TabAtkins> astearns: so proposed resolution is we specify that autospacing is done after bidi reordering
16:23:44 <TabAtkins> astearns: and you should never double auto-space any side
16:23:47 <TabAtkins> fantasai: yeah, that's implied
16:23:57 <TabAtkins> florian: do we want to add a note about it being hard?
16:24:11 <fantasai> Scribe+
16:24:21 <fantasai> TabAtkins: Useful to acknowledge if something is significantly difficult
16:24:29 <fantasai> TabAtkins: Here be dragons, when implementing
16:24:31 <TabAtkins> fantasai: i think they'll notice
16:24:41 <TabAtkins> astearns: would be good to have at least one example, hopefully we can find a real-world example
16:25:04 <TabAtkins> florian: could have a note which is less silly than my earlier phrasing. "CSSWG acknowledge that the interactino of this with line-breaking may be challenging to implement"
16:25:16 <TabAtkins> fantasai: or literally say "here be dragons"
16:25:32 <fantasai> s/or literally/or, as bkardell suggests, literally/
16:25:34 <TabAtkins> astearns: [restates proposed reoslution]
16:26:07 <TabAtkins> RESOLVED: autospacing happens *after* bidi-reordering, and we'll add a complex example to the spec
16:26:13 <fantasai> Topic: Sizing
16:26:19 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10721
16:26:19 <github-bot> Topic: [css-sizing-3] Content contribution of min-inline-size:fit-content and max-inline-size:fit-content
16:26:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10721.
16:26:37 <TabAtkins> oriol: when you're computing intrinsic cocntirubtion of a fit-content element, what should happen?
16:27:00 <TabAtkins> oriol: if you use fit-content on the preferred sizing property, it's clear that for the purpose of computing min-content contribution, you treat it as min-content; for max-content contrib, you treat it as max-content
16:27:12 <TabAtkins> oriol: but if you use this keyword on min or max sizing properties, it's less clear what shoudl happen
16:27:29 <TabAtkins> oriol: what webkit does is it just ignores the keyword, so in a min property it treats as 0, in max it treats it as none
16:27:39 <TabAtkins> oriol: blink used to have the same behavior, but changed to align with firefox
16:28:00 <TabAtkins> oriol: firefox beahvior is, when computing intrinsic contribs, fit-content acts as min-content in min sizing property, and as max-content in a max sizing property
16:28:26 <TabAtkins> oriol: i was implementing in servo and i think there's a better behavior, and i think it's what's actually specified in the spec, and is a bit simpler to implement
16:28:32 <oriol> https://github.com/w3c/csswg-drafts/issues/10721#issuecomment-2414743959
16:28:33 <TabAtkins> oriol: some testcases ^^^
16:28:51 <TabAtkins> oriol: in this testcase, magenta wrapper has a fixed width - first very narrow, then between, then wider
16:28:52 <fantasai> <3 Oriol's examples
16:29:00 <TabAtkins> oriol: element with black border is inline-block, so shrink-to-fit
16:29:12 <TabAtkins> oriol: the inline-block contains one element with `width` to a huge amount, and max-width:fit-content
16:29:21 <TabAtkins> oriol: so webkit ignores the max-width so the width makes it all explode
16:29:36 <TabAtkins> oriol: gecko and blink treat it as max-content, so the inline-block is always sized as max-content
16:29:49 <TabAtkins> oriol: i think the servo column is better. do the smae for the three sizing props
16:30:08 <TabAtkins> oriol: you always treat it as min-content when doing min-content contribution, and similar for max, for all three properties
16:30:26 <TabAtkins> oriol: so if magenta wrapper is narrow you'll use the min-content contribution, if wide you'll use the max-content contribution, and if between it'll be between
16:30:38 <TabAtkins> oriol: i think this is a better match for fit-content, trying to fit into the container
16:30:50 <TabAtkins> oriol: so i propose the spec is right, and servo is right, and other browsers should match
16:30:54 <astearns> ack fantasai
16:30:55 <TabAtkins> fantasai: thanks for the fantastic examples
16:31:12 <TabAtkins> fantasai: as editor, i think Servo's impl is correct. it reflects the author's request
16:31:35 <TabAtkins> fantasai: in 2.1's definition of min/max sizing properties, it says you literally run layout by subbing in the value for 'width' and then clamp appropriately; this matches that behavior as well
16:31:51 <TabAtkins> iank_: I think this is likely fine.
16:32:01 <TabAtkins> iank_: hopefully no compat issues, but on the surface it's not too difficult for us to do
16:32:21 <TabAtkins> astearns: so are we resolving the spec is correct?
16:32:32 <TabAtkins> oriol: yes
16:32:43 <TabAtkins> iank_: it's not obvious to me that the spec is correct, so clarifying would be good for the future
16:33:04 <TabAtkins> oriol: at end of th eissue i posted the quote of the spec that i think is backing the servo behavior, we can clarify or add some examples
16:33:06 <TabAtkins> examples++
16:33:30 <TabAtkins> fantasai: the spec doesn't make a distinction between what fit-content size means based on property, so i don't think it can support an interpretation that it works differentyl in the different properties
16:33:33 <TabAtkins> astearns: so let's make that explicit
16:33:56 <TabAtkins> astearns: so proposed resolution is we add examples like Oriol's and make the implication clear in the spec
16:34:16 <TabAtkins> RESOLVED: No normative change to spec, but add example like Oriol's and make the implication clearer in the spec.
16:34:25 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11236
16:34:25 <github-bot> Topic: [css-sizing] How to transfer intrinsic keywords via aspect ratio?
16:34:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11236.
16:34:43 <TabAtkins> iank_: replaced elements ahve three things
16:34:49 <TabAtkins> iank_: natural width, natural height, natural aspect ratio
16:35:04 <TabAtkins> iank_: you can have a natural widht of 20, height of 10, and ratio woudl be 2/1
16:35:19 <TabAtkins> iank_: it used to be possible (in svg, at least) to have the natural sizes not match the aspect ratio
16:35:26 <TabAtkins> iank_: this is more of a problem now with aspect-ratio proeprty
16:35:39 <TabAtkins> iank_: can have natural width/height of 20px and 10px, and an aspect-ratio proeprty of 1/1
16:35:41 <TabAtkins> iank_: so what happens
16:36:19 <TabAtkins> iank_: there's places where you're sizing a replaced element where you only llook at natural sizes, but then the aspect ratio comes in (to transfer min-height to a width, for example), and they're disjoint
16:36:27 <ydaniv> ydaniv has joined #css
16:36:30 <TabAtkins> iank_: there's a step which normalizes the natural sizes and aspect ratio
16:36:43 <TabAtkins> iank_: I think simplest answer is we coerce the natural sizes to match the aspect ratio
16:37:08 <TabAtkins> iank_: so if your natural sizes are 20px/10px, and aspect-ratio is 1/1, we coerce the block size to match and it becomes 20px/20px natural size
16:37:28 <TabAtkins> iank_: we have this normalization step for SVG. you can specify only a natural width, no natural height, yes natural aspect-ratio, adn we harmonize the three together
16:37:39 <TabAtkins> iank_: so I think we should do the same when all three are specified but disagree
16:38:00 <TabAtkins> astearns: when you say you don't care, you example had us adjusting the block natural size
16:38:07 <TabAtkins> astearns: is the other option adjusting inline size...?
16:38:14 <TabAtkins> iank_: you could adjust block/inline/width/height
16:38:17 <TabAtkins> fantasai: or larger/smaller
16:38:30 <TabAtkins> iank_: mild preference for adjusting block size
16:38:47 <TabAtkins> fantasai: I think if we do this fixup, adjusting the block size makes sense
16:38:54 <TabAtkins> fantasai: in most layout algorithms block size is the dependent size
16:39:08 <TabAtkins> fantasai: aspect-ratio in general works that way, it prioritizes that dependency direction
16:39:31 <TabAtkins> oriol: yeah in my second comment, i say we adjust the block size when transferring. so i'd prefer to be analogous
16:39:33 <TabAtkins> +1
16:39:45 <TabAtkins> dholbert: makes sense about aspect-ratio proeprty
16:40:09 <TabAtkins> dholbert: without aspect-ratio i think this doesn't matter? SVG says to derive the intrinsic aspect-ratio from the intrinsic sizes if they're present, ignoring the view-box. Is that right, Ian?
16:40:15 <TabAtkins> iank_: I thought there was a case...
16:40:29 <TabAtkins> iank_: viewbox aspect ratio fo 1/1, width=10 height=0
16:40:44 <TabAtkins> iank_: in that case the natural sizes are 10/0
16:40:58 <TabAtkins> dholbert: right, the 0 is equivalent to not having a size, not worried about that corner case
16:41:11 <TabAtkins> iank_: okay, then yeah i think it's otherwise correct, we can discuss offline if necessary
16:41:33 <TabAtkins> iank_: a little icky with a 0 width or height, i think we have some compat for it rendering as 0 height, and this would change it to non-zero
16:42:16 <fantasai> TabAtkins: So ignoring SVG complications, we can limit this to just aspect-ratio property?
16:42:27 <TabAtkins> iank_: I think we want this for aspect ratios generally
16:42:42 <TabAtkins> iank_: this is part of the nromalization step, svg's a-r comes from the width/height, and only if that doesn't exist does it come from the viewbox
16:42:56 <TabAtkins> iank_: so now we'll take aspect-ratio property into account
16:43:11 <TabAtkins> iank_: this can also happen in contain-intrinsic-size, it gives a natural width/height
16:43:30 <TabAtkins> iank_: so this can't just be for the aspect-ratio property, need fixup to work consistently
16:43:49 <dholbert> this is the SVG spec text I'm remembering RE getting aspect-ratio from width/height (if present), and falling back to viewBox ( https://svgwg.org/svg2-draft/coords.html#SizingSVGInCSS ).   Just noting for reference; I'm on board with what IanK just described
16:44:16 <TabAtkins> astearns: so this just applies to repalced?
16:44:20 <TabAtkins> [some confusion, but yes]
16:45:07 <TabAtkins> iank_: proposed resolution: for the final step in determining natural sizes, use the determiend aspect-ratio to coerce the block size to match
16:45:34 <TabAtkins> astearns: questions? objections?
16:45:55 <TabAtkins> RESOLVED: for the final step in determining natural sizes, use the determined aspect-ratio to coerce the block size to match
16:46:03 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/820
16:46:03 <github-bot> Topic: [css-sizing] Adding a 'size' shorthand for 'width'/'height'
16:46:03 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/820.
16:46:15 <TabAtkins> fantasai: wow this was old.
16:46:20 <TabAtkins> fantasai: not clear what to do here, but people want it solved
16:46:29 <TabAtkins> fantasai: complication is there's an existing size proeprty in @page rules
16:46:35 <TabAtkins> fantasai: and it's not equivalent to setting width/height
16:46:44 <TabAtkins> fantasai: width/height apply to the page area
16:46:49 <TabAtkins> fantasai: this is implemented by PDF renderers
16:46:54 <ntim> ntim has joined #css
16:46:58 <Di> Di has joined #css
16:47:19 <TabAtkins> fantasai: added this after chatting with emilio, who suggested maybe we just treat 'size' in @page specially, so they set a different size property, while everywhere else it's a shorthand
16:47:22 <oriol> q+
16:47:24 <fantasai> https://github.com/w3c/csswg-drafts/issues/820#issuecomment-810626883
16:47:27 <TabAtkins> fantasai: so wanted to know if it's viable
16:47:34 <ntim> i like the idea
16:47:50 <TabAtkins> astearns: seems a little icky to have different processing based on where 'size' comes up
16:47:55 <JoshT> q+
16:47:56 <TabAtkins> astearns: but maybe in this case its' reasonable
16:47:57 <emilio> q+
16:48:12 <TabAtkins> (I think there's not really any better solution. Also slightly icked but okay with it for the benefit.)
16:48:31 <astearns> ack oriol
16:48:32 <TabAtkins> florian: Yeah, unfortunate, but since the weirdness is so scoped it's probaqbly okay
16:48:42 <TabAtkins> oriol: in @page, it has descriptors not properties
16:49:01 <JoshT> q- Was going to make the same point
16:49:06 <TabAtkins> oriol: so a name conflict isn't *great* but not a big deal technically. can just say that 'size' descriptor and 'size' shorthand are different
16:49:10 <JoshT> q-
16:49:10 <astearns> ack emilio
16:49:14 <ntim> q+
16:49:22 <TabAtkins> emilio: i think this is the onlyw ay to make it work
16:49:39 <TabAtkins> emilio: but maybe it could be cool to make 'size' in @page a legacy alias for some other name, like 'page-size'?
16:49:54 <TabAtkins> emilio: that would be easier to implement, I think, then I don't need to deal with the name conflict as much.
16:49:55 <florian> +1
16:49:58 <TabAtkins> emilio: and maybe less confusing long term
16:50:11 <TabAtkins> astearns: do you have a mechanism to only apply an alias in one at-rule context?
16:50:14 <TabAtkins> emilio: yes, easily
16:50:35 <TabAtkins> emilio: just within the @page descriptor, if descriptor name is 'size' return 'page-size'
16:50:41 <astearns> ack fantasai
16:50:41 <Zakim> fantasai, you wanted to reply to emilio
16:50:46 <ntim> p+
16:50:50 <fantasai> https://github.com/w3c/csswg-drafts/issues/820#issuecomment-544582026
16:50:53 <TabAtkins> fantasai: we'd previously resolved to make it an alias and have page-size be the name
16:51:10 <TabAtkins> fantasai: response we got was some products support JS and 'size' has been supported as long as PDF renderers have existed
16:51:21 <TabAtkins> fantasai: so we could do aliasing, but would have to make sure it doesn't break CSSOM
16:51:28 <TabAtkins> emilio: yeah, aliases already work nicely for that
16:51:29 <astearns> ack ntim
16:51:43 <TabAtkins> ntim: any usage data on 'size'? i guess elika has answered the question
16:51:48 <TabAtkins> ntim: any browser have data?
16:52:04 <TabAtkins> fantasai: primary usage isn't in browsers, it's in pdf renderers. so big market difference in both content and userbase
16:52:15 <TabAtkins> emilio: i think browsers do support 'size' in printing, it's fairly used
16:52:25 <TabAtkins> iank_: yeah people generate PDFs from brwosers all the time, and do use the 'size' descriptor
16:52:31 <TabAtkins> iank_: so the markets are acteually pretty overlapping
16:52:37 <TabAtkins> florian: and epub readers too
16:52:45 <TabAtkins> florian: at least notionally, interactive pages user agents
16:52:51 <TabAtkins> ntim: common on web sites tho?
16:52:57 <TabAtkins> florian: when you print a web site, yeah, reasonably
16:53:15 <TabAtkins> iank_: very common in enterprise use-cases to have printable pages
16:53:24 <TabAtkins> iank_: and they use @page on those
16:53:36 <fantasai> https://www.w3.org/TR/css-cascade-5/#aliasing
16:53:39 <TabAtkins> ntim: i ask because in webkit, @page is pretty poorly maintained and we haven't seen many bug reports
16:53:59 <TabAtkins> iank_: I suspect we have the best support among browsers here, and enterprises are just targetting Chrome for printing webapps
16:54:20 <TabAtkins> astearns: so proposed resolution is we add 'size' shorthand proeprty that has nothing to do with '@page/size'
16:54:23 <TabAtkins> astearns: concerns?
16:54:50 <TabAtkins> RESOLVED: Add a 'size' shorthand property (for 'width'/'height'), no relation to @page's 'size' descriptor
16:54:56 <TabAtkins> ntim: woudl longhand be physical or logical
16:55:13 <TabAtkins> fantasai: i think would have to be physical because that's how we generally handle shorthand properties with both directions
16:55:20 <TabAtkins> fantasai: we map to the physical directions by default
16:55:30 <TabAtkins> florian: would be good to have a switch but we dont' have yet
16:55:49 <TabAtkins> ntim: possible confusion with inline-size/block-size, versus width/height
16:55:56 <TabAtkins> ntim: but otherwise fine with this
16:56:04 <TabAtkins> emilio: should we discuss the alias in @page?
16:56:08 <TabAtkins> astearns: separate issue
16:56:11 <TabAtkins> emilio: i'll file one
16:56:23 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11716
16:56:23 <github-bot> Topic: [css-sizing] Resolved value of min size properties doesn't round-trip
16:56:23 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11716.
16:56:47 <TabAtkins> oriol: Sizing 3 changed the initial value of min size properties. Was '0', now is 'auto'
16:57:05 <TabAtkins> oriol: but for back-compat, on block/inline-blcok/inline/table, when you use gCS() 'auto' can serialize as 0
16:57:23 <TabAtkins> oriol: problem is Sizing 4 added aspect-ratio, and that makes 'auto' behave differently than 0 on those boxes
16:57:39 <iank_> q+
16:57:40 <TabAtkins> oriol: so if you use gCS() you see 0, but it has a different meaning. if you assign it back, the value changes.
16:57:56 <TabAtkins> oriol: so I propose if aspect-ratio is a non-initial value, the "auto can serialize to 0" hack isn't applied
16:58:02 <TabAtkins> oriol: hopefully webcompatible to change
16:58:09 <emilio> q+
16:58:12 <astearns> ack iank_
16:58:33 <TabAtkins> iank_: i'm a little concerned. we already had auto problem for flex/grid, min-size:auto was treated differently too
16:58:40 <TabAtkins> iank_: didn't roundtrip there either
16:58:55 <TabAtkins> iank_: a little concerned that if gCS() starts returning 'auto' things could break. scared about compat.
16:59:02 <TabAtkins> iank_: mostly because this is the default
16:59:12 <TabAtkins> iank_: but width/height also don't fully roundtrip anyway
16:59:20 <TabAtkins> emilio: i think they do in gecko, blink has some bugs with scrollbars
16:59:31 <TabAtkins> iank_: nah, height:auto vs explciit value changes definiteness, which affects %s
16:59:40 <astearns> ack emilio
16:59:43 <TabAtkins> iank_: so the idea that width/height roundtrips is a spec fiction
16:59:57 <TabAtkins> emilio: similar concern. i think in principle we should probably do this, but it does scare me compat-wise
17:00:06 <TabAtkins> emilio: can try it, see what happens
17:00:27 <TabAtkins> emilio: middle ground, maybe less scary, is doing this for layout boxes where we know it makes a difference, like for flex items
17:00:33 <TabAtkins> emilio: but still not sure it's worth
17:00:52 <TabAtkins> oriol: you mentioned flex items, for those it's alreayd the case, 'auto' serializes to 'auto'. it only serializes to 0 for block/inline/inline-block/tab le
17:01:05 <TabAtkins> oriol: so only *those* will change, and only when aspect-ratio is a non-initial value
17:01:27 <TabAtkins> astearns: out of time. can resolve to try fixing this roundtripping, or take it back to the issue. ian, emilio, preference?
17:01:47 <TabAtkins> iank_: can we put it at start of call nexte week? want to check some things. I didn't realize we were alreayd doing this for flex/grid items.
17:01:54 <TabAtkins> emilio: same. I think this makes it a bit less scary.
17:02:05 <TabAtkins> astearns: so let's take it back to the issue. we'll revisit next week.
17:02:08 <TabAtkins> github-bot, end topic
17:02:20 <TabAtkins> astearns: HDR breakout in a few hours
17:02:23 <emeyer> emeyer has left #css
17:33:47 <astearns> zakim, end meeting
17:33:47 <Zakim> As of this point the attendees have been alisonmaher, JoshT, bkardell_, oriol, weinig, kizu, kbabbitt, vmpstr, fantasai, jfkthame, bradk, dholbert, miriam, ydaniv, flackr,
17:33:50 <Zakim> ... castastrophe, sgill, keithamus
17:33:50 <Zakim> RRSAgent, please draft minutes v2
17:33:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/12-css-minutes.html Zakim
17:33:58 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:33:58 <Zakim> Zakim has left #css
18:57:59 <ccameron> ccameron has joined #css
18:59:26 <Zakim> Zakim has joined #css
18:59:34 <astearns> zakim, start meeting
18:59:34 <Zakim> RRSAgent, make logs Public
18:59:35 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
19:04:56 <fantasai> present+
19:05:38 <fantasai> scribenick: fantasai
19:06:55 <fantasai> astearns: 2 issues, about 'auto' value and about 'initial' value
19:07:12 <fantasai> Topic: HDR
19:07:48 <github-bot> Subtopic: [css-color-hdr] auto value of dynamic-range-limit
19:08:08 <fantasai> ChrisL: Note that we changed 'high' to 'no-limit'
19:08:32 <weinig> present+
19:09:07 <fantasai> ccameron: with 'auto', I'm struggling to understand what the goal is
19:09:15 <fantasai> ccameron: Not necessarily agree with goal
19:09:22 <fantasai> ccameron: browser-defined incompatibility mode
19:09:25 <ChrisL> present+
19:09:36 <fantasai> ccameron: Might want to have UA limit how much headroom is available
19:09:46 <fantasai> ccameron: but that limit should be applied to page altogether
19:09:55 <fantasai> ccameron: don't want each element to get its own headeroom
19:10:24 <fantasai> ccameron: ... if want to e.g. hint that you really want HDR, and once can do constrained with video, etc. then can implement that
19:10:29 <fantasai> ccameron: so that's direction I would see it going
19:10:36 <fantasai> ccameron: Not a fan of 'auto' in current format for that reason
19:10:52 <fantasai> weinig: I'm also not clear on what 'auto' would do or why it would be a good idea
19:11:11 <fantasai> weinig: seems like if property intention is to provide upper limits on how much HDR headroom something should have, 'auto' doesn't really make sense
19:11:24 <fantasai> weinig: Idk how authors would use that
19:11:36 <fantasai> astearns: unfortunately Said who opened the issue isn't here
19:11:48 <fantasai> ChrisL: Agree that I don't think 'auto' adds much value.
19:11:57 <fantasai> ChrisL: incompatibility mode ... when you don't set anything
19:12:03 <fantasai> ChrisL: and then other values to get some sort of defined behavior
19:12:35 <fantasai> astearns: Table discussion until we have more clarity
19:12:48 <github-bot> Subtopic: [css-color-hdr] Initial value of `dynamic-range-limit`
19:12:53 <fantasai> ccameron: should it be auto or no-limit?
19:13:34 <fantasai> ccameron: I'm sympathetic to idea that if we're doing this ex-novo, make HDR opt in and whatever for the default
19:13:46 <fantasai> ccameron: but given every browser is shipping HDR on video by default
19:14:02 <fantasai> ccameron: and HDR images is not implemented yet only due to technical complexity
19:14:17 <fantasai> ccameron: I think UA should pull down everything together, and e.g. UA limits to 2x and you have to hint that you want HDR to get it
19:14:27 <fantasai> ccameron: or have mode where try to be smart in that property
19:14:29 <weinig> q+
19:14:31 <fantasai> ccameron: right now UA can do anything
19:14:41 <fantasai> ccameron: But I think everything should be limited on a page together
19:14:51 <fantasai> ccameron: if global limit, then adjust
19:15:00 <fantasai> ccameron: if there's behavior we want to care about
19:15:10 <fantasai> ccameron: better to let HDR images shine out, if too bright, that's just bad content
19:15:21 <fantasai> ccameron: clear signal that your HDR content is not authored in a good way
19:15:36 <fantasai> ccameron: we want people to integrate in a good way
19:15:43 <fantasai> ccameron: encourage people to create good content
19:16:00 <fantasai> ChrisL: I tend to agree with that
19:16:09 <fantasai> ChrisL: e.g. you could create lime green with flashing gif
19:16:16 <ccameron> I haven't been to Geocities that recently....
19:16:26 <fantasai> ChrisL: we don't limit that
19:16:35 <astearns> ack weinig
19:16:45 <fantasai> weinig: piece we're missing is, what's the goal of this property?
19:17:05 <fantasai> weinig: establish goal, then we can figure out our values
19:17:12 <fantasai> weinig: but without that, it's hard for us to make smart decisions
19:17:29 <fantasai> weinig: general premise of protecting people from poorly designed website is not our battle
19:17:43 <fantasai> weinig: But author may not know the source of images, so having author's abilitiy to limit
19:17:52 <fantasai> weinig: in this index, we're going to constrain HDR, because we dont' know what they contain
19:18:00 <fantasai> weinig: let's not waste that power
19:18:10 <fantasai> weinig: but default should be no limit, no use case for auto
19:18:39 <Said> Said has joined #CSS
19:19:12 <weinig> fantasai: believes that WebKit's position was that the initial value should be constrained
19:19:30 <weinig> fantasai: and things on a case by case basis should be marked unconstrained by authors
19:19:47 <weinig> fantasai: unfortunately not sure of the details, smfr would know more
19:20:13 <weinig> fantasai: authors do have the issue of things like 3rd party content, ads,
19:20:41 <ccameron> q+
19:20:42 <weinig> fantasai: if the default is no-limit, those ads might do bad things, and they would not know, because things works fine now
19:20:48 <astearns> ack fantasai
19:20:50 <fantasai> ads or user-generated content
19:20:51 <astearns> ack ccameron
19:21:04 <weinig> ccameron: would it be better to have a global hint?
19:21:14 <weinig> ccameron: we have to deal with the fact that video is already not constrained today
19:21:29 <weinig> ccameron: lots of people count on that
19:21:57 <weinig> fantasai: webkit/apple thinks a ua style sheet for video would help
19:22:18 <fantasai> ccameron: some browsers are shipping HDR images already, would break that behavior
19:22:23 <weinig> ccameron: for chrome, this would break things for images and webgpu canvas, which have already shipped
19:22:51 <fantasai> ccameron: hard to explain why we have this default a few years from now
19:23:07 <fantasai> ccameron: why not have a global signal
19:23:17 <fantasai> ccameron: whole page, if you want to keep the old behaviors, you need to opt into it
19:23:22 <fantasai> ccameron: roll that out slowly later
19:23:56 <fantasai> weinig: 2 weeks ago, position was that webkit/apple really wanted images also to be HDR unconstrained
19:24:00 <fantasai> weinig: in addition to video
19:24:21 <fantasai> fantasai: I can't remember which elements were proposed to except. ^_^;;
19:24:46 <fantasai> weinig: What if we split property in two, and have one limit apply to things like video/image/canvas -- replaced content
19:24:53 <fantasai> weinig: and separate one that applies to CSS colors etc.
19:25:03 <fantasai> weinig: then you could decide... is bg one or the other
19:25:08 <Said> q+
19:25:15 <astearns> ack Said
19:25:34 <fantasai> Said: I've been working with HDR for awhile now, and I feel it is really distracting to see HDR and SDR together in the same page
19:25:48 <fantasai> Said: I tried to get high quality HDR, but still same experience
19:26:03 <fantasai> Said: So it makes sense to me, to always have mixed content always be constrained
19:26:10 <ccameron> q+
19:26:16 <astearns> q+
19:26:20 <fantasai> Said: and only allow no-limit for fullscreen(?)
19:26:26 <astearns> ack ccameron
19:26:29 <fantasai> Said: This is my experience with SDR and HDR in the same page
19:26:48 <fantasai> ccameron: Right now the UA is free to do that, to limit all the HDR in the page to nothing for e.g. background windows (like Preview does on MacOS)
19:26:58 <fantasai> ccameron: and they can also limit the range heuristically, based on outlines
19:27:13 <fantasai> ccameron: Key thing is that the limit is imposed by UA on all content, so that page is affected all together, not element by element
19:27:28 <fantasai> ccameron: dynamic-range-limit property is author saying what they wayt
19:27:36 <fantasai> ccameron: if UA wants to do something beyond that, is compatible
19:27:55 <Said> q+
19:27:55 <fantasai> ccameron: Sympathetic to opt-in idea, but given where we are, disagree.
19:28:22 <fantasai> astearns: Wrt separate properties idea, aside from images and video, you can define a bg color as HDR color
19:28:42 <fantasai> astearns: if we decide initial value of dynamic-range-limit is constrained, then it's double-opt-in for that color? You'd have to specify the color and also raise the limit
19:28:51 <fantasai> ChrisL: You'd still get the color, just a more subdued color
19:29:04 <fantasai> astearns: That's a fair argument for not having a constraint, since we tend to avoid double opt in
19:29:07 <ChrisL> s/the color/an HDR color
19:29:22 <fantasai> weinig: We would re-imagine existing CSS colors as all being HDR capable, as long as their components were large enough
19:29:36 <astearns> ack fantasai
19:29:36 <fantasai> weinig: it wouldn't be a double opt in, you just need a color bright enough to warrant using some headroom
19:29:46 <astearns> ack astearns
19:30:42 <weinig> fantasai: the idea that the UA can do anything it wants
19:30:55 <weinig> fantasai: works well in cases where the UA has the final say, like background window
19:31:09 <weinig> fantasai: but it doesn't work well when the author overriding things
19:31:20 <weinig> fantasai: in that case, a property makes sense
19:31:30 <weinig> fantasai: element by element makes sense
19:31:42 <weinig> fantasai: but a different default for fullscreen or loaded alone might make sense
19:32:09 <weinig> fantasai: but allowing a page to have a mix of HDR  and non-HDR might make sense too
19:32:27 <weinig> fantasai: like YouTube, where there is video, but also other content
19:32:39 <weinig> fantasai: but only the main video should be HDR
19:32:53 <weinig> fantasai: magic limits later seems worse
19:33:05 <weinig> fantasai: should figure this out now, and make it work with the cascade
19:33:21 <weinig> fantasai: weird huerstics are worse, viewport metatag is awful
19:33:23 <astearns> q+
19:33:28 <astearns> ack Said
19:33:41 <fantasai> Said: We should take consideration the default, any possible auto values, take into consideration the transition
19:33:44 <fantasai> Said: At this time [missed]
19:34:10 <fantasai> Said: For example eBay, suppose someone decided "well, now all browsers support HDR, let's use this ability"
19:34:33 <fantasai> Said: [missed2]
19:34:57 <fantasai> astearns: I'm not sure I understand the story of having a constrained default be useful if we are also specifying that videos and images are not constrained for compat reasons
19:35:16 <fantasai> astearns: story of page with a lot of videos, if videos have their headroom expanded in UA stylesheet, that default is doing nothing for that case
19:35:22 <astearns> ack astearns
19:35:46 <fantasai> weinig: We have to figure out and agree on our goal
19:35:51 <fantasai> weinig: sounds like we dont' quite agree on it
19:35:55 <ccameron> q+
19:36:11 <fantasai> weinig: is the goal that videos, images are constrained or unconstrained? constrained in some circumstances? browsers can have different goals?
19:36:32 <fantasai> weinig: I see different goals here. We need to converge on the goal.
19:36:52 <fantasai> weinig: Another issue is that chrome has shipped this, so we also potentially have a compat problem here
19:37:13 <fantasai> weinig: Maybe Apple can give a concerete proposal
19:37:18 <fantasai> s/concerete/concrete/
19:38:33 <fantasai> Said: My understanding is that we like to provide the nicest experience for the user even during the transition period
19:38:50 <fantasai> Said: Having HDR without constraint doesn't seem nice
19:38:57 <fantasai> Said: so we want the default to be constrained-high for images
19:39:02 <astearns> ack ccameron
19:39:19 <fantasai> ccameron: One of my goals is to not lull people into the idea that they have good content because it looks good by default
19:39:30 <fantasai> ccameron: I want to show exactly what was specified up to capabilities of the machine
19:39:40 <fantasai> ccameron: and hope this will inform people to make good choices about how they use HDR
19:39:52 <Said> q+
19:39:58 <fantasai> ccameron: if specify too much, and end up getting 2x as bright because ...
19:40:37 <fantasai> ccameron: There is concern that I'm authoring to 10, but not knowing it
19:40:47 <fantasai> ccameron: HDR video authored with PQ is usually quite good.
19:40:58 <fantasai> ccameron: HDR images on iPhone, Pixel, etc are also good. They don't blow your eyes out.
19:41:16 <fantasai> ccameron: But ?? video shot at iPhone and Pixel is way too bright, looks bad, ruins people's eyes
19:41:27 <fantasai> ccameron: problem with that is, people were allowed to create the content without seeing what they're specifying
19:41:42 <fantasai> ccameron: I think it's better to show what was specified, and hope they are not making it unpleasant to view
19:42:11 <fantasai> ccameron: Should it turn out that we're wrong, and ppl can't do this right even when seeing what they're producing, then maybe ratchet down the defaults or global switch or something
19:42:22 <fantasai> ccameron: If we limit things by default, they will create bad content because won't see what they're specifying
19:42:49 <fantasai> ccameron: I want to give ecosystem a chance to get it right
19:43:00 <fantasai> ccameron: otherwise will be bad forever
19:43:01 <astearns> ack Said
19:43:19 <fantasai> Said: I disagree with ccameron
19:43:27 <fantasai> Said: Here's an example
19:43:41 <fantasai> Said: In WebKit, we limit animation to 60fps. But in Chrome, it uses device frame rate
19:43:53 <fantasai> Said: Chrome has already hit a problem where the frame rate can be 200 or 500, some device has this kind of speed
19:44:07 <fantasai> Said: and Chrome can't cope with this speed, and begins to limit it
19:44:14 <fantasai> Said: So I think unlimited would give you a bad experience
19:44:29 <astearns> ack fantasai
19:44:29 <fantasai> Said: We want to give the normal user the best experience.
19:44:53 <weinig> fantasai: Chris is making the argument we should give the author the opportunity to get it right
19:45:27 <weinig> fantasai: I am making the argument that there is a bunch of content out there where the author is not going to know, and user will get annoyed
19:45:39 <weinig> fantasai: not just about the transition period
19:45:50 <weinig> fantasai: constrained is a better default for the web
19:46:00 <weinig> fantasai: sophisticated authors will get it right
19:46:25 <weinig> fantasai: but many won't know how to make things right
19:46:30 <weinig> fantasai: better to make things opt in
19:46:44 <weinig> fantasai: you should not need to learn everything to use CSS
19:47:03 <ccameron> q+
19:47:22 <weinig> fantasai: shouldn't have to learn to turn down the headroom
19:47:58 <weinig> astearns: could be argued in either way
19:48:00 <astearns> ack ccameron
19:48:20 <weinig> astearns: could be hard to figure out how to make your photos look right
19:48:25 <fantasai> fantasai: If you want extra brightness you're expecting but not getting, then you can go looking for how to do it.
19:48:49 <fantasai> fantasai: but if your page is tacky and uncomfortable, as someone who isn't a designer, you might not even know why or that it's fixable
19:49:09 <fantasai> ccameron: I'm sympathetic to that argument, but in that case I would suggest a default of SDR
19:49:17 <fantasai> ccameron: since constrained high is [missed3]
19:49:31 <fantasai> ccameron: I could go for that. And maybe there's a bridge to that somehow.
19:49:38 <fantasai> ccameron: Keep going back to global thing.
19:49:40 <weinig> q+
19:49:53 <fantasai> ccameron: (something about gainmaps)
19:49:58 <astearns> ack weinig
19:50:01 <fantasai> ccameron: even if you have a very small headroom
19:50:10 <fantasai> weinig: I do think that the ideal default would be SDR
19:50:37 <fantasai> weinig: I would ask the browser vendors if that is a possibility, even though it would make some content that currently works not do what is expected
19:50:49 <fantasai> weinig: majority of content that wants to benefit from HDR values will learn about these properties
19:50:55 <fantasai> weinig: and in time get those properties set on them
19:51:03 <ccameron> q+
19:51:08 <fantasai> weinig: whereas if we start with unconstrained or a middle ground, it will always be fighting one battle or the other
19:51:23 <fantasai> weinig: both argument fantasai made and astearns made, that each group won't get behavior that makes sense
19:51:29 <fantasai> weinig: it would take video that's already HDR and make it not
19:51:32 <fantasai> weinig: but maybe that's OK
19:51:42 <fantasai> weinig: maybe there aren't enough websites that having this blip of compatibility isn't doable
19:51:46 <astearns> ack ccameron
19:51:57 <projecto-> projecto- has joined #css
19:52:19 <fantasai> ccameron: In terms of video, one difficulty is that right now tone-mapping videos to SDR is to do terrible and undefined things to the video
19:52:28 <leaverou_> leaverou_ has joined #css
19:52:49 <fantasai> ccameron: One of the nice things about images is that, from the moment they were defined in terms of SDR and in HDR, its' all parameterized in terms of headroom and it's great
19:52:54 <fantasai> ccameron: but for video, don't have that
19:53:14 <fantasai> ccameron: in many cases no ability to even tell the OS to render under constraints
19:53:28 <Rossen-> Rossen- has joined #css
19:53:32 <fantasai> ccameron: so that limits what we can do for video. Even if we want to, in some OSes it is technically impossible
19:53:42 <fantasai> ccameron: I do horrible things to make it "work" in Chrome
19:53:54 <fantasai> ccameron: We're working on standards to improve the situation
19:53:59 <shans_> shans_ has joined #css
19:54:13 <fantasai> ccameron: There's work going on in standards to improve video, to have double-graded content
19:54:25 <fantasai> ccameron: but for right now.... it would be a big amount of work
19:54:29 <sylvaing_> sylvaing_ has joined #css
19:54:44 <fantasai> ccameron: and it yes, there are pages that serve HDR content, usually professional stuff and they are paying for the bandwidth
19:54:58 <fantasai> ccameron: I think there's a chance we could push in a different direction in the future, but really built in right now
19:55:05 <fantasai> ccameron: Can we switch topic to names?
19:55:11 <fantasai> ChrisL: +1
19:55:27 <fantasai> astearns: I wonder if we can decide on an sdr default with video override in the UA stylesheet
19:55:34 <fantasai> weinig: I think we really need Simon for that
19:55:55 <fantasai> weinig: since I proposed that last time, and he had objected
19:56:00 <fantasai> astearns: OK, we'll take that back to the issue for now
19:56:32 <ChrisL> q+
19:56:33 <github-bot> Subtopic: [css-color-hdr] New values for dynamic-range-limit property
19:56:45 <astearns> ack ChrisL
19:57:44 <fantasai> Suggestions from ccameron at https://github.com/w3c/csswg-drafts/issues/11698#issuecomment-2662695204
19:58:22 <weinig> fantasai: its not clear that constrained is less constrained than standard
19:58:42 <weinig> ccameron: standard lines up with the media query, meaning most locked down
19:58:43 <fantasai> ccameron: Standard lines up with terminology and media query
19:58:48 <fantasai> ccameron: no-limit is pretty clear
19:58:57 <fantasai> ccameron: Do we agree on the two end points?
19:59:10 <fantasai> ChrisL: Yeah, it's just the middle one
19:59:25 <fantasai> ccameron: Constrained seems great to me, but I've been deep in this for a long time
20:01:28 <weinig> fantasai: maybe we can resolve on standard and no-limit, and ask the rest of the wg on names
20:01:44 <weinig> ChrisL: we already are pretty resolved on standard and limit
20:01:56 <weinig> s/limit/no-limit/
20:02:21 <weinig> fantasai: asking a person if constrained or standard is more constrained...
20:04:32 <weinig> https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571
20:05:59 <astearns> topic: side discussions
20:21:36 <JoshT> JoshT has joined #css
20:23:25 <ChrisL> rrsagent, make minutes
20:23:26 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/12-css-minutes.html ChrisL
21:22:43 <JoshT> JoshT has joined #css
21:23:03 <TabAtkins> plinss: is the server using an old version of Bikeshed? It's dying on the manifest update for some reason, and then dying trying to manually parse the csswg biblio file (which is gone now, thus triggering the error). That entire function it's erroring in was removed in the 5.1.1 update.
21:23:41 <TabAtkins> I can't reproduce the errors locally, which suggests to me that this might be a version from before I added the kdl-parsing code.
22:05:51 <JoshT> JoshT has joined #css
22:23:58 <JoshT> JoshT has joined #css
23:24:57 <JoshT> JoshT has joined #css
23:53:14 <JoshT> JoshT has joined #css