15:57:41 <RRSAgent> RRSAgent has joined #css
15:57:46 <RRSAgent> logging to https://www.w3.org/2025/05/14-css-irc
15:57:46 <Zakim> RRSAgent, make logs Public
15:57:47 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:23 <moonira> moonira has joined #css
15:58:26 <PaulG> PaulG has joined #css
15:58:34 <PaulG> present+
15:59:26 <JoshT> JoshT has joined #css
15:59:29 <emeyer> emeyer has joined #css
15:59:53 <emilio> present+
16:00:03 <kbabbitt> kbabbitt has joined #css
16:00:10 <kbabbitt> present+
16:00:23 <oriol> oriol has joined #css
16:00:26 <bramus> present+
16:00:30 <ydaniv> ydaniv has joined #css
16:00:46 <JoshT> present+
16:00:56 <kizu> kizu has joined #css
16:00:59 <kizu> present+
16:01:03 <jbreiland> jbreiland has joined #css
16:01:06 <andreubotella> andreubotella has joined #css
16:01:06 <oriol> present+
16:01:11 <andreubotella> present+
16:01:12 <jbreiland> present+
16:01:41 <schenney> schenney has joined #css
16:01:51 <flackr> flackr has joined #css
16:01:52 <schenney> present+
16:01:55 <bkardell> bkardell has joined #css
16:01:55 <flackr> present+
16:02:02 <bkardell> present+
16:02:06 <masonf> masonf has joined #css
16:02:06 <emilio> ScribeNick: emilio
16:02:46 <smfr> smfr has joined #css
16:03:03 <jfkthame> jfkthame has joined #css
16:03:35 <jensimmons> jensimmons has joined #css
16:03:40 <smfr> present+
16:03:41 <jensimmons> present+
16:03:45 <jfkthame> present+
16:03:53 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11195
16:03:53 <github-bot> Topic: [css-position-3] Absolute positioning - Is the new inset & auto-size behaviour web-compatible?
16:03:53 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11195.
16:03:55 <moonira> present+
16:04:09 <emilio> oriol: this was discussed a few weeks ago and I couldn't attend
16:04:18 <emilio> ... not sure if the consequences of the resolution were fully understood
16:04:44 <miriam> present
16:04:47 <miriam> present+
16:04:52 <emilio> ... the implication is that you can have an abspos with auto margins that if it has normal alignment it'd stretch, but if you change self-alignment to be stretch, then it will stop stretching
16:05:02 <emilio> ... I think that doesn't really make sense and would just cause confusion
16:05:27 <emilio> ... in flex and grid auto margins don't stretch even if they have stretch alignment
16:05:35 <emilio> ... but this happens both for stretch and normal alignment
16:05:42 <gfaujdar> gfaujdar has joined #css
16:05:43 <emilio> ... so I think it's better to have abspos be consistent
16:05:53 <gfaujdar> present+
16:06:02 <emilio> ... and avoid having the align-self: stretch align with flex / grid
16:06:13 <emilio> ... also the argument for making consistent with flex/grid feels weak
16:06:16 <futhark> futhark has joined #css
16:06:24 <emilio> ... in block layout auto margins don't prevent block level items
16:06:27 <emilio> ... from stretching
16:06:37 <emilio> ... so I'd like to change the previous resolution
16:06:41 <futhark> present+
16:06:49 <emilio> ... so that if they stretch with normal alignment they also stretch with stretch alignment
16:07:04 <emilio> fantasai: whichever way we go we are going to introduce inconsistencies
16:07:35 <emilio> ... in terms of alignment I think being consistent with flex/grid is more important because that's what authors are used to
16:07:49 <emilio> ... in block layout only blink has implemented and it's very recent so we can probably change it
16:08:16 <emilio> ... for normal we're stuck with css2, but for the other keywords it'd introduce inconsistencies
16:08:35 <emilio> ... are you proposing that auto margins are stronger than centering in flex/grid but not abspos? That seems like a bad idea
16:09:37 <emilio> ... I think maybe changing stretch only is better than the current situation, I admit it's quite weird that stretch is less stretchy than normal
16:09:52 <fantasai> s/I think//
16:10:06 <emilio> oriol: not sure the right way to look at this is props winning over other
16:10:22 <emilio> ... the way i see it is both margin and alignment have some effect simultaneously
16:10:31 <emilio> ... e.g. both may affect the auto size to be fit-content
16:10:49 <emilio> ... also auto-margins work by changing the margin box and alignment works in terms of that box
16:11:08 <emilio> ... so if you have auto margins that fills the whole container alignment won't do anything, but it's not like it is disabled
16:11:15 <emilio> ... it's more like it doesn't matter which value you use
16:11:37 <emilio> ... whether we decide that self-alignment forces auto size to be fit-content or auto margins do that I think it's independent decisions
16:11:44 <emilio> ... and it's not like some values win and they don't
16:11:50 <emilio> s/they/don't
16:11:53 <emilio> s/they/some
16:12:02 <emilio> ... e.g. even tho in flex and grid auto margins prevent stretching
16:12:14 <emilio> ... then center alignment could prevent stretching even with a 0 margin
16:12:25 <emilio> ... so we could say that center alignment is "winning" over the 0 margin
16:12:33 <emilio> ... so what wins and loses can be subjective
16:12:51 <emilio> ... I prefer seeing it as different things applying simultaneously
16:13:20 <emilio> fantasai: so iiuc, if you have auto margins and stretch, the first thing you do is stretch
16:13:33 <emilio> ... then auto margins end up having no effect (unless max-size is involved)
16:13:46 <emilio> oriol: exactly
16:14:06 <emilio> ... so in this case for abspos neither auto margins nor stretch alignment force fit-content size (so it can stretch)
16:14:28 <emilio> ... typically alignments won't matter because auto margins will resolve to 0 and then alignment would do nothing
16:14:40 <emilio> ... but if you have a max-size then you can align stuff using the alignment properties
16:15:00 <emilio> fantasai: I think that makes sense. There's a weird clause about negative and auto in this case, need to go back and check, but should be fine
16:15:24 <emilio> astearns: so prev resolution is no change to the spec, what should the spec say
16:15:58 <emilio> oriol: a way to word could be "change stretch alignment case to allow the size to stretch when the normal alignment case allows stretching"
16:16:08 <emilio> astearns: makes sense, wdyt fantasai?
16:16:11 <emilio> fantasai: yeah
16:16:12 <emilio> +1
16:16:26 <emilio> RESOLVED: change stretch alignment case to allow the size to stretch when the normal alignment case allows stretching
16:16:31 <vmpstr> present+
16:16:50 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11382
16:16:50 <github-bot> Topic: [cssom][css-grid] Do shorthands serialize with the resolved value of their longhands?
16:16:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11382.
16:17:13 <emilio> oriol: Some longhands have special getComputedStyle behavior, so you get the resolved rather than computed value
16:17:25 <emilio> ... it's not clear what happens when you're serializing a shorthand that involves these
16:17:31 <emilio> ... in the issue I have various examples
16:18:01 <emilio> ... e.g. margin: auto and you serialize margin-top you might get zero, but if you try to serialize the margin longhand itself you get auto in firefox but 0 in blink/webkit
16:18:07 <emilio> ... it's particularly weird in grid properties
16:18:14 <emilio> ... because the implicit tracks and repeat() expansion
16:18:15 <emilio> q+
16:18:25 <emilio> ... we have cases where all browsers are different
16:18:25 <astearns> ack fantasai
16:18:31 <emilio> ... I think I prefer what webkit does
16:18:50 <emilio> ... which is you serialize the shorthand as if the computed value of each longhand was set to each special resolved value
16:18:53 <fantasai> scribe+
16:18:56 <emilio> ... I think that's the most consistent
16:19:03 <fantasai> emilio: I agree.
16:19:31 <fantasai> emilio: FWIW, I consider the Firefox behavior to be a bug. Haven't gotten around to fixing, because the getters are in C++ and ...
16:19:48 <fantasai> emilio: What WebKit is doing, resolving each individual longhand, and then serializing shorthand with that is the right thing to do.
16:19:57 <fantasai> emilio: This is what Firefox does for all things that don't involve layout
16:20:35 <emilio> astearns: web compat concerns or other opinions?
16:20:49 <emilio> oriol: If webkit isn't having compat issues this is probably fine?
16:20:53 <TabAtkins> +1, I *suspect* this is reasonably safe
16:21:04 <TabAtkins> and we can always add exceptions as necessary
16:21:11 <fantasai> +1 TabAtkins
16:22:27 <emilio> PROPOSED: Shorthands serialize using the resolved value of the individual longhands
16:22:32 <emilio> RESOLVED: Shorthands serialize using the resolved value of the individual longhands
16:22:48 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/5813
16:22:48 <github-bot> Topic: [css-grid] grid-gap is still taking up space when an element defined in grid-template-area is not on the page.
16:22:48 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5813.
16:23:18 <emilio> oriol: the problem here is that's typical for authors when using grid to define some tracks in case some optional content is there
16:23:39 <emilio> ... if the optional content is not there, then if they use grid-gap you get extra space
16:23:53 <emilio> ... they basically want gaps to collapse together if there's no content in the track
16:24:10 <emilio> ... proposal is an `empty-tracks` property with an initial value of `normal`
16:24:36 <emilio> ... so empty tracks only collapse gaps with autofit
16:24:39 <kurt> kurt has joined #css
16:25:16 <emilio> ... then another value (`height` for `empty-cells` or `collapse` for consistency for `visibility`) that makes a track with no items in it or crossing it collapse
16:25:35 <emilio> ... there's other proposals which would make it collapse only if the sizing function is guaranteed to be zero
16:25:45 <emilio> ... or collapsing when the item spans
16:26:04 <emilio> ... but that adds a fair amount of complexity, and the simple solution already covers the vast majority of use cases
16:26:15 <emilio> ... for other variants we could consider other keywords in the future
16:26:20 <astearns> q?
16:26:21 <emilio> ... so I'd go with the simplest way
16:26:24 <emilio> q+
16:26:24 <astearns> ack emilio
16:26:34 <emilio> q+
16:26:43 <astearns> ack fantasai
16:26:47 <emilio> fantasai: I think this value makes sense
16:26:57 <emilio> ... some of the other behaviors are probably also valuable
16:27:05 <emilio> ... so I think the name should maybe be more extensible
16:27:36 <emilio> ... my suggestion is the `grid-collapse` property (`none` / `normal` as initial, `empty-tracks` as the value oriol is proposing)
16:27:45 <emilio> astearns: `grid-track-collapse` might be better?
16:27:48 <astearns> ack emilio
16:27:52 <alisonmaher> alisonmaher has joined #css
16:28:21 <astearns> q+
16:28:25 <emilio> emilio: was going to bring up the name as well
16:28:32 <emilio> ... but seems like a good idea
16:29:36 <emilio> astearns: Is this always going to be grid specific? Flexbox doesn't have this implicit things, but masonry might?
16:29:54 <astearns> ack fantasai
16:29:54 <emilio> ... just asking whether this should be layout agnostic since gaps are more layout-agnostic
16:30:09 <emilio> fantasai: conceptually it's about collapsing tracks, more than gaps
16:30:26 <emilio> ... re. grid vs. masonry they both use the grid-* track management properties
16:31:39 <emilio> ... if we're not making it grid specific we could do track-collapse, but I think grid- might make it easier to see they play together
16:31:50 <emilio> ... was going to bring up that the default value could maybe be more useful
16:31:58 <oriol> q+
16:32:07 <emilio> ... maybe if the track is completely empty and there's an intrinsic size it should collapse by default
16:32:16 <emilio> ... not sure about compat tho
16:32:24 <astearns> ack astearns
16:32:26 <emilio> astearns: yeah compat is a bit concerning here
16:32:31 <astearns> ack oriol
16:32:41 <emilio> oriol: a bit concern about changing the default for web compat
16:32:52 <emilio> ... the doing something different when the track sizing function is just intrinsic
16:33:12 <emilio> ... might be a bit weird. `auto` is intrinsic, but auto tracks stretches to fill, should it still be considered empty?
16:33:31 <emilio> ... this is related to the thing I talked about about whether the track is guaranteed to have a size of zero
16:33:38 <emilio> ... so in general more magic behavior worries me
16:34:08 <emilio> astearns: so details are going to be fuzzy, but sounds like starting to specify a `grid-track-collapse` prop might be a good idea?
16:34:31 <emilio> fantasai: if we call it `grid-collapse` we can expand it to `grid-collapse-{rows,columns}`
16:34:40 <kbabbitt> +1 fantasai
16:34:55 <emilio> ... the `track-` extra typing might be very wordy. Grid is mostly about tracks
16:35:04 <emilio> PROPOSAL: Start defining a `grid-collapse` property
16:35:07 <emilio> RESOLVED: Start defining a `grid-collapse` property
16:35:21 <fantasai> whereas grid-track-collapse-rows is very redundant
16:35:22 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/12102
16:35:22 <github-bot> Topic: [css-align] Clarify how `justify-self` affects automatic size of block-level box
16:35:22 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12102.
16:35:52 <emilio> oriol: two implementations of justify-self on block boxes (blink and servo). We interpreted some things that the spec says in different ways
16:36:01 <emilio> ... some things we agree on fantasai disagreed on
16:36:04 <emilio> ... want to clarify this
16:36:07 <emilio> ... two questions:
16:36:23 <emilio> ... first could be the effect of `justify-self` on the auto size of a block level box
16:36:40 <emilio> ... spec says that values other than stretch makes auto size fit-content
16:36:49 <emilio> ... so it applies to grid/flex items and block level items
16:36:54 <emilio> ... both blink and servo did this
16:37:18 <emilio> ... fantasai was interpreting it as this property doesn't affect block level sizing, only in over-constrained cases
16:37:38 <iank_> +1 to Oriol - it makes it more consistent w/ grid/flex
16:37:50 <emilio> ... I kinda prefer the fit-content behavior unconditional
16:37:58 <emilio> ... allows to explain tables
16:38:21 <emilio> ... could be explained as `justify-self: normal` on keywords is `start` rather than `stretch`
16:38:45 <emilio> ... on the other hand means diverging from `<center>` and html `align` attributes since those don't prevent stretching
16:38:53 <emilio> ... I prefer treating block-level boxes as other boxes
16:39:06 <emilio> ... but if fantasai wants to argue for an exception...
16:39:06 <astearns> ack fantasai
16:39:07 <iank_> q+
16:39:25 <emilio> fantasai: this also plays into the related issue about the effect of these properties when anon boxes are present
16:39:34 <emilio> ... anon boxes always stretch
16:39:59 <emilio> ... so there's an issue there where if you take the position that this affects fit-content you get inconsistent behavior if you have anon boxes
16:40:19 <emilio> ... I initially thought that this was fixing the alignment of stuff given how long block layout has existed
16:40:25 <emilio> ... guess we could go either way
16:40:27 <astearns> ack iank_
16:40:44 <emilio> iank_: IMO this makes the feature useful by default
16:40:57 <emilio> ... so kinda prefer how servo and blink interpret it
16:40:58 <emilio> q+
16:41:12 <astearns> ack emilio
16:41:20 <fantasai> emilio: Don't disagree, but was curious about the anonymous box situation
16:41:30 <fantasai> emilio: justify wouldn't apply to the anonymous box, right?
16:41:50 <fantasai> iank_: Concern for top-level anonymous boxes that are generated
16:42:07 <fantasai> iank_: consider our previous behavior a bug, so changed so that anonymous boxes ignore justify and always stretch, but we can talk about that issue separately
16:42:27 <fantasai> emilio: Makes sense to be consistent with block (???) to not introduce other issues
16:42:32 <fantasai> iank_: What do you mean?
16:42:40 <fantasai> emilio: If it doesn't do weird things if you have an anonymous block inside.
16:42:48 <fantasai> emilio: If that's ok, then making it work by default makes sense.
16:43:22 <fantasai> astearns: Do we have consensus? what's the resolution?
16:43:47 <fantasai> oriol: Values other than normal or stretch treat the automatic size as fit-content, just like in flex/grid
16:44:04 <fantasai> astearns: Does everyone agree?
16:44:45 <fantasai> fantasai: I'm ok with it.
16:44:47 <emilio> fantasai: we should ack that this makes justify-self not work for html centering stuff
16:44:48 <TabAtkins> yeah, we've abandoned doing <center> with this now
16:44:59 <emilio> PROPOSED: Values of `justify-self` other than normal or stretch treat the automatic size as fit-content, just like in flex/grid
16:45:03 <emilio> RESOLVED: Values of `justify-self` other than normal or stretch treat the automatic size as fit-content, just like in flex/grid
16:45:30 <emilio> oriol: there's another thing about how auto margins behave with this
16:45:39 <emilio> ... in servo we have different interpretations
16:46:16 <emilio> ... there's an example in the issue. If you set `justify-self: right` then the size will be `fit-content`, however if then you add auto margins, then these prevent `justify-self` from forcing fit-content
16:46:42 <emilio> ... in servo justify-self still prevents the stretching even with auto margins, and I think that makes more sense
16:46:53 <fantasai> +1
16:46:53 <oriol> https://github.com/w3c/csswg-drafts/issues/12102
16:47:28 <emilio> iank_: yeah basically, do auto margins disable justify-self or just the alignment part of it
16:47:35 <fantasai> If stretching is disabled for zero margins, then it should definitely be disabled for auto margins
16:47:53 <emilio> +1
16:48:15 <emilio> fantasai: this goes back to the first issue, where alignment is applied after margins
16:48:26 <fantasai> which are applied after sizing decisions
16:48:28 <emilio> oriol: right in this case the size of the margin box fills the container
16:48:48 <emilio> ... so you don't see the effect but it's not "not working"
16:49:07 <emilio> fantasai: if the box is larger than the container the auto margins will not absorb that space
16:49:16 <emilio> ... not sure we want the alignment to take effect in that case
16:49:27 <emilio> ... if you have auto margins you were expecting a particular alignment
16:49:41 <emilio> ... or do you just start-align it
16:49:47 <emilio> oriol: I think if you have unsafe alignment then why not
16:49:50 <emilio> ... but yeah, not sure
16:50:02 <emilio> iank_: I think auto margins are safe by default, so I think the defaults are actually the same
16:50:33 <emilio> fantasai: right but in this case the margin can't absorb the negative space
16:50:59 <emilio> iank_: but by default it's safe alignment so the default should be fine?
16:51:10 <emilio> fantasai: not sure it falls out of the definitions
16:51:21 <emilio> iank_: to be clear I'm fine changing blink here
16:51:24 <fantasai> I think CSS2.1 is written in a way that this wouldn't fall out.
16:51:33 <emilio> astearns: does the previous resolution apply here?
16:51:40 <emilio> oriol: probably should be a separate one
16:52:00 <emilio> ... the question that fantasai raised could be for a separate issue. We can resolve for the non-overflowing cases
16:52:36 <emilio> PROPOSED: alignment values different than stretch cause sizing to be fit-content, regardless of auto margins
16:52:41 <fantasai> PROPOSED: auto margins do not prevent justify-self from imposing fit-content
16:53:15 <fantasai> RESOLVED: auto margins do not prevent justify-self from imposing fit-content
16:53:40 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11461
16:53:41 <github-bot> Topic: [css-align] `justify-items` and anonymous block boxes
16:53:41 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11461.
16:53:46 <oriol> https://github.com/w3c/csswg-drafts/issues/11461#issuecomment-2842434810
16:54:28 <emilio> oriol: since we resolve justify-self can force fit-content size, if you use justify-items on a block container, a block container with inline level contents, justify-items won't apply
16:54:45 <emilio> ... if you then add a block, you add an anonymous block level box and justify-self applies to it
16:55:14 <emilio> ... so it's very unexpected that adding a block-level sibling changes the alignment
16:55:39 <emilio> ... option 1 would be that anon block boxes would always stretch rather than using justify-items of the parent
16:56:10 <emilio> ... another option would be that justify-items other than initial you'd still wrap stuff
16:56:30 <emilio> ... IMO option 1 is the easiest to implement in servo, also avoids some questions about what to do with percentages and so on
16:56:50 <iank_> +1 Oriol - There is a whole can of worms involved w/ option (2)
16:57:04 <emilio> ... percentages in the block axis skips anon boxes, should we skip them in the inline axis if we consider the other option?
16:57:26 <emilio> ... miriam preferred option 2 since it's more useful for authors (no need to wrap in implicit elements)
16:57:33 <astearns> ack miriam
16:57:57 <iank_> q+
16:58:03 <astearns> ack fantasai
16:58:04 <emilio> miriam: oriol described what I think, alignment is one of the more common things to do and doing it easily makes sense
16:58:10 <fantasai> https://www.w3.org/TR/css-text-4/#text-group-align-property
16:58:14 <emilio> .. but either option feels better than the alternative
16:58:29 <emilio> fantasai: there's one property that allows you to wrap things, not sure it's implemented
16:58:46 <emilio> ... the behavior you want is not the behavior that would fall off from wrapping in anon boxes
16:59:11 <emilio> ... consider a paragraph with text, block level, then text
16:59:39 <emilio> ... if we wrap each in a box then they'd be independently aligned which I'm not sure is what you want
16:59:50 <astearns> ack iank_
16:59:55 <emilio> iank_: pretty against option 2
17:00:07 <emilio> ... quite a large can of worms
17:00:14 <emilio> ... probably big source of confusion for web devs too
17:00:21 <emilio> ... a little concerned about compat too
17:00:49 <emilio> ... so prefer option 1, authors ??? text-align
17:01:08 <emilio> astearns: we could resolve on updating the spec to option 1 with a note
17:01:16 <emilio> miriam: ok with that
17:01:38 <emilio> PROPOSED: Anonymous block boxes always stretch
17:02:15 <emilio> RESOLVED: Anonymous block boxes always stretch (go with option 1)
17:02:36 <astearns> topic: end
17:02:45 <astearns> Zakim, end meeting
17:02:45 <Zakim> As of this point the attendees have been PaulG, emilio, kbabbitt, bramus, JoshT, kizu, oriol, andreubotella, jbreiland, schenney, flackr, bkardell, smfr, jensimmons, jfkthame,
17:02:48 <Zakim> ... moonira, miriam, gfaujdar, futhark, keithamus, vmpstr
17:02:48 <Zakim> RRSAgent, please draft minutes v2
17:02:49 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/14-css-minutes.html Zakim
17:02:56 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:02:56 <astearns> topic: none
17:02:56 <Zakim> Zakim has left #css
17:03:02 <futhark> futhark has left #css
17:24:41 <emeyer> emeyer has left #css
19:01:56 <keithamus> keithamus has joined #css
20:31:51 <Linux_Kerio> Linux_Kerio has joined #css
23:09:00 <keithamus> keithamus has joined #css