This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5757 - MediaElement features are needed on OBJECT element
Summary: MediaElement features are needed on OBJECT element
Status: VERIFIED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://esw.w3.org/topic/HTML/SpatialT...
Whiteboard:
Keywords: NoReply
Depends on:
Blocks:
 
Reported: 2008-06-14 10:57 UTC by Rob Burns
Modified: 2010-10-04 14:29 UTC (History)
4 users (show)

See Also:


Attachments

Description Rob Burns 2008-06-14 10:57:54 UTC
* The new video and audio elements have many useful features valuable to authors, but authors using the OBJECT element would also want to make use of these MediaELement features
 * The VIDEO and AUDIO elements create parsing tree construction problems in legacy UAs whereas the OBJECT element with MediaElement features would not have this problem
 * Arbitrary handlers may also be able to expose similar interfaces and make use of the DOM methods and attributes and content attributes
 * Though some feel OBJECT is too overloaded to handle these features, the current VIDEO element has virtually the same implementation as would be necessary for the OBJECT element requires so it would be similarly overloaded
 * while not necessarily something HTML5 needs to address directly implementations require  for better code maintainability  methods of abstraction and code factoring that are independent from the elements these classes are use with, i.e.,
  - implementations need to implement interfaces such MediaElement in a way that it can be attached to any element regardless of its type name
  - DOM interfaces should be modularized for reuse by for instance separating MediaElement and VideoElement interfaces into separate classes for 1) networking, 2) audible, 3) spatial, 4) temporal, and 5) UI control interfaces  where these interfaces can be attached to an element and have their methods and attributes flattened for DOM interaction
   - (this is all to suggest the overloading issue is not a burden that should be lifted off of implementors and placed on authors or by inaequately specifying OBJECT element behavior, but instead handled through good code design)
 * Authors find it needlessly complicated to author using VIDEO and AUDIO in a way that degrades gracefully in legacy UAs when required to use additional elements that will not parse consistently and in an interoperable way across existing UAs
 * Authors should be able to embed content using the OBJECT element with minimal markup and expect UAs to provide sane default parameters and presentation, but currently, prevalent browsers are not quite there yet (though close)

(see http://esw.w3.org/topic/HTML/SpatialTemporalAudible for evolving solution proposals)

[authoring issue, no additional implementation]
Comment 1 Ian 'Hixie' Hickson 2008-06-14 18:38:21 UTC
<audio> and <video> are already being implemented, so it's really too late to change this.

In any case, the whole point of these elements is to not overload <object> with yet more functionality. <object> is so overloaded with different things that UAs have uniformly screwed up its implementation. Adding yet more APIs would just make things worse.
Comment 2 Rob Burns 2008-06-14 18:56:48 UTC
Your argument regarding "overloading" is already addressed in this bug. VIDEO has virtually the same features OBJECT requires except OBJECT also needs to pass name/value paired parameters to a handler. This bug does not suggest removing VIDEO and AUDIO only that authors require the same MediaElement features for those elements also on the OBJECT element
Comment 3 Ian 'Hixie' Hickson 2008-06-14 19:10:26 UTC
Are user agent implementors willing to add the media interfaces to <object>?
Comment 4 Rob Burns 2008-06-14 19:12:22 UTC
Yes
Comment 5 Ian 'Hixie' Hickson 2008-06-14 19:18:43 UTC
Could you elaborate? Which UA vendors have said that? Could you point to their statements, or have them comment in this bug? UA implementors have told me the opposite. I would love to see a browser that implemented the media interfaces on the <object> element, it would be very helpful for spec writing purposes (I'm not really sure how to actually make it work, but experimenting with an implementation would allow me to just reverse engineer it to spec it).
Comment 6 Lachlan Hunt 2008-06-14 19:24:35 UTC
Overloading <object> with the MediaElement interface is not going to work well.
Given that object can be used for more than just video and audio, each method
would have to be defined to have different behaviour depending on the type of
content loaded.

Before making any more claims about how easily this can be implemnted, it would
be wise if you listened to what the implementers are actually saying about the
issue.  Several of the major implementers have already expressed their concerns
about this issue in the past, including Opera.
Comment 7 Rob Burns 2008-06-16 11:47:23 UTC
(In reply to comment #5)

Are job here is not to predict the future of UA implementations. Which should I use palm reading for that or some sort of start chart? I will certainly do what I can to ensure it gets brought to a couple of  implementations.

(In reply to comment #6)
This isn't overloading. The OBJECT element already needs this. It already is designed to embed these types of media. Specifying an incomplete implementation doesn't prevent overloading, it simply ensures under-specification.

The interface needs to be abstracted into networking, controls, spatial, temporal aspects and then use better abstraction to take advantage of polymorphism in these interfaces. The DOM and markup attributes could even be passed as namespaced parameters to handlers so that handlers could also be updated to respond to these interfaces. If these are good ideas for VIDEO and AUDIO  and I definitely think they are  then they also are needed for OBJECT or we end up further ghettoizing OBJECT elements (just as their support is achieving some interoperability).
Comment 8 Ian 'Hixie' Hickson 2008-06-16 20:47:48 UTC
> Our job here is not to predict the future of UA implementations. Which should 
> I use palm reading for that or some sort of start chart? I will certainly do 
> what I can to ensure it gets brought to a couple of  implementations.

Our job _is_ to work _with_ browser vendors are ensure we don't specify things they aren't willing to implement. We do that (I do that) by meeting them personally, by chatting with them on IRC, by attending their parties, by working with them in their bug system, by communicating by e-mail, by contributing to their projects, by making personal connections by taking employment with these companies or volunteering to do testing and write patches for open source projects.


> This isn't overloading. The OBJECT element already needs this.

That is unclear.


> It already is designed to embed these types of media. Specifying an incomplete
> implementation doesn't prevent overloading, it simply ensures under-
> specification.

Right now <object> is reasonably well specified and doesn't require exposing a media interface nor interacting with the rest of the media processing rules. Adding that would be loading the <object> element with more complexity.


> The interface needs to be abstracted into networking, controls, spatial,
> temporal aspects and then use better abstraction to take advantage of
> polymorphism in these interfaces.

Why? The current definitions seem fine, and have multiple implementations already. I haven't heard any feedback from implementors to the effect that the current definitions are a problem.


> If these are good ideas for VIDEO and AUDIO  and I definitely think they are 
>  then they also are needed for OBJECT or we end up further ghettoizing OBJECT
> elements (just as their support is achieving some interoperability).

It isn't clear why "ghettoizing" <object> would be a problem, frankly. These elements aren't people, we don't have any moral imperative to make sure they thrive or anything. :-)


Basically I think we need more evidence that this is a real requirement before we go ahead and do this.
Comment 9 Maciej Stachowiak 2010-03-14 13:14:17 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.