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

Re: [csswg-drafts] ResizeObserverEntry either needs to have its JS constructor removed, or define how its members are initialized when constructed (#3946)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 Nov 2019 00:42:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-550567232-1573087342-sysbot+gh@w3.org>
The CSS Working Group just discussed `ResizeObserverEntry either needs to have its JS constructor removed, or define how its members are initialized when constructed`, and agreed to the following:

* `RESOLVED: To remove the constructor and remove the language about how to populate the object into a different point in the spec`

<details><summary>The full IRC log of that discussion</summary>
&lt;myles> Topic: ResizeObserverEntry either needs to have its JS constructor removed, or define how its members are initialized when constructed<br>
&lt;myles> dlibby: This issue is a historical oddity. WICG spec language made it into an ED, despite it not being implemented in blink. Gecko realized this discrepancy, and after some debate, didn't implement this destructor. There's some conversation about what the destructor should be because it doesn't fit into JS. The point of resize observer is to give asynchronous notifications when layout changes to the size of elements<br>
&lt;myles> dlibby: so given that this doesn't exist in either current implementation, it seems worth removing from the spec and updating the language in a different section about implementation details of how a browser would populate a resize observer entry at runtime<br>
&lt;myles> bkardell_: There's an implementation in webkit as well.<br>
&lt;myles> dlibby: I'll check it<br>
&lt;myles> smfr: Is there a WPT test?<br>
&lt;myles> dlibby: no.<br>
&lt;myles> AmeliaBR: Seems easy to remove this from the spec. If there is desire for it later, add it back in.<br>
&lt;myles> AmeliaBR: But it doesn't seem like we're blocking anything for the future to remove it for now<br>
&lt;myles> astearns: Anyone want to argue for keeping it in?<br>
&lt;myles> RESOLVED: To remove the constructor and remove the language about how to populate the object into a different point in the spec<br>
&lt;myles> s/destructor/constructor/<br>
&lt;bkardell_> s/didn't implement this destructor. /didn't implement this constructor<br>
&lt;myles> GitHub: https://github.com/w3c/csswg-drafts/issues/3946<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3946#issuecomment-550567232 using your GitHub account
Received on Thursday, 7 November 2019 00:42:24 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:22:13 UTC