Re: OBJECT implementation (longish)

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

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

The contents of the OBJECT, IMHO, should be treated the same way as the
contents of a DIV. If the OBJECT is not rendered, then it is equivalent to
the contents having a CSS declaration of "display:none".

How are scripts dealt with in those cases?


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

Yes, IMHO, they should be in the DOM. Access should be equivalent to
access to IMG elements that have not downloaded (e.g., because images are
disabled at that point).


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

   <OBJECT declared id="declared" ...>
   </OBJECT>
   <!-- ... -->
   <OBJECT data="#declared">
      (could not be rendered)
   </OBJECT>

...would render the object with id=declared at the place where it is
referenced. If this occurs twice:

   <OBJECT data="#declared">
      (could not be rendered)
   </OBJECT>
   <OBJECT data="#declared">
      (could not be rendered)
   </OBJECT>

...then changing the id=declared object using the DOM would change the
rendering of both references, while changing the data attribute of either
of the referencing elements would change that element. (Is that clear?)


> How do you reference a declared object? 

IMHO, using data="#id" if you wish the element's data to be embedded.
The spec also references an OBJECT using the A element, which I
presume would execute that object as if it was linked directly. Take,
for example, the following:

   <P>
      <OBJECT declare id="earth" data="TheEarth.mpeg">
         <IMG src="earth.jpeg" longdesc="TheEarth.html"
              alt="Seen from space, the earth is a blue and green
              sphere."> 
      </OBJECT>
 
      What does the earth look like <a href="#earth">from space?</a>

   </P>

If you clicked on the link and your browser supported MPEGs (either
inline or using a helper app) and downloaded it fine, then the video
would replace the current document, as if the link had said:

      <a href="TheEarth.mpeg">from space?</a>

But, if MPEGs are not supported, then the image would be shown
instead, as if the link had said:

      <a href="TheEarth.jpeg">from space?</a>

If the image could not be downloaded, or if it was not supported, or
if images were disabled, then this would not work, so instead the
longdesc alternative would be shown, as if the link had read:

      <a href="TheEarth.html">from space?</a>

Finally, if that document couldn't be fetched, then the alt text would
be shown instead, resulting in a document containing only a single
sentence.


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

I would say yes, if the OBJECT is instanced through an A element.


> Should it be inserted visually in the document?

IMHO, that would be the case if the OBJECT was instanced through
another OBJECT element.


> At the point of declaration or at the point of reference?

Reference. (The declaration could be in the head, so at point of
declaration might make no sense, the only way of being consistent is to do
it at 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?

Definitely not. Scripting should be entirely optional.


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

No, CSS says that the image (which would be a replaced element) would
be stretched/squeezed/squashed.


> 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. IMHO if the object has no inherent dimensions then it should act
like an IFRAME.

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

Aka heuristics? I would guess so...

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

From the spec, section 17.2:
# [...] the initial value of an OBJECT element in a form is determined
# by the object implementation (i.e., it lies outside the scope of
# this specification)

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

No. Of course, the "standby" attribute should work.

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


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

Weird maybe, but it is much better than not being able to see the
content at all!

Again, from the spec:
# A user agent must interpret an OBJECT element according to the
# following precedence rules:
#
#  1. The user agent must first try to render the object. It should not
#     render the element's contents, but it must examine them in case
#     the element contains any direct children that are PARAM elements
#     (see object initialization) or MAP elements (see client-side
#     image maps).
#  2. If the user agent is not able to render the object for whatever
#     reason (configured not to, lack of resources, wrong
#     architecture, etc.), it must try to render its contents.

HTH.
-- 
Ian Hickson 
U+2642 U+2651
U+262E U+2603 U+263A

Received on Wednesday, 19 May 1999 09:44:21 UTC