WD-object-960312
WD-object-960312This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR
Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support the insertion of multimedia objects including Java applets, Microsoft Component Object Model (COM) objects (e.g. OLE Controls and OLE Document embeddings), and a wide range of other media plug-ins. The approach allows objects to be specified in a general manner and provides the ability to override the default implementation of objects.
Closely related to this draft are the drafts for HTML Scripting and Forms. Readers are encouraged to treat all three documents as a single whole.
Previously this draft was known as the "INSERT" draft. However, on 13-Feb-96 the authors decided, with input from various parties, to rename the elements defined by the specification. Thus the document was renamed from WD-insert to WD-object.
HTML 2.0 defined only a single mechanism for inserting media into HTML documents: the IMG tag. While this tag has certainly proved worthwhile, the fact that it is restricted to image media severely limits it usefulness as richer and richer media finds its way onto the Web.
Developers have been experimenting with ideas for dealing with new media: Microsoft's DYNSRC attribute for video and audio, Netscape's EMBED tag for compound document embedding, and Sun's APP and APPLET tags for executable code.
Each of these proposed solutions attacks the problem from a slightly different perspective, and on the surface are each very different. In addition, each of these proposals falls short, in one way or another, of meeting the requirements of the Web community as a whole. However, we believe that this problem can be addressed with a single extension that addresses all of the current needs, and is fully extensible for the future.
This specification defines a new tag <OBJECT> which subsumes the role of the IMG tag, and provides a general solution for dealing with new media, while providing for effective backwards compatibility with existing browsers. OBJECT allows the HTML author to specify the data, including persistent data and/or properties/parameters for initializing objects to be inserted into HTML documents, as well as the code that can be used to display/manipulate that data. Here, the term object is used to describe the things that people want to place in HTML documents, but other terms for these things are: components, applets, plug-ins, media handlers, etc.
The data can be specified in one of several ways: a file specified by a URL, in-line data, or as a set of named properties. In addition, there are a number of attributes that allow authors to specify standard properties such as width, and height. The code for the object is specified in several ways: indirectly by the object's "class name", by information included as part of the object's data, and the combination of an object class name and a network address.
This specification covers the syntax and semantics for inserting such objects into HTML documents, but leaves out the architectural and application programming interface issues for how objects communicate with the document and other objects on the same page. It is anticipated that future specifications will cover these topics, including scripting languages and interfaces.
This section is intended to help readers get the feel of the insertion mechanism, and is not a normative part of the specification. The OBJECT tag provides a richer alternative to the IMG tag. It may be used when the author wishes to provide an alternative for user agents that don't support a particular media. A simple example of using OBJECT is:
<OBJECT data=TheEarth.avi type="application/avi">
<img src=TheEarth.gif alt="The Earth">
</OBJECT>
Here the user agent would show an animation if it supports the AVI format, otherwise it would show a GIF image. The IMG element is used for the latter as it provides for backwards compatibility with existing browsers. The TYPE attribute allows the user agent to quickly detect that it doesn't support a particular format, and hence avoid wasting time downloading the object. Another motivation for using the TYPE attribute is when the object is loaded off a CD-ROM, as it allows the format to be specified directly rather than being inferred from the file extension.
The next example inserts an OLE control for a clock:
<OBJECT
id=clock1
type="application/x-oleobject"
data="http://www.foo.bar/test.stm"
code="http://www.foo.bar/controls/clock.ocx"
>
</OBJECT>
The ID attribute allows other controls on the same page to locate the clock. The DATA attribute points to the persistent stream data used to initialize the object's state. It includes a class identifier. The CODE attribute points to a file containing the implementation for this object. The file may contain the code for several classes, but this can be resolved by the class id from the object's data stream.
In the absence of the CODE attribute, the class identifier may be sufficient to locate the code implementing this object. User agents may provide a range of mechanisms for locating and downloading such code. For some formats such as image files, the Internet media type returned with the data is sufficient.
The class identifier can be specified explicitly using the CLASSID attribute. This value takes precedence over a class identifier included as part of the object's data, e.g.
<OBJECT
id=clock1
type="application/x-oleobject"
classid="clsid:{663C8FEF-1EF9-11CF-A3DB-080036F12502}"
data="http://www.acme.com/ole/clock.stm"
>
</OBJECT>
In this example, CLASSID is specified via Component Object Model "class id" URL scheme. A "clsid" is a universally unique identifier (uuid) as defined by OSF/DCE RPC. Other object systems, such as Java, have their own URL schemes ("java:").
For speedy loading of objects you can inline the object's state data using the new URL scheme "data:", e.g.
<OBJECT
id=clock1
classid="clsid:{663C8FEF-1EF9-11CF-A3DB-080036F12502}"
data="data:application/x-oleobject;base64, ...base64 data..."
</OBJECT>
The next example is a Java applet:
<OBJECT code="BounceItem.class" width=500 height=300>
</OBJECT>
This is the bouncing heads demo. The implementation is specified by a relative URL and dereferenced with respect to the document URL. The images for the heads are loaded by the Java program as follows:
bounceimages[i-1] = getImage(getCodeBase(), "images/jon/T" + i + ".gif");
The getCodebase() function returns the URL used to retrieve the Java program, and is used here to dereference the relative URL (e.g. "images/jon/T1.gif") used for each image.
The semantics of the CLASSID attribute and the Java name space are still under discussion. The following is therefore liable to change. The previous example could have used the CLASSID attribute to specify the class name, e.g. CLASSID="java:BounceItem.class". The user agent would then use the Java specific mechanism to locate the code for this class, in this case, to first check if BounceItem.class is already installed, and if not to treat it as a relative URL, which is dereferenced with respect to the URL supplied by the CODE attribute if present, otherwise with respect to the document URL, e.g.
<OBJECT
classid="java:NervousText.class"
code="http://java.acme.com/applets/NervousText.class"
width=400
height=75
align=baseline
>
<param name=text value="This is the Applet Viewer">
</OBJECT>
In the absence of the CLASSID, user agents may obtain the Java class name from information supplied with the code itself or from the URL used to retrieve the code. The other attributes on the OBJECT element define rendering properties of the container for the applet viewer. The PARAM element specifies a named property which is used to initialize the class.
The OBJECT tag enables arbitrary code ("applets", if you will) to be downloaded and executed. The DATA attribute and the PARAM tags allow the HTML author to specify the data to be used by the applet. One application of this is in the area of HTML scripting, whereby the "applet" specified by the OBJECT tag is actually a script interpreter engine. This feature enables arbitrary programming languages to be used from within HTML. For example if there were an implementation of the Perl language interpreter as a COM object, the following could appear in the HTML documents HEAD section:
<OBJECT
id="PERL"
classid="progid:Perl.Interpreter"
code="http://www.acme.com/perl/perl.cab"
>
</OBJECT>
<script SCRIPTENGINE=PERL>
# perl script here
#
</script>
See the W3C working draft on HTML3 Scripting for more information on the SCRIPT tag.
The document type definition provides the formal definition of the allowed syntax for HTML inserts. The following is an annotated listing of the DTD defining the semantics of the elements and their attributes. The complete listing appears at the end of this document.
Length values can be specified as an integer representing the number of screen pixels, or as a percentage of the current displayable region, e.g. "50%", for widths, this is the space between the current left and right margins, while for heights, this is the height of the current window or table cell etc.
You can also use fixed units by including a suffix after a floating point number, e.g. "0.5in". The allowed suffices are: pt for points, pi for picas, in for inches, and cm for centimeters, where 72pt = 6pi = 1in = 2.54cm.
http://www.spyglass.com/techspec/img_maps.html
The OBJECT element is used to insert an object into an HTML document. It requires both start and end tags. The OBJECT element has the same content model as the HTML BODY element, except that one or more optional PARAM elements can be placed immediately after the OBJECT start tag and used to initialize the inserted object. The content of the OBJECT element is rendered if the object specified by the data, code or classid attributes can't be rendered (user agents may choose to display the content of the OBJECT element if displaying the actual element will take a long time to render). This provides for backwards compatibility with existing browsers, and allows authors to specify alternative media via nested OBJECT elements.
Note that this doesn't provide the same level of flexibility as would be provided by a richer description of resource variants. For instance when a resource in available are several media types and for each such type in English, Spanish, French and German.
<!-- Content model entities imported from parent DTD:
%body.content allows objects to contain headers, paras,
lists, form elements *and* arbitrarily nested objects.
-->
<!ENTITY % attrs
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
style CDATA #IMPLIED -- rendering annotation --
dir (ltr|rtl) #IMPLIED -- I18N text direction --
lang NAME #IMPLIED -- as per RFC 1766 --"
>
<!ENTITY % URL "CDATA" -- uniform resource locator -->
<!ENTITY % Align "(texttop|middle|textmiddle|baseline|
textbottom|left|center|right)">
<!ENTITY % Length "CDATA" -- standard length value -->
<!ENTITY % Shapes "(rect|circle|poly)">
<!ENTITY % Coords "CDATA" -- shape dependent -- >
<!-- OBJECT is a character-like element for inserting objects -->
<!ELEMENT object - - (param*, bodytext)>
<!ATTLIST object
%attrs -- id, class, style, lang, dir --
declare (declare) #IMPLIED -- declare but don't instantiate flag --
classid %URL #IMPLIED -- object class identifier --
code %URL #IMPLIED -- reference to object's code --
data %URL #IMPLIED -- reference to object's data --
type CDATA #IMPLIED -- Internet media type for data --
standby CDATA #IMPLIED -- message to show while loading --
align %Align #IMPLIED -- positioning inside document --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
border %Length #IMPLIED -- suggested link border width --
hspace %Length #IMPLIED -- suggested horizontal gutter --
vspace %Length #IMPLIED -- suggested vertical gutter --
usemap %URL #IMPLIED -- reference to image map --
shapes (shapes) #IMPLIED -- object has shaped hypertext links --
ismap (ismap) #IMPLIED -- use server-side image map -
outline %Shapes #IMPLIED -- visible outline --
coords %Coords #IMPLIED -- coords for outline --
name %URL #IMPLIED -- submit as part of form --
tabindex NUMBER #IMPLIED -- position in tabbing sequence --
>
<!-- the BODYTEXT element is needed to avoid problems with
SGML mixed content, but is never used in actual documents -->
<!ELEMENT bodytext O O %body.content>
In general, all attribute names and values in this specification are case insensitive, except where noted otherwise. OBJECT has the following attributes:
en, en-US, en-uk, i-cherokee, x-pig-latin.
The DIR attribute specifies an encapsulation boundary which governs the interpretation of neutral and weakly directional characters. It does not override the directionality of strongly directional characters. The DIR attribute value is one of LTR for left to right, or RTL for right to left, e.g. DIR=RTL.
The CLASSID attribute value takes the form of a URL scheme prefix separated by a colon from the character string defining the class identifier. The prefix is used to identify the object system for the class identifier, for example, the following gives the (clsid) uuid for a Microsoft COM object, using the CLSID name space:
classid="clsid:{663C8FEF-1EF9-11CF-A3DB-080036F12502}"
While the following gives the class name for a Java applet:
classid="java:Animator.class"
CLASSID may be sufficient for the user agent to locate the code implementing the object. However, the CODE attribute can be used with CLASSID to provide a hint as to where to look for this code. The search mechanism will in general depend on the object system the identifier belongs to. Note that the value specified with CLASSID takes precedence over a class identifier derived from the object's data stream.
When searching for the implementation of an object, the CLASSID attribute takes precedence over the DATA/TYPE attributes. A decision tree giving further details on this resolution procedure appears later on in this specification. In the absence of CLASSID a value for the class identifier may be derivable from the DATA attribute, for instance the Internet media type for the DATA may sufficient, e.g. when the data is for a GIF encoded image.
Class identifiers can be cumbersome to type, and it may be convenient to use short names that indirect via LINK elements to the full names. This makes use of the REL=POINTER attribute to indicate that the LINK element acts as a pointer, e.g.
<LINK ID=oleclock REL=POINTER
HREF="clsid:{663C8FEF-1EF9-11CF-A3DB-080036F12502}">
...
<OBJECT
id=clock1
type="application/x-oleobject"
classid="#oleclock"
data="http://www.acme.com/ole/clock.stm"
>
</OBJECT>
The short name "oleclock" is used here in place of the full class identifier. Note that LINK elements used in this way can be grouped together and placed in a separate file for convenience. Further examples of short names are given below. The Internet Draft draft-ietf-html-relrev-00.txt summarises current proposals for named hypertext relationships.
The CLASSID, CODE and DATA attributes specify URLs. Any fragment identifier included as part of these URLs should be passed to the object, either directly, or by callback.
Note that an object's data can even be included inline for immediate loading, using the "data:" URL scheme which allows the object's data to be given as a base64 encoded character string. For instance a Microsoft COM object can be asked to write its state using the WriteClassStream procedure. This inserts the object's class id as the first 16 bytes of the stream.
DATA="data:application/x-oleobject;base64, ...base64 data..."
The media type is given as part of the URL. The media type specified as part of the URL indicates that the data is in the COM persistent stream format. The class id can then be read from the start of the stream and used to find the code implementing the object's behaviour.
The CLASSID/CODE attributes can be used to override the default implementation as implied by the DATA attribute. For example, you may have the pickled data for an Excel spread sheet but want to view it with the "SuperGraph" package. You would then use the DATA attribute to point to the Excel spreadsheet data, and the CLASSID and/or CODE attribute to point to the SuperGraph plug-in.
The following grammar for media types is taken from MIME (RFC 1521):
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
token = 1 * <any (ASCII) CHAR except SPACE, CTLs, or tspecials>
tspecials = <one of the set> ( ) < > @ , ; : \ " / [ ] ? =
The following values are chosen for their ease of implementation, and their independence of other graphics occurring earlier on the same line:
For ALIGN=TEXTTOP, the top of the object is vertically aligned with the top of the current font.
For ALIGN=MIDDLE, the middle of the object is vertically aligned with the baseline.
For ALIGN=TEXTMIDDLE, the middle of the object is vertically aligned with the position midway between the baseline and the x-height for the current font. The x-height is defined as the top of a lower case x in western writing systems. If the text font is an all-caps style then use the height of a capital X. For other writing systems, align the middle of the object with the middle of the text.
For ALIGN=BASELINE, the bottom of the object is vertically aligned with the baseline of the text line in which the object appears.
For ALIGN=TEXTBOTTOM, the bottom of the object is vertically aligned with the bottom of the current font.
For ALIGN=LEFT, the object is floated down and over to the current left margin. Subsequent text is flowed past the right hand side of the visible area of the object.
For ALIGN=CENTER, the object is floated to after the end of the current line and centered between the left and right margins. Subsequent text starts at the beginning of the next line.
For ALIGN=RIGHT, the object is floated down and over to the current right margin. Subsequent text is flowed past the left hand side of the visible area of the object.
Smooth scaling a small image to a larger size provides an effective solution to reducing the time needed to download an image, offering better subjective results when compared to color reduction.
Some objects allow themselves to be resized by the user, e.g. by dragging size bars. In this case the width and height attributes of the OBJECT element are used as initial values. When the object is resized the outline should be scaled to match. The same applies if the object changes its own size from the suggested width and height attribute values, for example to match its data.
Where x and y are measured in pixels from the left/top of the visible area of the object. If x and y values are given with a percent sign as a suffix, the values should be interpreted as percentages of the object's width and height, respectively.
Further information on OUTLINE is given below.
The DECLARE attribute of the OBJECT element is used to specify an object without inserting it into the document. Normally, OBJECT implies that the "body" requires a reference to the object. The DECLARE attribute allows HMTL authors to specify that the "body" does not directly reference the object; some other element does (via a URL that targets the OBJECT's ID value).
OBJECT markup with the DECLARE attribute imply objects that are not created (instantiated) until needed by something that references them (i.e. late binding). Each such "binding" typically results in a separate copy of the object (this is class dependent). In other words, the OBJECT DECLARE is treated as a declaration for making an instance of an object.
If the declared object isn't supported, or fails to load, the user agent should try the contents of the OBJECT DECLARE element, which is currently restricted to another OBJECT DECLARE element. The TYPE attribute can be used to specify the Internet Media Type for the object as a hint for this situation.
To allow PARAM values to be "object valued"; that is the value of the parameter is a pointer to an object. See the example below in the section describing the PARAM tag.
To allow hypertext links to point to objects which can't otherwise be addressed using a single URL.
For instance:
<OBJECT ID="obj1" DECLARE CLASSID="clsid:{ ... }">
<PARAM NAME=param1 VALUE=value1>
<PARAM NAME=param2 VALUE=value2>
...
</OBJECT>
<P>This points to an <A HREF="#obj1">object</A>.
Note: Anchors can exploit nested declared objects to provide alternative media for a given resource.
Use of <OBJECT DECLARE> for document backgrounds is discussed below.
The PARAM element allows a list of named property values (used to initialize a OLE control, plug-in module or Java applet) to be represented as a sequence of PARAM elements. Note that PARAM is an empty element and should appear without an endtag.
<!ELEMENT param - O EMPTY -- named property value -->
<!ATTLIST param
name CDATA #REQUIRED -- property name --
value CDATA #IMPLIED -- property value --
valuetype (DATA|REF|OBJECT) DATA -- How to interpret value --
type CDATA #IMPLIED -- Internet media type --
>
The NAME attribute defines the property name. The case sensitivity of the name is dependent on the code implementing the object.
The VALUE attribute is used to specify the property value. It is an opaque character string whose meaning is determined by the object based on the property name. Note that CDATA attribute values need characters such as & to be escaped using the standard SGML character entities, e.g. & for "&". It is also essential to escape the > character to defend against incorrect handling by many existing browsers (use >).
The VALUETYPE attribute can be one of REF, OBJECT, or DATA as described below:
Note that the valuetype attribute value can be given without the corresponding attribute name, see examples below. This exploits a feature of SGML minimization.
The TYPE attribute is only valid for VALUETYPE=REF. Note that, at present, there is no protocol for COM objects to receive properties typed by Internet media types; thus for COM objects this attribute serves no purpose.
Example 1:
<PARAM NAME="Caption" VALUE="Hello World!">
is equivalent to
<PARAM NAME="Caption" DATA VALUE="Hello World!">
The string "Hello World!" is passed to the object as the value for the "Caption" property.
Example 2:
<PARAM NAME="Font" OBJECT VALUE=#MyFont>
A pointer to the object (<OBJECT> tag) referenced by #MyFont is passed to the object as the value for the "Font" property. For COM objects, this means the property type is IUnknown* (VT_UNKNOWN) or IDispatch* (VT_DISPATCH). If the OBJECT tag referenced is of the "DECLARE" type, a new instance will be created. Otherwise the existing instance will be used.
Example 3:
<PARAM NAME="Source" REF VALUE=images/foo.gif>
The "Source" property of the object gets the string "http://base.url.com/images/foo.gif" as it's value.
Example 4:
<PARAM NAME="Source" REF VALUE=http://abc.com/images/bar.gif>
The "Source" property of the object gets the string "http://abc.com/images/bar.gif" as it's value.
Example 5:
Here is a complete example of an OBJECT element (Button1) using all variants of the PARAM tag. In this example, the HTML author wishes to set the Font property of a button control that can do a hyperlink jump to 12 point Bold Courier New:
<object declare id=Btn1Font classid=#CLSID-StdFont>
<param name="Face" data value="Courier New">
<param name="Bold" data value="True">
<param name="Size" data value="12">
</object>
<object id="Button1" classid=#CLSID-HyperLinkButton>
<param name="Font" object value=#Btn1Font>
<param name="Text" data value="Go To Home Page">
<param name="Target" ref value="http://www.somewhere.com/">
<param name="Source" ref value="">
</object>
The "Face", "Bold", and "Size" param elements are all of the DATA variety. The font object, when created, receives each of the property values specified.
The "Font" param element is of the OBJECT variety. An instance of the object identified by id=Btn1Font is created (and initialized) and the "Button1" control receives a pointer to the font object.
The "Target" param element is of the REF variety. Because the URL given is fully specified, it is passed as is to the control.
The "Source" param element is also of the REF variety. Because the URL given (an empty string) is a relative URL, it is expanded to a fully specified URL before being passed to the control. (e.g. "http://www.somewhere.com/a/b/c/page3.html")
The LINK element is suitable providing "#define" like capabilities.
<link id=CLSID-CoolButton rel=pointer
href="clsid:{F6E6DDD0-0000-11cf-A50D-080036F12501}">
<link id=CLSID-CoolText rel=pointer
href="clsid:{F6E6DDD1-0000-11cf-A50D-080036F12501}">
<link id=CLSID-CoolListBox rel=pointer
href="clsid:{F6E6DDD2-0000-11cf-A50D-080036F12501}">
<link id=CLSID-CoolCombo rel=pointer
href="clsid:{F6E6DDD3-0000-11cf-A50D-080036F12501}">
<link id=CLSID-CoolCheck rel=pointer
href="clsid:{F6E6DDD4-0000-11cf-A50D-080036F12501}">
<link id=CLSID-CoolRadio rel=pointer
href="clsid:{F6E6DDD5-0000-11cf-A50D-080036F12501}">
The HTML author would then cut-and paste this snippet into his HTML document near the top. He could then have OBJECT tags that looked like this:
<OBJECT id="x" classid=#CLSID-CoolButton> <param name="Text" value="Press me"> </OBJECT>
Or, the list of LINK's could be placed into a separate file (say, for example cool.cid) and referenced as in the example below:
<OBJECT id="x" classid=cool.cid#CLSID-CoolButton> <param name="Text" value="Press me"> </OBJECT>
Image maps allow hypertext links to be associated with shaped regions on an image. The following mechanism extends the anchor element and provides backwards compatibility with all existing browsers. It removes the need to duplicate image maps with textual hypertext menus for non-graphical browsers.
The following image is a navigation toolbar:
This is represented as:
<object data="navbar.gif" shapes>
<a href=guide.html shape=rect coords="0,0,118,28">Access Guide</a> |
<a href=shortcut.html shape=rect coords="118,0,184,28">Go</a> |
<a href=search.html shape=rect coords="184,0,276,28">Search</a> |
<a href=top10.html shape=rect coords="276,0,373,28">Top Ten</a>
</object>
|
On all HTML 2.0 browsers this would look like: Access Guide | Go | Search | Top 10 |
Note:The editor believes that it would be more elegant to combine shape and coords into a single attribute named shape. This would save an attribute and reducing typing at a trivial cost in parsing.
If the OBJECT element includes a "SHAPES" attribute then all browsers need to parse the contents of the element to look for anchors. The anchor element (<a href=...> ... </a>) is extended to permit a pair of new attributes SHAPE and COORDS. These attributes associate the hypertext link with a region on the image specified by the enclosing OBJECT element. The shape/coords attributes take one of the general forms:
Where x and y are measured in pixels from the left/top of the associated image. If x and y values are given with a percent sign as a suffix, the values should be interpreted as percentages of the image's width and height, respectively. For example:
SHAPE=RECT COORDS="0, 0, 50%, 100%"
The visually impaired community have argued strongly in favor of the shaped anchor mechanism, as it forces authors to provide a way to follow the links regardless of which browser they are working with.
It's also worth noting that the SHAPE attribute can be used together with the TARGET attribute proposed by Netscape for designating the target user interface object (e.g. frame) for displaying the linked document or resource.
In the following graphic, the blue and green regions are mapped to different URLs. Although the regions overlap, clicking on each region loads the appropriate document.
If two or more regions overlap, the region defined first in the map definition takes precedence over other regions. For example, in the map definition for the graphic above, the green region is defined before the blue region:
<object data="overlap.gif" shapes>
<a href=green.html shape=rect coords="66,13,186,37">Green</a> |
<a href=blue.html shape=rect coords="195,43,245,46">Blue</a>
</object>
In all cases shape=default has the lowest precedence. It extends to the whole of the visible region of the object.
You can combine ISMAP with the SHAPES attribute, for example:
<a href="http://www.hp.com/cgi-bin/imagemap/maps/hp/navbar.map">
<object data="navbar.gif" ismap shapes">
<a href=guide.html shape=rect coords="0,0,118,28">Access Guide</a>
<a href=shortcut.html shape=rect coords="118,0,184,28">Go</a> |
<a href=search.html shape=rect coords="184,0,276,28">Search</a> |
<a href=top10.html shape=rect coords="276,0,373,28">Top Ten</a> |
</object></a>
In this case, locally defined hotzones take precedence over server-side hotzones. The browser only sends the mouse click to the server if the click is not within a region defined by a shape attribute.
This allows authors to get the benefits of client-side image maps for parts of the image, e.g. regions that visually act as 3D bevelled buttons, while for complex image maps, or where it is undesirable to pass the maps to the client, the mouse click is dealt with by the server. For instance, in Find the ball competitions where sending the image to the client would give the competition away.
The MAP element provides an alternative mechanism for client-side image maps. It was developed by the Spyglass company for use with the IMG element. The shape and coords attributes are the same as for the shaped anchor mechanism. The earlier example for the toolbar becomes:
<object data="navbar1.gif" usemap="#map1">
</object>
<map name="map1">
<area href=guide.html alt="Access Guide" shape=rect coords="0,0,118,28">
<area href=shortcut.html alt="Go;" shape=rect coords="118,0,184,28">
<area href=top10.html alt="Top Ten" shape=rect coords="276,0,373,28">
</map>
The OBJECT element references the MAP with a URL given with the USEMAP attribute. The SHAPE/COORDS attribute behave in the same way as for the shaped anchor proposal. The ALT attributes can be used to provide a few words describing each choice. This can't include markup, but can include character entities. Note that MAP doesn't provide the same degree of backwards compatibility as the shaped anchor mechanism.
The DTD or document type definition provides the formal definition of the allowed syntax for HTML objects.
<!-- Content model entities imported from parent DTD:
%body.content allows objects to contain headers, paras,
lists, form elements *and* arbitrarily nested objects.
-->
<!ENTITY % attrs
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
style CDATA #IMPLIED -- rendering annotation --
dir (ltr|rtl) #IMPLIED -- I18N text direction --
lang NAME #IMPLIED -- as per RFC 1766 --"
>
<!ENTITY % URL "CDATA" -- uniform resource locator -->
<!ENTITY % Align "(texttop|middle|textmiddle|baseline|
textbottom|left|center|right)">
<!ENTITY % Length "CDATA" -- standard length value -->
<!ENTITY % Shapes "(rect|circle|poly)">
<!ENTITY % Coords "CDATA" -- shape dependent -- >
<!-- OBJECT is a character-like element for inserting objects -->
<!ELEMENT OBJECT - - (param*, bodytext)>
<!ATTLIST OBJECT
%attrs -- id, class, style, lang, dir --
declare (declare) #IMPLIED -- declare but don't instantiate flag --
data %URL #IMPLIED -- reference to object's data --
code %URL #IMPLIED -- reference to object's code --
classid %URL #IMPLIED -- object class identifier --
type CDATA #IMPLIED -- Internet media type for data --
standby CDATA #IMPLIED -- message to show while loading --
align %Align #IMPLIED -- positioning inside document --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
border %Length #IMPLIED -- suggested link border width --
hspace %Length #IMPLIED -- suggested horizontal gutter --
vspace %Length #IMPLIED -- suggested vertical gutter --
usemap %URL #IMPLIED -- reference to image map --
shapes (shapes) #IMPLIED -- object has shaped hypertext links --
ismap (ismap) #IMPLIED -- use server-side image map --
outline %Shapes #IMPLIED -- visible outline --
coords %Coords #IMPLIED -- coords for outline --
name %URL #IMPLIED -- submit as part of form --
tabindex NUMBER #IMPLIED -- position in tabbing sequence --
>
<!-- the BODYTEXT element is needed to avoid problems with
SGML mixed content, but is never used in actual documents -->
<!ELEMENT bodytext O O %body.content>
<!ELEMENT param - O EMPTY -- named property value -->
<!ATTLIST param
name CDATA #REQUIRED -- property name --
value CDATA #IMPLIED -- property value --
valuetype (DATA|REF|OBJECT) DATA -- How to interpret value --
type CDATA #IMPLIED -- Internet media type --
>
Currently, when it comes to finding the implementation for a given object, CLASSID takes precedence over CODE, which in turn takes precedence over DATA.
The editor believes that both Microsoft and Netscape want to restrict CODE to act as no more than a hint as to where to get an implementation, based on CLASSID, if present, otherwise based on the DATA/TYPE attributes and data stream. Under this assumption, DATA takes precedence over CODE, and if you want to override the default implementation for DATA you are forced to use CLASSID to specify the intended implementation. But in many cases there won't be a class identifier as such. For this reason, I propose we change the names of the attributes to: CODE, CODEBASE, DATA and TYPE. These attributes would be defined as follows:
- CODE
- This is either a class identifier (such as an OLE COM class id) or points directly to the code to use as the implementation of this object.
- CODEBASE
- When CODE specifies a class identifier, the CODEBASE attribute provides a hint as to where to find a matching implementation. The mechanism for resolving the hint is dependent on the name space for class identifiers.
- DATA
- This is a pointer to the object's data. In the absence of the CODE attribute, the media type of the data, perhaps together with information in the data stream, is used to determine a default value for the CODE attribute. The implementation is then loaded as if the CODE attribute had been given explicitly.
- TYPE
- This can be used to specify the media type of the data in advance of actually retrieving it.
This section defines the steps needed to bind an object given various combinations of attributes. Without a precise semantics for this, different user agents would otherwise produce different results to the frustration of authors.
If the CLASSID attribute is present:
Try to load an implementation based on the CLASSID. If that fails but a CODE attribute is present, then see if that can be used to find an implementation matching the CLASSID attribute. For instance, the CODE attribute might point to a directory containing implementations for a several Java classes.
If the CLASSID attribute is missing:
If the CODE attribute is present, then see if it can be used to find an implementation. For instance, the CODE attribute might point to the SuperGraph applet to be used to view an Excel spreadsheet pointed to by the DATA attribute. If the CODE attribute is missing then its necessary to use the DATA attribute to find identify a suitable implementation.
The media type of the data retrieved using the DATA attribute may be sufficient to identify a suitable implementation, for instance a GIF viewer. The TYPE attribute when present provides the media type in advance of loading the data. It speeds up the selection process, allowing the implementation to be retrieved in parallel with the data. In some cases though, the contents of the data stream may need to be inspected to gather enough information to make the choice. For instance an OLE COM stream with a media type:
type="application/x-oleobject"
This has a COM class id at the start of the data stream that should be enough to load the implementation.
In theory one might want to get the clsid from the data and then use the CODE attribute to find a specific implementation matching it. This would only occur with application/x-oleobject and avoids the need to specify the clsid in advance.
This step only takes place if the DATA attribute is present
Any URL parameters referencing declared objects would need to be instantiated prior to passing them to the new object.
This section describes proposals for extending the capabilities of the insertion mechanism as an encouragement and guide to developers wishing to experiment with such features. These ideas are under discussion, and support is not required for conformance with this specification.
Using a GIF image to tile the document background often results in significant delays while the image tile is downloaded. The ability to use a small Java applet or OLE Control to generate the image tile would allow rich background textures and patterns to be used without causing significant delay. As processing speeds increase, using an object to generate the background would make it practical to create animated backgrounds.
The proposed extension is to allow the BACKGROUND attribute of the BODY element to reference OBJECT DECLARE elements, for example:
<title>Demo Document</title> <object declare id=marble code="http://www.acme.com/applets/marble.class"> </object> <body background="#marble"> <p>This document has a marble texture generated by an applet.
Overlays are useful for reducing network bandwidth needs. For instance, you can place a PNG overlay on top of a JPEG image. If the PNG image is used for an antialiased text overlay while the JPEG image is used for an underlying photographic image with a high compression factor, then the two images will take significantly less time to send than a single image combining both layers. Selecting the format and compression for each layer separately allows you to get higher compression for the same level of quality.
Overlays also save time by making caching more effective. For instance you might send a large image on one page, and then make small changes to it on subsequent pages. Using an overlay allows the original large image to be reused, so that only the small changes need to be sent with each successive page.
<!ELEMENT overlay - O EMPTY -- image overlay -->
<!ATTLIST overlay
id ID #IMPLIED -- for naming this overlay --
class NAMES #IMPLIED -- for subclassing element --
style CDATA #IMPLIED -- for attaching style info --
x %Length #IMPLIED -- offset from left of parent --
y %Length #IMPLIED -- offset from top of parent --
width %Length #IMPLIED -- suggested width --
height %Length #IMPLIED -- suggested height --
src %URL #IMPLIED -- network address of object --
>
For instance, here is a road map overlayed on an aerial photograph:
<OBJECT data="photo.jpeg">
<overlay src=grid.png>
</OBJECT>
The SRC attribute of the OVERLAY element could be used together with an OBJECT DECLARE element. This allows you to create overlays from OLE controls or Java applets.
A time proven idiom for document layout is the figure. This is often an illustration, but may contain textual material separate from the main flow of the document. Figures are typically captioned and floated to between columns or to the top or bottom of a page. It is not uncommon to see separate contents lists for figures and tables, in addition to the main table of contents.
It is proposed that the FIG element is used to create captioned figures:
<!ENTITY % f.align "(left|center|right)">
<!ELEMENT fig - - (caption?, bodytext)>
<!ATTLIST fig
%attrs -- id, class, style, lang, dir --
align %f.align #IMPLIED -- position on page --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
>
<!ENTITY % c.align "(top|bottom|left|right)">
<!ELEMENT caption - - %body.content>
<!ATTLIST caption
%attrs -- id, class, style, lang, dir --
align %c.align #IMPLIED -- position relative to figure --
>
For example:
<fig>
<caption>Mount Washington</caption>
<OBJECT data=http://www.acme.com/images/vista.jpeg>
<p>A spectacular view of Mount Washington during a winter sunset.
</OBJECT>
</fig>
Note that FIG is a block-like element similar to tables. If a user agent supports tables then adding support for figures is quite simple, since the FIG element behaves in the same as a table with a caption and a single cell. Of course some would argue that in this case, why not use the TABLE element. This is an example of approaching HTML with a view to getting a desired visual effect without regard to what the markup means. This makes it hard to export HTML to other document formats, and makes it harder to read the markup, as you now have to guess what the author actually was trying to do.
Image such as GIF and PNG formats allow textual messages to be included with the image data. This provides an appropriate place to store copyright messages since these will then be automatically transferred with the image when it is dragged from the document to the desktop etc. For other formats, copyright notices can be included in HTTP headers, or by wrapping up the objects as MIME multipart files.
Even when information can be included as part of the object's data, it is still useful to present a credit or copyright message to the user as part of the document text. Something immediately visible is more effective that something hidden! The suggested way of handling credits is to use a new character emphasis element CREDIT that can be given as part of the FIG contents, e.g.
<fig>
<object data=http://www.acme.com/images/vista.jpeg>
<p>A spectacular view of Mount Washington during a winter sunset.
</object>
<credit>John Smith</credit>
</fig>
The World Wide Web Consortium: http://www.w3.org/pub/WWW/Consortium/