[whatwg] <a onlyreplace>

[Schuyler Duveen]

Tab Atkins Jr. wrote:
> On Sun, Oct 18, 2009 at 9:42 PM, Schuyler Duveen <whatwg at graffitiweb.org> wrote:
>> Tab Atkins Jr. wrote:
>>> On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
>>> <whatwg at graffitiweb.org> wrote:
>>>> The problem is that people will make links that refresh different parts
>>>> of a document, to the point that the current document is no longer
>>>> addressable.  Use cases for this happen often enough (not necessarily
>>>> good design, but people will do this)
>>>>
>>>> In the past, a good way to give (back) addressability to users is with
>>>> hash tags.  But here, the location changes, and the hash goes away.
>>>> Standard anchor tags (with no javascript) have generally been
>>>> addressable to users by default.  When this hasn't been true, like with
>>>> framesets, lots of confusion and frustration ensues.
>>>>
>>>> If this is, in the longterm, going to work non-dynamically, then things
>>>> should be addressable by default.  It's one of the killer features of
>>>> the web :-)
>>> You're right, and this makes me think more strongly that restricting
>>> the ability to specify the replaceable bits to just <base> is the
>>> right way to do this.
>> I'm starting to think the addressability is the main constraint.  What
>> if the original @onlyreplace anchor tag:
>>
>>   <a onlyreplace="id1 id2" href="page2.html" />
>>
>> would be equivalent to something like this:
>>
>>   <a href="#view(page2.html id1 id2)" />
>>
>> which would process onload or onhashchange as we've been describing
>> @onlyreplace and would appear in the browser's location bar.  A more
>> complicated one (after two jumps) might look something like:
>>
>> http://example.com/page1.html#view(page2.html id1 id2);view(page3 id3)
> 
> Hmm, that's interesting.  So, rather than simply changing the url and
> hoping that the author is maintaining the correct semantics (so that
> visiting the url fresh gives you same/similar results), you just
> explicitly express that the page is a combination of multiple pages.
> 
> I suppose that if, in your example, you then clicked a <a
> href=page4.html onlyreplace=id3>, the url would change to
> http://example.com/page1.html#view(page2.html id1 id2);view(page4.html
> id3); that is, it would record the location each segment was drawn
> from, but not the full history, as that is irrelevant for regenerating
> the page.
> 
> Then bookmarking that url and visiting it again would presumably make
> 3 separate requests, once for page1 for most of the page, and then for
> page2 and page4 for the particular ids.  Right?
Exactly.

These are the use cases I think we're targeting with such addressability:
(when considering some server-side request filter, as well)
1. Avoid flicker and state-reinitialization between similar pages.
2. preserve scroll context across loading similar pages.
3. robots crawling ajax-states reliably (and efficiently)
4. standardize addressability of (most) ajax states
5. Provide AJAX features to static pages that
   are low-hanging fruit.
   (considered as those mentioned above)
6. AJAX pages could also use more structure in the hash-tag
   e.g. to preserve their own state in the hash even while a user
   visits a specific part of the page
7. simplify very standard behavior in AJAX sites, especially in
   contexts that affect accessibility (like dynamic form submission)

/sky