W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Working Group Decision on ISSUE-124 rel-limits

From: Sam Ruby <rubys@intertwingly.net>
Date: Sat, 19 Mar 2011 10:17:17 -0400
Message-ID: <4D84BAED.8080504@intertwingly.net>
To: HTMLWG WG <public-html@w3.org>
The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.

*** Question before the Working Group ***

There is a basic disagreement in the group as to whether or not
"noreferrer" and "nofollow" should be allowed as rel attribute values
on link elements.  The result was an issue, two change proposals, and
a survey:


== Uncontested observation:

  * The positive effect claimed ("less special-casing") is appealing,
    but it only applies from a web authors point of view.

This, in itself, was not decisive.  There were people who supported
each of the two change proposals even after taking this fact into
consideration.  The fact that this was acknowledged up front was

=== Objections to allowing noreferrer and nofollow on link

The strongest objection was the fact that there were no use cases
put forward for this feature.

Additional objections were made on the basis of special-casing required
of user agents; lack of specification of how to handle conflicting
information; potential for the creation of race conditions;
implementation burden on conformance checkers, user agents, and editing
tools; and security.

=== Objections to disallowing noreferrer and nofollow on link

The objections brought forth were that it would be "silly and
unnecessarily inconsistent" and "seems to be no harm".  Perhaps the
most telling statement was the following:

   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.

This statement was made in the context of the purported implementation
burden, but applies equally to the objections to the proposal to
disallow noreferrer and nofollow on link.

In all, we find that there were no strong objections to this proposal.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the Change Proposal to
disallow noreferror and nofollow on "link".  Of the Change Proposals
before us, this one has drawn the weaker objections.

== Next Steps ==

Bug 10172 is to be CLOSED and marked as WGDecision.

Since the prevailing Change Proposal does not call for a spec change, no
further action is required.

As none of the proposals affected the definition or potential placement
of bookmark link types, the status of bug 10412 is unaffected by this
decision.  The chairs have agreed that this portion of the issue is
essentially "closed without prejudice", meaning that receipt of an
acceptable Change Proposal would be sufficient to reactivate this
portion of the issue as a Last Call issue.  In order to reduce
confusion, any such reactivation would likely be tracked with a
separate issue number and the description of such an issue would
contain a link back to the original issue.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition

== Revisiting this Issue ==

This issue can be reopened if new information come up.  An example of
possible relevant new information include:

* Real world use cases that specifically require nofollow/noreferrer
   relation values to be allowed on link elements.

== Arguments not considered

The following argument was not considered for the reason specified:

   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.

We only evaluate change proposals that actually were submitted.
Received on Saturday, 19 March 2011 14:17:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:11 UTC