Re: handling fallback content for still images

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.

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

Cheers

Josh

Received on Friday, 6 July 2007 09:30:26 UTC