- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 22 Oct 2009 08:59:41 -0500
On Thu, Oct 22, 2009 at 1:56 AM, Daniel Glazman <daniel.glazman at disruptive-innovations.com> wrote: > 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 actually consider that a loss. It's addressing a different problem, you see. HTMLOverlays is basically client-side includes. While you can hack it into solving a similar problem to @onlyreplace, that's not its primary purpose and the bookmarkability seems like it would be poor. (Note - bookmarkability of abusing htmloverlays as a navigation mechanism, not of using them as intended.) @onlyreplace is simply a way of specifying slightly different navigation semantics on your links. The original page load is the same as normal (unlike HTMLOverlays, where the initial request is a partially-empty page), and navigation is what's changed (unlike HTMLOverlays, which utilize normal navigation and just slot in the overlays again on pageload). Different solutions to different problems. > 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 :-) I think that's because we're doing different things, like I said. ^_^ There's a very small target in the problem-space I'm working in that's good, while nearly everything else is bad. If people interpreted HTMLOverlays as solving the same problem as what I'm trying to solve with @onlyreplace, then yeah, it's a bad solution. It may be fine at solving its own problem. > That said, there are a few problems to solve: > > - what means exactly "replacement" here? What's the scope of a > ?<script> element? "replacement" is semantically identical to setting outerHTML on the target elements. I'm not sure what you mean by "scope of a <script> element". > - what does it mean for stylesheets and scoped stylesheets? Nothing special. > - 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? The entire subtree is replaced, root and all. Event handlers attached to the root or any child are lost. Either reregister them in the swapIn event, or use event delegation on an ancestor. > - 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... Hm? There's nothing about @onlyreplace that only works for <body> elements. Where did you get that impression? (I'd like to know so I can reword things if needed.) As long as an element has an id it can be replaced. > - 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... I think you misunderstand the mechanics of @onlyreplace. It doesn't change anything when you first load a page, and it shouldn't be at all similar to prefetching. It only operates when you click on a link with the @onlyreplace attribute. The browser then makes an ordinary request for the desired page, parses it with scripting disabled, and locates elements with the given ids to swap into the old page. ~TJ
Received on Thursday, 22 October 2009 06:59:41 UTC