I am just now realizing that HN comments are collapsible...I wonder if anyone has ever looked at upvote/scroll behavior when the collapse button is used vs not? There are a ton of threads where the top comment is also a non-sequitur, but I know when that happens I frequently don't scroll past the hundreds of replies to see what the other first level comments are.
Okay. I'll bite. What is everyone talking about ? I see an upvote triangle, a down vote [-] and nothing else. Is this a mobile only thing ? I can't see a way to collapse comments under Chrome or Safari on a desktop. I am out of the loop what's the secret ?
[-] is not a downvote button, but the collapsing one.
Okay. I'll bite. What is everyone talking about ? I see an upvote triangle, a down vote [-] and nothing else. Is this a mobile only thing ? I can't see a way to collapse comments under Chrome or Safari on a desktop. I am out of the loop what's the secret ?
[-] is not a downvote button, but the collapsing one.
I would use the tag to solve this problem. Most people don't know this exists and I have no idea why. You would probably have to rewrite the html so it no longer uses tables but I don't really consider that to be a negative. I would also question why we are saving collapsed comments. I feel like this is something that doesn't need to be persisted forever. If you want this behavior why not use local storage instead?
I tried ctrl+f on text inside collapsed details and it didnt show up. I would have expected that with correct semantics, the browser would have figured out that it should expand the details and highlight that text.
Its also missing a group name, so I can expand only one details of a group.
I would use the tag to solve this problem. Most people don't know this exists and I have no idea why. You would probably have to rewrite the html so it no longer uses tables but I don't really consider that to be a negative. I would also question why we are saving collapsed comments. I feel like this is something that doesn't need to be persisted forever. If you want this behavior why not use local storage instead?
I tried ctrl+f on text inside collapsed details and it didnt show up. I would have expected that with correct semantics, the browser would have figured out that it should expand the details and highlight that text. Its also missing a group name, so I can expand only one details of a group. Why is it useful?
This is a really good point. The lack of searchability of the collapsed text makes this pretty useless for comments. Please consider this when thinking of using it anywhere.
It's also an issue when you don't even fully control the client, which in this case is the web browser. A game at least behaves exactly as you program it. Browsers are not necessarily consistent, especially when you throw in extensions.
Yes excellent point. Some browsers/plugins will prefetch every GET on the page to speed up browsing.
In the Hacker News case there isn't a GET request on the page, it's triggered by the javascript so this would not happen
Following the rules of REST is very important if you are presenting a public API to the world. If it's your own server you can do whatever you want. For example I used to work on servers for games and often there would be a single endpoint for processing one or more commands, and this would be technically a GET request regardless of what those commands did. Furthermore it's common to send application level error deta…
As you say it will work just fine as long as your client and server agree, but free-wheeling it with the HTTP spec can come with operational drawbacks. I've worked with a lot of different internal webservices as a freelancer, and if they're reasonably RESTful and built according to spec, it's easy to just get started with the codebase. Ones like you're describing mean a lot more conversations and reading through code…
I absolutely agree with your points, and that's good advice as long as your application works by modifying resources of a single type with each request. In my specific case we wanted to reduce round trips to the server by using compound commands that may do multiple things on the backend, affecting multiple entity types that would have to be, in rest, a resource. Also in our case my team was responsible for the client and the server, and the commands/responses are clearly documented for everyone to see.
Following the rules of REST is very important if you are presenting a public API to the world. If it's your own server you can do whatever you want. For example I used to work on servers for games and often there would be a single endpoint for processing one or more commands, and this would be technically a GET request regardless of what those commands did. Furthermore it's common to send application level error deta…
> If it's your own server you can do whatever you want. This is not at all true. For example, say I'm a user in a dorm that uses a proxy that I have no control over. If you make your GET request modify things, that proxy may cache the request, or worse, may repeat the request later to maintain its cache. My point is, you don't know what is between your server and their client, and even well behaved infrastructure wil…
There are ways to make sure that your GET requests are not cached. For example in the case we're talking about here the server sets that URI to have "Cache-Control: private; max-age=0". Now sure, a proxy could simply ignore HTTP protocol and cache it anyway, but that would break a lot of things and AFAIK is not seen often in the wild. Certainly in the case of the applications I worked on we did not have customers that reported connection difficulties over HTTP.