OBJECT implementation (longish)

Hey folks,

I'm looking at implementing support for the HTML 4.0 OBJECT tag The Right
Way.  But there's a number of issues that the spec does not address - and
nobody does it even close to correctly yet, so there aren't any examples to
work from.

If you have any suggestions, please let me know - or post to the list if you
think it's appropriate.

(1) Rendering an OBJECT vs. rendering the html that it contains.  Unlike
SCRIPT or EMBED or APPLET, a browser can't decide at parse time whether or
not the OBJECT will be able to render itself - the "type" attribute is
optional, so the browser may need to download some other file/code in order
to determine the MIME type.  (And even that may not determine it.)  Also,
given that the OBJECT may contain PARAMs, MAPs (and therefore AREAs and
anchors), that pretty much means that you have to parse the OBJECT contents
regardless.

But what does this mean for SCRIPT elements inside the OBJECT that contain
immediate code?  Are they executed even when the OBJECT *can* be rendered?
Or should the browser hold onto them and execute them only when the OBJECT
can't be rendered, and the contents of the OBJECT are displayed?  Or should
they be ignored?

It seems like it might be a nifty and useful thing to have a Java applet
that could fall back to a bit of JavaScript that animated some images or
such.  

(2) Should the contents of an OBJECT appear in the DOM even when they aren't
rendered?  If they should, would access to them be more limited than if they
were displayed (since they would conceivably not have downloaded the data or
code to support them).

(3) What should declaring an OBJECT do?  What behavior should you expect
when a declared object is referenced and instantiated?

How do you reference a declared object?  In Danny Goodman's _Dynamic HTML -
The Definitive Reference_, he states that you need another OBJECT tag that
specifies the same CLASSID or DATA to instantiate the OBJECT.  The spec
mentions an HREF to #id, where "id" is the OBJECTs id.  (Danny Goodman's
answer makes more sense, but it seems to have come from outer space.)

Once a declared OBJECT is referenced, what does it do?  Should the object
replace the page (as suggested by the original OBJECT working draft, but NOT
mentioned in the final HTML 4.0 spec)?  Should it be inserted visually in
the document?  At the point of declaration or at the point of reference?  Or
should the OBJECT be instantiated behind the scenes, and remain invisible
until some bit of script puts it on the page?

(4) Should an OBJECT have scroll bars?  If you have an object with a natural
size, like a GIF image, and you display it in an OBJECT that is smaller,
should you expect scroll bars?  Or should it be squashed to fit?  Or should
the OBJECT resize itself to the natural size of the image?

If the OBJECT needed to render an object without a natural size (like
text/html) which was too large to fit in the width/height provided, would
you expect scroll bars then?  (Since stretching/squashing rendered HTML
would be an odd solution.)

(5) If an OBJECT has no "type" attribute (legal) and specifies a URL to
something that doesn't provide type information (FTP, local file, etc.), how
should it be handled?  Scientific wild-ass guess?

Why would you want to embed OBJECTs but not provide a type attribute?  So
you could replace them on the fly on the server?

(6) If you put an OBJECT into a form, where does the value to be submitted
for it come from?

(7) Would you expect all those IMG enhancements, like LOWSRC or ICCPROFILE
or transparency to work on OBJECTs other than images?

(8) If an OBJECT has a renderable type, but the download of the data or code
fails (or turns out to be bogus data/code), would you expect it to revert to
rendering its contents at that late stage?  Or should the decision between
rendering self/contents be made once early in the game and not revisited?
(Might seem weird to the user, if page has apparently finished loading
except for one image, then image disappears and is replaced with chunk of
text, etc.)

BTW - I do work for Microsoft, but you shouldn't take this question as an
indication that support for anything mentioned will be in any particular
Microsoft product in the near future.

Thanks,

Brian R. Smith
bsmith@microsoft.com
Work: (408) 474-3877
Cell: (408) 569-0991

Received on Friday, 7 May 1999 19:50:54 UTC