- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Sep 2022 23:49:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Last remembered size when fragmented?`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-sizing] Last remembered size when fragmented?<br> <fantasai> s/Topic/Subtopic/<br> <fantasai> github:<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/7598<br> <fantasai> github: [css-sizing] Last remembered size when fragmented?<br> <fantasai> github: [css-sizing] Last remembered size when fragmented?<br> <fantasai> oriol: This is about what we do when we are in multicol or printing<br> <fantasai> oriol: elements can get fragmented<br> <fantasai> oriol: in that case, what the ResizeObserver does<br> <fantasai> oriol: is it only provides the size of the first fragment<br> <fantasai> oriol: ResizeObserver spec has plans to add sizes of more fragments<br> <fantasai> oriol: but for now implementations are only storing the first fragment<br> <fantasai> oriol: I think this is reasonable, because we cannot try to keep the same number of fragments and size for each<br> <fantasai> oriol: because only used when size containment, and it is monolithic in that case<br> <fantasai> oriol: so using size of first fragment seems reasonable and easiest solution<br> <astearns> ack fantasai<br> <heycam> fantasai: monolithic elements can be split across multiple cols/pages<br> <heycam> ... not convinced using the first fragment makes any sense<br> <heycam> ... probably want to use the total size of the element, not just the first piece of it that prints on the first page<br> <heycam> astearns: when a monolithic element gets spliced, does it have multiple fragments? or one fragment that's been sliced into pieces<br> <heycam> florian: pieces and fragments are the same thing?<br> <heycam> fantasai: it does have multiple pieces<br> <heycam> ... not sure if we clarified we call them fragments or not<br> <heycam> ... two effects of being monolithic. we try to avoid breaking them across breaks<br> <heycam> ... other is that we don't fragment the content inside them, just graphically slice it<br> <heycam> ... still get a bunch of pieces of the element. I'd call them fragments<br> <heycam> ... I think you want the total height of all of those pieces, and not just the height of the first piece<br> <heycam> oriol: if you have multiple fragments, in strange cases, each fragment might have different width/height?<br> <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.<br> <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<br> <heycam> florian: could have different widths, if expressed as a percent?<br> <heycam> fantasai: at that point you're doing something more sophisticated than just graphically slicing<br> <heycam> ... so going with the first one is perfectly fine<br> <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<br> <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. “<br> <heycam> oriol: doing something different seems tricky for an implementation<br> <heycam> fantasai: I'm good with it, but it's not ideal, didn't we agree on fixing ResizeObserver like 6 years ago?<br> <heycam> astearns: probably, but work isn't done<br> <heycam> fantasai: would've hoped the second implementation would've fixed things instead of copying the broken stuff<br> <heycam> florian: especially since we said that dealing with fragmentation properly was a precondition for going FPWD<br> <florian> s/since we said/since I believe we said/<br> <fantasai> astearns: 2 ways forward<br> <fantasai> astearns: 1st option is to just have the size of the first fragment be recorded, to match everything else<br> <fantasai> astearns: and maybe put issue in the spec that when ResizeObserver gets fixed, we should do better here<br> <fantasai> astearns: Or we can define how we construct a size out of the entire height and width of a sliced monolithic element<br> <fantasai> astearns: I'm lazily inclined towards the first<br> <fantasai> astearns: Oriol, you mentioned that's what Blink does atm<br> <fantasai> oriol: Yes, they take the size of the first fragment since that's the information that ResizeObserver is providing<br> <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?<br> <fantasai> oriol: At the time we record the size, the element might not be monolithic<br> <fantasai> oriol: it might be monolithic when using<br> <fantasai> oriol: having a mismatch, it's not a big deal<br> <fantasai> oriol: the deal is having to compute the size in a new way<br> <fantasai> oriol: it could be that only ResizeObserver in the page is the internal one<br> <fantasai> oriol: we'd have to calculate different sizes for this and for ResizeObserver<br> <fantasai> oriol: so a bit more work, and maybe trickier<br> <fantasai> oriol: but like you said about the mismatch, it's not like the other ResizeObservers are getting the last remembered size<br> <fantasai> oriol: they can use cotent-visibility to see it<br> <fantasai> oriol: but I don't think they are affected by the added complexity in the implementation<br> <fantasai> astearns: so, can people live with doing the easy thing for now and putting a note in that we should do better later?<br> <TabAtkins> +1<br> <heycam> fantasai: brings up the question of whether we want to do something better later?<br> <heycam> ... generally, people say we have to decide right now<br> <heycam> ... what's the point of the note if we've decided not to change anything?<br> <fantasai> astearns: Last time we put significant effort into fragmentation was when Bloomberg was interested<br> <fantasai> astearns: might require a non-browser team to care to improve<br> <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<br> <heycam> ... if we're open for change int he future? that's one thing<br> <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<br> <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<br> <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<br> <heycam> ... if you take the size of the first fragment, it won't make any sense<br> <heycam> ... if you set the first fragment size as the height, you'll get a very different result<br> <heycam> ... a ResizeObserver is trying to do something a bit different, we're changing stuff and we want to know<br> <heycam> ... but the point of ResizeObserver is to observer it, not to set the size back again to the element<br> <heycam> ... but last remembered size is about setting the size back again<br> <heycam> ... but if you chop off some percentage of it, due to fragments, it's not really preserving its remembered size<br> <bradk> +1<br> <heycam> astearns: that convinces me<br> <heycam> florian: me too<br> <TabAtkins> I'm just not happy about this diverging from ResizeObserver<br> <TabAtkins> They should do the same thing imo<br> <fantasai> They're not trying to solve the same problem<br> <heycam> oriol: I can try to take a look at the best way to implement this, see what different approaches there are<br> <fantasai> TabAtkins: okay with investigating, not with resolving on something problematic<br> <fantasai> astearns: [explains]<br> <fantasai> astearns: I would like to hear what the problems of mismatching, what problem will that cause?<br> <fantasai> TabAtkins: the use case is just as valid when done manually with ResizeObserver<br> <fantasai> TabAtkins: if we can do one way, should do it the other way<br> <fantasai> florian: I think that means we fix both this and ResizeObserver<br> <fantasai> TabAtkins: I'm fine with that<br> <TabAtkins> s/with that/with that, if implementable/<br> <fantasai> astearns: I suggest we resolve that last remembered size, when fragmented, returns the entire size of the unfragmented element<br> <fantasai> astearns: and get some implementation feedback<br> <fantasai> astearns: and come back to this if the implementation feedback raises problems<br> <fantasai> dholbert: is this specifically for monolithic elements? or anything fragmented<br> <fantasai> oriol: anything, since last remembered size can be recorded if element is not monolithic<br> <fantasai> dholbert: I'm concerned that the unfragmented size is not something we generally have or would generally be useful<br> <fantasai> dholbert: if you have line height extremely tall lands on the fragmentation point<br> <fantasai> dholbert: might have two pieces that aren't summing to the original total<br> <Rossen-phone> a+<br> <Rossen-phone> a+<br> <fantasai> dholbert: ...<br> <fantasai> astearns: that's only the case for non-monolithic elements<br> <fantasai> dholbert: Yes, for monolithic sum of parts should equal sum of pieces<br> <Rossen-phone> q+<br> <fantasai> florian: similar problem figuring out the height of a thing<br> <dholbert> s/thing/thing with getComputedStyle/<br> <astearns> ack Rossen-phone<br> <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 ???<br> <fantasai> astearns: discussed earlier, but didn't come to conclusion on the monolithic width<br> <fantasai> Rossen-phone: I think answer varies based on that<br> <fantasai> astearns: So if ppl have concerns we leave issue open and have Oriol investigate what can be implemented in at least one implementation<br> <fantasai> astearns: and see whether what he comes up with is an acceptable path forward<br> <florian> +1<br> <fantasai> oriol: that's fine<br> <fantasai> astearns: so not resolving today<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7598#issuecomment-1240028670 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 September 2022 23:49:50 UTC