[Bug 13577] New: ISSUE-118 CP 3, rel="start" and friends, rant

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13577

           Summary: ISSUE-118 CP 3, rel="start" and friends, rant
           Product: HTML WG
           Version: unspecified
          Platform: Other
               URL: http://www.w3.org/mid/20110630064507.66f11a49@driedfru
                    it.mindloop.net
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mike+html-wg-mailbot@w3.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 August 2011 05:40:18 UTC