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