- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Thu, 22 Oct 2009 11:35:22 +0200
Markus Ernst wrote:
> They are crucially different in some points:
> - HTMLOverlays is a ready-to-use script solution. It does not require
> any specification nor implementation by UAs. Instead, it requires work
> on the authoring side; using HTMLOverlays means totally re-writing your
> websites.
It's ready as a script, yes, and that is absolutely not satisfactory.
It's so simple that it could be specified and implemented by browsers.
> - HTMLOverlays does not degrade nicely. If a UA does not support
> scripting, or the script is not found for any reason, there is no way to
> render the page in a useable manner. This also applies to search
> engines, which will not see anything that is part of the overlay - this
> will typically apply to the whole navigation.
Agreed, and that's why I think a standardized solution is better.
> > - I think a mechanism using a <link> element is better because it's
> > similar to prefetching. It's also semantically better because it
> > used a _very_ old proposal of mine called "link dereferencing" [1].
> > And of course it is better because it can help resolving the
> > progressive rendering issues of <a onlyreplace> since the head
> > is parsed before the body...
>
> Can you give a code example how this could look like?
>
Sure. That only requires to extend the rel attribute to any element.
Semantically, it's perfectly ok since onlyreplace is really establishing
a link of some sort to a potentially external resource.
<head>
<link id="myreplacement"
rel="prefetch"
href="http://www.example.com/foo.html#bar"/>
</head>
<body>
<p rel="replace" src="#myreplacement"/>
</body>
</Daniel>
Received on Thursday, 22 October 2009 02:35:22 UTC