- From: John Foliot <jfoliot@stanford.edu>
- Date: Sun, 11 Apr 2010 14:54:10 -0700 (PDT)
- To: "'Laura Carlson'" <laura.lee.carlson@gmail.com>
- Cc: "'Janina Sajka'" <janina@rednote.net>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'Michael\(tm\) Smith'" <mike@w3.org>, "'Michael Cooper'" <cooper@w3.org>, "'Judy Brewer'" <jbrewer@w3.org>
Laura Carlson wrote: > Hi John, > > > why struggling over a word is worth the effort > > If the word is not "error", there will be no result. OK, so we call it an ERROR. Now what? What *practical* result does it get us? The image still displays in the browser. Even calling it a "super-mega-show-stopping-error-to-end-all-errors" still gets the same result in the browsers, so it's just a word IMHO; the net result is that the image still displays. What have we 'won', what have we gained? > Developers pay > attention to errors not warnings. If the final outcome is that the error has zero impact on how the image/page renders visually on the screen, then why will they 'pay attention'? *I* know what the problem is, as do you and everyone following this thread, but for the average, non-educated content creator, she doesn't see a problem - she sees an image on the screen. What is the *cost* of that problem to the content creator? What is the cost to my Dad, uploading pictures to Flickr? To the third-world child, with their new green and white $100.00 computer, making a web page about his village? Without practical outcomes, this is an exercise in angels-on-a-pinhead. What we really call that outcome boils down to two things - success or failure. > >> This isn't about making deals. > > Sure it is - that's the nature of compromise and consensus > > Consensus is about being able to "live with" something. Right. I can live with changing the *name* of what it is we are talking about, if at the end of the day we get all of the other behaviors and recommendations in your Change Proposal. Those requirements, to me, are what we should be fighting for, not what we name them. Getting MUST language into the spec is where the big win is - that editors and validators that encounter broken images MUST enforce a teachable moment and provide guidance and assistance in remediation/repair, so at the end of the day we have neither an ERROR nor a WARNING, we have a complete <img>! > Some things > can't be lived with. Without both @src and a text alternative the > <img> element is broken. Making them both a warning doesn't make > sense. Both are needed for an image to be complete. Logically, emotionally, philosophically I am 100% in agreement with you. Unfortunately, mechanically this is not true, and we are not going to change that reality either. <img src=""> works ('complete' or otherwise) in all of the browsers today, and will continue to work so long as the value of @src is intact. That ship has sailed long ago. > Both are on the > same level. Lowering standards for one and not the other is > discrimination. I can't live with that. WAI CG's consensus document > doesn't live with that. Laura. This isn’t about _us_ lowering our standards - that has been done for us already by the browsers and there is no going back; we won’t get draconian fail and honestly that is the only real penalty that would make @src and @alt truly equal. (The browsers could use the same argument too BTW - that introducing draconian fail is a lowering of their well established rendering standards to a point that they cannot accept) I HATE that as much as you do, as much as we *all* do. But it is a reality we must come to accept. Insisting that we call this an ERROR, *fighting* for it at HTML WG, is a battle we will not win; or conversely we will all agree to call it an ERROR, but (with a wink and a nod) in true Orwellian fashion we will have a situation where all ERRORS are considered equal, but some are more equal than others... JF
Received on Sunday, 11 April 2010 21:54:46 UTC