Intent to Implement and Ship : onslotchange event handler IDL attribute
ssi...@igalia.com
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
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()">
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
Frédéric Wang
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.
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
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.
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
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
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
--
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/548bb454-41d4-9b8d-0706-ea3d1ca4138b%40igalia.com.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU4bkkHJWLm-O%2BqztmJjS8N4XykQe0g%2BxMrkiLGzm3MPg%40mail.gmail.com.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfHD-GHZZOzookXU5UXk53Yzy9sEN8DO_iMAMHLEJA84Q%40mail.gmail.com.