- From: Markus Ernst <derernst@gmx.ch>
- Date: Thu, 22 Oct 2009 11:13:30 +0200
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