On Mon, Jun 21, 2010 at 5:57 AM, Tisza Gergo <[email protected]> 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.

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to