- From: Schuyler Duveen <whatwg@graffitiweb.org>
- Date: Sat, 17 Oct 2009 22:52:40 -0400
If you'd like to see what this looks like in Javascript, I implemented this technique several years ago. One place you can see it publicly is the swapFromHttp() function at: http://havel.columbia.edu/media_panels/js/MochiPlus.js You can see it in action on some pages like: http://havel.columbia.edu/media_panels/video_window/?material=abrams where it adds in the page on the left from this file http://havel.columbia.edu/media_panels/materials/abrams.html 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. 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.  ) 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/ 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). cheers, sky > Date: Sat, 17 Oct 2009 11:34:25 -0700 > From: Jonas Sicking <jonas at sicking.cc> > To: Dion Almaer <dion at almaer.com> > Cc: Markus Ernst <derernst at gmx.ch>, "Tab Atkins Jr." > <jackalmage at gmail.com>, Aryeh Gregor <Simetrical+w3c at gmail.com>, > whatwg <whatwg at whatwg.org> > Subject: Re: [whatwg] <a onlyreplace> > Message-ID: > <63df84f0910171134j193e35exf4d79dcddc5ded13 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Oct 17, 2009 at 11:16 AM, Dion Almaer <dion at almaer.com> wrote: >> This feels like really nice sugar, but maybe the first step should be to get >> the shim out that gets it working using JS now.... and then see how it works >> in practice. I totally understand why this looks exciting, but I have the >> same uneasiness as Jonas. ?It feels like a LOT of magic to go grab a page >> and grab out the id and ..... and I am sure there are edges. Cool idea for >> sure! It also feels like this should work nicely with the history/state work >> that already exists. > > Yeah, I think this puts the finger on my uneasiness nicely. There's > simply a lot of stuff going on with very little control for the > author. I'd love to see a JS library developed on top of > pushState/XMLHttpRequest that implements this functionality, and then > see that JS library deployed on websites, and see what the experiences > from that are. > > If it turns out that this works well then that would be a strong case > for adding this to browsers natively. > > In fact, you don't even need to use pushState. For now this can be > faked using onhashchange and fragment identifier tricks. It's > certainly not as elegant as pushState (that is, after all, why > pushState was added), but it's something that can be tried today. > > / Jonas > > > ------------------------------ > > _______________________________________________ > whatwg mailing list > whatwg at lists.whatwg.org > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > > > End of whatwg Digest, Vol 67, Issue 81 > ************************************** >
Received on Saturday, 17 October 2009 19:52:40 UTC