Ticket
refactor table of contents+solution
The big change is that we're going to generate the table of contents in the browser with JavaScript manipulating the browser's dom parsing. At the same time we'd like to address most or all of these:
- have ToCs reflect only some headers in inclusions (needs some design)
- stop showing root of relative plus cards in ToC
- keep blank headers out of ToC
- include anchors even if no toc
- make toc work on Related subtabs
There may be others, check:
Development Tickets (by status)
Ideas
Documentation Tickets
Support Tickets
now starting to think this might be possible to do as chunks. tagging 1.5.3 but just want to have a look.
(would restore old functionality, with an eye toward these other issues)
--Ethan McCutchen.....Fri Feb 18 10:16:39 -0800 2011
The idea I had for getting refactor table of contents working in wagn 1.5+3 would mean moving the handling into lower level rendering, which I'm now realizing would make it hard to have any rendered content view (including content and naked) without the toc.
The takeaway is that we might want to give toc some more talking over.
--Ethan (from make toc work on Related subtabs)
You want to talk about toc?
--John Abbe.....Mon Feb 28 10:13:26 -0800 2011
We'd offer some flexibility if we class ToC links to anchors based on whether they're from the root card of an inclusion.
--John Abbe.....Tue Mar 22 21:43:11 -0700 2011
We've been asked how to display the TOC bullet points as numbers instead of Roman Numerals.
--John Abbe.....Tue Mar 22 21:58:02 -0700 2011
What about merging these thoughts and features with things like 'fold' processing. Seems to me that the TOC is just another section/variation of the card's content. I think I would make it a separate view (view=toc), then the Javascript can fetch and display it how it wants. If the style is just nested divs with classes indicating how deeply nested a given div is, lots could be done with styling alone.
Then also use the show/hide mechanism too?
+1 re show/hide
I like the idea of its being a view. Though one thing I figured we should do with this refactor is move most of the HTML parsing into javascript. It's not "just another view" if the ruby suddenly has to get smart about HTML. Because for this to work we need sophisticated parsing. We don't want header tags inside closed view.