Intent to Implement and Ship : onslotchange event handler IDL attribute

72 views
Skip to first unread message

ssi...@igalia.com

unread,
Aug 27, 2021, 2:37:49 PMAug 27
to blin...@chromium.org
Contact emails
ssi...@igalia.com, fw...@chromium.org

Explainer:
Currently, the way to listen an event is:
target.addEventListener("slotchange", listener);

After this addition an alternative attribute-based form will be
availlable for the developers
element
<target onslotchange="myListener()">

Doc Link(s):
- https://html.spec.whatwg.org/#handler-onslotchange
- https://dom.spec.whatwg.org/#dom-shadowroot-onslotchange
- https://github.com/whatwg/dom/pull/785
- https://github.com/whatwg/html/pull/4129

Specification
https://html.spec.whatwg.org

Summary
The slotchange event is fired on a <slot> element when the node(s) it
contained change. One can listen to that event via the
EventTarget.addEventListener() API. The goal is now to expose the
onslotchange IDL attribute from the GlobalEventHandlers and ShadowRoot
interfaces, so that one can register a listener by attaching this
attribute to target elements.

Blink component
Blink>DOM

Motivation
The slotchange event is fired on a <slot> element when the node(s) it
contained change. One can naturally listen to that event via the
EventTarget.addEventListener() API. However, web developers are also
familiar with the alternative attribute-based form (e.g.
element.addEventListener("load", ...) Vs on <element onload="...">)
which is sometimes convenient for quick testing. For consistency with
other events, an attribute onslotchange is thus added.

Its important to have it on ShadowRoot too as <slot> is normally used
for web components, and there is a common use case to add a listener on
this ShadowRoot.

TAG review

TAG review status
Not applicable

Risks

Interoperability and Compatibility

Gecko:
Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1501983)


WebKit:
Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=191310)


Web developers:
No signals

Debuggability
No DevTools changes are required, treated like any other
event/attribute.

Is this feature fully tested by web-platform-tests?
Yes

Web Platform Tests:

dom/idlharness.window_exclude=Node
html/dom/idlharness.https_exclude=(Document_Window_HTML._)
html/dom/idlharness.https_include=(Document_Window)
html/dom/idlharness.https_include=HTML._
html/webappapis/scripting/events/event-handler-all-global-events
html/webappapis/scripting/events/event-handler-attributes-body-window
html/webappapis/scripting/events/event-handler-attributes-frameset-window
html/webappapis/scripting/events/event-handler-attributes-windowless-body
mathml/relations/html5-tree/math-global-event-handlers.tentative


Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1006096

Patch:
https://chromium-review.googlesource.com/c/chromium/src/+/3096889

Estimated milestones
-

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5739143222001664

Yoav Weiss

unread,
Sep 2, 2021, 6:15:11 AMSep 2
to blink-dev, ssi...@igalia.com
On Friday, August 27, 2021 at 8:37:49 PM UTC+2 ssi...@igalia.com wrote:
Contact emails
ssi...@igalia.com, fw...@chromium.org

Explainer:
Currently, the way to listen an event is:
target.addEventListener("slotchange", listener);

After this addition an alternative attribute-based form will be
availlable for the developers
element
<target onslotchange="myListener()">

An actual explainer that outlines what the feature does, and its developer and user benefits would be helpful for reviewing this.
Can you explain why is a TAG review not applicable?
 


Risks

Interoperability and Compatibility

Gecko:
Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1501983)


WebKit:
Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=191310)


Web developers:
No signals

Could you gather signals? https://goo.gle/developer-signals

Frédéric Wang

unread,
Sep 2, 2021, 7:18:37 AMSep 2
to blin...@chromium.org
Le 02/09/2021 à 12:15, Yoav Weiss a écrit :

An actual explainer that outlines what the feature does, and its developer and user benefits would be helpful for reviewing this.

Just to clarify, the slotchange event is already implemented in all browsers, one can find document on MDN [1] [2]. But <slot> is used by developers as a placeholder for custom DOM tree in Web Components and the slot change event is dispatched when such a substree changes. Typically, the JS code of the web component will listen to slotchange events and react with necessary updates.

As Sonia explained in the motivation, one could just use addEventListener, but for convenience and consistency with other events (e.g. load) it makes sense to add a IDL onslotchange attribute... which also reflect the attribute on elements. And because web components typically put their contents in a ShadowRoot, it makes sense to be able to place the listener on that root.

(note: I'm not really an expert on web components, probably people who are more familiar can explain better the motivation)

 
TAG review

TAG review status
Not applicable

Can you explain why is a TAG review not applicable?

This is just a small change to an existing spec implemented in browsers and it was discussed at WHATWG (see the link provided by Sonia). When is a TAG review typically required?

 


Risks

Interoperability and Compatibility

Gecko:
Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1501983)


WebKit:
Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=191310)


Incidentally, Sonia landed her patch so this is now shipped in WebKit and Firefox.

Web developers:
No signals

Could you gather signals? https://goo.gle/developer-signals

We were not able to find much information from https://github.com/whatwg/html/issues/3487 ; I think Sonia meant to use N/A "The change is too small to justify this effort".

--
Frédéric Wang

Yoav Weiss

unread,
Sep 2, 2021, 7:46:58 AMSep 2
to Frédéric Wang, blink-dev
On Thu, Sep 2, 2021 at 1:18 PM Frédéric Wang <fw...@igalia.com> wrote:
Le 02/09/2021 à 12:15, Yoav Weiss a écrit :

An actual explainer that outlines what the feature does, and its developer and user benefits would be helpful for reviewing this.

Just to clarify, the slotchange event is already implemented in all browsers, one can find document on MDN [1] [2]. But <slot> is used by developers as a placeholder for custom DOM tree in Web Components and the slot change event is dispatched when such a substree changes. Typically, the JS code of the web component will listen to slotchange events and react with necessary updates.

As Sonia explained in the motivation, one could just use addEventListener, but for convenience and consistency with other events (e.g. load) it makes sense to add a IDL onslotchange attribute... which also reflect the attribute on elements. And because web components typically put their contents in a ShadowRoot, it makes sense to be able to place the listener on that root.

(note: I'm not really an expert on web components, probably people who are more familiar can explain better the motivation)

OK, thanks for clarifying what this intent is aiming to ship. 


 
TAG review

TAG review status
Not applicable

Can you explain why is a TAG review not applicable?

This is just a small change to an existing spec implemented in browsers and it was discussed at WHATWG (see the link provided by Sonia). When is a TAG review typically required?


OK, I agree that since this is following a well-known and established pattern, a TAG review is most-probably an overkill. 

 


Risks

Interoperability and Compatibility

Gecko:
Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1501983)


WebKit:
Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=191310)


Incidentally, Sonia landed her patch so this is now shipped in WebKit and Firefox.

Web developers:
No signals

Could you gather signals? https://goo.gle/developer-signals

We were not able to find much information from https://github.com/whatwg/html/issues/3487 ; I think Sonia meant to use N/A "The change is too small to justify this effort".


The motivation section brings up use cases that this would make easier, but it's not super clear what they are, and if developers feel they are important. I wondered if this is something you have evidence for.
With that said, now that I understand what you're trying to ship, consistency can also be an argument for such a change.
 
--
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ce90f246-e1f9-ce3f-9bcc-efdeca45cb01%40igalia.com.

Frédéric Wang

unread,
Sep 2, 2021, 8:57:49 AMSep 2
to blin...@chromium.org
Le 02/09/2021 à 13:46, Yoav Weiss a écrit :

The motivation section brings up use cases that this would make easier, but it's not super clear what they are, and if developers feel they are important. I wondered if this is something you have evidence for.
With that said, now that I understand what you're trying to ship, consistency can also be an argument for such a change.
 

As I said one can already do that with EventTarget.addEventListener so it is not critical at all for developers. But things like EventTarget.onload = ... and <element onload="..."> are pretty common, and it would be surprising for developers if this does not work for all events. But yes, again this is just speculation, not based on any concrete feedback from developers. I imagine somewhat hitting the problem would just switch to addEventListener and move on.

-- 
Frédéric Wang

Yoav Weiss

unread,
Sep 2, 2021, 9:39:49 AMSep 2
to Frédéric Wang, blink-dev
LGTM1

This seems like a small addition to improve the platform's consistency.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike West

unread,
Sep 2, 2021, 1:10:11 PMSep 2
to Yoav Weiss, Frédéric Wang, blink-dev
LGTM2. I agree that this is a tiny ergonomic change, and matching Safari's behavior (with Mozilla's positive signals) should increase interop in the future.

-mike


Chris Harrelson

unread,
Sep 2, 2021, 1:12:21 PMSep 2
to Mike West, Yoav Weiss, Frédéric Wang, blink-dev
Reply all
Reply to author
Forward
0 new messages