|
|
|
A Sample Chapter from
|
HTML 4.01 Programmer's Reference
|
|
Book Title: |
HTML 4.01 Programmer's Reference |
|
Published by: |
Wrox Publication |
|
Chapter Number: |
10 |
|
Chapter Title: |
Embedding Objects |
|
Author: |
Wrox Author Team |
|
Price $: |
24.99 |
|
ISBN: |
1861005334 |
|
Buy It Now: |
Click here |
|
Additional Info: |
Wrox Publication |
|
|
HTML 4.01
|
|
|
Embedding Objects
While what we've looked at in HTML so far, such as links, tables, and
forms, offers a lot of important functionality, there are still many things that
can't be achieved with just HTML alone. What happens if we want a movie embedded
in our web page, or an audio MP3 file? In the first days of the web, we could do
little more than browse hyper-linked text pages with the very occasional image if
we were lucky. With HTML 2.0, we could only insert images, videos, sounds, and text.
This improved further with HTML 3.2, but to add anything more, such as simple animated
messages, spreadsheets, word documents, or even full 3D renderings of landscapes,
we needed to insert them as objects.
HTML 4.01 allows for this by making the <object> element the standard
way of doing this. Previously, the placement of objects in web pages was supported
in a mish-mash of standard and non-standard ways. Indeed, the <object> element
supercedes the <applet>, <embed>, and <img> elements, as well
as Microsoft's <bgsound> element and dynasrc attribute. The <object>
element is mainly used for content types the browser can't handle itself, and therefore
an <object> element needs to provide both the data to be displayed and the
plug-in that handles the display of the data. <object>, in theory, provides
a single way to embed a whole range of objects into web documents, and offer more
universal, cross-platform support for HTML pages.
However, a major source of disappointment is that the <object>
element, despite being the standard way of doing this, was until recently, only
really available in Internet Explorer. This is because the plug-ins needed to support
many objects are not often universally cross-platform compatible. Netscape 6 goes
part of the way to rectifying this, by adding support. Despite this, though, in
the early versions of Netscape 6 (6.0 and 6.01), support for the <object>
element when adding anything other than images, was erratic verging on non-existent
at times. However, in the more up-to-date Mozilla milestone builds (0.8 and beyond,
which form the basis for future Netscape releases), many of these problems have
been resolved, and <object> will therefore work properly in the next major
upgrade to Netscape 6 expected in summer 2001. Also, other browsers such as Opera
5, and older browsers like Netscape 4 still have limited support for this element
and rely entirely on the old <embed> element to enable components.
In this chapter we will be focusing on the <object> element, as
the other elements (except for <img>) have either been deprecated, and are
covered in Chapter 15, or in the case of the <embed> and <bgsound> elements,
were never part of the standard. Both of these elements are covered in Chapter 16.
The <object> Element –
History
Originally, the HTML 2.0 Standard provided only one method for incorporating
media into HTML documents: the <img> element. This element has certainly proved
worthwhile, but it is, of course, restricted to image media, which means that its
usefulness is limited as richer media find their way onto the Web. For other media
though, there was the <embed> element, which was introduced in Netscape 2
and IE 3, and is still in many browsers the only way to insert many types of objects
into web pages. With the introduction of Java, the <applet> element was introduced
in HTML 3.2, to allow developers to insert Java applets.
The <object> element was originally introduced by Microsoft in Internet Explorer
3 for the inclusion of Microsoft Component Object Model or COM objects
(such as ActiveX Controls and a wide variety of different media types and plug-ins).
Internet Explorer introduced this tag with support for ActiveX controls, and Microsoft
has continued to develop around it.
The reason the <object> element has proved so popular with the HTML W3C standards
body, and was ultimately adopted by it, was that it introduces a uniform way to
embed all kinds of object – images, Java applets, movies, etc. We can't use
the <embed> tag to place images or Java applets, and we can't use the <img>
element for anything other than images, yet the logic behind introducing this content
is very similar for each type of object. For each object, regardless of whether
it's a graphic, a Java applet, or a RealTime movie, we still need to state the location
of the object, the type of object we are including, and a place to download a "helper
application" so that the browser can still invoke the object, even if it doesn't
have native support for it.
|
A helper application is one that needs to be downloaded by the browser before it
can run a particular object. For instance with some browsers need to download Macromedia's
Flash before they can run a Flash animation.
|
Arguably, the <embed> element handles all of these features as
well and could have been adapted to handle images and Java applets; however, the
<object> element, together with the param attribute provides a cleaner and
more general approach to passing parameters to the component, and that may have
been what tipped the scales in its favor.
It's an attractive solution, if a somewhat flawed one in some ways.
One problem was that Netscape 4 didn't support the <object> element –
Netscape still preferred to use the <embed> element, which was never officially
recognized, but as previously mentioned, <object> has been introduced in Netscape
6 and Opera 5, albeit to a limited extent. There is also the problem that several
components created by Microsoft only ship with Internet Explorer, and are therefore
only available with Internet Explorer, such as the graphic effects filters. In general,
it is possible to add a lot of other third-party components with <object>
in Netscape 6, such as images and applets, and it is possible to include images
in Opera 5. However, at this precise moment in time, the <object> element
is not an entirely cross-browser solution.
How the <object> Element Works
Most browsers have built-in native support for common features
such as images (GIFs, JPEGs, and PNGs), text, fonts, and colors. When IE 4 was released
in 1997, the most common components available on the web were ActiveX controls and
Java applets, both of which could be run by the <object> element. However,
there has been a considerable shift since then. COM objects have replaced ActiveX
controls, and these in turn are in the process of being partially superceded by
web services in the .NET framework.
The progress with compression algorithms and higher bandwidth being
made available more cheaply means that streaming video, such as MPEGs, AVIs, and
Quick time Movies, are now much more commonplace on the web. These require separate
applications such as the Windows Media Player, or the Apple Quick Time Movie Player
to be available to run them. Secondly, audio has moved beyond large, clunky WAV
files. Streaming audio is common in the form of .ra (real audio files), but by far
the most common form of audio file is the MP3 format, which has shrunk the size
of audio files to a manageable few megabytes, while retaining a sound quality close
to that of a CD player. Once again, we need to insert a third party player such
as Windows Media Player into our page to be able to play MP3 files.
We can use the <object> element to insert these kinds of technologies.
However, due to large file sizes, the preferred method for many web users is to
download these files separately, and as a result it is becoming less common for
web developers to actively embed either video or audio files within a web page.
Instead, the most common form of embedded application in a web page is Macromedia's
motion web graphics tool – Flash. This allows developers to create animations,
interactive graphics, and menus and embed them into web pages. Flash can also handle
sound and text, and has become a popular catchall solution for developers. Flash
animations are embedded into HTML pages using the <object> element.
To be able to embed an object in a page, the W3C states that we need to specify
three types of information:
- The implementation of the included object (or the location of the executable code).
- The data to be rendered.
-
Additional values required by the object at run time.
The first two values are specified within the attributes of the <object>
element, while additional values are specified within the <param> element.
However, we don't need to specify all three at once. Some objects might not have
to be initialized at run time, while others won't have any data to render. When
a browser comes across an object it must attempt to render its contents on the web
page, otherwise it must attempt to render the contents of the <object> element.
For example:
Here we have placed some alternative text inside a non-existent object.
All browsers will display the alternative text, as they can't render the object.
We can also use the <object> element to embed objects one inside
another. The browser will attempt to the render the first <object> –
if it can't render that, then it should attempt to render the second <object>
element, and so on, until it reaches the innermost <object> element, if it
hasn't yet managed to render any objects. If it can't render any objects, then it
will render the text contained within. If we wish, we can supply the object as an
<embed>, <applet>, or <img> element within the innermost object
instead, for those browsers that don't support the <object> element.
It is also possible to insert the <object> element within the
document header (within the <head> element), as long as the <object>
element isn't intended to render any physical content on the web page. This sounds
a little strange, given that the <object> element is primarily intended for
embedding multimedia content, but it is a useful technique to consider – for
example, we could use an <object> element in the document header to invoke
a database, values out of which could then be manipulated by script in the body.
However, looking at the way in which Netscape 6 and Opera 5.x handle
the <object> element, it seems we need to ensure ourselves that the element
doesn't render, for example by setting it within a style sheet display: none;. IE
5.5 on the other hand automatically won't render any <object> elements appearing
in the <head> section.
Now, let's take a look at the <object> element's attributes, and
see how we can use an object in our web page.
<object> Attributes
The <object> element supports the following attributes:
|
archive |
border |
classid |
codebase |
|
codetype |
data |
declare |
height |
|
width |
hspace |
vspace |
name |
|
standby |
tabindex |
usemap |
|
plus the usual HTML 4.01 attributes id, class, style, dir, lang, and title, and
the common events (see Chapter 2 for more details on these).
archive
This attribute specifies a list of space-separated URLs, which have
information relevant to the resource specified in classid and data attributes. The
syntax is:
archive="urllist"
border
This attribute specifies the width of the border to be drawn around
the object. The syntax is:
border="n"
where n is an integer. For border="0", no border is drawn.
Like align, this attribute is deprecated in HTML 4.01. Style sheets are the preferred
method for adding borders.
classid
This specifies a class identifier for an object (on Windows platforms,
this information is stored in the registry on the user's machine, once the object
has been installed). The syntax is:
classid="class_identifier"
The class_identifier is the information used to create an object on our web page.
The class identifier (the HTML 4.01 standard specifies that this should be a URL)
tells the browser to draw an object of a specified type. However, in Internet Explorer
it's treated slightly differently; the classid attribute is the key to the whole
element – this is a value that is unique for every instance of the object,
and this is how the browser knows which object to load into the page. Here's an
example of the classid for the RDS control.
It is used as an alternative to the data attribute, and is often preferred in Internet
Explorer to data, where it doesn't seem to work as well for the <object> element.
codebase
This allows us to specify the URL location and version of the object
to be used. The syntax is:
codebase="url"
However, it's only IE that really implements this attribute, and it implements it
in the following way:
codebase="url#Version=a,b,c,d"
Most components need to be installed on our system before we can use them in our
web pages. In IE, the codebase attribute points to a location from where the object
can be downloaded and installed on our system for use. It also identifies the version
of the file that should be downloaded. If an object isn't available already on our
local machine then the system will have to go to the url specified. Of course, if
the site specified in the codebase is busy or out of action, then unfortunately
our page won't download and insert the requisite object correctly.
As we can see from the syntax, we can optionally append the URL with a version number
string. The string has the following format:
- a – High-order word of the major version of the component available at the
specified URL.
- b – Low-order word of the major version of the component available at the
specified URL.
- c – High-order word of the minor version of the component available at the
specified URL.
-
d – Low-order word of the minor version of the component available at the
specified URL.
If a, b, c and, d are all set to 1 then the component is only downloaded if the
release date is later than the installation date on the user's machine.
An example codebase to enable us to run a Macromedia Flash 5 animation looks like
this:
However, this will only work with IE.
|
|
|
|
|
|
