w3c / tr-design

CSS used by W3C specs (this repo is not about the w3.org/TR index page)
https://w3c.github.io/tr-design/src/README
Other
64 stars 29 forks source link

Add "scrollspy" like behavior to ToC #108

Open tobie opened 8 years ago

tobie commented 8 years ago

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 commented 8 years ago

Very good idea.

tobie commented 8 years ago

Just sent a PR for this to the WebIDL spec: https://github.com/heycam/webidl/pull/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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

plehegar commented 8 years ago

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

tobie commented 8 years ago

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

plehegar commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

tobie commented 8 years ago

Yeah, sorry.

plehegar commented 7 years ago

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