RE: Issue 131 Change Proposal

Re multiline:
Multiline is where we have a mismatch between what is possible in the subdom and what is possible in the canvas rendering. 
Canvas fillText/strokeText only draw a single line of text, with no word wrap (The web has several examples of how to do word wrap via measureText; see http://stackoverflow.com/questions/4478742/html5-canvas-can-i-somehow-use-linefeeds-in-filltext )
In an multiline case, the author would have to do manual word wrapping and create a subdom element for each line of text. 

Re text cursor/selection position:
Keeping the subdom and canvas in sync is not hard; see the attached quick-and-dirty proof of concept. If the canvas text and the subdom element are at the position and size, the user agent can draw the cursor and selection.

(In the proof of concept, the subdom element is the first line of text; the canvas rendering is the second line of text. Selection is kept in sync between the two; The caret in caret browsing is kept in sync. I draw the selection/caret manually to illustrate the concept.)


-----Original Message-----
From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis@googlemail.com] 
Sent: Sunday, February 12, 2012 2:30 AM
To: Frank Olivier
Cc: public-html@w3.org; public-html-a11y@w3.org
Subject: Re: Issue 131 Change Proposal

On Fri, Feb 10, 2012 at 9:10 PM, Frank Olivier <Frank.Olivier@microsoft.com> wrote:
> I would like to submit http://www.w3.org/wiki/Reading_text_in_canvas 
> as a change proposal for this issue.

How does this proposal address screen magnifier content focus for multi-line spans of text?

Also, the proposed spec text says:

"User agents that support caret browsing can use the subdom text cursor position to indicate the current caret location on the screen."

How is that supposed to happen?

--
Benjamin Hawkes-Lewis