W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: object element interoperability Re: handling fallback content for still images

From: Ben Boyle <benjamins.boyle@gmail.com>
Date: Fri, 6 Jul 2007 01:30:12 +1000
Message-ID: <5f37426b0707050830q17676b66g7c8ed5b2a25f909e@mail.gmail.com>
To: "Karl Dubost" <karl@w3.org>
Cc: "Ian Hickson" <ian@hixie.ch>, "Robert Burns" <rob@robburns.com>, "HTMLWG WG" <public-html@w3.org>
Thanks Karl, I found this very useful background. I wonder if it might
be useful referenced from the design principles, perhaps relevant to
"avoid needless complexity", or maybe "separation of concerns"?
http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#avoid-needless-complexity
Maybe even a statement in there that we prefer not to overload
elements? Is that our stance?



On 7/4/07, Karl Dubost <karl@w3.org> wrote:
>
>
> 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 Thursday, 5 July 2007 15:30:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:46 UTC