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
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
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.
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
--
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.
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.
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.