Re: handling fallback content for still images

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.

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

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.

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

Regards,
Maciej

Received on Tuesday, 3 July 2007 04:33:38 UTC