[uf-discuss] Vote Links: rel="voted-for"

[Ryan King]

On Jan 23, 2007, at 10:44 AM, Ara Pehlivanian wrote:

>> I disagree.
>>
>> First of all, you don't need both @rel and @rev for votelinks. Right
>> now you just need @rev to declare votes. Linking in the opposite
>> direction doesn't add anything, as it is a 3rd party assertion (or
>> hearsay).
>>
>> Secondly, if people can't figure out how to use it properly, they'll
>> use it improperly. Then people building tools will have to deal with
>> that confusion. It's better to just make the technology simpler and
>> unambiguous.
>>
>> Removing @rev is not hobbling HTML5. Very few people who use it
>> properly and even more use it improperly. See Google Web Authoring
>> statistics for more data [1].
>
> As I'm sure you're already aware, two discreet bits of data are
> communicated via the rev/rel attributes. The attribute itself
> communicates the direction of the relationship while the value states
> the type of relationship. By dropping one of the directions, you
> introduce ambiguity in the data.

I understand that the attributes, as defined specify the direction of  
the relationship. However, it has been found in practice that people  
confuse these and misuse the two attributes. So, that ambiguity is  
already there in practice, but not reflected in the specification.  
HTML5 is a step towards having the spec better line up with the real  
world.

> At least one real world example for the implementation of a rev/rel
> relationship exists: my previously stated "site of the month"
> scenario. A vote using rev is made for a site of the month. That site
> in turn will link back to the originator via an icon with a rel. This
> would properly describe the forward/reverse relationships between
> sites. To a machine crawling the vote icon (rel), it will properly
> pick up the URL of as the source for the vote and not a site that's
> being voted for. Similarly, if a machine were to crawl the site where
> the "sites of the month" are picked, it would know that this is the
> originator who is voting (rev). The ambiguity caused by ignoring the
> direction of the vote could really throw off stats when tallying
> votes. And that's just one example.

I'm not saying we should ignore the direction of links. I'm saying  
that we can only really annotate them in one direction. As someone  
who works for a search engine, I can safely say that third-party  
assertions (eg, "that site over there voted for me") are unhelpful  
and usually ignored.

> I don't agree that rev should be dropped in order to fall in line with
> the way rel is being (badly) used today. Rather, if a change is to be
> made to the spec, it would make more sense to revisit the entire
> attribute set so as to come up with something that is easier to
> use/understand while still being able to define a direction for the
> relationship as well as a type.

WHATWG's mission is to make HTML5 backwards compatible with the way  
that HTML4 is deployed today. Revisiting the entire attribute set  
would be out of the question. But, of course, I can't speak for them.

To reiterate my main point, @rel and @rev are often confused by web  
authors today, which means that people writing consuming applications  
must treat them as such. When a web page says <link  
rev=stylesheet .../> you can't take it at it's word. That's just the  
way things are, and it'd be unreasonable to try and change the entire  
web to work in 'strict mode'.

> Either that, or we should stick with
> the existing spec and simply require developers to understand and use
> it correctly. Nobody dumbs down compilers because of thick coders, why
> is this any different? It took me a couple of posts on this list and I
> ended up learning.

I wouldn't call people 'thick' just because they don't understand the  
difference between @rev and @rel. I've seen numerous people (myself  
included) mistake the two. Hey Tantek, why don't you tell everyone  
the story about how you and Kevin confused the two and wrote the  
wrong one into vote-links? :D

> If the spec just ends up bending to the popular usage, then what's the
> point behind the standards movement? We may as well invest our time
> writing better error correction.

The point is to build interoperable implementations, not make ideally  
pure languages. If you'll go read more about HTML5, you'd realize  
that large parts of its parsing section are about specifying a common  
error handling mechanism. Without that, there's little hope of having  
large numbers of user agents who can interpret an HTML document the  
same way.

Also, 'bending to popular usage' is what microformats are all about.  
We try and figure out how people are already using the web, the  
vocabulary that they use and the common use cases, then document that  
into a microformat. Formats and applications should follow behavior,  
not try and create it.

-ryan
--
Ryan King
ryan at technorati.com