4 ms·

Why?

by ashark 9y ago

Why?

wvenable 9y ago
Every upvote would refresh the whole page.
- ashark 9y ago
  See discussion in this thread about the "204 No Content" response code. Not all successful HTTP requests trigger a page load. And that's without having to change anything about current HTTP/HTML—except maybe giving hyperlinks and/or forms access to more HTTP methods, though for god's sake we ought to already have that in HTML and if you'd told me in 2007 that in 2017 we still wouldn't be able to PUT or DELETE on a web page without Javascript I'd have laughed at how implausible that was, so that's a long-overdue change anyway.
  - wvenable 9y ago
    You'd have way no indicate that your upvote succeeded with a 204 status code. Going back to my original point, and what you're arguing for me here, is that do this properly you'd have to imagine and implement every possible use case. In 1993, nobody envisioned web pages like Reddit. And yes, without JavaScript the web would be much faster and much safer but also much less interesting and powerful. It's hard to imagine websites without simple upvote/downvote mechanisms but that's what you're asking us to do. And that's just one tiny feature that barely scratches the surface of what is possible.
    - ashark 9y ago
      We had working voting systems before AJAX (source: I have a high-but-now-considered-lowish Slashdot ID) so we can do it. Besides, visited link state seems like it'd resolve the problem, and it's been in HTML approximately forever. I still don't see the problem. The rest of what's possible can go on the current web, which would hopefully optimize (even more) for delivering apps if that happened. I want a content reader that won't, in practice, often run malicious code when I point it at the wrong document. That means it must not be able to run scripts, or at least not scripts that can communicate with the outside world in any way, at which point you may as well save the disk, memory, and complexity by leaving scripting out. There's no reason the thing I browse Craigslist, Wikipedia, IMDB, and Facebook and Twitter for that matter on must also be able to run ports of Wolfenstein or Excel clones or whatever. Or chat clients. The loss of trust and predictability in ordinary web browsing that scripting and complex layout systems bring aren't worth it. Put them somewhere else (including right where they are now—that'd be fine. Move the web to something more suited to it and leave the apps on the current "web")
      - wvenable 9y ago
        I have a site that delivers content, forums, and maybe even a few application-like features all in one. Why have two systems when one system can do all that? It'll simply never happen. The web killed gopher. The web killed NNTP. The web has almost killed email. What you described has existed and been killed off a half-dozen times already. I'm not against having more user-protection features (heck, I have a number of plugins installed to do just that) but limiting usability and creativity is the wrong approach. It's been done and it always fails.
        ashark 9y ago
        I'd be OK with keeping both in the same client, with warnings when transitioning from one to the other (say, you follow a link on a web page to a web app), if that's what it took. It'd be like the HTTPS lock and content-origin policies and such but for guaranteeing the page you're visiting isn't actually a "page" that's spying on you and doing all kinds of other nasty stuff, or that the link you're following may go to a page that's a god-awful pain in the ass to read and burns your battery up ("modern" designed web articles). Like a not-shit version of Google's AMP, kinda. It'd be better separate if that worked out—if all the things that work just fine without JS and advanced CSS went to the New Web I'd be able to arrange things so I rarely need anything else. Web apps blow and I try to avoid them when possible, or, increasingly, they're better off in Electron for reasons including that it's quicker to get to them to murder them mercilessly when they go rogue, than it is with some tab somewhere. But a unified client for both that kept them strictly separate would at least be a lot better than what we have now.
        wvenable 9y ago
        Everything you describe is a usability nightmare including "with warnings when transitioning from one to the other". You might not use any web applications but major web applications are the most used sites on the web. Would it not be better to provide full functionality and simply use better sandboxing to avoid spying and nasty stuff? Reducing functionality is like throwing the baby out with the bathwater -- you really want better privacy and more control but rather than attack that problem you want to take the web back 20 years. That's a solution but it's not a very good one. I personally don't think that browsers shouldn't leak all the information that they do -- that should be a hole to be plugged.
    - niftich 9y ago
      > 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
  - dragonwriter 9y ago
    > See discussion in this thread about the "204 No Content" response code. HTTP is not the problem, the problem is knowing how to update the rendered page once the upvote happened (which, sure, could be communicated to the browser by a 204.) JS is what does that now; what does that without JS?

Why?

by ashark 9y ago

Why?

wvenable 9y ago

Every upvote would refresh the whole page.

ashark 9y ago
See discussion in this thread about the "204 No Content" response code. Not all successful HTTP requests trigger a page load. And that's without having to change anything about current HTTP/HTML—except maybe giving hyperlinks and/or forms access to more HTTP methods, though for god's sake we ought to already have that in HTML and if you'd told me in 2007 that in 2017 we still wouldn't be able to PUT or DELETE on a web page without Javascript I'd have laughed at how implausible that was, so that's a long-overdue change anyway.
- wvenable 9y ago
  You'd have way no indicate that your upvote succeeded with a 204 status code. Going back to my original point, and what you're arguing for me here, is that do this properly you'd have to imagine and implement every possible use case. In 1993, nobody envisioned web pages like Reddit. And yes, without JavaScript the web would be much faster and much safer but also much less interesting and powerful. It's hard to imagine websites without simple upvote/downvote mechanisms but that's what you're asking us to do. And that's just one tiny feature that barely scratches the surface of what is possible.
  - ashark 9y ago
    We had working voting systems before AJAX (source: I have a high-but-now-considered-lowish Slashdot ID) so we can do it. Besides, visited link state seems like it'd resolve the problem, and it's been in HTML approximately forever. I still don't see the problem. The rest of what's possible can go on the current web, which would hopefully optimize (even more) for delivering apps if that happened. I want a content reader that won't, in practice, often run malicious code when I point it at the wrong document. That means it must not be able to run scripts, or at least not scripts that can communicate with the outside world in any way, at which point you may as well save the disk, memory, and complexity by leaving scripting out. There's no reason the thing I browse Craigslist, Wikipedia, IMDB, and Facebook and Twitter for that matter on must also be able to run ports of Wolfenstein or Excel clones or whatever. Or chat clients. The loss of trust and predictability in ordinary web browsing that scripting and complex layout systems bring aren't worth it. Put them somewhere else (including right where they are now—that'd be fine. Move the web to something more suited to it and leave the apps on the current "web")
    - wvenable 9y ago
      I have a site that delivers content, forums, and maybe even a few application-like features all in one. Why have two systems when one system can do all that? It'll simply never happen. The web killed gopher. The web killed NNTP. The web has almost killed email. What you described has existed and been killed off a half-dozen times already. I'm not against having more user-protection features (heck, I have a number of plugins installed to do just that) but limiting usability and creativity is the wrong approach. It's been done and it always fails.
      - ashark 9y ago
        I'd be OK with keeping both in the same client, with warnings when transitioning from one to the other (say, you follow a link on a web page to a web app), if that's what it took. It'd be like the HTTPS lock and content-origin policies and such but for guaranteeing the page you're visiting isn't actually a "page" that's spying on you and doing all kinds of other nasty stuff, or that the link you're following may go to a page that's a god-awful pain in the ass to read and burns your battery up ("modern" designed web articles). Like a not-shit version of Google's AMP, kinda. It'd be better separate if that worked out—if all the things that work just fine without JS and advanced CSS went to the New Web I'd be able to arrange things so I rarely need anything else. Web apps blow and I try to avoid them when possible, or, increasingly, they're better off in Electron for reasons including that it's quicker to get to them to murder them mercilessly when they go rogue, than it is with some tab somewhere. But a unified client for both that kept them strictly separate would at least be a lot better than what we have now.
        wvenable 9y ago
        Everything you describe is a usability nightmare including "with warnings when transitioning from one to the other". You might not use any web applications but major web applications are the most used sites on the web. Would it not be better to provide full functionality and simply use better sandboxing to avoid spying and nasty stuff? Reducing functionality is like throwing the baby out with the bathwater -- you really want better privacy and more control but rather than attack that problem you want to take the web back 20 years. That's a solution but it's not a very good one. I personally don't think that browsers shouldn't leak all the information that they do -- that should be a hole to be plugged.
  - niftich 9y ago
    > 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
- dragonwriter 9y ago
  > See discussion in this thread about the "204 No Content" response code. HTTP is not the problem, the problem is knowing how to update the rendered page once the upvote happened (which, sure, could be communicated to the browser by a 204.) JS is what does that now; what does that without JS?