23:00:29 <RRSAgent> RRSAgent has joined #css
23:00:29 <RRSAgent> logging to https://www.w3.org/2022/09/07-css-irc
23:00:31 <Zakim> RRSAgent, make logs Public
23:00:32 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:00:57 <oriol> oriol has joined #css
23:01:51 <oriol> present+
23:01:52 <flackr> flackr has joined #css
23:01:55 <flackr> present+
23:02:21 <dholbert> present+
23:02:25 <dlibby> dlibby has joined #css
23:02:58 <miriam> present+
23:03:04 <fantasai> present_
23:03:07 <fantasai> present+
23:03:15 <dlibby> present+
23:03:45 <fantasai> ScribeNick: fantasai
23:04:13 <fantasai> Topic: Administrivia
23:04:24 <fantasai> astearns: If you're attending TPAC, in-person or remote, please sign up on the wiki
23:04:26 <heycam> heycam has joined #css
23:04:30 <fantasai> https://wiki.csswg.org/planning/tpac-2022
23:04:50 <fantasai> astearns: If dialing in for an issue, letting me know which issues and when you're available would be helpful
23:05:16 <fantasai> Topic: Scroll Animations
23:05:38 <fantasai> fantasai: Scroll Animations, most edits are in, looking for FPWD next week
23:05:40 <fantasai> https://drafts.csswg.org/scroll-animations-1/
23:05:46 <dgrogan> present+
23:05:53 <fantasai> https://github.com/w3c/csswg-drafts/pull/7710
23:06:01 <fantasai> Topic: Administrative (revisted)
23:06:13 <fantasai> dholbert: What's the schedule exactly?
23:06:22 <fantasai> dholbert: joint meeting, is CSSWG the rest of the day?
23:06:29 <fantasai> astearns: yes, joint meeting is just as listed
23:06:35 <fantasai> astearns: and CSSWG the rest of Thu/Fri
23:06:42 <fantasai> astearns: [describes various timeslots etc]
23:06:51 <fantasai> astearns: When in session / when on break, is on TPAC events page
23:07:02 <fantasai> dholbert: you mean the wiki?
23:07:13 <fantasai> astearns: No, the calendar invite page
23:07:19 <fantasai> astearns: I'll update wiki with links to all the things
23:07:25 <fantasai> dholbert: thanks
23:07:38 <fantasai> Topic: CSS Contain
23:07:48 <fantasai> Subtopic: [css-contain-3] .conditionText and name vs query
23:08:08 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7190
23:08:47 <fantasai> miriam: Currently we have .conditionText which is a single string
23:09:01 <fantasai> miriam: but includes 2 parts, a name for name of container and a query for the conditions to match against that container
23:09:10 <fantasai> miriam: so proposal is to keep .conditionText as the entire query
23:09:20 <fantasai> miriam: but add .containerName and .containerQuery so you can get the parts yourself
23:09:27 <alisonmaher> alisonmaher has joined #css
23:09:32 <fantasai> astearns: if we have the parts, why do we need the concatenated thing?
23:09:43 <fantasai> TabAtkins: to match the other conditional rules
23:09:55 <fantasai> heycam: it inherits from ConditionalRule, so need to say what that property returns
23:09:59 <fantasai> astearns: Anyone with opinions?
23:10:01 <TabAtkins> +1
23:10:01 <fantasai> +1 from fantasai
23:10:06 <fantasai> heycam: makes sense to me
23:10:09 <TabAtkins> (and emilio already implemented it, apparently)
23:10:13 <fantasai> heycam: just question, the one that returns the expression
23:10:19 <fantasai> heycam: that doesn't include the parentheses?
23:10:31 <fantasai> miriam: that would include potentially multiple expressions
23:10:36 <fantasai> heycam: was asking about outermost parens
23:10:41 <fantasai> miriam: they're not required
23:10:45 <fantasai> miriam: no need to include them there
23:11:01 <fantasai> heycam: ah, so parens are part of the expression, not extra syntax
23:11:03 <fantasai> miriam: right
23:11:16 <fantasai> astearns: objections?
23:11:42 <fantasai> miriam: @andruud already posted a PR, so we could resolve to merge the PR
23:12:10 <fantasai> astearns: Not seeing anything about parens
23:12:19 <fantasai> miriam: if they are included, not part of the .containerQuery?
23:12:34 <fantasai> astearns: need to know whether to expect the parens
23:12:40 <fantasai> miriam: could merge the PR and add that as well
23:12:44 <astearns> ack fantasai
23:12:50 <heycam> fantasai: the syntax is like for MQs
23:13:11 <heycam> fantasai: so there are potentially a redundant set of parens around the entire expression, but in lots of cases you'll have ( expr ) or ( expr )...
23:13:20 <heycam> fantasai: any parens there should appear there
23:13:27 <heycam> fantasai: if we want to simplify, we should do it all the way through
23:13:37 <fantasai> heycam: I guess I wasn't suggesting simplification
23:13:49 <fantasai> heycam: wasn't sure if outermost parens were part of @container rule syntax
23:13:55 <fantasai> heycam: but sounds like it's part of the expression
23:14:01 <fantasai> astearns: so it's just as specified, with whatever parens
23:14:03 <fantasai> miriam: yes
23:14:11 <fantasai> astearns: then we can resolve to accept this PR and add these attributes
23:14:21 <fantasai> RESOLVED: Add .containerName and .containerQuery
23:14:31 <fantasai> Subtopic: [css-sizing] Define precise timing for setting last remembered size?
23:14:45 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7659
23:15:01 <fantasai> oriol: Spec says that when element needs to record last remembered size, occurs when ?? events occur
23:15:12 <fantasai> oriol: but may be multiple observers that need to be notified
23:15:18 <fantasai> oriol: what happens if callbacks are involved?
23:15:22 <fantasai> oriol: [missed]
23:15:32 <fantasai> oriol: Implementations for the last remembered size are using an internal ResizeObserver
23:15:38 <fantasai> oriol: it will be sorted somewhere in this list of observers
23:15:48 <fantasai> oriol: other callback observers can observe whether the last rememberd size was recorded
23:16:10 <fantasai> oriol: so webpage can notice that current impl in Blink and Firefox, they are creating this internal ResizeObserver the first time an element needs to update its size
23:16:25 <fantasai> oriol: then this interal ResizeObserver is preserved for other elements that may need to update their last remembered size
23:16:34 <fantasai> oriol: even if nothing needs to be updated, the ResizeObserver is not removed
23:16:39 <fantasai> oriol: it continues to exist
23:16:49 <fantasai> oriol: We are exposing these implementation details to web pages
23:16:55 <fantasai> oriol: My question is, are we fine with that?
23:17:15 <fantasai> oriol: This is the simplest way to impelemtn it, but shouldn't be hard to say that the last remembered size should be recorded before other ResizeObserver callbacks are involved
23:17:31 <fantasai> oriol: this would be consistent with creating such observers at the very beginning of the creation of the document
23:17:49 <fantasai> oriol: What do people think? Should we keep exposing these? Should we define a specific order?
23:18:02 <fantasai> TabAtkins: I don't think exposing these impl details is good, and your suggestion of timing is good
23:18:08 <fantasai> TabAtkins: would be happy to write that into the spec
23:18:26 <fantasai> iank_: Just to clarify, this would be internal ResizeObserver would be effectively inserted as first in the list of ResizeObservers or something similar to that?
23:19:00 <fantasai> oriol: Yes, that would be the proposal
23:19:32 <fantasai> oriol: Other ResizeObservers can be created and appended, so best to say it's first, before other ResizeObservers are involved
23:20:01 <fantasai> astearns: Only change to authors would be less info about...
23:20:23 <fantasai> oriol: Effect would be if they create their own ResizeObserver, by the time their callback is called the last remembered size will have been recorded
23:20:38 <fantasai> oriol: otherwise it might not be recorded yet, and might fall back to fallback of contain-intrinsic-size
23:21:04 <fantasai> astearns: Any objections to setting this precise timing?
23:21:29 <fantasai> RESOLVED: Accept Oriol's proposal to record last remembered size first before ResizeObserver callbacks
23:21:42 <fantasai> Topic: [css-sizing] Last remembered size for non-atomic inlines?
23:21:47 <fantasai> github: [css-sizing] Last remembered size for non-atomic inlines?
23:21:57 <astearns> github: https://github.com/w3c/csswg-drafts/issues/7606
23:22:00 <fantasai> oriol: Spec doesn't clarify the details of what size we are recording as the last remembered size
23:22:10 <fantasai> oriol: for non-atomic inline elements, it's hard to determine a size
23:22:18 <fantasai> oriol: ? has a size of 0x0
23:22:26 <fantasai> oriol: when recording a size, we have two resonable ways
23:22:30 <fantasai> oriol: one is to store 0x0 as usual
23:22:35 <fantasai> oriol: this is what implementations are currently doing
23:22:43 <fantasai> oriol: might be a bit surprising since not the real size, just an arbitrary decision
23:22:50 <bradk> bradk has joined #css
23:22:56 <fantasai> oriol: another possibility would be doing the same that we do for display:none or when not generating a box
23:23:02 <fantasai> oriol: we are not storing the last remembered size
23:23:10 <fantasai> oriol: and we allow the element to keep a previously-set last remembered size
23:23:14 <fantasai> oriol: I don't have a strong opinion
23:23:22 <fantasai> oriol: bit of an edge case, since inline elements do not support size containment
23:23:34 <fantasai> oriol: so this will only matter if you are dynamically changing the display from 'inline' to other things
23:23:39 <fantasai> oriol: but would like to clarify expected behavior
23:23:46 <bradk> present+
23:23:46 <fantasai> astearns: when you say Chrome and FF are treating inlines as 0x0
23:23:53 <fantasai> astearns: WebKit result is different? or don't know?
23:23:58 <fantasai> oriol: I think WK has not implemented this feature
23:24:21 <fantasai> TabAtkins: I have no attachment to either solution
23:24:30 <fantasai> TabAtkins: in absence of a reason for a change, would stick with existing behavior
23:24:42 <fantasai> dholbert: Seems weird to have different behaviors for transiently display:none vs display:inline
23:24:53 <fantasai> dholbert: without a good reason for 0x0 it feels arbitrary to have those differ
23:25:06 <fantasai> dholbert: what happens if you 'display: contents' or other value?
23:25:14 <fantasai> dholbert: would be best to have a consistent answer to "no sensible size"
23:25:17 <fantasai> TabAtkins: that's fair
23:25:44 <fantasai> astearns: other opinions?
23:25:48 <fantasai> [silence]
23:26:02 <fantasai> astearns: Proposed resolution is to not accept current behavior in impls, but go with option 2 of not recording the size
23:26:06 <fantasai> astearns: any objections?
23:26:10 <bradk> bradk has joined #css
23:26:13 <fantasai> RESOLVED: display:inline doesn't record a size
23:26:27 <fantasai> Topic: [css-sizing] Last remembered size when fragmented?
23:26:32 <fantasai> s/Topic/Subtopic/
23:26:38 <fantasai> github:
23:26:40 <astearns> github: https://github.com/w3c/csswg-drafts/issues/7598
23:26:42 <fantasai> github: [css-sizing] Last remembered size when fragmented?
23:26:49 <fantasai> github: [css-sizing] Last remembered size when fragmented?
23:27:32 <fantasai> oriol: This is about what we do when we are in multicol or printing
23:27:36 <fantasai> oriol: elements can get fragmented
23:27:42 <fantasai> oriol: in that case, what the ResizeObserver does
23:27:47 <fantasai> oriol: is it only provides the size of the first fragment
23:27:57 <fantasai> oriol: ResizeObserver spec has plans to add sizes of more fragments
23:28:07 <fantasai> oriol: but for now implementations are only storing the first fragment
23:28:23 <fantasai> oriol: I think this is reasonable, because we cannot try to keep the same number of fragments and size for each
23:28:34 <fantasai> oriol: because only used when size containment, and it is monolithic in that case
23:28:48 <fantasai> oriol: so using size of first fragment seems reasonable and easiest solution
23:28:51 <astearns> ack fantasai
23:29:04 <heycam> fantasai: monolithic elements can be split across multiple cols/pages
23:29:12 <heycam> ... not convinced using the first fragment makes any sense
23:29:22 <heycam> ... probably want to use the total size of the element, not just the first piece of it that prints on the first page
23:29:38 <heycam> astearns: when a monolithic element gets spliced, does it have multiple fragments? or one fragment that's been sliced into pieces
23:29:47 <heycam> florian: pieces and fragments are the same thing?
23:29:51 <heycam> fantasai: it does have multiple pieces
23:29:57 <heycam> ... not sure if we clarified we call them fragments or not
23:30:05 <heycam> ... two effects of being monolithic. we try to avoid breaking them across breaks
23:30:15 <heycam> ... other is that we don't fragment the content inside them, just graphically slice it
23:30:21 <heycam> ... still get a bunch of pieces of the element. I'd call them fragments
23:30:34 <heycam> ... I think you want the total height of all of those pieces, and not just the height of the first piece
23:30:50 <heycam> oriol: if you have multiple fragments, in strange cases, each fragment might have different width/height?
23:31:11 <TabAtkins> Specifically, my "strong agree" is to "do whatever ResizeObserver currently does"; I have no opinions on what that behavior actually *is* and *strongly* feel we shouldn't be litigating that topic here in this issue.
23:31:12 <heycam> fantasai: for the height, you add them. for the width, you can just take the width of the first one, because for a monolithic element you wont' have different widths on different pages
23:31:22 <heycam> florian: could have different widths, if expressed as a percent?
23:31:35 <heycam> fantasai: at that point you're doing something more sophisticated than just graphically slicing
23:31:41 <heycam> ... so going with the first one is perfectly fine
23:31:58 <bradk> bradk has joined #css
23:32:13 <heycam> astearns: might agree with Tab, that we agree ResizeObserver is not fragment aware. that current state, taking the first fragment might be fine for this edge case
23:32:21 <bradk> “Finally, if there are no possible break points below the top of the fragmentainer, and not all the content fits, the UA may break anywhere in order to avoid losing content off the edge of the fragmentainer. In such cases, the UA may also *fragment* the contents of monolithic elements by slicing the element’s graphical representation. “
23:32:38 <heycam> oriol: doing something different seems tricky for an implementation
23:32:57 <heycam> fantasai: I'm good with it, but it's not ideal, didn't we agree on fixing ResizeObserver like 6 years ago?
23:33:09 <heycam> astearns: probably, but work isn't done
23:33:19 <heycam> fantasai: would've hoped the second implementation would've fixed things instead of copying the broken stuff
23:33:29 <karlcow> karlcow has joined #css
23:33:36 <heycam> florian: especially since we said that dealing with fragmentation properly was a precondition for going FPWD
23:33:52 <florian> s/since we said/since I believe we said/
23:34:07 <fantasai> astearns: 2 ways forward
23:34:20 <fantasai> astearns: 1st option is to just have the size of the first fragment be recorded, to match everything else
23:34:32 <fantasai> astearns: and maybe put issue in the spec that when ResizeObserver gets fixed, we should do better here
23:34:46 <fantasai> astearns: Or we can define how we construct a size out of the entire height and width of a sliced monolithic element
23:35:01 <fantasai> astearns: I'm lazily inclined towards the first
23:35:38 <fantasai> astearns: Oriol, you mentioned that's what Blink does atm
23:35:52 <fantasai> oriol: Yes, they take the size of the first fragment since that's the information that ResizeObserver is providing
23:36:18 <fantasai> astearns: If we decide to go with the entire height and width of monolithic element, is there going to be a mismatch between last remembered size and what is available in resizeObserver?
23:36:28 <fantasai> oriol: At the time we record the size, the element might not be monolithic
23:36:33 <fantasai> oriol: it might be monolithic when using
23:36:40 <fantasai> oriol: having a mismatch, it's not a big deal
23:36:50 <fantasai> oriol: the deal is having to compute the size in a new way
23:36:59 <fantasai> oriol: it could be that only ResizeObserver in the page is the internal one
23:37:09 <fantasai> oriol: we'd have to calculate different sizes for this and for ResizeObserver
23:37:15 <fantasai> oriol: so a bit more work, and maybe trickier
23:37:27 <fantasai> oriol: but like you said about the mismatch, it's not like the other ResizeObservers are getting the last remembered size
23:37:32 <fantasai> oriol: they can use cotent-visibility to see it
23:37:42 <fantasai> oriol: but I don't think they are affected by the added complexity in the implementation
23:38:13 <fantasai> astearns: so, can people live with doing the easy thing for now and putting a note in that we should do better later?
23:38:17 <TabAtkins>  +1
23:38:28 <heycam> fantasai: brings up the question of whether we want to do something better later?
23:38:41 <heycam> ... generally, people say we have to decide right now
23:38:48 <heycam> ... what's the point of the note if we've decided not to change anything?
23:38:56 <bradk> bradk has joined #css
23:39:07 <fantasai> astearns: Last time we put significant effort into fragmentation was when Bloomberg was interested
23:39:17 <fantasai> astearns: might require a non-browser team to care to improve
23:39:38 <heycam> fantasai: if the premise is we can't change behavior, then it doesn't matter if Bloomberg decides to fund fixing things 2 years from now
23:39:47 <heycam> ... if we're open for change int he future? that's one thing
23:40:17 <heycam> astearns: not sure that's the case for this API. can definitely see a path forward to not change current behavior, but add a fragment aware portion that gives you the same information in a fragment aware form
23:40:33 <heycam> fantasai: we agreed to do that when we discussed it, to be fixed for FPWD. but that's different for what we do for last remembered size
23:40:47 <heycam> ... the poitn of last remembered size is that it's the size of hte element. if you size the element to that size, it'll give a reasonabel result
23:41:00 <heycam> ... if you take the size of the first fragment, it won't make any sense
23:41:13 <heycam> ... if you set the first fragment size as the height, you'll get a very different result
23:41:43 <heycam> ... a ResizeObserver is trying to do something a bit different, we're changing stuff and we want to know
23:41:58 <heycam> ... but the point of ResizeObserver is to observer it, not to set the size back again to the element
23:42:05 <heycam> ... but last remembered size is about setting the size back again
23:42:25 <heycam> ... but if you chop off some percentage of it, due to fragments, it's not really preserving its remembered size
23:42:37 <bradk> +1
23:42:48 <heycam> astearns: that convinces me
23:42:51 <heycam> florian: me too
23:42:58 <TabAtkins> I'm just not happy about this diverging from ResizeObserver
23:43:05 <TabAtkins> They should do the same thing imo
23:43:22 <fantasai> They're not trying to solve the same problem
23:43:24 <heycam> oriol: I can try to take a look at the best way to implement this, see what different approaches there are
23:43:30 <Rossen-phone> Rossen-phone has joined #Css
23:44:07 <Rossen-phone> present+
23:44:24 <fantasai> TabAtkins: okay with investigating, not with resolving on something problematic
23:44:32 <fantasai> astearns: [explains]
23:44:51 <fantasai> astearns: I would like to hear what the problems of mismatching, what problem will that cause?
23:45:01 <fantasai> TabAtkins: the use case is just as valid when done manually with ResizeObserver
23:45:08 <fantasai> TabAtkins: if we can do one way, should do it the other way
23:45:17 <fantasai> florian: I think that means we fix both this and ResizeObserver
23:45:20 <fantasai> TabAtkins: I'm fine with that
23:45:32 <TabAtkins> s/with that/with that, if implementable/
23:45:42 <fantasai> astearns: I suggest we resolve that last remembered size, when fragmented, returns the entire size of the unfragmented element
23:45:52 <fantasai> astearns: and get some implementation feedback
23:46:02 <fantasai> astearns: and come back to this if the implementation feedback raises problems
23:46:10 <fantasai> dholbert: is this specifically for monolithic elements? or anything fragmented
23:46:23 <fantasai> oriol: anything, since last remembered size can be recorded if element is not monolithic
23:46:34 <fantasai> dholbert: I'm concerned that the unfragmented size is not something we generally have or would generally be useful
23:46:44 <fantasai> dholbert: if you have line height extremely tall lands on the fragmentation point
23:46:54 <fantasai> dholbert: might have two pieces that aren't summing to the original total
23:46:56 <Rossen-phone> a+
23:47:02 <Rossen-phone> a+
23:47:05 <fantasai> dholbert: ...
23:47:11 <fantasai> astearns: that's only the case for non-monolithic elements
23:47:27 <fantasai> dholbert: Yes, for monolithic sum of parts should equal sum of pieces
23:47:36 <Rossen-phone> q+
23:47:36 <fantasai> florian: similar problem figuring out the height of a thing
23:47:48 <dholbert> s/thing/thing with getComputedStyle/
23:47:52 <astearns> ack Rossen-phone
23:48:17 <fantasai> Rossen-phone: What I wanted to ask here, does this discussion apply to variable-size fragments or to fragmentainers that are of regular fragment size or ???
23:48:37 <fantasai> astearns: discussed earlier, but didn't come to conclusion on the monolithic width
23:48:48 <fantasai> Rossen-phone: I think answer varies based on that
23:49:05 <fantasai> astearns: So if ppl have concerns we leave issue open and have Oriol investigate what can be implemented in at least one implementation
23:49:13 <fantasai> astearns: and see whether what he comes up with is an acceptable path forward
23:49:20 <florian> +1
23:49:27 <fantasai> oriol: that's fine
23:49:31 <fantasai> astearns: so not resolving today
23:49:46 <fantasai> subtopic: [css-contain-1] contain:size shouldn't fragment as monolithic
23:49:54 <fantasai> https://github.com/w3c/csswg-drafts/issues/5648
23:49:57 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5648
23:50:04 <astearns> github: https://github.com/w3c/csswg-drafts/issues/5648
23:50:16 <heycam> florian: CSS Contain has several types of containment
23:50:29 <heycam> ... all these are establishing changes to how CSS normally behaves, to reason about inside/outside the element, breaking dependencies
23:50:37 <heycam> ... what's going on inside an element doesn't affect the outside
23:50:52 <heycam> ... we have size containment, the goal being when the inside changes, the size of the element doesn't
23:51:02 <heycam> ... and in particular within that, we want to deal with size changes in the case the element is fragmenting
23:51:22 <heycam> ... for that we have a double goal. 1. regardless fo how the element fragments, its total size shouldn't change. but nore than that, the size of the fragments shouldn't change either
23:51:31 <heycam> ... the spec says applying size containment causes the element to be monolithic
23:51:36 <heycam> ... fantasai opened an issue to say it doesn't need to be
23:51:48 <heycam> ... she correctly poitns out size containment causes the element to be fixed size
23:51:57 <heycam> ... so the total size of the element won't vary, regarldess of the breaking point
23:52:06 <heycam> ... but making it fixed size does not guarantee the fragment sizes won't change
23:52:14 <heycam> ... so I think we need something more than merely making the element fixed size
23:52:41 <heycam> ... I agree making the element monolithic is slightly overkill, in the sense that it will guarantee that not only the total size of the box and all fragmnets won't change, but it also means the content of the element will not be fragmented and will be sliced
23:52:45 <heycam> ... which isn't actually necessary in this case
23:52:57 <heycam> ... as long as we guarnatee fragment sizes to not change, we can still allow fragmentation
23:53:07 <heycam> ... fixed size fragments but content fragments is not a thing we have currently
23:53:26 <heycam> ... preference is to stick with the existing spec requirement that all size contained elements become monolithic, because it fulfills the requirement and is what is implemented
23:53:47 <heycam> ... in some later level possibly relax this to not be monolithic as long as you fulfil these specific constraints
23:53:59 <heycam> ... could do that without trouble, any implementation compliant today would be compliant in the future
23:54:05 <heycam> ... but this is the last open issue on css-contain-1
23:54:20 <heycam> ... not sure it's so interesting to change the spec to allow behavior nobody has at this point
23:54:32 <florian> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10671
23:54:57 <heycam> fantasai: that seems very weird to me
23:55:03 <heycam> ... don't think it's supposed to do that
23:55:06 <heycam> florian: it's interoperable
23:55:09 <bradk> bradk has joined #css
23:55:20 <heycam> fantasai: it should be drawing the box all the way to the bottom of the page, and not leaving a gap when it fragments
23:55:31 <heycam> florian: the total size does stay fixed, btu the size of the fragments doesn't
23:56:04 <heycam> fantasai: drawing the box sides all the way down to the end of the page or column, rather than ending at the fragmentation point, then the size of the fragments would not change based on the fragmentation position
23:56:19 <heycam> iank_: all of the fragmentation engines for most cases, when you fragment, you'll typically consume the remaining fragmentainer space
23:56:34 <heycam> fantasai: that's what I was epxecting to happen
23:56:39 <heycam> florian: Safari, Chrome, and Firefox all do this
23:57:10 <heycam> ... three line element fragment, just tall enough to contain the three lines, but the fragmentainer containing the element is 2.5 lines high. so the first fragment will be 2 lines, the third fragment will be 1 line. so there's a 0.5 line gap at the end of the first one
23:57:17 <heycam> ... whether that's the case or not depends on the content of the element
23:57:32 <heycam> ... maybe this is an interoperable spec violation, but I'm not convinced it's a spec violation
23:57:45 <astearns> The fragment heights stay the same in blink, but adjust in gecko
23:57:46 <heycam> fantasai: that's super weird. I wonder what's causing this to happen
23:57:51 <bradk> bradk has joined #css
23:58:07 <bradk> Wouldn’t box-decoration-break: clone cause the fragments to grow?
23:58:11 <heycam> fantasai: I could undersatnd if engines were like "oh for web compat reasons we can't conusme the extra space", but even when it's auto, it's not consuming down to the fragmentainer
23:58:40 <heycam> florian: because here we're not in a monolithic case, it doesn't want to have one full line of content [...]
23:58:51 <heycam> fantasai: the fact it's not working for auto is disturbing
23:59:04 <heycam> florian: that's the current behavior, and doesn't work for contain:size
23:59:15 <heycam> ... I propose sticking with monolithic for level 1, then maybe relaxing in a later level
23:59:41 <heycam> fantasai: rather defer the issue
23:59:48 <heycam> florian: would you object to the monolithic beahvior being allowed?
23:59:53 <heycam> fantasai: no, I think it's fine to allow that
00:00:21 <heycam> florian: all implementations behave this way, and you're agreeing it should be allowed. is it worth blocking the spec to make a change that's not testable and not invalidate any implementation?
00:00:24 <heycam> fantasai: I said I don't mind deferring
00:01:15 <heycam> RESOLVED: Not make any changes to css-contain-1, possibly relax the monolithic requirement in later levels
00:02:55 <astearns> topic: end
00:03:02 <astearns> zakim, end meeting
00:03:02 <Zakim> As of this point the attendees have been oriol, flackr, dholbert, miriam, fantasai, dlibby, dgrogan, bradk, Rossen-phone
00:03:03 <bradk> bradk has joined #css
00:03:05 <Zakim> RRSAgent, please draft minutes v2
00:03:05 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/07-css-minutes.html Zakim
00:03:08 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
00:03:12 <Zakim> Zakim has left #css
02:56:00 <claraaudbtc> claraaudbtc has joined #css
03:26:32 <clararussel> clararussel has joined #css
05:06:59 <claraaudbtc> claraaudbtc has left #css
06:34:34 <CSSWG_LogBot> CSSWG_LogBot has joined #css
07:19:26 <Linux_Kerio> Linux_Kerio has joined #css
07:23:39 <rego> rego has joined #css