[html4all] some reflections on @alt usage

[Vlad Alexander (XStandard)]

> Another way of thinking about this is that tag soup thereby
> becomes part of the standard.
Well said.

> Vlad, why can't such tools have error checkers anyhow?
> Why can't browsers have them?
They can and it can be done in an informative and non-intrusive way. And if stakeholders in the Web wanted to, tag soup can be significantly reduced and a good portion of the Web can be made accessible even with HTML 4. But this is not going to happen. None of the major stakeholders in the Web really wants to have an honest conversation about the problems of the Web and how to solve them.

Regards,
-Vlad
http://xstandard.com

-------- Original Message --------
From: Leif Halvard Silli
Date: 2008-04-29 8:12 AM
> Jason White 2008-04-29 12.36:
>> On Tue, Apr 29, 2008 at 06:00:31AM -0400, Vlad Alexander wrote:
>>> And that will not change until major Web browsers will begin to report
>>> invalid markup to the users in some way. There is no incentive for tool
>>> vendors to generate standards-compliant markup if it gets treated by Web
>>> browsers the same as tag soup. In fact, HTML 5 will make the problem even
>>> worse. HTML 5 will help Web browsers parse tag soup better which will then
>>> provide less incentive for authors and tool vendors to author Web pages to
>>> specification and thus creating more tag soup on the Web.
>>   
> 
> Vlad, why can't such tools have error checkers anyhow? Why can't 
> browsers have them? iCab has always had one.  (But, ps, the idea had 
> about an unready stamp comes to mind. It does not seem appropriate to 
> receive the full load of errors messages at all steps of the author 
> process.)
> 
>> This is why I suggested in an earlier contribution that the @alt discussion is
>> ultimately a question of what markup validators should treat as acceptable.
>>   
>> If you accept the premise of HTML 5 that user agents should parse and handle
>> broken markup in predictable, specified ways, then the question inevitably
>> arises as to how missing @alt should be treated.
>> I doubt that it makes much practical difference whether @alt is
>> mandatory or optional in the grammar, given that if it is missing, error
>> handling will have to be specified (or left for implementations to define)
> 
> Jason, now that you say it, this sounds so obvious.  And it makes me 
> think that the ideas driving HTML 5 has not been implemented when it 
> comes to @alt. At least, I see no error handeling being specified.
> 
> Yes, of course, it would be entirely in the spirit of HTML 5 to say that 
> a missing alt should be corrected in the DOM. To put it like that would 
> be to say that a missing ALT is, in fact, an error. Correcting it in the 
> DOM should also help screen reader users, since they need to read the 
> web through a graphical User Agent.
> 
> To leave the issue to the implementations to define, does not seem to be 
> in the spirit of HTML 5, as it would be unpredictable.
> 
> So, what should the DOM do with a missing alt? Should it always be 
> corrected in the same way, for instasnce by enumerating the images in a 
> certain way? Or can some contexts be identfied, and some contextual 
> error handeling be specified?