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

On 2/14/05 12:55 PM, "Karl Dubost" <karl@w3.org> wrote:

> 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.

A test *suite* would be sufficient but not necessary in this case.  All that
would be necessary is are the minimum tests to prove the above statement
that " the element object is not implemented correctly on any
 browser I have tried so far" along with a list of such browsers.  A proper
test suite for object is probably quite a bit more work.


> 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.

Karl, this is excellent.  It's always good to have more folks developing
test suites and materials.


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

Perhaps it should be I encouraging *you* to build on the effort several
folks (including myself) started over two years ago with the HTML4.01 Test
suite:

http://w3.org/MarkUp/Test/HTML401/20030123/

Including testable assertions for <object>:

http://w3.org/MarkUp/Test/HTML401/20030123/assertions/assertions_section13.h
tml

A few of which are linked to respective tests in said test suite:

http://w3.org/MarkUp/Test/HTML401/20030123/tests/section13.html

But many more which need tests!

The point is, there is no need to start from scratch, please build upon the
already started W3C HTML4.01 test suite effort.


> 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.

Agreed, that is unspecified.  One solution would be to write a test for it,
and check what browsers that support both codetype and type do in that case,
if they interoperate, suggest an erratum to HTML4.01 accordingly.


> -> The attribute is optional (SHOULD) but recommended (MUST with a
> classid ???) when classid is specified.

IMHO I would interpret "optional" as a MAY and "recommended" as a SHOULD.
If present, the word "required" would be MUST.


> -> 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?

This is more well specified than you make it seem.  The browser sees the
type from HTTP headers, and if it supports it it renders it, if not, it
follows the fallback rules.


> 
> etc, etc, etc.
> 
> 
> *** The Assertions List. ***

See:

http://w3.org/MarkUp/Test/HTML401/20030123/assertions/assertions_section13.h
tml

Thanks,

Tantek

Received on Tuesday, 15 February 2005 16:52:27 UTC