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

(I'm replying to all the copyee's, but on which list shall we continue this).

I realize the following remark is a bit academic in the present context, 
and I apologize for that, but...

shouldn't IFRAME be deprecated in favor of a style sheet equivalent?

Len

At 01:46 PM 6/1/00 -0400, Gregory J. Rosmaita wrote:
>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/>
>------------------------------------------------

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University 423 Ritter Annex, Philadelphia, PA 19122

kasday@acm.org
http://astro.temple.edu/~kasday

(215) 204-2247 (voice)  (800) 750-7428 (TTY)

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/

Received on Thursday, 1 June 2000 15:24:08 UTC