[whatwg] <a onlyreplace>

[Aryeh Gregor]

On Sat, Oct 17, 2009 at 1:22 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> Also, what should happen if the user presses the 'back' button?

It should be the same as for regular navigation.  If the UA usually
stores some page state in a cache when the user navigates, it should
store the same state.  If it doesn't have the previous contents cache,
it should reload, assuming that's what it normally does.

On Sun, Oct 18, 2009 at 11:51 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> Okay, so possible revision: <base onlyreplace="foo"> carries a list of
> ids to replace.  This automatically makes all links and forms on the
> page carry the onlyreplace semantics.  You can turn this off for
> specific links by setting @noreplace (a binary attribute) on the link
> or form; activating/submitting them will trigger a normal navigation.

By "all links and forms" do you really mean "all same-domain links and
forms"?  Even that's too many.  Consider a typical site with a forum
at /forum and a wiki at /wiki.  You don't want links from one to the
other to try onlyreplacing.  Even within an app it can be complicated.
 MediaWiki is often installed in both /w (actual files) and /wiki
(fake rewrite path), and you'd probably want links to everything in
/wiki but only some things in /w to be affected.

Perhaps <a onlyreplace> should be a boolean attribute.  Opting links
into onlyreplace seems safer than opting them out.  In many cases you
might be injecting some raw HTML into the page, like using a template
system or JavaScript, such that adding noreplace to all links you're
unsure about would be tricky or impossible.  Opt-in is much easier to
verify.

In any event, this variant is fairly disastrous for copy-pasting.
What you thought meant "load only foo and bar from the target" might
suddenly mean "load only baz and quuz from the target", and the result
will probably be that the link completely fails.  I think sticking
only to per-<a> attributes is a safer idea, one way or another.

Also, I anticipate that on many pages that would like to use this
feature, only some unpredictable minority of links would actually need
it.  I don't think there will be any way to identify which ones
without some kind of case-by-case human intervention, so I don't think
<base> would be terribly useful.


Some attention needs to be given to error handling.  What happens if
one or more of the requested id's aren't found?  Do they silently
fail?  If so, this could result in the link doing absolutely nothing
in hard-to-control situations -- like an error page that occurs
sporadically, say a 500.  Do they trigger a normal page load?  If so,
they have to wait until the entire page has loaded, which would be bad
user experience but hard to track down -- a long, inexplicable delay
followed by everything working normally.  This could be mitigated by
having an HTTP header to say "that id doesn't exist, load the whole
page instead", but it would fail in the default case (standard HTTP
server unaware of new feature).

Also, what happens if some of the given id's are present, but not others?


One final observation is that this method isn't ideal for fixing
flickering, because often you'll want to change everything at once --
you just don't want it to flicker.  For instance, consider a case
where you have a navigation pane and a content pane.  Changing pages
will change the content pane, but also sometimes cause a different
item to be highlighted in the navigation pane, or cause some
contextual items to disappear and reappear, etc.  However, a solution
to that has all the advantages of the onlyreplace proposal, that's
simple to describe using existing functionality, and works well with
URLs, but doesn't kill all script handlers and such, seems hard.

On Sun, Oct 18, 2009 at 12:22 PM, tali garsiel <t_garsiel at hotmail.com> wrote:
> 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 :)

I don't think the scenario is realistic.  You can't usually get away
with calculating anything very expensive on page load, because then
page load would take unacceptably long.  Calculations like this that
you want to run as infrequently as possible are normally cached on the
server side, in my experience.  If they weren't you'd re-run the
calculations every time the user navigates away and then back, or
reloads the page.  I don't see why that would be acceptable if the
behavior you describe isn't.