On 06/08/2025 17:24, Christian Moe wrote:
Ihor Radchenko writes:
And that firefox bug has been fixed and "Added to the Fx139 relnotes."
So, we can make use of #+begin_details ... #+end_details if we enable
fancy HTML5 export for WORG.
Finally I have tried it. I can confirm that Firefox-140 ESR opens
details on search initiated in UI and for scroll to text link anchors
(#:~:text=... By the way, it should be supported by ox-html for ::search).
However since this thread started, I had to visit some sites demanding
users to click to read next couple of paragraphs. I find it annoying
even when there are no strict accordions and several entries may be
opened simultaneously. Sometimes I used DOM inspector to disable some
CSS rules and to reveal all text at once (when it is implemented without
<details> and when hidden text is not obtained through XHR on click).
Side note: it might be an idea for a browser extension "broke accordion"
- reveal all hidden text.
I prefer to have meaningful text readable by default, so I can just
scroll without clicking to skim though a page. That is why I am against
<details> for FAQ.
Workarounds for long table of contents are skip links
<https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a#skip_links>
for keyboard users and some trick to close TOC by default for narrow
screens of mobile devices.
Some FAQ entries may be extracted to dedicated Worg articles. The
question is directory structure for them.
A bit nicer:
#+macro: summary @@html:<summary>$1</summary>@@
#+begin_details
{{{summary(I have keys but no doors. I have space but no room. You can
enter but can’t leave. What am I?)}}}
A keyboard.
#+end_details
I anticipate text trimmed by commas that are not properly escaped.
We already have several types of frequently appearing errors like
absolute paths in "file:" links to parent directories.
