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>
