Working Group Decision on ISSUE-118 broken-link-types

Question before the Working Group

The current HTML5 draft includes a some definitions of particular
link relations that do not exactly match what was defined in previous
specifications. In particular, these are the so-called document
structure rel values, index, up, first, last, prev and next, and the
related or synonymous begin, start, top, contents, toc and end. Some
WG members feel this change from past specifications is
unwarranted. Others believe that more weight should be given to
experience based on authoring practice.

This scope of this decision covers how the set of link relations
should be changed in light of compatibility considerations. A section
below details what arguments were not considered, a number of which
were not considered due to scope reasons.

Uncontested observations

Document structure rel values are not used in a consistent way by different authoring tools.

Neither of these were decisive by themselves. There were people who
supported each of these three proposals even after taking these facts
into consideration.

Summary of Arguments

Three different proposals were submitted, each advocating a
different way of dealing with the rel values in question.

Regarding the "Simplify the rel model" proposal

The first proposal advocates the current draft definitions of
document structure link relations.

One supporting argument for this particular set of link definitions
(and therefore objection to the other proposals) was the claim that
existing rel values are "a mess". While it was generally conceded that
many rel values are not used with full consistency, the conclusion
that they are "a mess" was disputed. There was not a great deal of
supporting evidence on either side. Furthermore, if existing usage is
poor, that does not necessarily argue for one set of new definitions
over another. Thus, this was a weak argument, and a weak objection to
the other proposals

Another argument for this change was that document structure rel
values are not very widely implemented in browsers. Once again, this
does not argue for any specific change; if anything, it calls for
removing these rel values entirely, unless they have some use case
other than UI in the browser.

A final argument was that WordPress is one of the biggest users of
these rel values, so it's worthwhile to be consistent with it. In
particular, WordPress uses "index" to mean start page, and no other
CMS system cited uses it at all. One counter-argument presented was
that WordPress users need to upgrade frequently, so it's more
reasonable to invalidate WordPress than other
implementations. Furthermore, other CMS systems are more consistent
with the historical definitions of document structure rel values. This
argument is a wash, because it's not clear why being consistent with
some CMS systems is more important than being consistent with others.

Regarding the "Well founded consolidation" proposal

The second proposal argues for several specific changes to link
relations. Some link relations are redefined to be more in line with
historical usage, and some additional synonyms are added.

One argument for this set of changes is that HTML5's definitions of
link types conflict with HTML4, XHTML1, and other previous
standards. By itself, this is a relatively weak objection to other
proposals - in past decisions, the Working Group has generally
prioritized real-world compatibility over matching older versions.

Another raised for this proposal are that HTML5's
definitions of link types conflict with some some browser
implementations (including Opera). However, it was pointed out that
most mainstream browsers do not support these link relations at all;
only Opera has UI for them, the UI is hidden by default, and Opera
representatives have said it is going to be removed. Thus, this is a
weak objection at best to removing link relations or altering their
definitions relative to HTML4.

Further arguments in favor of this proposal cited compatibility
with use in some CMS systems, notably excluding WordPress; and with
use in some specific hand-authored documents (in particular W3C
specifications). This is useful concrete evidence. However, it is a
relatively weak objection to other proposals. The evidence from CMS
systems is mixed, and the set of hand-authored documents does not
appear to be a representative sample.

Regarding the "Drop support for rel values" proposal

The final proposal argues for the removal of some relation values,
to wit, it suggests removal of index, up, first and last. It was
pointed out in survey comments that these relations are already
registered in the IANA link relation registry. Presumably, these
relations could also be entered in whatever other registry or
registries HTML5 adopts for this purpose. In support of this proposal,
and against the proposals to retain or alter these relations, a number
of arguments were presented.

It was pointed out that support is quite scarce. Document structure
rel values are relatively rarely used. Popular Web browsers have no
default UI to expose document structure rel values (Opera has UI that
is hidden by default), though prev and next are used for some non-UI
purposes. Hand-authored pages very rarely use these rel values, though
they are often used in template-generated pages. This is a moderately
strong argument, and a significant objection to keeping the relation
types in HTML5, whether modified or as-is. When an extension mechanism
exists, then it does not seem essential to keep marginally important
features in the core.

Several objections were presented to this proposal. It was claimed
that removal of particular rel values may be ineffective because they
are already rarely implemented, and Opera already plans to remove
their support. However, this seems like an argument in favor of
removal, rather than against.

Second, the SeaMonkey browser as well as browser extensions support
document structure link relations, including some that are not defined
in HTML5 at all, even in the proposal. But this objection did not
explain why the existing registration at IANA and/or possible
registrations elsewhere would be inadequate for these use cases. So
this was a weak objection.

Finally, it was noted that the link relations being dropped are
already defined in the IANA registry and could be defined in future
registries; but in the meantime these relations would become invalid,
thus invalidating a great deal of content. Since validators do not
implement relation checking at all yet and are waiting on a registry
solution before doing so, this was also a weak objection.

Overall, the objections to the proposal to remove several relations
were the weakest. No objection explained why registration as
extensions was insufficient, and such registration would allow more
time and freedom to fine-tune the definitions of these relations,
independent of the HTML WG.

Decision of the Working Group

Therefore, the HTML Working Group hereby decides to adopt the
proposal to drop support for rel="" values based on the lack of
interest from implementors and users.

Next Steps

bug
7475 will be reopened and tagged WGDecision, with instructions to
the editor to adopt the proposal to drop support for selected rel
values. Once the edits are made, the bug and issue will both be
closed.

Since the relations to be removed are already registered at the
IANA link relation registry, no further action is needed to include
them there. WG members are free to register or record these relations
elsehwere, as well.

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

Revisiting this Issue

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

Demonstrations of wider implementation in mainstream clients, such as the most popular browsers or search engines.

Evidence of growing popularity among authors.

Additionally, bug reports on the definitions of relation types that remain in the spec continue to be welcome.

Arguments not considered

It was claimed that people may criticize HTML5 more unless the set
of link relations changes from the current draft. However, objectors
are expected to speak for themselves, not for others. Predicted
third-party reactions are not a relevant consideration.

It was claimed that the "contents" link type, used to refer to the
table of contents may not provide a useful distinction compared to a
main or start page. No evidence or supporting argument was given for
this assertion.

Some objected to the removal of some link relation types on the
basis will leave us with only a few relation types. But whether to
reduce the set of relation types is a key part of what is at issue, so
this argument does nothing but restate the question.

It was claimed WordPress is likely to be willing to be willing to
change its use of rel values, thus, matching the usage of WordPress is
not important. This was once again a claim on behalf of a third party,
with no evidence for the assertion.

It was argued that using 'index' for a start page rather than an
index is illogical/confusing. No evidence was provided for this
assertion.

Using 'start' for the first page in a sequence rather than a home
page is illogical/confusing. No evidence was provided for this
assertion.