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?
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.