[whatwg] <a onlyreplace>

On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel <t_garsiel at hotmail.com> wrote:
> Some comments:
>
> I think an optimization that enables the server to strip unnecessary content is a MUST.

Well, as I explained, it's not really a MUST.  Doing an ordinary
navigation requests an entire page, and without optimizations this
does the exact same thing.  You're not burning *more* bandwidth than
normal; you're just slightly changing the effect of it.

That said, such optimizations would be really useful, I agree.  It
could significantly cut down bandwidth use (on my company's site, the
average request would drop from about 20k to about 1.5k).  This could
*really* improve site performance, and even perhaps be good for the
overall net.

> It seems the browser will need to make a distinction between a regular request and a request invoked by a bookmark.
> In case of a bookmark the server should not strip content so the browser must let him know that.

There's no need to make a distinction.  Only requests with onlyreplace
semantics trigger the special behavior.  Typing an address into your
browser won't add those semantics, nor will a bookmark; only links
with @onlyreplace (or links on a page with <base onlyreplace> that
don't override their own @onlyreplace with the empty string) carry the
semantics.

If you're talking about this in terms of optimizations, then the
onlyreplace information would be carried by a request header.  When
the browser doesn't send this header, the server wouldn't strip
anything down.

> In a single page application AJAX updates can be originated in 2 roots:
> 1. The user clicks something in the navigation panel
> 2. The user clicks an action button inside the content panel
>
> An example of use case #2 can be clicking a "save" button.
> In this case the "<a>" tag is usually not used but a button, this means that other tags the? "<a>" should have the "onlyreplace" attribute.

I thought it would be interesting to be able to put @onlyreplace on
forms, or perhaps form submission inputs.

> In this example the URL should not be remembered by the history.

Then you should use ordinary AJAX to do so.  @onlyreplace is supposed
to be merely an optimization on normal navigation.  The url *must* be
remembered by the history.

> There are other cases of use case #2 where the URL should be remembered - like a "next" button on a page-able data grid.

Yup, exactly.  A paged control is a great use-case!  It's extremely
simple to set up (just pass paging info in query params), and
bookmarking works beautifully!

> I think this solution is good for changes of the entire content panel.
> When a specific widget needs to update a data binding solution may be better.

Yeah, this is not meant to be a general replacement for AJAX.  It just
makes a particular set of common cases extremely easy.  In many
circumstances being explicit with javascript is still the better
solution.

> This means the "onlyreplace" will probably be always the defaults.

I'm not sure what you mean here.

~TJ

Received on Sunday, 18 October 2009 07:17:19 UTC