allow the user to control whether the toc jumps to the left

[w3c]

allow the user to control whether the toc jumps to the left

[tripu]

I think we mentioned this will come when we tackle HTML+JS changes, next year.

[r12a]

we already do some magic with the go-to-toc icon in the bottom left of the window, which disappears when the toc is shown and reappears when toc is hidden - is it not something that could be packaged with that?

[marcoscaceres]

Agree. I use a 40" 4K screen and have the same problem. It would be great to have an easy way to hide/show the toc.

Sent from my iPhone

On Nov 18, 2015, at 9:39 PM, r12a [email protected] wrote:

while it's generally useful to have the toc automatically jump to the left as the window widens, from time to time it can be annoying – for example, when stretching the window to see a large table, when i'm just about at the right width and suddenly i have to repeat the process (if my screen allows).

if there were some button in the toc area that can be used to hide the toc when displayed to the right, i think this may be sufficient.

—
Reply to this email directly or view it on GitHub.

[tripu]

@r12a, toggling visibility of the back-to-top overlay is achieved via media queries. What you're asking for would require JS, afaik. It wouldn't be complex, but if we stick to the initial scope, it's a feature for the next cycle (TR 2017).

[tripu]

(Actually, I think it could be done with pure CSS with a checkbox or something like that; but it would not be an elegant solution. So I still think it's best to leave it out for now.)

[r12a]

i'm all for elegance, but if it removes useful features, it's not clear to me that it's justified.

seems like for the next year we have to choose between a potentially annoying lack of flexibility in the user interface on a regular basis, or a small inelegant checkbox on the page. Given that the elegance can be fixed next year with the other changes, it seems logical to me to temporarily enable the 'inelegant' approach. My 2p.

[tripu]

I personally don't mind not having the option to collapse the TOC, nor see it as a necessary feature. I'm used to seeing responsive sidebars with navigation that you can't hide. What you are suggesting would be a lot of clicks and mouse interaction, I think (drag to stretch window, click to collapse sidebar, read wide content, drag to shrink window again… and probably later realising you want to have the sidebar to jump quickly between sections).

[marcoscaceres]

On 4 Dec 2015, at 8:05 PM, tripu [email protected] wrote:

I personally don't mind not having the option to collapse the TOC, nor see it as a necessary feature. I'm used to seeing responsive sidebars with navigation that you can't hide.

These docs are different to websites tho. For example, I literally spend hours in w3c documents every day. The way they are used is different to anything else I use on the web.

What you are suggesting would be a lot of clicks and mouse interaction, I think (drag to stretch window, click to collapse sidebar, read wide content, drag to shrink window again… and probably later realising you want to have the sidebar to jump quickly between sections).

I think you nailed it. It's basically about providing flexibility because people need to spend a ton on time pouring over these docs.

Sometimes one jumps in and out. Other times, one needs to read them from start to finish, etc. The ToC can be very useful if you are jumping in and out... Not so much for a long-haul review.

—
Reply to this email directly or view it on GitHub.

[tripu]

OK, then. If that feature is welcome by some users (and agreeing with @marcoscaceres that TRs are very special pages), we shall have it.

I'm only stressing here that it's too late in the current cycle to add this (or any other feature). We're late already for deployment and adoption at the beginning of 2016…

[r12a]

What you are suggesting would be a lot of clicks and mouse interaction, I think (drag to stretch window, click to collapse sidebar, read wide content, drag to shrink window again… and probably later realising you want to have the sidebar to jump quickly between sections).

No, not at all. What i'm suggesting is that things work the way they currently do, but if the toc has appeared to the left and you decide you want to recover that space at some point, then you should be able to simply click on something to make it disappear. Ideally, you'd be able to make it reappear, if you wanted to, by clicking on the same thing again, but i'd be happy with refreshing the page for the time being. Hope that's clearer.

[iherman]

On 7 Dec 2015, at 13:32, r12a [email protected] wrote:

What you are suggesting would be a lot of clicks and mouse interaction, I think (drag to stretch window, click to collapse sidebar, read wide content, drag to shrink window again… and probably later realising you want to have the sidebar to jump quickly between sections).

No, not at all. What i'm suggesting is that things work the way they currently do, but if the toc has appeared to the left and you decide you want to recover that space at some point, then you should be able to simply click on something to make it disappear. Ideally, you'd be able to make it reappear, if you wanted to, by clicking on the same thing again, but i'd be happy with refreshing the page for the time being. Hope that's clearer.

Indeed, this does not seem to be very complicated. I guess if the core style file defined two different rendering of the TOC (bound to different classes) then a very simple Javascript should be able to switch back and forth the class of the TOC as a result of a click.

I must say that I would also welcome such a possibility (or simply those two available classes) from the point of view of EPUB generation. Typical EPUB readers have their own TOC facilities and EPUB requires to have that TOC as part of a navigation file anyway. Ie, my plan is to switch that side-bar TOC off in any case, because it is unnecessary and uses too much space for an EPUB.

[tripu]

Indeed, this does not seem to be very complicated. I guess if the core style file defined two different rendering of the TOC (bound to different classes) then a very simple Javascript should be able to switch back and forth the class of the TOC as a result of a click.

I didn't say it's difficult to implement; only that it's out of scope for this year, and that we're already past the freeze date to be able to roll out these changes on time for 2016. I'll be happy to review PRs about this, regardless of when they're deployed, though!

[fantasai]

If the Webmaster is okay with it, I think a short, self-contained JS script that added the necessary markup and behavior to make the ToC collapsible could be reasonable to do for this year, since it does seem to be a major point of discomfort for people. I would not want to add any additional markup requirements for the HTML, though, other than linking to said JS script, since we want to minimize changes to the underlying document markup.

Would people want to make that same switch also disable the max-width?

[fantasai]

(Sorry, I keep hitting the wrong button to comment. :( )

[fantasai]

Rough draft at http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample
Comments strongly encouraged; JS is not part of my normal skillset...

[iherman]

Works for me...

Thanks

[tripu]

Thank you, @fantasai. That script looks OK to me.

Just a tiny thing: the arrow you're appending to nav#toc > h2 isn't intuitive for me; I had to hover/click to see what it does. I guess that was clear for others here?

(I'd close the issue with this 👍. Especially now that it's associated to a milestone that is overdue 11 days.)

[fantasai]

Do you have a better idea for the icon? That's easy to change if so.

[tripu]

Do you have a better idea for the icon?

Hum, no. “Collapse sidebar” is a difficult action to represent graphically. I did a quick search on a couple icon libraries but couldn't find anything inspiring.

It's fine, thanks :)

[r12a]

the trigger looks fine to me, but i notice that if you remove the toc side panel, then the slightest tweak to the width of the window brings it back, and you have to dismiss it again. I was expecting the toc to stay hidden until you explicitly bring it back. I think the current arrangement has the potential to be quite annoying. Can we please save the state of the toc display so that adjustments to the window size don't reveal the toc.

[fantasai]

Fixed. Let me know if there's any remaining issues.

[fantasai]

Tab fixed up a bunch of stuff to make it behave a bit better, check it out.
http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample

[r12a]

actually this seems worse, sorry :( A couple of problems:

a. if the window is not wide enough to automatically trigger lefting of the toc, the toc can be manually produced but covers half of the main body text. Very messy.

b. if you hide the lefted toc, and stretch the window all is ok, but if you happen to reduce the window width and stretch it out again the toc reappears – which is annoying.

i think what we had from your previous fix was better, iirc.

(i'd try to take a look at it myself, but i'm really backed up after 3 weeks absence)

[fantasai]

a. was existing behavior from the previous fix.... If you click on a link now, though, it goes away.
I can't produce space for the toc where there is none, such as on a mobile display. You can argue about making a third zone between "mobile" and "maximized" where the body text is narrowed to make room for the toc, but then balancing the space requirements becomes a separate issue, and I really don't want to code up a resizer, that's more complication than I want to handle at this point.

b. can be adjusted back to being sticky; I can look into it tomorrow