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

Re: "Pave The Cowpaths" Design Principle

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 14 May 2007 10:33:35 -0700
Message-Id: <062429E7-4903-483D-87EC-45662C6ECC5C@apple.com>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, www-html@w3.org, public-html@w3.org, Roger Johansson <roger@456bereastreet.com>
To: Gervase Markham <gerv@mozilla.org>



On May 14, 2007, at 7:53 AM, Gervase Markham wrote:

> Laura Carlson wrote:
>> The proposed HTML 5 design principle "Pave The Cowpaths" [4] does
>> indeed seem to condone many practices that past specs  may have
>> frowned upon. "Pave the Cowpaths" is an underlying principle being
>> debated in many* of the recent semantics and accessibility threads on
>> public-html@w3.org.
>
> Is it possible that the two sides are talking past each other a  
> little bit? I can see two possible formulations of "Pave the  
> Cowpaths":
>
> 1) Find a thing lots of people are trying to do, and the markup  
> hacks/proprietary features/workarounds they are using to do it, and  
> put those hacks into the spec.
>
> 2) Find a thing lots of people are trying to do, and make sure the  
> new spec provides a simple way to do it, which may or may not be  
> related markup-wise to the way they are doing it now.
>
>
> I think perhaps that many Pave The Cowpath proponents are arguing  
> for 2), but many of their opponents are afraid of and arguing  
> against 1). Could that be so?

The intent of the principle was neither of these, at least by my  
understanding. It was more like:

If you want to solve a problem, and authors already have a common ad- 
hoc solution, consider using the de facto solution rather than making  
up something new, if it does not create significant problems to do so.


Here are some examples from the HTML5 spec that I think could be  
considered instances of this principle in action:

1) Support dual-mode html/xhtml documents but allowing things like  
<br/> and an xml namespace declaration for the html namespace on the  
root element.

2) Define <small> to indicate "small print", since this matches the  
most common use of the element in the wild and gives the right  
presentation by default, rather than defining a <finePrint> element.

3) Standardize the <embed> element, since it is very commonly used in  
the wild, often in combination with <object>, and does not cause any  
accessibility or other problems that don't already exist with <object>.

4) Define some commonly used class names to have their usual commonly  
used semantics.

How this principle plays out depends on what past author practices we  
think are "bad". Personally, I find sending XHTML as text/html  
distasteful, but I have to admit that it does not cause major  
immediate problems, and clearly defining how it works solves most of  
the problems that do exist.

Regards,
Maciej
Received on Monday, 14 May 2007 17:39:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:58 GMT