When typing into <input>, an Event is fired. However, when running document.querySelector("input").value = "x", none is fired.

When clicking into <details>, an Event is fired. And when running document.querySelector("details").open = true, the event is also fired.

Is this pure inconsistency or was it the developers personal taste?

Or is there some deeper concept on when events are being fired and when not? Maybe even outside of HTML (on a more general computer science level)?

Background: I'm building a component library and try to be as close to native HTML as possible so that the consumers can feel at home.

CodePudding user response：

An Event is fired to notify the program of an occurrence they might want to interact on.

The <input> case seems quite straightforward here: when the user edits the input value, we want our JS to handle these changes, maybe even prevent them.
When our program did the change, e.g by setting the .value IDL attribute, it's far less interesting to have that notification, if we wanted to prevent the change, we wouldn't have done it to begin with.

This is the behavior of most "native" events.

Now, for the case of <details>'s toggle event, it's indeed weird to notify the program when it did the change. The thing is that we're in a very particular case where the user agent itself can change the attribute when the user toggles the element.

details { color: blue }
details[open] { color: red } /* when the attribute is set */

<details><summary>open me</summary>Now I'm red</details>

This is because the open attribute is reflected in IDL, i.e when you set the IDL attribute (.open), the attribute is either set or removed (because here it's a boolean attribute). And it was thought that this attribute would be used to help styling the element, so that we don't need yet another :pseudo-class with complicated relationships.

So we end up with an attribute that can be changed by the user, and we definitely want an event when the user does this change. So it makes some sense that this event actually represents the attribute change, and that even when we change it programmatically, we do have an event firing.

Honestly, I too find it particularly surprising. You can read this very related thread on which I based most of this answer, where some arguments where exposed, in both ways, though not exactly about the event.

So I think that you can keep the mental model of "native" events firing when something outside our doing did happen, while remembering that there are always particular cases and that you should look at the details of each event.

CodePudding user response：

Events (such as value changes) triggered by users and value changes done programmatically are different things. Thus, JS behaves differently. Such distinction gives developers more control of how the system behaves.

If you wish to trigger change event after updating the value, you need to do it yourself with dispatchEvent().

The links below explain how JS events work. If you do the same for your library, you will have good compatibility.

https://www.w3docs.com/learn-javascript/introduction-to-browser-events.html https://www.w3docs.com/snippets/javascript/how-to-create-and-trigger-event-in-javascript.html