[whatwg] <a onlyreplace>

2009/10/17 Jonas Sicking <jonas at sicking.cc>:
> On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> Promoting this reply to top-level because I think it's crazy good.
>>
>> On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
>>> On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>>> As well, this still doesn't answer the question of what to do with
>>>> script links between the static content and the original page, like
>>>> event listeners placed on content within the <static>. ?Do they get
>>>> preserved? ?How would that work? ?If they don't, then some of the
>>>> benefit of 'static' content is lost, since it will be inoperable for a
>>>> moment after each pageload while the JS reinitializes.
>>>
>>> Script links should be preserved somehow, ideally. ?I would like to
>>> see this be along the lines of "AJAX reload of some page content,
>>> without JavaScript and with automatically working URLs".
>> [snip]
>>> I'm drawn back to my original proposal. ?The idea would be as follows:
>>> instead of loading the new page in place of the new one, just parse
>>> it, extract the bit you want, plug that into the existing DOM, and
>>> throw away the rest. ?More specifically, suppose we mark the dynamic
>>> content instead of the static.
>>>
>>> Let's say we add a new attribute to <a>, like <a onlyreplace="foo">,
>>> where "foo" is the id of an element on the page. ?Or better, a
>>> space-separated list of elements. ?When the user clicks such a link,
>>> the browser should do something like this: change the URL in the
>>> navigation bar to the indicated URL, and retrieve the indicated
>>> resource and begin to parse it. ?Every time an element is encountered
>>> that has an id in the onlyreplace list, if there is an element on the
>>> current page with that id, remove the existing element and then add
>>> the element from the new page. ?I guess this should be done in the
>>> usual fashion, first appending the element itself and then its
>>> children recursively, leaf-first.
>>
>> This. Is. BRILLIANT.
>
> [snip]
>
>> Thoughts?
>
> We actually have a similar technology in XUL called "overlays" [1],
> though we use that for a wholly different purpose.
>
> Anyhow, this is certainly an interesting suggestion. You can actually
> mostly implement it using the primitives in HTML5 already. By using
> pushState and XMLHttpRequest you can download the page and change the
> current page's URI, and then use the DOM to replace the needed parts.
> The only thing that you can't do is "stream" in the new content since
> mutations aren't dispatched during parsing.
>
> For some reason I'm still a bit uneasy about this feature. It feels a
> bit fragile for some reason. One thing I can think of is what happens
> if the load stalls or fails halfway through the load. Then you could
> end up with a page that contains half of the old page and half the
> new. Also, what should happen if the user presses the 'back' button?
> Don't know how big of a problem these issues are, and they are quite
> possibly fixable. I'm definitely curious to hear what developers that
> would actually use this think of the idea.

I have spent most of last night trying to figure out what's wrong with
this proposal. I can't think of anything important except for the back
button behaviour. The suggestions I had have already been mentioned:
the <base> tag extension and the marker HTTP headers. You'd obviously
also need a JS hook to be able to invoke this functionality
programmatically (location.onlyreplace...?)

Another plus point for this idea is that it is implementable on
existing browsers with some JS (I'm trying something simple at the
moment and it works, albeit only for XML documents).

As for the back button, there are a few possibilities:

- Reload the full page
- Load & process the document using the same "onlyreplace" behaviour
as explained in the original email
- Allow a response header that specifies which of the above the
browser should do on clicking the back button
("backwards-navigation-safe: True"?)
- The browser remembers the state of the document as it was prior to
each history point and resets it to that state before applying the
point in history we are jumping to (yikes!)

Any concerns about caching that aren't covered by the above?

Nelson Menezes
http://fittopage.org

Received on Saturday, 17 October 2009 02:51:19 UTC