RE: Design Principles, Section 1.6.1 relationship to HTML 4.01

Maciej wrote concerning "don't reinvent the wheel"
(but I'm going to reverse the order of his response for dramatic effect)
 

(1)
The full text of the principle also clarifies that sometimes "new use 
cases may call for a new approach instead of more extensions on an old 
approach". So I don't think it even disagrees with your position.

Damn! I saw you write that things had been updated since I last looked. I should have paid better attention. The softening does indeed soften my objection. I still would prefer the principle "don't let Occam's razor slit your throat" to "no more wheels"  Or better yet, "please examine all wheels carefully; some may roll better than others"  
 
(2)
Since this principle states a design preference, and not a fact about 
the world, I don't see how it can be factually inaccurate. That's like 
saying "Stop smoking" is false because some people still smoke.
 
Yeah, I know.  +1
I troubled over exactly this for a moment before hitting "send." I even tried to find statements about why design principles were important and to argue with those, but realized such statements are not really a part of the document in question.*  My fuss, if it is to be fussed, belongs somewhere else. 
 
My complaint is really probably possibly maybe not about fact?? It is more a question of what why and how this is supposed to help anyone who might otherwise be tempted to create a bad spec. Plenty of progress is made in HTML WG whether or not design principles are invoked.  
 
I guess in my mind I have two things going on about  the issue that make me fussy about "no new wheels":
1) Occam's razor:
Suppose  HTML5 already has mechanisms that enable behavior B (albeit in a convoluted way). Someone recommends  new tags <x/> <y/> <z/> that may make that behavior B more parsimonious.  It is not a new "use case" but a new analysis of why wheels roll and their relationship to axles. 
 
We have here the risk of simplifying the "implementer's" work at the expense of the author's work. A "proper" objective study of how best to maximize useful communication via the web *might* find that authoring is streamlined via mechanisms which complicate the borwser implementer's work. (remember how big Mac OS was compared to DOS)
 
That is, HTML5, if engineered for the author's perspective, might necessitate lots of new wheels. We could imagine an authoring-performance space (as augmented by authoring tools) in which seven new tags (largely replacing four earlier ones) could allow greater successful-understandable-conforming-happy-validating-semantic-accessible content (as long as it does not involve Wittgenstein) in 85% more circumstances.
 
2) What behavior are we really trying to promote in our spec writers? 
Parsimony? If so why not invoke parsimony as a principle?
Avoidance of redundancy? If so why not invoke parsimony? 
Simplicity? Then why not just point back to the Working Group charter instead of extending it through small, unobtrusive, design principles?  
 
I really don't like fussing about design principles. I mean I do, but I don't. If I felt I had somewhere to go with my fussing I would be all excited about it. Practically, I recognize that the advocates of the design principles are contributing about 2736 times as much as I am toward making a new and vital HTML5 and I respect that. But I really don't see how the design principles are helping us get to where we are going. I think that the first vote on them was really a vote of confidence in HTML5. I might recommend to the Chairs that a simple vote of confidence in the directions  HTML5 is going would be more satisfying than a vote on the principles that purport to guide our discussion. I'll bet a virtual nickel that consensus would be more than an iota higher!
 
If the principles are to be taken seriously then I would want to undertake a much more systematic study of the nature of principles in the evolution of policy and in the way that those principles may be used to introduce bias into the evolution of policies. 
 
In what way are these design principles vital to the task at hand?
 
respectfully
David 
 
* design principle, sub zero: design principles are valuable.

Received on Sunday, 31 May 2009 04:47:53 UTC