The "WhatWG's Mine is Mine" Design Principle kerfuffle

I'm not part of the HTML WG, but still follow along. Enough to see that one of the big ongoing debates lately is about the HTML WG's Design Principles draft document. There are too many threads to link, but I would suggest the following as good places to start:

• Laura Carlson's initial question about the document [1]
• minutes: HTML WG Weekly 21 May 2009 [draft] [2]
• Henri Sivonen's reference to the "cowpath" section of the document [3]
• Discussion continued into June in W3C Archives [4]
• David Dailey specifically addressing the misuse of the document [5]
• Maciej Stachowiak stating "Since this principle states a design preference, and not a fact about the world..." [6]
• "I think some people, i.e. Laura and Larry, expect the Design Principles to be used as rules, rather than as means of explaining" [7]
• "Wow is Laura really azsking[sic] for quantitative principles...That's...crazy" [8]
• Laura Carlson stating "Principles that use wishy-washy rhetoric are not principles at all.They are judgment calls, completely subjective to the personal opinion of the person invoking the principle or authoring the spec." [9]
• And it continues into June on the HTML WG email list [10]
• The original poll on the Design Principles document [11]

I think some people, i.e. Laura and Larry, expect the Design Principles to be used as rules, rather than as means of explaining

My own opinion of the document, and the discussion surrounding the document, is that the HTML WG Design Principles document is imprecise, vague, and vulnerable to use by self-justifying entities—OK, if you just want a fuzzy feel-good document that looks good in the press, but not something you want to see from a formal W3C Note, which is what the Design Principles wants to be...when it grows up. Definitely not something you want to see used to enforce, or justify, design decisions.

There have been numerous objections to the Design Principles document, in the past and in the current debate, not all of which have been addressed. In my opinion, though, what's more important is that provisions in the HTML WG Design document have been used to shoot down discussion and debate about namespace support in HTML, support for RDFa, and the introduction of the microdata section:

• DOM Consistency and RDFa [12]
• "When you do, please consider the HTML Design Principles..." [13]
• Are you still considering? [14]
• DOM...consistency [15]
• Every time the DOM is inconsistent, a kitten gets it—because developers _never_ have to code for implementation differences... [16]
• DOM Consistency and RDFa and namespace support [17]
• A variation of "We get to play, too?" [18]
• "...seems to be a great example of how to abuse the design principles" (in discussion related to @profile) [19]
• Evidently not. "Since it [RDFa] wasn’t designed with the HTML Design Principles in mind, it should come as no surprise that RDFa violates several of them, and so isn’t suitable for inclusion in the Web platform." [20]
• Now, what part of the "pave the cowpath" or "don't reinvent the wheel" principles in the Design Principles document explain the introduction of Microdata? [21] I get easily confused.

But I don't want RDFa to hog all of the focus. Other groups and interests have also been gently schooled in the HTML Design Principles:

• Related to Meeting with SVG, XHTML, WAI people and namespaces [22]
• "The HTML Design Principles discuss principles used to help make decisions, and will help you understand the rationale behind many of the current design decisions." [23]
• Referenced in discussion re: closed captioning and video [24]
• DOM Consistency and SVG [25]
• The Degrade Gracefully subsection and MathML [26]
• But the Design Principles just don't seem to apply with issues of the @alt attribute [27]. Huh. How about that. But I think alt is in. Not, it's out. No it's in. No...

So, what do we know about the Design Principles? Ian Hickson in the HTML WG mailing list [28]:

I think the text in the Introduction of the editor's draft of the HTML Design Principles as of rev 1.26 is quite accurate, and that the rest of the text in that document meets the goals set out in the introduction admirably. I think that it is ridiculous to think that language design can ever be based on strict objective rules, and I do not think that the design guidelines claim that this is what is attempted (indeed quite the opposite). In fact, that's what the term "design principles" means.

Thank you for that clarification, Ian. Oh, Henri, about that DOM Consistency principle you frequently mention...