[whatwg] <a onlyreplace>
t_garsiel at hotmail.com
Sun Oct 18 09:22:21 PDT 2009
<BAY117-W90F5B859CD291AC4E373B83C20 at phx.gbl>
<dd0fbad0910180717q60e0c0f5l12e81a337af57dc8 at mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
When I said an optimization is a must I didn't just mean bandwidth.
Imagine this use case:
You have a page with a chart and a table showing data calculated from complex statistical analysis on your huge database.
Both the chart and the table have "refresh" buttons implemented with "<a onlyreplace ...>".
Recalculating the chart when you refresh the table or vice verse will not be acceptable by your project manager :)
The server will need to know what is currently requested.
The solution is not necessarily to strip the content, but the server must get information of the updated parts and choose what to calculate.
> From: jackalmage at gmail.com
> Date: Sun, 18 Oct 2009 09:17:19 -0500
> Subject: Re: [whatwg]
> To: t_garsiel at hotmail.com
> CC: simetrical+w3c at gmail.com; derernst at gmx.ch; whatwg at whatwg.org
> On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel 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 that
> don't override their own @onlyreplace with the empty string) carry the
> 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 "" tag is usually not used but a button, this means that other tags the "" 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
>> This means the "onlyreplace" will probably be always the defaults.
> I'm not sure what you mean here.
Keep your friends updatedeven when youre not signed in.
More information about the whatwg