22:57:19 <RRSAgent> RRSAgent has joined #css
22:57:23 <RRSAgent> logging to https://www.w3.org/2024/09/04-css-irc
22:57:23 <Zakim> RRSAgent, make logs Public
22:57:24 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:00:43 <masonf> masonf has joined #css
23:00:58 <flackr> flackr has joined #css
23:01:17 <kbabbitt> kbabbitt has joined #css
23:02:13 <schenney> schenney has joined #css
23:02:17 <schenney> present+
23:02:20 <dholbert> dholbert has joined #css
23:02:41 <kbabbitt> present+
23:02:59 <andreubotella> andreubotella has joined #css
23:03:19 <ethanjv> ethanjv has joined #css
23:03:45 <chrishtr> present+
23:03:53 <miriam> present+
23:04:03 <andreubotella> present+
23:04:19 <dholbert> present+
23:05:22 <TabAtkins> present+
23:05:59 <alisonmaher> alisonmaher has joined #css
23:06:02 <alisonmaher> present+
23:06:23 <ethanjv> present+
23:06:24 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900
23:06:24 <github-bot> Topic: Republishing Tasks Permathread
23:06:24 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.
23:06:58 <andreubotella> astearns: Tab asked for a new WD for anchor positioning. If all of the edits have resolutions, we don't need a resolution for publishing a new version, but we might as well
23:07:36 <andreubotella> TabAtkins: Not 100% sure everything has a resoltuion. I might have made small edits that didn't have a proper resolution. We also have a lot of renamings that need to be reflected on the WD
23:08:12 <andreubotella> fantasai: Will review the changelog before publishing
23:08:25 <florian> +1
23:08:42 <andreubotella> REOSOLVED: new WD for anchor positioning
23:08:55 <astearns> RESOLVED: new WD for anchor positioning
23:09:14 <andreubotella> github-bot, take up https://github.com/w3c/csswg-drafts/issues/5335
23:09:14 <github-bot> Topic: [css-inline-3] text-box-trim vs fragmentation
23:09:14 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5335.
23:10:55 <astearns> q+
23:10:55 <andreubotella> fantasai: I was chatting with Jen Simmons about how text-box-trim interacts with fragmentation. We have a discussion about setting text-box-trim in a box in the flow that gets fragment, but not on the multicol element. There's a lot of column boxes inside it, should it apply to any of them?
23:11:09 <andreubotella> Probably makes sense to apply to the first and last line box in each column
23:11:21 <andreubotella> assuming there's no intervening padding or borders
23:11:25 <chrishtr> +1
23:11:28 <miriam> +1
23:11:29 <andreubotella> frivoal: makes sense to me
23:12:10 <andreubotella> astearns: I know of a use case where we'd want to trim all of the top and bottom (?) of a column except for the very first and last. But we can handle that with the :column element
23:12:33 <andreubotella> frivoal: I'm aware of that for trimming margins, but this issue is about trimming the top and bottom of lines. Is that correct as well?
23:13:04 <andreubotella> astearns: You might be right that it might apply only to margins. There might also be a usefulness for lines. But yes, it should apply only to the top and bottom if it applies to multicolumn
23:13:26 <andreubotella> bfgeek: My concern is that if applied to the end, it might shorten the column box, which might change the fragmentation point
23:13:46 <andreubotella> fantasai: When fragmenting, you'd have to be aware of whether the line box to add to a page is trimmed or not
23:13:47 <astearns> ack astearns
23:13:59 <andreubotella> bfgeek: It's more complex, because of interactions with collapsing margins at the end
23:14:21 <andreubotella> I dont' know if this is implementable for end trimming
23:14:40 <andreubotella> frivoal: In this issue we're talking about trimming leading in lines, does that also affect?
23:15:24 <dholbert> q+
23:16:19 <andreubotella> astearns: We might need some make-forward-progress algorithm where you decide where the fragmentation break is, then apply the trimming, and not reconsider the break
23:17:04 <andreubotella> fantasai: It's similar to when trying to see if something fits, you truncate the margins. If there are borders or padding, you already cannot trim. It's different between line boxes and at the end of the element, so when you evaluate whether you fit, you trim the line box
23:17:26 <andreubotella> if additional content fits, then you move forwards
23:17:47 <andreubotella> frivoal: it's clear it's desirable, but not clear how doable. Can we edit it later if it's too hard?
23:18:19 <andreubotella> fantasai: I think that's reasonable. Because margins are invisible, it doesn't matter whether you consider the box trim or not. It's only when placing the content and checking wherther it fits before the end of the page is when you need to consider trimming
23:18:31 <andreubotella> bfgeek: What is the behavior with empty elements that are after this?
23:18:57 <masonf> masonf has joined #css
23:19:00 <andreubotella> If there's a subsequent empty element. That's not considered (?) if there's an empty element afterwards
23:19:13 <andreubotella> That's complex because we don't want to arbitrarily look forwards to see if this is the last
23:20:15 <andreubotella> fantasai: If the bottom edge of my box is 1em from the bottom of the page, but it has a bottom-margin of 2em
23:20:26 <andreubotella> we truncate the margin to the extent necessary to make it fit
23:21:30 <astearns> ack dholbert
23:22:02 <andreubotella> dholbert: when fantasai was talking about how it works in practice, discounting the text-box-trim for the purposes of seeing if the element fits, should it also make the element draw a smaller border box if it happens to fit when this is taken into account?
23:22:12 <andreubotella> should the border box extend to the bottom of the column?
23:22:32 <andreubotella> s/border box/background/
23:22:49 <andreubotella> fantasai: do you mean a block background or an inline background?
23:23:06 <andreubotella> dholbert: if the line of text has a background, i'm thinking of a span that has a background
23:23:35 <andreubotella> ...
23:23:51 <andreubotella> fantasai: as an author, you don't want to combine text-box-trim with a block background
23:24:07 <andreubotella> in the long term, we might want to have a control for this, similar to margin-trim for margins, but this would be the default
23:24:16 <fantasai> s/margin-trim/margin-break/
23:24:31 <andreubotella> astearns: should we specify the behavior as florian suggested, and reopen the issue if there are implementability concerns? or do we take it back to the issue for now?
23:24:52 <andreubotella> fantasai: I think this is what people would want if they set text-box-trim on multicolumn. The alternative is it doesn't apply at all
23:25:05 <andreubotella> frivoal: If it applies only to the first column, it's worse because you have unbalanced columns
23:25:32 <andreubotella> astearns: any objections, dholbert and bfgeek?
23:26:28 <andreubotella> bfgeek; there's some complexity because, the way it works we'd need to backtrack. For example, you place a line box, there's 10px of space remaining. You need to lay out the next line box, because it might only be 8px
23:26:46 <andreubotella> But if it's 12px high, you need to backtrack and go to the previous line box, and then trim it, which is a bit scary
23:26:54 <andreubotella> you don't know if it's the last line box until you lay out the next line
23:27:37 <andreubotella> frivoal: Having it only apply to the first column and not the others will be ugly. In general, for the problem, if we only trim at the first column it's bad
23:27:54 <andreubotella> same for printing and pagination, if you have a multi-page document, you want the top and bottom to match
23:28:44 <andreubotella> bfgeek: At the minimum we'd want trim-top. I'll talk to Morten to see how feasible is trimming the bottom if we have to backtrack
23:29:24 <andreubotella> fantasai: Once you've decided that the line box fits, you can forget about whether you trimmed it. It only matters if you drew a background, and if you do, you have the question of where it ends
23:29:34 <andreubotella> You have to make sure the background doesn't go beyond the fragmentainer edge
23:29:44 <andreubotella> bfgeek: It affects more things than that
23:30:22 <andreubotella> astearns: We should table the discussion of how it should work for now. bfgeek, are you okay having the conversation with Morten before resolving?
23:30:27 <andreubotella> bfgeek: yeah
23:30:46 <andreubotella> frivoal: Can we resolve to do it on the start side and leave the end side open?
23:30:54 <andreubotella> astearns: We'll discuss that next time
23:30:57 <dholbert> fwiw the "in what ways is the column-end-trimming observable [and how do we need to tidy up after ourselves after placing that line]"is the bit that I'm wondering about too
23:31:04 <andreubotella> github-bot, take up 10761
23:31:04 <github-bot> andreubotella, I can't comment on that because it doesn't look like a github issue to me.
23:31:18 <andreubotella> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10761
23:31:18 <github-bot> Topic: [css-box-4] Applying `margin-trim` to fragmentation containers
23:31:18 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10761.
23:31:43 <fantasai> dholbert: it's observable wrt what fits in the column, and if the multicol box itself is auto-height
23:32:45 <florian> q+
23:32:49 <andreubotella> fantasai: Jen and I think it makes sense if an author applies margin-trim to a multicolumn container, that it should apply to both the top and bottom
23:32:59 <fantasai> of the column box
23:33:40 <andreubotella> bfgeek: For grid and flex I don't think it's a problem. For block layout, we have the same problem as before: start is fine, end is even more complex than text-box-trim
23:33:53 <andreubotella> When you're processing an element, you fundamentally don't know the end margin of it
23:34:22 <fantasai> andreubotella: for line-clamp: auto I'm keeping track of the bottom margins in order to subtract relevant sizes when computing block size
23:34:34 <fantasai> andreubotella: that's currently implemented in Blink, but only when you have line-clamp
23:34:38 <fantasai> andreubotella: idk if it could be useful for this
23:34:47 <astearns> ack florian
23:35:12 <andreubotella> florian: in terms of use cases, this is important to consider, because trimming the margins at the start of all columns is something authors may want
23:35:26 <fantasai> https://www.w3.org/TR/css-break-4/#break-margins
23:36:31 <andreubotella> ... this exists in AntennaHouse, which means there's demand for it
23:36:57 <andreubotella> fantasai: we have that spec'd on the ... property. If it says keep, you keep it regardless of margin-trim
23:37:33 <fantasai> s/.../margin-break/
23:38:24 <andreubotella> bfgeek: I'm oscillating between "it's actually easier" and "it's harder". I'd like to talk to Morten about it
23:38:41 <andreubotella> we could resolve that it only applies to block layout
23:38:51 <andreubotella> that might be something to make forward progress
23:39:28 <andreubotella> PROPOSED: margin-trim only applies to a multicolumn container by trimming block-level margins at the top and bottom of each column box
23:39:43 <andreubotella> florian: Is this only multicolumn? Pages printed side-by-side have the same demands
23:39:50 <andreubotella> fantasai: What are you setting it on then?
23:39:54 <andreubotella> florian: The root?
23:40:14 <andreubotella> fantasai: They're both kind of similar, I'd like to resolve on this one sooner than later
23:40:26 <andreubotella> bfgeek: I'll meet with Morten next week and chat with him abotu this
23:40:40 <andreubotella> astearns: If we have not come back to this by TPAC, I'll make sure it's on the agenda then
23:41:01 <andreubotella> github-bot, please take up https://github.com/w3c/csswg-drafts/issues/10321
23:41:01 <github-bot> andreubotella, Sorry, I don't understand that command.  Try 'help'.
23:41:02 <iank_> ive got to drop now soryr.
23:41:11 <andreubotella> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10321
23:41:11 <github-bot> Topic: [css-anchor-position] `position-anchor` should be defined as a longhand of `position`
23:41:11 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10321.
23:41:41 <andreubotella> TabAtkins: A while back, we resolved to make position a shorthand for position-type (setting the absolute, fixed... keywords) and position-anchor
23:41:53 <andreubotella> We've experimented since then, and the Chrome team would like to reverse this resolution
23:42:19 <andreubotella> Compat reason: we'd thought there would be a stronger compat reason to not shorthand position or other properties, but upon further review, while there's still risk, it's not that bad
23:42:26 <andreubotella> so we should consider shorthanding these older property
23:42:36 <andreubotella> we don't want to do it without a good reason because it's risky though
23:42:44 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/10321#issuecomment-2136102979
23:42:56 <andreubotella> Also, after some thought, we don't agree with shorthand position being part of the position shorthand
23:43:27 <andreubotella> while we have a pretty strong tradition of prefix name shorthands being shorthands for properties with the same prefix, but it's not as strong as thought
23:43:32 <andreubotella> there's a list in that thread
23:43:52 <andreubotella> THe argument from langauge design is weaker than we thought, and that strengthens the argument for not making it
23:44:09 <andreubotella> to make a reasonable shorthand out of this, you need more complex grammar, which makes it harder to use
23:44:09 <astearns> q+
23:44:23 <andreubotella> this is in the category of properties that are adjacent to other properties but shouldn't be reset together
23:44:30 <astearns> ack fantasai
23:44:42 <andreubotella> shouldn't reset, especially if you're switching from static to fixed
23:45:00 <andreubotella> so we object to making position a shorthand right now, and in particular with making position anchor a part of that shorthand
23:45:34 <andreubotella> astearns: is the complexity of the shorthand across all the value spaces, or does it only get complex when trying to set anchor positioning values?
23:45:52 <andreubotella> TabAtkins: both. The first, because anchor positioning only appliies to static or fixed, ...
23:46:11 <andreubotella> fantasai: That's not true, if you set to sticky it would ignore all of the anchor positioning stuff
23:46:36 <andreubotella> TabAtkins: I think none is one of the few obvious counterexamples, but more complex distinctions we don't do too often
23:46:37 <astearns> ack astearns
23:47:03 <andreubotella> the second bit of complexity: ... and ... are custom idents, so we'd need to make them distinguishable
23:47:22 <TabAtkins> like, `position: absolute --foo / --bar`
23:47:22 <andreubotella> explicitly setting position: absolute, maybe with container in there, and then ... gives a more readable CSS in our opinion
23:48:08 <andreubotella> fantasai: We are interested in trying to adress Chrome's concerns. We're happy with the spec as it is now until those concerns are solved, but not happy with reverting before
23:49:02 <andreubotella> florian: I agree with TabAtkins about the language not being consistent with the prefix not always being the shorthand. About position resetting all of the longhands, how important is it?
23:49:17 <andreubotella> fantasai: it depends on whether we want a shorthand that sets it together
23:49:28 <andreubotella> we'd have to design that and put it out to the whole working group
23:49:50 <andreubotella> florian: Even if the shorthand doesn't set it together, for the things that are set by position, would you have interference from the other things set by it?
23:50:03 <andreubotella> If we're reverting and leaving the issue open for now, I'm good with it
23:50:22 <andreubotella> TabAtkins: ... and inset-area being set together ...
23:50:29 <andreubotella> fantasai: That's a problem with the UA stylesheet
23:50:38 <TabAtkins> s/inset-area/insets and position-area/
23:50:49 <andreubotella> RESOLVED: undo the previous resolution and not add position-anchor and position-type to the position shorthand for now
23:50:51 <florian> s/from the other things set by it/from the other things set by it if they don't get reset
23:51:07 <fantasai> scribenick: fantasai
23:51:14 <andreubotella> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10448
23:51:14 <github-bot> Topic: [css-overflow-4] display: -webkit-box and line-clamp without -webkit-box-orient: vertical
23:51:14 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10448.
23:51:42 <fantasai> andreubotella: We had agreed to a compat workaround for line-clamp
23:51:54 <fantasai> andreubotella: if you have -webkit-box and -webkit-box-orient: vertical
23:52:08 <fantasai> andreubotella: then either line-clamp or -webkit-line-clamp would make it not a flex, and make it a block
23:52:14 <fantasai> andreubotella: and -webkit-line-clamp would apply
23:52:23 <fantasai> andreubotella: issue is if you have line-clamp on block containers
23:52:48 <fantasai> andreubotella: should display: -webkit-box + line-clamp without box-orient, should it also trigger the behavior of making it a block container?
23:53:16 <fantasai> andreubotella: I agree with Florian that -webkit-line-clamp only applies with -webkit-box and -webkit-box-orient:vertical
23:53:27 <fantasai> andreubotella: but if you have [missed]
23:53:31 <florian> q+
23:53:52 <astearns> ack florian
23:53:53 <fantasai> andreubotella: if you have -webkit-box and line-clamp, is -box-orient also required?
23:54:01 <fantasai> florian: This problem is more difficult to dscribe than to solve
23:54:12 <fantasai> florian: we have a weird compat hack that is required when you have -webkit-line-clamp
23:54:19 <fantasai> florian: and is allowed for line-clamp
23:54:25 <fantasai> florian: I don't think we need to generlaize
23:54:35 <fantasai> florian: we need to support the set for -webkit-line-clamp to work
23:54:53 <fantasai> florian: it needs to not work when the whole set is not there, because the Web depends o nit not triggering if any piece is missing
23:55:00 <fantasai> florian: if you don't have the full thing, then don't blockify the flexbox
23:55:09 <fantasai> florian: the non-hacky version doesn't apply to flexboxes
23:55:19 <fantasai> florian: not helpful, and not needed for compat, so keep it simple
23:55:36 <fantasai> florian: already resolved that the new line-clamp works if you have the full set of weird stuff
23:55:49 <fantasai> florian: but if you only have one of them, then we don't trigger the magic condition, and shouldn't
23:55:57 <fantasai> florian: so proposal is no change, just clarify with a note
23:56:33 <fantasai> astearns: proposed no change to spec, add a note mentioning the new version doesn't interact with only part of the old hack
23:56:52 <fantasai> RESOLVED: no change to spec, add a note
23:57:01 <github-bot> Topic: [css-easing-2] Linear easing function requires at least two points?
23:57:46 <fantasai> TabAtkins: reviewing the easing spec, I realized the algorithm for parsing the list of points in linear() didn't match up with how we do lists of points elsewhere, e.g. radial-gradient()
23:57:52 <fantasai> TabAtkins: where we allow single points
23:57:55 <fantasai> TabAtkins: or one value with two positions
23:58:10 <fantasai> TabAtkins: I'm hoping for resolution that we change the linear() parsing to be similar to gradient parsing
23:58:16 <fantasai> TabAtkins: allow a single value, whether 2 positoins or 1 position
23:58:21 <fantasai> TabAtkins: and do the obvious thing with that
23:58:54 <TabAtkins> the "obvious" behavior is that it's a flat line at the given value
23:58:59 <fantasai> astearns: proposed to allow linear() easing function to have a single stop
23:59:18 <fantasai> RESOLVED: Allow linear() to have a single stop
23:59:39 <fantasai> Topic: Administrative
23:59:50 <fantasai> astearns: OpenUI meeting tomorrow. Come talk about form controls!
00:00:28 <fantasai> https://www.w3.org/events/meetings/178efb2e-e0a7-4b6c-9b39-ef2dba1a3457/
04:13:29 <Linux_Kerio> Linux_Kerio has joined #css
04:30:33 <Zakim> Zakim has left #css