It is pretty bad in many respects. For example, it seems to ignore the "display" attribute, so "display: block" and especially "display: none" don't have an effect; as a consequence, every external link has their URL next to it, which is pretty bad *especially* on a small-screen device. :-(

Actually, I think hiding things using CSS is probably a rather bad idea anyway - I know it's kind of cool that it's possible, and it's certainly an elegant solution where available, but invisibility is one attribute that really doesn't 'degrade elegantly' if unavailable.

I was thinking of pointing this out somewhere before, if it hasn't been already, since text-based browsers (for instance) have the same problem. It looks especially ugly for footnote-style links ("[1]" et al) and links typed in the form "[http://example.com http://example.com]" - although the latter are broken at the moment anyway. :-/

I'm not sure what a better solution would be, but maybe some JavaScript voodoo to add them or uncomment them. In general, I dislike relying on JavaScript even more than I dislike relying on CSS, but I accept that this option is never going to be viable server-side, and presumably people wanted it.

Rowan Collins wrote:

Actually, I think hiding things using CSS is probably a rather bad idea anyway - I know it's kind of cool that it's possible, and it's certainly an elegant solution where available, but invisibility is one attribute that really doesn't 'degrade elegantly' if unavailable.

Actually, that's exactly an instance of elegant degradation. In plaintext you get the full information: brief link text plus the URL. With CSS on the web page, we can hide the URL since you'll see it when hovering over the link anyway.

I was thinking of pointing this out somewhere before, if it hasn't been already, since text-based browsers (for instance) have the same problem. It looks especially ugly for footnote-style links ("[1]" et al)

We ought to be producing actual footnotes for footnote-style links, but iirc we don't yet.

and links typed in the form "[http://example.com http://example.com]" - although the latter are broken at the moment anyway. :-/

That should never even happen -- you'd write just http://example.com.

-- brion vibber (brion @ pobox.com)

People use the [http://example.com http://example.com] syntax because our parser is not intelligent enough to ignore punctuation marks after the URL; most commonly the problem occurs with parentheses.

Yes, and I'm 99% sure there used to be a style-guide suggesting people use this rather than assuming the software would always autolink plaintext URLs. It seems to have gone now (or I can't find it), and perhaps it dated to when the software was in the process of being rewritten or something.

Personally, though, I would very much prefer if every link had a sensible link text. While I admit the URL is better than "click here", I still think it's pretty lame, and you can *always* find something better.

Yes, there are a few instances where it's valid - like, in order to construct a sentence which tells the user what the address is for future reference, and turns that address into a link at the same time in case they want to go there right now; but mostly, it's just links waiting for a decent description.

It's bug #974082, BTW.

Actually, that's exactly an instance of elegant degradation. In plaintext you get the full information: brief link text plus the URL. With CSS on the web page, we can hide the URL since you'll see it when hovering over the link anyway.

I see your point, but this is information that neither Wikipedia, nor any other website I can think of, traditionally shows *at all* [even Slashdot only puts the domain]. People are usually quite happy to let their browsers tell them where links head if they want to, and writing out the whole URL can take up quite a bit of space and rather breaks up the flow of text and layout that the article's author(s) thought they were creating.

Although your reasons seem sound, your stance raises the question: Does that mean you reject the idea of using the same HTML for different layouts? Thing is, that is the whole purpose of CSS.

Well, I guess it does rather raise that question, but my answer would be that I love the concept of CSS, and the idea of using one page for multiple formattings is great. But in reality, like all things web-based, it has to be done in a way that makes no assumptions about the client's environment - and since it's entirely a client-side technology, that means a lot of compromises. So, for instance, the non-CSS'd version of a page is best written in an order that will make sense for a linear display (e.g. the venerable lynx). I think the non-CSS'd version having the same *information* as the CSS'd one - no more, no less - is similar, but that's just an opinion.

I had another thought, though, about a possibly nicer way of having this option if people really want it - enable it in MySkin but not Monobook, so that people can reconstruct "monobook but with visible link text" if they want, but it's not there by default. That may be more coding than it's worth though, if MySkin is just literally MonoBook minus the CSS; I don't really understand how the skinning works.

On Thu, 2004-07-01 at 00:49 +0100, Rowan Collins wrote:

I'm not sure what a better solution would be, but maybe some JavaScript voodoo to add them or uncomment them. In general, I dislike relying on JavaScript even more than I dislike relying on CSS, but I accept that this option is never going to be viable server-side, and presumably people wanted it.

There is a simple css-only solution in commonPrint.css, currently commented out. Drawback: doesn't work with older browsers like IE, but is fine in Opera, Moz/Firefox and derivates, Safari etc.