Re: handling fallback content for still images

On Jul 2, 2007, at 9:15 PM, Sander Tekelenburg wrote:

>
> At 01:04 +0000 UTC, on 2007-07-03, Ian Hickson wrote:
>
>> On Mon, 2 Jul 2007, Robert Burns wrote:
>>>
>>> [...]
>>>
>>> <canvas> could just be
>>>
>>> <object type='image/canvas'>
>>> fallback
>>> </object
>>
>> Actually, no -- the <video>, <audio>, and <canvas> elements all  
>> expose
>> elaborate APIs that are specific to the kind of media to which they
>> relate. When those elements were introduced, it was thought unwise to
>> overload <object> with all these APIs as well as APIs for frames,  
>> plugins,
>> images, and the like. (Part of the reason <object> is so poorly
>> implemented is that it is so overloaded with different behaviours, a
>> lesson that I've tried to apply to all the new features in HTML5.)
>
> 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%. However, I would strongly disagree with  
Ian's contention here. Complexity in the UA implementation should be  
dealt with through good code factoring and other best practice  
programming not through dumping the problem onto the authoring  
language. 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. The  
more the UA can deal with complexity, the easier it will be for  
authors and users.

On the other hand, if its somehow confusing to authors to use  
<object> for all of these uses (even if <param> was required by UAs  
only in exceptional circumstances as the case whould be), than I  
think we would be justified in introducing other elements (such as  
<audio>, <video>, <picture>, and <canvas>). However, I don't think  
that's the case. Instead I think the only justification (that I can  
glean from this) would be that the term "object" is unfamiliar  to  
novice authors (they wonder what is an "object" and think it must be  
something more sophisticated programmers use and not me). Even  
"embed" is more colloquial.

Again, I think its entirely the wrong approach to take complexity in  
API implementation and deal with that by making HTML needlessly more  
complex. The algorithms should simply branch on the different media  
types. If there are other arguments for semantically distinguishing  
between the various embedded content objects,, that's fine, but not  
simply to off-load (minor) difficulties from the processing algorithms.

I feel some relief that so many think we can deal with these <object>  
interoperability/implementation problems.

Take care,
Rob

Received on Tuesday, 3 July 2007 03:20:38 UTC