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/[email protected]
[3] http://www.w3.org/mid/[email protected]
[4] http://lists.w3.org/Archives/Public/public-html/2009May/0410
--
leif halvard silli
