[whatwg] <a onlyreplace>

[Tab Atkins Jr.]

On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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"?

Yes.

> 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.

I think the opposite.  If I upgraded my site to this, I'd want nearly
all the links to onlyreplace.  There's only a handful of same-origin
links that I'd instead want to trigger a full load.

> 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.

It's true that this could be bad on copypasta, but is your failure
scenario going to be common?  Are people going to often use different
<base>s on different pages in the same origin?  I think more usually a
single origin will have the same <base onlyreplace> everywhere, or
else not have <base onlyreplace> at all.  In the latter case, you'd
presumably want all links to trigger full navigation, since that's
what you're indicating with the lack.

(Also, the same problem you note happens similarly with per-<a>
onlyreplace - what if you copy a link from one page to another, and
the new page has *different* elements with the same #ids as elements
in the old page?  Then you'd be replacing random bits of the page.  Is
this situation more/less likely than the one you brought up?)

> 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.

I disagree, and think that most links would use it on a typical page.

> 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?

I'll think a bit about these issues today.  I'm not sure, off the top
of my head, what the best response is.

> 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.

You'd just hook the links with javascript and use that to change the
navigation-pane highlight.  (Or, in some cases, harness CSS, such as
by using the proposed pseudoclass that matches links to the current
document.)

~TJ