[html4all.org] [wbs] response to 'review of HTML Design Principles' (fwd)

Thu Aug 23 19:26:07 PDT 2007

These are mine replies, for easy consumption ... all comments are welcome, on and off list

Leif.

From: webmaster at w3.org (WBS Mailer on behalf of lhs at malform.no)
Subject: [wbs] response to 'review of HTML Design Principles'

The following answers have been successfully submitted to 'review of HTML
Design Principles' (HTML Working Group) for Leif Halvard Silli.

---------------------------------
principle "Support Existing Content"
----
Do you support the "Support Existing Content" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
* The wordig «even if they [...] do not specifically request HTML 5
processing». How can a document «request HTML 5 processing» when we
are moving away from a DOCTYPE that tells which version of HTML we are
dealing with?

* The wording «We need to judge whether the value of the change is worth
the cost» is a principle in its own.  Remove it.

* What does «change» refer to in this principle? The spec? Well isn't it
the spec we are making? In a debate on public-html, the interpretation
«changes applying to the handling of legacy content» was proposed, and
qualified with the word «significant»: «significant content» [1]. 
Further, to demonstrate that «significant» was not meant purely as a
reference to quantity, an related WhatWG IRC debate was quoated where, as
first requirement, it was stated that one should look for «use cases» to
justify that UAs support existing legacy content. [2] As if
abc has a use case?

* «Cross browser content [etc]t»: To clear up what «existing content»
is, I support  Laura's  proposed change: «Valid markup should be given
the most weight, but legacy invalid markup shouldn't stop working.»

[1] http://lists.w3.org/Archives/Public/public-html/2007Aug/0944.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0889.html

---------------------------------
principle "Degrade Gracefully"
----
Do you support the "Degrade Gracefully" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
Avoid mention of browsers (see related comments of Karl Dubost and Laura
Carlson and others.)

---------------------------------
principle "Do not Reinvent The Wheel"
----
Do you support the "Do not Reinvent The Wheel" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
Delete «Sometimes, though, new use cases may call for a new approach
....».

This principle seeks to justify that we are positive about making
implemented proprietary solutions into standard solutions (if and when
this seems like a good solution) - as opposed to inventing
parallell/competing solutions.  That we also need new solutions, is
another matter.

---------------------------------
principle "Pave the Cowpaths"
----
Do you support the "Pave the Cowpaths" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * ( ) Disagree
 * (x) Strongly Disagree

Comments (or a URI pointing to your comments): 
As Karl Dubost says, this has a browser perspective: «Recovering bad
content is good. Making bad authoring practices a rule is NOT good.»

The debates we have had in public-wg, has also revealed this principles as
fruitless: Is it about identifying positive things? Many tried to use it
that way. But as it is explained in the editors draft, it is just about
accepting certain wrongs ( ) which in the end perhaps do not lead to
any harms.

---------------------------------
principle "Evolution Not Revolution"
----
Do you support the "Evolution Not Revolution" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
I lend my vote to Karl Dubost: «Promote progressive design»

---------------------------------
principle "Solve Real Problems"
----
Do you support the "Solve Real Problems" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * ( ) Disagree
 * (x) Strongly Disagree

Comments (or a URI pointing to your comments): 
I cannot see this principle as an serious «attempt to capture consensus
on design approach»

This principle has the  undertone of «some of you are looking to solve
purely theoretical problems».

---------------------------------
principle "Priority of Constituencies"
----
Do you support the "Priority of Constituencies" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
The last sentence, «Of course, it is preferred to make things better for
multiple constituencies at once», seems like an unneeded tail. First, it
should not say that this is the preferred solution. Rather, it should say
that this would be the _perfect_ solution.

I propose that we move this forwared to be the first sentence! And
thenafter, we change the wording of it so that the paragraph begins this
way:  «A perfect solution make things better for multiple constituencies
at once. But in case of conflict [...] »

---------------------------------
principle "Media Independence"
----
Do you support the "Media Independence" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
WhatWg and W3C might have been in different worlds for a while, but it
seems unneccesary to state that «A hyperlink can not be actuated in a
printed document, but that is no reason to omit the a element.»

Media Independence and Universal Access  converge. E.g. according to CSS,
screen reader and graphical UAs are different media. 

One could actually state the seemingly opposite principle: «HTML should
be media dependent». Meaning that it should have a useful display in all
media.

---------------------------------
principle "Universal Access"
----
Do you support the "Universal Access" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
Drop the «... when possible» addition in «but alternate mechanisms
should be provided when possible.»  It only serves to relativise the
principle itself.

And who should the «when possible» be aimed at? The spec-writers? Or the
authors?

The word «entirely» in «This does not mean that features should be
omitted entirely ...» calls for the question: Can they be halfway
dropped? Please drop the word «entirely» - entirely! :-)

---------------------------------
principle "Support World Languages"
----
Do you support the "Support World Languages" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
I support Richard Ishida's comments about this principle at 
<http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html>.

Also, his comment (same URI) under «Don't Reinvent the wheel» is also
relevant in showing how supporting Universal Access/Accessibilty goes hand
in hand with World Languages: «... adapting <img> so that alt text is
content rather than an attribute would be a big help [for] Arabic and
Hebrew content who need to apply directional tags to their alt text.»

The negativeness expressed in the wording «features to represent a single
web page in multiple languages are out of scope» unfortunatly  goes hand
in hand with the negativeness of the loudest voices of the WhatWg
community when it comes to alternative content in general: LONGDESC, ALT
etc.

---------------------------------
principle "Secure By Design"
----
Do you support the "Secure By Design" principle?

 * ( ) Strongly Agree
 * (x) Agree
 * ( ) Neutral
 * ( ) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
Joshue O Connor is correct when he says: «accessibility and security are
two forces (sic) that could be at logger heads. In many ways they are
opposing principles.» CAPCHAS can be one example of that.  

Presumabely the quoted example, cross-document messaging, is an example of
how one might enable usability, as well as security, through working with
the rules of the web.

---------------------------------
principle "Separation of Concerns"
----
Do you support the "Separation of Concerns" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
The 2nd example says «The b and i elements are widely used — it is
better to give them good default rendering for various media including
aural than to try to ban them.» 

What does «try to ban them» mean?  Our 2nd principle is  «Support
Existing content». That does not sound as «banning»?  

Else I find that I agree with Karl Dubost and Laura Carlsson.

---------------------------------
principle "Well-Defined Behavior"
----
Do you support the "Well-Defined Behavior" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
Again we see how the principle first states one thing, and then
relativises itself with a «however, implementations should still be free
[to improve/do what they want]». The fact that UA vendors will naturally
try to improve things, might just be stated as a fact, but one do not need
to say that «they are free to etc».  Improvements might eventually break
the «support existing content» principle.

Alternative wording:  «The spec should describe well-defined UA
behaviour that content authors could rely on, in preference to vague or
implementation-defined behavior.  »

---------------------------------
principle "Avoid Needless Complexity"
----
Do you support the "Avoid Needless Complexity" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
Again, the «when possible» phrase modifies. This is bad. I also support
removing « But this should not be used as an excuse to avoid satisfying
the other principles.» as this is true about all principles. «Needless»
is also a subjective term. Avoid complexity is perhaps enough.

But I also wonder about the word «complexity»: «complex is the opposite
of independent, while complicated is the opposite of simple.» [1]

The principle also needs better explanation.

[1] http://en.wikipedia.org/wiki/Complexity

---------------------------------
principle "Handle Errors"
----
Do you support the "Handle Errors" principle?

 * ( ) Strongly Agree
 * ( ) Agree
 * ( ) Neutral
 * (x) Disagree
 * ( ) Strongly Disagree

Comments (or a URI pointing to your comments): 
The wording "so that users are not exposed to authoring errors" could just
as well have been "so that documents do not expose authoring errors when
they are being read".

The principle is related to "Support Existing Content" , whose «badly
nested elements»  example fits just as well under this principle.
Actually,  that example actually better belongs under "Handler Errors"
than under "Support Existing Content"! Because, first we must define what
elements falls under "existing content", and then - if "existing content"
(marquee for instance) involves "badly nested elements", we must have
error handeling. I.e. MARQUEE first need to be supported as "existing
content", and then, if MARQUE is badly nested, then that error needs to be
handled.

This principle involves semantics, as the error handeling will have to try
to display it in a sensible way.

---------------------------------
Do you support publication?
----
Whether you support adopting any one principle or not, do you support
publishing the draft for community review?

 * ( ) Abstain
 * ( ) no; let's not work on this
 * (x) Only after critical issues are addressed
 * ( ) yes

Rationale: 
In this poll, many have issues have been raised. The principles have at
times bad language (the repeated relativising comments). 

---------------------------------
Are you OK to delegate some edits?
----
The document will have to go through at least some edits required
by W3C publication process. In particular, the "Status of this document"
section is written by the Staff Contact (with input from the editor,
chair, and WG).

It often helps to allow the editor to incorporate edits at their
discretion, either just small things or in general.

It's often useful to get a the chair or some other WG member to check any
changes just before publication. If there's some WG member you're happy to
delegate to, please nominate them in a comment.

Maciej Stachowiak and Anne van Kesteren have offered
to work on this document, and they seem like reasonable editor
candidates.

 * [ ] any edits the editors choose
 * [x] any small/editorial changes the editors choose
 * [x] any small/editoral changes, where "small" is judged by the chair

Comments (or a URI pointing to your comments): 
For the Design Principles to count as a true «attempt to capture
consensus on design approach», someone - at least one! – from outside
the inner circles of the WhatWg community should do the edits.

I suggest these names: Laura Carlsson, Karl Dubost, Richard Ishida, Philip
Taylor, Joshue O Connor, Robert Burns.

These answers were last modified on 24 August 2007 at 02:00:53 U.T.C.
by Leif Halvard Silli

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/40318/dprv/ until 2007-08-23.

 Regards,

 The Automatic WBS Mailer