As much as dom & domkit are breeze to work with, there are little niggles that keep catching me out, and I can do all but tear my hair out! And I believe a lot of it boils down to this:

Can domkit::Button be a HTML <button>?

Currently it is a div, which causes the following issues:

1). Divs aren't semantically correct.

2). Divs no not fire form submit events.

HTML button / submit elements are the only way to fire a form submit event (see submit-event-does-not-fire-if-submit-initiated-programatically).

I find the submit event very important, in part because I use hyperform to enhance HTML5 validation.

So when I want a form submit button, I have to create my own Submit class, that is a HTML button, but emulates domkit::Button so it looks and behaves the same as the rest of the application.

3). Divs don't have a disabled attribute.

domkit::Button overrides the dom::Elem.enabled field to apply different behaviour. (One sets the disabled attribute, the other sets a CSS class.)

When using querySelectorAll() I don't immediately know if I have an input, button, or div, so I can't blindly set the Elem.enabled field because it doesn't work on domkit::Buttons.

None of the above issues are insurmountable, but I do find myself having to work around them time and time again - so I thought it worth asking the question.

Can domkit::Button be a HTML <button>?

It might be possible; but I think it would be challenging with the all the ways its customized. More future proof to just use a <div>.

1). Divs aren't semantically correct.

This is true for most of domkit :) We try to be a good citizen, but practicality generally wins out (see also: Tables)

2). Divs no not fire form submit events.

Not sure the context here; but obviously you have control over the onAction handler. If you're looking for the "Enter" key submit, then a few ways to handle that -- either use a hidden <submit> element -- or add a key event handler to the <form>.

Might be useful to have a standard domkit::FormBox element if you think we are missing something out-of-the-box?

3). Divs don't have a disabled attribute.

Not every widget maps back to a native browser control. So not sure how you get around this. Though I think standardizing using the dom::Elem API works pretty well.

When using querySelectorAll() I don't immediately know if I have an input, button, or div, so I can't blindly set the Elem.enabled field because it doesn't work on domkit::Buttons.

You should get back an instance of Button so this should work -- you seeing problems with this?

Might have to make an HtmlButton then :(

I agree, using the more semantically appropriate tag seems better.