Re: Why Design Principles?

Maciej Stachowiak On 09-06-02 05.11:

> 1. == Where did the Design Principles document come from? ==

> Some dissenters, chiefly but not exclusively browser vendors, 
> felt that the right path forward was incremental evolution on 
> top of HTML + CSS + JS + DOM. This was based on concerns over 
> continuity, compatibility and so forth. Some of the dissenters 
> formed the WHATWG to carry on its vision.

Ironically, the opposition against the WHATwg hegemony is also
concerned about continuity and compatibility.

> 3. == Are the Design Principles really principles? ==
> 
> Yes. The fact that they are neither phrased nor treated as 
> absolute doesn't make them non-principles. Keep in mind, these
>  principles have a fair chunk of their cultural origin on the 
> pragmatist side of the pragmatist vs. idealist schism of 2004.
>  Naturally they will try to reflect practical considerations
> and not just unattainable ideal goals. As I explained[6], and
> as Ian also explained[7]

Ok, so you use "absolute" as synonym for "clear". With that in 
mind, let's see what Ian "explained". He, btw (if we use the same 
positive reading as you do, and thus ignore the fact that he was 
creating a strawman version of Laura's position) use "strict 
objective rules" as synonyms for "absolute":

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

Whereas you said that they are principles _despite_ that they 
could have been expressed more clearly.

> 7. == Some of the least successful Design Principles ==

> - Pave the Cowpaths - People get caught up on the word 
> "Cowpath". The spec has not done literally what this principle
>  says that often. Not worth having it there to fight about. - 

It is a poster child of principles that _sounds_ very wishy washy. 
But I actually begin to feel at home with that principle.

> 8. == Design Principles that likely should be added ==
> 
> - Work from Use Cases - This is clearly a key practice, and 
> important to keep in mind to prepare a successful proposal.

Aka Lachy's proposal for a replacement for Cowpaths [2]. Seemingly 
proposed because Cowpaths was not able to get the results that was 
wanted. After all, Cowpaths cannot justify keeping @profile out.

This new principle proposal has the same "from scratch" problem 
that I have mentioned a few times. It sounds as something that is 
planned for "kill in the cradle" usage.

> - Learn from Data - Quantitative analysis has been a factor in 
> some decisions. I think we have seen (for instance from Ben 
> Millard's table study) that providing better data is more 
> effective than arguing with the idea of using data. 

"Data" does not only refer to "quantitative data". Quantitative 
analysis has also been a big controversy. In one way, with this 
principle proposal, you are coming with the _perfect_ cowpath 
principle. The cowpath principle as it has been perceived.

Also, you are here effectively arguing that this principle should 
be added to describe what we have actually been doing. Well, then 
why no rather support Larry's idea that we try to make a document 
that documents what principles we actually have been following?

> - Incremental Improvement - This could be a more general 
> statement of "Evolution and not Revolution", as well as 
> something like the Microformats 80/20 rule. Building on the de
>  facto existing Web platform is in a very real sense HTML5's 
> reason for being. And it's clearly a goal to avoid defining too
>  much of a feature directly, until there is more experience 
> with the initial version.

What kind of decisions should this help make?

> [7] http://lists.w3.org/Archives/Public/public-html/2009Jun/0037

I think one problem with the principles is their origin. They need 
to express a more _rational_ relationship to the other W3C 
specifications. We cannot have principles that are - as you 
described it - only rooted in the WHATwg crowd. We cannot have 
unclear and convoluted principles, with the justification that, 
"sorry but they are perhaps a bit coloured by the anti-feelings 
towards the winning party at a meeting in 2004".

Therefore, as a new principle to be added, I propose what Julian 
stated [3]:

	Consistency with other specifications

   Consistency with other specifications is a very  important
   goal and {one} that it needs extremely good reasons to give
   up on that.

   In general, if another specification clearly has a bug, it
   should be reported to the standards body maintaining that spec.
   In the worst case, this is where the process ends (such as for
   IETF specs with an Erratum on the RFC Editor page), on the other
   hand that Standards Body may be revising that spec anyway.

   [...] ignoring/overriding other specs often is a symptom of an
   assumption that one can do something better than those who were
   involved writing the "other" spec (a certain kind of "NIH*").
   This may be true sometimes, in which case the right thing to do
   is to help making that other spec better.

*Not invented here

Ian has already said - twice in the same letter[4] - that he 
"completely agree" to this principle. It would only be fair to, as 
proof that WHATwg is not suffering from NIH, be open for a 
principle that has actually not been invented there.

When it comes to the new principles you have be proposing, Maciej, 
then I don't support any of them, for the reasons I have mentioned 
above.  Instead the principles we have should clearer so that we 
can avoid discussing the theoretical point about whether they 
actually are principles, but instead use them. For instance, when 
it comes to "Consider Cowpaths", it would be much better if the 
title was extend to say - what is already said in the text: 
"Consider Cowpaths Before Inventing New Features".

[1] http://krijnhoetmer.nl/irc-logs/whatwg/20090522#l-195
[2] http://www.w3.org/mid/4A1FE9A0.3020102@lachy.id.au
[3] http://www.w3.org/mid/4A1BB7B0.9010605@gmx.de
[4] http://lists.w3.org/Archives/Public/public-html/2009May/0410
-- 
leif halvard silli

Received on Tuesday, 2 June 2009 22:53:38 UTC