- From: Nelson Menezes <flying.mushroom@gmail.com>
- Date: Sun, 18 Oct 2009 16:00:57 +0200
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. >> 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. >> 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
Received on Sunday, 18 October 2009 07:00:57 UTC