On Tue, Sep 9, 2008 at 8:58 PM, Aryeh Gregor
<Simetrical+wikilist(a)gmail.com> wrote:
On Tue, Sep 9, 2008 at 8:27 PM, Ilmari Karonen
<nospam(a)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.
Probably every browser you can think to name supports them. I suspect
that if I added up the user agents known to support it we'd be well
above 99% of all traffic.
My bigger concerns are with things like content-munging proxies,
anti-porno filters, SSL VPN appliances, and the like, breaking things
for clients. Along with truly oddball clients (lynx is not oddball),
and mobile devices. Testing with the logo, however, won't give a good
exercise, but it wouldn't be a bad start.
Some of these may be obscure enough to ignore, some may not. But they
are going to be rare enough that further 'light' pre-deployment
testing isn't likely to find them.
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.
Huh? Did you actually try saving a page?
A protocol relative url is a relative URL. We would use them where
sites normally use relative URLs, but where we currently use fully
qualified URLs because our 'site' spans many domain names (i.e.
en.wikipedia.org and
upload.wikimedia.org).
If you take some relative URLs from a website and merely write them
into a file, of course it isn't going to work. Which is why browsers
do not do anything like that when you save a page.
Browsers support relative URLS in saved copies by rewriting them at
save time. Otherwise all relative URLs would break in saved
documents, and the overwhelming majority of anchors and images on
sites outside of Wikipedia are fully relative paths.
I just tested several browsers and they rewrote protocol relative URLs
just as they do for any other kind relative URL. Images get saved and
work fine. Links get fully qualified out just fine. It just
works(tm).
I also tried this on a captured copy of the Wikipedia HTML. It works
just as I'd expect.
As far as I can tell there is no problem here, but perhaps I'm missing
something.
![src="//upload.wikimedia.org/foo.jpg"/>](http://src="//upload.wikimedia.org/foo.jpg%22/%3E){kind=link}