Re: OBJECT implementation (longish)

On Fri, 7 May 1999, Brian R. Smith wrote:

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

You have to parse the content of OBJECT in order to find the OBJECT's end
tag. This is true also if PARAM and MAP did not exist.

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

No. Why should they?

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

Yes. The specs do not distinguish SCRIPT elements from other elements as
far as content of OBJECT is concerned. 

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

Its up to the browser how to handle unknown type. Guessing, asking the
user or refusing to render are all acceptable.

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

Yes. You may have content negotiation for any resource.  


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

I wouldn't expect them to work at all, since they are not standard.

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

Yes. I thing that the specs say that the content should be rendered if
the object can't be rendered for any reason.

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

It makes much more sense to replace the object with its content as the
author intended rather than puting a square in the middle of the page
with a "404 file not found" message, and I have seen a browser doing the
latter. 

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

Regards,
Nir Dagan.

mailto:nir@nirdagan.com
http://www.nirdagan.com

Received on Saturday, 8 May 1999 09:36:48 UTC