Interactive HTML Trees with No JavaScript | Hacker News Reader

Interactive HTML Trees with No JavaScript

shkspr.mobi

46 pointsedent30 comments

The linked blog post seems to have been deleted. At the time I'm writing this, the links has been pointing to a 404 error page for a few minutes already and the article is nowhere to be found in the blog's archive.

https://webcache.googleusercontent.com/search?q=cache:tOB1K9...

Right now it loads for me.

I'm not sure why the article mentions accessibility as a downside to this approach. If you use details/summary, it probably has some default behavior in screen readers to explain that it's collapsable. The alternative of using some show/hide element with an onClick handler probably doesn't work as well for screen readers without a bunch of aria tags.

It breaks the intended semantics of the <details> and <summary> elements though: A post is not a summary of its replies.

So screen readers which rely on these semantics could cause confusing behaviour.

> it probably has some default behavior in screen readers to explain that it's collapsable.

Yes, and it reads leaves as collapsed, the user expands them and there's nothing there. That's confusing.

> The alternative of using some show/hide element with an onClick handler probably doesn't work as well for screen readers without a bunch of aria tags.

Yeah, `aria-expanded` (you need an expanded CSS class anyway) and maybe `aria-owns`. Titanic work.

The cool thing about accessibility is that you have to think a lot less. You just open https://www.w3.org/TR/wai-aria-practices-1.1 , find the widget or scenario you need and do as they say. Win-win.

What do you mean by "the user expands them and there's nothing there"?

It's also possible to implement drop-down menus using CSS, with zero JavaScript.

https://www.grc.com/menudemo.htm

It is and there is no reason not to do it this way just because it has been around for a long time.

However, for accessibility reasons, Son of Suckerfish[0] works a bit better. It moves hidden items out of the viewport instead of using display: none, thus making the menu usable to screenreaders users without them having to "hover". It would of course also be advisable, to expand the :hover to also inlclude :focus.

[0] https://www.htmldog.com/articles/suckerfish/dropdowns/

...and that works all the way back to at least IE6.

This is a good example of a JavaScript-phobic treatment of webdev to no ends other than the abuse of HTML tags. There is a use case for JavaScript, and this is it.

Personally I think this solution is simpler and easier to implement than using js. This isn't really an abuse. This seems exactly what these tags were intended for

It says it in the article:

> WARNING! This is a misuse of these HTML elements. While it is valid markup, it may not be accessible. This is an experiment and not intended for production use.

Seems an overly cautious warning. The spec seems to indicate that the only "semantic" meaning to these elements is "I have content or controls I wish to show/hide" and the accessibility guarantee is "allow the user to show/hide details". It sounds perfectly cromulent use.

Could even default the details to shown with the "open" attribute and still meet the spec-detailed description as the affordance there is that it can then be hidden.

DETAILS spec: https://html.spec.whatwg.org/multipage/interactive-elements....

Then what is the correct use for them? If it's valid markup, used for the correct purpose, accessibility is the responsibility of the browser.

The correct use is for the <summary> element to be a summary of the rest of the block. This is not the case in threaded conversations.

Is the title of a thread not a summary of that thread?

This is not about the title but about a post and its replies though.

But in most "threaed forum" examples, including several in the article, such as HN or Reddit, the post contents would be in the body of the DETAILS and the SUMMARY for when minimized is just the title or a summary of how many comments are below. This article isn't suggesting putting the whole post in the SUMMARY, though the given example doesn't likely make that clear because it isn't a full example.

Trees and tables that can scroll and freeze like Excel should have been made standard decades ago. I'm so sick of having to find a third-party component for the framework-of-the-month every time I start a new project.

I'm on MDN browsing the game development section because of the front page MDN story. I noticed they have a tree menu, so I was curious what they were using. It's exactly this.

I wish the text in a collapsed <details> would show up in the browser's ctrl+F search. Why didnt Firefox and Chrome implement this yet?

Sorry, the page you requested cannot be found. These are not the blogs you're looking for…

That just ugly. I'd just go with something like this: http://experiments.wemakesites.net/css3-treeview.html

It can be styled. Does the tree menu on the left of this page look ugly: https://developer.mozilla.org/en-US/docs/Games/Introduction

It's not nested but I'm sure it could be made to look just as good if it was.

Edit: That link you gave looks pretty nice though, I'm actually in need of a tree view today, I might try that.

I'm sorry that I was unclear. I found it technically "ugly", as far as styling goes I'd assume that any solution could be made as pretty as needed.

The `:checked` stuff also works great for accordions and whatever else is toggled, I use it all the time.

The link appears down

Anyone tested how E-Mail clients display those tags?

What about performance?

I’m sorry to say, but there’s nothing new here.

Reply on news.ycombinator.com