4 ms·

> You'd have way no indicate that your upvote succeeded Sure you do. 204 No Content for success, 4xx for an error that you (or your browser) can fix, and 5xx f

> You'd have way no indicate that your upvote succeeded Sure you do. 204 No Content for success, 4xx for an error that you (or your browser) can fix, and 5xx for an error that only the server can fix.

wvenable 9y ago
Still horrible usability; you've taken me away from what I was doing to show me an error page.
- niftich 9y ago
  There is no rule in HTTP that mandates the user-agent must navigate away from what it's currently displaying to show you the payload of an HTTP error. It simply says [1] that the error "SHOULD" (in the RFC 2219 meaning of SHOULD [2]) be displayed to the user. Because of this, most browsers display the payload, but some show a built-in "friendly" error page if the payload is under a certain size. Because of the language in the spec, the server can't rely on any particular behavior. If it reliably knew that user-agents always display the payload, the body of the 4xx or 5xx response could contain the exact HTML of the page you were just on, with the details of the error spliced in. Understandably, few people do this. In late 1990s, early 2000s browsers, a status bar was commonplace which tended to show parsing errors, script errors, and other errors the user probably couldn't fix; nowadays these notifications have been moved to the console or log and are hidden from non-power users. A HTML form property could be used to signify that the form be submitted out-of-band, and have the results logged instead of updating the document view. With HTML5, they introduced the 'async' tag to allow linked assets to load without blocking rendering, so conceivably the same mechanism could be used to mark forms, if any user-agent were interested in supporting it. The point is, extremely minor changes could improve usability in this particular case, using semantics that aren't breaking new ground at all, but quite simply no one has done it. [1] https://tools.ietf.org/html/rfc7231#section-6.5 https://tools.ietf.org/html/rfc7231#section-6.5 [2] https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119
  - wvenable 9y ago
    None of this is necessary if you have JavaScript to control the error handling exactly the way you want. If it's a critical problem, you can display an error message. You can retry behind the scenes and succeed without even having to inform the user of a failure. Again, I make the point that a pure declarative solution only works if you know every possible use-case. You can add all kinds of new tags and attributes that could possibly exist to solve the one problem you imagine right now and that still won't be enough.
    - niftich 9y ago
      Completely agree. Declarative approaches define the palette of available options ahead of time, but if wish to do something out-of-scope, it's back to the drawing board. Imperative approaches instead give you a low-level computation environment, and hooks into manipulating the outside world. Most facets of the original Web are declarative: HTTP is a complex state machine, HTML is a declarative language, hyperlinks are declarative ways of specifying outgoing edges of a node in a graph. Javascript enhanced that with imperativeness, which is why it's been leveraged to extend the Web in new ways -- ways that are ad-hoc reimplementations of behaviors that have not (yet) been otherwise codified.

wvenable 9y ago

Still horrible usability; you've taken me away from what I was doing to show me an error page.

niftich 9y ago
There is no rule in HTTP that mandates the user-agent must navigate away from what it's currently displaying to show you the payload of an HTTP error. It simply says [1] that the error "SHOULD" (in the RFC 2219 meaning of SHOULD [2]) be displayed to the user. Because of this, most browsers display the payload, but some show a built-in "friendly" error page if the payload is under a certain size. Because of the language in the spec, the server can't rely on any particular behavior. If it reliably knew that user-agents always display the payload, the body of the 4xx or 5xx response could contain the exact HTML of the page you were just on, with the details of the error spliced in. Understandably, few people do this. In late 1990s, early 2000s browsers, a status bar was commonplace which tended to show parsing errors, script errors, and other errors the user probably couldn't fix; nowadays these notifications have been moved to the console or log and are hidden from non-power users. A HTML form property could be used to signify that the form be submitted out-of-band, and have the results logged instead of updating the document view. With HTML5, they introduced the 'async' tag to allow linked assets to load without blocking rendering, so conceivably the same mechanism could be used to mark forms, if any user-agent were interested in supporting it. The point is, extremely minor changes could improve usability in this particular case, using semantics that aren't breaking new ground at all, but quite simply no one has done it. [1] https://tools.ietf.org/html/rfc7231#section-6.5 https://tools.ietf.org/html/rfc7231#section-6.5 [2] https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119
- wvenable 9y ago
  None of this is necessary if you have JavaScript to control the error handling exactly the way you want. If it's a critical problem, you can display an error message. You can retry behind the scenes and succeed without even having to inform the user of a failure. Again, I make the point that a pure declarative solution only works if you know every possible use-case. You can add all kinds of new tags and attributes that could possibly exist to solve the one problem you imagine right now and that still won't be enough.
  - niftich 9y ago
    Completely agree. Declarative approaches define the palette of available options ahead of time, but if wish to do something out-of-scope, it's back to the drawing board. Imperative approaches instead give you a low-level computation environment, and hooks into manipulating the outside world. Most facets of the original Web are declarative: HTTP is a complex state machine, HTML is a declarative language, hyperlinks are declarative ways of specifying outgoing edges of a node in a graph. Javascript enhanced that with imperativeness, which is why it's been leveraged to extend the Web in new ways -- ways that are ad-hoc reimplementations of behaviors that have not (yet) been otherwise codified.