- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 23:07:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `adding fragmentation support to resize observer`, and agreed to the following:
* `RESOLVED: Option 1; contentBox is an array of fragment sizes`
<details><summary>The full IRC log of that discussion</summary>
<heycam> TopiC: adding fragmentation support to resize observer<br>
<gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3673<br>
<heycam> gregwhitworth: plinss brought up that we don't support fragments<br>
<heycam> ... which is valid<br>
<heycam> ... I don't want this API to back us into a corner for future support of some new display type<br>
<heycam> florian: or printing<br>
<heycam> gregwhitworth: in the issue we have this similar entry API shape<br>
<heycam> florian: if you observe a multi col you would have two values in the entry?<br>
<heycam> gregwhitworth: if observing a box that is fragmenting ...<br>
<heycam> florian: ok<br>
<heycam> gregwhitworth: ... this is just turning the contentBox property value from a single object to a list<br>
<heycam> ... the one caveat I have with Houdini causing many fragments is that you'll get callbacks during custom layout, and you probably wouldn't use custom layout here.<br>
<heycam> florian: inline fragmentation<br>
<heycam> ... do this cover that?<br>
<heycam> alex: resize observer doesn't support watching inlines<br>
<heycam> florian: ruby doesn't fragment<br>
<heycam> dbaron: some larger pieces can<br>
<heycam> florian: the rb and rt don't<br>
<heycam> florian: anyway, the API shape here works<br>
<heycam> Rossen: the only thing you're trying to express here is paginated scenarios, such as multicol, in which you say are observing a div<br>
<heycam> ... and the div is broken between two columns<br>
<heycam> ... the representation would be a list of all of the fragments for that div<br>
<heycam> ... of the content box of that div<br>
<heycam> ... and the expected behavior is that you would get a callback when any of them change?<br>
<heycam> gregwhitworth: that's the next issue<br>
<heycam> ... technically I don't think you can observe those<br>
<heycam> ... in multicol it's ok, content rect will change, and you'll get the notification<br>
<heycam> ... I don't think you can't observe the other boxes<br>
<heycam> florian: what other boxes?<br>
<heycam> gregwhitworth: when you add a RO to an element, I don't know if you can add a resize observer to the other fragments<br>
<heycam> dbaron: one way you could see this working is that -- an element has multiple boxes, if you're split over three columns, you have three boxes, if you fire an observer right now, you would produce an array with 3 boxes in it<br>
<heycam> ... if that array were at some future point some different result, now it only has 2 things in it, or 4, or anything changes in that array, you fire another observation<br>
<heycam> ... because something has changed<br>
<heycam> florian: e.g. because it moved<br>
<heycam> stefan: the interesting case if the content box didn't change but the fragments did<br>
<heycam> ... I don't like that idea<br>
<heycam> gregwhitworth: not even sure we can observe just the fragments<br>
<heycam> dbaron: so you do'nt want to fire an event if it only moves between columns?<br>
<heycam> gregwhitworth: did the content rect change? then produce the fragments from that<br>
<heycam> dbaron: but there are 3 content rects<br>
<heycam> [Rossen draws]<br>
<heycam> gregwhitworth: so what the API represents at this point is the fragmentainer ...<br>
<heycam> florian: no fragmentainer is the container around that<br>
<heycam> alex: if I am a web dev, have a concern how they're oging to use the fragmentation feature if at all<br>
<heycam> ... most webdevs will code for a single box<br>
<heycam> ... what happens if I've created a resized observer and suddenly someone puts the target in a multi col<br>
<heycam> ... now the use of resize observer breaks<br>
<heycam> heycam: depends on the exact API shape whether it would break or not<br>
<heycam> alex: not sure what the use cases are exactly, but I can see most authors not thinking about fragmentation<br>
<heycam> Rossen: the few that care about it have it<br>
<heycam> gregwhitworth: I think it's ok to have it in here<br>
<heycam> ... I don't see this scenario happening much based on the main use case for resize observer<br>
<heycam> florian: I think for now we could kind of pretend that if we want to make it easy, we could pretend there's no fragmentation and just expose a single box<br>
<heycam> ... but that's not future proof<br>
<heycam> iank_: we have bugs in our impl with reporting geometry things in fragmented containers<br>
<heycam> gregwhitworth: so the idea was to add an array, then add a single item for now in the array (incorrectly)<br>
<heycam> florian: I think this satisfies plinss and fantasai's concerns<br>
<heycam> rego: now the offsets might be useful...<br>
<heycam> stefan: at some point if you're doing things with multicol and resize observer is not giving you granular enough information, you will use Houdini<br>
<heycam> florian: cases where you might want more detailed info is custom painting, but then you'd use Custom Painting API<br>
<heycam> dbaron: what kind of boxes or elements or whatever can you use resize observer on?<br>
<heycam> Rossen: block elements<br>
<heycam> alex: and SVG<br>
<heycam> florian: grid, multi-col<br>
<heycam> dbaron: tables?<br>
<heycam> ... some things get messier with e.g. column spans in tables<br>
<heycam> alex: watching column span sizes? or cell sizes?<br>
<heycam> dbaron: watching a div with a column span in the middle of it<br>
<heycam> florian: we need to be mindful about which boxes, and which kinds of elements you can observe<br>
<heycam> Rossen: I hope the current spec is already precise as to which elements you're allowed to observe<br>
<heycam> florian: if not it needs to be<br>
<heycam> iank_: still an open question about how to represent the fragments, a separate side structure<br>
<heycam> alex: an array<br>
<heycam> iank_: an additional array?<br>
<heycam> ... the most common thing is people will use only one box<br>
<heycam> ... weshouldn't make them access through an array<br>
<heycam> Rossen: multiple box objects or a bunch of rects?<br>
<heycam> Rossen: people might come back and say that fragments are not really rects<br>
<heycam> iank_: if there's a single fragment, is that still an array with 1 element?<br>
<heycam> gregwhitworth: yes<br>
<heycam> heycam: what about the order of the entryies in the array?<br>
<heycam> Rossen: document order<br>
<heycam> ... the biggest issue with regions is that people complain about search result order<br>
<heycam> gregwhitworth: the common use case for this is people watching border box and watch that change<br>
<heycam> Rossen: but even that can be fragmented<br>
<heycam> alex: the question what elements can we watch<br>
<heycam> ... all elements, but observations don't fire for non-replaced inline elements<br>
<heycam> ... per spec<br>
<heycam> florian: so we need to be a bit more specific about table cells, ...<br>
<heycam> alex: we can<br>
<heycam> iank_: it would be nice if not needing to use the array<br>
<heycam> ... could also make the contentBox attribute polymorphic<br>
<heycam> alex: it would break things as soon as it becomes fragmented<br>
<heycam> gregwhitworth: that's why I would like to have the summation in the entry too<br>
<heycam> florian: what about when one fragment is narrower than another?<br>
<heycam> iank_: Edge and Firefox take the union of the rects<br>
<heycam> gregwhitworth: that would let you handle the common case<br>
<heycam> ... but you would also have the fragments available in a separate property<br>
<heycam> florian: as long as this isn't an excuse to not implement the array<br>
<heycam> Rossen: if I have a tiny column for one part of a div and a large one for the rest of the div<br>
<heycam> ... would you sum up the inline sizes in these single values?<br>
<heycam> iank_: what you report for clientWidth today, which is the union of those values<br>
<heycam> [whiteboard discussion about how to deal with summing up fragment sizes when they're on different pages]<br>
<heycam> gregwhitworth: valid point about not being able to sum them up<br>
<heycam> ... but I'm going back to the main use case of non fragmented boxes you want to observe<br>
<heycam> Rossen: one way to interpret the proposal here is "we have heard your comment about fragmentation and come up with a future proofing of how this could be done"<br>
<heycam> ... "and this or a version of this will solve this problem in a way to satisfy everyone"<br>
<heycam> ... so we could resolve on having the fragments as a list we can add later<br>
<heycam> florian: doesn't help, it's hard to define the separate values for the summed inlineSize/blockSize now<br>
<heycam> Rossen: we can open a separate issue on fragmentation spec for that<br>
<heycam> florian: if we go with the earlier syntax we don't have that problem<br>
<heycam> iank_: we need this defined anyway for clientWidth/clientHeight<br>
<heycam> ... there is blink/webkit vs edge/firefox<br>
<heycam> Rossen: opening an issue on CSSOM and defining how clientWidth/clientHeight work under fragmentation is needed<br>
<heycam> ... and whatever answer that has, will be reflected to be the two numbers here for inlineSize and blockSize on the entry<br>
<heycam> ... if you don't have fragmentation, you don't have the problem<br>
<heycam> ... being able to add fragments even as a v2, with this defined shape, will resolve the issue that peter, me, etc. who care about fragmentation have<br>
<heycam> florian: in the spec right now we say "it's the same as clientWidth" and defer to CSSOM<br>
<heycam> stefan: Intersection Observer is similar, it defers to getBoundingClientRect<br>
<heycam> florian: the "add that later" ...<br>
<heycam> gregwhitworth: realistically nobody is asking me for it<br>
<heycam> Rossen: it's fine to have a v2 with it there right now<br>
<heycam> gregwhitworth: but in terms of blocking on implementations we can't do that<br>
<heycam> florian: the thing I like better with the first alternative, the fragmentation case is rare, when things become weird -- we tell them "wait til v2"<br>
<heycam> gregwhitworth: this is not a "we don't want this", but it's prioritization<br>
<heycam> [discussion about Chrome implementation of fragments]<br>
<heycam> [discussion of whether web devs will notice the inline/block size being duplicated in the single-fragment case]<br>
<heycam> iank_: I was imagining that for a single fragment that fragments is null<br>
<heycam> florian: different approach to the same question<br>
<heycam> ... an author who hasn't thought about fragments<br>
<heycam> ... the thing they haven't thought about happened to be placed in multicol<br>
<heycam> ... does it break more to get the first fragment size, or the union size?<br>
<heycam> gregwhitworth: I would say equally<br>
<heycam> iank_: if we use the max of the inline sizes and the sum of the block sizes that would be closest to being useful<br>
<heycam> florian: regardless, if they just look at one it'll be wrong<br>
<heycam> heycam: just wonder if using names other than inlineSize/blockSize for the summed values would make it look less unsensible<br>
<heycam> florian: so I'm ok with both options prefer the one without the summed inlineSize/blockSize<br>
<heycam> alex: is there any perf difference between the two?<br>
<heycam> iank_: very small. don't have to synthesize the array until you access it<br>
<heycam> straw poll:<br>
<heycam> 1. always return a contentBox which is an array of fragment sizes (usually containing one item currently)<br>
<heycam> 2. return contentBox: { inlineSize: <offsetWidth>, blockSize: <offsetHeight>, fragments: [ { inlineSize, blockSize }, ... ] }<br>
<astearns> main room is about to break<br>
<astearns> (go on a break)<br>
<florian> option 1<br>
<smfr> 1<br>
<Rossen> option 1, 2<br>
<iank_> 2<br>
<gregwhitworth> option 2<br>
<heycam> option 1<br>
<rego> option 1<br>
<rachelandrew> option 1<br>
<dbaron> prefer 2, I think, but not sure<br>
<heycam> result: option 1<br>
<heycam> RESOLVED: Option 1; contentBox is an array of fragment sizes<br>
<heycam> trackbot: end telcon<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3673#issuecomment-467221565 using your GitHub account
Received on Monday, 25 February 2019 23:07:47 UTC