Re: handling fallback content for still images

On Thu, 05 Jul 2007 12:54:30 +0200, Robert Burns <rob@robburns.com> wrote:
> 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.

I bring it up because this working group has several constraints when it  
comes to language development that do not apply to long-term approach  
solutions when text/html would no longer be around.


> [...] 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.

Or maybe XHTML 1? It hasn't happened yet. I'm not sure what clear  
indication there is it will.


> 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).

Not for web authors. Most systems are still written using string  
concatenation which is perfectly fine but not suitable when dealing with  
XML.


> 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.

I'm saying it already is confusing.


>> 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?

Opera does not support it. (I haven't tested Mozilla.) If I disable images  
in Opera (something that often happens on mobile phones and such) I don't  
get to see any content whatsoever. Just the string "Image".


>>  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?

Because it's not clear that it should.


> 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?

I can't do anything with these statements. Can you provide some arguments  
for why markup is needed?


>>  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.

Again, I'm not convinced.


>>> 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.

James explained the reasons for <video> and <audio> in a separate thread.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 5 July 2007 11:39:26 UTC