[whatwg] <a onlyreplace>

[Schuyler Duveen]

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
> **************************************
>