#fx

21:35

heycam

trackbot: start telcon
21:35

» trackbot is preparing a teleconference.
21:35

RRSAgent

logging to w3.org/2019/02/25-fx-irc
21:35

trackbot

RRSAgent, make logs world
21:35

RRSAgent

I have made the request, trackbot
21:35

trackbot

Meeting: CSS-SVG Task Force Teleconference
21:35

trackbot

Date: 25 February 2019
21:37

heycam

Topic: Add offset pos
21:37

gregwhitworth

Github: w3c/csswg-drafts #3550
21:37

» github-bot OK, I'll post this discussion to w3c/csswg-drafts #3550 ([resize-observer] Add offset position to rects).
21:37

heycam

gregwhitworth: Simon brought up that the position of the rects you're observing
21:37

heycam

... say the author wants to observe the content rect, you want both the tlbr offsets relative to the box
21:37

heycam

... Alex and I discussed this. Ian brought up a valid pint, we're not observing the offsets
21:37

heycam

.. beingable to use the offsets inside the observer may cause stale issues
21:38

heycam

... only when dimensions change do you fire the observer
21:38

heycam

smfr: which box?
21:38

heycam

gregwhitworth: the one you're watching
21:38

heycam

... say you're observing context box
21:38

heycam

... you' dget the dimensions of that back
21:38

heycam

... you asked about having the offsets in there sa well
21:38

heycam

... use counters say that isn't common
21:38

heycam

... Ian brought up looking at the offsets when not firing the observer
21:38

heycam

... you'd want to add that you're also observing offsets
21:39

heycam

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

heycam

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

heycam

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

heycam

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

heycam

gregwhitworth: but also need to add observing offsets
21:39

heycam

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

heycam

stefan: the behavior is polyfillable if oyu have a 100% div inside
21:40

heycam

... if the size changes, the offsets will have chnaged
21:40

heycam

dbaron: I like the idea that hte pieces of data you provide are the ones you're observing
21:40

heycam

... don't like having data in there that you're using which you don't get notifications for
21:41

» heycam proposed RESOLUTION: Don't include offsets for the box being observed.
21:41

heycam

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

heycam

Topic: ResizeObserverEntry shape
21:41

» github-bot Successfully commented on w3c/csswg-drafts #3550
21:41

gregwhitworth

Github: w3c/csswg-drafts #3329
21:41

» github-bot OK, I'll post this discussion to w3c/csswg-drafts #3329 ([resize-observer] Which box information should we pass to the callback).
21:42

gregwhitworth

w3c/csswg-drafts #3329#issuecomment-466737070
21:42

heycam

gregwhitworth: two options for the shape
21:42

heycam

... during the fragmentation discussion we might impact this
21:42

heycam

... the important part is that you can now watch N different types of boxes
21:42

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

heycam

... so inline/block would be the dimensions of the observed box. that's option A
21:45

heycam

... option B has separate properties for each box you could have observed
21:45

heycam

... benefit is that you can do e.g. `if (entry.borderBox)`
21:45

heycam

... overall most web devs I asked prefer B
21:46

Rossen

heycam, is it possible to observe multiple boxes with the same observer?
21:46

Rossen

gregwhitworth, no
21:47

heycam

heycam: could also have a type property with values like "border"
21:47

heycam

... rather than having multiple properties where only one will ever be non-null
21:47

heycam

gregwhitworth: the polls I did were like 65%-35%, 80%-20%
21:47

heycam

... so majority wanted option B
21:48

heycam

iank_: only thought about the .type property is that often people don't check types
21:48

heycam

... option B does give you stronger type safety
21:48

heycam

alex: option B could break easily
21:48

heycam

florian: which is what you want
21:49

heycam

Rossen: any other options?
21:49

heycam

gregwhitworth: no
21:50

heycam

... what are the thoughts about the Houdini Box API
21:50

heycam

Rossen: I mentioned last time, wedon't necessarily have Box structures for those things
21:50

heycam

... not that we couldn't have an identifier that has this
21:50

heycam

... but I'm curious what the lifetime expectaitons are
21:50

heycam

... if you take a reference to one of these boxes, and hold on to it
21:50

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

heycam

... what are the expectations here?
21:51

heycam

iank_: these aren't live objects
21:51

heycam

... we create a new one each time
21:51

heycam

gregwhitworth: the observation life cycle takes care of this
21:51

heycam

alex: the life cycle of resize observer ... the stuff we already released deals with the life cycle and it's complex
21:52

heycam

... the question is, what keeps the resize observer alive
21:52

heycam

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

heycam

stefan: the entry has a reference to the element
21:52

heycam

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

heycam

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

heycam

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

heycam

smfr: CSS pixel units?
21:53

heycam

gregwhitworth: we have an issue tomorrow to discuss device units
21:55

heycam

[some discussion about the downsides of option B shape]
21:55

heycam

gregwhitworth: the reason this API exists is to watch dimensions to do container query like things
21:55

heycam

... did width change? fire it
21:55

heycam

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

heycam

gregwhitworth: not sure if scroll box is heavily defined
21:55

heycam

Rossen: not *heavily*
21:56

heycam

florian: which scroll box are we talking about?
21:56

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

heycam

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

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

heycam

[some whiteboard drawing]
21:59

heycam

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

heycam

gregwhitworth: I'm leaning towards that
22:01

heycam

Rossen: so would dropping scroll box make people happy?
22:01

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

heycam

alex: the use case for scroll box was a chat box
22:02

heycam

... you always want to keep the the bottom, and if you are loading images you might want to scroll down
22:02

heycam

smfr: scroll to MAXINT
22:02

heycam

florian: scroll snapping will do that for you
22:02

heycam

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

heycam

stefan: just do it any time you get new content
22:03

heycam

florian: scroll snap will do that for you declaratively
22:03

gregwhitworth

Proposed resolution: remove scrollBox
22:03

gregwhitworth

Proposed resolution: remove scrollBox from the observable boxes
22:04

heycam

RESOLVED: Option B, and remove scrollBox
22:05

heycam

TopiC: adding fragmentation support to resize observer
22:05

» github-bot Successfully commented on w3c/csswg-drafts #3329
22:05

gregwhitworth

Github: w3c/csswg-drafts #3673
22:05

» github-bot OK, I'll post this discussion to w3c/csswg-drafts #3673 ([resize-observer] ResizeObserver should support fragments).
22:05

heycam

gregwhitworth: plinss brought up that we don't support fragments
22:05

heycam

... which is valid
22:05

heycam

... I don't want this API to back us into a corner for future support of some new display type
22:06

heycam

florian: or printing
22:06

heycam

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

heycam

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

heycam

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

heycam

florian: ok
22:07

heycam

gregwhitworth: ... this is just turning the contentBox property value from a single object to a list
22:08

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

heycam

florian: inline fragmentation
22:08

heycam

... do this cover that?
22:08

heycam

alex: resize observer doesn't support watching inlines
22:08

heycam

florian: ruby doesn't fragment
22:08

heycam

dbaron: some larger pieces can
22:08

heycam

florian: the rb and rt don't
22:08

heycam

florian: anyway, the API shape here works
22:09

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

heycam

... and the div is broken between two columns
22:09

heycam

... the representation would be a list of all of the fragments for that div
22:09

heycam

... of the content box of that div
22:09

heycam

... and the expected behavior is that you would get a callback when any of them change?
22:10

heycam

gregwhitworth: that's the next issue
22:10

heycam

... technically I don't think you can observe those
22:10

heycam

... in multicol it's ok, content rect will change, and you'll get the notification
22:10

heycam

... I don't think you can't observe the other boxes
22:10

heycam

florian: what other boxes?
22:10

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

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

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

heycam

... because something has changed
22:11

heycam

florian: e.g. because it moved
22:12

heycam

stefan: the interesting case if the content box didn't change but the fragments did
22:12

heycam

... I don't like that idea
22:12

heycam

gregwhitworth: not even sure we can observe just the fragments
22:12

heycam

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

heycam

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

heycam

dbaron: but there are 3 content rects
22:13

heycam

[Rossen draws]
22:14

heycam

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

heycam

florian: no fragmentainer is the container around that
22:23

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

heycam

... most webdevs will code for a single box
22:23

heycam

... what happens if I've created a resized observer and suddenly someone puts the target in a multi col
22:23

heycam

... now the use of resize observer breaks
22:24

heycam

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

heycam

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

heycam

Rossen: the few that care about it have it
22:24

heycam

gregwhitworth: I think it's ok to have it in here
22:25

heycam

... I don't see this scenario happening much based on the main use case for resize observer
22:25

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

heycam

... but that's not future proof
22:25

heycam

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

heycam

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

heycam

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

heycam

rego: now the offsets might be useful...
22:27

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

heycam

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

heycam

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

heycam

Rossen: block elements
22:28

heycam

alex: and SVG
22:28

heycam

florian: grid, multi-col
22:28

heycam

dbaron: tables?
22:29

heycam

... some things get messier with e.g. column spans in tables
22:29

heycam

alex: watching column span sizes? or cell sizes?
22:29

heycam

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

heycam

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

heycam

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

heycam

florian: if not it needs to be
22:32

heycam

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

heycam

alex: an array
22:32

heycam

iank_: an additional array?
22:32

heycam

... the most common thing is people will use only one box
22:32

heycam

... weshouldn't make them access through an array
22:32

heycam

Rossen: multiple box objects or a bunch of rects?
22:33

heycam

Rossen: people might come back and say that fragments are not really rects
22:34

heycam

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

heycam

gregwhitworth: yes
22:36

heycam

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

heycam

Rossen: document order
22:37

heycam

... the biggest issue with regions is that people complain about search result order
22:37

heycam

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

heycam

Rossen: but even that can be fragmented
22:37

heycam

alex: the question what elements can we watch
22:37

heycam

... all elements, but observations don't fire for non-replaced inline elements
22:37

heycam

... per spec
22:38

heycam

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

heycam

alex: we can
22:38

heycam

iank_: it would be nice if not needing to use the array
22:38

heycam

... could also make the contentBox attribute polymorphic
22:39

heycam

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

heycam

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

heycam

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

heycam

iank_: Edge and Firefox take the union of the rects
22:39

heycam

gregwhitworth: that would let you handle the common case
22:40

heycam

... but you would also have the fragments available in a separate property
22:40

heycam

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

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

heycam

... would you sum up the inline sizes in these single values?
22:41

heycam

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

» 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?
22:44

» heycam everyone is distracted by a whiteboard right now
22:44

» smfr if only the whiteboard integrated with the minutes
22:44

heycam

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

heycam

gregwhitworth: valid point about not being able to sum them up
22:45

heycam

... but I'm going back to the main use case of non fragmented boxes you want to observe
22:45

» AmeliaBR smfr, well you're one of the people to ping, since one is your issue w3c/csswg-drafts #2095
22:45

» 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: ...").
22:45

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

heycam

... "and this or a version of this will solve this problem in a way to satisfy everyone"
22:46

heycam

... so we could resolve on having the fragments as a list we can add later
22:46

heycam

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

heycam

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

heycam

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

heycam

iank_: we need this defined anyway for clientWidth/clientHeight
22:47

heycam

... there is blink/webkit vs edge/firefox
22:48

heycam

Rossen: opening an issue on CSSOM and defining how clientWidth/clientHeight work under fragmentation is needed
22:48

heycam

... and whatever answer that has, will be reflected to be the two numbers here for inlineSize and blockSize on the entry
22:48

heycam

... if you don't have fragmentation, you don't have the problem
22:49

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

heycam

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

heycam

stefan: Intersection Observer is similar, it defers to getBoundingClientRect
22:50

heycam

florian: the "add that later" ...
22:50

heycam

gregwhitworth: realistically nobody is asking me for it
22:50

heycam

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

heycam

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

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

heycam

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

heycam

[discussion about Chrome implementation of fragments]
22:54

heycam

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

heycam

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

heycam

florian: different approach to the same question
22:56

heycam

... an author who hasn't thought about fragments
22:56

heycam

... the thing they haven't thought about happened to be placed in multicol
22:56

heycam

... does it break more to get the first fragment size, or the union size?
22:56

heycam

gregwhitworth: I would say equally
22:57

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

heycam

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

heycam

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

heycam

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

heycam

alex: is there any perf difference between the two?
23:02

heycam

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

heycam

straw poll:
23:04

heycam

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

heycam

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

astearns

main room is about to break
23:05

astearns

(go on a break)
23:05

florian

option 1
23:05

smfr

1
23:05

Rossen

option 1, 2
23:06

iank_

2
23:06

gregwhitworth

option 2
23:06

heycam

option 1
23:06

rego

option 1
23:06

rachelandrew

option 1
23:06

dbaron

prefer 2, I think, but not sure
23:07

heycam

result: option 1
23:07

heycam

RESOLVED: Option 1; contentBox is an array of fragment sizes
23:07

heycam

trackbot: end telcon
23:07

» trackbot is ending a teleconference.
23:07

trackbot

Zakim, list attendees
23:07

Zakim

As of this point the attendees have been (no one)
23:07

» github-bot Successfully commented on w3c/csswg-drafts #3673
23:07

trackbot

RRSAgent, please draft minutes
23:07

RRSAgent

I have made the request to generate w3.org/2019/02/25-fx-minutes.html trackbot
23:07

trackbot

RRSAgent, bye
23:07

RRSAgent

I see no action items

2 years ago

« 8 months earlier

a day later »

today »