> I've no idea what people expect right clicking a delete link to open in a new tab to do?
I expect it to issue the delete, and then dump the response to the delete into a new tab rather than navigating away from the page that hosts the delete link.
There might be ten other delete links on the original page, and I don't want to delete-back-delete-back-delete-back, when I can just open all of them in a new tab, then go through the tabs to look for errors.
That sounds like the right behaviour to me, although there is an arguably nasty non-idempotence. Click it the first time and you get a DELETE response. Click it the second time and you get a 404.
Yes, but application developers have long faked it using GET .../thing?op=DELETE
When you get sick of faking it you look into why there is no way to get browser to send real DELETEs and PUTs and w3c verbiage says "because application developers don't seem to need it" ... because they fake it ... because they have to fake it ... because browser don't do it ... because devs don't need it ...
I was gonna write a snarky comment about using a <button formmethod="DELETE"> but apparently, the only methods allowed on a <form>s and <button>s are GET and POST.
I wonder why these limitations. Especially since you can get past this with an:
Though as dragonwriter points out, using a button+POST to fake a delete is much better than using a link.
Api-wise that's a reason to mux your puts and deletes in the POST handler and not in the GET handler, since it force the HTML to use buttons rather than links that might get crawled.
I don't care about minor cases like that. I'm talking about things like a CMS not letting you open a post in a new tab because they wanted to load the post via Ajax and failed to provide a fallback.
Really egregious examples even change the location so that I can copy the URL after clicking, new tab, paste, and hit back in the original, but I can't middle click for a new tab.
I've no idea what people expect right clicking a delete link to open in a new tab to do?