- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Mon, 22 Nov 2010 21:07:50 +0000
- To: public-canvas-api@w3.org, public-html-a11y@w3.org, franko@microsoft.com, Charles Pritchard <chuck@jumis.com>
aloha! minutes from the 22 november 2010 meeting of the canvas sub-team of the HTML5 a11y task force can be accessed as hypertext at: http://www.w3.org/2010/11/22-html-a11y-minutes.html as an IRC log at: http://www.w3.org/2010/11/22-html-a11y-irc and as plain text following this announcement -- as usual, please report any errors, clarifications, omissions, and the like by replying-to this announcement on-list... canvas sub-team members are asked to review RichardS' "Reworked Canvas 2D API using our revised DrawFocusRing" proposal, available at: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html the cover emessage for which can be found at: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0035.html _________________________________________________________ - DRAFT - HTML Accessibility Task Force Teleconference 22 Nov 2010 Agenda http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html See also: IRC log - http://www.w3.org/2010/11/22-html-a11y-irc Attendees Present Rich, Gregory, Charles Regrets David_Bolter, Frank_Oliver Chair Rich Scribe Gregory_Rosmaita Contents * Topics 1. Current CANVAS Issues 2. Defects (Bugs) Logged 3. Non-RTE Canvas Scenarios 4. WHAT WG Feedback * Summary of Action Items _________________________________________________________ <trackbot> Date: 22 November 2010 <richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Subteam <scribe> scribe: Gregory_Rosmaita <scribe> scribenick: oedipus <richardschwerdtfe> agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html minutes will be logged to: http://www.w3.org/2010/11/22-html-a11y-minutes.html Current CANVAS Issues CP: second kind of canvas bvehavior used by webkit -- getCSSCanvasContext -- slightly different semantics, but only implemented by webkit <Downchuck> getCSSCanvasContext <Downchuck> http://webkit.org/blog/176/css-canvas-drawing/ RS: for zooming detection? CP: yes -- canvas should work as is now -- need metrics to know resolution ... css canvas drawing makes sense to have drawing manager ... 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 RS: applies only to CSS? CP: CSS canvas has semantic relationship with rendering -- doesn't change my proposal, but interesting idea RS: CP's proposal is "if get metrics, can get dpi" -- MS exposing everything on right track has been argued Defects (Bugs) Logged RS: satisfied <Downchuck> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029091.html CP: pretty happy with them <Downchuck> Robert O'Callahan proposal for CSS based backing store on a canvas RS: haven't heard from FO, but for now consider nothing new ... CP, could you edit current canvas 2d api modifications document CP: yes, needs a bit of tidying up 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 CP: don't see problems with that as long as realize have to use the extents can work with strangely shaped paths -- UA can decide what path -- works RS: if read spec, magnifier, based on type of object will deterimine how want centered <Downchuck> extents 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 ... want to ensure this is understandable CP: 2 separate things caret tracking and focusRing RS: CP will review; FO and DB will review what CP produces Non-RTE Canvas Scenarios 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 ... going to look deeply into RTE ... is there basic code for RTE that we can work off of? 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 ... complex because getting mouse coords and mapping to text is quite a bit of work RS: why i didn't want to start from scratch 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 RS: what licensing? CP: CC 0 public domain ... 100% clear <Downchuck> http://creativecommons.org/publicdomain/zero/1.0/ RS: if you could provide me a link and the liscense (creative commons zero) -- am U.S. citizen, so can do public domain <Downchuck> http://w115.visc.us/html/textbox.html 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 ... 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 RS: put a line break in actual content, or CSS-wrapping CP: can put line break, but :psuedo CSS method of inserting content directly -- unicode and existing HTML semantics should work fine ... CSS content spec is on the right path <scribe> agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html works in IE -- GJR try out with JAWS and IE9 GJR: will do RS: set selection from contenteditable areas -- how to do across browsers ... FO supposed to have API differences for what they've done for IE CP: anything public? RS: windows.selection -- works on contenteditable areas -- trying to ascertain what for caret ... in FF, have collapse property CP: found similar in chrome -- empty range but different property -- in extentions api despite lack of caret browsing in Chrome ... 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 ... don't want to do on multiple ranges at once RS: API for that? 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 RS: selection, then collapse? ... Chrome and FF try to keep same thing -- get window.selection return a range -- when have caret, is collapsed CP: want to get properties -- if fire a select, may collapse inadvertently RS: window selection, range X, select from 0, if range X is collapsed, is caret ... don't know what happens in IE -- have to find out from FrankO CP: textareas? ... 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 RS: going to investigate code; CP please review what i have for caret ... updating code very important -- don't know what browser hixie's code works in, but didn't work in IE or FF for me CP: label might be reason to put out as survey item -- who is implementing label correctly? WHAT WG Feedback CP: brought up baseline and zoom issues -- have mozilla talking to me about zoom use case -- ... a lot of feedback has been "this isn't a valid use case" ... no response on baseline issue -- need to know baseline so can get text on same baseline when in 2 diff font sizes ... getting some traction on ideas from mozilla RS: glad MS has keyboard nav into sub-tree -- first time been able to do example with shadow DOM -- that is a BIG plus GJR: will check out with IE9 and JAWS 12 RS: need to look at caret tracking in TEXTAREAs 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 ... allowable element -- is shadow DOM outside or inside of the DOM? RS: part of DOM -- just treat as shadow DOM 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 ... explicitly say items that need initializtion should not be initialized, should be ok ... if add SCRIPT to shadow dom, will initialize, before scripting happens, should create SCRIPT in DOM but not initialize it ... "activated content" is the key term RS: if canvas isn't supported, UA has to fall back to fallback content ... what if stick IFrame in middle of CANVAS? CP: would make sense that IFrame available in DOM, but src="foo" bit doesn't load so IFrame would be empty ... 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 RS: target on scriptiong side? CP: yes RS: require spec change? CP: do need to state how IFRAME is handled in shadow-DOM -- hopefully we just need an explicit statement of that rather than reengineering RS: haven't seen any comments from hixie on defects on canvas ... have code to test -- now need to ascertain support 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 ... sub-DOM itself should be addition to canvas element -- should work same for 2d and 3d context RS: 1-to-1 mapping for elements in DOM to what is seen on visual canvas 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 RS: work on that? CP: yes -- work on canvas element wording RS: so another change proposal for canvas? CP: yes [adjourned] Summary of Action Items [End of minutes] _________________________________________________________
Received on Monday, 22 November 2010 21:09:57 UTC