W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

Re: [csswg-drafts] [resize-observer] Which box information should we pass to the callback (#3329)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 25 Feb 2019 22:05:03 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-467202586-1551132301-sysbot+gh@w3.org>
The CSS Working Group just discussed `ResizeObserverEntry shape`, and agreed to the following:

* `RESOLVED: Option B, and remove scrollBox`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: ResizeObserverEntry shape<br>
&lt;gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3329<br>
&lt;gregwhitworth> https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-466737070<br>
&lt;heycam> gregwhitworth: two options for the shape<br>
&lt;heycam> ... during the fragmentation discussion we might impact this<br>
&lt;heycam> ... the important part is that you can now watch N different types of boxes<br>
&lt;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?<br>
&lt;heycam> ... so inline/block would be the dimensions of the observed box.  that's option A<br>
&lt;heycam> ... option B has separate properties for each box you could have observed<br>
&lt;heycam> ... benefit is that you can do e.g. `if (entry.borderBox)`<br>
&lt;heycam> ... overall most web devs I asked prefer B<br>
&lt;Rossen> heycam, is it possible to observe multiple boxes with the same observer?<br>
&lt;Rossen> gregwhitworth, no<br>
&lt;heycam> heycam: could also have a type property with values like "border"<br>
&lt;heycam> ... rather than having multiple properties where only one will ever be non-null<br>
&lt;heycam> gregwhitworth: the polls I did were like 65%-35%, 80%-20%<br>
&lt;heycam> ... so majority wanted option B<br>
&lt;heycam> iank_: only thought about the .type property is that often people don't check types<br>
&lt;heycam> ... option B does give you stronger type safety<br>
&lt;heycam> alex: option B could break easily<br>
&lt;heycam> florian: which is what you want<br>
&lt;heycam> Rossen: any other options?<br>
&lt;heycam> gregwhitworth: no<br>
&lt;heycam> ... what are the thoughts about the Houdini Box API<br>
&lt;heycam> Rossen: I mentioned last time, wedon't necessarily have Box structures for those things<br>
&lt;heycam> ... not that we couldn't have an identifier that has this<br>
&lt;heycam> ... but I'm curious what the lifetime expectaitons are<br>
&lt;heycam> ... if you take a reference to one of these boxes, and hold on to it<br>
&lt;heycam> ... and the element is removed from the DOM tree, or it's mutated in a way that this box no longer exists<br>
&lt;heycam> ... what are the expectations here?<br>
&lt;heycam> iank_: these aren't live objects<br>
&lt;heycam> ... we create a new one each time<br>
&lt;heycam> gregwhitworth: the observation life cycle takes care of this<br>
&lt;heycam> alex: the life cycle of resize observer ... the stuff we already released deals with the life cycle and it's complex<br>
&lt;heycam> ... the question is, what keeps the resize observer alive<br>
&lt;heycam> Rossen: my question is, in one case we're just returning pure data<br>
&lt;heycam> stefan: the entry has a reference to the element<br>
&lt;heycam> ... so even if the element is removed from the DOM, it still has a reference to the element<br>
&lt;heycam> iank_: we gather up all the obserations, and we snapshot at that time<br>
&lt;heycam> stefan: even if you have an element removed from the DOM, you still have a reference to the object<br>
&lt;heycam> smfr: CSS pixel units?<br>
&lt;heycam> gregwhitworth: we have an issue tomorrow to discuss device units<br>
&lt;heycam> [some discussion about the downsides of option B shape]<br>
&lt;heycam> gregwhitworth: the reason this API exists is to watch dimensions to do container query like things<br>
&lt;heycam> ... did width change?  fire it<br>
&lt;heycam> smfr: what about observing scroll box on something not scrollable?<br>
&lt;heycam> gregwhitworth: not sure if scroll box is heavily defined<br>
&lt;heycam> Rossen: not *heavily*<br>
&lt;heycam> florian: which scroll box are we talking about?<br>
&lt;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<br>
&lt;heycam> florian: "scroll viewport" is defined, "scroll box" is not<br>
&lt;heycam> Rossen: are we talking about the scrollable box, the extent of all your contents, which you could scroll if you were scrollable?<br>
&lt;heycam> [some whiteboard drawing]<br>
&lt;heycam> Rossen: if this was just added there without a use case, we could just remove it<br>
&lt;heycam> gregwhitworth: I'm leaning towards that<br>
&lt;heycam> Rossen: so would dropping scroll box make people happy?<br>
&lt;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<br>
&lt;heycam> alex: the use case for scroll box was a chat box<br>
&lt;heycam> ... you always want to keep the the bottom, and if you are loading images you might want to scroll down<br>
&lt;heycam> smfr: scroll to MAXINT<br>
&lt;heycam> florian: scroll snapping will do that for you<br>
&lt;heycam> alex: how do you know if you've scrolled?<br>
&lt;heycam> stefan: just do it any time you get new content<br>
&lt;heycam> florian: scroll snap will do that for you declaratively<br>
&lt;gregwhitworth> Proposed resolution: remove scrollBox<br>
&lt;gregwhitworth> Proposed resolution: remove scrollBox from the observable boxes<br>
&lt;heycam> RESOLVED: Option B, and remove scrollBox<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-467202586 using your GitHub account
Received on Monday, 25 February 2019 22:05:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:44 UTC