- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 23 Aug 2007 00:57:30 +1000
- To: public-html <public-html@w3.org>
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) ä 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