Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> There's also simply no reason to change it, it works.

It works, and it's arguably simpler than the div-soup with extensive styling, which is the "kosher" way of doing this.



Well using divs would at least make you able to group the elements semantically so you could remove a single node rather than having a for loop which removes exactly three nodes. This would be significantly simpler in my opinion. And it would be less fragile since now you can redesign everything inside this node without the JavaScript breaking.


Agreed. But getting divs to do what you want has also gotten considerably easier in the last 10 years. It used to be a lot more work/boilerplate to get a consistent div-based layout across all browsers down to IE 6.

As for the redesign, the total amount of code (HTML/CSS/JS) you’d need to touch is still small. Do web designers still exist that only do HTML/CSS but no JS?


> Do web designers still exist that only do HTML/CSS but no JS?

I hope so, given that most websites (as opposed to web apps) in existence should not need JS for core functionality.


> Do web designers still exist that only do HTML/CSS but no JS?

That is really beside the point. HTML and JS should not be coupled to the extent that adding or removing some whitespace from the HTML will cause the JS to fail. This kind of things turns a trivial improvement into a nightmare, so you end up not daring to change anything.


I expect the layout would also be simpler in another way: Give every "child" div a static indentation, nothing more. They'll nest and the indentation will stack the deeper the comments go.

Right now there's already nested tables-within-tables, just to work around how table columns work in order to handle indentation (and each row's indentation is handled separately with a stretched 1x1 image with a width attribute that's calculated server-side).


Or better still, use the HTML elements whose sole purpose is to display nested content: <UL> and <LI>


I'd argue it's far from ideal. Mainly because closing a large tree of comments can often hang the UI for a second or so while this JS runs to find and hide all the children that need to be hidden.

But it is simple, and it does get the job done for the most part.


It's true that the code is slow on large threads. That's on our list to fix. The last time I profiled it, it was (surprisingly to me) forEach that showed up as the culprit.


I figured, and to be honest it's not that big of a deal. I swear it used to be much worse when the collapsing comments first came out, but as I made that comment I realized that I actually had trouble triggering it.

Either way, it's a minor annoyance on an otherwise fantastic site!


Guys, it's 2018. Let's not have this conversation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: