W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Request for Decision: Design Principles

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Wed, 18 Apr 2007 17:51:56 -0400
Message-ID: <462692FC.7040809@vectoreal.com>
To: public-html@w3.org

Hi, Maciej-

Maciej Stachowiak wrote:
> I don't think anyone has called for treating them as "holy writ". They 
> are guidelines, not inviolate rules.

Ah... a non-binding resolution, then...

If they are guidelines, then they are already there on the wiki to cite. 
  Why do they need to be official?

Are these design principals comprehensive?  If they are made official, 
what manner do you propose to enforce them?  If you don't enforce them, 
how do they help?  I'd like all these issues answered as part of the 
voting process.

>> I see no clear benefit in establishing such a rigid stance.  But what 
>> I think they would be very effective at doing is establishing a "power 
>> base" at the outset of the group that would quash different opinions 
>> later on, a practice I find dubious at best.
> These are issues that I expect will come up over and over again. I think 
> it would be a waste of our time to re-argue the underlying issues 
> repeatedly. 

It seems to me that introducing them has merely created long arguments 
about them, distracting from productive discussion about individual 
issues.  I see no evidence that this will subside.

I will continue to argue each issue from the view that makes the most 
sense to me, regardless of whether or not it reflects one of the 
Official Design Principles.  I hope others will do the same.

Ideas stand on their own merit, not on the merit of an ideology.

> I would be much more sympathetic to disagreement with 
> specific things in the principles than in disagreement with recording 
> them at all.

That's the point.  I don't want to get bogged down in a discussion of 
whether an idea is RightThink.  That doesn't seem pragmatic.

And your reply doesn't address my issue: I think that any such 
codification will be harmful to a free and open debate.

>> I suspect that most people will not really care enough (or have the 
>> time) to about review and vote on the design principals (much less 
>> fully understand the implications)... but that once they were voted in 
>> by the core constituency that does seem to care strongly, it would be 
>> hard to defend against misuse.  I think we should be more open and 
>> flexible as a group.
> If people don't have time to read and think about this fairly brief 
> document, how will they find the time to participate in the discussion 
> in an informed way?

Laws are made up of the people that enforce them.  I think that many 
people will have opinions and ideas to contribute without knowing 1) 
these design principals, and 2) more importantly, the agendas of the 
people that put them forth.

These ideas are not abstract and unencumbered.  They reflect the 
methodology of the WHATWG, and have a storied and elaborate set of 
arguments to support them.  I'm not saying they are bad in themselves; 
I'm saying that one would have to be familiar with far more than the 
document you cite to truly understand all the implications.

To wax cassandric, what this means is, for each given argument against 
something in the WHATWG spec, there will be a chorus of talking points 
citing these principals that will drown out those who haven't had time 
or interest to read the whole WHATWG document *and* the associated 
mailing list.

>> For that reason alone, not any merit or deficit of the principals 
>> themselves, I would be against making them Official.  I'm in favor of 
>> using them as "gentle reminders".
> That being said, if we put them up for a vote, you'll have the 
> opportunity to express this point of view.

If it's going to come down to a vote, I'd like to let people know what 
they're voting for.

Of course, since this list is full of people who have already drunk the 
WHATWG koolaid, I anticipate that these Design Principals will indeed 
become "official".  So I'm glad that there is unlikely to be any 

Received on Wednesday, 18 April 2007 21:52:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:19 UTC