5 ms·
CSS is needed because this app isn't using HTML forms to send the data. That would be easier, but part of the magic here is that in addition to no JavaScript, t
by kyle-rb 3y ago
CSS is needed because this app isn't using HTML forms to send the data. That would be easier, but part of the magic here is that in addition to no JavaScript, the page also never reloads.
The readme explains how the CSS :active selector is used to detect button presses.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- ComputerGuru 3y agoI mentioned multipart/x-mixed-replace above and I think it can work here instead of CSS. You never reload the chat history page, just put that in an iframe and use a separate iframe with a form that submits your newest reply. Edit: actually this should work even without mixed replace.
- remram 3y agoWhen the form submits its frame refreshes ("navigates").
- ComputerGuru 3y agoRight but reloading a static html asset (the reply iframe consisting of just a textbox) is basically free. So long as you separate the chat history window and the reply textbox/form into two separate frames, I don’t see the problem.
- croshan 3y agoUsing JavaScript is also “basically free”. There’s no problem with either listed approach, GP just seems to consider a method without page reloads as adhering to a harder constraint.
- weird-eye-issue 3y agoUsing JS would have broken the threat model of the dark web chatroom. So it is a non starter in that context.
- bawolff 3y agoI thought chrome killed x-mixed-replace (except for jpg images)
- ComputerGuru 3y agoMentioned above: https://news.ycombinator.com/item?id=36545326 https://news.ycombinator.com/item?id=36545326
- p4bl0 3y ago> the page also never reloads Well, that's really only technically correct, since the strategy here is to replace the whole page with a new version of it on each virtual keypress, by using CSS to hide the previous HTML and then receiving the new updated version of the web page's content. The only tricks is to use a chunked content-transfer to have this all happen over a single HTTP request, so yes technically the page does noes reload, but it's pretty much the same thing as if it did. Really cool trick nonetheless! And more importantly fun trick, and fun read :).
- pcthrowaway 3y agoI think it'd at least eliminate some of the overhead with establishing new connections on every request with HTTP/1.1 or HTTP/2, but I'm not sure about HTTP/3