W3C home > Mailing lists > Public > www-style@w3.org > April 2004

Re: some WAI comments on CSS3 Basic UI, more WAI comments on CSS3 Basic UI, forms terminology in CSS3 Basic UI

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Sat, 10 Apr 2004 23:48:50 -0700
To: Al Gilman <asgilman@iamdigex.net>
Cc: <www-style@w3.org>
Message-ID: <BC9E3853.3AB8C%tantek@cs.stanford.edu>

On 7/31/03 7:04 AM, "Al Gilman" <asgilman@iamdigex.net> wrote:

> <notes
> class="inTransmittal">
> 
> Reference:
> 
> http://www.w3.org/TR/css3-ui/
> 
> These comments were developed in the Protocols and Formats working group.
> They have had some of the rough edges knocked off them in that process,
> but are certainly open to clarification and refinement.  We don't claim
> to have absorbed all the context for the current document completely.
> 
> If there is anything in these comments which is not clear, or appears to be
> un-implementable, we would welcome the opportunity to discuss these points
> with you before you make a final determination on a disposition.
> 
> Thank you for your consideration of these comments.
> 
> Al
> --
> Al Gilman, Chair
> W3C/WAI Protocols and Formats Working Group
> 
> </notes>

Thank you for your review and comments.

The individual comments are addressed below, in context, as discussed
between the CSS and WAI-PF working groups at the recent W3C All-Group
meeting in Mandelieu.


> 1. Automatic icons
> 
> Specific Reference:
> 
> http://www.w3.org/TR/css3-ui/#box-model
> 
> The document introduces the new 'icon' value for the 'display' property of
> an element and adds an 'icon' property which identifies a resource which
> replaces the element in the rendered content if the the value of 'display'
> is 'icon.'
> 
> However, it goes on to include an 'auto' value for the 'icon' property which
> is "as defined by the user agent."

Agreed.


> But there is no clue as to when the user agent will use one icon vs. another.
> 
> Does this not open wide a barn door for entire UIs to be constructed without
> the faintest semantic clue in the 'content' as to what is going on?

Disagreed.  The 'auto' value is only there to capture initial default
styling, and it is necessary for precisely that reason.


> The standing problem with the "separation of content and presentation"
> afforded by CSS is that there is no standardization of the 'class' tokens
> that govern the selection of style rules.  This innovation perpetuates or
> exacerbates that problem, in that there is no basis in any standard taxonomy
> for the selection of UA-supplied icons.

Disagreed.  There is no worsening of any problem because the 'auto' value in
this case only reflects default styling behaviors which already exist.

This allows the behavior typical of the environment to flow through.

The UAAG says that user agents should follow the interface conventions of
the environment when possible.

The 'auto' value for the 'icon' property enables style sheet authors to
explicitly do so, when they don't have a better icon to offer.


> Delivery contexts where we would be interested in the re-binding of elements
> where the author's presentation used display:icon and icon:auto would include:
> 
> Simplified verb vocabularies, for severe learning disabled -adaptive
> presentation
> as described in
> 
>  http://www.learningdisabilities.org.uk/html/content/webdesign.cfm
> 
> a similar verb-vocabulary-reduction transform for operability from a
> telephone or
> computer number keypad.  Used in mobile device transform and for users with
> good
> fine motor control but bad gross motor strength.
> 
> Personalized verb-vocabulary-transformation for auxiliary communication device
> uses with a large but personal vocabulary of one-button utterances.
> 
> Anyone else with high cost of input symbol actuation needing a normalization
> of
> the verb vocabulary as part of optimizing the binding of shortcuts.

Agreed.  These are all excellent use cases for the 'icon' property.



> 2. Directional [focus] navigation introducing hyperlinks?  Don't.

Disagreed.  This is functionality that has been requested (and to some
extent already implemented) by various companies and other standards bodies
(specifically in the television space, e.g. DVB, ATSC).  We (W3C) have been
asked to normalize this functionality so that there can be a consistent set
of properties, values and behaviors, rather than differences among
implementations and various standards bodies.


> Specific Reference:
> 
> http://www.w3.org/TR/css3-ui/#nav-dir
> 
> The specification introduces a mechanism by which a stylesheet can identify
> multiple navigation destinations (hyperlink equivalents) bound to an element
> in the document which are navigated-to and given focus on receipt of
> directional-navigation user-input events.
> 
> Each navigation destination may be an arbitrary URI-reference i.e. off the
> current web page, and the back button is by [the draft] specification broken.
> 
> This functionality should not be included as drafted here.  Navigation
> destinations associated with an element are content, not style.

Disagreed.  *Directional* focus navigation is very much dependent on the
layout of the page, and thus goes hand in hand with the styling of the page.
Thus *directional* navigation hints are very much style, not content.


> The equivalent functionality should be implemented by
> 
> a) in the content, creating vectored, that is to say multiple/selectable
> hyperlinks using the results of the currently-active consultation on linking.

Agreed that this would be useful functionality.
Disagreed that it should be in CSS3-UI.
Note that this kind of functionality should NOT preclude directional focus
navigation -- both functionalities are useful.


> b) in the styling, binding arrow keys or other directional-navigation UI
> events to these navigation arcs using the keyboard-control facilities
> established in section 8.2 above.

Agreed postponed.  It could certainly be useful to bind the directional
focus navigation to elements indicated by arbitrary attributes or other
elements.  This is functionality that could be added to a future version of
the directional navigation properties and should be thusly considered.  At
the moment, implementation experience has shown that no such immediate need
exists, therefore it makes sense to postpone this feature.


> 3. More to come
> 
> There are a few more comments we are working on the reference links for.

Agreed.




On 8/6/03 10:27 AM, "Al Gilman" <asgilman@iamdigex.net> wrote:

> <notes
> class="onResend">
> 
> Tantek, Bert:
> 
> The first send of this message to www-style appears to have gotten
> lost in the mails. A copy showed up in the wai-liaison archives
> 
> http://lists.w3.org/Archives/Member/wai-liaison/2003Jul/0018.html
> 
> but not in the www-style archives.  Hope you can still process
> the as Last Call comments.
> 
> Al
> </notes>

Agreed.  The CSS working group agreed to process these additional comments
as Last Call comments.


> <notes
> class="inTransmittal">
> 
> Reference:
> 
> http://www.w3.org/TR/css3-ui/
> 
> These comments were developed in the Protocols and Formats working group.
> They have had some of the rough edges knocked off them in that process,
> but are certainly open to clarification and refinement.  We don't claim
> to have absorbed all the context for the current document completely.
> 
> If there is anything in these comments which is not clear, or appears to be
> un-implementable, we would welcome the opportunity to discuss these points
> with you before you make a final determination on a disposition.
> 
> Thank you for your consideration of these comments.
> 
> Al
> --
> Al Gilman, Chair
> W3C/WAI Protocols and Formats Working Group
> 
> </notes>

Thank you for your review and comments.

The individual comments are addressed below, in context, as discussed
between the CSS and WAI-PF working groups at the recent W3C All-Group
meeting in Mandelieu.



> 4. Navindex and keyboard control:
> 
> For languages where an accesskey or similar function exists, the accesskey
> attribute should take precedence. It may be years before CSS figures into
> the interaction between sites and assistive technologies.
> 
> Key equivalents and nav-index items should also be displayable via menu, to
> allow users to discover them.
> 
> For the purposes of re-mapping, the user agent implementation of key
> equivalents and the navigation index ordering should be treated like event
> handlers as discussed in
> 
> http://www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-handlers
> 
> In the case of re-mapping because an indicated key is not available in the
> delivery context, it is not enough to 'ignore' the indicated key.  *Some*
> alternative mode of activation needs to be provided.  The provisions as
> stated in XForms on this point should apply, here.
> 
> <quote
> cite="http://www.w3.org/TR/xforms/slice8.html#id2623376">
> 
>   accesskey
>          Optional attribute defines a shortcut for moving the input
>          focus directly to a particular form control. The value of
>          this is typically a single character which when pressed
>          together with a platform specific modifier key (e.g., the alt
>          key) results in the focus being set to this form control.
> 
>          The user agent must provide a means of identifying the
>          accesskeys that can be used in a presentation. This may be
>          accomplished in different ways by different implementations,
>          for example through direct interaction with the application or
>          via the user's guide. The accesskey requested by the author
>          might not be made available by the player (for example it may
>          not exist on the device used, or it may be used by the player
>          itself). Therefore the user agent should make the specified key
>          available, but may map the accesskey to a different interaction
>          behavior.
> 
> </quote>

Not applicable / postponed.

As discussed, the problematic 'key-equivalent' property is being dropped
from CSS3-UI based on your feedback and the feedback of others, until it can
be fixed with major changes to address the problems and concerns that have
been raised.


> 5. System fonts and colors:
> 
> If a user has extra large system fonts set at the OS level, and has their
> browser set to increase the size of Web sites by 200%, this could be a
> problem, in that the resulting font could become absurdly large.

Disagreed.  The problem statement does not make sense, because EITHER:

  1. The web site (or element) uses a system font, and thus EXACTLY reflects
the user's OS level font preference.

OR

  2. The web site (or element) DOES NOT use a system font, and thus has its
size increased by 200% by the user preference.

The way you have worded the problem, it is not possible for both situations
to occur, thus the problem situation you pose cannot occur.


> At the 
> same time, some users with low vision keep their icons small, but want
> larger text when they are reading rather than interacting with the OS. This
> is a thorny issue due to the juxtaposition of operating system and user
> agent accessibility conventions.

Agreed.  The UAAG should address this issue.


> Users should be able to override system font or appearance selections with
> their own choices or proportions, within the user agent.

Agreed.  The CSS2.1 specification (which CSS3 UI normatively references)
requires user agents to allow turning off style sheets.

The UAAG should provide specific advice about user agent preferences.

CSS3UI will mention your suggestion.


> Compare with the requirements in the User Agent Accessibility Guidelines
> such as
> 
> http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-styles
> 
> 

Agreed. Those are excellent suggestions and I will add a link to them in the
next draft.




On 7/31/03 7:38 AM, "Al Gilman" <asgilman@iamdigex.net> wrote:

> 
> 
> 
> [individual comment, not reviewed in PF group.]
> 
> General Reference:
> 
> http://www.w3.org/TR/css3-ui/
> 
> 1. :out-of-range
> 
> In
> 
> 3.1.3. :in-range and :out-of-range
> http://www.w3.org/TR/css3-ui/#pseudo-range
> 
> there appears to be a mis-use of XForms terminology.
> 
> Where it says
> 
> <quote
> cite="http://www.w3.org/TR/css3-ui/#pseudo-range">
> 
>   v... In summary: an element is
>   :out-of-range when it does not accurately reflect the state of the
>   model.
> 
> </quote>
> 
> ..should it not say "the state of the instance"?  Suggest you cross-check
> with XForms.
>
>
> A possible re-wording of the whole paragraph would be:
> 
> <draft
> class="possible clearer">
> 
> The :in-range and :out-of-range pseudo-classes are defined with respect to the
> limitations of the rendered or concrete interface, as opposed to the :valid
> and :invalid pseudo-classes defined above which reflect the logical
> limitations
> imposed by the application or business logic through the model.
> 
> A rendered element is :out-of-range when the value in the bound instance that
> it should display is beyond its capability to display.  For example, a slider
> which can show values from 1-10 when the value in the instance is 11 would
> have :out-of-range true and :in-range false.
> 
> </draft>


Agreed.  This section has been cross-checked with XForms and made consistent
with the corrections requested by the XForms folks.


> 2. What's a form element?
> 
> <quote
> cite="http://www.w3.org/TR/css3-ui/#pseudo-required-value">
> 
>    3.1.4. :required and :optional
> 
>   A form element is :required or :optional if a value for it is,
>   respectively, required or optional before the form it belongs to is
>   submitted. Elements that are not form elements are neither required
>   nor optional. This spec does not defined what is a form element.
> 
> </quote>
> 
> The last two sentences taken together form a semantic hole in the
> specification.  This will lead to semantically-incompatible use by
> different users and implementers and the feature will become disreputable
> and will be avoided in practice.  Unsuitable in a specification.
> 
> Consider instead:
> 
> Cite specifically the items in the XForms schema and HTML specification
> which have the intended semantics, and extrapolate gracefully from there.
> 
> Say things like
> 
> processors MUST recognize the following conditions as :required and :optional
> where the XForms schema applies:...
> 
> processors MUST recognize the following conditions as :required and
> :optional where HTML 4.01 semantics applies by specification:...
> 
> processors MAY recognize these pseudo-classes in formats which use clearly
> equivalent semantics
> 
> processors SHOULD NOT recognize either :required or :optional in the absence
> of
> any of these conditions.

Disagreed.  In discussions with the XForms group, the better suggestion was
to simply leave outside the bounds of the specification of "what is a form
element".  Thus a general statement was placed earlier on that states that
the specification does not define what is a form element.  This makes the
most sense, because other specifications can much better define what is a
form element, and if CSS3-UI also did so, it might accidentally contradict
such other specifications in that manner, and that is undesirable.


Thank your for your review and feedback.  Your comments have helped improve
the CSS3 UI module specification.

Regards,

Tantek Çelik
editor, CSS3 Basic UI module
Received on Sunday, 11 April 2004 02:48:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:28 GMT