[whatwg] <a onlyreplace>

On Thu, Oct 22, 2009 at 9:47 AM, Daniel Glazman
<daniel.glazman at disruptive-innovations.com> wrote:
> Tab Atkins Jr. wrote:
>
>> I actually consider that a loss. ?It's addressing a different problem,
>> you see. ?HTMLOverlays is basically client-side includes. ?While you
>
> It's client-side only because I implemented in JS that way! Explain
> me what prevents from implementing server-side?

Nothing, of course, but then it seems equivalent to any other
server-side-include mechanism.  It may have a better syntax for many
cases (in fact, it looks like it probably does), but it's otherwise
relatively unremarkable and doesn't require any changes to browsers.

Specifically, it doesn't do anything like what @onlyreplace does.
Navigation still involves a complete tear-down and refresh of the
page, js state, etc.

>> I think you misunderstand the mechanics of @onlyreplace. ?It doesn't
>> change anything when you first load a page, and it shouldn't be at all
>> similar to prefetching. ?It only operates when you click on a link
>> with the @onlyreplace attribute. ?The browser then makes an ordinary
>> request for the desired page, parses it with scripting disabled, and
>> locates elements with the given ids to swap into the old page.
>
> Exactly. And I said this is a good start and not enough. We could do
> simple AND more powerful than that.

Can you elaborate?  If you understand @onlyreplace, then you must be
hinting at a larger abstraction than I can see currently.  To my eyes
@onlyreplace and overlays (XUL, HTML, or otherwise) only share some
basic surface similarities, in that they both have a "replace an
element with one from another document with the same id" mechanic.
The way that mechanic is used, and the effect it has on the page, the
UI, the user experience, and the browser is completely different.

~TJ

Received on Thursday, 22 October 2009 08:09:04 UTC