[HDP] Response to Review of HTML Design Principles Questionnaire

Hi,
   These are my comments regarding the HTML Design Principles, in 
response to the survey [1].

***

Table of Contents

This email is structured into separate sections for easier reading.

1. General Comments
2. Support Existing Content
3. Degrade Gracefully
4. Do not Reinvent The Wheel
5. Pave the Cowpaths
6. Evolution Not Revolution
7. Solve Real Problems
8. Priority of Constituencies
9. Media Independence
10. Universal Access
11. Support World Languages
12. Separation of Concerns
13. Secure By Design
14. Well-Defined Behavior
15. Avoid Needless Complexity
16. Handle Errors
17. Support Publication
18. Delegate Edits

***

1. General Comments

I think Steve Faulkner made a very good point about the Universal Access 
principle and the need for a separate Accessibility principle [2]. 
Additionally, I believe Pave the Cowpaths is in the wrong category (it's 
currently in Compatibility).  In that light, I'd like to suggest that 
the principles should be restructured into 4 categories, instead of the 
existing 3.

* Compatibility
   - Support Existing Content
   - Degrade Gracefully
   - Do not Reinvent the Wheel
   - Evolution Not Revolution
* Utility
   - Pave the Cowpaths
   - Solve Real Problems
   - Secure By Design
   - Priority of Constituencies
   - Separation of Concerns
   - Baby Steps
* Interoperability
   - Well-defined Behavior
   - Avoid Needless Complexity
   - Handle Errors
* Universal Access
   - Support World Languages
   - Media Independence
   - Accessibility (New Principle)

Additionally, I think it would also be a good idea to eventually 
describe techniques for applying each principle.  The idea is to clarify 
when and how each principle should and should not be applied, which will 
hopefully resolve some of the concerns about them being misused.


2. Support Existing Content

This principle is essential.  However, there appears to be some 
misunderstanding as to the purpose of this principle.  In several 
comments on the survey, people have attempted to apply this principle as 
an argument to retain certain attributes on the grounds that not making 
them conforming will break existing content. (Although I'm not 
particularly sure what relevance such arguments have to the survey 
itself, beyond making noise about issues they want addressed.)

For example:

Stéphane Deschamps wrote:
> In particular I feel that a low statistic on particular usage is not
> sufficient enough to erase said usage (I want to keep @summary for
> tables, @longdesc for images, etc). Not making them mandatory suits
> me, deprecating them doesn't: they do work.

Joshue O Connor wrote:
> In particular @summary, @longdesc and header/id combinations.
> [...]
> When these changes impact heavily on users of assistive technology,
> then they certainly are not.

This principle is actually more about processing by user agents, not 
retaining previous markup from earlier versions.  Existing content would 
not break by making such attributes non-conforming, as long as the user 
agent processing requirements remained compatible with the legacy 
content.  This is not an argument for or against those specific 
attributes, just an explanation as to why the principle is being misused 
here.

Bob Hopgood wrote:
> I agree with the need to support existing content in XHTML 1.0 and HTML
>  4.01 but as written it implies support for HTML 1.0 as well.

It really doesn't matter whether a particular feature was defined in 
HTML4, XHTML1 or not defined at all (since HTML 1.0 doesn't exist).  If 
there is significant existing content on the web that relies on 
particular user agent behaviour, then that behaviour should be 
specified.  This does not imply that such content should be considered 
conforming.  For example, <marquee> will have processing requirments, 
but it's not likely to be considered conforming.

Given the amount of confusion, I think it would be wise to clarify the 
meaning and purpose of the principle.  Ideally, it should clearly 
describe the situations when it can and can't be applied.

This is my proposed rewording:

Existing legacy content often relies upon expected user agent processing 
and behaviour to function as intended.  Where possible, processing 
requirements should be specified to ensure that user agents implementing 
this specification will be able to effectively handle most legacy 
content in a way that is compatible with the existing expectations of 
users and authors, and behaviour of existing browsers.

The effect of all changes applying to the handling of legacy content 
should be carefully considered with respect to the cost of breaking some 
content and the expected benefits to be gained from the changes. 
Changes that break significant content and provide little benefit should 
be avoided.  Changes that provide significant benefit and break only 
insignificant or no content should be adopted.

***

3. Degrade Gracefully

I strongly agree with this principle.

***

4. Do not Reinvent The Wheel

I agree with this principle, though I have already posted my suggested 
revision of it.
http://lists.w3.org/Archives/Public/public-html/2007Aug/0435.html

The wording of this principle needs to make it clear that existing 
solutions should be evaluated and not just blindly adopted.  Several 
people have commented in the survey that it depends on the quality of 
the wheel, or equivalent, and they are absolutely correct.

The disagreements from the people who have stated that seem to be based 
on the belief that the principle implies an existing solution trumps all 
others, which is certainly not the case.  I believe this is a problem 
with the current wording and that these concerns are suitably addressed 
using my previous suggestion.

One comment suggested that the phrase "widely used" is too subjective, 
which is somewhat true.  The current wording isn't explicit enough to 
describe the conditions under which it applies.  I believe my proposed 
wording also somewhat addresses this concern, since it doesn't use 
ambiguous language, and it could be further addressed by describing 
techniques to apply this principle, as I mentioned above.

***

5. Pave the Cowpaths

I strongly agree with this principle being included, it is absolutely 
essential to the design of HTML.  I have previously posted my suggested 
revision of it to help clarify the misconceptions about it.

http://lists.w3.org/Archives/Public/public-html/2007Aug/0435.html

Several comments indicated an issue with the <br/> example provided.  I 
believe these issues would be address using my previous suggestion to 
revise this example.

http://lists.w3.org/Archives/Public/public-html/2007Aug/0746.html

Julian Reschke wrote:
> A cowpath is a sign that many people want to achieve something. 
> But just paving it may be the wrong solution. 

That comment doesn't make sense.  The first sentence correctly describes 
the concept of a cowpath, but the second sentence seems to miss the 
point.  Paving the cowpathts is just about addressing existing use cases 
and practices using whatever the best solution is, not necessarily the 
existing solution.

It's fairly neutral about the specific solution to use.  Whether the 
path is eventually paved using bricks, asphalt or even gold is more 
dependent upon other relevant principles.

This principle is certainly not about adopting widespread bad practices, 
as some people have expressed concern about.  As I have said previously, 
dirt paths formed by people continually cutting across the grass doesn't 
indicate that dirt paths should be built everywhere.

Some people have expressed the desire to rename this principle, since 
the existing name is associated with much confusion and misconception. 
Although I do like the existing name and would prefer leaving it as is, 
something like "Consider Existing Practices and Use Cases" would be 
acceptable.

***

6. Evolution Not Revolution

I agree with the concept of this principle, though I do think it needs 
to be clarified.  I support the suggestions from Karl Dubost and James 
Graham gave in the survey.

***

7. Solve Real Problems

I support this principle, though I think it needs to be clarified to 
address the concerns others have expressed.  In particular, it needs to 
define what is and is not considered a real problem and describe 
techniques to determine if a problem is real or not.

Despite what some have claimed in their survey responses, there are 
indeed cases where people think they are trying to solve a real problem 
when they're really not.

It is important to realise that the question of whether a problem is 
real or not, is not dependent upon whether someone thinks it is.  If a 
problem is real, there would need to be some sort of evidence to support 
it, although there are many forms of evidence and problems can apply to 
groups.  For example:

* Example pages that demonstrate authors trying to solve a problem,
   using techniques that aren't fully effective or cause problems for
   others. e.g.
   - Authors using JavaScript to simulate placeholder text in text boxes

* Feedback from implementers explaining how or why something is
   difficult or impossible to implement. e.g.
   - Implementing parsing algorithms according to SGML rules isn't
     possible on the web.

* Information about users trying to achieve something, which isn't as it
   easy as it should be. e.g.
   - Users of assistive technology need to be able to easily interpret
     and navigate the document, based on its structure.
     (That's one reason for introducing <section>, <header>, etc.)

Henri gave some good examples of problems people try to solve that 
aren't real in IRC:

<hsivonen> Regarding fantasy problems: the thing is people do try to 
solve them. sometimes the problems aren't 100% fantasy, but common sense 
says they aren't real problems. Examples: 1) "search engines could" 
(this is a common one), 2) suggesting new markup to support 
letter-duplicating Swedish hyphenation, 3) &auml; and other *uml 
entities are biased towards German and need politically correct aliases 
for other languages

http://krijnhoetmer.nl/irc-logs/html-wg/20070818#l-45

***

8. Priority of Constituencies

I agree with this principle and support Henri Sivonen and James Graham's 
insightful comments on this issue.  However, I'm not sure how to address 
the concerns.

***

9. Media Independence

I strongly agree with this principle.

***

10. Universal Access

As I mentioned above, I now believe this should become a category 
containing the 3 principles: accessibility, media independence and 
support world languages.

***

11. Support World Languages

I strongly agree with this principle.

***

12. Secure By Design

I agree with this principle, though it needs to be expanded and 
clarified.  As others have pointed out, "security model of the web" is 
undefined and ambiguous.

Joshue O Connor claimed:
> For example accessibility and security are two forces (sic) that could 
> be at logger heads. In many ways they are opposing principles. How can 
> we make the web more accessible while still making it more secure? How 
> can they be reconsiled? Which one will get the bums rush when the chips 
> are down?

I'm not sure what he's basing that claim on, I can't imagine how any 
security or privacy issue could affect accessibility.  But, even 
hypothetically, if it comes down to deciding on a feature that could 
seriously compromise the security of users for the benefit of 
accessibility, security wins and accessibility would have to be 
addressed in another way.  Ideally, however, features would be both 
secure and accessible and that scenario would never occur.

***

13. Separation of Concerns

I agree with this principle, although the B and I element example is not 
well phrased.  They aren't included because just because they are widely 
used, they're included because they're useful for representing semantics 
that commonly use these typographical conventions, but for which no 
other appropriate element exists.

I discussed this issue on my blog a few months ago.
http://lachy.id.au/log/2007/05/b-and-i

***

14. Well-Defined Behavior

I strongly agree with this principle.

***

15. Avoid Needless Complexity

I strongly agree with this principle.

***

16. Handle Errors

I strongly agree with this principle.

***

17. Support Publication

I support publication of the design principles as a First Public Working 
Draft, either with or without changes.

Although I do believe there are significant improvements that can and 
should be made to the principles, I do not think it is productive to 
hold up publication of a FPWD because of that.  A FPWD is not a stable 
document, I don't believe its content needs to entirely represent 
consensus of the Working Group at this stage.  If it did, it would be 
several months before it could get published.  If it were going to LC or 
CR, then it would certainly need to be much more mature, but it's not. 
It's only a FPWD.

I do not mind if the changes I suggested above don't get included in the 
FPWD, though I would like to see them in future drafts.  However, I 
would recommend that the draft at least include notes about or 
references to known issues with the current principles.

***

18. Delegate Edits

The editor should be free to make any edits, without restriction.

[1] http://www.w3.org/2002/09/wbs/40318/dprv/
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Wednesday, 22 August 2007 14:57:50 UTC