This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22737 - Add link type "prerender" to html5 spec
Summary: Add link type "prerender" to html5 spec
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 enhancement
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-19 19:56 UTC by arvind
Modified: 2016-04-22 17:10 UTC (History)
10 users (show)

See Also:


Attachments

Description arvind 2013-07-19 19:56:59 UTC
I'm requesting adding link type "prerender" to the html5 specification. It is similar in nature to the existing link type "prefetch" in the specification.

The "prerender" keyword is meant to be a hint to the browser to load a webpage in anticipation of a user navigation. It's implemented in Chrome and IE11 as an experimental feature.

We discussed this in the Web Performance working group and on html wg:
http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0013.html
http://lists.w3.org/Archives/Public/public-html/2013Jul/0014.html

I've written below the proposed addition to the html5 spec below. Please let me know if you have any comments on it and what would be the next step in considering this addition to the spec.
Thanks,
Arvind

4.13.5.10 Link type "prerender"
The prerender keyword may be used with a link, a, and area elements. This keyword creates an external resource link.

The prerender keyword indicates that preemptively fetching and loading the specified resource in a hidden top-level browsing context is likely to be beneficial, as it is highly likely that the user will navigate to this resource. If the resource is navigated to, the user agent may replace the current browsing context with the one it loaded the specified resource in. 

The user agent may discard the browsing context corresponding to the prerendered resource if any of the following is true:

- If the resource is not navigated to within a reasonable amount of time.
- If the user navigates to some other resource from the current browsing context.
- If the link element is removed from the document.
- There is no default type for resources given by the prerender keyword.
Comment 1 Julian Reschke 2013-07-19 20:53:04 UTC
New link types do not need to be defined in the spec; see <http://www.w3.org/html/wg/drafts/html/master/links.html#other-link-types>
Comment 2 Sam Ruby 2013-07-22 19:19:14 UTC
Generally we don't add new features while a specification is in CR; the default is to put new features into the queue for 5.1.  Furthermore, nothing will get added unless it can meet the exit criteria for CR.

I also agree with Julians comment.
Comment 3 Jatinder Mann [MSFT] 2013-07-23 20:56:41 UTC
The suggested spec text states: "If the resource is navigated to, the user agent may replace the current browsing context with the one it loaded the specified resource in." If you replace the current browsing context, you will lose history. For example, the section on browsing contexts, http://www.w3.org/html/wg/drafts/html/master/browsers.html#windows, states that "A browsing context has a session history". I don’t think we want a prerendered page to lose its history.

I think we may want to update that sentence to instead say something like: "If the user chooses to navigate to this resource, the user agent may navigate the current browsing context to the specified resource."
Comment 4 Philippe Le Hegaret 2013-07-30 14:47:57 UTC
Based on Arvind text and Jatinder addition, I made the following:
 http://microformats.org/wiki/rel-prerender

and updated the HTML5 link type extensions table consequently.

I'm still interested in pushing this into the main HTML spec as well. If
prefetch is there, prerender has a place as well imho.
Comment 5 Silvia Pfeiffer 2013-08-10 11:12:47 UTC
Is it sufficient to add to HTML5.1?
Comment 6 Silvia Pfeiffer 2013-08-10 11:16:59 UTC
Philippe: would your http://microformats.org/wiki/rel-prerender page be removed and prerender be added to http://microformats.org/wiki/existing-rel-values after adding to the html5.1 spec?
Comment 7 arvind 2013-08-10 13:59:03 UTC
Yes once you add the text for prerender in the HTML5.1 spec, we can remove the  http://microformats.org/wiki/rel-prerender page.
Comment 8 Julian Reschke 2013-08-11 06:11:58 UTC
Are you going to add the other relations as well?

What's the point of the registry btw then?
Comment 9 Silvia Pfeiffer 2013-08-11 07:47:06 UTC
I'm likely missing some history here, so your help is appreciated. Can you tell me what were the criteria for having the ones that are listed in http://www.w3.org/html/wg/drafts/html/master/links.html#linkTypes be part of the HTML spec rather than the registry?
Comment 10 Michael[tm] Smith 2013-08-11 12:27:06 UTC
I'm not necessarily advocating for rel=prerender to be added to the HTML spec but it seems like the difference between it and most other values documented on the Microformats wiki is that rel=prerender affects UA behavior.
Comment 11 Ian 'Hixie' Hickson 2013-08-19 23:10:29 UTC
FWIW, this will probably end up specced in the WHATWG spec in due course.

(It's not clear to me why this has to exist separate from rel=prefetch, by the way. As rel=prefetch is defined, it seems to completely allow for the behaviour of rel=prerender. Also, if we do spec this I guess we should spec the processing model, in particular, how the WindowProxy object is supposed to handle having two "active" documents at the same time, and so on. Tests would be useful.)
Comment 12 Arron Eicholz 2016-04-22 17:10:58 UTC
HTML5.1 Bugzilla Bug Triage: Incubation needed

This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3].
[1] https://github.com/w3c/html#contributing-to-this-repository
[2] https://www.w3.org/community/wicg/
[3] https://wicg.github.io/admin/intent-to-migrate.html