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