[Proposal] button[type=“abort”]/input[type=“abort”]

Since the fetch requests are now abortables, via an AbortController, I’m self-asking about why the HTML doesn’t have the dedicated input/button type for that behavior, a few like the [type="reset"].

It can be used to unify the abortion process, between the fetch API, non-JS fetching or any future JS feature.

Related to a form, it follows the current input/button spec, nested in it or targeted by its formattribute.

Related to an a or another media requesting a resource, we should find a relevant attribute.

Imho, the AbortController constructor should be a few touched too, to take the input/button to listen.

What do you think about it, please?

The button and input element’s are already fairly overloaded. Input more-so than button granted. I think the spec designers would rather not jump to modifying very old specs of the web without a very good reason. As it is, fetch can’t even be used without JS. So, modifying an element to provide a “non-js” way to abort a JS only API seems weird.

I think this is a case best explained by simply isolating scope and needs to keep effort to a minimum amount. What is your use-case/need to have a dedicated element modification to allow for auto-aborting a request?

Hi @Garbee,

Sorry for the delay, I just published a new DOM tool, inspired on the native constructors, which it can illustrate the needs: https://github.com/Lcfvs/content-handler

The idea is to have a standard element to rely on it for request abortions and automatically detect it if any.

Imho, even without JS, the abortion is useful, thinking to these points:

• to cancel a download, without ending to a blank page
• to have an UI element to do that, to don’t let the user’s attention getting away from the UI
• to have a standard way to the seamless apps, with JS or not

A download of what exactly? Files don’t abort to a blank page. And last I used the stop load button in any browser UX, the page stayed as-is in memory.

We have button type=button, so if you need to abort something within your app, that’s available for wiring up. Not sure why you need a specific abort type with murky functionality based on context.

So without JS what would this do that the browsers stop loading button doesn’t already do?

As you can probably tell, I’m highly opposed to stuffing more contexts into an already difficult to understand area. Especially when there doesn’t seem to be a core problem that need solving, it is pure developer convenience as far as I am understanding it.

If it can be justified that end users need this kind of functionality to improve their experiences, then there is something to talk about. As is though, it’s a few extra lines of JS to cancel things, so if you’re doing that already it’s no big deal. Gzip will handle compressing it down just fine. And non-JS apps, well what are you aborting that isn’t done already by a browser with the stop button?

Prove it benefits end users. Until then, I personally wouldn’t help push something like this.