Re: Proposed Design Principles

Maciej Stachowiak schreef:
> Inspired by David Baron's suggested requirement of Don't Break The 
> Web, a few of us came up with this proposed set of design principles, 
> to be used when evaluating changes to the spec. Besides me, and the 
> idea and text we borrowed from David Baron, at least the following 
> people contributed: Anne van Kesteren, Marcos Caceres, Henri Sivonen 
> and Ian Hickson.
>
> http://esw.w3.org/topic/HTML/ProposedDesignPrinciples
>
> I'd appreciate feedback on these. Are any important principles 
> missing? Are any of these wrong? Do they need refinement? 

I have some concerns about architecture missing as a consideration in 
these design principles, and actually only being mentioned as a negative 
in the "Solve Real Problems" item. It makes it sound as if taking a 
structured approach to a problem by first discussing the general 
architecture is a bad thing.

In any case, it’s a difficult document to deal with, because many of 
these things are a matter of perspective, e.g. what exactly constitutes 
‘complexity’, and when is it too much? Also, often you sacrifice one 
principle for another, so you need to weigh them somehow. For these 
things, it should really only be used as a guideline.

Some other points like ‘don't break the web’ I think should be taken as 
rules that should not be broken, so here it is no longer a guideline.

In general this is a nice document, and it would be interesting to 
discuss certain recent proposals in terms of the guidelines laid out 
here :).

However I think it would be good if this were to be taken a step 
further, and a secondary specification (or note) were created with an 
architectural view of HTML. This document should provide details on 
issues like how to provide graceful degradation [1], when to provide 
only a scripting interface and when also a declarative one (XForms 
transitional, video controls), when to create new elements and when not 
(elements like <love> versus a <div>-only universe) and how to deal with 
semantics that you don’t want to create elements for (microformats? 
class? role? RDFa?), et cetera, et cetera.

Reading it should give someone who wants to create a proposal for a new 
feature specific guidelines on whether it is really desired, and how to 
design the new feature. Because it is a separate document, it can also 
be discussed on a higher level, separately from implementation details 
that are specified in the main specification.


~Grauw

[1] What constitutes ‘graceful degradation’, is using CSS or JavaScript 
to provide fallback behaviour in older browsers considered to be 
degrading gracefully? And an XBL or XSLT one? Do barebones browsers like 
Lynx have to be considered here, or do we assume a world where scripting 
is enabled? (personal opinion: please don’t :))

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.