W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Simple Links

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Tue, 03 Aug 2010 15:56:56 +0000
Message-ID: <4c583c5f.9decd80a.16c9.ffffc980@mx.google.com>
> On Tue, Jul 27, 2010 at 3:13 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I also randomly picked a Wikipedia page (Potato) and looked at some of th=
> e
> > links there. The only link that matched that pattern on the whole page wa=
> s
> > in the footer that only gets displayed in the print media:
> >
> > =C2=A0 <div class=3D"printfooter"> Retrieved from "<a href=3D"http://en.w=
> ikipedia.org/wiki/Potato">http://en.wikipedia.org/wiki/Potato</a>"</div>
It's also presented to unknown UAs (as Wikimedia assumes they're dumb bots).

> For what it's worth, this is because the href's in the articles
> themselves have /wiki/ prepended (<a href=3D"/wiki/Potato">, not <a
> href=3D"Potato">).  In turn, this is because the pages can actually be
> served from multiple directories: http://en.wikipedia.org/wiki/Potato
> is the same as http://en.wikipedia.org/w/index.php?title=3DPotato.
> (There are actually some differences at the moment if you do a diff,
> but that's because they're cached separately by Squid.  If you log in,
> the differences should disappear.)  So href=3D"Potato" would do the
> wrong thing in the latter case.
> Indeed, in a dynamic web application, something like href=3D"Potato" is
> practically useless unless you can guarantee that you're always
> rewriting URLs to look pretty and conceal the actual script serving
> the request.  So in particular, MediaWiki could not use the proposed
> <a href> syntax.
I consider the equivalence of /wiki/Potato and /w/index.php?title=Potato
a bug. Metadata such as the URI of the document can be served by various
means, such as the Location header in HTTP, and a seperate "base" URI to
use for relative linking can be specified with the <base> element in HTML.

> Ian Hickson:
> > On Tue, 30 Mar 2010, Christoph P=E4per wrote:
> >> I wonder whether HTML could and should provide some sort of similar =
> shortening, i.e. =93<a href>Foo</a>=94 or even, just maybe, =
> =93<a>Foo</a>=94.
> I later came to the conclusion that this might be a nice thing for HTML =
> editors, but not for browsers.=20
> If nothing else, it would probably be abused for comment spam, because =
> there probably are scripts out there that do not filter =91href=92-less =
> =91a=92-elements.
> >> The UA would append the string content, properly encoded, to the base =
> Web address as the hyperlink=92s target, =85
> >=20
> > I (=85) couldn't find any pages that matched the pattern <a =
> href=3D"(.+)">$1</a>, =85
> Um, that=92s not exactly what I meant, note =93append =85 to the base =
> Web address=94.
> These are conversions I had in mind, assuming the location =
> <https://example.com/Bar/baz.html>:
> derived href value
> <a href>Foo</a>            =3D> /Bar/Foo or ./Foo or Foo
> <a href>Foo.html</a>       =3D> /Bar/Foo.html or ./Foo.html or =
> Foo.html
> <a href>Foo.com</a>        =3D> /Bar/Foo.com or ./Foo.com or Foo.com
> <a href>Foo/</a>           =3D> /Bar/Foo/ or ./Foo/ or Foo/
> <a href>/Foo</a>           =3D> /Foo
> <a href>#Foo</a>           =3D> #Foo
> <a href>/</a>              =3D> /
> <a href>http://Foo.com</a> =3D> http://foo.com
> <a href>://Foo.com</a>     =3D> https://foo.com (?)=

According to RFC 3986, section 4.2, the first component of a relative
reference can't contain a colon (':'). The last example should be:
<a href>//Foo.com</a>	https://foo.com

We don't need to define a new "append" algorithm, relative [IU]RI
references are powerful enaugh.
Received on Tuesday, 3 August 2010 08:56:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:59 UTC