Adding MediaElement features to OBJECT element

Media interface and markup abstraction

Problem statement / use cases

• The new video and audio elements have many useful features valuable to authors
• Authors using the OBJECT element would also want to make use of these MediaELement features
• 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)

Proposed solutions

Include sufficient specification of OBJECT

Currently, the OBJECT element requires complicated markup to have interoperable behavior from every browser. With only the data attribute included, UAs (including plugged-in handlers) should provide decent default values for attributes and parameters. In this way the following example should be rendered well without any other author provided markup:

<object data='file' >...[fallback]...</object>

UAs should retrieve the resource “file” and render it without any further specification of parameters for UA supported formats. In the absence of any additional parameters, attributes or CSS selectors, UAs should properly handle the content (see ObjectSupport: Current browser support for OBJECT element for examples of current leading UA behavior). For:

• still image files: the UA should apply the intrinsic dimensions of the image to determine the box frame in the same way the UA handles the resource if the author used the IMG element and the src attribute
• video files: likewise for supported video formats, the UA should determine the OBJECT elements box frame dimensions from the intrinsic dimensions of the data attribute referenced video resource (or perhaps only up to or near the size of the UA canvas)
• audio files: UAs should respect the new controls markup and DOM attributes in rendering controls for audio in the document, but should also provide such controls in the chrome, in the menu bar or elsewhere for users to identify and control audio and video

Combined MediaElement and VideoElement interfaces on OBJECT

Add facilities for new, media, video, and audio related features for use on the OBJECT element and add interfaces for arbitrary media handlers.

Object Element

Markup content attributes:

• Current attributes
  • data
  • type
  • name
  • usemap
• Controls attribute
  • controls
• Temporal attributes
  • poster
  • autoplay
  • start
  • loopstart
  • loopend
  • end
  • playcount
• Spatial attributes
  • width
  • height

interface HTMLObjectElement : HTMLMediaElement {
           attribute DOMString data;
           attribute DOMString type;
           attribute DOMString name;
           attribute DOMString useMap;
           attribute long width;
           attribute long height;
           attribute DOMString poster;
  readonly attribute unsigned long mediaWidth;
  readonly attribute unsigned long mediaHeight;
};

The OBJECT element would then inherit its interface from the MediaElement interface and also add the parameters available on both the audio and the video elements. This would allow authors to easily add some features of HTML5 (e.g., autoplay) to existing content that already worked with the OBJECT element.

Change ‘controls’ attribute to an enumerated NMTokens value

Whenever, embedded media content appears in a document, interactive UAs should provide users with the appropriate UI to control the media whether: spatial controls (such as fullscreen or perhaps resize), temporal controls (such as play, pause, scrub-forward, scrub-revers) and audible controls (such as mute and volume). However, the controls attribute should be used by authors who want to provide visible presentation of those controls alongside the embedded media. In this sense the controls attribute could be used by authors to specify which controls should appear.

Possible broad category values include:

• Audible (mute, volume)
• Spatial (resize, fullscreen)
• Temporal (play, pause, scrub-forward, scrub-reverse, file-start, file-end, loop-start, loop-end)

Then authors could add other keywords to more fine tune the controls appearing in the rendering of the document:

• mute
• volume
• fullscreen
• resize

Other keywords could provide exceptions to the broad category keywords. For example for the Audible keyword, the following values could subtract one or the other two audible controls:

• -volume
• -mute

Perhaps another liaison with the CSS WB to add CSS properties overriding these presentational keywords.

Discussion and evaluation

Email

WG members should post feedback and other discussion to the WG’s list serve (the URI for the links below provides date information). Search on this email subject.

• initial email (Robert Burns)

See also

• ObjectSupport: Current browser support for OBJECT element
• ObjectElement: the Object element
• ObjectTestResults: Object element test results