Working together for standards The Web Standards Project

Adding Multimedia in Web Documents (part 2)

In the first part of this article, we reviewed the history of the multimedia inclusion in hypertext documents. Let us now explore in more detail how we can use the most current and recommended method to accomplish this task: the object element.

A versatile and complete inclusion mechanism

The object element is a good solution to the early problems of inserting multimedia in (X)HTML:

  • It can be used for any type of content
  • It comes with a powerful cascading mechanism for alternate content
  • It can pass variables to executable content (such as an applet) using its param attribute
  • It can specify the exact content-type of the included object. For example, you can show the source of a script within a page by serving it as text/plain. (Note, however, the particular object’s content-type has been specifically set on the server, the server’s declaration (over HTTP) takes precedence, just as it does for <meta name="http-equiv" ... )
  • It can be used to include the object directly instead of referring to it by using data attributes

The object element is a generic mechanism that gives us more flexibility than any previous elements that have been designed to perform multimedia inclusion.

Usage of the object element

Back to the question for this WasP asks the W3C issue: How do we insert multimedia objects into Web documents in a backwards-compatible way?

The term “backwards-compatible” as used here is vague and could be misleading. Backwards-compatibility is not a matter of how a document is authored. A technology can be backwards-compatible if a new version of the technology completely includes the functionality of its predecessor.

Questions that have been asked about including multimedia in web documents:

  • Can a feature that has been deprecated after a given version (e.g. applet) be used in more recent versions of the same technology? No, it is not recommended. If you need this feature, it is possible to use an older version of the technology where it is legitimately included. This may not be a good idea; after all there are certainly good reasons the feature was deprecated. You may not want to stick with an old version of a technology, but this is nonetheless perfectly allowed.
  • Is an element added in a recent version of a technology usable in an earlier version? Unless you have a time travel machine, of course not! This means you can only use the object element in HTML 4.01 and more recent versions of (X)HTML.
  • What about embed? Good or bad, embed was never included in any version of HTML. Again, it is not a question of “backwards-compatibility”.

The question we ought to be asking is: How do we include multimedia in (X)HTML documents in a way that will work with every existing browser?

Conclusion

As we have just seen, backwards-compatibility is not truly relevant to the issue of multimedia inclusion. What we need to know is how well the different techniques attached to the different versions of (X)HTML are supported by the browsers, and based on that knowledge, which DTDs and associated techniques should be chosen.

There is no a single best option, but we recommend:

  1. Choose a DTD, strict if possible. Strict DTDs are supported by browsers, authoring tools, and devices.
  2. When the DTD is chosen, use the available tags and avoid items which are deprecated
  3. If the web content is to be changed in the future or delivered in a different way (such as generating RSS feeds) using older deprecated tags or unsupported methods and not using well-formed/strict DOCTYPEs may or will cause that web content to break. Also, if the document will need a transformation, if it is in strict format and well-formed then transformation to other DOCTYPEs or formats will be easier to accomplish or automate.

The test results show that the implementation of object element in modern browsers has been improved but is not yet perfect. The object element is part of XHTML 2.0 Working Draft specification.

Specifications are now created according to stricter rules than in the past, and this will no doubt benefit future implementations of the object element.

Please run these tests with your platform of choice and send a quick report to the mailing-list. This way, we will be better armed to request more solid implementations of the object element from user agent vendors.

Discussion

For clarification and discussion on this topic, please address your
comments and questions to the W3C Web Standards Education list.

To subscribe to the list, send an email to href="mailto:[email protected]">public-evangelist-
[email protected] with “Subject: subscribe”. You can read
archived posts at href="http://lists.w3.org/Archives/Public/public-evangelist/">http://
lists.w3.org/Archives/Public/public-evangelist/.

The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.

All of the entries posted in WaSP Buzz express the opinions of their individual authors. They do not necessarily reflect the plans or positions of the Web Standards Project as a group.

This site is valid XHTML 1.0 Strict, CSS | Get Buzz via RSS or Atom | Colophon | Legal