[whatwg] <a onlyreplace>

Daniel Glazman schrieb:
 > Hi there,
 >
 > That onlyreplace attribute is not enough, and trust me, I have
 > spent quite a while on solutions transforming HTML documents using
 > bits contained in external instances...
 >
 > Hixie referenced at some point in the thread my HTMLOverlays proposal
 > [1] and that proposal has a clear plus compared to the onlyreplace
 > attribute: it's not meant to ONLY replace but ALSO to add elements to
 > an existing container, using an order defined by the web author and not
 > only appending overlaid elements.
 > That's a _major_ win compared to onlyreplace.
 >
 > I am not saying here that onlyreplace is a bad idea, it's even a very
 > good one. And I find VERY amusing to read super-positive comments about
 > it that are exactly contrary to comments I received myself on
 > HTMLOverlays while the two proposals are rather similar :-)

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.
- 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.

 > That said, there are a few problems to solve:
 >
 > - what means exactly "replacement" here? What's the scope of a
 >   <script> element?
 > - what does it mean for stylesheets and scoped stylesheets?
 > - what does it mean for the root of the replaced subtree? Let's call
 >   that the bound element and the binding : how are deferred to the
 >   subtree even handlers attached to the bound element?
 > - I don't like <a onlyreplace> because that works only with elements
 >   inside the body of a document. I want a generic mechanism that can
 >   apply to elements in head too...

Are you sure about that? I assumed this was valid:

<html>
   <head>
     <title id="title">My title</title>
     <style id="mystyle">
       @import url(mystyle.css);
       #contents h2 { color:red; }
     </style>
     <script>
       alert("This one is not replaced");
     </script>
     <script id="script2">
       function foo() { alert("bar"); }
     </script>
     <base onlyreplace="title mystyle script2 contents">
   </head>
   <body>
     <ul id="navigation">
       <li><a href="otherpage.html" onlyreplace></li>
     </ul>
     <div id="contents">
       <p>Text</p>
     <div>
   </body>
</head>

Anyway, it might be reasonable to always replace the <title> element, as 
it is recommended to have individual titles for every page, and looks 
like an overkill to give this unique element an id, just to reference it 
in the onlyreplace list.

 > - 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?

Received on Thursday, 22 October 2009 02:13:30 UTC