On Tue, Sep 9, 2008 at 8:27 PM, Ilmari Karonen nospam@vyznev.net wrote:
I think the next step, after the log comparison test we both suggested, would be to set $wgLogo to a protocol-relative URL. A missing logo wouldn't actually break anything, but you _bet_ people would notice it.
Now that's a simple, elegant, effective idea. It would require almost no effort, hurt no one, and give immediate feedback. The only catch with this, as with other image-based proposals, is that a client that doesn't support images (as well as, in the case of the logo, CSS) won't be picked up. But I don't see much help for that. There are few enough of those anyway. lynx does support them, I just checked.
One interesting catch, though, that I just noticed when testing. What happens when someone downloads the HTML to their hard drive and views it locally? lynx assumes FTP as the protocol, which is completely wrong. Firefox, Opera, Konqueror, and Chrome all try to use the *file://* protocol -- which is absolutely reasonable but absolutely terrible for us.
So this means that anyone who tries to save a Wikipedia page using protocol-relative URLs to their hard drive will find that all the relevant links are broken. This is, obviously, not a good thing. I can't see any conceivable workaround, and if there is none I don't see any way we (or anyone) can use protocol-relative URLs. Being able to save web pages locally is pretty basic and important functionality that a lot of people must be relying on.