Warning:
This wiki has been archived and is now read-only.

ProposedDesignPrinciples

From HTML WG Wiki

Jump to: navigation, search

HTML Design Principles (Proposed)

This page is obsolete. See the current draft of the HTML Design Principles document and DesignPrinciplesReview.

Don't Reinvent The Wheel

DontReinventTheWheel: Evaluate the success and failure of existing solutions. For those that have proven reasonably successful in terms of benefits, usage and implementation, consider adopting, retaining and/or improving upon them in preference to dismissing and inventing new features.

Example: contenteditable= was already used and implemented by user agents. No need to invent a new feature.

Pave The Cowpaths

PaveTheCowpaths: Investigate existing practices and design or adopt features that meet the desires of authors. Where possible, solutions should leverage the existing techniques and skill sets of authors which will help promote the adoption of new features.

Example: Authors already used the
syntax as opposed to
in HTML. Lets just allow that.

UnPaveTheNonCowpaths/PaveTheCowpaths has been used as an argument for removing features that aren't widely used. This seems like inappropriate application of the principle, and may have undesirable side-effects. For example: @profile isn't widely used, but removing the feature prevents its use becoming a cowpath.

PaveTheCowpaths seems to condone many practices that past specs may have frowned upon. Codifying bad practices may not be a good idea. Cowpaths could be one factor to inform decisions but not "pave" the way to them. (see related email)

No set number of use cases proves a feature should be included or excluded from the spec. The W3C requires that technologies must be accessible. By definition, people with disabilities are a minority. Accessibility features address failure modes that are infrequent, but critical when they occur.

Current use shouldn't be ignored. But it isn't necessarily an either/or proposition. As with HTML 4, many authors may not have taken advantage of certain features, but some certainly did. Just ditching one feature because it's less used (or used incorrectly by well-meaning, but mistaken authors) takes away from the language, as it then forces the knowledgeable authors who were indeed using those features correctly to adapt to a lowest common denominator, impoverishing their content in the process.

Because of this the PaveTheCowpaths: principle should be changed to something like:

"ConsiderUseCases: "Research existing practices. When a practice is already widespread among authors, consider it. Use cases (cowpaths) are one factor to inform design decisions but not nescesarily "pave" the way to them. No set number of use cases proves a feature should be included or excluded from the spec."

I object to that proposed change for the following reasons:

The way it is phrased lacks neutrality. Explicitly stating that "No set number of use cases proves a feature should be included or excluded from the spec." seems to be a way to stop the principle being applied when a proposed feature lacks any significant use case. If there are 0 use cases, there should be no feature. Beyond that (1 or more use cases), they should be evaluated according to the Baby Steps principle. So the statement itself is also inappropriate for this principle.
The number and quality of use cases is completely independent from the issue of accessibility. A use case is about determining why some feature would be used, and an accessibility issue is not a use case, it is a problem to solve. e.g. Marking up tables using header cells that are associated with data cells is the use case. Making tables accessible by clearly indicating that association is not a use case; rather it is a specific problem that the headers attribute (among other solutions) solves within the use case. But a problem for a feature to solve is non-existent without a use case for that feature. e.g. If nobody ever needs to use image maps on input elements, the accessibility issue of server-side image maps on input elements is non-existent.
Saying 'but not nescesarily "pave" the way to them' doesn't make sense. It seems to be based upon faulty assumptions and/or misunderstandings. Paving the cowpaths is not about condoning practices that are frowned upon, it's about addressing the use cases using the most appropriate solution. That's why the current text says "design or adopt features". Sometimes, an existing feature may be suitable and can just be used. In other cases, authors may be using poor quality hacks, and so a new design would be more suitable.
Saying "When a practice is already widespread among authors, consider it" is also bad precisely because it inaccurately suggests adopting existing practices as is, which causes the confusion about this principle. That's why it was taken out of the old wording and replaced with the much more specific "leverage the existing techniques and skill sets". It says leverage because it's about using what already works to guide the design or adoption of the new feature.

However, changing the name to Consider Use Cases instead may be reasonable, though I do prefer Pave the Cowpaths. Finally, this principle should actually belong in the Utility category (when it's no longer disputed), rather than the Compatibility category where it was. -- Lachlan Hunt

Cowpaths References

The Calf Path by Sam Walter Foss (1895) - Popular humorous poem during the early days of the good roads movement. In the poem, Foss describes how a crooked path originally carved by a calf walking home developed into a major road traveled by hundreds of thousands of people. Foss talks of of blindly following a crooked cow path course.
Don't Pave the Cowpaths By Mike Arace - discusses why codifying bad practices may not be a good idea.
ObjectType =COL Paving Cow Paths By Jim Highsmith - Warns that when we pave the cow paths and ignore the highways, we do a disservice to our customers. He says, "In the IT world, 'paving cow paths' means automating a business process as is, without thinking too much about whether or not that process is effective or efficient. Often business process automation initiatives require figuring out entirely new ways of doing business processes -- impossible prior to automation (for example, work flow automation and digital image processing) -- defining more effective and efficient process highways."