[whatwg] <a onlyreplace>

[Tab Atkins Jr.]

On Mon, Oct 19, 2009 at 5:37 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, Oct 19, 2009 at 1:10 PM, Markus Ernst <derernst at gmx.ch> wrote:
>> Aryeh Gregor schrieb:
>>> But it breaks progressive rendering, which could be extremely
>>> annoying.  The user might give up after a second or two of no
>>> response, as the (possibly quite long) page is fetched and parsed.
>>
>> This is true. So using this as a feature to exclude pages from being
>> "onlyreplaced" should be discouraged, authors should set onlyreplace to
>> false (resp. not set the onlyreplace attribute) on the links to those pages.
>
> The problem I see here (as an author) is that the attribute *will*
> accidentally get placed where it shouldn't.  From the user's point of
> view, this dramatically slows down clicking the link (making them
> annoyed at my site), but in a way that's very difficult for me to
> notice.  It's an X% chance that clicking a given link will be
> inexplicably slow, at random, if I use this feature.  The value of X
> will vary based on all sorts of things, some possibly beyond my
> control.  It's a risk that would definitely count against the feature
> if I were deciding whether to use it.

Actually, though, I think that the problem won't be nearly as bad as
you're implying.

You're imagining that it takes as long to decide if the requested
elements are in the page as it would take to actually render the page.
 This is *far* from true.  Looking at the Net panel data in Firebug
for my company's website on a full refresh, actually downloading the
page takes only 150-200ms.  I'm told that the actual parsing is
basically insignificant compared to network latencies.

Assuming that the DOM-building proceeds identically to that employed
by responseXML (except allowing HTML, as XHR2 says), in the worst-case
scenario embedded scripts may run in case of document.write() (though
Anne says that he plans to *not* run scripts while parsing HTML into
responseXML), but linked scripts won't ever download.  And, of course,
once the DOM is built checking for ids is trivial.  So for a typical
page (as I said earlier, my company's page is apparently just on the
low end of average) we're looking at response times under half a
second.

~TJ