Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
1 to 61 of 61
Over in this thread, we started talking about floating TOCs, but thought it is better to create a separate discussion here.
On the bottom of each nLab page, there are a few options for selecting how the page is displayed:
For me, and to a certain extent I think Zoran, the floating TOCs are distracting. I especially do not like having floating TOCs in the print view. But it is futile to argue against them altogether since other people really like them and they are there, so end of story.
So I was wondering if there is any way to take advantage of the above listed display selections to create a floating TOC free display? For example, could we add a new item to the “Views” list, e.g.
It would be even more super if clicking a link on a “Print (fTOC free)” page took you to another fTOC free page.
This would be equivalent to having an option of turning off fTOCs.
Elsewhere, John remarked that the nStuff is quite reliant on me - technically, that is. So with that in mind and in the spirit of “Give a man a fish, and he wonders where the chips are …”, here’s what I would do:
Mildly more seriously, this level of customisation is not built in to instiki. Whilst it’s possible to do this, it would involve branching us from the main instiki tree and I’m not prepared to do that for this particular feature. In addition, the number of different permutations and so forth that could be dreamt of is quite large. I think that this is far better handled at the user end, which is where the Stylish extension comes into effect as that easily (and quickly) adds some CSS rules on top of the page that is being viewed.
Step 5 is important, since there are probably dozens of little CSS tweaks like this which people would like and I think that a list of common ones that are easy to install would enable us to offer a level of customisability without having to overload the code base.
Welcome back, Andrew. Hope you had a good vacation. Sorry for the fishnchips business here.
The bottleneck of your prescription seems to be
Third. Learn how to use the Stylish extension
at least if we are talking about appearance of the nLab to the rest of the world. If there are many readers appalled by floating tocs (are there? I don’t know) then telling them “well, go learn how to reprogram your browser” might be an option, but maybe not the best one. I don’t know.
But isn’t there any already present feature in instiki that would allow one to mark parts of a page as “display on demand” only? We have scrollbar boxes, for instance, built in. Isn’t there anything similar that would help here?
Learning how to simply use Stylish doesn't require learning CSS and how to reprogram page appearance. The minimum knowledge needed is how to install somebody else's Stylish rule and how to activate it."well, go learn how to reprogram your browser"
Rod’s hit the nail on the head: it only takes one person to learn how to implement a particular feature using Stylish for us all to benefit. If there was a repository of Stylish styles on the nLab that people could pick and choose from, then it would be just as easy for a user to select from as having a preference pane.
I’m not unhappy with Urs’ translation of my comment as “go learn how to reprogram your browser”. We can’t ignore the fact that we are using browsers to interact with the nLab and nForum and hence with each other. Therefore, learning more about what your browser is capable of is a Good Thing and can only serve to enhance your experience.
But I would like to emphasise that there is a difference between this particular feature request and the bigger issue of how the nLab looks to the Outside World. We should make the default view of the nLab as user-friendly as possible, with “user” meaning someone who stumbles across it from a link on, say, MO. But then for the “power users”, we can add customisations via things like the Stylish firefox extension which they can choose to use if they like. (BTW, I’d be amazed if there weren’t similar extensions for the other major browsers.)
I’ll echo Urs’ question…
It seems worthwhile to explore the possibility of some “already existing” feature in Instiki that will let us do what we want to do. There does exist some ability to customize things in Instiki for other things, e.g. rolling bars, so is there any existing ability to customize the available “Views”?
I definitely agree we don’t want to start modifying source code, but turning on or taking advantage of an existing feature is something worth trying.
The “views” are hard-coded into the source. It’s not difficult to add new ones, but given that the list of them would easily clutter up the display, each should have a very clear reason for existence.
The desired new view is only a minor modification of one of the current ones, and a modification that can be entirely controlled by CSS. All the suggestions, including drop-down menus and rolling bars, can be (as far as I’m aware) done via CSS. In addition, changing things to such a level is extremely user-specific: one person’s elegant design is another person’s cluttered nightmare. It certainly would involve modifying the source code to add a level of user customisation.
To me, the browser does feel like the right place to implement this. It’s the easiest way of being user-specific since it is completely controlled by the user! Why add the necessity that instiki remember who you are when the browser already knows?
Sounds reasonable to me :)
Sounds good to me, too. (Which is easy for me to say in this case, because I am the one who is already happy with the TOCs.)
So do we have any volunteers for creating that required Stylish-extension and describing how to use it on the HowTo-page?
But also at some point I would like to drive the discussion in the opposite direction: while I can see why floating TOCs may be a nuisance in some respects, I feel that nevertheless we still should try more to not only add bits of content to the nLab, but also to interlink the content correctly.
As the thing grows, much of its value will not just come from the fact that somewhere, on some page, there is a gem of information hidden, but from the fact that the user does arrive at this gem if he needs to, even if he is not actively looking for it and may not even know yet what it is called.
I think for that reason it is very important to provide with the creation of every entry also all the proper context for that entry. This means among other things to add the right hyperlinks from the entry and to the entry.
I’ll quote a few sentences from above:
to motivate these questions:
I’m pretty sure that the answer to (1) is Yes, although I won’t be certain until I try (or somebody else just does it). I’m fairly agnostic about (2), since I never use that view.
By the way, if by “display on demand”, Urs means something like the sidebars on Wikipedia that only display when you click on ‘Show’, then No, we cannot do that with stylesheets. Or at any rate, Wikipedia does not do it with stylesheets; they use Javascript, and we can’t just add new Javascript features to our Instiki.
to motivate these questions:
- Can we set the nLab’s default stylesheet so that the floating TOCs are hidden in the Print view?
Good point, my impression is that this is indeed the crucial point. Ideally, the TOCs would disappear on the print view. Certainly there they serve no purpose.
I’m feeling deja vu all over again, but at some point, I remember suggesting the same thing, i.e. not having floating TOCs in print view, but someone objected, so we never proceeded trying. That would be great if possible.
Eric, you suggest a new view and my objection was to the new bit. I’ve no objection per se to changing the CSS on one of the standard views providing such a change is intended to make it better (in some indefinable sense!) for Joe Public. I can see how that might well be the case for this change.
I’ve no objection per se to changing the CSS on one of the standard views providing such a change is intended to make it better (in some indefinable sense!) for Joe Public. I can see how that might well be the case for this change.
Ah! So if that’s easily possible then I say: let’s do this! Let’s make the print view suppress the floating TOCs.
(Unfortunately, when I say “let’s” I have to mean: it would be great if you found a minute to do so…)
Yeah, I suggested a new view because I think someone objected to changing the existing view for some reason. But if that person was a figment of my imagination, then by all means :)
It makes sense to remove floating TOCs from the existing print view if that is not too much trouble.
PS: Welcome back! :)
Slightly orthogonal to removing them altogether from the Print view, the range of what’s possible with CSS is as large as I thought: floating table of contents (doriath) (hover over the word “Contents”). That’s pure CSS. It’s perhaps lacking a little in elegance, and as I only copied a little from the source then I may have missed a few necessary pieces for other browsers, but as a proof-of-concept it’s neat.
(Source for code: TJK Design, partly so I remember where I got it and also in case anyone else wants to find out what’s possible and play around a little)
(Edited to correct the location from nlabmeta to doriath in response to Urs’ comment)
Andrew, the page floating table of contents (nlabmeta) does not exit. Probably you meant some other web?
Yes! I meant floating table of contents (doriath) since doriath is the testing ground. (I’ve edited my original post so that no-one creates that page by mistake)
You rock :)
Very nice :)
Okay, I am trying that code on a real-life example, currently at the entry topos.
But I guess somebody fist has to copy some CSS code to the main web..
As I said, it’s a proof-of-concept and probably should be tweaked a little before using in the main nLab. The contents at Topos is highly structured, and so it might be worth thinking a minute about how much should be hidden and how much viewable at each stage. Do you want the whole list hidden and then the whole list revealed on hovering over a magic word (say, “Contents”)? Or do you want a basic list with all the headings, but the sections revealed bit-by-bit?
There’s two examples at floating table of contents (doriath) now; the first uses nested lists. But having seen topos, then the second has a header followed by a list.
Thanks, Andrew.
I think what should be visible before hovering the mouse is precisely one line per included floating toc. For instance Higher Topos Theory has five different floating TOCs included. i think it would be good if this would collaps to a menu that shows precisely the 5 titles of these TOCs and then reveals their content on mouseover
I like that last proposal.
Okay, see what I’ve done at Higher Topos Theory. The setup from doriath broke for technical reasons when the contents is another page that is included due to how the inclusion process is handled, so I had to modify it a little by putting titles on the including page (in this case, Higher Topos Theory). One advantage of this approach is that the decision as to whether or not a TOC is drop-down is entirely at the disposal of the including page.
Now we just need to go through the labor of changing the code everywhere.
Is there maybe a way that the title that is being shown in the drop-down menu is determined by the included page instead of having to be fixed by hand in each including page?
I really like the looks of these drop-down things. Here is one at cohomology.
Regarding the titles, the answer is that if it is possible, then it needs a different method to the one that I used. The problem is that the drop-down method needs two pieces: a bit that’s always visible and a bit to be revealed when the mouse hovers over the visible bit. Due to how includes are handled, with the current method then the declaration of which bit is which has to be on the master page, not on the included page. I don’t truly understand all the ins and outs of why it doesn’t work so more experimentation may reveal a way in which it can be done, but my experiments didn’t work. On the other hand, some flexibility in the title might be appropriate.
Regarding the labo[u]r of changing the code everywhere, well, that’s a facet both of how it’s done and of my principle that significant changes to the CSS shouldn’t be applied retrospectively without giving people the opportunity to object beforehand.
Okay, that’s fine.
We can just piece-by-piece change the code.
Thanks for all your efforts! I think that should pretty much solve Zoran’s and Eric’s request, while still keeping the benefit of the TOCs. I think it’s great.
Really slick job, Andrew! Thanks so much for this.
I wrote:
By the way, if by “display on demand”, Urs means something like the sidebars on Wikipedia that only display when you click on ‘Show’, then No, we cannot do that with stylesheets. Or at any rate, Wikipedia does not do it with stylesheets; they use Javascript, and we can’t just add new Javascript features to our Instiki.
Which just goes to show that Andrew knows something that Wikipedia doesn’t, I guess.
A little problem:
On topos, there are two TOCs. If I mouse over the first one, then it opens, and I can scroll down it. When I get to the bottom, my mouse goes over a horizontal rule, and suddenly the TOC collapses, and I’m in the middle of nowhere. I would have preferred to instead smoothly move into the second TOC and open that too.
I understand why it works this way. Possibly removing the horizontal rule would help a bit, but it wouldn’t stop the first TOC from collapsing, so it would still be a jarring effect. On the other hand, I wouldn’t want to mouse over only the second TOC and have them both open! So I don’t know a solution.
One thing to notice is that it is never possible to have both TOCs open at once. I don’t know if that’s good or bad.
Even for the newcomer (and certainly for myself, although I can use Stylish for myself), I think that it would be better to have the TOCs open as they were before, but collapsed in the Print view.
I think that should pretty much solve Zoran’s and Eric’s request, while still keeping the benefit of the TOCs.
Yep yep. Great stuff Andrew. You rock :)
Sorry to come a little bit late and be unhappy, but I’m not yet thrilled with the current setup. I very much like the idea of hiding TOCs by default, including in the ordinary non-Print view. (Several pages are currently made less-than-readable for me by the big TOCs.)
However, I have the same complaint that Toby does about moving from TOC to TOC. Moreover, even when there is just one TOC I have a problem: if the TOC is longer than the height of my screen, then I need to scroll down to see the rest of it… but as soon as I move my mouse over to the scroll bar, the TOC disappears! I need to hover my mouse over the TOC and then scroll the page with the keyboard in order to see the rest of the TOC; and if I scroll a little too far then the TOC disappears again and I need to go all the way back up again to find it. I don’t think this is very friendly to Joe casual user.
In general, I think our TOCs are really too big to be someting that appears and disappears based on a mouseover. (I’m not really thrilled with mouseover dropdowns at all, but I can live with really small ones.) I’d be much happier with a button I could click to make the TOC drop down and stay dropped-down until you roll it back up. If we can’t do that with CSS, then maybe we should think about how else we could do it.
Evolution. Yeah. Having collapsable TOCs is nice and the proof of concept is complete. I think whether it executes with a mouse over of a click is of secondary importance from a tech perspective.
Having said that, I agree. I’m not crazy about mouse overs either. Simply clicking it would be better I think.
Firstly, this was intended as a proof-of-concept to show what was possible with just CSS (and therefore no hacking on the core). It certainly was not intended as a solution to Eric and Zoran’s request to remove TOCs from the print view. Then Urs decided he really liked it, so I added the capability to the nLab. Of course, that has revealed issues with how it’s done!
For the record, there’s a decent library of javascript stuff packaged with instiki (scriptaculous, for instance). I just don’t know how to attach it to stuff within a page. Although there isn’t an inbuilt mechanism for adding javascript to pages, it might not be a major change to do so as it only requires adding stuff (which is reasonably safe against upstream modifications).
So it was intended to get you all thinking about what you’d like these menus to do, which it is doing, which is great. But it would also be useful if you’d go out in to the Big Wide Internet and look around for other ways to do it! I’m not a CSS expert, I’m learning this as I go along.
Anyway, back to the issue with print views, do you want it so that the menus aren’t visible in the print view or when a page is printed? The two are slightly, and subtly, different.
do you want it so that the menus aren’t visible in the print view or when a page is printed?
Wouldn’t it just be confusing for everyone if the print view does not show what would be being printed?
Yes, but at my current state of knowledge, it’s easier to do it for when a page is actually being printed. The point is that there is a way to tell a browser to use certain rules for different media (print versus screen) but looking at the different views (show versus print), I don’t see a way to have a rule hold only in one of them since the stylesheet tweaks get added to both. As far as the browser is concerned, the two views are called “wibble” and “wobble” so it doesn’t know to use the “print” rules for “wobble” and not for “wibble”. I’ve just sent an email to Jacques to ask if the necessary tweak can be made. Plus, I expect that not everyone knows to use the “print” view for printing!
In other news, I’ve got a pure-CSS click-down menu over at doriath: floating table of contents (doriath). The trick is to make the menus “clickable”, meaning that you can click on them. That triggers a CSS pseudo-class in the same way as hovering over them does. To hide a menu, click anywhere else in the page. I’ve added a couple of long lists so you can see how it works with varying the lists.
The issue about a long list followed by a short list remains, but is slightly better. Reaching the end of a long list and clicking on the header of the short list will cause the list to disappear from view as it doesn’t take up as much space as the long list, but it will actually be there when you scroll up.
do you want it so that the menus aren’t visible in the print view or when a page is printed?
Wouldn’t it just be confusing for everyone if the print view does not show what would be being printed?
Agreed. I vote for removing them from both print view and what is printed.
I have no clue about this, but maybe to save you some googling here are some promising links:
Edit: I was a bit slow so these links are a bit redundant given that you are finished it :)
In other news, I’ve got a pure-CSS click-down menu over at doriath: floating table of contents (doriath).
All right, there we go!
Could you copy the CSS source to the nLab so that we can test it on real world examples?
I think this would address Mike’s point above if we stopped having separate pull-downs for each topic, but just made the whole collection of floating TOCs appear and disappear at once upon clicking.
As an experiment, at topos I put te two hidden tocs into the same drop-command.
Okay, I’ve copied it across. The syntax (viewable on Doriath) is:
+-- {: .clickDown tabindex="0"}
###OnClick Drop-down Contents###
* First Item
* Second Item
* Third Item
{: .hide}
=--
The outermost +–/=– pair establish a containing div. That div is given the class ’clickDown’ (it can be given others as well, such as ’toc’ or ’rightHandSide’, of course). That class has the feature that anything inside it which is given the class ’hide’ is hidden from view by default. In the example above, this applies to the list but not to the header. The ’tabindex’ entry means that this div can be given focus, either by clicking on it or tabbing via the keyboard. When it is given focus, the hidden stuff is made visible. When focus is removed (by clicking elsewhere, or tabbing off it), then the hidden stuff is hidden again.
Note that there is a minor spam issue here. It is technically possible for someone to hide something on one of our pages for search engines to pick up which wouldn’t be visible to a casual viewer. To do this, that person would have to know exactly how this syntax works (unlikely in a random spammer) and it’s easy to set up a simple regular search to check for this. So I judge it low risk and therefore worth having the facility.
I am trying it at topos, but I can’t get the hiding to work. (?)
Fixed it. The ’hide’ part needs something to attach to on the including page so I added a div around the inclusions.
Just spotted one (minor) irritation. If you expand the TOC, then forget you did so and click somewhere else on the page (say, to select some text), then the TOC collapses and the page adjusts itself accordingly. Exactly what happens to that “click” is probably browser-specific.
Incidentally, I like the use of the word “Context”. Perhaps it should be followed by “(click to expand)”?
Perhaps it should be followed by “(click to expand)”?
I think if we could underline the word “Context” then it would look like a hyperlink and it would be intuitively clear that one can click on it.
I always forget: how to underline outside of math mode?
Look at how I have it at topos now. What do you all think?
Looks good to me. By the way, as far as I’m concerned, this completely satisfies any reservations I had about floating TOCs. I don’t see any reason to make them completely disappear as long as they can be collapsed.
Is it possible to make the TOC re-collapse if you click it again in the same spot (rather than clicking away)?
One kind of amusing problem now is that one can no longer access the links in the TOCs: because the moment one clicks, the TOC disappears! :-)
@Eric: No. It works by figuring out where the “focus” is, which is where you last clicked the mouse (or tabbed to using the keyboard), and setting the style according to whether or not the element has the focus or not. Since focus doesn’t toggle, the style can’t toggle. On a test site I have it display the text “(Click to reveal)” under the title which then changes to “(Click elsewhere to hide)”. At the moment, there’s a feature/bug preventing me doing that on the nLab but I’ve asked Jacques whether or not it’s a feature or a bug and we’ll see what the verdict is (it be possible to do without fixing this, but the elegance of this method is that the two sentences are inserted by the CSS).
@Urs: picky, picky! “Where’s the chips?”, indeed. Try now. It’s a rather cunning combination of the two methods! The reason that the links didn’t work was that clicking on a link removed focus from the list (transferring it to the link - focus isn’t inheritable in either direction) and so hid the list. This, on my browser, happens before the click is acted upon, meaning that the link doesn’t get the click. I’ve added a rule now that says that when the mouse is over the list, then the list should be visible. When clicking on a link, clearly the mouse must be over the list (as the link is in the list) and so the list stays visible. By tying the “hover” property to the bit that’s hidden, it still needs the click to reveal it. Neat, huh?
I like it! Regarding the long-followed-by-short problem, could we make it so that clicking on a second TOC while a first one is already open doesn’t close the first one? Or is that impossible?
OK, still a little clunky, but it works.
Like Eric, I’d rather close it by click on the title again, rather than by clicking outside it. Just in case anybody figures out how to do that.
Like Eric, I’d rather close it by click on the title again, rather than by clicking outside it. Just in case anybody figures out how to do that.
I pose this as a challenge to anybody BESIDES Andrew :)
Andrew has done more than enough already and this minor enhancement is something I or Toby (or any enthusiastic lurking visitor) can try to figure out.
I pose this as a challenge to anybody BESIDES Andrew :)
Another challenge whose existence I at least mention, is to recode all the pages now. It’s a bit of a daunting task.
Maybe for those who play with the CSS: it seems it would be good if we could somehow achieve a standard pseudocode for tocs. Something at the beginning of each page that reads in
the titles of the tocs to be included
the source files where to include from
so that whatever we decide the implementation of this will be, the code for a floating TOC on each page willl always be the same.
Is this possible?
@Eric: sorry, couldn’t resist! Checkout the HomePage now, look at the source, and marvel at the wonders of CSS! However, I agree with your general point that it would be useful to have more people playing with the CSS than just me. As I said, I’m learning this as I go along so there are no doubt things that are possible that I’m overlooking through sheer ignorance.
@Mike: I think that nesting the lists would achieve that, so that each is contained in the “hide” bit of the one before. However, then you’d need to reveal each one to see the next. However, I suspect that the best (current) solution is an “all or nothing” one: i.e., all the lists are revealed or none are.
@Urs: I’m not sure what you want, there. Do you actually want to be able to write something like:
[[!toc mathematicscontents Context]]
and have it convert it to the appropriate code? That would need a new feature in the core so you’d need to ask Jacques about that. However, I’m not convinced that this is really needed.
I’m not sure what you want, there.
I want to be able to encode on each page just the information of which tocs I want to include. Then the software should decide how to handle that.
See, currently I go through the entries and keep changing the toc-code, even though the tocs that are being included are always the same. I am worried that this is a mightly load of work right now, and as soon as we decide that we want yet a little bit of different CSS code to include tocs, it will be the same mighty load of work all over again. That doesn’t look like a good perspective.
But if there is no easy solution to this, then so be it.
For instance the code that you just added to HomePage: would there be a way to capsulate this such that it propagates to all other pages? Or are we bound to have to copy these lines of code into each and every single page?
i guess what I am asking boils down to: does CSS support a little bit of functional programming? I just want to call a function
at the beginning of each entry.
Andrew,
the problem that the floating TOC disappears when one clicks on one of its links, without the link being followed, still persists apparently, whenever there is more than one TOC included.
As an example, you might go to category theory, open the TOC and click on any link in the second one, the one on category theory.
I suppose this is easy to fix?
I suppose this is easy to fix?
Hmmm. I’ve put a fix in, but now it’s working as a combination of the two systems: the hover-to-see and the click-to-see. So if you hover over the word “Context” (or whatever) then the menu drops down, but then it only stays in place nicely if you click. The new fix has removed the instructions (“Click to reveal” and “Click to hide” or whatever they were) which wasn’t intentional.
Bother.
My, that works very nicely!
Thanks, Andrew!
i second Toby: this is now clearly the best solution we had so far.
I challenge everyone to recode the TOC for 3 nLab pages a day to the new system. Then within a few weeks, we should be all re-TOCed.
Of course the best thing is that I can feel totally uninhibited and add TOCs to every single entry. Eventually.
1 to 61 of 61