Re: Aphorisms of First Principle [was Proposed Design Principles]

Hi David,

Thanks for your comments.

On Apr 12, 2007, at 9:41 PM, Dailey, David P. wrote:

> (apologies in advance: this is lengthy and rather polemic. But it  
> is by invitation, in a sense. A charter is plenty enough without  
> adding principles or guidelines or creeds - the rest of these  
> mores, norms, and folkways are better left for anthropologists than  
> for legislators.)

I continue to think shared principles are important. These principles  
will be relevant to many individual design issues, and if we don't  
agree on an approach, we will just end up arguing in circles every  
time. Most people seem to agree with me and you haven't really raised  
new arguments here. So I won't address this in depth.

> If they are indeed more of a guideline than a "code", then my  
> concerns as alluded to in messages http://lists.w3.org/Archives/ 
> Public/public-html/2007Apr/0460.html <http://lists.w3.org/Archives/ 
> Public/public-html/2007Apr/0460.html>  and http://lists.w3.org/ 
> Archives/Public/public-html/2007Apr/0007.html <http://lists.w3.org/ 
> Archives/Public/public-html/2007Apr/0007.html>  (at least one of  
> which was plus-oned by a sympathetic onlooker) are lessened. Such  
> spells, if based on magic alone, are easily met with counterspells.

> However, given that these "aphorisms of first principle" (AFP's)  
> have been waved again with such vigor in recent days, perhaps a  
> more critical response is required. And why would one need to vote  
> on "guidelines"? Their status is taking on a bit too much gravity  
> for my comfort.

You can think of them as self-imposed amendments to the charter, so  
that we don't have to pick through the often vague language of the  
charter for justification. Since they are self-imposed, they are also  
less difficult to add or remove in response to feedback. All it takes  
is a decision of the group, not the full re-chartering process which  
is slow and disruptive.

> Okay, that makes sense. Principles like
>
> "be nice to one another"
>
> "try not to misquote",
>
> "keep your threads straight m'boy"
>
> "remember what we're trying to accomplish"
>
> "remember to recite your aphorisms" and
>
> "HTML is not obsolete"
>
> are (with an exception or two) good guiding principles, that I hope  
> most participants will abide by. I can imagine dozens of such first  
> principles - some of which seem considerably clearer and, in the  
> long run, more important than those we are asked to agree to.

These mostly aren't design principles for the specification, but  
rather rules of etiquette or procedure. Since you brought up the  
analogy with legislation, the rules you listed are comparable to the  
US Senate rules of debate, while the current design principles are  
more analogous to the First Amendment's requirement that "Congress  
shall make no law abridging the freedom of speech".

> 1.	DontBreakTheWeb: New versions of HTML must not break significant  
> numbers of Web pages. In other words, browsers implementing the new  
> version should still be able to handle existing documents.
>
> On the surface, this seems self-evident. It seems consistent with  
> the charter's statement:
>
> 1CH: The Group will define conformance and parsing requirements for  
> 'classic HTML', taking into account legacy implementations;
>
> Sometime, however, it seems to have been invoked in our discussions  
> to mean
>
> 1ICK: Making a new browser which could do what you suggest, and at  
> the same time handles legacy content, is too big a burden on  
> browser developers despite whatever simplicity it may afford to  
> authors or usefulness to users.
>
> If you can define it, you can program it. So, so long as the  
> syntactic requirement of some new feature can be clearly  
> differentiated from the backdrop of existing utterances, then a  
> grammar for that corpus can be written, following from some sort of  
> Church's thesis.

I am not sure what distinction you are trying to draw here. The  
intent of DBTW is that browsers implementing the spec for currently  
existing web content should not break significant amounts of web  
content. I'm not sure if that is 1CH or 1ICK or what your letters  
even stand for. However, I do think something being so complex that  
it is difficult to implement correctly is a valid argument against  
it, just not based on this principle.

> Now one might ask: "when has anyone ever used a 'Don't break the  
> web' to mean a 1ICK?" I don't know if there have been instances.

In that case I see no need to change the principle. But if you have a  
specific change in mind, please say so.

> 2.	DegradeGracefully: New versions of HTML should allow documents  
> using them to work in user agents that don't yet support it.  
> Authors will be reluctant to use new features that cause problems  
> in older browsers, or that don't provide some sort of graceful  
> fallback. Graceful degradation is most effective when it does not  
> require special script or styling to work.
>
> Again a veritable aphorism! How could one disagree? At first  
> glance, the browser developers are the true experts here, since  
> they know when things will not work in old browsers - they after  
> all built the old browsers we authors are so fond of. But in that  
> case, can we authors who might like to be able to propose something  
> new be given examples of what will or won't degrade nicely?

I can give you an example that really came up. When Apple originally  
implemented <canvas>, we made it an empty tag like <img> that had no  
content and no close tag. This did not degrade very well to browsers  
without <canvas> support, because there was no easy way to include  
alternate content. In HTML5, <canvas> can have fallback content and  
requires a close tag, so you could have: <canvas><img src="server- 
generated-static-image.gif"></canvas>. This design is better at  
degrading gracefully.

Another example is the new form controls in Web Forms 2. These are  
generally represented as new values for the "type" attribute on  
<input>. This means the fallback in browsers that don't support the  
WF2 controls will be a text box, which is often a suitable  
alternative to a specialized entry field for an email address or the  
like.

I'd be happy to add specific examples to the Design Principles  
document, if you think that would be useful.

> 3.	DontReinventTheWheel <http://esw.w3.org/topic/ 
> DontReinventTheWheel> : If there's already an implementation with a  
> sufficient userbase that exposes a widely used feature, prefer  
> specifying that feature as opposed to inventing something new for  
> the same purpose.
>
> With the above argument one can say
>
> a)      why have <video> when we have JavaScript + JPG?
> b)      Why have <video> since the patent on animate GIF seems to  
> have expired?
> c)      Why have <canvas> when we have <body onmousemove="f()">  
> plus JavaScript?
> d)     Why have <canvas> when we have <svg>?

<video> and <canvas> both satisfy use cases that the alternatives you  
mentioned do not. Note also that <canvas> was not invented by the  
WHATWG.

> e)     Why does WHATWG not just focus on fixing things instead of  
> inventing new things?

It's focused mostly on fixing things and adopting things that others  
invented, but sometimes innovation is required.

The principle is already stated using "prefer" rather than more  
absolute terms, but I could add clear language that sometimes a new  
feature is needed to satisfy use cases not addressed by an existing,  
superficially similar one.

> Sure. I think the principle is something worth keeping in mind like  
> "be nice to people", but it seems like the argument feels better  
> when we make it at someone, but not so fun when someone makes it at  
> us. If a new wheel solves a problem better, then it is a good new  
> wheel.

The primary goal of the standards process should be a useful spec,  
not fun. It's true that inventing new things is fun, and someone  
saying "that's just like existing feature X except for the syntax" is  
not so fun. But honestly I don't care that pragmatism is less fun,  
and I don't think we as a group should care.

> 4.	PaveTheCowpaths <http://esw.w3.org/topic/PaveTheCowpaths> : When  
> a practice is already widespread among authors, consider adopting  
> it rather than forbidding it or inventing something new.
>
> I happen to like this one. If these darn principles become a creed  
> of some sort - rather than just friendly guidelines, best be warned  
> I'll be using this like a mad ant whenever somebody fusses about  
> improper uses of tables and blockquote.

OK, if you like it I won't make any changes.

> 5.	EvolutionNotRevolution <http://esw.w3.org/topic/ 
> EvolutionNotRevolution> : Revolutions sometimes change the world to  
> the better. Most often, however, it is better to evolve an existing  
> design rather than throwing it away. This way, authors don't have  
> to learn new models and content will live longer. Specifically,  
> this means that one should prefer to design features so that old  
> content can take advantage of new features without having to make  
> unrelated changes. And implementations should be able to add new  
> features to existing code, rather than having to develop whole  
> separate modes.
>
> Again, what looks revolutionary to one person looks only  
> evolutionary to another and vice versa. Yeah, sure most of what  
> this says is sensible, though the catch-phrase grates on my nerves  
> like fingernails on a chalkboard. And I'm pretty sure I don't  
> really understand the last sentence, to tell you the truth. I would  
> like HTML to become much more ambitious than I think WHATWG is  
> aiming at.

You're welcome to pursue your ambitions but I think requested changes  
would have to be incremental, not earth-shattering, to get a good  
reception.

> See http://lists.w3.org/Archives/Public/public-html/2007JanMar/ 
> 0555.html <http://lists.w3.org/Archives/Public/public-html/ 
> 2007JanMar/0555.html>  by way of explanation.
>
> I think much of what I'm talking about there cannot be done  
> currently using HTML and from what I can gather on the basis of  
> discussion to date, most of it cannot be done with WHATWG's HTML.

You should raise specific feature requests for things that you think  
are needed but can't be done.

> 6.	SolveRealProblems <http://esw.w3.org/topic/SolveRealProblems> :  
> Changes to the spec should solve actual real-world problems.  
> Abstract architectures that don't address an existing need are less  
> favored than pragmatic solutions to problems that web content faces  
> today. And existing widespread problems should be solved, when  
> possible.
>
> I'm sorry. I know I shouldn't have problems with this but I do. Can  
> someone give me a real world example of a problem (deserving of the  
> moniker "problem") which is not a real world problem?

The concern here is about proposals that don't solve *any* actual  
problems. But here's an example: someone might propose that the spec  
needs to have a DTD or schema, because that is somehow the  
theoretically right thing to do for language specs. But in fact, the  
practical reasons you may want one (validation, UA processing,  
parsing) are already better handled in other ways in the spec. So it  
would only solve the "problem" of meeting some abstract standard for  
specs, not a practical problem for authors or implementors.

> I surmise that what this means is "back up what you propose with a  
> needs analysis"? If that's what we mean then, let's say that. But  
> that already seems to be a general dictum of the culture of the  
> W3C, so I'm not sure we need an aphorism that sends some of our  
> brains into funny directions to help us remember it.

I think the funny directions side effect may be specific to a small  
subset of brains.

> 7.	 Separation of Concerns. - The ambiguity of the word "semantic"  
> is troublesome see http://lists.w3.org/Archives/Public/public-html/ 
> 2007Apr/0167.html <http://lists.w3.org/Archives/Public/public-html/ 
> 2007Apr/0167.html>  in which Karl Dubost suggests:
>
> I think we should avoid to use the word semantics to qualify the  
> type of content the element/attribute is supposed to mark up. That  
> would help to avoid debates based on misunderstanding.

I could rewrite this one to leave out the word "semantic" entirely.  
But our charter itself says we are to come up with a document to  
describe the semantics of web documents and applications, so I am not  
sure avoiding it is all that useful

> 8.	Support world languages.
>
> Of course. I am troubled by how little representation we appear to  
> have of languages outside the Indo-European family in our group here.

I think we want to stick largely to well-known techniques such as  
unicode, bidirectional text layout, and so forth, rather than deeply  
studying the typographical conventions of other scripts.

> 9.	AvoidNeedlessComplexity <http://esw.w3.org/topic/ 
> AvoidNeedlessComplexity> : Simple solutions are preferred to  
> complex ones, when possible. Simpler features are easier for user  
> agents to implement, more likely to be interoperable, and easier  
> for authors to understand. But this should not be used as an excuse  
> to avoid satisfying the other principles.
>
> I particularly like this one. Would it not suggest that we  
> eliminate the Proposed Design Principles / AFP's. The working  
> group's charter is a whole lot simpler.

This principle is avoid *needless* complexity, and I think what the  
charter says about our goals is too simplistic to be useful.

Let me know if you'd like me to make any changes to the principles  
based on your feedback.

Regards,
Maciej

Received on Sunday, 15 April 2007 22:58:20 UTC