- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 19 Oct 2000 13:23:36 -0400
- To: "Gregory J. Rosmaita" <unagi69@concentric.net>
- CC: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
"Gregory J. Rosmaita" wrote:
>
> OBJECTION:
> The priority level of Checkpoint 5.7 (support for the DOM2 Style Module for
> UAs that support CSS) should be raised from Priority 3 to at least Priority
> 2, if not to Priority 1.
>
> RATIONALE:
>
> 1. Inline style information attached to elements is exposed through the
> style attribute of the DOM2 Style Module.
Gregory,
Good catch. Here are some comments:
1) For XML applications, style and all other information will be
available through the Core module. This means that assistive
technologies
can calculate anything they want given the same document object as
the
communicating user agent.
2) For HTML, the "style" attribute is *not* available through the
HTML module. From section 1.5.4 of the DOM Proposed Recommendation
[1]:
"Note: The style attribute of an HTML element is accessible through
the ElementCSSInlineStyle interface which is defined in the CSS
module
[DOM Level 2 Style Sheets and CSS]."
This means that unless the CSS module (or part of it) is implemented,
ATs will not have access to inline style information (i.e., some part
of
content).
[1]
http://www.w3.org/TR/2000/PR-DOM-Level-2-HTML-20000927/html.html#ID-011100101
3) The Style Sheets module consists of two parts: an abstract style
sheets part (which gives access to style defined via the
"style" attribute) and a CSS-specific part.
So:
========
PROPOSED: Split checkpoint 5.7 into two parts.
========
a) For user agents that support style sheets, provide programmatic
access to style sheet information by conforming to the W3C
Document Object Model (DOM) Level 2 Specification, Chapter 1
"Document Object Module Style Sheets" and exporting the
interfaces it defines. [Priority 1]
b) For user agents that implement Cascading Style Sheets ([CSS1],
[CSS2]), provide programmatic access to CSS style sheets by
conforming to the W3C Document Object Model (DOM) Level 2
CSS module, Chapter two "Document Object Module CSS"
and exporting the interfaces it defines. [Priority 3]
Note that the priority of the first checkpoint is P1, otherwise
ATs will not have access to embedded or linked styles.
As to establishing the priority of the second checkpoint,
I would argue that any piece of software that implements the
APIs provided by that module must be almost, if not entirely,
a CSS user agent. The DOM CSS module provides convenience
interfaces to structures and values of a CSS style sheet,
quick access to the style attribute, the ability to insert
and delete rules in a style sheet, and (probably most
attractively) access to computed values. I would argue that
any AT that implements the API, in order to make use of
the computed value, must know enough about CSS (and implement
enough of it) that it could probably compute the value
itself (given access to the DOM and the style sheets). So
the question is, I think: is having access to the computed
value a P1 requirement, or more of a convenience? I think that
in the past, we have argued (and Gregory has objected) that
providing the computed value was not a P1 requirement.
One reason is that CSS computed values (as defined in
section 6.1.2 of the CSS2 specification [2]) are a step
removed from "actual values", which are "computed values
after any approximations have been applied." In other
words, the user agent may not be able to use a computed
value and therefore make modifications to it that will
not be reflected through the DOM CSS module. So the goal
of providing information to ATs about "what's on the screen"
is not entirely met by the CSS DOM.
Summarizing why I don't think that CSS DOM support should
be a P1 requirement (nor P2, though I feel less strongly
about that):
1) Information is available through the Style Sheets module
(bug fixed thanks to Gregory).
2) ATs would probably have to be almost, if not entirely,
CSS agents to make use of the DOM CSS API.
3) The DOM CSS module may not solve the problem completely
anyway.
- Ian
[2] http://www.w3.org/TR/REC-CSS2/cascade.html#computed-value
> This is extremely important,
> as inline style attributes are particularly difficult (if not impossible)
> for most users to either anticipate and/or change/tailor/transform into
> something useable by that user by use of a client-side stylesheet. As the
> Proposed Recommendation draft of the DOM2 Style Module states, quote It
> represents the contents of the STYLE attribute for HTML elements (or
> elements in other schemas or DTDs which use the STYLE attribute in the
> same way). The expectation is that an instance of the
> ElementCSSInlineStyle
> interface can be obtained by using binding-specific casting methods on an
> instance of the Element interface when the element supports inline CSS
> style informations. unquote
>
> I believe that this alone is a most compelling reason for raising the
> priority level of UAAG Checkpoint 5.7 (support for the DOM2 Style Module).
> Moreover, the quote cited above is drawn from Section 2.2.3. (Element with
> CSS inline style), a sub-section of Section 2.2, which is entitled, quote
> CSS Fundamental Interfaces unquote of which, the Proposed Recommendation
> states:
>
> quote
> The interfaces within this section are considered fundamental CSS
> interfaces, and must be supported by all conforming implementations
> of the CSS DOM module. These interfaces represent CSS style sheets
> specifically.
> unquote
>
> 2. Currently the CSS module is the only way that pseudo-elemental information
> can be carried through the DOM, and thereby exposed to the user either
> through the user agent's UI, or via the user's assistive technology.
>
> 3. While information about nested lists is carried through the DOM, such
> essential orientational information is often unavailable to a user with a
> disability, due to the use of UA-generated symbols to indicate the nesting
> level of a list item. The use of pseudo-elemental text (using the
> ":before" and ":after" syntax outlined in Section 12.1 of the CSS2
> Recommendation) to indicate the nesting level of a list item (as well as
> distinguishing one list item from another) prevents perceptual black
> holes that can drastically affect a disabled user's interaction with a
> document
>
> 4. Use of stylesheets to generate pseudo-elemental information (such as
> "Begin Spanish text" and "End Spanish text") is not only of incalculable
> assistance to users with physical disabilities, but may also facilitate
> comprehension of a document's content and structure for a user with a
> cognitive disability
>
> 5. Promotion of the development of more interoperable, as well as more
> accessible and more usable, user agents through the promotion of more
> widespread and robust support for aural and tactile environments (more
> robust support for "@media" rules other than those which have currently
> been implemented, and which are--implicitly or explicitly--visually-
> oriented)
>
> References:
> 1. Document Object Model (DOM) Level 2 Style Specification, 27 September
> 2000 (Proposed Recommendation) Draft
> <http://www.w3.org/TR/2000/PR-DOM-Level-2-Style-20000927>
>
> 2. Cascading Style Sheets, Level 2 Technical Recommendation
> <http://www.w3.org/TR/REC-CSS2/>
>
> 3. The :before and :after pseudo-elements:
> <http://www.w3.org/TR/CSS2/generate.html#before-after-content>
> ------------------------------------------------
> 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/>
> ------------------------------------------------
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 19 October 2000 13:23:44 UTC