Re: handling fallback content for still images

On Jul 5, 2007, at 5:32 AM, Anne van Kesteren wrote:

>
> On Thu, 05 Jul 2007 12:10:31 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>> Yes, I understand that's why I added the con. Should I add it a  
>> second time? I've said this again and again this will take a long- 
>> term solution approach. In that time-frame authors may not even  
>> know what a text/html compatible serialization is? They won't be  
>> confused because there might come a time when no one uses that  
>> serialization anymore.
>
> In that case it would make more sense to develop something like  
> XHTML 2.0 which is not what this Working Group is doing last time I  
> checked.

I don't really understand this whole XHTML 2 inferiority complex  
that's going on around here. I'm not from the XHTML 2 working group,  
I wasn't sent as a spy. I don't even know why you would bring this up  
here. Its irrelevant. There are a lot of reasons that authors may  
move to xml one day and it wouldn't have to be through adopting XHTML  
2. It could be through adopting XHTML5, XHTML 1.5, or HTML5/XML or  
whatever we end up calling it.  Outside of HTML, XML has already  
become widespread (including namespaces and mixed namespaces, doctype  
declarations, schema, and all sorts of goodies that seem to be bad  
words around here). Authors are already going to have to familiarize  
themselves with the differences. With text/html serialization they  
won't be able to do lost of nice things with their documents that  
they will be able to do with the xml serialization. Adding fallback  
to an img element is only one more thing. I don't think it will be  
that confusing.

>>>> Because <Img> has to be empty, authors cannot provide  
>>>> semantically rich or media rich fallback content for images in a  
>>>> simple and straight-forward manner (as they can for <object>,  
>>>> <video>, <audio>, <iframe>, <object>, and <canvas>). <img alt>  
>>>> cannot do that at all. It's really only listed there as a token  
>>>> solution.
>>>
>>> Is there any evidence that suggests that authors will start  
>>> providing more meaningfull fallback when they can have more than  
>>> just text? For instance, what do authors currently do for  
>>> <object> when they use it for Flash or video or some such?
>>
>> I'm not a palm reader. I don't know the future. Is there any  
>> evidence that the world wide web will exist next year? I know I  
>> couldn't prove it will. However, it should be a goal of ours to  
>> provide a language that services the needs of authors. Why are you  
>> so resistant to providing these facilities?
>
> Because
>
>  1) Changing fundamental parts of HTML in drastic ways is not  
> something
>     I think we should be doing.

How is allowing fallback content inside <img> in the xml  
serialization (something that Opera and Mozilla are already doing  
gracefully) a drastic change to a fundamental part of HTML. Did God  
decree that <img> shall never have fallback content?

>  2) While I agree that it would have been nice if <img alt> was  
> designed
>     better when invented I'm not convinced it's so bad now. All user
>     agents now support it so graceful fallback is no longer  
> relevant and
>     you typically don't need markup fallback.

Why should <img>, which will probably be used much more often than  
other embedded media elements, not have at least thee equivalent  
fallback where the contents of the element can serve as fallback? Add  
to that the fact that other media my have better accessibility  
features than still images do and the need for <img> to have rich  
fallback is  increased.

Why would one not need markup fallback for a still image? Have you  
made the blind see?

>  3) As mentioned above, I'm not convinced images need markup fallback.
>     The people who really do need markup fallback (I'd love to see  
> some
>     realistic examples) can use <object> once that's better supported.

I'm the one who raised better support for <object> as a solution to  
this problem (I believe I got resistance on that one too). However,  
why shouldn't our discussion reflect several possible alternative  
solutions like <picture> fallback</picture and <img>fallback</img>  
and <img longdesc='fallback">. And again, @alt doesn't cut it.

>> No. I wasn't trying to make it true. That its true I think is  
>> obvious.
>> I was simply trying to reiterate so you wouldn't forget about it.
>
> Ok, I hope I explained well enough why I think this is not obvious  
> at all.

No. That had nothing to do with <video> and <audio>. Look I have  
nothing against those additions to the language. But I can't even  
begin to come up with a use-case for <video> and <audio> that could  
come close in importance to the need to provide fallback for still  
images. And no one else has been able to describe any pressing need  
for those either.

Take care,
Rob

Received on Thursday, 5 July 2007 10:54:55 UTC