[whatwg] <a onlyreplace>

[tali garsiel]

 <dd0fbad0910161343s277083c7v4eee5197c15bdfa4 at mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


Some comments:

I think an optimization that enables the server to strip unnecessary content is a MUST.
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.

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.
In this example the URL should not 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.

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.
This means the "onlyreplace" will probably be always the defaults.








----------------------------------------
> From: jackalmage at gmail.com
> Date: Fri, 16 Oct 2009 15:43:25 -0500
> To: Simetrical+w3c at gmail.com
> CC: derernst at gmx.ch; whatwg at whatwg.org
> Subject: Re: [whatwg] 
>
> A few public responses to issues/questions brought up in IRC: (thanks,
> Aryeh and Philip!)
>
> How is this better than  and <a target>?<br />> =========================================================<br />> It's significantly better in multiple ways, actually.<br />><br />> 1. <iframe>s, like frames before them, break bookmarking. If a user<br />> bookmarks the page and returns to it later, or gets deeplinked via a<br />> search engine or a link from a friend, the <iframe> won't show the<br />> correct content. The only way around this is some fairly non-trivial<br />> url-hacking with javascript, altering the displayed url as the user<br />> navigates the iframe, and parsing a deeplink url into an appropriate<br />> url for the iframe on initial pageload. @onlyreplace, on the other<br />> hand, automatically works perfectly with bookmarking. The UA still<br />> changes urls and inserts history appropriately as you navigate, and on<br />> a fresh pageload it just requests the ordinary static page showing the<br />> appropriate content.<br />><br />> 2. <a target> can only navigate one iframe at a time. Many/most<br />> sites, though, have multiple dynamic sections scattered throughout the<br />> page. The main site for my company, frex, has 3 (content,<br />> breadcrumbs, and section nav) which *cannot* be combined to display as<br />> a single <iframe>, at least not without including a whole bunch of<br />> static content as well. You'd have use javascript to hook the links<br />> and manually navigate the additional iframes. @onlyreplace, on the<br />> other hand, handles this seamlessly - just include multiple ids in the<br />> attribute value.<br />><br />> 3. <iframe>s require you to architect your site around them. Rather<br />> than a series of independent pages, you must create a single master<br />> page and then a number of content-chunk mini-pages. This breaks<br />> normal authoring practices (though in some ways it's easier), and<br />> requires you to work hard to maintain accessibility and such in the<br />> face of these atrophied mini-pages. @onlyreplace works on full,<br />> ordinary pages. It's *possible* to link to a content-chunk mini-page<br />> instead, but this will spectacularly break if you ever deeplink<br />> straight to one of the pages, so it should become automatic for<br />> authors to do this correctly.<br />><br />> 4. <iframe>s have dubious accessibility and search effects. I don't<br />> know if bots can navigate <a target> links appropriately. I also<br />> believe that this causes problems with screen-readers. While either<br />> of these sets of UAs can be rewritten to handle <iframe>s better (and<br />> handle @onlyreplace replacement as well), with @onlyreplace they<br />> *also* have the option of just completely ignoring the attribute and<br />> navigating the site as an ordinary multi-page app. Legacy UAs will<br />> automatically do so, providing perfect backwards compatibility.<br />><br />><br />> Isn't if inefficient to request the whole page and then throw most of<br />> it out? With proper AJAX you can just request the bits you want.<br />> ======================================================<br />> This is a valid complaint, but one which I don't think is much of a<br />> problem for several reasons.<br />><br />> 1. One of the big beneficiaries of @onlyreplace will be fairly<br />> ordinary sites that are currently using an ordinary multi-page<br />> architecture. All they have to do is add a single tag to the <head><br />> of their pages, and they automatically get the no-flicker refresh of a<br />> single-page app. These sites are *already* grabbing the whole page on<br />> each request, so @onlyreplace won't make them take any *additional*<br />> bandwidth. It will merely make the user experience smoother by<br />> reducing flicker and keeping js-heavy elements of the page template<br />> alive.<br />><br />> 2. Even though site templates are usually weighter than the dynamic<br />> portions of a site, it's still not a very significant wasteage. For<br />> comparison, my company's main site is roughly 16kb of template, and<br />> somewhere around 2-3k of dynamic page content. (Aryeh - I gave you<br />> slightly different numbers in chat because I was counting wrong.) So<br />> that's a good 85% of each request being thrown away as irrelevant.<br />> However, it's also *only 16kb*, and that's UNCOMPRESSED - after<br />> standard gzip compression the template is worth maybe 5kb. So I waste<br />> 5kb of bandwidth per request. Big deal. (According to Philip`, my<br />> company's site's weight is just on the low side of average.)<br />><br />> 3. Because this is a declarative mechanism (specifying WHAT you want,<br />> not HOW to get it), it has great potential for transparent<br />> optimizations behind the scenes. For example, the browser could tell<br />> the server which bits it's interested in replacing, and the server<br />> could automatically strip full pages down to only those chunks. This<br />> would eliminate virtually all bandwidth waste, while still being<br />> completely transparent to the author - they just create ordinary full<br />> static pages. Heck, you could even handle this yourself with JS and a<br />> bit of server-side coding, intercepting clicks and rewriting the urls<br />> to pass the @onlyreplace data in a query parameter, and have a<br />> server-side script determine what to return based on that. Less<br />> automatic, but fairly simple, and still easier than using JS to do<br />> this in the normal AJAX manner. (And UAs that don't run javascript<br />> but do support @onlyreplace will still work properly, just with a bit<br />> more bandwidth waste.)<br />><br />><br />> What about scripts in the page?<br />> ===============================<br />> Semantically the replace operation should be identical to grabbing the<br />> appropriate chunk of text from the new page and setting is as the<br />> outerHTML of the appropriate element. Any <script>s that are located<br />> within this chunk would run in the exact same manner. Scripts<br />> elsewhere in the new page would not be run.<br />><br />><br />> What about document.write()? What if the important fragment of the<br />> page is produced by document.write()?<br />> ====================================================<br />> Then you're screwed. document.write()s contained in <script> blocks<br />> inside the target fragment will run when they get inserted into the<br />> page, but document.write()s outside of that won't. Producing the<br />> target fragment with document.write() is a no-go from the start.<br />> Don't do that anyway; it's a bad idea.<br /> 		 	   		  
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010