[whatwg] embedded content: OBJECT

I too think there needs to be some specifics on how the UA should
handle objects.

The current methods of "The server Content-Type rules all" and "If
there's no data attribute, then fail" are
not working out. There are cases where a data attribute is not needed
and there are cases where a type attribute
should be the priority. The type attribute is really used as "Here's
what plug-in/handler I want to use".

There also needs to be some specifics for the classid attribute.  If
the classid contains an unsupported naming
scheme, should the UA really have to just fail or should it go on and
try to use the type and data attributes?

How should data uris be handled?  Is it just up to the plug-in to
handle the passed data uri or is the UA allowed
to create a file from the data URI and pass the file path to the
plug-in/hander (if it can do it safely)?

What should happen when a UA encounters a codebase attribute that has
a path to a cab file instead of a base URI?
Should the UA always use the codebase to resolve URIs even if it has junk in it?

Anyway, here's how ( which still isn't specific enough ) I think a UA
should handle the object element.


Object Element - Order of Operations:

Pre-Initialization:

First, the UA should check for a classid attribute.

If present and the the UA has a handler associated with the specified
naming scheme, then the UA should pass all arguments to the handler in
a manner that is specific to the handler.

If the classid attribute is not present or the naming scheme is not
supported or the handler returns an error code, then the UA must check
for the presence of a type attribute.

If it exists, the UA must check to see if it has a handler associated
with the Content-Type specified in the type attribute.

If the Content-Type is associated with a handler, the UA must pass all
arguments to the handler.

If that fails and there is a data attribute, check the Content-Type
sent by the server for the file and determine if there's a handler
associated with the type.

If there is a handler associated with the type, pass all arguments to
the handler.

If there is not, the UA *should* compare the file extension to a list
of known Content-Types associated with that extension.

If a handler is found, pass all arguments to the handler.

If no handler was found through any of the methods, display the
fallback content.

( URIs to files should be passed to the handler and the handler should
download the files as necessary. The Ua should
not download the file on its own. Only the handler should make that
request to the UA.)


Initialization:

Once the handler gets the arguments, it *must* detmermine whether it
has the necessary and valid arguments to initialize. If it does not,
it should return a failure code. If it does, it should try to
initialize and if successful, return a success code; otherwise, return
a failure code. The handler should return a failure code in every
situation where there's no need to initialize in the first place.

The UA must check for this return code to determine whether to display
fallback content.


Anyway, current plug-ins do not conform to html4's recommendations and
it's a problem. However, there are more situations out there
there than the spec covers.  The current way of just following what
html4 recommends doesn't work. (An example of this would
be Firefox choking on classid value that it doesn't support instead of
ignoring it.)

I don't know the internals of how a plug-in is initialized etc.

This is just to show the need for specifics and to spark up some discussion.

burnout426

Received on Monday, 30 January 2006 21:51:59 UTC