On Mon, Jun 21, 2010 at 5:57 AM, Tisza Gergo gtisza@gmail.com wrote:
Infoboxes would do fine, navboxes not so much. Consider something like [1], how would that work with fixed widths?
If I remember correctly, there was an effort a while ago to make navbox markup less ugly (make it use a single table at least, instead of one table stacked into another), and even that didn't work in more comlicated cases like navbox subgroups.
Also, you can use visibility: collapse with collapsible tables, which looks much nicer in certain cases (when the table cannot be set to fixed width for some reason).
You might not be able to get the exact same appearance, but I'm very sure you can get something that looks just as good without using tables non-semantically. I don't have the time to actually try, though, particularly not when I doubt anyone will bother changing it. I asked someone I know who's more expert in CSS (an editor of some CSS specs, in fact), and he said it would only be a few minutes to change that template to be (in his words) "non-disgusting". Of course, that would mean no longer using {{navbox}}.
Sorry; I meant the "link" wikitext parameter but remembered the name wrong. The point is, when you use images as icons or similar eye candy, and the pointer changes to link style over it, the reader will expect something more relevant than an image description page, so link= should be used. Conversely, when it is used, it is a good guess that the image is purely presentational.
I'm not clear what you're saying. Images that are actually being used as links are the last thing you want to give empty alt text -- that would (as far as I understand) make it hard or impossible to click the link using a screen reader.