<trackbot> Date: 17 January 2011

<richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Subteam

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0016.html

give me sec

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0016.html

we don't seem to have a scribe

<Downchuck> I'm not aware of the system, I can write notes, but don't know how to speak to the bot

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0016/HTML_Canvas_2DContext120910.html

RS: we'll discuss basics today, and RTE another time.

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0016/HTML_Canvas_2DContext120910.html

RS: selection management is simply tracking what the user is operating on
... the api section, section 1, we've highlighted the changes for drawfocus ring, it takes an element, function for getting blink rate, and set caret selection rect
... so whoever is doing the caret can get the platform blink rate
... on a mac you can have a separate caret and selection

F: do you need the caret for non text editing situations

CP: we use it that way in our image editor

(discussion of windows platform setcaretpo and magnifiers)

CP: the concept of the baseline in text metrics is to return the baseline... a baseline is essentially where the font is aligned to vertically. we need it to work with mixed font sizes... gives us a vertical offset.

<Downchuck> https://developer.mozilla.org/en/drawing_text_using_a_canvas

DB: i'm not the one to give you good feedback on this area

RS: section 11 Caret and selection management

F: re drawfocusring... it takes an element from the fallback accessible dom right? how do i calc width and height on that element.

(we are back to section 10)

RS: one of the comments we got back - (possibly James Graham) - the rect needs to be based on the drawing path, you can compute the bounding rect, so you don't need to actually pass those as params.

F: how do we assoc element with canvas subtree draw path

RS: you call drawfocusring and you take the drawing path and compute the bounding rect, the element has an associated object, you would load the bounding rectangle around the object...

DB: suppose you tab to an element

RS: element recieves focus, author calls drawfocusring, to go in to draw the bounding rectangle, and set the dimensions of that object.

DB: as a gecko dev how do i supply the API size and screen coordinate info for the element

F: a few things... one is some user agents just report 0,0... you could take width and height of the parent container (canvas) and repot that through... these are not too useful, the other thing that is more natural, for that element that is now in the DOM, set the top,left,width,and height for it (the web page author sets this).

DB: I like the latter

(reusing dom element attributes)

F: for non-text editing controls, the focus ring is how the screen mag determines how it should pan to.

DB: who draws the focus ring (what code is running?)

RS: some OSes will want to have the focus ring drawn a certain way (e.g. high contrast), we are providing a drawing path, either the OS will draw it or the path will be drawn based on the settings for drawing ...
... under the covers, in addition to actually doing the drawing the path, the user agent will compute the bounding rectangle, and call desktop API or expose through desktop API
... please review the user agent algorithm

DB: do curved lines form a closed path?

(discussion)

CP: typically if the path is not closed it will automatically close to the origin

DB: ok
... not sure about using element in terms of focus ring style
... I would say may/should (not must)
... I'd like to leave the door open to improvement

F: I would go for 'should' as well

CP: perhaps is should be a param

(discussion about who draws the focus ring)

group agrees on "should"

RS: section 11, Caret and selection management
... this says here is the element, the x, y, width and height, the user agent is responsible for maintaining that position relative to the canvas.

F: so on the IE side, we don't currently support this change at this time. We want to push the authors to not do text editing in canvas. it is a large area, and not sure we can do a good solution in this way. MS will be pushing anyone here to not enable a scenario for text entry inside a canvas element.
... the idea of trying to map a large number of attributes through the canvas element seems to be frought with peril.

RS: I can see why RTE would be a problem.

CP: right now we do have an editor that uses canvas to display text, and right now laying a div contenteditable over it... there is shifting... padding... it has made it difficult, perhaps not impossible but difficult.
... looking at the caret pos, it doesn't have to be text editing...
... we'd like to be able to have a caret in our canvas based UIs
... I understand the initial reaction to RTE
... caret position is not necessarily RTE

F: what is the non-text editing use case?

CP: it is simlar to drawfocusring, essentially it is a caret.

F: what is expectation if i turn on caret browesing and i move my caret into the fallback dom, what should web dev do in that scenario?

CP: should draw focusring... and should draw a caret (maybe[?])

F: what happens if you select text inside and outside of the canvas element, there is diff between who draws, and who controls

DB: (via IRC) Downchuck, how close can you get via the overlaid contenteditable and should we focus efforts there?

F: [describes hairy issues with caret]
... whatever can happen on an element that has a visual response, there should be someway to map that through to canvas.
... (in context of say dragging mouse)
... or scenario, in caret browsing mode, you can go into any part of the dom, what happens if you enter the part of the dom under the canvas? what is the expectation for well behaved browser and well behaved author.

<Downchuck> afaik caret browsing mode is not exposed. Is it, as a range?

RS: this is going to be an issue (mouse or keyboard), you are going to have to know where that position is of the caret, while you are selecting the underlying dom .. author have to solve.
... you wouldn't be able to select content within the canvas...

F: I don't think author is aware of selection events

DB: via IRC, I support evangelizing against using canvas for text editing

CP: I'm willing to come up with non-text use cases

(DB and CP discuss alt approaches)

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: davidb
Inferring Scribes: davidb

WARNING: No "Topic:" lines found.

Default Present: Rich, Chuck_Pritchard, David_Bolter, Frank
Present: Rich Chuck_Pritchard David_Bolter Frank
Found Date: 17 Jan 2011
Guessing minutes URL: http://www.w3.org/2011/01/17-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report