It should be possible to listen on a node that also happens to have child nodes.

[malcolmsparks]

I spent a few hours today tracking down this issue, so thought I'd write it up as a gotcha.

I was trying to listen to submit events on a form.

<form id="myform">
  <input type="text"></input>
  <input type="submit"></input>
</form>

This was my first attempt.

(events/listen!
   (by-id "myform") "submit"
   (fn [ev] (.log js/console "Submit")))

It doesn't work.

But this works :-

<button id="test"/>

(events/listen!
   (by-id "test") "click"
   (fn [ev] (.log js/console "OK")))

And, going back to the previous example, this works too :-

(events/listen!
   (domina.css/sel "#myform") "submit"
   (fn [ev] (.log js/console "Submit")))

So does this.

(events/listen!
   [(by-id "myform")] "submit"
   (fn [ev] (.log js/console "Submit")))

Notice that I've wrapped the node in a vector.

But this doesn't :-

(events/listen!
   (by-id "myform") "submit"
   (fn [ev] (.log js/console "Submit")))

And I think it should.

Why doesn't it work?

If we look at the events/listen! function we see it is wrapper the node with domina/nodes. That's what you want if you're passing a NodeList (perhaps found using a selector). But in the case of an HTML form, it returns the 2 child nodes (the input text and submit button).

So

(events/listen!
   (by-id "myform") "submit"
   (fn [ev] (.log js/console "Submit")))

adds the event listener to both inputs, but not to the form.

I think the DomContent protocol is complects the notion of parenthood with the notion of a collection of nodes. They are not the same thing.

[levand]

Thanks for the report: I'll take a closer look.

DomContent is not intended to complect the notion of parenthood and node collections. It is intended to regard a single node as a single node, whether or not it has children.

Unfortunately, some browsers implement the NodeList (or a similar) interface on certain nodes, with respect to their children, causing unintentional complection. I saw that happen on button groups before, my guess is that that's what's happening with html elements as well.

Unfortunately the only solution is to special-case those elements; I'll take a look and see if that's indeed what's going on.

[masklinn]

Well I've just hit this issue and it's a rather frustrating one.

FWIW, it's probably because as per spec HTMLFormElement is array-like for its controls (except image buttons): it has a length property and can be indexed.

I think the problem here is that the array-like filter is incorrect: it's possible (and indeed trivial) to have nodes with no name attribute (and the comment is incorrect, a select with no explicit @name will be considered array-like — the default @name is "") which I'm pretty sure is unexpected).

Either the filter should be replaced by nodeName (or a typecheck on Node or HTMLElement if that works in all browsers), or the check should be that name is undefined (for elements with a @name, the default value is the empty string). The latter will still be error-prone, but less-so.

[malcolmsparks]

I think there's a good case for type check on HTMLElement . The current behaviour violates the principle of least surprise: http://en.wikipedia.org/wiki/Principle_of_least_astonishment for its intended audience (developers). I hope and expect that ClojureScript gains a much increased audience as it begins to offer advantages beyond simply LISP syntax (as show by David Nolen's recent demonstrations) and Domina is a very useful and fundamental library (and used in Pedestal) - it would be beneficial to many if this kind of thing were fixed because it can lead to hours of frustration for the unwary developer, enough to put them on CLJS for good -

[ckirkendall]

This was due to an issue with selecting on form nodes without a name attribute in some browsers. This has been addressed in 1.02-SNAPSHOT.