Wiktionary talk:Votes/2010-06/Hiding numbers in the table of contents

Future ToC

This might be a bit of a tangent, but if I (or anyone else) can find the time I'd like to write some JS to simplify the ToC a bit. I'd like to just show language and definitions headers (hiding links to "Anagrams" and the like). It would hide the etymology section as well, and instead put the etymology number after the PoS links. For example a ToC could start

• English

  Noun 1

  Verb 1

  Noun 2

If we kept number in the front, this would look awkward. Not sure if others would like this simplified ToC, but it would mesh well with a numberless ToC like what is being voted on here. --Bequw → τ 08:02, 11 June 2010 (UTC)

The TOC should mirror the heading text, or readers may get confused when the browser window jumps down, and they can't find the text they clicked on. That said, I've never been pleased with the inconsistency resulting from pushing down all of the heading levels by one when Etymology 1 is injected near the top. I'm thinking that an HTML5 semantic structure might help make more consistent formatting for the lowered sections. —Michael Z. 2010-06-13 16:07 z

I wholeheartedly agree with any proposal to stop nesting under Etymology, it causes no-end of similar problems. Besides, most editors are too lazy to split etymology sections when they add new senses, so the nesting is often incorrect. Conrad.Irwin 04:34, 14 June 2010 (UTC)

We could have the JS append the etymology # to the PoS headers as well. That would match them up perfectly (though they'd be gone in the edit window). --Bequw → τ 20:26, 14 June 2010 (UTC)

That would also be confusing if the POS headers were for different POSes (e.g. a Verb 1 but Noun 2). --EncycloPetey 20:33, 14 June 2010 (UTC)

Implementing CSS

Whether we end up with the default view with or without visible numbering, we may as well switch the rendering of the list over to CSS numbering. I've outlined the required CSS in Wiktionary:BP#Numbers_in_the_table_of_contents. Anyone know which templates or whatever have to be changed? —Michael Z. 2010-06-14 15:25 z

It's not customisable (see includes/Linker.php:1278 et.al.). Your CSS doesn't work in IE < 8. Conrad.Irwin 15:55, 14 June 2010 (UTC)

I can't find that path name, but I'm guessing you mean that only Mediawiki developers can change this? I'm not surprised at all that Microsoft took 11 years to add support for these CSS2 properties. —Michael Z. 2010-06-14 17:09 z

other ideas

Yair rand wrote: Does anyone have any other ideas for how to shrink the table of contents, even a little? It's size on many pages is completely ridiculous. Maybe L5 headers could be removed?

No, L5 headers should not be removed as this makes the TOC less useful, particularly on entries with multiple etymology sections. I personally don't see the problem with long TOCs, but not showing the whole contents is not the way forward. Thryduulf (talk) 08:24, 18 June 2010 (UTC)

I've had it floating on the right for many moons (WT:PREFS: “Put the table of contents onto the right of entries”), and its length has never been an issue for me. Why not make this the default presentation? —Michael Z. 2010-06-18 16:04 z

For the same reasons this vote failed. It's not the default in other MW projects. Also, because it must necessarily either reduce screen width or interfere with right-hand items like images. --EncycloPetey 16:10, 18 June 2010 (UTC)

Screen width is never an issue, when most of our content is in point form or brief paragraphs (anyway, I narrow my window to about 1/3 of my screen for better readability). It's never interfered with images in my browser (but it actually does help linearize the collective ephemera like images, Wikipedia links, etc, so it's easy to see when some of them are out of order). Right-floated TOC is win–win for me.

I don't see what other projects have to do with it. We have different content which already requires a different format. We don't write the dictionary with infoboxes and in paragraph form like Wikipedia's, so why should we be restricted to a TOC as in Wikipedia? —Michael Z. 2010-06-18 21:18 z

You must not have any relatives or friends who must use IE with a larger font size because of poor vision. In such situations, screen width becomes very important. Deiscriminating against the elderly would be bad for us. --EncycloPetey 21:38, 18 June 2010 (UTC)

You must have a hard time understanding that I'm offering my own specific experience for the discussion, and not offering generalized non-sequiturs leading to backhanded swipes at other editors. I don't personally know anyone who uses IE.

What problems do your relatives have with right-aligned tables of contents in Wiktionary? —Michael Z. 2010-06-19 15:46 z

Using IE to enlarge websites is a very bad idea anyway. It completely fails to resize text if its size is specified in pixels, for example. -- Prince Kassad 21:46, 18 June 2010 (UTC)

My personal opinion is that using IE to view any websites is a very bad idea, but IE is widespread and is the only option available for some users, such as through libraries and universities. --EncycloPetey 16:37, 19 June 2010 (UTC)

Then I suppose you didn't understand the reasoning in the oppose votes, did you? --EncycloPetey 21:38, 18 June 2010 (UTC)

I know I sure didn't. I don't suppose you could explain why it's so important that Wiktionary's style mimic those of our sister projects? --Yair rand (talk) 22:05, 18 June 2010 (UTC)

I would have abstained. I don't see the value in it, but I'm not against it. Per what Conrad.Irwin said, you get used to TOC so you don't read them anyway. Mglovesfun (talk) 15:42, 19 June 2010 (UTC)

That's partly a design problem. The TOCs are an undifferentiated mass of numbers and text, displaying no obvious relationship to the headings.

I formatted the TOC using my vector.css, and after just a couple of days find I'm glancing at it more often to get a picture of what's present on a long entry. —Michael Z. 2010-06-19 15:50 z

Personally I find the default TOC provides an excellent picture of what is present in entries, and I frequently use it exactly as you use your custom one. The numbers and indentation together combine to give a very clear picture of the structure of an entry. Thryduulf (talk) 16:31, 19 June 2010 (UTC)