Moved to wikitech-l as we've gone to the minutiae of implementation rather than policy. :)
On Wed, 2 Jul 2003, Erik Moeller wrote:
Tables are predictable and dependable. CSS often isn't. ;-) But it's probably safe to use it by now.
If we don't encourage users to use browsers that support CSS, they'll have no incentive to not drive us fricking crazy with their stupid broken browsers. :)
A nice named div will allow skins to be flexible with the TOC placement. In a sidebar, perhaps, whatever...
<a name="Culture/Blecchistan">... <a name="Language/Blecchistan">...
[snip]
But not if the hierarchy is changed, and we would still have to retain the numbering feature for H2 dupes. Also, these anchor names could get very long, especially for H4 anchors.
Yes, all these are reasons why I don't like generating anchor names from header text. :) Whatever you do, they remain fragile. Nice explicit anchors would be better, though of course your fiendish table of contents needs automatic ones anyway, so oh well. :)
and by default are faded (so seemingly partially transparent on the solid background) until a mouseover darkens them up to full visibility?
Hm, can you demonstrate that?
Off the cuff, something like:
<div class="sectionedit">[<a href="blahblah">Edit</a>]</div>
.sectionedit { float: right; color: #ccc; /* light gray text */ font-size: 0.8em; } .sectionedit a:link { color: #ccf; /* light blue link text */ } .sectionedit a:hover { color: #00f; /* darker, brighter blue */ }
-- brion vibber (brion @ pobox.com)
On Wed, 02 Jul 2003 12:53:17 -0700 (PDT), Brion Vibber vibber@aludra.usc.edu gave utterance to the following:
[snip]
But not if the hierarchy is changed, and we would still have to retain the numbering feature for H2 dupes. Also, these anchor names could get very long, especially for H4 anchors.
Yes, all these are reasons why I don't like generating anchor names from header text. :) Whatever you do, they remain fragile. Nice explicit anchors would be better, though of course your fiendish table of contents needs automatic ones anyway, so oh well. :)
Does your current code ensure that anchor names only start with a letter a- z? names starting with a number are illegal, and hyphen and underscore are the only permissible punctuation.
Re the HTML for the TOC: Why don't you use ol and li? And why do you need two nested tables?
Greetings, Timwi
Timwi-
Re the HTML for the TOC: Why don't you use ol and li?
Because we need to do manual numbering anyway, to keep the numbers consistent with those used by the auto-numbering for headers (which is a user preference). Also, it was easier to get all the margins right and avoid unnecessary whitespace this way.
Feel free to play around this with Skin.php, but please realize these two requirements. There should be no indentation on the first level, and no margin above or below the list items; the numbers must be the same and in the same format as in the headlines. I think that's a pointless exercise, because the current solution works fine and probably takes less space.
And why do you need two nested tables?
That's an ugly hack to accomplish a thin border without using CSS. It works in all browsers I've tested, though, since it relies on very basic table properties. I've experimented with replacing the whole table with a <DIV> yesterday, but that didn't work as desired; the border did not auto- expand. I could either specify a min/max width, or it would take up 100% of the screen. That's not acceptable. There's a commented version of my last variant in Skin.php.
I've also played around with floating the table, but that takes a lot of screen real estate, and will not work well with all but the highest resolution when there's also an image. Given that not all users will enable the toc, this would make testing if the image width is too high quite tricky.
Regards,
Erik
Hi,
03.07.2003 13:57:00, erik_moeller@gmx.de (Erik Moeller) wrote:
Re the HTML for the TOC: Why don't you use ol and li?
Because we need to do manual numbering anyway, to keep the numbers consistent with those used by the auto-numbering for headers (which is a user preference).
Will this numbering ever be different from that of ol/li?
Also, it was easier to get all the margins right and avoid unnecessary whitespace this way.
Not really. You are plugging a style="margin-bottom:0px;" on loads of divs inside the table. It would suffice to give the table a class="toc" and then specify in the stylesheet: .toc LI { margin: 0; } and the left margins would be handled automatically by nested <ol>s.
The major reason I want to use <ol> is because if you have a really long heading, it will render like this:
1 This is a really long heading
I think it would do a *lot* to readability if it were rendered li-style:
1. This is a really long heading
Of course you're going to tell me such long headings will never occur, but take a look at http://test.wikipedia.org/wiki/Be for a near- plausible example (switch to 800x600).
Feel free to play around this with Skin.php
Unfortunately, the way this is constructed now (with Indent and Unindent functions) already assumes unstructuredness (non-nestedness). I would have to restructure that...
the current solution works fine and probably takes less space.
"works fine" isn't always the best excuse hackishness ;-)
As for table vs. div: Ah, I see.
Please could you at least change it so that the number isn't part of the link? Remember links should have meaningful and usable link text. I like to follow links by typing the first few characters of their link text. It is easier to type letters than numbers.
Greetings, Timwi
Timwi-
Because we need to do manual numbering anyway, to keep the numbers consistent with those used by the auto-numbering for headers (which is a user preference).
Will this numbering ever be different from that of ol/li?
Not sure if we can get 1.2.3 formatting with <ol> at all. In any case, the numbering is different with inversely nested headlines (a higher level being introduced after a lower one).
Also, it was easier to get all the margins right and avoid unnecessary whitespace this way.
The major reason I want to use <ol> is because if you have a really long heading, it will render like this:
1 This is a really long heading
We can use the table to fix that. <tr valign="top"><td>1</td><td>Heading</td></tr>. Then we can also put the link on only the heading text.
Regards,
Erik
Erik Moeller wrote:
Not sure if we can get 1.2.3 formatting with <ol> at all. In any case, the numbering is different with inversely nested headlines (a higher level being introduced after a lower one).
I don't know how to get 1.2.3 for <ol> either; but as a user of auto-numbered headings, I don't need it. The number with inversely nested headlines is the same; it's just that you have to take care that the HTML is valid. I should point out that inversely nested headlines, AFAICT, are /always/ an error -- and I always fix them. I support switching to <ol>.
-- Toby
Richard-
Does your current code ensure that anchor names only start with a letter a- z? names starting with a number are illegal, and hyphen and underscore are the only permissible punctuation.
I've tested with Mozilla, Opera, IE, lynx, links, w3m and noticed no problems with anchors containing other punctuation or starting with numbers. Keep in mind that these anchors are also used to link to individual sections from elsewhere:
[[Popular songs#99 bottles of beer]]
This will no longer work as expected if we escape the anchor names to satisfy a restriction that no browser seems to implement anyway. My features don't depend on the anchor names, but the anchor linking feature does, and so far I've seen no good alternatives to using the section title as is to make this easy.
Regards,
Erik
The Table of Contents feature could potentially suffer from the following problems, as it is currently implemented:
1. An article with many short sections would inappropriately get a TOC that would waste space. 2. An article with just two very long sections wouldn't get a TOC but would be appreciably helped by one. 3. Sometimes a TOC would be best located not at the top of an article, but after a short introductory paragraph. I think some dead tree encyclopedias use this method. 4. If displaying TOCs is off by default, most users won't appreciate their utility, as most users won't change preferences. It seems a TOC is most useful to readers of an encyclopedia, and as many readers won't even be logged in, they won't see the potentially helpful TOCs.
I propose that whether and and where a TOC appears should be specified by each article using a wiki tag indicating where the TOC should appear. This would allow articles with many short sections to not have a TOC, long articles with just a few sections have a TOC, and allow article authors/editors to specify the best location for the TOC without relying upon the wiki software to presume the very top of an article is the best place.
I think keeping the option of having automatically-generated TOCs as a user preference is desirable, as at first, most articles won't have a TOC. Maybe they should be a different color, so editors can easily identify articles that would benefit from a TOC and insert the wiki tag for one, and perhaps identify articles that suffer from a TOC and insert a wiki tag to exclude one.
- David Friedland (Nohat)
(I'm not sure if this is more appropriate discussion for Wikipedia-l, as it might involve policy, so I erred on the conservative side and have posted on wikitech-l)
David Friedland wrote at last:
(I'm not sure if this is more appropriate discussion for Wikipedia-l, as it might involve policy, so I erred on the conservative side and have posted on wikitech-l)
I replied on <wikipedia-L>, since you posted there also eventually.
-- Toby
wikitech-l@lists.wikimedia.org