W3C home > Mailing lists > Public > www-style@w3.org > March 2019

[CSSWG] Minutes San Francisco F2F 2019-02-25 Part III: Resize Observer [resize-observer]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 Mar 2019 22:28:06 +0300
Message-ID: <CADhPm3tB4tYnXbR093R5fa3R+A7kL38=rfGHoo9rASEnE_fqCQ@mail.gmail.com>
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


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

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

ResizeObserverEntry shape
  Github: https://github.com/w3c/csswg-drafts/issues/3329

  gregwhitworth: Two options for the shape
  gregwhitworth: During the fragmentation discussion we might impact
  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
  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
  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
  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

  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
  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
  iank: If there's a single fragment, is that still an array with 1
  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
  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

  [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
  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

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2019 19:28:58 UTC