CSS-SVG Task Force Teleconference -- 25 Feb 2019

Add offset pos

<gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3550

gregwhitworth: Simon brought up that the position of the rects you're observing
... say the author wants to observe the content rect, you want both the tlbr offsets relative to the box
... Alex and I discussed this. Ian brought up a valid pint, we're not observing the offsets
... beingable to use the offsets inside the observer may cause stale issues
... only when dimensions change do you fire the observer

smfr: which box?

gregwhitworth: the one you're watching
... say you're observing context box
... you' dget the dimensions of that back
... you asked about having the offsets in there sa well
... use counters say that isn't common
... Ian brought up looking at the offsets when not firing the observer
... you'd want to add that you're also observing offsets

smfr: so author could change border and padding so the content box doesn't change

alex: you'd have to put two boxes together if you really wanted to know the offsets

smfr: I suggested it for completeness. if it adds complexity I don't feel strongly

iank_: if we need it eventually, it should be trivial to extend to support this

gregwhitworth: but also need to add observing offsets

iank_: but we haven't painted ourselves into a corner

stefan: the behavior is polyfillable if oyu have a 100% div inside
... if the size changes, the offsets will have chnaged

dbaron: I like the idea that hte pieces of data you provide are the ones you're observing
... don't like having data in there that you're using which you don't get notifications for

RESOLUTION: Don't include offsets for the box being observed.

ResizeObserverEntry shape

<gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3329

<gregwhitworth> https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-466737070

gregwhitworth: two options for the shape
... during the fragmentation discussion we might impact this
... the important part is that you can now watch N different types of boxes
... should we only pass back the dimensions of the dimensions of the box being observed? or provide the dimensions of other boxes as null?
... so inline/block would be the dimensions of the observed box. that's option A
... option B has separate properties for each box you could have observed
... benefit is that you can do e.g. `if (entry.borderBox)`
... overall most web devs I asked prefer B

<Rossen> heycam, is it possible to observe multiple boxes with the same observer?

<Rossen> gregwhitworth, no

heycam: could also have a type property with values like "border"
... rather than having multiple properties where only one will ever be non-null

gregwhitworth: the polls I did were like 65%-35%, 80%-20%
... so majority wanted option B

iank_: only thought about the .type property is that often people don't check types
... option B does give you stronger type safety

alex: option B could break easily

florian: which is what you want

Rossen: any other options?

gregwhitworth: no
... what are the thoughts about the Houdini Box API

Rossen: I mentioned last time, wedon't necessarily have Box structures for those things
... not that we couldn't have an identifier that has this
... but I'm curious what the lifetime expectaitons are
... if you take a reference to one of these boxes, and hold on to it
... and the element is removed from the DOM tree, or it's mutated in a way that this box no longer exists
... what are the expectations here?

iank_: these aren't live objects
... we create a new one each time

gregwhitworth: the observation life cycle takes care of this

alex: the life cycle of resize observer ... the stuff we already released deals with the life cycle and it's complex
... the question is, what keeps the resize observer alive

Rossen: my question is, in one case we're just returning pure data

stefan: the entry has a reference to the element
... so even if the element is removed from the DOM, it still has a reference to the element

iank_: we gather up all the obserations, and we snapshot at that time

stefan: even if you have an element removed from the DOM, you still have a reference to the object

smfr: CSS pixel units?

gregwhitworth: we have an issue tomorrow to discuss device units

[some discussion about the downsides of option B shape]

gregwhitworth: the reason this API exists is to watch dimensions to do container query like things
... did width change? fire it

smfr: what about observing scroll box on something not scrollable?

gregwhitworth: not sure if scroll box is heavily defined

Rossen: not *heavily*

florian: which scroll box are we talking about?

Rossen: say you want to observe the scroll box only of an element, and it's not scrollable -- let's say it changes overflow value

florian: "scroll viewport" is defined, "scroll box" is not

Rossen: are we talking about the scrollable box, the extent of all your contents, which you could scroll if you were scrollable?

[some whiteboard drawing]

Rossen: if this was just added there without a use case, we could just remove it

gregwhitworth: I'm leaning towards that

Rossen: so would dropping scroll box make people happy?

stefan: only opinion is if if have it, it should be either the scroll port box or the scroll box that include the padding

alex: the use case for scroll box was a chat box
... you always want to keep the the bottom, and if you are loading images you might want to scroll down

smfr: scroll to MAXINT

florian: scroll snapping will do that for you

alex: how do you know if you've scrolled?

stefan: just do it any time you get new content

florian: scroll snap will do that for you declaratively

<gregwhitworth> Proposed resolution: remove scrollBox

<gregwhitworth> Proposed resolution: remove scrollBox from the observable boxes

RESOLUTION: Option B, and remove scrollBox

adding fragmentation support to resize observer

<gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3673

gregwhitworth: plinss brought up that we don't support fragments
... which is valid
... I don't want this API to back us into a corner for future support of some new display type

florian: or printing

gregwhitworth: in the issue we have this similar entry API shape

florian: if you observe a multi col you would have two values in the entry?

gregwhitworth: if observing a box that is fragmenting ...

florian: ok

gregwhitworth: ... this is just turning the contentBox property value from a single object to a list
... 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.

florian: inline fragmentation
... do this cover that?

alex: resize observer doesn't support watching inlines

florian: ruby doesn't fragment

dbaron: some larger pieces can

florian: the rb and rt don't
... anyway, the API shape here works

Rossen: the only thing you're trying to express here is paginated scenarios, such as multicol, in which you say are observing a div
... and the div is broken between two columns
... the representation would be a list of all of the fragments for that div
... of the content box of that div
... and the expected behavior is that you would get a callback when any of them change?

gregwhitworth: that's the next issue
... technically I don't think you can observe those
... in multicol it's ok, content rect will change, and you'll get the notification
... I don't think you can't observe the other boxes

florian: what other boxes?

gregwhitworth: when you add a RO to an element, I don't know if you can add a resize observer to the other fragments

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
... 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
... because something has changed

florian: e.g. because it moved

stefan: the interesting case if the content box didn't change but the fragments did
... I don't like that idea

gregwhitworth: not even sure we can observe just the fragments

dbaron: so you do'nt want to fire an event if it only moves between columns?

gregwhitworth: did the content rect change? then produce the fragments from that

dbaron: but there are 3 content rects

[Rossen draws]

gregwhitworth: so what the API represents at this point is the fragmentainer ...

florian: no fragmentainer is the container around that

alex: if I am a web dev, have a concern how they're oging to use the fragmentation feature if at all
... most webdevs will code for a single box
... what happens if I've created a resized observer and suddenly someone puts the target in a multi col
... now the use of resize observer breaks

heycam: depends on the exact API shape whether it would break or not

alex: not sure what the use cases are exactly, but I can see most authors not thinking about fragmentation

Rossen: the few that care about it have it

gregwhitworth: I think it's ok to have it in here
... I don't see this scenario happening much based on the main use case for resize observer

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
... but that's not future proof

iank_: we have bugs in our impl with reporting geometry things in fragmented containers

gregwhitworth: so the idea was to add an array, then add a single item for now in the array (incorrectly)

florian: I think this satisfies plinss and fantasai's concerns

rego: now the offsets might be useful...

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

florian: cases where you might want more detailed info is custom painting, but then you'd use Custom Painting API

dbaron: what kind of boxes or elements or whatever can you use resize observer on?

Rossen: block elements

alex: and SVG

florian: grid, multi-col

dbaron: tables?
... some things get messier with e.g. column spans in tables

alex: watching column span sizes? or cell sizes?

dbaron: watching a div with a column span in the middle of it

florian: we need to be mindful about which boxes, and which kinds of elements you can observe

Rossen: I hope the current spec is already precise as to which elements you're allowed to observe

florian: if not it needs to be

iank_: still an open question about how to represent the fragments, a separate side structure

alex: an array

iank_: an additional array?
... the most common thing is people will use only one box
... weshouldn't make them access through an array

Rossen: multiple box objects or a bunch of rects?
... people might come back and say that fragments are not really rects

iank_: if there's a single fragment, is that still an array with 1 element?

gregwhitworth: yes

heycam: what about the order of the entryies in the array?

Rossen: document order
... the biggest issue with regions is that people complain about search result order

gregwhitworth: the common use case for this is people watching border box and watch that change

Rossen: but even that can be fragmented

alex: the question what elements can we watch
... all elements, but observations don't fire for non-replaced inline elements
... per spec

florian: so we need to be a bit more specific about table cells, ...

alex: we can

iank_: it would be nice if not needing to use the array
... could also make the contentBox attribute polymorphic

alex: it would break things as soon as it becomes fragmented

gregwhitworth: that's why I would like to have the summation in the entry too

florian: what about when one fragment is narrower than another?

iank_: Edge and Firefox take the union of the rects

gregwhitworth: that would let you handle the common case
... but you would also have the fragments available in a separate property

florian: as long as this isn't an excuse to not implement the array

Rossen: if I have a tiny column for one part of a div and a large one for the rest of the div
... would you sum up the inline sizes in these single values?

iank_: what you report for clientWidth today, which is the union of those values

[whiteboard discussion about how to deal with summing up fragment sizes when they're on different pages]

gregwhitworth: valid point about not being able to sum them up
... but I'm going back to the main use case of non fragmented boxes you want to observe

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"
... "and this or a version of this will solve this problem in a way to satisfy everyone"
... so we could resolve on having the fragments as a list we can add later

florian: doesn't help, it's hard to define the separate values for the summed inlineSize/blockSize now

Rossen: we can open a separate issue on fragmentation spec for that

florian: if we go with the earlier syntax we don't have that problem

iank_: we need this defined anyway for clientWidth/clientHeight
... there is blink/webkit vs edge/firefox

Rossen: opening an issue on CSSOM and defining how clientWidth/clientHeight work under fragmentation is needed
... and whatever answer that has, will be reflected to be the two numbers here for inlineSize and blockSize on the entry
... if you don't have fragmentation, you don't have the problem
... 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

florian: in the spec right now we say "it's the same as clientWidth" and defer to CSSOM

stefan: Intersection Observer is similar, it defers to getBoundingClientRect

florian: the "add that later" ...

gregwhitworth: realistically nobody is asking me for it

Rossen: it's fine to have a v2 with it there right now

gregwhitworth: but in terms of blocking on implementations we can't do that

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"

gregwhitworth: this is not a "we don't want this", but it's prioritization

[discussion about Chrome implementation of fragments]

[discussion of whether web devs will notice the inline/block size being duplicated in the single-fragment case]

iank_: I was imagining that for a single fragment that fragments is null

florian: different approach to the same question
... an author who hasn't thought about fragments
... the thing they haven't thought about happened to be placed in multicol
... does it break more to get the first fragment size, or the union size?

gregwhitworth: I would say equally

iank_: if we use the max of the inline sizes and the sum of the block sizes that would be closest to being useful

florian: regardless, if they just look at one it'll be wrong

heycam: just wonder if using names other than inlineSize/blockSize for the summed values would make it look less unsensible

florian: so I'm ok with both options prefer the one without the summed inlineSize/blockSize

alex: is there any perf difference between the two?

iank_: very small. don't have to synthesize the array until you access it

straw poll:

1. always return a contentBox which is an array of fragment sizes (usually containing one item currently)

2. return contentBox: { inlineSize: <offsetWidth>, blockSize: <offsetHeight>, fragments: [ { inlineSize, blockSize }, ... ] }

<astearns> main room is about to break

<astearns> (go on a break)

<florian> option 1

<smfr> 1

<Rossen> option 1, 2

<iank_> 2

<gregwhitworth> option 2

option 1

<rego> option 1

<rachelandrew> option 1

<dbaron> prefer 2, I think, but not sure

result: option 1

RESOLUTION: Option 1; contentBox is an array of fragment sizes

trackbot: end telcon

- DRAFT -

CSS-SVG Task Force Teleconference

25 Feb 2019

Attendees

Contents

Add offset pos

ResizeObserverEntry shape

adding fragmentation support to resize observer

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output