- From: Karl Dubost <karl@w3.org>
- Date: Wed, 4 Jul 2007 12:28:05 +0900
- To: Ian Hickson <ian@hixie.ch>
- Cc: Robert Burns <rob@robburns.com>, HTMLWG WG <public-html@w3.org>
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