See also: IRC log
<trackbot> Date: 17 January 2011
<richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Subteam
give me sec
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
RS: we'll discuss basics today, and RTE another time.
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.
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?
CP: typically if the path is not closed it will automatically close to the origin
... 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
... 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
... 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
... 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[End of scribe.perl diagnostic output]