20:00:43 <RRSAgent> RRSAgent has joined #html-a11y
20:00:43 <RRSAgent> logging to http://www.w3.org/2010/11/22-html-a11y-irc
20:00:45 <trackbot> RRSAgent, make logs world
20:00:47 <trackbot> Zakim, this will be 2119
20:00:47 <Zakim> ok, trackbot; I see WAI_PFWG(A11Y)3:00PM scheduled to start now
20:00:48 <trackbot> Meeting: HTML Accessibility Task Force Teleconference
20:00:48 <trackbot> Date: 22 November 2010
20:00:48 <Downchuck> Downchuck has joined #html-a11y
20:00:54 <richardschwerdtfe> chair: Rich
20:01:32 <richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Subteam
20:01:58 <oedipus> scribe: Gregory_Rosmaita
20:02:01 <oedipus> scribenick: oedipus
20:02:59 <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html
20:03:01 <oedipus> agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0179.html
20:03:10 <oedipus> zakim, who is here?
20:03:10 <Zakim> apparently WAI_PFWG(HTML TF)11:00AM has ended, oedipus
20:03:11 <Zakim> On IRC I see Downchuck, RRSAgent, oedipus, richardschwerdtfe, davidb, MichaelC, Zakim, sideshow, trackbot
20:04:49 <oedipus_> oedipus_ has joined #html-a11y
20:06:39 <oedipus> zakim, who is here?
20:06:39 <Zakim> apparently WAI_PFWG(HTML TF)11:00AM has ended, oedipus
20:06:40 <Zakim> On IRC I see oedipus, Downchuck, RRSAgent, richardschwerdtfe, davidb, MichaelC, Zakim, sideshow, trackbot
20:07:58 <oedipus> no minutes at http://www.w3.org/2010/11/22-html-a11y-minutes.html
20:08:38 <oedipus> CP: second kind of canvas bvehavior used by webkit -- get.ps.canvas.conent -- slightly different semantics, but only implemented by webkit
20:08:47 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:08:52 <Downchuck> getCSSCanvasContext
20:08:55 <Downchuck> http://webkit.org/blog/176/css-canvas-drawing/
20:08:56 <oedipus> RS: for zooming detection?
20:09:11 <oedipus> CP: yes -- canvas should work as is now -- need metrics to know resolution
20:09:22 <oedipus> CP: css canvas drawing makes sense to have drawing manager
20:10:01 <oedipus> CP: set backing to meet resolution when canvas element created -- that would create a lot of overhead authors would have to work around, but if use get.css.canvas.conent, can do
20:10:13 <oedipus> RS: applies only to CSS?
20:10:49 <oedipus> CP: CSS canvas has semantic relationship with rendering -- doesn't change my proposal, but interesting idea
20:11:15 <oedipus> RS: CP's proposal is "if get metrics, can get dpi" -- MS exposing everything on right track has been argued
20:11:32 <oedipus> present: Rich, Gregory, Charles
20:11:39 <oedipus> regrets: Frank_Oliver
20:11:45 <oedipus> regrets: David_Bolter
20:11:53 <oedipus> agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0179.html
20:12:07 <oedipus> TOPIC: Defects (Bugs) Logged
20:12:13 <oedipus> RS: satisfied
20:12:17 <Downchuck> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029091.html
20:12:19 <oedipus> CP: pretty happy with them
20:12:31 <Downchuck> Robert O'Callahan proposal for CSS based backing store on a canvas
20:12:32 <oedipus> RS: haven't heard from FO, but for now consider nothing new
20:12:54 <oedipus> RS: CP, could you edit current canvas 2d api modifications document
20:13:00 <oedipus> CP: yes, needs a bit of tidying up
20:13:46 <oedipus> RS: for drawing FocusRing, way set up now, diff from HTML5, is to draw FocusRing based on current drawing path have today -- if OS has high-contrast mode, should draw in its place so can ensure when made call, actually happened and mapped to a11y API and UA
20:14:24 <oedipus> CP: don't see problems with that as long as realize have to use the x stems can work with strangely shaped paths -- UA can decide what path -- works
20:14:42 <oedipus> RS: if read spec, magnifier, based on type of object will deterimine how want centered
20:15:04 <Downchuck> extents
20:15:17 <oedipus> RS: problem with hixie's proposal -- provide x and y coordinates assuming author knows (should be up to magnifier) - FocusRing separate from caret and selection
20:15:36 <oedipus> RS: want to ensure this is understandable
20:15:45 <oedipus> CP: 2 separate things caret tracking and focusRing
20:16:05 <oedipus> RS: CP will review; FO and DB will review what CP produces
20:16:15 <oedipus> TOPIC: Non-RTE Canvas Scenarios
20:16:51 <oedipus> RS: made valid point about only checking hit test on checkbox image and not the entire checkbox input element -- take code and replace hixie's broken code
20:16:58 <oedipus> RS: going to look deeply into RTE
20:17:13 <oedipus> RS: is there basic code for RTE that we can work off of?
20:17:22 <silvia> silvia has joined #html-a11y
20:17:46 <oedipus> CP: code bass designed from ground up to match implementation standard -- doesn't use DOM nodes in shadow DOM, which is needed to get it working
20:18:00 <oedipus> CP: complex because getting mouse coords and mapping to text is quite a bit of work
20:18:07 <oedipus> RS: why i didn't want to start from scratch
20:18:39 <oedipus> CP: need stylable select elments was beginning, built up DOM, when got to input type="text" realized a whole lot of other issues -- do need a large library to do RTE
20:18:52 <oedipus> RS: what licensing?
20:18:58 <oedipus> CP: CC 0 public domain
20:19:04 <oedipus> CP: 100% clear
20:19:27 <Downchuck> http://creativecommons.org/publicdomain/zero/1.0/
20:19:29 <oedipus> RS: if you could provide me a link and the liscense (creative commons zero) -- am U.S. citizen, so can do public domain
20:20:09 <Downchuck> http://w115.visc.us/html/textbox.html
20:21:07 <oedipus> CP: "dual lisence" by explicitly stating is "public domain" -- CC0 is for those where public domain doesn't apply -- if make changes, need branch or fork
20:22:02 <oedipus> CP: at bottom of demo, used pseudo CSS -- need to observe in relation to line breaks (for braille interfaces -- could be done with unicode) -- CSS generated text easiest way to mark changes in content -- generating style and injecting image
20:22:12 <oedipus> RS: put a line break in actual content, or CSS-wrapping
20:22:37 <oedipus> CP: can put line break, but :psuedo CSS method of inserting content directly -- unicode and existing HTML semantics should work fine
20:23:24 <oedipus> CP: CSS content spec is on the right path
20:24:34 <oedipus> agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html
20:24:50 <oedipus> http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html
20:25:05 <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html
20:25:41 <oedipus> http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html works in IE -- GJR try out with JAWS and IE9
20:25:43 <oedipus> GJR: will do
20:26:01 <oedipus> RS: set selection from contenteditable areas -- how to do across browsers
20:26:16 <oedipus> RS: FO supposed to have API differences for what they've done for IE
20:26:20 <oedipus> CP: anything public?
20:26:36 <oedipus> RS: windows.selection -- works on contenteditable areas -- trying to ascertain what for caret
20:26:47 <oedipus> RS: in FF, have collapse propert
20:26:53 <oedipus> s/propert/property/
20:27:16 <oedipus> CP: found similar in chrome -- empty range but different property -- in extentions api despite lack of caret browsing in Chrome
20:28:25 <oedipus> CP: if implemented, ranges will work for grammar and spelling areas -- how to implement is more difficult -- want to set up range, then get more ranges from it for a spell or grammar chacker -- might just attach to a single element for ease of use -- get.Element on current DIV get.Element.grammarranges
20:28:35 <oedipus> CP: don't want to do on multiple ranges at once
20:28:38 <oedipus> RS: API for that?
20:29:13 <oedipus> CP: not for spell checking -- range apis fairly well known and implemented to standard, including caret position, albeit in a weird way -- caret position another range with additional properties
20:29:21 <oedipus> RS: selection, then collapse?
20:29:41 <oedipus> RS: Chrome and FF try to keep same thing -- get window.selection return a range -- when have caret, is collapsed
20:29:59 <oedipus> CP: want to get properties -- if fire a select, may collapse inadvertently
20:30:25 <oedipus> RS: window selection, range X, select from 0, if range X is collapsed, is caret
20:30:36 <oedipus> RS: don't know what happens in IE -- have to find out from FrankO
20:30:40 <oedipus> CP: textareas?
20:31:38 <oedipus> CP: spelling and get.range on spelling -- get all spelling ranges inside a single element -- less straightforward is get me all spelling errors in all ranges -- add to collection of ranges  prototype, and spit out antother collection of ranges -- mozilla did work on allowing multiple ranges being chosen at same time
20:31:56 <oedipus> RS: going to investigate code; CP please review what i have for caret
20:32:18 <oedipus> RS: updating code very important -- don't know what browser hixie's code works in, but didn't work in IE or FF for me
20:32:43 <oedipus> CP: label might be reason to put out as survey item -- who is implementing label correctly?
20:35:31 <oedipus> TOPIC: WHAT WG Feedback
20:35:46 <oedipus> CP: brought up baseline and zoom issues -- have mozilla talking to me about zoom use case -- 
20:36:01 <oedipus> CP: a lot of feedback has been "this isn't a valid use case"
20:36:31 <oedipus> CP: no response on baseline issue -- need to know baseline so can get text on same baseline when in 2 diff font sizes
20:37:15 <oedipus> CP: getting some traction on ideas from mozilla
20:37:50 <oedipus> RS: glad MS has keyboard nav into sub-tree -- first time been able to do example with shadow DOM -- that is a BIG plus
20:38:15 <oedipus> GJR: will check out with IE9 and JAWS 12
20:38:30 <oedipus> RS: need to look at caret tracking in TEXTAREAs
20:39:00 <oedipus> CP: did a lot of work on caret tracking a while ago -- IE6 did not have way to do that -- would tell what was highlighted, but not where it was -- fixed since ranges implemented
20:39:12 <oedipus> CP: allowable element -- is shadow DOM outside or inside of the DOM?
20:39:20 <oedipus> RS: part of DOM -- just treat as shadow DOM
20:39:50 <oedipus> CP: items that need to be initialized such as script src= need to go through process -- if embedded inside CANVAS shouldn't be initialized unless CANVAS isn't supported
20:40:07 <oedipus> CP: explicitly say items that need initializtion should not be initialized, should be ok
20:40:37 <oedipus> CP: if add SCRIPT to shadow dom, will initialize, before scripting happens, should create SCRIPT in DOM but not initialize it
20:40:44 <oedipus> CP: "activated content" is the key term
20:40:58 <oedipus> RS: if canvas isn't supported, UA has to fall back to fallback content
20:41:05 <oedipus> RS: what if stick IFrame in middle of CANVAS?
20:41:36 <oedipus> CP: would make sense that IFrame available in DOM, but src="foo" bit doesn't load so IFrame would be empty
20:42:11 <oedipus> CP: keep existing semantics in place and work with actual language -- can have IFrame inside shadow DOM, not going to do anything unless use scr= for scripting
20:42:17 <oedipus> RS: target on scriptiong side?
20:42:19 <oedipus> CP: yes
20:42:24 <oedipus> RS: require spec change?
20:42:51 <oedipus> CP: do need to state how IFRAME is handled in shadow-DOM -- hopefully we just need an explicit statement of that rather than reengineering
20:43:01 <oedipus> RS: haven't seen any comments from hixie on defects on canvas
20:43:42 <oedipus> RS: have code to test -- now need to ascertain support
20:44:40 <oedipus> CP: 1 comment: there is a complexity introduced by separating canvas 2d context from canvas element -- basic ammount of implementation that needs to be in any canvas content -- shadow DOM itself is to be found in CANVAS tag, not canvas context -- wasn't sure if that was clear
20:45:02 <oedipus> CP: sub-DOM itself should be addition to canvas element -- should work same for 2d and 3d conext
20:45:07 <oedipus> s/conext/context/
20:45:21 <oedipus> RS: 1-to-1 mapping for elements in DOM to what is seen on visual canvas
20:46:02 <oedipus> CP: want to add to that -- elements inside CANVAS sub-tree do not get initialized in browser mode -- script still available via DOM, just not loaded on window.load -- want to ensure based on actual reality
20:46:16 <oedipus> RS: work on that?
20:46:26 <oedipus> CP: yes -- work on canvas element wording
20:46:37 <oedipus> RS: so another change proposal for canvas?
20:46:38 <oedipus> CP: yes
20:46:59 <oedipus> [adjourned]
20:47:40 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:48:20 <oedipus> regrets+ Frank_Oliver
20:48:25 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:49:18 <oedipus> s/get.ps.canvas.conent/getCSSCanvasContext/G
20:49:49 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:50:28 <oedipus> s/no minutes at/minutes will be logged to:/
20:51:11 <oedipus> s/x stems/extents/
20:51:15 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:52:54 <oedipus> meeting+ CANVAS Accessibility Sub-Team
20:52:55 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:54:08 <oedipus> i/second kind of canvas/TOPIC: Current CANVAS Issues/
20:54:10 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/22-html-a11y-minutes.html oedipus
20:57:55 <oedipus> zakim, please part
20:57:55 <Zakim> Zakim has left #html-a11y
21:05:18 <RRSAgent> I see no action items