Originally we were using Foundation's sticky, which wasn't entirely
compatible with our way to open/close the Table of Contents because its
width would not automatically be updated when the TOC was opened/closed
but when users scrolled the page.
Using CSS, which is now supported in most browsers, simplifies the
matter. On browsers like Internet Explorer, where it's not supported,
the content will not stick but other than that it'll work fine.
We're also adding `scroll: auto` so when the TOC's height will be large
than the page, it'll be possible to scroll it, which users couldn't do
in the original version.
Now that comments and TOC can be closed at the same time, we use a flex
layout so the main content uses the available width.
We're also making the comments work better on medium-sized screens,
since previously they had a fixed width and now the width is adapted to
the size of the screen.
Since now the comment box element has a relative position instead of an
absolute one, we need to consider the draft panel height when
calculating the comment box position.
We were using JavaScript to show/hide the Table of Contents.
In my humble opinion, the <details> tag has a few shortcomings [1][2],
which means we should be careful about when to use it.
IMHO a Table of Contents is a good candidate for this tag because it's a
very common pattern to add a show/hide behavior for it, even if using it
means the "navigation" role (which we are *not* using anyway) wouldn't
be identified correctly.
I'm adding a <details> tag to the comments section as well for
consistency and in order to simplify the code. I'm not sure this is as
good an application of the <details> tag, though, but then again I'm not
sure about the interface we use to show/hide the comments (and this
feeling is increased by the fact that we use a different interface on
small screens). If we decide to change the interface in the future, we
might consider using the <details> tag for the Table of Contents but not
for the comments.
Since the <details> tag is not supported on Internet Explorer, I'm
only adding styles to this tag using the `:not([open])` option. On
Internet Explorer <details> will always be opened and so these styles
will be ignored.
[1] https://adrianroselli.com/2019/04/details-summary-are-not-insert-control-here.html
[2] https://daverupert.com/2019/12/why-details-is-not-an-accordion/
Even if "r" is shorter, "regular" is easier to understand, and we're
going to store these icons in a folder named "regular", which is the
convention Font Awesome uses.
It was removed in commit 128a8164 because we hadn't reviewed it nor
tested it properly. We're now adding it again, fixing the issues we've
found while reviewing.
This feature wasn't properly tested nor reviewed, and after reviewing
several pull requests with a similar status and considering this pull
request is related to the public area of the web, we've decided to
remove it before releasing version 1.1.
This commit reverts commit 4f50e67a.
