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 13577 - ISSUE-118 CP 3, rel="start" and friends, rant
Summary: ISSUE-118 CP 3, rel="start" and friends, rant
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other All
: P3 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/mid/20110630064507....
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-03 05:40 UTC by HTML WG bugbot
Modified: 2011-12-02 19:05 UTC (History)
6 users (show)

See Also:


Attachments

Description HTML WG bugbot 2011-08-03 05:40:16 UTC
public-html-comments posting from: Driedfruit <driedfruit@mindloop.net>
http://www.w3.org/mid/20110630064507.66f11a49@driedfruit.mindloop.net

Hello list!

Recently, the w3c validator began spitting errors on some of the rel
links. That came as quite a surprise to me, even a shock. I always spend
some time to provide "rev" coverage to my websites, as far as I know,
everybody does. It was considered one of best practices just yesterday?

I'm talking about "Document structure rel values" ("rel links" form
now on), and their recent removal from HTML5 spec. Gasp!

> Document structure rel values are not widely implemented in
> mainstream Web browsers.

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

I fail to understand how this reasoning is applicable _at all_?
Absolutely everything discussed on those lists falls into this category.
Otherwise we wouldn't need the specs to guide us. By that logic (and
jumping back in time), we don't need well-formed HTML either, because,
hell, neither IE5, neither NN4, neither FrontPage Express, neither
DreamWeaver actually produce/consume well-formed HTML.

But that's rhetorics. Yet, a very practical and real problem stands
before me. How do you define a "parent" element in a hierarchy of
documents? If "next" and "prev" denote a collection, how do you define
"first" and "last" elements of such a collection?

Your options are:
 - Use HTML4.01
 - Wait for some matching Microformat to appear (keeping in mind,
   that "start", "up" and friends are *explicitly* forbidden from
   ever reappearing)

Which are not options at all, if you wish to do it TODAY. While that
situation might've been fine for some cutting edge technology, like
VIDEO tag, it's in no way fine for such a classic HTML feature.

Sometimes, it makes no sense to use those links, as the data is not
really hierarchical/structured anyway. More often then not, that's not
the case.

> This feature is used by virtually nobody. None of the major browsers 
> display any user interface by default for this feature; the only
> major browser to even remotely support this feature is Opera, which
> hides its interface by default in recent releases. Hand-authored Web
> pages largely don't use it; the main use is from pages that are
> generated from templates that have been configured to use the feature
> (e.g. WordPress and automatically generated HTML man(1) pages).
>

The reason for the apparent disinterest in the feature is very simple:
the notion of "semantic web" became popular only recently. People
drudgingly accepted the idea they have to remove presentation from
their content, they accepted removing behavior from their content with
even a larger effort. Why would separating navigation and content be
any different?

The feature was considered a staple of "semantic web" long before the
term was popularized. Now, that it *is* popularized, I can only imagine
"rel" links booming, not dying out. For example, Dive Into HTML5
(arguably, a major force behind HTML5 adoption) promotes the use of
such "rel" tags, so we can expect to see more of those, not less.

One more consideration: rel links in general (not the rel="start" and
friends, but newish ones) are becoming more and more popular. With
rising popularity it is feasible to imagine major browsers
a) Returning the NAV bar to include new rels (like "author").
b) Extensions appearing that pray on those links.

> NEGATIVE EFFECTS
> ================
>
> None.

What? Where do I even start?

Why having machine-readable, semantical, deterministic links is
important.

1. Separation of content and presentation. 

I'm surprised that mantra was not in a way of ISSUE-118 CP 3. Without
the "ref" links authors must resort to their own schemas, breaking
interoperability between different websites. 

By using custom CSS and JavaScript one can tailor his web experiences
to his own liking. Well, almost. There's no reliable method to target
the navigation. Are those the links inside the <nav><ul> ? Maybe it's
the role="" that could tell us? What if that particular site's
navigation is in the <footer> ?

Rel links provide an answer. Simple, logical and reliable answer.

2. Limited browsers.

Text-only browsers like "links" are not used by choice, or to make
one look cool. They are used from graphic-less consoles over 88x24
terminals with no other Internet in sight (because the machine in
question was routing the Internet). They are used from livecds,
busyboxes, superuser modes, etc.

Such browsers can obviously present problems with whatever layout is
used. If you're lucky, and a <ul> at the very top of the page was used,
good for you, if it's something more obscure, too bad.

Such browsers are *excellent* at handling the rel links. Always were.

3. Manuals and Books.

Because almost all manuals (man pages, doc books, unixy stuff) there
are, are formatted with them. That works nicely together with point 2.
But it also helps with converting books FROM HTML into other formats.
Moving freely up and down between sub-sections is a virtue.

4. Accessibility.

Screen readers. Keyboard shortcuts. Having the navigational menu always
in your view, without the need to "scroll back to top" or other
awkwardness. 

5. Novelty browsers.

I think Apple's touchpad demonstrated that idea well. Tap for "next".
Shake for "up". Twist for "last". Imagine various new uses. Imagine
various devices that could leverage this information.

6. Crawlers and other robots.

Poor fellas. I guess they'll just have to fetch ALL the links from a
page and "guess" which one most likely leads "up".

7. Fans.

Some people will miss them dearly, just because they were a neat
concept. For example see this screenshot of navbar-powered UA in action:

http://oliwer.net/nichu/img/130942303350.png

.....

Ok, this is getting a bit repetitive, guess I made my point clear by
now.

> This issue can be reopened if new information come up. Examples of
> possible relevant new information include:
> ....
> Evidence of growing popularity among authors.

It's hard to imagine growing popularity considering the validator
errors. That alone might kill adoption faster then anything else being
discussed! And that worries me!

I hope that it's not too late to get invloved. I liked the proposal
which said "make them all synonymous to each other and embrace current
use-cases the most", but I'd give anything to have our good old "messy"
HTML4 rev links back right now.

Please *do* tell if there are other (better?) places for this message to
be posted.

Thank you,

driedfruit
Comment 1 Michael[tm] Smith 2011-08-04 05:34:24 UTC
mass-move component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-12-02 19:05:59 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: The spec reflects the chairs' decisions on the matter.