W3C home > Mailing lists > Public > www-html@w3.org > February 2005

Test Suite for Object element in HTML 4.01 (XHTML 1.0, XHTML 1.1)

From: Karl Dubost <karl@w3.org>
Date: Mon, 14 Feb 2005 15:55:43 -0500
Message-Id: <5f3196dd331aad26ee27f43ade534754@w3.org>
Cc: <www-html@w3.org>
To: Tantek Çelik <tantek@cs.stanford.edu>
Hi,

Le 09 févr. 2005, à 12:08, Tantek Çelik a écrit :
> On 2/8/05 11:55 AM, "Karl Dubost" <karl@w3.org> wrote:
>> For example, the element object is not implemented correctly on any
>> browser I have tried so far and I say any, and believe me I would love
>> to be proved wrong.
>
> With all due respect, such statements are hollow without an  
> accompanying URL
> to a valid page using <object> which you believe demonstrates this.

Because Tantek has said, there's a need for a test suite "to  
demonstrate" the bad implementations of the "object" element.
And Because Tantek said that without knowing that there is (was) an  
ongoing effort which has not reached its goal for more than one year  
now because of a third party. I have decided to restart the effort of  
object element test cases/test suite.

http://www.w3.org/TR/1999/REC-html401-19991224/struct/ 
objects.html#edef-OBJECT

I'm preparing it.
It will have to be cross-checked and verified by your expert eyes to  
fix the possible mistakes, I would have made interpreting the  
specification.

Once the work will have been completed a bit more I will publish the  
list of tests and people will be able to run against their  
implementations.

Tantek, I encourage you to participate to this effort and if you want.

Benefits:
	* The object element is not very well implemented, or at least not  
consistently.
	* The mobile industry has a strong need of the object element and for  
interoperability purpose, that it works the same everywhere.
	* Helps desktop browser developers to fix their software when it's  
needed.

This is the preliminary list of _assumptions_, I have made from HTML  
4.01 specification. Please feel free to fix, to add comments, etc.  
Don't forget, the goal is to create a test suite and trying to make a  
good implementation report.

To give you an example of the difficulty:

	[[[
	codetype = content-type [CI]
	This attribute specifies the content type of data expected when  
downloading the object specified by classid. This attribute is optional  
but recommended when classid is specified since it allows the user  
agent to avoid loading information for unsupported content types. When  
absent, it defaults to the value of the type attribute.
	]]]

[Assertion-001] MUST:  codetype = content-type [CI] When absent, it  
defaults to the value of the type attribute.

-> What's happening when "codetype" and "type" are in conflicts? which  
one has precedence. Not specified in the specification.
-> The attribute is optional (SHOULD) but recommended (MUST with a  
classid ???) when classid is specified.
-> Conflicts: usually for an HTML file, there are 3 ways of declaring  
the content type. Imagine there's a PNG image (image/png) which is sent  
with image/gif by the server.

	1. Sent by the Server
		Content-Type: image/gif
	2. object element type attribute
		type="image/png"

In this case, the user agent must choose the one from the server.  
	[Assertion-014] type attribute: If the value of this attribute differs  
from the HTTP Content-Type returned by the server when the object is  
retrieved, the HTTP Content-Type takes precedence.

The browser MUST return a broken image? MUST display the next object  
(fallback mechanism), MUST warn the user is going in recovering mode?  
MUST silently recover?

etc, etc, etc.


*** The Assertions List. ***

	[Assertion-001] MUST:  codetype = content-type [CI] When absent, it  
defaults to the value of the type attribute.
	[Assertion-002] MUST: (Rendering) If the user agent is not able to  
render the object for whatever reason (configured not to, lack of  
resources, wrong architecture, etc.), it must try to render its  
contents.
	[Assertion-003] MUST: (Rendering) The user agent must first try to  
render the object.
	[Assertion-004] MUST: align=bottom (deprecated) This is the default  
value.
	[Assertion-005] MUST: align=left (deprecated) floats the object to the  
current left margin. Subsequent text flows along the image's right  
side.
	[Assertion-006] MUST: align=right (deprecated) Floats the object to  
the current right margin. Subsequent text flows along the image's left  
side
	[Assertion-007] MUST: border=pixels (deprecated and implementation  
dependant) This attribute specifies the width of an IMG or OBJECT  
border, in pixels. The default value for this attribute depends on the  
user agent.
	[Assertion-008] MUST: codebase = uri [CT] This attribute specifies the  
base path used to resolve relative URIs specified by the classid, data,  
and archive attributes.
	[Assertion-009] MUST: codebase = uri [CT] When absent, its default  
value is the base URI of the current document.
	[Assertion-010] MUST: declare [CI] When present, this boolean  
attribute makes the current OBJECT definition a declaration only. The  
object must be instantiated by a subsequent OBJECT definition referring  
to this declaration.
	[Assertion-011] MUST: End tag of object required
	[Assertion-012] MUST: hspace=pixels (deprecated and fuzzy definition)  
This attribute specifies the amount of white space to be inserted to  
the left and right of an IMG, APPLET, or OBJECT. The default value is  
not specified, but is generally a small, non-zero length.
	[Assertion-013] MUST: Start tag of object required
	[Assertion-014] MUST: type = content-type [CI] If the value of this  
attribute differs from the HTTP Content-Type returned by the server  
when the object is retrieved, the HTTP Content-Type takes precedence.
	[Assertion-015] MUST: vspace=pixels (deprecated and fuzzy definition)  
This attribute specifies the amount of white space to be inserted above  
and below an IMG, APPLET, or OBJECT. The default value is not  
specified, but is generally a small, non-zero length.
	[Assertion-016] MUST: width, height (intrinsic size) Ambiguous, no  
clear definition When specified, the width and height attributes tell  
user agents to override the natural image or object size in favor of  
these values. Test 001
	[Assertion-017] MUST: width, height (override) When specified, the  
width and height attributes tell user agents to override the natural  
image or object size in favor of these values. Test 002
	[Assertion-018] MUST: width, height (percentage) Note that lengths  
expressed as percentages are based on the horizontal or vertical space  
currently available, not on the natural size of the image, object, or  
applet. Test 003
	[Assertion-019] MUST?: (choice of renderer) The OBJECT element allows  
authors to control whether data should be rendered externally or by  
some program, specified by the author, that renders the data within the  
user agent.
	[Assertion-020] MAY: (embedded content type) each embedded OBJECT  
declaration may specify alternate content types.
	[Assertion-021] MAY: (object element inside head) The OBJECT element  
may also appear in the content of the HEAD element.
	[Assertion-022] MAY: archive = uri-list [CT] Preloading archives will  
generally result in reduced load times for objects.
	[Assertion-023] MAY: archive = uri-list [CT] This attribute may be  
used to specify a space-separated list of URIs for archives containing  
resources relevant to the object, which may include the resources  
specified by the classid and data attributes.
	[Assertion-024] MAY: classid = uri [CT] It may be used together with,  
or as an alternative to the data attribute, depending on the type of  
object involved.
	[Assertion-025] MAY: classid = uri [CT] This attribute may be used to  
specify the location of an object's implementation via a URI.
	[Assertion-026] MAY: data = uri [CT] If given as a relative URI, it  
should be interpreted relative to the codebase attribute.
	[Assertion-027] MAY: data = uri [CT] This attribute may be used to  
specify the location of the object's data, for instance image data for  
objects defining images, or more generally, a serialized form of an  
object which can be used to recreate it.
	[Assertion-028] MAY: standby = text [CS] This attribute specifies a  
message that a user agent may render while loading the object's  
implementation and data.
	[Assertion-029] MAY: width, height (Reserving space during rendering)  
The height and width attributes give user agents an idea of the size of  
an image or object so that they may reserve space for it and continue  
rendering the document while waiting for the image data.
	[Assertion-030] SHOULD-author: Authors should complete this  
declaration by including alternate text as the contents of OBJECT in  
case the user agent cannot render (the clock).
	[Assertion-031] SHOULD-author: Authors should not include content in  
OBJECT elements that appear in the HEAD element.
	[Assertion-032] SHOULD-author: classid and data In order to ensure  
portability, authors should use the PARAM element to tell  
implementations where to retrieve additional data.
	[Assertion-033] SHOULD-author: Since user agents generally do not  
render elements in the HEAD, authors should ensure that any OBJECT  
elements in the HEAD do not specify content that may be rendered.
	[Assertion-034] SHOULD: (Rendering) It should not render the element's  
contents, but it must examine them in case the element contains any  
direct children that are PARAM elements (see object initialization) or  
MAP elements (see client-side image maps).
	[Assertion-035] SHOULD: align=bottom (deprecated) means that the  
bottom of the object should be vertically aligned with the current  
baseline.
	[Assertion-036] SHOULD: align=middle (deprecated) means that the  
center of the object should be vertically aligned with the current  
baseline.
	[Assertion-037] SHOULD: align=top (deprecated) means that the top of  
the object should be vertically aligned with the top of the current  
text line.
	[Assertion-038] SHOULD: archive = uri-list [CT] Archives specified as  
relative URIs should be interpreted relative to the codebase attribute.
	[Assertion-039] SHOULD: codetype = content-type [CI] This attribute  
specifies the content type of data expected when downloading the object  
specified by classid. This attribute is optional but recommended when  
classid is specified since it allows the user agent to avoid loading  
information for unsupported content types.
	[Assertion-040] SHOULD: type = content-type [CI] This attribute  
specifies the content type for the data specified by data. This  
attribute is optional but recommended when data is specified since it  
allows the user agent to avoid loading information for unsupported  
content types.
	[Assertion-041] SHOULD: width, height When the object is an image, it  
is scaled. User agents should do their best to scale an object or image  
to match the width and height specified by the author.
	[Assertion-042] SHOULD?: style attribute (it doesn't say if it  
overrides width/height etc.: style = style [CN] This attribute  
specifies style information for the current element.
	[Assertion-043] Not Specified: classid and data (free to  
implementation): This document does not specify the behavior of OBJECT  
elements that use both the classid attribute to identify an  
implementation and the data attribute to specify data for that  
implementation.


Additional Tests:


	[Sup001] Insert an ascii text without encoding information from the  
server and the client Test 004





-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Tuesday, 15 February 2005 04:39:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:02 GMT