Add "scrollspy" like behavior to ToC

[tobie]

See for example: https://getbootstrap.com/javascript/#scrollspy (and see it in action in the nav on the right hand side).

Reasoning: it's super hard to understand structure of large specs and especially where in the spec you're located when you navigate to it from elsewhere (or when you follow links to definitions from within). Knowing where you are in the ToC really helps build a mental model of the spec.

[tripu]

Very good idea.

[tobie]

Just sent a PR for this to the WebIDL spec: whatwg/webidl#196

See it in action here: https://heycam.github.io/webidl/

You're welcome to lift the code off for tr-design.

Happy to help if you have questions.

[tobie]

For ref, here's the CSS I use:

#toc .current,
#toc .current-parent {
  border-right-width: 3px;
  border-right-style: solid;
  border-right-color: #3980B5;
}

#toc .current {
  background: rgba(75%, 75%, 75%, .25);
  border-right-color: #054572;
}

I also didn't find any hooks that were easy enough to use when the toc was popped in and out in smaller-sized screens, so the scrollspy doesn't work there. That should be fixed. :)

[zcorpan]

A border changes layout and could cause text in the ToC to rewrap, right? Maybe all items could have a 3px transparent border and then .current/.current-parent can just change the color.

[tripu]

@plehegar, before I work on a PR reusing @tobie's code, I'd like to clarify how we're going to work with this project in the current cycle (design for 2017). I'd like to follow the approach outlined in README, with separate branches (we ignored it in the last cycle).

That's what I prefer. If the decision is to continue having just one branch in practice, OK; but we should be clear and update the documentation if that's the case.

Is @fantasai the design point person this year, too?

[tripu]

(Strong candidate for our next cycle; whether that's some time in 2016 or not.)

[plehegar]

@tripu, @fantasai wasn't interested in a new design this year so the design point person is up for grab.

[tobie]

It would be awesome to see TR/ design be among the priorities of W3C's systeam.

[plehegar]

TR/ design is not a W3C's system priority, by design. We need expertise in design, which isn't a quality of the W3C systeam (nor a good chunk of the W3C staff, including myself). And I actually don't want the W3C team to block progress on /TR design.

[tobie]

I don't think this is the right venue for this conversation, but to clarify I'm not suggesting you block progress, just that you get and assign resources to things that are valuable to W3C, it's members, it's community and the Web. Proper design for specs is clearly paramount. That this gets relegated, year after to year, to volunteering from members or IE on their own time is completely baffling. If Hollywood was just focusing on writing scenarios and tasking volunteers to turn them into movies, we'd roll our eyes, and yet…

[plehegar]

Feel free to move the discussion to spec-prod (see my email there). But the W3C team has failed to update on /TR design for years and this new Process was designed to prevent that from happening again. In terms of improving publications, we have multiple things on our list: /TR pages, /TR versioning, old drafts on /TR (aka SEO issue), support for FPWD/CR in Echidna, documentation improvements everywhere (especially /Guide), support for Process 2017. In terms of systeam, my list contains things like better GitHub/W3C integration (account, mirroring), ash-nazg enhancements, better office like tooling (aka the google docs issue). I also need to provide a better management of W3C TR milestones. Now, if the only change we make in 2017 is this scroll thing, that's something that can be relatively easily handled but we just did a new design a few months ago so doing a new major one is nowhere close to the top of my list.

[plehegar]

(and I see that you just did move the conversation there)

[tobie]

Yeah, sorry.

[plehegar]

Last email on this front is at
https://lists.w3.org/Archives/Public/spec-prod/2016OctDec/0036.html