
Interactive HTML Trees with No JavaScript - edent
https://shkspr.mobi/blog/2020/08/interactive-html-trees-with-no-javascript/
======
p4bl0
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.

~~~
c8g
[https://webcache.googleusercontent.com/search?q=cache:tOB1K9...](https://webcache.googleusercontent.com/search?q=cache:tOB1K9m_8CAJ:https://shkspr.mobi/blog/2020/08/interactive-
html-trees-with-no-javascript/+&cd=1&hl=en&ct=clnk&gl=bd&client=ms-android-
vivo)

------
lucasmullens
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.

~~~
galoisgirl
> 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](https://www.w3.org/TR/wai-aria-practices-1.1) , find the widget
or scenario you need and do as they say. Win-win.

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

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

[https://www.grc.com/menudemo.htm](https://www.grc.com/menudemo.htm)

~~~
Grumbledour
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/](https://www.htmldog.com/articles/suckerfish/dropdowns/)

------
ironmagma
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.

~~~
conradludgate
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

~~~
ironmagma
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.

~~~
anoncake
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.

~~~
xg15
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.

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

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

~~~
WorldMaker
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.

------
kgwxd
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.

------
kgwxd
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.

------
aitchnyu
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?

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

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

~~~
kgwxd
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](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.

~~~
stefanfisk
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.

------
swagasaurus-rex
The link appears down

------
tomschwiha
Anyone tested how E-Mail clients display those tags?

------
The_rationalist
What about performance?

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

