- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 Mar 2019 22:28:06 +0300
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Resize Observer
---------------
- RESOLVED: Don't include offsets for the box being observed. (Issue
#3550: Add offset position to rects)
- RESOLVED: Option B, and remove scrollBox [from the observable
boxes] (Issue #3329: Which box information should we
pass to the callback)
- RESOLVED: Option 1; contentBox is an array of fragment sizes
[always return a contentBox which is an array of
fragment sizes (usually containing one item currently)]
(Issue #3673: Adding fragmentation support to resize
observer)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Present+ Aleks Totic
Scribe: heycam
++++++++++++
This is the breakout focused on Resize Observer.
The rest of the group's minutes are captured in Part IV
++++++++++++
Resize Observer
===============
Add offset position to rects
----------------------------
Github: https://github.com/w3c/csswg-drafts/issues/3550
gregwhitworth: Simon brought up that the position of the rects
you're observing
gregwhitworth: Say the author wants to observe the content rect, you
want both the tlbr offsets relative to the box
gregwhitworth: Alex and I discussed this. Ian brought up a valid
point, we're not observing the offsets
gregwhitworth: Being able to use the offsets inside the observer may
cause stale issues
gregwhitworth: only when dimensions change do you fire the observer
smfr: Which box?
gregwhitworth: The one you're watching
gregwhitworth: Say you're observing content box
gregwhitworth: you'd get the dimensions of that back
gregwhitworth: You asked about having the offsets in there as well
gregwhitworth: Use counters say that isn't common
gregwhitworth: Ian brought up looking at the offsets when not firing
the observer
gregwhitworth: 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
aleks: 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 polyfill-able if you have a 100% div inside
stefan: if the size changes, the offsets will have changed
dbaron: I like the idea that the pieces of data you provide are the
ones you're observing
dbaron: Don't like having data in there that you're using which you
don't get notifications for
proposed RESOLUTION: Don't include offsets for the box being
observed.
RESOLVED: Don't include offsets for the box being observed.
ResizeObserverEntry shape
-------------------------
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
gregwhitworth: During the fragmentation discussion we might impact
this
gregwhitworth: The important part is that you can now watch N
different types of boxes
gregwhitworth: Should we only pass back the dimensions of the
dimensions of the box being observed? or provide the
dimensions of other boxes as null?
gregwhitworth: So inline/block would be the dimensions of the
observed box. That's option A
gregwhitworth: Option B has separate properties for each box you
could have observed
gregwhitworth: Benefit is that you can do e.g. `if (entry.borderBox)`
gregwhitworth: 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"
gregwhitworth: Rather than having multiple properties where only one
will ever be non-null
gregwhitworth: The polls I did were like 65%-35%, 80%-20%
gregwhitworth: so majority wanted option B
iank: Only thought about the .type property is that often people
don't check types
iank: Option B does give you stronger type safety
aleks: Option B could break easily
florian: Which is what you want
Rossen: Any other options?
gregwhitworth: No.
gregwhitworth: What are the thoughts about the Houdini Box API
Rossen: I mentioned last time, we don't necessarily have Box
structures for those things
Rossen: not that we couldn't have an identifier that has this
Rossen: but I'm curious what the lifetime expectations are
Rossen: If you take a reference to one of these boxes, and hold on
to it
Rossen: and the element is removed from the DOM tree, or it's
mutated in a way that this box no longer exists
Rossen: what are the expectations here?
iank: These aren't live objects
iank: We create a new one each time
gregwhitworth: The observation life cycle takes care of this
aleks: The life cycle of resize observer ... the stuff we already
released deals with the life cycle and it's complex
aleks: 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
stefan: so even if the element is removed from the DOM, it still has
a reference to the element
iank: We gather up all the observations, 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
gregwhitworth: 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 we have it, it should be either the
scroll port box or the scroll box that include the padding
aleks: The use case for scroll box was a chat box
aleks: You always want to keep at 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
aleks: 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 from the
observable boxes
RESOLVED: Option B, and remove scrollBox
Adding fragmentation support to resize observer
-----------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/3673
gregwhitworth: plinss brought up that we don't support fragments
gregwhitworth: which is valid
gregwhitworth: 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
gregwhitworth: 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
florian: do this cover that?
aleks: Resize observer doesn't support watching inlines
florian: Ruby doesn't fragment
dbaron: Some larger pieces can
florian: The rb and rt don't
florian: Anyway, the API shape here works
[note from fantasai: actually, ruby, including rb and rt, can
fragment]
Rossen: The only thing you're trying to express here is paginated
scenarios, such as multicol, in which you say are observing
a div
Rossen: and the div is broken between two columns
Rossen: The representation would be a list of all of the fragments
for that div
Rossen: of the content box of that div
Rossen: and the expected behavior is that you would get a callback
when any of them change?
gregwhitworth: That's the next issue
gregwhitworth: Technically I don't think you can observe those
gregwhitworth: In multicol it's ok, content rect will change, and
you'll get the notification
gregwhitworth: 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
dbaron: 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
dbaron: 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
stefan: I don't like that idea
gregwhitworth: Not even sure we can observe just the fragments
dbaron: So you don't 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
aleks: If I am a web dev, have a concern how they're going to use the
fragmentation feature if at all
aleks: Most webdevs will code for a single box
aleks: What happens if I've created a resized observer and suddenly
someone puts the target in a multi col
aleks: now the use of resize observer breaks
heycam: Depends on the exact API shape whether it would break or not
aleks: 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
gregwhitworth: 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
florian: 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
aleks: And SVG
florian: Grid, multi-col
dbaron: Tables?
dbaron: Some things get messier with e.g. column spans in tables
aleks: 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
aleks: An array
iank: An additional array?
iank: The most common thing is people will use only one box
iank: We shouldn't make them access through an array
Rossen: Multiple box objects or a bunch of rects?
Rossen: 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 entries in the array?
Rossen: Document order
Rossen: 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
aleks: The question what elements can we watch
aleks: All elements, but observations don't fire for non-replaced
inline elements
aleks: per spec
florian: So we need to be a bit more specific about table cells, ...
aleks: We can
iank: It would be nice if not needing to use the array
iank: Could also make the contentBox attribute polymorphic
aleks: 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
gregwhitworth: 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
Rossen: 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
gregwhitworth: 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"
Rossen: "and this or a version of this will solve this problem in a
way to satisfy everyone"
Rossen: 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
iank: there is blink/webkit vs edge/firefox
Rossen: Opening an issue on CSSOM and defining how clientWidth/
clientHeight work under fragmentation is needed
Rossen: and whatever answer that has, will be reflected to be the
two numbers here for inlineSize and blockSize on the entry
Rossen: If you don't have fragmentation, you don't have the problem
Rossen: 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:
florian: An author who hasn't thought about fragments
florian: The thing they haven't thought about happened to be placed
in multicol
florian: 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
aleks: Is there any performance 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 }, ... ] }
<florian> option 1
<smfr> 1
<Rossen> option 1, 2
<iank> 2
<gregwhitworth> option 2
<heycam> option 1
<rego> option 1
<rachelandrew> option 1
<dbaron> prefer 2, I think, but not sure
result: option 1
RESOLVED: Option 1; contentBox is an array of fragment sizes
Received on Tuesday, 26 March 2019 19:28:58 UTC