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


From: Ian Jacobs <ij@w3.org>
Date: Fri, 27 Apr 2001 17:56:44 -0400
Message-ID: <3AE9EB1C.A66DCA97@w3.org>
To: "gregory j. rosmaita" <oedipus@hicom.net>
CC: w3c-wai-ua@w3.org
"gregory j. rosmaita" wrote:
> 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)...  

Hi Gregory, 

My comments below are preceded by IJ:. I think that all of the issues
you refer to have been addressed by checkpoints 2.1, 2.3, and 2.9. We
to ensure that the HTML elements you mention are listed in the


> 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?

IJ: It should probably be mentioned in Frame techniques.
> 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

IJ: We don't need to say anything in the Guidelines, but we should
IFRAME in the Techniques. The HTML 4.01 spec says:

   "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,

Checkpoint 2.1 says "Render according to spec" so we are covered for the
rendering". For the rendering of conditional content (the content of the
element), the HTML 4.01 spec says:

   "The contents of the IFRAME element, on the other hand, should only 
    be displayed by user agents that do not support frames or are
    not to display frames."

Checkpoints 2.3 and 2.9 cover this case, and the Techniques of 2.3
should list
IFRAME as an example of an element that provides conditional content.
2.3 includes the option of rendering in a separate viewport.

> -- 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? 

IJ: This is probably a bug of HTML 4.01. UAAG 1.0 doesn't include any
requirements for viewports, but I think that checkpoint 7.3 (use
system conventions) will cover us on this and other interface-specific
points. For instance, the Microsoft design guidelines for Windows [1]

    "Because display resolution and orientation vary, your software
     not assume a fixed display size, but rather adapt to the shape and
     defined by the system.

[1] http://msdn.microsoft.com/library/partbook/winguide/ch07d.htm




> ... 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...

IJ: That is one of the options provided by checkpoint 2.3.

> 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...

IJ: I'm not sure that I understand this comment. How do you set the UA
so that it
doesn't issue a GET for the referenced document?

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


IJ: The longdesc attribute is one that is likely to be addressed by the 
"provide a link to it" option of checkpoint 2.3.

> 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

IJ: This is covered by checkpoint 2.3. However, checkpoint 2.3 doesn't
the behavior of the "link to it" option. Following the link might
display the
content in a new viewport or in the same viewport. Your options 1 and 3
look the
same to me, except that the scrollbar would be added in the case where
the inline
content dimensions were larger than its (sub-)viewport dimensions.
Checkpoint 2.3
includes a query option which is not one of your choices.

 - Ian

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783
Received on Friday, 27 April 2001 17:56:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:30 UTC