[whatwg] <a onlyreplace>

[Aryeh Gregor]

On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> 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.

It's very common for several web apps to be installed under a single
domain, with links from one to the others: the wiki, forum, and CMS
all linking to each other, say.  These links are often added to
templates by admins as static HTML that the app doesn't even look at.
Having them break horribly when the next version of the software uses
onlyreplace isn't helpful.  Basically, if you're outputting *any* HTML
without parsing and sanitizing it, opt-out isn't acceptable, since you
*can't* opt out of links in that HTML.  And every web app I'm familiar
with (admittedly that's about two) does output some HTML without
parsing and sanitizing it.

Keep in mind that if you can't opt out when you need to, the link will
fail.  If you can't opt in when you need to, the link will work, just
trigger a full reload.  Opt-in is a much better idea for that reason
alone, given that many apps won't be able to sanitize some of the
links they output.

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

I didn't remember that it would only be same-domain.  You're right
that that's a mitigation.  But yes, I'd very much expect the same
domain to often use different onlyreplace.  Different web apps will
have different onlyreplaces, and different web apps are often on the
same domain.

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

I'd hope id collision would be rare enough that this isn't a huge
issue.  MediaWiki tries to prefix all new classes and id's with mw-
for this sort of reason.  id's like "content" are likely to show up
pretty often, though, you're right.  (And in fact MediaWiki does have
an id="content" in the default skin.)

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

I'm not sure anymore.  It depends how it's used.

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

Well, okay.  That completely defeats the ease of use of this proposal, though.