Re: handling fallback content for still images

On Jul 2, 2007, at 11:33 PM, Maciej Stachowiak wrote:

> On Jul 2, 2007, at 8:20 PM, Robert Burns wrote:
>
>> 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.
>
> In practice, requiring an implementation of something complex means  
> lack of interoperability. The <video> API is already quite complex  
> without mixing it up with all the different things that <object> does.

Does this mean we'll move towards having a different element for  
every MIME Type (or at least the first level types)? Won't we still  
require conforming implementations to work with <object> for diverse  
types?

>> 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.
>
> As far as authors go, I don't think it's just a matter of whether  
> one option is confusing. <video src="foo.mp4"> is more intuitive  
> than <object type="video/mpeg4" data="foo.mp4"> and more clearly  
> expresses the semantic of an embedded video. "video" is clearly  
> more of a first-class concept than "object of type video". I don't  
> see any reason why the object version would be better for authors,  
> novice or otherwise, and a distinguished element way better for  
> data mining tools once widely deployed (they don't have to guess at  
> the magic strings in an <object> that would result in it being a  
> video).

Again, don't these same arguments apply to <picture>? Yet again and  
again we're told "well why don't you just use <object> if you want a  
single unified approach to still images that allows optional  
fallback". I'm not trying to be argumentative here. I'm really trying  
to understand the principles that are being applied so that we can  
start to build a consensus around these issues.

> Consider also developers using the DOM API. It makes sense that a  
> single class doesn't wildly change what methods and properties it  
> exposes, based on runtime conditions. And with <object>, changing  
> the type attribute on the fly could, if <object> was overloaded,  
> result in a total change of API on the very same object.
>
> So in this case, I think the goals of being implementation-friendly  
> and author-friendly are aligned.

I understand what you're saying. However, I'm thinking more of the  
novice authors. Authors using the DOM already have a level of  
sophistication that allows them to understand these things. I'm  
trying to make easy things really easy and difficult things possible.

>> 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.
>
> Exposing completely different APIs on the same element depending on  
> what type of content it is currently displaying is more than a  
> minor difficulty.

I guess I'll take another look at the <audio>, <video> and <canvas>  
APIs, but I don't recall the differences being that major. It would  
require DOM code to use introspection on <object> elements (how about  
doing canvas drawing right on the top of a video?) before assuming it  
will respond to video calls for instance. How is that any different  
from checking whether a <div> has a particular value for @class  
before performing some method on it?

>> I feel some relief that so many think we can deal with these  
>> <object> interoperability/implementation problems.
>
> I think IE is the main problem area so I'd like to hear from  
> Microsoft on this.

Me too. Though I'd also be interested in testing (or if someone else  
has done this already) what the various UAs do, when confronted with  
those simplified <object> cases (i.e., no <param> and not necessarily  
any declared type) for video, audio, image, and flash (probably no  
one supports type='image/canvas' since I made it up).

Take care,
Rob

Received on Tuesday, 3 July 2007 05:17:31 UTC