Re: Why Design Principles?

Hi Leif,

Your response takes the tone of a conspiracy theory. Things like your  
use of the word "hegemony" and your apparent belief that the Design  
Principles are an elaborate plot against the profile="" attribute make  
it hard to evaluate or respond to your feedback.

In the past you've lumped Rob Sayre in the same "hegemony" as Ian, yet  
Rob has stated his strong opposition to many of Ian's actions as  
editor, and even wrote an alternate HTML5 draft that makes different  
decisions on what features are in or out.

I can assure you that the Design Principles were not written with  
profile="" in mind. As one of the editors, I personally do not care  
either way about profile="", and I've certainly not made it my mission  
in life to stamp it out. In fact, if it were up to me, I would make  
use of profile="" conforming, if only to remove the need to argue  
about it further.

I suggest you resubmit your feedback without the conspiratorial tone.

Regards,
Maciej

On Jun 2, 2009, at 3:52 PM, Leif Halvard Silli wrote:

> 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 23:31:07 UTC