286055 - syntactic sugar for listener lodgement

Status: NEW

(Core :: DOM: Events, enhancement, P5)

Description

[Nigel McFarlane]

E4X provides some much needed brevity and simplicity, but only goes
so far. This is a request for event listener support, either in an
E4X style, or something equivalent in the DOM.

It would be nice if E4X could facilitate easy attachment of
event listeners, as HTML's onclick was originally designed to do.

This would be especially convenient since addEventListener is a
verbose feature that most simple DHTML code requires. It compliments
straight content mutation via appendChild and createElement and so on.

There is a simple syntax already available:

foo.onclick = myhandler;

but it has a specific shortcoming: it doesn't support lodgement
of multiple listeners. Modern DHTML techniques use a graceful fallback
strategy that relies on scanning the current page "onload",
and decorating that page with extra (not replacement) handlers
to support the intended DHTML effects. foo.onclick doesn't allow this
extra lodgement, so such techniques rely on addEventListener() and MS
equivalents. Looking forward, this is a bit clunky, and means that
E4X does not provide a "complete escape" from the DOM APIs for
the common 80% of cases.

Use of foo.onclick is also untenable from the point of
view of (one day) namespaced JS, where global document content
might be decorated with handlers from a number of packages.

Something perhaps like these suggestions would be nice:

foo.bar:mouseover = fn;    // = foo.bar.addEventListener("click", fn, false);
foo.bar:mouseover += fn;   //  adds a *second* listener

I borrowed bar:mousover from CSS2 selector syntax like a:hover for
the purposes of speculation only. Alternatively:

foo.bar.mouseover e= fn;   // a hint that 'mouseover' is an event target?

Regardless of syntax, it's the ability to safely add event listeners,
regardless of the current content or currently lodged listeners, that's
the wanted feature and the point at hand.

Scripters would still have to fallback to addEventListener
for the less common case of capture events (which requires reading
about the DOM, anyway).

If this, or equivalent, syntactic sugar was supported, that would be a
learning bonus for DOM-engaged developers. They could then code
their DHTML / DXUL / DSVG in E4X exclusively, without ever having to
learn the traditional DOM API. Currently they must learn either DOM
or both DOM and E4X if they want to do anything that effectively
adds an interactive widget or element. From the point of view of
learning tasks, E4X as it stands does not relieve the burden of
learning the DOM APIs because of this event issue.

You might say: "the DOM is not hard", and that is true (for you).
E4X, however, provides an easier shorthand that lowers the barrier to
entry for those just starting to learn JS+XML programming. It lacks
a shorthand for useful and frequently used event registration, though.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't see what this has to do with E4X, since E4X is a mechanism for handling
XML fragments in JavaScript, and there aren't any XML fragments here.

Comment 2

[Nigel McFarlane]

Please reassign the component if it's wrong. This is either an
enhancement request about handlers, or about E4X, or about the DOM,
or some combination.

E4X provides a partial syntax alternative to the DOM API, whether
by design or merely fortuitously. This bug requests more such syntax
specifically for the DOM Events API so that web and application
developers can perform simple DOM-manipulation tasks without any
formal training on the DOM.

Syntax for event listener registration is the main missing item, so
that's what this bug requests.

- N.

Comment 3

[Nigel McFarlane]

Attachment: example of a DHTML effect with some fallback.

As an exercise, edit this DHTML page, inserting E4X syntax until as much DOM
verbosity as possible is gone. Clearly addEventListener() is the main obstacle
to   a "pure" E4X solution, which would be far easier to code and to read. I
agree this example is a little contrived, and could perhaps be better put in
XUL than in HTML.

- N.

Comment 4

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.