- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Thu, 01 Jun 2000 13:46:07 -0400
- To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
- Cc: Web Content Accessiblity Guidelines Mailing List <w3c-wai-gl@w3.org>, Authoring Tools Guidelines List <w3c-wai-au@w3.org>, Evaluation & Repair Interest Group <w3c-wai-er-ig@w3.org>
- Message-Id: <4.3.1.2.20000427161351.00cc5940@pop3.concentric.net>
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/> ------------------------------------------------
Attachments
- text/html attachment: iframe_test1.html
- text/html attachment: foo1.html
- text/html attachment: object_test1.html
Received on Thursday, 1 June 2000 13:56:48 UTC