Why does the HTML spec fire some events without their defined constructor?

What I means is: When specifying firing of events, in some places in the spec it states the event constructor with “using”, like this:

fire an event named hashchange at document's relevant global object, using HashChangeEvent

…and in other places it’s stated without “using”

fire an event named input at the element, with the bubbles and composed attributes initialized to true.

So given that, when that input event is fired, the Event constructor is used — because the caller doesn’t have a “using” statement.

But the input event have an InputEvent constructor defined in the UI Events spec at https://w3c.github.io/uievents/#inputevent. Why doesn’t the HTML spec state that constructor must be used when firing the input event?

No, I wasn’t sure — it just seemed odd that https://html.spec.whatwg.org/#text-(type=text)-state-and-search-state-(type=search):user-interaction-task-source has this:

Queue an element task on the user interaction task source given the element to fire an event named input at the element, with the bubbles and composed attributes initialized to true.

…where input is a link to the UI events definition of an input event with an InputEvent. But then despite that, the spec doesn’t state the event must be constructed with that InputEvent interface

So I notice that the Event code in WebKit sets isTrusted (to true by default) in the Event constructor — despite the DOM spec making a clear distinction between the “constructing an event” operation and the “creating an event” operation. And the spec states that that isTrusted is set to true in the “creating an event” operation, not in the “constructing an event” operation.

Nevertheless, it’d seem like the observable behavior in WebKit must be conforming to the spec — since WebKit passes whatever the relevant tests in WPT are.

So… Is it actually expected that setting isTrusted in the Event constructor will have the same observable effect at setting in the implementation of the “create an event” operation? And if so, the separation about where isTrusted is set is something that exists in the spec for some reason but doesn’t actually get exercised in practice by all calling operations?

Because in the constructor code at https://github.com/WebKit/WebKit/blob/e4d6852ee20ff3dfcd3a59fe241d84f662abb234/Source/WebCore/dom/Event.cpp#L45-L55 I see:

, m_isTrusted { isTrusted == IsTrusted::Yes }

…and the create signatures I see are:

Ref<Event> Event::create(const AtomString& type, CanBubble canBubble, IsCancelable isCancelable, IsComposed isComposed)
{
    return adoptRef(*new Event(EventInterfaceType::Event, type, canBubble, isCancelable, isComposed));
}

…so if that’s called, then it defaults to IsTrusted::Yes

And then the other create signature is:

Ref<Event> Event::create(const AtomString& type, const EventInit& initializer, IsTrusted isTrusted)
{
    return adoptRef(*new Event(EventInterfaceType::Event, type, initializer, isTrusted));
}

…for callers that need to set IsTrusted::No