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

[Ara Pehlivanian]

> 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.

Is the direction being maintained or dropped in the HTML5 spec?

> 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.

Does that mean that search engines ignore XFN attributes? What defines
a third party assertion and what makes a legitimate "first-party"
assertion?

> 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.

I can appreciate the need for backwards compatibility, though I had
heard somewhere that HTML5 was redefining a lot of the existing markup
(or was that XHTML 2?)

> 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'.

You're right, the ambiguity already exists in the badly marked up
data. But don't you think our effort should be spent educating those
who are writing the code rather than compensating for their mistakes?
Because the logical outcome to catering to their errors is a spec that
evolves into something that doesn't make any sense. But if the apps
that are crawling their sites don't pick up on their tags, they'll
quickly wake up to the proper syntax. Kinda of like when Google
doesn't crawl your site because you only have JavaScript generated
navigation links. I think that there's room for compromise. I'm not
saying "let's force the web to run in strict mode" per se, but if new
apps being launched were a little less forgiving, people would adapt
(and actually learn something in the process). I honestly believe the
power to push people toward the adoption of standards (the spec) is in
the hands of app developers and how lenient they choose to be with the
data they consume.

> 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

I meant 'thick' in the nicest possible way (myself included). I'm more
than willing to admit that there's a whole lot that I don't know and I
don't appreciate for a moment that IE3/4 were forgiving of my bad
markup when I was learning to build sites. I stagnated for a long time
building crappy markup because of that.

> 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.

I agree 100% with the idea of interoperability and a common
interpretation of the spec in regards to error handling etc... But I
think a line needs to be drawn in what's defined as an error. I think
it's great that the browser doesn't break when I forget to close a <p>
tag. But it shouldn't go ahead and plow through reams and reams of
badly written code assuming I meant "a" when I wrote "xyz". I should
(as a developer worth his salt) learn to write "a" instead of "xyz"
instead of writing garbage and expecting gold. What ever happened to
GIGO? :-)

> 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.

I think that the spirit of microformats is right in adopting the
standards that are in popular usage (ie adopting vcard for hcard). But
at the same time, I think it's a mistake to adopt bad practices and
use them because "everybody does it". Best example of not doing this
is the steady stream of developers now dropping table based design.
The alternative would have been for the spec writers to say "well,
everyone's using it, let's just alter the spec in the next version to
state that tables are also inteded for use in layout".

I appreciate your taking the time to discuss this.

A.