IFRAME, OBJECT, & LONGDESC (embedding HTML in HTML)

aloha, y'all!

i began the following in April as part of my action item to review the User 
Agent Accessibility Techniques for the exposition of framed 
content...   please note that i have cross-posted this emessage to the UA, 
AU, ER, and WCAG mailing lists, as techniques for authoring and exposing 
the content of the IFRAME element, and the provision of equivalent 
alternatives for inline frames hasn't (at least, according to my search of 
the WAI archives) been addressed explicitly in any of the WAI guidelines or 
techniques documents, and yet, use of the IFRAME element (with the is quite 
a common means of dumping advertisements into HTML documents on web portals 
and other commercial sites...

IFRAME is an element in the HTML 4.01 and XHTML 1.0 Frameset DTDs which 
allows one HTML document to be embedded in a scrollable sub-window within 
the referring document...  IFRAME is a strange case, however, as it is 
similar to FRAME, but unlike FRAME, it could -- by virtue of being a 
container -- potentially provide a built-in mechanism for the generation of 
an equivalent alternative that could be displayed inline, and from the 
example given in the HTML 4.01 Rec, that is exactly the function use of 
IFRAME as a container is meant to provide -- although i wish the example 
had been a bit less like the abusive NOFRAMES that populate the web...

clarification question: since the HTML 4.01 and XHTML 1.0 Frameset DTDs 
incorporates the entire Transitional DTD, is IFRAME also part of the 
Transitional/Lose HTML 4.01 DTD, as well?  the attached test pages (adapted 
and reconstructed as HTML 4.01 by hand from test pages created using a 
freeware HTML authoring tool i upon which i was performing a conformance 
evaluation for the Authoring Tool working group named Arachnophilia) both 
validated as HTML 4.01 Transitional using the 30 April 2000 build of Dave 
Raggett's HTML Tidy <http://www.w3.org/People/Raggett/tidy/> and the W3C 
Validator <http://validator.w3.org/>

IFRAME in HTML 4.01 is defined at:
(long URI warning!)
<http://www.w3.org/TR/html401/present/frames.html#h-16.5>
for the technically inclined, and those who don't like reading specs 
online, the HTML 4.01 definition of the IFRAME element: follows my signature...

my question to the working group is this: is Section 3.7 (Frames 
Techniques) also where we should be addressing exposition of the IFRAME 
element in HTML, or should that discussion be included in the section on 
equivalent alternatives, or both?

FIRST ELEVENTH HOUR SIDE ISSUE: i think we need to explicitly state that 
users need to be offered the option of having the content of an IFRAME 
rendered inline (as an organic part of the document in which the reference 
occurs) and having it displayed as a scrollable slash scaleable sub-window 
-- as the HTML 4.01 rec states:

quote
Inline frames may not be resized (and thus, they do not take the noresize 
attribute).
unquote

Why can't they be resized?  or spawned into a new viewport, if that is what 
the user wants slash needs?  and is the HTML 4.01 rec implicitly implying 
that OBJECT is better than IFRAME for embedding one HTML document into the 
body of another?  should WCAG be explicitly stating that, or can UAs treat 
IFRAMES intelligently? -- which means including the means to resize them if 
necessary?  is this a compelling reason to ask that XHTML 2.0 retain an 
OBJECT-like container, that meets the needs so eloquently spelled out in 
UAAG?  (yes, i know IFRAME is as unsupported in XHTML 1.1 as is OBJECT, but 
that's another issue for another day--and, as ian and al would probably be 
quick to remind me, another list...)

fortunately, however, since, like OBJECT, IFRAME is a container, authoring 
tools could automatically reproduce the content of the BODY of the document 
referenced by the "src" attribute in the IFRAME between the <IFRAME> and 
</IFRAME> tags whenever an IFRAME is created...

as for implementation examples, Lynx exposes an IFRAME thus:

         IFRAME: [link number] _Vaule of NAME Defined for IFRAME or URI 
defined in SRC_
         Any alternative/explanatory text added by the author. This
            can be "rich" (marked-up) text, as IFRAME is a container.
            Optimally, it would contain the exact same content as that
            contained in the BODY of the document referenced by
            IFRAME's "src" attribute.

note that, in the above "illustration", underscores were utilized to 
symbolize the presence of a hyperlink...

Lynx displays the "name" defined for the IFRAME; in the absence of the 
"name" attribute, Lynx displays the URI of the IFRAME as the hyperlink 
text....  Lynx (at least 2.8.3dev.17 for Win32) doesn't recognize the 
"title" element for IFRAME, so when a page author uses the "title", and not 
the "name" attribute, Lynx displays the URI of the document referenced by 
the IFRAME's "src" attribute...  this is a legacy bug in Lynx, as the 
definition of the "title" attribute in HTML 4.01 spec:
(long URI warning)
<http://www.w3.org/TR/html401/struct/global.html#adef-title>
clearly states that the "title" attribute is the proper way to provide a 
"human readable" description of any element for which it is defined as an 
attribute...  any content contained in the IFRAME container is rendered 
inline...  (note, too that i changed the "name" attribute originally 
bestowed upon my IFRAME example by Arachnophilia to "title" in the attached)

Opera, with support for FRAMES disabled, renders the content contained 
within the IFRAME container inline -- that is, in the body of the referring 
document...  NetScape Navigator 4.08 renders the content contained between 
the <IFRAME> and </IFRAME> tags, even though Navigator 4.08 renders the 
FRAMES contained in a FRAMESET   since i have been unable to install 
Navigator 6, i don't know how that build handles the IFRAME element...

JFW (as noted in my post archived at:
(long URI warning)
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0123.html>
doesn't recognize the presence of inline frames, and IE 5.01 doesn't 
provide a mechanism (such as CONTROL+TAB, which is used to move from FRAME 
to FRAME in a FRAMESET) for giving an inline frame focus, so that JFW could 
treat it as read-only edit box, such as the type commonly used to display 
license agreements...

SECOND ELEVENTH HOUR SIDE ISSUE: the HTML 4.01 recommendation allows for 
the transformation of rich content contained within the OBJECT  container 
into an IFRAME-like interface, which -- while it may benefit some -- will 
definitely harm others...  users should, therefore, be able to configure 
the user agent so that exposition of rich content contained within OBJECT 
tags can not only be rendered in an IFRAME manner, but can also be rendered 
inline -- that is, as part of the referring document, or in a separate 
viewport, if that is what is necessary for the user or his or her adaptive 
technology to access the content contained in the embedded HTML document, 
as well as in a scrollable sub-window (as is currently the default setting 
for GUI UAs that support IFRAME...

in Section 13.5 of HTML 4.01, it states,

quote
13.5 Notes on embedded documents

    Sometimes, rather than linking to a document, an author may want to
    embed it directly into a primary HTML document. Authors may use either
    the IFRAME element or the OBJECT element for this purpose, but the
    elements differ in some ways. Not only do the two elements have
    different content models, the IFRAME element may be a target frame
    (see the section on specifying target frame information for details)
    and may be "selected" by a user agent as the focus for printing,
    viewing HTML source, etc. User agents may render selected frames
    elements in ways that distinguish them from unselected frames (e.g.,
    by drawing a border around the selected frame).

    An embedded document is entirely independent of the document in which
    it is embedded. For instance, relative URIs within the embedded
    document resolve according to the base URI of the embedded document,
    not that of the main document. An embedded document is only rendered
    within another document (e.g., in a subwindow); it remains otherwise
    independent.

    For instance, the following line embeds the contents of embed_me.html
    at the location where the OBJECT definition occurs.

...text before...
<OBJECT data="embed_me.html">
Warning: embed_me.html could not be embedded.
</OBJECT>
...text after...

    Recall that the contents of OBJECT must only be rendered if the file
    specified by the data attribute cannot be loaded.

    The behavior of a user agent in cases where a file includes itself is
    not defined.
unquote

what page authors need, therefore, should they trod the OBJECT path to 
embedding one HTML document directly into another is the same sort of 
automagic that should cause their authoring tools to replicate the content 
of the referenced data object in the OBJECT container, both so that it can 
be rendered inline, as part of the referring document, as well as a 
fail-safe for when the document to which the OBJECT points cannot be loaded....

second clarification question: would a UA setting that causes embedded 
documents to be rendered inline, and not as a scrollable sub-window, 
automatically cause the contents of the OBJECT container to be 
rendered?  it seems to me that it should, if the UA is actually HTML4 
compliant, for, as the above quote illustrates, if the UA is set so that it 
does not issue a get for the referenced document, it has to render the 
content of the OBJECT container inline in the referring document...

as for implementations that support use of the OBJECT tag to embed one 
document inside another, using the attached file object_test1.html:

MSIE 5.01: rendered only the level one header defined for the page and the 
W3C validation button, but did not render either the OBJECT as a scrollable 
sub-window, nor inline, as part of the referring document

Opera 3.61: rendered the level one header and the text contained between 
the OBJECT tags inline (as part of the referring document), as well as the 
W3C validation button

Opera 4 public beta: rendered the level one header and the W3C validation 
button, but did not render either the OBJECT either as a scrollable 
sub-window, nor inline, as part of the referring document

Navigator 4.08: rendered the level one header and the text contained 
between the OBJECT tags inline (as part of the referring document), as well 
as the W3C validation button

Lynx 2.8.3(dev17): rendered the level one header as a level one header, and 
the content of the OBJECT tags inline

and, now, finally, the answer to the question you've all been asking -- 
"What Does All This Have to Do With LONGDESC?"

i couldn't find anything in the HTML 4.01 Recommendation that would prevent 
UAs from rendering the content of a LONGDESC in an IFRAME manner, 
especially if the LONGDESC is a large document...  while this is one 
rendering strategy that may well benefit one community of users, it would 
need to be balanced by a configuration option that allowed for the 
rendering of the content contained in the LONGDESC inline, in the referring 
document, as part of that document, or as an alternative equivalent to the 
object it describes, or a supplement thereunto, accessed via a link -- 
which is the traditionally way of postulating how LONGDESC might be 
implemented...  clearly, it is in the best interest of the greatest number 
to have as many options available as possible, and at the very least, the 
following 4:

1. render inline (as part of the referring document)
2. render as a link, using the TITLE of the referred document as the 
hyperlink text
3. render as a scrollable, re-sizable sub-window
4. render in a new viewport (users should be able to configure spawned 
viewports, such as an independent window containing a LONGDESC or the text 
of a captioned multi-media presentation, to either respect the defaults the 
user set for the UA, or allow the user to configure viewports spawned as 
alternative equivalents

oh, and did i mention that it would also need to be resizable?

gregory.

(excerpt from the HTML 4.01 Recommendation
<http://www.w3.org/TR/html401/present/frames.html#h-16.5>)

16.5 Inline frames: the IFRAME element
<!ELEMENT IFRAME - - (%flow;)*         -- inline subwindow -->
<!ATTLIST IFRAME
   %coreattrs;                          -- id, class, style, title --
   longdesc    %URI;          #IMPLIED  -- link to long description
                                           (complements title) --
   name        CDATA          #IMPLIED  -- name of frame for targetting --
   src         %URI;          #IMPLIED  -- source of frame content --
   frameborder (1|0)          1         -- request frame borders? --
   marginwidth %Pixels;       #IMPLIED  -- margin widths in pixels --
   marginheight %Pixels;      #IMPLIED  -- margin height in pixels --
   scrolling   (yes|no|auto)  auto      -- scrollbar or none --
   align       %IAlign;       #IMPLIED  -- vertical or horizontal alignment --
   height      %Length;       #IMPLIED  -- frame height --
   width       %Length;       #IMPLIED  -- frame width --
   >

    Attribute definitions

    longdesc = uri [CT]
           This attribute specifies a link to a long description of the
           frame. This description should supplement the short description
           provided using the title attribute, and is particularly useful
           for non-visual user agents.

    name = cdata [CI]
           This attribute assigns a name to the current frame. This name
           may be used as the target of subsequent links.

    width = length [CN]
           The width of the inline frame.

    height = length [CN]
           The height of the inline frame.

    Attributes defined elsewhere
      * id, class (document-wide identifiers)
      * title (element title)
      * style (inline style information)
      * name, src, frameborder, marginwidth, marginheight, scrolling
        (frame controls and decoration)
      * align (alignment)

    The IFRAME element allows authors to insert a frame within a block of
    text. Inserting an inline frame within a section of text is much like
    inserting an object via the OBJECT element: they both allow you to
    insert an HTML document in the middle of another, they may both be
    aligned with surrounding text, etc.

    The information to be inserted inline is designated by the src
    attribute of this element. The contents of the IFRAME element, on the
    other hand, should only be displayed by user agents that do not
    support frames or are configured not to display frames.

    For user agents that support frames, the following example will place
    an inline frame surrounded by a border in the middle of the text.
   <IFRAME src="foo.html" width="400" height="500"
              scrolling="auto" frameborder="1">
   [Your user agent does not support frames or is currently configured
   not to display frames. However, you may visit
   <A href="foo.html">the related document.</A>]
   </IFRAME>

    Inline frames may not be resized (and thus, they do not take the
    noresize attribute).

    Note. HTML documents may also be embedded in other HTML documents with
    the OBJECT element. See the section on embedded documents for details.

------------------------------------------------
The optimist thinks that this is the best of all
possible worlds; the pessimist knows it is.
------------------------------------------------
Gregory J. Rosmaita     <unagi69@concentric.net>
       Webmaster & Minister of Propaganda
The Visually Impaired Computer Users' Group of
the New York City Metropolitan Area (VICUG NYC)
      <http://www.hicom.net/~oedipus/vicug/>
------------------------------------------------