- From: Sander Tekelenburg <st@isoc.nl>
- Date: Wed, 22 Aug 2007 22:29:16 +0200
- To: <public-html@w3.org>
At 00:57 +1000 UTC, on 2007-08-23, Lachlan Hunt wrote: [...] > I'd like to suggest that > the principles should be restructured into 4 categories, instead of the > existing 3. Seems like a good idea. This may also help make it more clear what each principle is or isn't about. [...] > 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. Another good idea :) > 2. Support Existing Content [...] > This is my proposed rewording: [...] Looks good to me. [...] > 4. Do not Reinvent The Wheel [...] > people have commented in the survey that it depends on the quality of > the wheel, or equivalent, and they are absolutely correct. > [...] I believe this is a problem > with the current wording and that these concerns are suitably addressed > using [...] 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 I don't think I could subscribe to this. The moment you start defining "successful" (by adding "in terms of benefits, usage and implementation"), you exclude other definitions of succes. That seems a very risky path to take at this point. It would seem wiser to levae this much more open (say just "reasonably sucesful"). Alternatively we could try to come up with a watertight definition of success that most can subscribe to, but that would probably be a lot of work with doubtful benefit. It seems more realistic to leave a discussion of what is "reasonably succesful" to occur when it needs to. So I'd suggest simplifying your wording to: Evaluate the success and failure of existing solutions. For those that have proven reasonably successful, consider adopting, retaining and/or improving upon them in preference to dismissing and inventing new features I've expressed the same type of concern with with the "Well-defined behaviour" principle btw. [...] > 5. Pave the Cowpaths [...] > I believe these issues would be address using my previous suggestion to > revise this example. [...] 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. Agreed. I can more easily subscribe to that. [...] > 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. Well, yes. But there is also the opposite: problems that are real, but that no one or hardly anyone has tried to solve yet. If it would be required that the 'level of realness' be proven by pointing to attempts to solve something, such cases would suddenly be 'not real'... Take uniformity of equivalents mark-up for instance. That isn't something that users or authors can try to solve. At the very best authors could provide feedback to this WG, asking for uniformity. And given that so few authors are even aware of the needs/possibilities of universality and accessibility, there won't be many such requests. Does that make it an Unreal Problem? Same for authoring of multiple equivalents and how they should/could cascade. Same for the legibility of the spec. I'm sure others can think of many more such examples. I do not see how these types of Real Problems can be proven to be real through the often requested "evidence". So I think that either it should be made clear how that can be done realistically, or the definition of 'real' should remain undefined... That aside, if we officially decide that "evidence" is required for anything, "evidence" will need to be defined. And even then I'd have serious doubts, because gathering evidence is something that can cost a lot. Such a requirement would probably exclude the majority of the WG members. I don't see how that could be solved. [...] > 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" I really don't understand how this is a good example. "search engines could" sounds like relevant context was omitted. [...] > 11. Support World Languages As I commented in the survey: I don't understand what " Features to represent a single web page in multiple languages are out of scope." means. Aren't @lang and @dir such features? Can someone help me understand? > 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. It may depend on how one defines "acccessibility"... (In my mind "accessibility" is pretty close to "usability", which is commonly recognised as something that needs to be balanced against security. Perhaps Joshue was thinking in that direction.) Trying to think of an obvious example of universality vs security: perhaps the issue of (visual-only) "Captchas" would be one? [...] > 13. Separation of Concerns [...] FWIW, I've expressed serious concerns with this principle: this Design Principle cliams that mark-up defines structure, ignoring that it also defines meaning. If that omission is intentional it should be explained. Also, I really can't agree with "Profound and detailed semantic encoding is not necessary if the end can be reached otherwise." lt leaves the door way too wide open for purely presentational mark-up, or non-mark-up (as in "equivalents need not be marked up as such"). If you (or someone) think my concerns are based on me misunderstanding the principle, could you explain please? -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Wednesday, 22 August 2007 20:39:24 UTC