Re: OBJECT implementation (longish)

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

I think this is true... So you cannot make this decision at parse time
*unless* the "type" attribute is specified. The only "weird" case here I
can think of is: what if the hint MIME type ("type" attribute) is
supported by the browser, but the actual MIME type (sent by the server)
is not supported by the browser. The browser should know at parse time
from the hint when it *definitely does* have to display the OBJECT's
content, but it can only know when it *definitely does not* have to
display the content after downloading the first several bytes of data
from the "data" href.

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

I associate running these immediate scripts with loading of the
document, just like I associate loading of dependent resources with
loading the document. The spec suggests that dependent resources in
OBJECT's content should not be downloaded (or at least, the browser can
opt not to download them) unless OBJECT's content is displayed. So by
the same token, I'd suggest that script code triggered by "onload"
should also not be run until display time.

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

I agree; however, treating different branches of the parse tree
differently based on their display state strikes me as unsteady ground
for some reason I can't quite put my finger on. But I do think this
interpretation is the most inline with what the spec does say.

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

I think they should be treated the same is blocks with CSS "display:
none", so I think this means, "yes, they should be in the DOM parse
tree."

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

I think the question is, "Are OBJECT instantiations representative of
unique instances, or pointers to a singular instance?" I'd suggest that
the latter option is preferable. The former is possible without doing
the declaration, so treating the instantiations as unique would gain no
functionality.

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

The examples in the spec indicate that an OBJECT declaration is
basically a HTML wrapper around a data type, such that that data can be
literally referenced only once in the HTML document. Under this
interpretation, I think this example is consistent with the HTML spec:

    <object declare id="airplane" data="airplane.wrl"
type="model/vrml"></object>
    <div>
    <object data="#airplane"></object>
    </div>

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

That behavior would be consistent with the notion that such an OBJECT
link should be treated the same as a normal link to the data.

> (4) Should an OBJECT have scroll bars?

If and only if they are necessary.

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

Both the HTML 4 descriptions of the "height" and "width" attributes and
the CSS descriptions of the "width" and "height" properties say that
these measurements should be used to rescale images. So I think this
case is pretty well-specified.

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

Yes.

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

The HTTP case is clear; for the local file case, I'd say that
determining the MIME type is up to whatever mechanism the local OS has
in place (which could be a "scientific wild-ass guess"). What to do with
FTP seems a good question. I don't have any better idea than the
wild-ass guess.

> Why would you want to embed OBJECTs but not provide a type attribute?

Laziness?

>  So
> you could replace them on the fly on the server?

Oh, that's a better answer. Consider an OBJECT who's "data" attribute
points to a CGI script or a servlet. It is a reasonable expectation that
the server-side program should be able to send a different content type
without having to change the host document.

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

I'm not a forms guy, so I'll pass on this one.

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

Talking about PARAM data here, right? It would be a nice plus. But this
would understandably be implementation dependent.

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

This is the case I partially addressed before. It's a toughie--my
initial response is to say that it should revert. However, the partially
downloaded image is an interesting case. For most any structured data
type (an applet, a 3D model, etc.), it's an all-or-nothing game. So if
the download fails, I think that displaying the alternate content is
decidedly better than displaying nothing at all. However, it's not so
clear cut for data like streamable formats. If one decision has to be
made across the board for all content types, I'd say that the content
should replace the failed download. If it's possible to modulate this
based on the content type, then I'd make an exception for images,
streamable formats, and the like.

-- 
Braden N. McDaniel
braden@endoframe.com
<URI:http://www.endoframe.com>

Received on Friday, 7 May 1999 23:14:21 UTC