- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Mon, 30 Apr 2001 11:37:42 -0500
- To: "gregory j. rosmaita" <oedipus@hicom.net>, WAU-ua <w3c-wai-ua@w3.org>
IE requires <height> and <width> attributes for object to be rendered.
Although not specifically required in the HTML spec. HTMLhelp.com
http://www.htmlhelp.com/reference/html40/special/object.html recommends
The WIDTH and HEIGHT attributes define the dimensions of the object. The
value may be given in pixels or as a percentage of the parent element's
width or height. Most browsers require the WIDTH and HEIGHT attributes for
all objects embedded using OBJECT.
that being said...I think IE failed because it did not render the
alternative content within the <object> element.
from HTML Spec
http://www.w3.org/TR/REC-html40/struct/objects.html#edef-OBJECT
13.3.1 Rules for rendering objects
A user agent must interpret an OBJECT element according to the following
precedence rules:
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).
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.
Interestingly, <IFRAME> suffers no ill effects in IE if height and width are
not specified.
Opera 5.03 renders both examples without problem
Netscape 4.75 renders neither (as content within a scrolling box), but
renders alternative content appropriately. Tried with and without height and
width--no difference--only render alternative content.
HPR 3. rendered the IFRAME, user could read contents using frame reading
controls, did not render <object> on screen but provided access to
alternative content.
Jim Allan, Webmaster & Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"I see the Earth. It is so beautiful."--
first words spoken by human in space.
[Yuri Alekseevich Gagarin, from the Vostok 1, April 12, 1961.]
-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of gregory j. rosmaita
Sent: Friday, April 27, 2001 3:55 PM
To: w3c-wai-ua@w3.org
Cc: wendy@w3.org
Subject: IFRAME, OBJECT, & LONGDESC (embedding HTML in HTML)
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 Monday, 30 April 2001 12:39:15 UTC