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
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
