- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Thu, 22 Oct 2009 08:56:46 +0200
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 :-) 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... - 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... [1] http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html [2] http://www.w3.org/Submission/1997/12/ </Daniel>
Received on Wednesday, 21 October 2009 23:56:46 UTC