onderhond

While I don't dispute any of those points, we (as an industry/community) should have matured enough by now to realize the dangers. "Don't develop for a specific browser" should be common knowledge and best practice no 1. Apparently many people still don't get it, and frankly I'm not surprised. Looking at home we promoted html5 and css3 these past two years, not nearly enough attention was spent on thinking things true when educating other, sharing demos that are basically just browser-specific examples.

Actually, the meta data you're talking about is there. You can even test the page to see that it should work (though it never appears like that in Google search results for me): http://www.google.com/webmasters/tools/richsnippets?url=http...

As for complexity, some classes are hard to grasp without a good reference list (like wtf is FN (formatted name)? I'm not saying it's rocket science, but it's still a lot more work (front-end and back-end) than adding class="contact person" to your base tag.

>> Generally ordered sequences are designed to be read from the start

The spec makes no such claims, it just talks about sequences of documents in a very generic way. If the spec is not clear on this, it should be changed first.

And in a search context, I definitely don't agree with your interpretation of "sequence". The fact that my hit is part of a sequence is secondary to the fact that I just want to see a hit on my search query.

Mind you that I don't necessarily disagree with your nuances on the various use cases, but the current spec is clearly written to be very generic and should be interpreted as such.

Google bases their actions on dry information harvested from people. Human science does not exist without statistics, and statistics requires you to make assumptions. Google can analyze me till kingdom come, it cannot correctly predict what I prefer at a certain moment in time. And as for big companies making documented assumptions, check what Facebook rolled out today in their news feed.

In situations where user preference is key, the only option is to leave the decision to the individual user. I don't mind if Google implements this and offers it as a service to their users, but deciding based on dry statistics is never good, it leaves people frustrated and makes it impossible for authors to properly implement a spec like this.

It's quite funny to criticize a html-guy on worrying about semantics ... seriously, it's the core of html and the core of my every day job.

If you want a more detailed explanation, check the "sad semantics" section here: http://www.onderhond.com/blog/work/html5-meet-world-irony

Whatever the w3c would like to be, there is a different reality, namely what people perceive them to be. Client, back-end programmers and other non-front-end people alike look to the w3c when it comes to front-end. And seeing they've just launched a community site built around a silly logo, I'm sure they are a tad more than a simple standards body.

If they are not happy with their public image, it's up to them to make it clear (and not through a few paragraphs on their oh-so-usable site).

The problem is that the subheading in my articles is really part of the main heading. Without it the heading itself loses meaning. When using the hgroup tag only the main title is considered for the document outline so I'm losing valuable information there. As for the fix, I'd rather split both titles in the h1 tag itself. That way both titles remain 1 whole, even for the document outline.

Sure, but why would you still want to use the other hn elements? The only reason I see is for subheadings within a hgroup, but I'm not a big fan of that tag.