Re: Why Design Principles?

Maciej Stachowiak wrote:
> 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.

I also take exception to the use of terms like "hegemony" (hey: am I in 
on it too?), but would also like to add that public-html is intended for 
technical discussion.  People have a hard enough time keeping up with 
the bandwidth as is, meta-discussion such as this one should be taken 
off list, possibly copying www-archive in order to allow others to see 
and/or refer to it.

Thanks.

> Regards,
> Maciej

- Sam Ruby

> 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:41:30 UTC