W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

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

From: gregory j. rosmaita <oedipus@hicom.net>
Date: Fri, 27 Apr 2001 16:54:43 -0400
Message-ID: <002c01c0cf5c$49779b10$7bb6f5d0@igor>
To: <w3c-wai-ua@w3.org>
Cc: <wendy@w3.org>
the following is a resend of a post originally submitted to w3c-wai-ua in
june 2000, which is archived at: (long URI warning)
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0396.html> --
based on the discussion at today's (now yesterday's) telecon, i think some
the issues
addressed herein are worth revisiting (and, i hope, the test pages are of
some utility in testing implementation)...  unfortunately, because
attachments are given a permenant URI when they are archived (which is an
extrapolation on their actual filenames) the test pages attached to the
original post do not function correctly when one attempts to access them via
the W3C mail archive...  however, the test pages attached to the original
document can still be accessed online using the following URIs:

1. IFRAME used to embed HTML in an HTML document:
<http://www.hicom.net/~oedipus/wai/ua/iframe_test1.html>

2. OBJECT used to embed HTML in an HTML document:
<http://www.hicom.net/~oedipus/wai/ua/object_test1.html>

granted, these are only rudimentary test pages, but they illustrate the
points made in the body of the post sufficiently...  as for implementation
reporting, while the post contains an implementation report based on the
results obtained by having the above-referenced test pages rendered by a
variety of UAs, i can update a sliver of that information with the
following:

UA: IE 5.5 (version 5.50.4522.1800; update versions: ;SP1;q261255;Q279328)
PLATFORM: Windows 2000 Professional (build 2195)
RESULTS: IE 5.5 does not appear to render the content of the OBJECT
container declared in the second test page, located at:
http://www.hicom.net/~oedipus/wai/ua/object_test1.html
at all, even though the test document validates against the W3C Validator,
which is to say that IE 5.5 does NOT render either the embedded HTML
document reference by the OBJECT element, nor the text contained within the
<OBJECT></OBJECT> tags

--- BEGIN ORIGINAL POST ---
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 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.
Received on Friday, 27 April 2001 16:53:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:50 GMT