[recursivedoubts]

This is a very good example where the HTML extensions that alex proposed here:

https://www.youtube.com/watch?v=inRB6ull5WQ

(TLDW: allow buttons to make HTTP requests; allow buttons & forms to issue PUT, PATCH & DELETE; allow buttons, forms & links to target elements in the DOM by id instead of only iframes)

would improve the web platform. You could have a stand-alone logout button that issues a DELETE to /session or whatever. Nice and clean.

[williamdclt]

I mean, it should just be a submit for a form with a /logout POST action. It’s standard and what web devs have been doing for decades

[recursivedoubts]

Yeah, the problem is that it requires a form, which has layout implications w/o styling and POST is not idempotent, whereas a logout operation typically is idempotent. Being able to issue a DELETE to a URL like /session from an element that doesn't have layout implications would be ideal.

[de46le]

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it.

  <button form="logout-form" ...>logout</button>
  <form name="logout-form"></form>

No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

[recursivedoubts]

doable but rarely used, inconvenient and awkward, alex proposes allowing buttons to be stand-alone hypermedia controls which also allows multiple buttons located within a form to perform different actions (e.g. save v. cancel)

[de46le]

Oh for sure, standalone elements would definitely be better, I just wanted to point out that there's a way around needing to do silly stuff like <form class=blabla>

Though in my experience, it's great in frameworks like svelte. Define your forms at the top of the component, and you can see at a glance what native actions the component can do, and where it posts to.

[williamdclt]

> POST is not idempotent

It certainly can be, there’s just no _requirement_ that it is idempotent. There’s no problem with having an idempotent POST operation.

I’m also not a fan of a DELETE /session option, the client shouldn’t have to care about the concept of “session”, it’s the server’s problem. But I’m not a fan of resource-based endpoints in general, I tend to prefer task-based endpoint so /logout makes more sense to me.

Also, even if it was possible to trigger DELETE in html it probably would be implemented as a form. Not really a problem, making a form element inline is trivial, and probably needed in various parts of an app (any button that changes some state)

[recursivedoubts]

right, but the browser doesn't know that and so it has to treat the operation as if it were not idempotent (i.e. warn on a resubmit)

You second paragraph indicates that you do not like the REST pattern of the web, which is fine, but i hope you can appreciate that some of us would like the web as the web to make it possible to abide by that pattern

the last point is addressed in Alex's proposal to allow buttons to function as stand-alone hypermedia controls