[whatwg] <a onlyreplace>

[Tab Atkins Jr.]

On Sun, Oct 18, 2009 at 10:07 AM, Nelson Menezes
<flying.mushroom at gmail.com> wrote:
> I guess the <base> @onlyreplace would probably be an important part of
> making this truly useful. There might be too many maintainability
> problems stemming from having @onlyreplace all over the place on links
> (imagine having 5 sections on the page that need updating and dozens
> of links... and then adding a 6th section).

Yup, my thought exactly.

> I wonder, though, if there might be a problem with this after all...
> picture this:
>
> ...
> <a onlyreplace="div1 div2" href="ingredients.html">Ingredients</a>
> <a onlyreplace="div2" href="nutrition.html">Nutrition</a>
> <a onlyreplace="div3" href="preparation.html">Preparation</a>
> ...
> <div id="div1"></div>
> <div id="div2"></div>
> <div id="div3"></div>
> ...
>
> Let's say I click the links in order (Ingredients, Nutrition,
> Preparation), and now bookmark the page (it's now preparation.html).
> When I return to it, #div1 and #div2 will only be populated if
> preparation.html is guaranteed to contain the same content as the
> other two documents. There are a lot of testing paths to guarantee
> that's the case... does this make the mechanism too fragile?

Ooh, that... is a problem.  I mean, if this is used properly it
shouldn't ever happen, obviously, as every page should be a valid
page.  But the example you described above seems very possible, with
authors thinking that it's okay to create 4 nearly identical pages,
with the sub-pages containing only particular bits filled in (not just
content chunks, but still "incomplete").  This degrades badly (just
following each link gives you only partial recipes).  I'd like
bookmarking to return you to something as similar as what you were
looking at before as possible.

The better would be to have only two pages, foo-empty.html and
foo-complete.html, with the links grabbing particular bits from
foo-complete.  Then bookmarking would take you to foo-complete, which
isn't horrible.

Ideally, though, we should never have this situation at all.  Using
@onlyreplace for information hiding is stupid; that's what <details>
was made for, and it does it *way* better (instantaneous replacement,
no bandwidth waste, bookmarking is fine).

So, hmm.  Is this enough of a problem that we have to address it?  If
it is, probably the best thing to do would be to remove the id list
from <a> and only leave it on <base>, with some attribute on links to
indicate whether they should trigger an onlyreplace or a normal
navigation.  That way all links carrying the onlyreplace semantic will
replace the same bits, making the above scenario impossible.

This eliminates many useful cases for onlyreplace, though.  Frex, say
you have a documentation site, with a main-nav up top, a fancy
treeview section-nav on the left, and documentation pages on the
right.  Clicking one of the mainnav links should replace both the
section-nav and the doc page, but clicking on a section-nav link
should only replace the content.  I suppose this is still possible by
just making the main-nav links trigger a normal navigation, the
section-nav links trigger an onlyreplace navigation, and having <base
onlyreplace="content">.

I feel this may still render onlyreplace unusable for more complex
single-page apps, though.  I dunno, this may be ok - perhaps those
apps are complex enough that we can't meet their needs with a
mechanism this simple anyway.  This limitation wouldn't really hurt
the simpler use-cases that I envisioned (ordinary pages which want to
enhance their static area with heavy js, but don't want the cost of
reloading libraries on every navigation and having things move around
as they get manipulated every time).

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.

Can anyone think of any concrete cases that were addressed well by the
older suggestion, but are now impossible with this newer revision?
I'm sure there are some, I just want to assess how valuable they may
be before I decide to cut them off.

~TJ