- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Sep 2022 17:00:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Last remembered size when fragmented`, and agreed to the following: * `RESOLVED: Last remembered size uses the "stitch together in block axis" bounding box` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Last remembered size when fragmented<br> <TabAtkins> oriol: continuing discussion<br> <jcraig> s/@@@elika help?@@@/listed below/<br> <TabAtkins> oriol: what size to record as last remembered size when ther'e smultiple fragments?<br> <TabAtkins> oriol: in discussion, preferred behavior was taking all frags into account, but we weren't sure if that was possible<br> <TabAtkins> oriol: the ResizeObserver API supposedly only returned the frist fragment size<br> <TabAtkins> oriol: but in Blink, while a single size is exposed, it's not the first fragment size as the spec says; instead it's the sum of the block sizes of the fragments<br> <TabAtkins> oriol: So perhaps by accident, the last remembered size is behaving as we desired in blink already<br> <TabAtkins> oriol: So I implemented a way in RO to track size per fragments, not enabled yet but used by last remembered size<br> <TabAtkins> oriol: So impls have this behavior we thought was better in discussion, so I think we can resolve on this<br> <TabAtkins> oriol: Precisely, the last remembered block size will be the sum of the fragment block sizes, while last remembered inline size is the max of the fragment inline sizes<br> <TabAtkins> (As if pasting all the fragments together block-wise, then taking boudning box)<br> <iank_> that sounds good to me - its a long standing issue that we aren't taking the max.<br> <TabAtkins> Rossen_: I'm assuming that, without knowing current impl, what we used to have in Edge especially for variable-size frags was we used boudning box of all fragments as the size<br> <TabAtkins> Rossen_: What I'm hearing is matching that<br> <fantasai> TabAtkins: No, that's not right<br> <fantasai> TabAtkins: The summary that I put in is right, it's as if you too all the fragments, pasted them together, and then took the bounding box<br> <fantasai> TabAtkins: not take the bounding box as they exist on the page<br> <fantasai> Rossen_: That's what I meant to say<br> <TabAtkins> oriol: [missed, something about columsn]<br> <TabAtkins> iank_: This sounds good to me<br> <TabAtkins> iank_: Note that we need to ignore repeated things like table headers<br> <TabAtkins> fantasai: Do we?<br> <TabAtkins> Rossen_: And box-decoration?<br> <TabAtkins> iank_: Repeated table headers, for example, if you take the stitched size...<br> <TabAtkins> iank_: the table header won't vary between the fragmentainers<br> <TabAtkins> iank_: So if you have a repeated frag you just want to take the first<br> <TabAtkins> iank_: It's an edge case tho<br> <TabAtkins> Rossen_: what about border-decoration:repeat?<br> <TabAtkins> Rossen_: ARe you ignoring the borders along the slices?<br> <bradk> box-decoration: clone<br> <TabAtkins> oriol: Re: decos, we're remembering content size, so it's not including the borders<br> <TabAtkins> oriol: Re: tables, the last remembered size is only used when the element has size containment, and I think tables can't have size containment so it doesn't matter in practice<br> <TabAtkins> Rossen_: Stepping back, proposal lsounds good. Think there will be some details as we implement.<br> <TabAtkins> Rossen_: But I think the path forward sounds good<br> <TabAtkins> Rossen_: thoughts or objections?<br> <TabAtkins> RESOLVED: Last remembered size uses the "stitch together in block axis" bounding box<br> <TabAtkins> fantasai: We've had interesting convos about RO<br> <TabAtkins> fantasai: Many inconsistencies between planned and implemented<br> <TabAtkins> fantasai: Who's working on this?<br> <TabAtkins> TabAtkins: RO has new editors<br> <TabAtkins> oriol: I can try to drive something to make the spec handle different fragments, like what I impld in Firefox<br> <TabAtkins> oriol: But there are unclear details<br> <TabAtkins> fantasai: We also have a previous discussion, ,maybe from A Coruna, about this?<br> <TabAtkins> oriol: I think we have a resolution that API shoudl extend to expose fragments, it's just not clear how to do so in some cases<br> <TabAtkins> fantasai: Think we discussed an array of fragments, we just didn't do that in first version because it shipped before review<br> <TabAtkins> oriol: Yes, impl currently returns an array that has 1 item, in FF it's the first...<br> <TabAtkins> Rossen_: Wait is this part of the topic?<br> <TabAtkins> fantasai: My point is just that we're basing decisions on RO but RO is shaky, and we haven't followed up on resolutions we made for RO.<br> <TabAtkins> oriol: emilio<br> <TabAtkins> oriol: is the new editor<br> <fantasai> Having the first item in the array be the sum of all fragments makes *no sense*<br> <bradk> I gotta go. Bye.<br> <TabAtkins> oriol: I added some RO issues to the agenda, hopefully we can handle those<br> <TabAtkins> oriol: I can try to change the spec to handle fragments<br> <fantasai> Either it's not an array and it's the sum of all fragments, or its an array of multiple items each representing a fragment<br> <TabAtkins> Rossen_: Ok, please do that and raise issues if there are any new questions<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-1261201816 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 September 2022 17:00:50 UTC