See also: IRC log
<MarkS> [18:01:33] -> http://www.w3.org/2014/03/17-html-a11y-minutes.html Minutes from last meeting
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#hit-regions
JM: I changed pixels to paths
MS: Jay you had some questions in an off-list email, did those get resolved?
JM: i wasn't sure if we should take the section on clearing regions, or reword it.
<JatinderMann> http://lists.w3.org/Archives/Public/public-html-a11y/2014Mar/0071.html
<JatinderMann> http://lists.w3.org/Archives/Public/public-html-a11y/2014Mar/0061.html
JMann: accessing regions by ID is clumsy, why not just reference by the associated element
... we can talk about his on list, get Rik's opinion. we won't need the dictionary if we just require the control and not the ID
... for level 1 spec purposed, the dictionary just has control and ID.
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#hit-regions
MS: will that cause any problems when L2 comes around?
JMann: yes it will. OK.
... perhaps we should continue using the dictionary.
... should also still question the requirement for ID
... it currently sounds like even control is optional
<JatinderMann> “If the control member is null or no such region currently exists, let previous region for the control be null.”
MS: i think that needs to be there for L2 when developers can create "virtual" fallback content and define aria roles states and properties directly in canvas code.
JMann: i only showed Jacob L1 spec
... in the context of L1, having control be optional doesn't a make sense
... if we build on this in L2, there is a potential compatibility issue.
... it sees like Jacob is finding things that don't make sense when you don't know that its there for L2
... want to hear Rik's opinion on why ID and control are optional
... the argument type (dictionary) isn't defined any where.
... i think its a simple oversight
... would want to add the dictionary in, with just control, but that is going to be awkward for developers.
... i think we should clarify the reason why we have only one item (control) in the dictionary.
... he also said there was no way to access the hit region. only add it, and remove it.
RS: that is bad.
JMann: i should be able to iterate through hit regions
... we could reference it by control.
RS: we don't have Path yet.
JMann: we could expose a list of hit regions.
RS: need a new method that allows us to access the list and add or remove items from it
JMann: what are the use cases. I would want to change the path of the hit region.
RS: if its by ID you could replace it. Just require that they have an ID in order...
JMann: jacob's feedback was that we should reference by control's id, not the id of the region.
... use the DOM id for the hit region.
... for L1 spec, we don't have path, fill rule, etc only a dictionary of one item. Do we need a dictionary, for only one item. but that is because of L2, which will require a dictionary.
RS: Explain it in a note that this will be expanded in L2.
JMann: it was interesting feedback from someone who only looked at the L1 spec.
... the other thing is that the spec says that you don't have to specify a control, why would control be optional?
MS: its for hixie's concept of unbacked regions
JMann: if we don't do label and role in L1, we have to make sure that control is required.
RS: I agree
... not sure unbacked region will go anywhere.
JMann: the spec should handle pointer events. inherit mouse events. Wherever we talk about a mouse event being fired, we should also talk about pointer events being fired. The next question is about touch events.
RS: what do we say about touch events in the HTML5 spec
JMann: there is no active work being done on touch events. I think they are deprecated for pointer events
RS: i think so
JMann: i think safari and chrome support touch events.
... it sounds like we're taking all of jacob's feedback, remove ID, make control required, we keep the dictionary, figure out a way to expose and iterate through hit regions and to add pointer events to the spec.
RS: Doug is saying that apple doesn't want it
JMann: lets start with pointer events. if we get feedback on touch events, we can deal with it then.
... it would get complicated if we supported touch events.
... I'll work with Jay to get these changes made.
... post to mailing list as well
JM: sounds like we will be adding new methods for exposing hit regions list.
JMann: will talk to jacob about how he envisioned that working.
... will follow up with him on that.
MS: will also have to file bugs on WHAT WG for these new methods.
JMann: and a bug on pointer events too
MS: I think we should propose spec text with rationale
JMann: I'm good with that.
JMann: we have good feedback. would love to hear dominic's take on these changes. make sure implementors are OK with changes.
JM: we will drop ID, we will change mouse to refer to mouse and pointer. and there is the method to access the hit region list.
JMann: have to go throughout he processing model, capture all processes for control.
... i think we can do this in a week. next week review changes.
... I'd rather get feedback early and change it. It's painful but good. I think it is looking good, hard to say until we get feedback from other implementers.
... is it good enough to add a getter method and then something to add and remove
... or an update method that handles it
... right now we can only link it to an element. what are the use cases. would we link it to a different element? add a path?
... I'll come up with something to propose.
MS: OK, so we will get feedback from dominic on list RE: changes proposed today and share L1 spec with changes already agreed upon for review. Once we have feedback from both dominic and ric it will be easier to establish a timeline.