Re: Draft Revisions to Canvas 2D Context API to drive magnification

Richard Schwerdtfeger wrote:

> It would be good to have either you or James on the canvas api call Monday. 

Unfortunately, I have a conflict that will prevent me from attending.

> James Craig wrote:
> 
>> Initial feedback for the proposed methods:
>> 
>> 1. The focus ring should be a set of coordinates or a shape rather than a single xy coordinate. At a minimum, it should be rect(x1, y1, x2, y2), but it'd be better to use a standard shape as the parameter, e.g. line, rectangle, ellipse, or polygon... Poly would allow not only non-standard shapes, but would also provide an easy way to implement focus rings for UI elements that appear skewed or rotated.
> 
> 1. The reason I chose only an x, y position is we felt the rectangle could be determined from the associated object. That said, I can see why a polygon would be more powerful. 

The bounds could be determined automatically if only a single point were provided. That said, the size and shape of the associated shadow DOM object may not be the same as the canvas representation of the UI element, so the parameter should leave the option for a point or a shape.

> Frank, David, Alex, Are you on board with supporting a polygon? Essentially I would supply a collection of vertices for which would cover the polyline. We would then need to convert that to the objects bounding rectangle in the accessibility API. 

Any standard shape should be accepted, not just polygons. Most common will probably be rect() and poly()…

>> 2. Caret position should likewise have more than one coordinate or shape(s), especially since I assume this is intended to work for both selection ranges as well as unselected caret position. 
> 
> 2. Caret position - This is solely for magnifier tracking. So, ...
> 
> - You only need to follow the last point of regard position. You can't have a magnifier magnify in two places. So, why do want to specify ranges. I think this unnecessarily complicates the problem.

If the user's zoom level can display the entire selection, it probably should. Most common usage will still be a single caret position, but there should be an option for authors to specify the size, shape, and location of the entire selection range. Also, a single point does not indicate font-size/line-height on the canvas representation of the control. Without the additional information, for example, a magnifier may only display the top-half of the text or line-box on the canvas.

>> Perhaps a some optional parameters such as cursor type (I-beam, block, etc.), orientation (vertical, horizontal LTR, horizontal RTL), and maybe language/locale (Are there any language- or locale-specific cursors? I don't know.)
> 
> - Why does it matter what type of cursor is drawn? Were you looking for some additional functionality to drive a screen reader? This would be a new requirement. Also, we are not asking the system to draw cursor and the canvas 2D context API does not have an API for configuring the cursor which leads me to believe this is handled outside the canvas API and can be processed by normal accessibility API mapping by the browser. I would want to hear from Microsoft to see if this is something that they also want this for Windows. Mac and Windows are different and I am not sure we can get a matching set of system caret/selection types. I am thinking we could do without this functionality. 

That suggestion was intended for discussion and I'm willing to drop it if it's deemed unnecessary. Hence the words, 'perhaps', 'optional', and 'maybe'… 

Cheers,
James

Received on Monday, 24 May 2010 05:54:41 UTC