See also: IRC Log
trackbot, start meeting
<trackbot> Date: 31 March 2014
<scribe> Meeting: Canvas Accessibility Sub-Group Teleconference
<scribe> Scribe: MarkS
JM: Pixels to Path work is complete.
... I took out ID but based on discussion, I put that back in as required.
... I need feedback on the interface for accessing hit regions and hit regions list
-> http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0191.html hit region list interface
JM: on hitRegionList, to access items, we don't currently know what the index will be. I added HitREgionOptions to accomplish that, but I'm not sure if that is going to work for implementers
... looking for feedback on that approach
RC: I'm not sure that we need this.
JMann: you can keep your own list in JS
JM: I put ID back in, I had taken it out, but I referenced Level 2 and saw that it was referenced in the WebIDL. I added it back but took out required
JMann: should we require ID or not? Last call, we said we shouldn't, waiting to hear from Rik on that.
... you can always use the ID of the control
RC: What if there is no control, like if you are drawing a dialog on top of an existing button.
JMann: so do we want to support the unbacked regions?
RC: one or the other, or both
JMann: so for Level 1, we won't support unbacked region but because we want to be forward compatible, we ...
RC: how will we remove an item, since that requires an ID
JMann: for Level 1, control is required.
... for Level 2, control will be optional
RC: it sounds like you won't be able to change that for Level 2
JMann: to be forward compatible with Level 2, we need to make control optional.
... which is how the spec has it.
RC: but they cannot both be absent
JM: correct, I suggested that in my email
... I will add that to the spec then to clarify
JS: Should look for precedent on how that should be written. One of them will be required,
JM: do we want to say the reverse is true? if there is no ID, you must have a control? I'll research that.
JS: we should at least have the concepts out, can perfect it later
JMann: to remove a hit region, ID is required.
RC: removing a control will also do that.
JM: in the WebIDL it says "remove hit regions(ID)" probably need to make that match
... and if we want to remove it, you need to specify an ID
JMann: Level 2 removeHitRegion take an ID. so it will match the spec text
RC: it will be a regression issue
<JatinderMann> http://www.w3.org/html/wg/drafts/2dcontext/master/#hit-regions
<JatinderMann> http://drafts.htmlwg.org/2dcontext/master/#2dcontext
JM: is that the nightly? I'm not seeing that. The WebIDL and the spec text both say they take multiple options
<JatinderMann> void removeHitRegion(DOMString id);
<jaymunro> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/
RC: we need to delete that branch or ask someone to turn it off. we want to make sure L1 and L2 match
JM: I'll see who I have to contact to fix that
-> http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0191.html exposing hit region list
MS: currently is no way to reference an item in the list if we don't know if it has an ID or a control
JM: if hitRegionList returned hitREgionOptions with the right one...
... we're only working with ID and control in L1
... what will we be using it for
RC: i think for now, we should leave it up to the author
JM: to track the list himself
RC: is someone strongly in favor of having a list?
JMann: This was raised by Jacob. You're right, the author can keep their own list.
... Jacob was concerned about being able to update existing items I think.
... we could have a getRegions that returns a list, or an attribute on which the list existed, but that could be overkill
... the downside is that if I'm not keeping track, and I add a bunch of regions, it could get difficult to manage.
... do we think its common to remove hit regions? like a use case in a game?
RS: yeah, sure. You might also be resizing something?
... I've seen canvas be used for flowcharts. dropping objects, resizing objects, etc. I can see someone doing that.
... would the author be more likely to reference them by control or ID
JMann: we give you the current path and the ID. can't change fill rule, can't change path,e tc. I wonder if this becomes more important in the L2 spec.
... currently, I can just remove and add a new one. you can remove by ID, or remove the control itself.
... then create a new one
... you can walk through the DOM and remove the controls to accomplish this.
RS: we talked about this in ARIA RE: Webcomponents. I would limit the number of ways you can reference things, at least for L1
JMann: Jacob raised this from an API design POV. IS there an advantage to exposing the list to developers. Probably not beyond the developer who can maintain his own list, or walk the DOM
... It may not be worth the additional complexity
JM: You were talking earlier about changing the hit region. wouldn't that just happen if you make a new path and assign the control to the new path. wouldn't that replace the old one?
RC: the other one would draw on top.
JM: If you create a new path, then call addHitRegion with an ID that was previously used, shouldn't it just replace the old one?
... If you don't redraw the canvas, the old path will still be there? ok.
JMann: talking to Jacob on this one. Wherever we say mouse event, we should say pointer event.
RS: are new pointer events implemented in all the browsers?
JMann: I know Chrome and IE or Apple and IE. not sure
RS: did we agree what events we wanted to support? focus? blur?
... mousein etc
... did we want to pass the pointer position through to the fallback element or the hit region.
JMann: looking t what we have now.
RC: it currently doesn't say which are supported
... it doesn't say anything about that
... it inherits behavior from HTML
RS: does the canvas element handle all of this? do we need all the mouse events?
JM: looking at WHAT WG spec, their pointer events look more like our Level 2. more specific pointer event support.
RC: yes, they have made a lot of changes there. It seems unclear what it is doing. Seems like they are adding support for WebApps or something
... waht should happen when you click on a hyperlink (fallback content) for instance
... we could send the events to the canvas element, which would still be forwards compatible.
RS: do you have to do all the hit testing yourself?
RC: no, but the author would write the code to handle certain mouse events or pass it through to the fallback
... just standard event handling.
... with the ID of the hit region
... this is the ID of the hit region.
RS: would need to reference the control by ID too
JM: seems like having a standard interface to do this (ref by ID) is ideal. Argument for making ID required.
RS: the only thing that worries me about ID, in ARIA we talked about using query-selectors to reference stuff in shadow dom
... worry about limiting this to just ID
RC: if we say an ID is not required, you just wouldn't get the event handling, still get accessibility
RS: I think it would be better to just focus on the hit testing behavior rather than how to reference elements in case we want to change that in the future
RC: seems like a big change
RS: I think managing the list of hit regions, with everything in 2.0 might be better to just focus on the dispatching.
RC: that is the hardest part
RS: isn't there a javascript dispatch event that you can use to retarget it?
RC: harder from the UA perspective. easy from JS. lots of special case handling
JMann: I wanted to hear from implementers about whether or not this would be a difficult approach, bad for performance, etc.
RC: It seems like its easy until you have to do event retargeting.
... may be an issue when things scale to hundreds of hit regions.
... if the browser doesn't manage it, the author does.
JMann: so today, a listener on the fallback will not get the event.
RS: the authors need to supply an ID if they want to control that.
... I would use the same ID i used in the fallback content to make it easier.
JMann: seems like we should add that ability.
MS: how about if we specify that if you specify the control's ID but not the hit regions' ID, the hit regions automatically gets the same ID as the fallback element?
RS: not a bad idea
RESOLUTION: canvas element will handle event handling from the hit testing, and will not handle dispatching the event.
RS: what about remove a node? in terms of hit region management.
JM: if you set the control('s ID) and that was duplicated in the ID of the hit regions. Why would you need both?
RS: wouldn't if you could guarantee they were the same
JMann: why not just require the controls's ID
... right now they have to control the mapping
RS: any compatibility issues when we go to L2
... may also have to reference things by selectors.
... i think webcomponents will affect this.
RC: should we wait until this is ready?
RS: imagine a web component in the fallback content of canvas...
JM: so hit region interfaces are being left out for now and we are not specifying whether ID or control are required or not until we work through this issue.
JS: we are going to get pressure from HTML WG on extra time for this
RS: I think we are making great progress and are almost done here.
RC: may be we should add an API to clear all hit regions.
... add clearRect() back in
... its still in the WHAT WG spec
RS: lets add clearRect() back in. can do a clearRect() on the entire canvas to remove all the hit regions.
JM: its still in L2 that way
RC: its a little funky
RS: what about clearHitRegions()
RC: I like that
JM: OK, so we are going to add clearHitRegions, not clearRect and change mouse to pointer events
RC: I don't think we should do pointer event change just yet.
RS: we need to talk to other browsers to see if they are supporting pointer events yet.
JM: ID and control are still up in the air.
RS: I think we should leave it up to the author to manage ID's etc.