21:35:00 <RRSAgent> RRSAgent has joined #fx
21:35:00 <RRSAgent> logging to https://www.w3.org/2019/02/25-fx-irc
21:35:02 <trackbot> RRSAgent, make logs world
21:35:02 <Zakim> Zakim has joined #fx
21:35:04 <trackbot> Meeting: CSS-SVG Task Force Teleconference
21:35:04 <trackbot> Date: 25 February 2019
21:35:05 <smfr> smfr has joined #fx
21:36:14 <rego> rego has joined #fx
21:37:03 <heycam> Topic: Add offset pos
21:37:08 <gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3550
21:37:24 <heycam> gregwhitworth: Simon brought up that the position of the rects you're observing
21:37:37 <heycam> ... say the author wants to observe the content rect, you want both the tlbr offsets relative to the box
21:37:46 <heycam> ... Alex and I discussed this.  Ian brought up a valid pint, we're not observing the offsets
21:37:56 <heycam> .. beingable to use the offsets inside the observer may cause stale issues
21:38:02 <heycam> ... only when dimensions change do you fire the observer
21:38:06 <heycam> smfr: which box?
21:38:10 <heycam> gregwhitworth: the one you're watching
21:38:15 <heycam> ... say you're observing context box
21:38:20 <heycam> ... you' dget the dimensions of that back
21:38:27 <heycam> ... you asked about having the offsets in there sa well
21:38:32 <heycam> ... use counters say that isn't common
21:38:42 <heycam> ... Ian brought up looking at the offsets when not firing the observer
21:38:48 <heycam> ... you'd want to add that you're also observing offsets
21:39:02 <heycam> smfr: so author could change border and padding so the content box doesn't change
21:39:19 <heycam> alex: you'd have to put two boxes together if you really wanted to know the offsets
21:39:31 <heycam> smfr: I suggested it for completeness.  if it adds complexity I don't feel strongly
21:39:40 <heycam> iank_: if we need it eventually, it should be trivial to extend to support this
21:39:47 <heycam> gregwhitworth: but also need to add observing offsets
21:39:52 <heycam> iank_: but we haven't painted ourselves into a corner
21:40:19 <heycam> stefan: the behavior is polyfillable if oyu have a 100% div inside
21:40:29 <heycam> ... if the size changes, the offsets will have chnaged
21:40:39 <heycam> dbaron: I like the idea that hte pieces of data you provide are the ones you're observing
21:40:47 <heycam> ... don't like having data in there that you're using which you don't get notifications for
21:41:19 <heycam> RESOLVED: Don't include offsets for the box being observed.
21:41:42 <heycam> Topic: ResizeObserverEntry shape
21:41:47 <gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3329
21:42:01 <gregwhitworth> https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-466737070
21:42:03 <heycam> gregwhitworth: two options for the shape
21:42:08 <heycam> ... during the fragmentation discussion we might impact this
21:42:24 <heycam> ... the important part is that you can now watch N different types of boxes
21:42:44 <heycam> ... should we only pass back the dimensions of the dimensions of the box being observed?  or provide the dimensions of other boxes as null?
21:44:50 <heycam> ... so inline/block would be the dimensions of the observed box.  that's option A
21:45:03 <heycam> ... option B has separate properties for each box you could have observed
21:45:21 <heycam> ... benefit is that you can do e.g. `if (entry.borderBox)`
21:45:30 <heycam> ... overall most web devs I asked prefer B
21:46:13 <Rossen> heycam, is it possible to observe multiple boxes with the same observer?
21:46:37 <Rossen> gregwhitworth, no
21:47:15 <heycam> heycam: could also have a type property with values like "border"
21:47:24 <heycam> ... rather than having multiple properties where only one will ever be non-null
21:47:53 <heycam> gregwhitworth: the polls I did were like 65%-35%, 80%-20%
21:47:58 <heycam> ... so majority wanted option B
21:48:14 <heycam> iank_: only thought about the .type property is that often people don't check types
21:48:21 <heycam> ... option B does give you stronger type safety
21:48:33 <heycam> alex: option B could break easily
21:48:41 <heycam> florian: which is what you want
21:49:11 <heycam> Rossen: any other options?
21:49:36 <heycam> gregwhitworth: no
21:50:06 <heycam> ... what are the thoughts about the Houdini Box API
21:50:15 <heycam> Rossen: I mentioned last time, wedon't necessarily have Box structures for those things
21:50:26 <heycam> ... not that we couldn't have an identifier that has this
21:50:31 <heycam> ... but I'm curious what the lifetime expectaitons are
21:50:40 <heycam> ... if you take a reference to one of these boxes, and hold on to it
21:50:49 <heycam> ... and the element is removed from the DOM tree, or it's mutated in a way that this box no longer exists
21:51:03 <heycam> ... what are the expectations here?
21:51:11 <heycam> iank_: these aren't live objects
21:51:17 <heycam> ... we create a new one each time
21:51:25 <heycam> gregwhitworth: the observation life cycle takes care of this
21:51:54 <heycam> alex: the life cycle of resize observer ... the stuff we already released deals with the life cycle and it's complex
21:52:02 <heycam> ... the question is, what keeps the resize observer alive
21:52:15 <heycam> Rossen: my question is, in one case we're just returning pure data
21:52:28 <heycam> stefan: the entry has a reference to the element
21:52:41 <heycam> ... so even if the element is removed from the DOM, it still has a reference to the element
21:52:57 <heycam> iank_: we gather up all the obserations, and we snapshot at that time
21:53:08 <heycam> stefan: even if you have an element removed from the DOM, you still have a reference to the object
21:53:48 <heycam> smfr: CSS pixel units?
21:53:54 <heycam> gregwhitworth: we have an issue tomorrow to discuss device units
21:55:01 <heycam> [some discussion about the downsides of option B shape]
21:55:12 <heycam> gregwhitworth: the reason this API exists is to watch dimensions to do container query like things
21:55:16 <heycam> ... did width change?  fire it
21:55:28 <heycam> smfr: what about observing scroll box on something not scrollable?
21:55:51 <heycam> gregwhitworth: not sure if scroll box is heavily defined
21:55:54 <heycam> Rossen: not *heavily*
21:56:04 <heycam> florian: which scroll box are we talking about?
21:56:37 <heycam> 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
21:56:55 <heycam> florian: "scroll viewport" is defined, "scroll box" is not
21:57:19 <heycam> Rossen: are we talking about the scrollable box, the extent of all your contents, which you could scroll if you were scrollable?
21:57:52 <heycam> [some whiteboard drawing]
21:59:19 <heycam> Rossen: if this was just added there without a use case, we could just remove it
21:59:22 <heycam> gregwhitworth: I'm leaning towards that
22:01:30 <heycam> Rossen: so would dropping scroll box make people happy?
22:01:55 <heycam> stefan: only opinion is if if have it, it should be either the scroll port box or the scroll box that include the padding
22:02:06 <heycam> alex: the use case for scroll box was a chat box
22:02:22 <heycam> ... you always want to keep the the bottom, and if you are loading images you might want to scroll down
22:02:25 <heycam> smfr: scroll to MAXINT
22:02:33 <heycam> florian: scroll snapping will do that for you
22:02:40 <heycam> alex: how do you know if you've scrolled?
22:02:55 <heycam> stefan: just do it any time you get new content
22:03:02 <heycam> florian: scroll snap will do that for you declaratively
22:03:19 <gregwhitworth> Proposed resolution: remove scrollBox
22:03:51 <gregwhitworth> Proposed resolution: remove scrollBox from the observable boxes
22:04:44 <heycam> RESOLVED: Option B, and remove scrollBox
22:05:01 <heycam> TopiC: adding fragmentation support to resize observer
22:05:22 <gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3673
22:05:39 <heycam> gregwhitworth: plinss brought up that we don't support fragments
22:05:41 <heycam> ... which is valid
22:05:52 <heycam> ... I don't want this API to back us into a corner for future support of some new display type
22:06:02 <heycam> florian: or printing
22:06:27 <heycam> gregwhitworth: in the issue we have this similar entry API shape
22:06:48 <heycam> florian: if you observe a multi col you would have two values in the entry?
22:06:57 <heycam> gregwhitworth: if observing a box that is fragmenting ...
22:07:00 <heycam> florian: ok
22:07:23 <heycam> gregwhitworth: ... this is just turning the contentBox property value from a single object to a list
22:08:00 <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.
22:08:00 <heycam> florian: inline fragmentation
22:08:06 <heycam> ... do this cover that?
22:08:15 <heycam> alex: resize observer doesn't support watching inlines
22:08:21 <heycam> florian: ruby doesn't fragment
22:08:25 <heycam> dbaron: some larger pieces can
22:08:29 <heycam> florian: the rb and rt don't
22:08:49 <heycam> florian: anyway, the API shape here works
22:09:22 <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
22:09:26 <heycam> ... and the div is broken between two columns
22:09:34 <heycam> ... the representation would be a list of all of the fragments for that div
22:09:40 <heycam> ... of the content box of that div
22:09:55 <heycam> ... and the expected behavior is that you would get a callback when any of them change?
22:10:01 <heycam> gregwhitworth: that's the next issue
22:10:06 <heycam> ... technically I don't think you can observe those
22:10:16 <heycam> ... in multicol it's ok, content rect will change, and you'll get the notification
22:10:21 <heycam> ... I don't think you can't observe the other boxes
22:10:27 <heycam> florian: what other boxes?
22:10:45 <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
22:11:07 <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
22:11:24 <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
22:11:28 <heycam> ... because something has changed
22:11:32 <heycam> florian: e.g. because it moved
22:12:07 <heycam> stefan: the interesting case if the content box didn't change but the fragments did
22:12:30 <heycam> ... I don't like that idea
22:12:37 <heycam> gregwhitworth: not even sure we can observe just the fragments
22:12:48 <heycam> dbaron: so you do'nt want to fire an event if it only moves between columns?
22:13:00 <heycam> gregwhitworth: did the content rect change?  then produce the fragments from that
22:13:04 <heycam> dbaron: but there are 3 content rects
22:13:13 <heycam> [Rossen draws]
22:14:19 <heycam> gregwhitworth: so what the API represents at this point is the fragmentainer ...
22:14:28 <heycam> florian: no fragmentainer is the container around that
22:23:13 <heycam> alex: if I am a web dev, have a concern how they're oging to use the fragmentation feature if at all
22:23:16 <heycam> ... most webdevs will code for a single box
22:23:38 <heycam> ... what happens if I've created a resized observer and suddenly someone puts the target in a multi col
22:23:43 <heycam> ... now the use of resize observer breaks
22:24:11 <heycam> heycam: depends on the exact API shape whether it would break or not
22:24:29 <heycam> alex: not sure what the use cases are exactly, but I can see most authors not thinking about fragmentation
22:24:36 <heycam> Rossen: the few that care about it have it
22:24:47 <heycam> gregwhitworth: I think it's ok to have it in here
22:25:00 <heycam> ... I don't see this scenario happening much based on the main use case for resize observer
22:25:18 <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
22:25:24 <heycam> ... but that's not future proof
22:25:52 <heycam> iank_: we have bugs in our impl with reporting geometry things in fragmented containers
22:26:19 <heycam> gregwhitworth: so the idea was to add an array, then add a single item for now in the array (incorrectly)
22:27:15 <heycam> florian: I think this satisfies plinss and fantasai's concerns
22:27:26 <heycam> rego: now the offsets might be useful...
22:27:50 <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
22:28:02 <heycam> florian: cases where you might want more detailed info is custom painting, but then you'd use Custom Painting API
22:28:20 <heycam> dbaron: what kind of boxes or elements or whatever can you use resize observer on?
22:28:24 <heycam> Rossen: block elements
22:28:28 <heycam> alex: and SVG
22:28:39 <heycam> florian: grid, multi-col
22:28:48 <heycam> dbaron: tables?
22:29:08 <heycam> ... some things get messier with e.g. column spans in tables
22:29:16 <heycam> alex: watching column span sizes?  or cell sizes?
22:29:26 <heycam> dbaron: watching a div with a column span in the middle of it
22:31:26 <heycam> florian: we need to be mindful about which boxes, and which kinds of elements you can observe
22:31:37 <heycam> Rossen: I hope the current spec is already precise as to which elements you're allowed to observe
22:31:42 <heycam> florian: if not it needs to be
22:32:16 <heycam> iank_: still an open question about how to represent the fragments, a separate side structure
22:32:18 <heycam> alex: an array
22:32:24 <heycam> iank_: an additional array?
22:32:40 <heycam> ... the most common thing is people will use only one box
22:32:47 <heycam> ... weshouldn't make them access through an array
22:32:54 <heycam> Rossen: multiple box objects or a bunch of rects?
22:33:08 <heycam> Rossen: people might come back and say that fragments are not really rects
22:34:15 <heycam> iank_: if there's a single fragment, is that still an array with 1 element?
22:34:18 <heycam> gregwhitworth: yes
22:36:15 <heycam> heycam: what about the order of the entryies in the array?
22:36:17 <heycam> Rossen: document order
22:37:14 <heycam> ... the biggest issue with regions is that people complain about search result order
22:37:24 <heycam> gregwhitworth: the common use case for this is people watching border box and watch that change
22:37:28 <heycam> Rossen: but even that can be fragmented
22:37:44 <heycam> alex: the question what elements can we watch
22:37:54 <heycam> ... all elements, but observations don't fire for non-replaced inline elements
22:37:56 <heycam> ... per spec
22:38:05 <heycam> florian: so we need to be a bit more specific about table cells, ...
22:38:09 <heycam> alex: we can
22:38:39 <heycam> iank_: it would be nice if not needing to use the array
22:38:52 <heycam> ... could also make the contentBox attribute polymorphic
22:39:03 <heycam> alex: it would break things as soon as it becomes fragmented
22:39:29 <heycam> gregwhitworth: that's why I would like to have the summation in the entry too
22:39:37 <heycam> florian: what about when one fragment is narrower than another?
22:39:46 <heycam> iank_: Edge and Firefox take the union of the rects
22:39:55 <heycam> gregwhitworth: that would let you handle the common case
22:40:04 <heycam> ... but you would also have the fragments available in a separate property
22:40:36 <heycam> florian: as long as this isn't an excuse to not implement the array
22:41:19 <heycam> Rossen: if I have a tiny column for one part of a div and a large one for the rest of the div
22:41:28 <heycam> ... would you sum up the inline sizes in these single values?
22:41:42 <heycam> iank_: what you report for clientWidth today, which is the union of those values
22:44:33 <heycam> [whiteboard discussion about how to deal with summing up fragment sizes when they're on different pages]
22:45:02 <heycam> gregwhitworth: valid point about not being able to sum them up
22:45:11 <heycam> ... but I'm going back to the main use case of non fragmented boxes you want to observe
22:45:38 <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"
22:45:47 <heycam> ... "and this or a version of this will solve this problem in a way to satisfy everyone"
22:46:03 <heycam> ... so we could resolve on having the fragments as a list we can add later
22:46:18 <heycam> florian: doesn't help, it's hard to define the separate values for the summed inlineSize/blockSize now
22:46:28 <heycam> Rossen: we can open a separate issue on fragmentation spec for that
22:46:34 <heycam> florian: if we go with the earlier syntax we don't have that problem
22:47:28 <heycam> iank_: we need this defined anyway for clientWidth/clientHeight
22:47:37 <heycam> ... there is blink/webkit vs edge/firefox
22:48:25 <heycam> Rossen: opening an issue on CSSOM and defining how clientWidth/clientHeight work under fragmentation is needed
22:48:39 <heycam> ... and whatever answer that has, will be reflected to be the two numbers here for inlineSize and blockSize on the entry
22:48:47 <heycam> ... if you don't have fragmentation, you don't have the problem
22:49:07 <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
22:49:26 <heycam> florian: in the spec right now we say "it's the same as clientWidth" and defer to CSSOM
22:49:38 <heycam> stefan: Intersection Observer is similar, it defers to getBoundingClientRect
22:50:05 <heycam> florian: the "add that later" ...
22:50:16 <heycam> gregwhitworth: realistically nobody is asking me for it
22:50:23 <heycam> Rossen: it's fine to have a v2 with it there right now
22:50:42 <heycam> gregwhitworth: but in terms of blocking on implementations we can't do that
22:51:21 <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"
22:51:43 <heycam> gregwhitworth: this is not a "we don't want this", but it's prioritization
22:53:05 <heycam> [discussion about Chrome implementation of fragments]
22:54:30 <heycam> [discussion of whether web devs will notice the inline/block size being duplicated in the single-fragment case]
22:55:38 <heycam> iank_: I was imagining that for a single fragment that fragments is null
22:55:55 <heycam> florian: different approach to the same question
22:56:00 <heycam> ... an author who hasn't thought about fragments
22:56:06 <heycam> ... the thing they haven't thought about happened to be placed in multicol
22:56:45 <heycam> ... does it break more to get the first fragment size, or the union size?
22:56:48 <heycam> gregwhitworth: I would say equally
22:57:30 <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
22:58:10 <heycam> florian: regardless, if they just look at one it'll be wrong
23:00:27 <heycam> heycam: just wonder if using names other than inlineSize/blockSize for the summed values would make it look less unsensible
23:01:21 <heycam> florian: so I'm ok with both options prefer the one without the summed inlineSize/blockSize
23:02:40 <heycam> alex: is there any perf difference between the two?
23:02:57 <heycam> iank_: very small.  don't have to synthesize the array until you access it
23:03:49 <heycam> straw poll:
23:04:15 <heycam> 1. always return a contentBox which is an array of fragment sizes (usually containing one item currently)
23:04:57 <heycam> 2. return contentBox: { inlineSize: <offsetWidth>, blockSize: <offsetHeight>, fragments: [ { inlineSize, blockSize }, ... ] }
23:05:08 <astearns> main room is about to break
23:05:18 <astearns> (go on a break)
23:05:51 <florian> option 1
23:05:53 <smfr> 1
23:05:59 <Rossen> option 1, 2
23:06:07 <iank_> 2
23:06:07 <gregwhitworth> option 2
23:06:08 <heycam> option 1
23:06:18 <rego> option 1
23:06:23 <rachelandrew> option 1
23:06:34 <dbaron> prefer 2, I think, but not sure
23:07:09 <heycam> result: option 1
23:07:25 <heycam> RESOLVED: Option 1; contentBox is an array of fragment sizes
23:07:44 <heycam> trackbot: end telcon
23:07:44 <trackbot> Zakim, list attendees
23:07:44 <Zakim> As of this point the attendees have been (no one)
23:07:52 <trackbot> RRSAgent, please draft minutes
23:07:52 <RRSAgent> I have made the request to generate https://www.w3.org/2019/02/25-fx-minutes.html trackbot
23:07:53 <trackbot> RRSAgent, bye
23:07:53 <RRSAgent> I see no action items