object element interoperability Re: handling fallback content for still images

Le 3 juil. 2007 à 10:04, Ian Hickson a écrit :
> (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.)

Do we have a resource which lists all the interoperability problems  
of object element among user agents? I see many claims of  
interoperability problems, but not that much actual tests, and  
reported and explained issues to back up the assertions. That would  
be cool to collect more data on this issue.

If you have resources please add them to
http://esw.w3.org/topic/HTML/ObjectElement


We had done a [few tests][1] (far to be enough) in the past but it  
might be worthwhile to compile all the troubles. It would certainly  
help browsers vendors and others to fix object in a next release.

[1]: http://esw.w3.org/topic/ObjectTestResults
[2]: http://www.w3.org/html/wg/html5/#the-object


For reference
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/ 
010282.html

     ON HANDLING OTHER MEDIA FORMATS:

     A lot of feedback concerned the necessity of introducing an
     element specifically for <video> in the first place.

      We could use <object> for this, adding multiple APIs to <object>
     for each kind of media file, defining the semantics for changing
     from one to the other, for content-negotiation, for
     disambiguating similar media types that have overlapping but not
     identical APIs, and so forth.

      However, the browser vendors would hate us. Browser vendors have
     repeatedly and loudly stated that overloading elements leads to
     implementation difficulties, resulting in poor interoperability,
     edge cases with strange behaviour, security bugs, and the works.
     Good examples of this in existing HTML browsers are <object> and
     <input>, both of which have had huge interoperability problems
     over the years, and both of which still have big issues. When it
     takes more than 10 years to get an element implemented well in
     every single browser that has tried to implement it, you have to
     look at why that is, and you have to learn from the mistake. In
     this case, the mistake is adding too much functionality to one
     element.

      Similarly, for backwards-compatibility reasons, adding anything
     to <object> is a nightmare. We'd have to carefully examine every
     addition to make sure it didn't clash with existing content, for
     instance.

      Furthermore, overloading an element with various APIs results in
     difficulties for authors. An author dealing with audio doesn't
     want to think about aspect ratios, and an author dealing with
     video doesn't want to think about plugin parameters.

      This doesn't mean we have to specify everything as its own
     element. There are media types that it doesn't make sense to
     support with a specific element (at least not yet); we don't want
     to have six dozen elements with each type having its own set of
     features (and bugs). We _do_ have a generic element, <object>,
     which does work for generic inclusion. It doesn't support
     media-specific features (like the Video API) but it works as a
     stop-gap until the media in question is important enough to
     deserve special treatment, if that happens.



     -- [whatwg] <video> element feedback
     http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/ 
010282.html
     Sun, 01 Apr 2007 02:26:35 GMT



-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

Received on Wednesday, 4 July 2007 03:28:12 UTC