- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 22 Jul 2009 18:26:41 -0700
- To: Jon Gunderson <jongund@illinois.edu>
- Cc: Charles McCathieNevile <chaals@opera.com>, Doug Schepers <schepers@w3.org>, Anne van Kesteren <annevk@opera.com>, wai-xtech@w3.org, Jacob Rossi <t-jacobr@microsoft.com>, Travis Leithead <travil@microsoft.com>, www-dom@w3.org, public-forms@w3.org
On Jul 22, 2009, at 5:55 PM, Jon Gunderson wrote: > These event handlers are commonly used to create styling effects for > node or more importantly related nodes that cannot be styled using > CSS selectors. > > If an element receives keyboard focus what event can be used to > update visual styling? The "focus" and "blur" events can be used for this. "DOMFocusIn" and "DOMFocusOut" largely duplicate their functionality. Although for purely visual styling, I would recommend CSS :hover effects over script. > If we don't need focusin and focusout, then I assume mouseover and > mouseout will also be deprecated. > > Focus styling is not very well implemented in browsers or by web > developers. No one is proposing taking away focus events. The question is just whether we need to have two separate sets of them. - Maciej > > Jon > > > ---- Original message ---- >> Date: Thu, 23 Jul 2009 00:18:55 +0200 >> From: "Charles McCathieNevile" <chaals@opera.com> >> Subject: Re: Deprecating DOMFocusIn/DOMFocusOut (was: DOMActivate >> vs. Click) >> To: "Doug Schepers" <schepers@w3.org>, "Anne van Kesteren" <annevk@opera.com >> >, "wai-xtech@w3.org" <wai-xtech@w3.org> >> Cc: "Jacob Rossi" <t-jacobr@microsoft.com>, "Maciej Stachowiak" <mjs@apple.com >> >, "Travis Leithead" <travil@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org >> >, public-forms@w3.org >> >> IMHO, and cc'ing the WAI-xtech list to see if PF really agrees with >> me. >> >> On Wed, 22 Jul 2009 23:05:25 +0200, Doug Schepers <schepers@w3.org> >> wrote: >> >>> Hi, Anne- >>> >>> +public-forms@w3.org >>> >>> Anne van Kesteren wrote (on 7/22/09 9:35 AM): >>>> On Tue, 21 Jul 2009 23:16:14 +0200, Jacob Rossi<t-jacobr@microsoft.com >>>> > >>>> wrote: >>>>> >>>>> Ok. That makes sense. Given that, is DOMActivate simply left in >>>>> DOM >>>>> L3 Events to support backwards compatibility with DOM L2 events? >>>>> Or >>>>> are there still use cases which it solves that other events do >>>>> not? >>>> >>>> I think the sole reason we have DOMFocusIn, DOMFocusOut, and >>>> DOMActivate is political. I'm not sure if that changed to backwards >>>> compatibility at this point, but I doubt it. >> >> They were created at a time when there were serious accessibility >> problems >> activating the relevant events through keyboard use, and it was a >> compromise between fixing the more common events and doing nothing >> - in >> that sense it was indeed political. >> >> Since then, the original events have in fact been improved in >> browsers, >> and the reason for retaining these is back-compat (this was an early >> decision of the old WebAPI WG) at the request of other groups. >> >>>> DOMFocusIn and DOMFocusOut have been retained on request of the >>>> Forms >>>> WG and for DOMActivate I do not really remember. Fact of the matter >>>> is that focus/blur/click work fine and already are platform >>>> independent and much better understood by authors of Web >>>> applications. >>>> >>>> I'd be very happy if could consider yet again dropping >>>> DOMFocusIn/DOMFocusOut/DOMActivate. >> >> I think it makes good sense to deprecate them, pointing out that >> people >> shouldn't keep using them but should use the improved originals. >> (And it >> only took ten years to get to this :) ). >> >> Likewise, the click event is now cross-platform and device- >> independent, so >> the reason for a seperate DOMActivate is gone, and that should also >> be >> deprecated. >> >> I haven't looked carefully at the impact on WCAG 2 yet, but the >> impact on >> WCAG 1.0 is that the relevant checkpoints 6.4 [1] and 9.3 >> especially, but >> also some others need not be updated. However the techniques >> documents >> should note that it is possible to use the focusin/out and click >> events >> because they are generally device-independent in this way (mouseover, >> mousein/out by contrast are still problematic). If someone could >> check >> this for WCAG2 it would be helpful. >> >>> Taking a look at the current state of implementation [1], and >>> seeing the >>> similarity of function between IE's focusin/focusout and >>> DOMFocusIn/DOMFocusOut, I have now included focusin/focusout, and >>> deprecated DOMFocusIn/DOMFocusOut in favor of those event types. >>> This >>> is a tentative decision, but it seems logical to me; any comments >>> are >>> welcome. >> >> [1] >> http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-keyboard-operable-scripts >> [2] >> http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-device-independent-events >> >> cheers >> >> Chaals >> >> -- >> Charles McCathieNevile Opera Software, Standards Group >> je parle français -- hablo español -- jeg lærer norsk >> http://my.opera.com/chaals Try Opera: http://www.opera.com >> > Jon Gunderson, Ph.D. > Coordinator Information Technology Accessibility > Disability Resources and Educational Services > > Rehabilitation Education Center > Room 86 > 1207 S. Oak Street > Champaign, Illinois 61820 > > Voice: (217) 244-5870 > > WWW: http://www.cita.uiuc.edu/ > WWW: https://netfiles.uiuc.edu/jongund/www/ > > --------------------------------------------------------------- > Privacy Information > --------------------------------------------------------------- > This email (including attachments) is covered by the Electronic > Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and > may be legally privileged. It is intended for the use of the > individual or entity to which it is addressed and may contain > information that is privileged, confidential, and exempt from > disclosure under applicable law. If the reader of this email is not > the intended recipient, or agent responsible for delivering or > copying of this communication, you are hereby notified that any > retention, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, please reply to the sender that you have > received the message in error, then delete it. Thank you. > >
Received on Thursday, 23 July 2009 01:27:29 UTC