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 13636 - Missing link types
Summary: Missing link types
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2011-08-03 20:32 UTC by Greg Lowney
Modified: 2011-11-24 03:07 UTC (History)
8 users (show)

See Also:


Attachments

Description Greg Lowney 2011-08-03 20:32:24 UTC
It seems that there are quite a few link types that are not yet defined, but that probably should be in order to let accessibility aids provide standardized commands for navigating and operating web sites more easily without requiring the user to read and understand a lot of content and contextual information (e.g. voice or keyboard commands to go do the next page, style sheets that would highlight or enlarge the navigation links, toolbar buttons that provide large mouse targets for navigating, etc.)

HTML WG expressed concern that these aren't widely supported, but that seems to be mostly about the <link rel> in the document header rather than marking up existing, visible links in the document body. It seems to me that (a) authors are more likely to mark up links they're already including than they are to add new, hidden links in the document header, and (b) marking up of links can be encouraged by future versions of WCAG and other accessibility guidelines, and (c) even though mainstream browsers do not expose this markup, it could and may be used by accessibility aids (e.g. speech input utilities) and browser add-ins (e.g. the Link Widgets add-in for Firefox).

It appears that new link types can be added using RDFa or Microformats after HTML5 is finalized, although I doubt they'd get as widely adopted as if they're in the primary spec. I'm even more concerned because the Microformats document states that the HTML5 Working Group explicitly decided to drop support for some link types, including index, up, first, and last (discussed at http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html), and they forbid adding them back into the list of supported microformat rel types. There may or may not be good reasons; I haven't had a chance to review all their arguments. On the other hand, the same decision page says that "these relations are already registered in the IANA link relation registry", and they seem to be, leaving me quite confused about the relationship between the IANA link relation registry, the rel microformats listed on microformats.org, and the link rel values listed in the HTML5 spec.

Also, as I suggested elsewhere, it's good to be able to mark up things other than links in the same way, as in identifying a name as the source document or author even if there's no link to it. Presumably WAI-ARIA could eventually do this, but doesn't that mean a lot of overlap between it and the link types? Alternatively, HTML5 could simply allow rel attribute on a elements that don't have href attributes, so that rel could be used to annotate things other than usable links. This is currently forbidden.

Some examples of real-world link types that aren't now but could potentially be standardized include (names just placeholders):

    content-feedback - link to page or email address for providing feedback on the topic of the page (e.g. to comment on the blog posting)
    content-support - link to a page or email address for support on the site or topic of the site (e.g. product support for the software discussed by the page)
    content-edit - link to edit the current content
    content-preview - link to preview edited content before submitting
    site-feedback - link to page or email address for providing feedback on the web site
    site-support - link to page or email address for getting support on the web site
    sitemap - link to a page containing a sitemap for the web site
    index - link to an index
    contact - link to a contact page (although the name has already been reserved for another purpose--a huge drawback to microformats)

    types for navigating a site or collection of related documents:
        site - a link to the home page for the web site (which may include multiple subsites or multipage documents, e.g. w3.org/)
        subsite - a link to the home page for the subsite or document collection (e.g. w3.org/WAI/)
        up* - a link to the page that is logically the parent of the current page (e.g. on http://www.w3.org/WAI/gettingstarted/Overview.html it would be a link to w3.org/WAI/)
        first* - a link to the first document
        last* - a link to the last document
        first-child - a link to the page that is the logically-first child page

    types for navigating through a document broken up into multiple pages:
        continued-first
        continued-prev
        continued-next
        continued-last

* indicates types explicitly deleted by the HTML5 Working Group.

To understand the difference between links for navigating through a site or collection of documents vs. navigating through pages of a single document or article that's broken into multiple pages, consider that it's common for discussion forums, to feature one set of navigation links for going between topics (e.g. "next-in-collection"), and another set of links for going between pages of posts within the current topic (e.g. "next-in-continuation"). This could still be confusing, but we should at least consider it.
Comment 1 Julian Reschke 2011-08-03 20:36:42 UTC
This seems to be a misunderstanding. There's a registry for new link types; they do not need to be defined in HTML5.
Comment 2 Michael[tm] Smith 2011-08-04 05:35:21 UTC
mass-move component to LC1
Comment 3 Michael[tm] Smith 2011-11-20 15:12:16 UTC
Greg, this bug waiting for you to respond to comment #1:
> This seems to be a misunderstanding. There's a registry for new link types;
> they do not need to be defined in HTML5.
Comment 4 Ian 'Hixie' Hickson 2011-11-24 02:42:35 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: For each link you want to add, you should first get implementation experience, and add it to the wiki.