[whatwg] <a onlyreplace>

[Tab Atkins Jr.]

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

This seems compelling.  I agree, then.  @onlyreplace on <base> defines
the id-list, and then @onlyreplace on links/forms says "I should carry
the onlyreplace semantics".  In the former case it's a space-separated
list of IDREFs, in the latter it's a binary attribute.

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

Hmm?  No it doesn't.  The @onlyreplace still makes the page *way*
easier to handle.  Needing a little bit more js to hook extra behavior
around doesn't seem unreasonable.  (It's better than refreshing the
navlist just to highlight a new section.)

~TJ