W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Re: Proposal for modifying checkpoint 4.17 (Issue 405)

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 14 Dec 2000 14:48:00 -0500
Message-Id: <200012141953.OAA729496@smtp1.mail.iamworld.net>
To: jon gunderson <jongund@ux1.cso.uiuc.edu>
Cc: Jon Gunderson <jongund@staff.uiuc.edu>, w3c-wai-ua@w3.org
Works for me, with one low-level detail suggestion:

Detail:  I would use "e.g." rather than "i.e." because when reading a
specification I would take i.e. as restrictive, and the focus and selection
styles are not _limited_ to the formatting properties mentioned.

The abbreviation i.e. is short for "id est" which is Latin for "that is."  The
implication is that when i.e. is used, all relevant cases are covered in what
is stated.

The abbreviation e.g. is short for "exempli gratia" which is Latin synonymous
with "for example" or "such as."  The implication is that when e.g. is used,
there are some examples given but there are actually others that are also
and not mentioned.


PS:  This is one of those cases which confirms Eric's insistence that
vocabulary matters.  While it looks 'editorial' as a "wrong word" discrepancy,
it affects the substantive interpretation of the language of the checkpoint. 

At 05:31 AM 2000-12-14 -0600, jon gunderson wrote:
>How about htis for the last sentence.
>If an element has both selection and highlight, and there exists a
>conflict between selection and focus styling (.i.e. color, border style,
>text decoration), focus styling should receive priority for final
>On Wed, 13 Dec 2000, Al Gilman wrote:
>> At 01:32 PM 2000-12-13 -0600, Jon Gunderson wrote:
>> >Al,
>> >Basically from my point of view, if there is choice between using

>> >or focus color use the focus color.  If there is a choice between

>> >and focus border styles use the focus border style.  If selection uses 
>> >border styling and focus doesn't use border styling there is no conflict 
>> >that the priority rule would need to decide on.  In this case the

>> >border could still be rendered on an item with both selection and focus.
>> >
>> >Is this what you want to say?
>> >
>> That's a little more specific than I wanted to say, but it is very similar.
>> I would want to give the User Agent free rein to invent creative ways to
>> combine the selected effects.  If the User Agent developer decides to punt
>> combining certain effects, then they can resort to the priority and favor
>> presentation effects associated with focus.
>> [more below]
>> >Is there a way that this can be more clearly stated in the checkpoint?
>> >
>> Quoting from
>> Message-Id: <>
>> archives at: 
>> [NEW]
>> 4.17 Allow the user to configure how the content focus is highlighted 
>> (e.g., foreground and background color, voice pitch,
>> etc.). For graphical viewports, offer at least three rendering options, 
>> including colors and fonts. For graphical viewports, allow the user to 
>> select from among the range of system colors and fonts. The default focus 
>> highlight mechanism must be different from the default selection highlight 
>> mechanism.  If an element can simultaneously be part of a selection and 
>> have focus, the focus styling should have priority over the selection 
>> styling when rendering the element. [Priority 1]
>> [/NEW]
>> [just take that last sentence]
>> If an element can simultaneously be part of a selection and have focus, the
>> focus styling should have priority over the selection styling when
>> the element.
>> [Maybe it could say]
>> When some content is both focused and selected, the user agent should give
>> priority, if needed to resolve a conflict, to the focus styling over the
>> selection styling.
>> [What do others think?]
>> Al
>> >Jon
>> >
>> >
>> >
>> >At 02:13 PM 12/13/2000 -0500, you wrote:
>> >>At 12:11 PM 2000-12-13 -0600, Jon Gunderson wrote:
>> >> >
>> >> >2. Focus style should have priority over selection style.  No mixing,
>> >> >priority.
>> >> >
>> >>
>> >>Please note my concern on this point.  The UA should be allowed or
>> encouraged
>> >>to mix them if it can.  The priority should only be an issue if it
>> The
>> >>CSS algorithm (pick one style) is bad human engineering in this
>> >>Lots of the relevant screen effects mix fine.
>> >>
>> >>I think that my input on this point is consistent with what Greg Lowney
>> said.
>> >>Greg says that the default focus and selection styles should be mixable
>> be
>> >>mixed when something is both focused and selected.  That is a good idea. 
>> >>don't necessarily have to make it a requirement, but we sure shouldn't
>> it
>> >>disallowed.
>> >>
>> >>It's one thing to say that the UA is not required to mix them and when it
>> >>can't
>> >>it should use the focus style.  It's another to say that the UA should
>> mix
>> >>them but just use the focus style.  To me the latter is writing rules
>> >>degrade the communication effectiveness of the tool, which is not our
>> >>last I checked.
>> >>
>> >>Al
>> >
>> >Jon Gunderson, Ph.D., ATP
>> >Coordinator of Assistive Communication and Information Technology
>> >Division of Rehabilitation - Education Services
>> >MC-574
>> >College of Applied Life Studies
>> >University of Illinois at Urbana/Champaign
>> >1207 S. Oak Street, Champaign, IL  61820
>> >
>> >Voice: (217) 244-5870
>> >Fax: (217) 333-0248
>> >
>> >E-mail: jongund@uiuc.edu
>> >
>> >WWW:
>> >WWW:
>> >  
Received on Thursday, 14 December 2000 14:47:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:29 UTC