Re: handling fallback content for still images

On Jul 6, 2007, at 4:30 AM, Joshue O Connor wrote:

> Robert Burns wrote:
>>> So that would seem to be an argument for introducing <picture>  
>>> then. I mean,
>>> earlier I agreed with Anne that it would seem better if <object>  
>>> would become
>>> interoperable. But if its non-interoperability is an argument to  
>>> introduce
>>> <video>, <audio> and <canvas>, then it's also an argument for  
>>> <picture>. (I'm
>>> not denying there are some cons, just that this is a pro for  
>>> <picture>.)
>>
>> I would agree with this 100%.
>
> I think (as I am working this out as I go) that I agree also. However
> what is the different between having  <image> and <picture>? Why  
> change
> it if authors are used to the old way? Unless (and I am sure there  
> are)
> good reasons to do so. Does <picture> do lots of great stuff, have a
> more advance API, more so than <image>? If so please indicate.

I see this might have been answered on list for you, but I'll just  
add that UAs not expect <img> to be empty. So we can't place any  
content inside the <img> tags. This leads to the @alt and @longdesc  
workarounds to add accessibility to <img> (<embed> has the same  
problems without any workarounds added yet).

>> Author's are not as sophisticated as the programmers who do UA  
>> implementations.[..]
>> The complexity of implementing <object> should not lead us to dump  
>> that
> complexity on authors of HTML documents.[...]
>
> I am looking ahead here with these comments as opposed to my usual
> comments on why we need to support attributes etc that work for
> accessibility reasons. While I can see the benefits of using a 'one  
> size
> fits all' <object> element, I think that the valid point Rob makes  
> about
> novice authors etc could be an issue, but I would suggest that novice
> authors would not have as big a problem as authors who are used to
> marking up content the 'old' way. However, even it there is  
> potential to
> author incorrectly (as there always is) that should not deter the
> specification from moving forward *if* best practice is ingrained  
> within
> it. So the language/implementation is semantically intuitive both for
> the author and parsing algorithm/UA etc.
>
>> I feel some relief that so many think we can deal with these  
>> <object> interoperability/implementation problems.
>
> Rob, are you saying that you would like to see <object> used as a  
> fully
> interoperable element with all the various APIs that can handle  
> <video>
> ,<audio> etc instead of having <video>, <audio> etc in the spec?

Yes, I would. And I would like to see it capable of achieving that  
with the simplest syntax, like:

<object data='afile' >alternate content</object>

All other attributes and parameters would simply be added optionally  
or as needed to change the values from very reasonable default values  
(like height and width). I think this should work for still images,  
video, audio, flash and perhaps even canvas as:

<canvas type='image/canvas' >alternate content </object>.

This wouldn't mean we would have to necessarily drop <picture>,  
<video>, <audio>, and <canvas>, but just that the <object> element  
should be a feasible alternative to using those other elements.

On the offer to test sample code with assistive technology, that's  
sounds great. I don't do web development for a living, So I'm really  
not setup for that. I have trouble even getting access to Internet  
Explorer.

One file, that you could try would be:

This is an xhtml fie which should use the .xhtml filename extension  
so that the OS interprets it as MIME type application/xhtml+xml. The  
goal here was to see if visual UAs would display on the image  
referenced by the <img> element's @src attribute and then to see if  
Aural/Tactile UAs would provide user's access to the contents of the  
<img> element. It might be worth it to add an @alt attribute too, to  
see how the UAs handle that.

Thanks for offering. There's a wiki page on this you'll find at:

<http://esw.w3.org/topic/HTML/ 
LongdescRetention#head-0fcf0ad36f8c981c5f383b141dc0a833703e2f2b>

Take care,
Rob