- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 02 Jun 2009 19:39:57 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Leif Halvard Silli <lhs@malform.no>, www-archive <www-archive@w3.org>
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