[whatwg] <a onlyreplace>

[Schuyler Duveen]

Nelson Menezes wrote:
> 2009/10/18 Ian Hickson <ian at hixie.ch>:
> 
>> On Sat, 17 Oct 2009, Schuyler Duveen wrote:
>>> One of the big issues we found using it on some other sites is that
>>> javascript listeners (rather than onclick="" attributes), and other DOM
>>> pointers in the system became stale.  Thus, only half the problem was
>>> solved.
> 
> Well, you are effectively destroying and regenerating parts of your
> DOM so whatever JS event handlers you have in place need to be updated
> on refresh. That is no different from what happens today with AJAX, or
> indeed multi-frame JS.
My point (which feeds on Marcus Ernst's point) is that we need some kind
of load event.  Maybe something like:
document.addEventListener('replaceonly')
with the event object providing access to the new DOM content and the
old DOM node.

>>> Also, the problem (as I implemented it) is that XMLHttpRequest.xml has
>>> been very finicky in past (and current) browsers.  My comments in the
>>> code reflect some of the things you need to make sure you're doing to
>>> make it work across browsers (at least if you want a DOM vs. regex
>>> implementation):
>>>
>>> * IE 6 needed the Content-type: text/xml
>>>
>>> * Firefox (?2.x) wants xmlns="http://www.w3.org/1999/xhtml" in html tag
>>>
>>> * IE and Safari don't handle named entities like   well in this
>>> context and should be numeric (e.g.  )
> 
> I ran into the same problem, but it is possible to invoke in current
> browsers their HTML parsers by injecting the responseText of
> XMLHttpRequest (as opposed to responseXml) into a temporary Document
> (in a temp iframe). I would imagine it would be a requirement for
> implementing browsers to use the same parsing rules on the
> "onlyreplace" document as they would for a normal document. Indeed, it
> should be no harder to build a onlyreplace document than any other,
> since the same document would be usable interchangeably in both
> contexts.
> 
>>> Vendors might better serve us by reducing these hoops to jump through so
>>> a javascript library could do the job reliably.
>>>
>>> This method did make it much easier to leverage server template code.
>>> But since it largely simplifies server template code, then why not stick
>>> with server-side solutions like Ian Bicking's:
>>> http://blog.ianbicking.org/2008/09/08/inverted-partials/
> 
> The possibility remains to use partial content responses to optimise
> resource usage (via the proposed "onlyreplace" HTTP header), but the
> point of this proposal is that it makes it easy to address the
> no-UI-refresh requirement without a complex server- and client-side
> framework, and offers transparent fallback. It is not so much that
> this can't be done today (it can) but that we would standardise and
> promote the way to do it right.

I like this idea a lot.  It seems like a job for the HTTP Content-Range
header (using a different word than 'bytes').

One other thought:
It might be a good idea to allow the server to explicitly demand a full
load.  (I.e. a server-side equivalent to window.top=location)

There's still seems like a big danger in addressability.  Yes, it's a
problem in ajax, but it's a problem that authors can solve on their own
with hash tags (in ad-hoc ways).  When the browser takes over the
location value, the author's ability to do that is undermined.  Maybe it
should all *stay* in the hash tags like your implementation has it.

Something like:
http://example.com/#id1=page2;id2=page3;
where the value is the most recent source URL for that @id.

cheers,
sky

>>> It's still a bit weird that this proposal, instead of allowing every
>>> element to be a link (like XHTML2), would allow every element to be
>>> something like an IFRAME (all while a thread remembering how evil
>>> framesets are continues).
> 
> But this doesn't make different elements behave like iframes since
> every link still corresponds to a single document, so it doesn't break
> navigation or bookmarking.
> 
>> My recomendation would be to follow the process for adding features:
>>
>>   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>>
>> In particular the bit about experimental implementations. I think this
>> idea looks very interesting, but it's hard to evaluate without concrete
>> experience with a browser implementing this (or, as Jonas suggests, a
>> library that hacks it in).
> 
> http://test.fittopage.org/page1.php ?
> 
>> It seems like the kind of thing that we could adopt early on in the next
>> feature cycle, if it turns out to be a good solid model.
> 
> Is there a mailing list for HTML 6?  :-)
> 
> [1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
> [2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html
> 
> Nelson Menezes
> http://fittopage.org
>