Summary of UA discussion with CSS WG

Hello,

The CSS WG was kind enough to allow Gregory and me to
discuss some user interface questions about CSS3. Below is
a quick summary of the discussion, with some action
items highlighted for UAWG/WAI PF follow-up. 

1) Include a stricter requirement that a conforming user 
   agent allow ssers to specify user style sheets in CSS3.

 a) The Working Group agreed in principle, but raised some
   questions about whether this would be burdensome for small
   devices. It was pointed out that the user style sheet didn't
   necessarily need to reside on the mobile device (e.g., a server
   could be configured to apply it on the server side). There
   were other comments that exceptions due to device limitations
   were already covered by "the spec". However, it doesn't seem that
   there's a CSS3 module that addresses user style sheets (so no
   place to include this requirement yet).
 
 b) Suggested requirements:

   i) A conforming user agent must allow users to 
      apply user style sheets. [Authoring them not required, but
      possibly required for an authoring tool.]

  ii) A conforming user agent must allow users to turn
      off author and user style sheets.  
      Note: The WG said "Users need to turn off 
      author and user style sheets even in the XML case?" to which
      we replied that both functionalities (turning off user
      and author styles) were useful independently, and therefore
      both needed to be implemented. It was not a problem that,
      in some cases, the user might not find useful turning off all
      author and user style sheets (leaving only UA default styles).
      
 iii) A conforming user agent must allow users to select
      from available alternative style sheets.

ACTION: The CSS WG would like WAI PF to make a formal proposal
        for what requirements about selection of user/author
        style sheets should be in CSS3.

2) Will CSS3 have a :selection pseudo-class?
   Answer: yes (in the UI module [1]). However, the WG does not
   anticipate making the selection stylable according to the
   full range of visual styles (this is in line with the
   UAWG's own expectations about not requiring font size changes
   for selected text). The CSS WG had not anticipated making
   the selection stylable for audio/speech output and agreed
   in principle to add ACCS properties to the spec.

   We also asked whether the CSS WG was aware of whether the
   DOM WG was going to implement the selection in the DOM
  (the CSS WG didn't know). I think that the DOM WG does not
  intend to include an API for selection (not sure, though).
  The CSS WG is also interested in such an API.

ACTION: The CSS WG would like WAI PF to make a formal proposal
        listing specific properties of ACSS (possible a subset
        of all of them) that should be available with the
        :selection pseudo-class.

[1] http://www.w3.org/TR/css3-userint

3) Device-independent property values in the UI module?

 There was discussion of the device-dependent property values
 in section 4.6 of CSS3 UI module [1] (e.g., 'hover-checkbox-on').
 People agreed that:

 a) It was a good thing to remove device-dependent information
    from format specs.

 b) The CSS spec should use device-independent properties/values
    when genericity is cal

 c) It was ok to have device-dependent values for media-specific
    rendering.

 Conclusion: The CSS3 spec seems ok as is.

4) Keyboard bindings (key-equivalent, tab-index).

 We said that the HTML 4 keyboard access model was broken.
 The CSS WG asked for a URI to documentation of the fact
 that it's broken.

 Here's one (from w3c-wai-ua):
   http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0017.html

 We asked how much coordination had been done between DOM WG,
 CSS WG, and WAI PF. Not much had been done.

 It is not certain that the CSS3 modules will fix the model, but there
 may be some benefits by moving it to CSS (e.g., the cascade).

 There was discussion of the need for "modes" in a keyboard
 access model (to be able to reuse characters since there are
 a limited number of single keys).


ACTION: The CSS WG would like WAI PF to document how the HTML
        keyboard access model is broken. Also, some coordination
        should be done with DOM/CSS/WAI PF about keyboard
        models.
            
5) Status report on behaviors module.

  There was mention of the recent "XBL - XML Binding Language 1.0"
  Submission [3]. It seems like there may be movement
  around this module again. There was also mention of UIML (but not
  much mention).

  [3] http://www.w3.org/Submission/2001/05/

6) Status report on ACSS module.

  Not much happening here (and the WG didn't know of any
  implementations other than emacspeak). There seems to be growing
  interest in getting ACSS implemented in a major browser.  Also,
  there was some discussion about how ACSS should not just be for
  speech-only or audio-only output; it should be used (and useful) in
  visual-plus-speech environments.
  
  Is the Voice WG to take over this work? Apparently not.
  The Voice WG does not seem to be moving in the direction of writing
  specs where content styled for voice input and speech
  output. Instead, they are using a model where they are representing
  already-styled content (this is a rough summary of Chris Lilley's
  assessment of the Voice WG's work).

7) Authoring requirements?

  Daniel Glazman (Netscape) asked whether we had any suggestions
  for the Composer developers with respect to CSS. 
  We mentioned the ability to author with one style sheet and
  publish with another, and we pointed them to the ATAG 1.0.

8) Styling properties for time-dependent content.

  We asked whether CSS should include properties for time control
  of time-dependent content. There is already a property for
  controlling speech playback rate, what about video and animations? 
  We agreed that specific WGs (e.g., SYMM) should come up with 
  properties and values they needed, but that these should be 
  integrated into the common formatting properties. Having these
  properties in CSS rather than in each individual format
  has advantages such as the cascade, styling through selectors, 
  etc.

9) Ruby

  We didn't really discuss Ruby, but acknowledged that it would
  be a useful mechanism for authoring text annotations.

10) Same requirements for XSL as for CSS?

  The CSS WG asked whether we had approached the XSL WG with
  these same requirements. We said we had not yet, but that was
  a good idea.

11) Mention of accessibility features in the CSS specs.

  We didn't address this topic: getting the CSS spec itself
  to include text such as "This feature is known to be 
  useful to users with disabilities for the following reasons..."

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Monday, 26 February 2001 18:48:07 UTC