W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] <a onlyreplace>

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Thu, 22 Oct 2009 11:35:22 +0200
Message-ID: <4AE0275A.3010108@disruptive-innovations.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC