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