- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 11 Mar 2010 09:37:29 -0800
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org, HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html-a11y-request@w3.org
- Message-id: <252D577A-D46D-40CE-8972-606ADBDD8B86@apple.com>
On Mar 11, 2010, at 7:43 AM, Richard Schwerdtfeger wrote: > Hi Maciej, > > First, this is great feedback. I tried to stay in line with what was > in the 2D Context draft that was out there, which in the fine print, > indicated that the focus rectangle was also used for caret. It was > unclear how much of the drawFocusRing() was implemented and I tried > not to break things. So, I also had problems with reusing the same > method. > > Here is the the text in the existing text that I am referring to: > "The position of the center of the control, or of the editing caret > if the control has one, should be given in the x and y arguments." > > So, it appears you are in agreement with simply having caret API > that says setCaretPosition with a set of coordinates. As it states > it would be bound to an element in the subdom which has a logical > character position which the author would synch with. This we have > in the proposal. I will simply separate them out. > Why setCaretPosition rather than setSelectionPosition? It seems to me that screen magnifiers or the like may be interested in the screen location of non-caret selections too. > Second, if we require the author to do all the caret drawing I see a > problem with not honoring blink rate settings that the author does > not have access to. If the blink rate is high enough (greater than 3 > times a second) this may call seizures in some users. Should we not > provide the ability for the user agent to override the drawing in > some way? > We may have to expose the blink rate. I think it would be hard for the UA to properly handle the blinking, because in general content may overlap the caret, but canvas has no data model other than a bitmap. For carets in native controls, the UA has to ensure that overlayed content is drawn over the caret, but in the canvas case, it would be the responsibility of the Web content. > > Third, what I and others are struggling with is canDrawCustom on > drawFocusRing(): > > "If the canDrawCustom argument is true, then the focus ring is only > drawn if the user has configured his system to draw focus rings in a > particular manner. (For example, high contrast focus rings.)" > > This does not make sense. The parameter, my name, indicates that the > author can draw a custom focus rectangle. It would make more sense > to say that the focus ring is drawn, by the user agent, only if the > user has configured the system to draw focus rings in a particular > matter. ... meaning the user has configured the desktop to draw > focus rings in a standard way and the author should not override > that. Do you agree? > canDrawCustom is a bit of a funny name. I believe the intent of the parameter is as follows: - If canDrawCustom is false or omitted, the UA takes care of drawing the focus ring, no matter what. This is the simplest form of the call to use. - If canDrawCustom is true, then the Web application is indicating its intent to draw the focus ring in a custom way; but if the UA would draw focus rings in a way that respects a special accessibility setting, such as high contrast, then it still does the drawing. The Web application can tell whether it should do its custom focus ring drawing from the return value. So canDrawCustom really means something like wantToDrawCustomUnlessSpecialFocusRingSettingIsInEffect, but that's a bit verbose. Perhaps there is a different good short name for the parameter. Regards, Maciej
Received on Thursday, 11 March 2010 17:38:07 UTC