Another way is to use the checkbox-and-CSS trick. You add a hidden checkbox next to the element you want to hide, add a label to trigger the checkbox, and then use a + selector to toggle the visibility based on the state of the checkbox. Like this:

    <label for="spoiler">Toggle spoiler</label>
    <input type="checkbox" id="spoiler"/>
    <div id="spoilerContent">Spoilery stuff goes here</div>
    <style>
    #spoiler, #spoilerContent{display: none;}
    #spoiler:checked+#spoilerContent{display: block;}
    </style>

You can also use a variation of this for tabs - just use radio buttons instead - and accordions.

IIRC that will mess up screenreaders though. The detail tag is specifically made for this sort of thing and is therefore almost certainly more accessible.

And accessibility trolls are hot right now.

I hope my fellow HN readers never need an accessibility troll to advocate on their behalf.

Yes. But I believe details / summary is considered more accessible. Since its in the spec it's something AT has or is working towards.

It be more correct to say what grishka said above: "that will mess up screenreaders though"

But if it's more accessible depends on the target user. If you're target are IE users or users with very old browser versions, for one reason or another, more accessible would be to use the CSS toggle trick. But if indeed your target user are users using screenreaders and using recent browsers, then details and summary elements would be more accessible.

A bit anal, but important to consider when talking about accessibility, it's very context sensitive.

Accessibility is specifically about making things accessible to those with disabilities. Unless you are making a joke about the intelligence IE users or those using old browsers, accessibility isn't about maximizing potential reach.

Accessibility is often thought of as just making things accessible to people with disabilities, but it's not just that. Accessibility is mainly about maximizing the reach, not just for people with disabilities but people in any situation.

For example, people who live in South America usually have a lot worse internet connection, and more likely to be on mobile networks, than people in the west. If you're audience is mainly in South America, working on making your application accessible, means making sure your application has low bandwidth usage, can deal with high latency and jitter, and works well for phones.

One only has to look at the definition of the word "Accessibility" to see why you're wrong: "accessibility - the quality of being able to be reached or entered - the quality of being easy to obtain or use - the quality of being easily understood or appreciated".

Not sure where the focus on people with disabilities came from, it's important, but accessibility is much bigger than just that.

> Not sure where the focus on people with disabilities came from

You are right, accessibility _can_ take into account degraded environments, but if you don't know why disabilities are focused on, that suggests to me you are philosophizing on the word, and not addressing actual technical standards that have been put in place. Just google it

"Just Google it" doesn't scream curious conversation exactly.

Your argument was "Accessibility is specifically about making things accessible to those with disabilities" which by no definition of the word, is true. Look it up.

Not sure why I'd have to read the various specifications again when I've already done that. I'm still of the same impression (like most others) that accessibility is much bigger than just making things work for those with disabilities.

What's IE? ;)

Thanks!

It even works in GitHub Markdown: I use it to put long code snippets/examples into a fold.

Oh no way. Going to have to use this

Somehow it takes 4 seconds to un-collapse a toplevel comment in Chrome. E.g. this one: https://teddit.net/r/Bossfight/comments/k6vh5v/bearers_of_th...

Pages also seem to take around 10 seconds to do the initial render. No server problem, just rendering.

So if you do use this, I guess don't overdo it. :) Or at least profile.

I use a 2015 MBP potato laptop. I guess my perf problems aren't really relevant. But it handles all modern sites just fine, so it was surprising.

Definitely spikes something to 100% on each load: https://i.imgur.com/1fqBDEX.png and the CPU graph is a nice timeline of me reloading teddit.

EDIT: Oof. I just did a profiling session to figure out what the heck it was doing:

https://imgur.com/ilvRkEb

Purple = rendering time. As you can see, it's 100% pegged at rendering whenever I uncollapse a thread.

So, devs, if you happen to read this, the process is:

1. go to https://teddit.net/r/Bossfight/comments/k6vh5v/bearers_of_th...

2. Collapse the toplevel comment https://imgur.com/vjDhTk2

(which is very fast.)

3. Activate a profiling session: Command-option-I, click performance tab, command-E to start recording

4. Un-collapse the thread

5. Stop recording

Here's the profiling session in case it helps: https://battle.shawwn.com/misc/2020-12-04/Profile-20201204T1... No idea if it gives any insight into what's going on, but there y'go.

I'm not sure how they'd solve this. 98.2% of the time is spent in "Layout": https://i.imgur.com/tSexr0n.png

Is there even anything you can do to address that kind of perf problem? Yuck. I don't envy whoever digs into that one.

I tried profiling with "Enable advanced paint instrumentation (slow)" but it seemed to show exactly the same result:

https://i.imgur.com/V26oOTT.png

"Nodes That Need Layout 3841 of 3987 Layout root#document" seems relevant. So it sounds like the details card is somehow causing a full-page layout for almost every element on the page. Which should be fast, except that every element seems to cause another layout. Or ... something.

Not sure if there's any other details I could give, but let me know if anyone has ideas.

fwiw, it's instantaneous for me on a 2016 laptop running Firefox on Linux w/ Xorg and nVidia. No fans even spin up (and this is an HP, and we all know how much HP fans like to spin.)

https://imgur.com/a/BjRqAs2

On my 2013 macbook pro running Firefox 83 it spends about ~130ms in "layout" when expanding the comments (quick enough to be almost imperceptible).

https://imgur.com/a/nV14ybI

Seems to be a Chrome-only issue?

Instantaneous on FF, old samsung S7

Dev here. This is a known issue. https://codeberg.org/teddit/teddit/issues/24

So far I haven't come up with any solution. The nested .comment styles seemed not be the problem. Although something in the CSS triggers the slow rendering on Chromium based browsers – not sure yet what.

If any of you have an idea, leave a comment here or in Teddit, appreciated!

EDIT: Oh, forgot to say: Works fine in Firefox, no rendering issues.

Any reason not to use flex instead of float?

Habits. Haven't updated my CSS skills as much as I would've wanted along the years. I'm mostly writing CSS like it's year 2010.

Hmm. Not related to the issue you mention, but also on that page, when I click a "Load more comments" link, it takes me to https://teddit.net/r/Bossfight/comments/k6vh5v/bearers_of_th... , a webpage that just says "Cannot GET /r/Bossfight/comments/k6vh5v/bearers_of_the_eternal_duel/genbcos/genr9x6".

On Linux instantaneous in Firefox (78.5.0), takes forever in Chrome (87.0.4280.66) while using 100% of one CPU core/thread (I killed the tab after ~1 minute).

chrome potato here. seems approx. 6 seconds for collapsing any that i've clicked.

Working around Chrome's bugs just disincentivizes Google from fixing them.

Is it `details` [1] instead of `detail`?

1. https://css-tricks.com/quick-reminder-that-details-summary-i...

Yes, that's how I do it on littr.me (a federated link aggregator).

[edit] An example: https://littr.me/moderation