[whatwg] <a onlyreplace>
whatwg at graffitiweb.org
Sun Oct 18 09:20:04 PDT 2009
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
>>> pointers in the system became stale. Thus, only half the problem was
> 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:
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
>>> * 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
>>> Vendors might better serve us by reducing these hoops to jump through so
>>> 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:
> 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.
where the value is the most recent source URL for that @id.
>>> 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:
>> 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? :-)
>  http://msdn.microsoft.com/en-us/library/aa155133.aspx
>  http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html
> Nelson Menezes
More information about the whatwg