Intent to Prototype: Invokers

364 views
Skip to first unread message

Keith Cirkel

unread,
Oct 10, 2023, 1:14:13 PM10/10/23
to blin...@chromium.org

Contact emails


Explainer


Specification


Summary

Adding invoketarget and invokeaction attributes to <button> and <input type="button"> / <input type="reset"> elements would allow authors to assign behaviour to buttons in a more accessible and declarative way, while reducing bugs and simplifying the amount of JavaScript pages are required to ship for interactivity. Buttons with invoketarget will - when clicked, touched, or enacted via keypress - dispatch an InvokeEvent on the element referenced by invoketarget, with some default behaviours.



Blink component


Motivation

All elements within the DOM are capable of having interactions added to them. A long while ago this took the form of adding inline JavaScript to an event attribute, such as <button onclick="other.open()"></button>. Inline JavaScript has (rightly so) fallen out of favour due to the security and maintainability concerns. Newer pages may instead introduce more JavaScript to imperatively discover elements and call addEventListener('click', ...) to invoke the same behaviour. These patterns reduce developer experience and introduce more boilerplate and friction, while remediating security and maintainability concerns. Some frameworks attempt to reintroduce the developer experience of inline handlers by introducing new JavaScript or HTML shorthands, such as React’s onClick={...}, Vue’s @click=".." or HTMX’s hx-trigger="click". This proposal attempts to redress the balance by adding invoketarget and invokeaction attributes to <button> and <input type="button"> / <input type="reset"> elements would allow authors to assign behaviour to buttons in a more accessible and declarative way, while reducing bugs and simplifying the amount of JavaScript pages are required to ship for interactivity.



Initial public proposal


TAG review

None

TAG review status

Pending

Risks



Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



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

No

Flag name on chrome://flags

Experimental Web Platform Features

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status


This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
Forward
0 new messages