w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-124: Allow noreferrer and nofollow on <link> - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2011-02-20 to 2011-02-28.
7 answers have been received.
Jump to results for question:
- Objections to the Change Proposal to allow noreferror and nofollow on "link"
- Objections to the Change Proposal to disallow noreferror and nofollow on "link"
1. Objections to the Change Proposal to allow noreferror and nofollow on "link"
We have a Change Proposal to allow noreferror and nofollow on <link>. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the Change Proposal to allow noreferror and nofollow on "link" |
|---|---|
| Philip Jägenstedt | No use cases are given for allowing noreferrer or nofollow on <link>. The change proposal claims less special-casing as a positive effect, but this is only from a web authors point of view. For browsers, it would likely lead to more special-casing (code sprinkled around to handle this), as loading of inline resources (like CSS) via <link> follows rather different code paths than navigating to a new page via <a> or <area>. Finally, the change proposal doesn't specify how to handle conflicting information like this in a page: <link rel="stylesheet noreferrer" href="foo.css"> <link rel="stylesheet nofollow" href="foo.css"> Is the effective set of keywords "noreferrer", "nofollow" or "noreferrer nofollow"? Presumably both browsers and search engines would be clever enough to only issue one request, but should the search engine consider "that the link is not endorsed by the original author or publisher of the page" and should a browser "not include a Referer (sic) HTTP header"? |
| Anne van Kesteren | I object to this proposal on the grounds that it does not state a use case. Making relationships more general is not necessarily a benefit and I do not believe we should strive for generality in general. We should strive to address use cases in the best way possible. |
| Martin Kliehm | I don't see a real use case for <link rel="nofollow"> or <link rel="noreferrer">, therefore I'm against this and in support for the no-change proposal. |
| Theresa O'Connor | The CP does not state any use cases for this change; it's not clear if allowing authors to specify noreferrer and nofollow on <link> Solves Real Problems <http://www.w3.org/TR/html-design-principles/#solve-real-problems>. As pointed out by Philip, such a change would introduce a race condition in the loading of stylesheets, and thus fails to have Well-defined Behavior <http://www.w3.org/TR/html-design-principles/#well-defined-behavior>. The positive effect claimed ("less special-casing") is appealing, but theoretical purity is at the bottom of our Priority of Constituencies <http://www.w3.org/TR/html-design-principles/#priority-of-constituencies>. This race condition is a potential source of confusion for web authors, and thus this CP puts theoretial purity ahead of web authors, inverting our Priority of Constituencies. |
| David Baron | The Referer header provides a useful function to authors: it allows finding the resources that refer to another resource when reference is a sign that an update is needed: for example, use of an obsolete style sheet or image (say, the old version of the company logo). This is the sort of feature that the original author may not believe he's going to need, due to overconfidence... but in the future he (due to failed memory of the distant past) or his replacement may need. Providing ways to opt out of this sort of feature thus defeats its purpose. If those opt-outs don't have a strong use case, they shouldn't be added. |
| Toby Inkster | No objection per se, though I think that the "nofollow" link type is poorly named, and is probably too esoteric to include in the HTML5 spec at all - it could be moved out of the HTML5 spec and into whatever registry the HTMLWG settles on for extension link types. |
| Julian Reschke |
2. Objections to the Change Proposal to disallow noreferror and nofollow on "link"
We have a Change Proposal to disallow noreferror and nofollow on <link>.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the Change Proposal to disallow noreferror and nofollow on "link" |
|---|---|
| Philip Jägenstedt | |
| Anne van Kesteren | |
| Martin Kliehm | |
| Theresa O'Connor | |
| David Baron | |
| Toby Inkster | The RDFa and microdata specs don't differentiate between the rel attribute on LINK and on other elements. It seems silly and unnecessarily inconsistent to allow <a href="noreferer next">...</a> to create a link to the next page which will not send an HTTP Referer header, and will possibly be included as part of a browser's navigation toolbar (or in Opera for the Fast Forward feature), while not allowing the corresponding <link> to do the same. For nofollow there are perhaps fewer use cases for including them in <link> elements, but there also seems to be no harm in allowing them to appear there. The advantages of allowing it to appear on <link> would be the reduction of differences between rel on different elements, making HTML easier for authors, and simplifying writing HTML tutorials. |
| Julian Reschke | I find none of these objections particularly convincing; they all seem to be based on different opinions about what is "simple" and what is not. See detailed response in <http://lists.w3.org/Archives/Public/public-html/2011Feb/0472.html>. |
More details on responses
- Philip Jägenstedt: last responded on 21, February 2011 at 08:14 (UTC)
- Anne van Kesteren: last responded on 21, February 2011 at 14:37 (UTC)
- Martin Kliehm: last responded on 21, February 2011 at 14:45 (UTC)
- Theresa O'Connor: last responded on 24, February 2011 at 17:43 (UTC)
- David Baron: last responded on 26, February 2011 at 18:26 (UTC)
- Toby Inkster: last responded on 27, February 2011 at 14:00 (UTC)
- Julian Reschke: last responded on 28, February 2011 at 15:46 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project