W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Change proposal for ISSUE-74 and ISSUE-105

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 29 Jul 2010 07:30:16 +0000 (UTC)
To: public-html@w3.org
Message-ID: <Pine.LNX.4.64.1007290704050.3056@ps20323.dreamhostps.com>

(Chairs: It's not clear to me what problems issues 74 and 105 have been 
raised to deal with; I hope this is an appropriate change proposal for 
them. If it is not, please let me know what the actual topic of those 
issues is so that I can reconsider them.)


SUMMARY

Explain how to avoid the performance problem of redrawing the focus ring 
with each movement of the text entry caret.


RATIONALE

The spec, as written, does not explain how to use the drawFocusRing() API 
to provide accessible tools with information regarding the current caret 
position without causing the whole focus ring to be repainted with each 
movement of the caret.

A naive use of this API would therefore result in the entire control being 
repainted for every edit or caret movement. This is a performance 
nightmare -- you might end up having to repaint everything behind the 
control as well as the control itself.

To avoid this problem, the specification should recommend the use of a 
clip region and an opaque text field background. By clipping out 
everything but the inside of the text field, the focus ring will not need 
to actually be painted. This allows browsers to optimise away the graphics 
calls to render the focus ring, while still allowing authors to use a 
simple API to make their tools accessible, even if they do not realise 
that that is what they are doing.

The specification should probably also discourage the use of <canvas> for 
text editing.


DETAILS

Add a note such as the following after the domintro box for drawFocusRing:

  Note: It is generally ill-advised to use canvas to implement text fields 
  -- authors are encouraged to use input elements or, in highly graphical 
  situations, interactive SVG. However, if canvas is indeed used to render 
  a text field, then authors are encouraged to make use of the clip() 
  method to create a clipping region representing the inside of the text 
  field while updating the text field's text and the caret position. This 
  allows user agents to optimise the rendering of these updates to only 
  include the actual text field, rather than having to repaint the entire 
  focus ring with each move of the caret.


IMPACT

POSITIVE EFFECTS
Improves performance of authors using drawFocusRing() for text fields, 
which in turn increases the likelihood that authors will use it rather 
than avoid it for performance reasons, which in turn improves real-world 
accessibility of the Web.

NEGATIVE EFFECTS
Might encourage the use of <canvas> for text fields, which would be a step 
backwards for the Web as a whole, in terms of usability and accessibility.

CONFORMANCE CLASS CHANGES
None.

RISKS
See Negative Effects.


-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 29 July 2010 07:30:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:19 UTC