See also: IRC log
<oedipus> trackbot, start telcon
<trackbot> Date: 06 March 2009
<oedipus> scribe: Gregory_Rosmaita
<oedipus> ScribeNick: oedipus
JS: would like to address RichS' DETAILS proposal
SF: 3 approaches in adddition to
mine; mine i believe is the least controversial;
... Leif's proposal: move summary from TABLE element to CAPTION element - details on wiki
... Rich's suggestion -- dropping @summary and adding the DETAILS element instead
... hoping Gez would make it -- non-plussed by suggestion
... been working hard on why should keep summary, when comes down to it, can see Rich's point myself
... want to concentrate on @summary and leave DETAILS proposal to someone is committed to it
JS: have to discuss for a few
weeks, but might be useful to throw out on wiki
... as HTML5 draft stands, is insufficient
... like Rich's idea because less is more is a good rule in general; re-use of elements good, but have to ensure that meets requirements of @summary
SF: will be posting to the wiki
the way that DETAILS might work based on what is in the spec;
would like to show them proposed solution rather than
... taken on board HTML WG's suggestions for alternatives; describedby with css selector to hide is not appropriate enough; can envision DETAILS element being useful; not implemented anywhere, which causes a problem as far as testing
... taken from desktop environment - DETAILS obtainable through user action - shows after content there; for a TABLE, would need to have DETAILS in top of TABLE
... unless floats over content that is there, going to mess up visual display of TABLE
JS: currently only for FORMs?
SF: "interactive elements" can't
be used for footnotes is only current restriction; seems like a
good generic means of hiding/revealing content
... @summary in JAWS and W-E supports @summary by default -- auto announced by default
... with DETAILS, may be able to say "is announced by default" for non-visual renderers, then advise that app should have toggle (read summary when reach table, don't read summary)
JS: something the AT can control
GJR: was going to ask if DETAILS could be restricted in TABLE to top like THEAD and TFOOT
SF: if have frames or IFRAME on
page -- what would be reasonable restriction on that to let you
... would "empty" be enough or "no visible content" needed
JS: empty frame?
GJR: currently JAWS at least has an "ignore IFRAME"
<inserted> ScribeNick: Joshue
GJR: This has been difficult for AT to implement.
but that is a user generated choice and the user has to be aware of the iFrame model in the first place. We can't expect users to understand this kind of thing as many users are just not developers.
JOC: They are used as holders for banner ads also.
SF: Describes how some of his
clients uses iFRAMES.
... Use of display:none or display:hidden is good for removing them from the doc flow.
<oedipus> IFRAME accessibility query: http://lists.w3.org/Archives/Public/wai-xtech/2008Jun/0061.html
JS: I don't notice them in FF.
SF: Yeah. AM just wondering if there is a phrase that will help u identify them.
JS: What about just skipping over it?
SF: JAWS will indicate that there is a frame.
GJR: There isn't a hot key to
bounce in or out of the iFrame.
... The link there will give you an overview..
... iFrame and a script may best be treated as a Live Region.
... So it would be communicated to the user (content changes).
SF: These frames are sometimes
invisible as they have no content.
... GMail for example has about 6 iFrames that are used behind the scenes.
<Zakim> oedipus, you wanted to ask if such use of IFRAME is illegal according to spec
GJR: Is that illegal ?
SF: Not that I know.
... Do you think it is?
<oedipus> "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."
SF: I would like to mention <canvas> again. We need to discuss it.
<oedipus> "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. "
Cyns: Would it make sense to support role="presentation" for iFrames.
<oedipus> GJR: but isn't that a kludge -- isn't a script an "application"
Cyns: Presentation may not be right but I don't want to add another attribute.
<oedipus> "Inline frames may not be resized (and thus, they do not take the noresize attribute).
<oedipus> Note. HTML documents may also be embedded in other HTML documents with the OBJECT element. See the section on embedded documents for details.
GJR: Does the use of the script success this is an application.
<oedipus> GJR: note IFRAME has longdesc as an attribute
GJR: Iframe has longdesc as an
... The use of script in iFrames is an abuse IMO and they should use <object>
Cyns: Support is pretty poor.
<oedipus> "Inline frames may not be resized (and thus, they do not take the noresize attribute)."
<oedipus> GJR: invisible IFRAMEs seems like a kludge
<oedipus> JOC: wondering if there is an attribute that would render IFRAME invisible if serving no purpose
<oedipus> JOC: reuse what is there
<oedipus> "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."
JOC: But that needs support for ARIA, is there a current method that would work and is backward compat?
<oedipus> GJR: treat IFRAME which displays content as a live region
<oedipus> JOC: take out of document flow altogether?
<oedipus> SF: yes
<oedipus> JOC: often used as containers for Flash animations and that sort of thing
<oedipus> GJR: pretty clear that IRFAME is meant to contain hypertext; that it is a means of embedding a remote document into the current document which is why IFRAME to display longdesc or its equivalent is an option, although not optimal since "noresize" restriction
<inserted> ScribeNick: oedipus
<Joshue> JOC: How did we get to this avenue of discussion btw?
SF: script in src defined for IFRAME; whether it is legal or not, it is being done, and done a lot, so we need to insure that AT users don't have to interact with it because nothing in there; if do discern it, what should be done -- tell AT nothing here for you
GJR: bows to reality
<Joshue> GJR: Reality bows back
GJR: shouldn't authors use the EMBED element for this?
"The iframe element represents a nested browsing context." (HTML5 PWD)
"The src attribute gives the address of a page that the nested browsing context is to contain. The attribute, if present, must be a valid URL. When the browsing context is created, if the attribute is present, the user agent must resolve the value of that attribute, relative to the element, and if that is successful, must then navigate the element's browsing context to the resulting absolute URL, with replacement enabled, and with the iframe element's document's
"Whenever the src attribute is set, the user agent must resolve the value of that attribute, relative to the element, and if that is successful, the nested browsing context must be navigated to the resulting absolute URL, with the iframe element's document's browsing context as the source browsing context."
"If the src attribute is not set when the element is created, or if its value cannot be resolved, the browsing context will remain at the initial about:blank page."
"When content loads in an iframe, after any load events are fired within the content itself, the user agent must fire a load event at the iframe element. When content fails to load (e.g. due to a network error), then the user agent must fire an error event at the element instead."
GJR: HTML5 does allow script in IFRAME legally, but EMBED is superior mechanism
"If, during the handling of the load event, the browsing context in the iframe is again navigated, that will further delay the load event."
<Joshue> JOC: Repeating Frame in title is useless btw
"The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe. Its value must be an unordered set of unique space-separated tokens. The allowed values are allow-same-origin, allow-forms, and allow-scripts."
<Joshue> The use of the title element in Frame is supposed to identify the purpose of the Frame.
"While the sandbox attribute is specified, the iframe element's nested browsing context, and all the browsing contexts nested within it (either directly or indirectly through other nested browsing contexts) must have the following flags set:"
"The sandboxed navigation browsing context flag"
"The sandboxed plugins browsing context flag"
"The sandboxed origin browsing context flag, unless the sandbox attribute's value, when split on spaces, is found to have the allow-same-origin keyword set"
"This flag [sandboxed origin browsing context flag] also prevents script from reading the document.cookies DOM attribute."
"The sandboxed forms browsing context flag, unless the sandbox attribute's value, when split on spaces, is found to have the allow-forms keyword set"
The sandboxed scripts browsing context flag, unless the sandbox attribute's value, when split on spaces, is found to have the allow-scripts keyword set
JOC: if have to invoke @summary or DETAILS will that break AT support?
JS: if content is there in page that one retrieve, AT will display unless user suppresses support for IFRAME
SF: having hidden and display on demand might be the best solution for all visual users; AT users may want info by default and setting to skip summary
<Stevef> chatter on WHAT WG IRC about WAI alt discussions http://krijnhoetmer.nl/irc-logs/whatwg/20090305#l-251
JOC: objection has been that only AT has access to contents of summary
CS: if UA wants to display it it can
JOC: logic being twisted - counter argument is that @summary is useful for blind users but discriminates against everyone else
JS: specious argument
CS: agree, but nothing stopping UA implementation
<Joshue> Thanks for that Janina, my new word in the defense of reason will be 'specious'.
SF: HTML4x says explicitly "this is for non-visual user agents" -- in definition on wiki point out that user agents may provide access as contingent content in a device independent manner
JS: orginally developed to support for a specific user group - gives indication of who needs and actually uses it -- where and how particularly used
CS: user agents MAY display this information -- insertion would undercut objections
JS: good strategy
addition: "User Agents MAY display the contents of @summary."
RESOLUTION: add "User Agents MAY display the contents of @summary" to end of definition of @summary
<Stevef> "Any user agent may provide a mechanism to access the summary attribute content. If the mechanism provides the summary content as conditional content it must be input device independent."
JS: could provide generic and global way to provide contextual info
JOC: if DETAILS can do what we want, great, but should reinstate @summary as a "deprecated element" while introductoin of DETAILS like element is implemented
JS: consistent with guidance provided by al's email of 6 august 2008
<Stevef> sidenote: if @summary is added back in to html5, it would be the only none universal attribute
alG's august 2008 email: http://lists.w3.org/Archives/Public/public-html/2008Aug/0213.html
SF: common attributes addressed, but no definitive list of what attributes are common/universal
HTML5 definition of IFRAME it states:
"Contexts in which this element may be used: Where embedded content is expected."
GJR: suggests to me that hiddens IFRAMEs with scripts are illegal
HTML5 global attributes: http://www.w3.org/TR/html5/dom.html#global-attributes
SF: list of global attributes, but no list of specific attributes
<cyns> script is part of the WCAG definition of "content"
GJR: hixie using ← in
navigation - that is use of ASCII art and a violation of WCAG
-- would need to at least encase the character entity in an
<abbr title="Previous">←</abbr> or
... or just use the actual words: "Previous" and "Next"
meeting+ PF HTML5 Issues Caucus
<scribe> meeting: PF HTML5 Issues Caucus
<scribe> Meeting: PF HTML5 Issues Caucus
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/generates/generated/ Succeeded: i/GJR: This/ScribeNick: Joshue Succeeded: i/JOC: How did we get to this avenue/ScribeNick: oedipus Succeeded: s/@summary."/@summary" to end of definition of @summary/ Found Scribe: Gregory_Rosmaita WARNING: No scribe lines found matching ScribeNick pattern: <Gregory_Rosmaita> ... Found ScribeNick: oedipus Found ScribeNick: Joshue Found ScribeNick: oedipus ScribeNicks: oedipus, Joshue Present: Janina_Sajka Steve_Faulkner Cynthia_Shelly Gregory_Rosmaita Joshue_O_Connor Regrets: Gez_Lemon Laura_Carlson Agenda: http://lists.w3.org/Archives/Member/w3c-wai-pf/2009JanMar/0542.html Found Date: 06 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/06-pf-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]