Re: [CSS21] as-rendered properties

>On Monday 2005-08-29 15:31 -0400, Al Gilman wrote:
>>  At 2:58 PM -0700 7/21/05, L. David Baron wrote:
>>  >On Thursday 2005-07-21 17:38 -0400, Al Gilman wrote:
>>  >> at the CSS working group. What provision is being made in the CSS DOM
>>  >> API to acquire the final format css properties. This information is
>>  >> used by assistive technologies and in fact is a fulfillment
>>  >> requirement of accessibility APIs. It is valuable for platform
>>  >
>>  >How is the getComputedStyle method in
>>  >http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-ViewCSS
>>  >insufficient for this requirement?
>>
>>  The assistive technologies need to know the actual values of
>>  presentation properties.
>>
>>  It is our understanding that the computed style may not reflect the
>>  property values
>>  that actually appear in the user experience.  Is this true?
>
>That is true.  For example, when a device has bitmap fonts available at
>9, 12, and 15 pixels and the computed value of 'font-size' is 11px, the
>12px font might be used (or, likewise, if the computed value is 11.8px
>and the device or graphics API is only capable of rendering fonts at
>integral pixel sizes).  Or if the computed value of 'color' is #A0BDEA
>and the device has 8-bit color, the color #99CCFF might be used instead.
>
>  > http://www.w3.org/TR/CSS21/cascade.html#actual-value
>>
>>  When they differ, we need the actual values, as opposed to the computed
>>  values.
>
>Given the examples I gave, I'm not quite sure why.  Do you have some
>examples showing why?

How does this interact with a High Contrast setting in the OS?

There are several concerns:

a) if the approximation causes differently - styled content to be
presented the same, information is lost. Knowing that there is no
distinction in the as-rendered content alerts the view manager to
signal these differences some other way than via the property which
carries the distinction in the style rules.  In your example style
rules that compute to 11 and 13 (normally perceived as quite
distinct) could collide at 12 when the choices are (9, 12, 15).

b) The difference may be over the boundary between usable and
non-usable in some cases. The examples given are at the mild end.
It's not clear that the differences are guaranteed to be that mild.
Here [I don't myself know the particulars but] the interaction with
High Contrast in the OS is a conspicuous example where the 'used'
value, even, may not be close to the actual. When using large fonts and
screen magnification together, one next-available difference in the font
size could make a radical difference in the viewport width in em's
and make text readable or unreadable by a difference of one available
font size.

c) We can't get the AT vendors to use what is available in the DOM
until what is in the DOM is what is on the screen. Most of the
content that screen reader users use was created for eyeballs and
without concern for usability with a screen reader. Consultation with
sighted friends or associates is a fact of life. If the AT is reading
the DOM and the AT is therefore telling the sightless user things
that the sighted helper doesn't see, all trust is lost. This is the
sad experience of the AT industry and they have retreated to very low
level processing of the content and eschew the DOM. So without this
"what they see is what you get" validity, we can't get the AT
industry bought into using the high-science version of accessing
browsers.  But that is were we have to get to make it all work.

>Requiring implementations to *know* the actual value in some of these
>cases might be a significant burden (and not one that we currently
>impose).  Consider the examples of printing, where an implementation
>might not know whether it's printing to a color or black and white
>printer, or an implementation built on top of a graphics or font API
>where it might not know what approximations the API it's using needs to
>make.

Printing is an interesting example.

Web media other than PDF that depend on CSS for styling are avoided
for printing precisely because there is inadequate synchronization
between what the controller knows and what the view produces. I know
this is being addressed with newer specifications and
implementations. But there is a lot of market share to catch up and
this is directly related to why we're playing catch-up at this time.

We lost that printing market because we assumed it was too hard to know.
The competition knew they had to know and invented the necessary
technology.  Live an learn.

Here is another example where a system issue that people with disabilities
raise is actually a serious problem for other reasons for the technology that
they are alerting to the problem.

>  > Thank you for you assistance in clarifying this comment.
>
>It seems to be a reasonable comment on the CSSOM specification (although
>I still think I disagree, based on what I've heard so far), but I still
>don't see how it's a comment on CSS2.1.

You may be right in terms of the way that W3C has divided up the 
specifications.

We can only testify to the fact that it is a system flaw as far as access for
people with disabilities, and to the extent that there is a 
separation of content
from presentation, CSS is, where it is used, the system segment responsible
for rendering or presentation.  And CSS 2.1 is the great white hope in terms
of a widely-commonly implemented profile of CSS.

This is, for our needs, a defect in the behavior of the rendering 
system-segment.

We don't really have the discernment as to whether this belongs in one spec
or another or in an overarching profile.  All we know is it does need fixing.

I think that we will progress faster with some joint talk time on
this; I'll approach Bert to try to set it up.

Al

>-David
>
>--
>L. David Baron                                <URL: http://dbaron.org/ >
>           Technical Lead, Layout & CSS, The Mozilla Foundation
>
>Attachment converted: Macintosh HD:Untitled 76 (    /    ) (0009AD93)

Received on Thursday, 1 September 2005 19:22:33 UTC