IndieUI Task Force telecon -- 20 Jun 2012

<jcraig> scribe: jcraig

<scribe> agenda: Source Code Repository Update

Source Code Repository Update

mc: no progress from last week.

jc: needed to send proposal regarding branches or directories per version

<clown> last week's minute: http://www.w3.org/2012/06/13-indie-ui-minutes.html

Task Force Work Statement http://www.w3.org/WAI/IndieUI/IUITF

js: Are we done? Any more discussion needed?
... Otherwise, close discussion through email.

jc: changes were mainly about editors sending regrets

Recruiting Update

js: some participants may have schedule conflict. aus, asia
... any more updates from recruiting?

ab: forwarded to group: Rick Byers from google and sang moon(?) from Opera.
... also one person from mozilla via IRC has expressed interest

ds: any idea of number of people in EU?

ah: I'm in EU.

vg: I'm in France

ds: I suggest a poll once we get more participants.
... already have reps from apple, google, nokia, mozilla, opera, etc.

<clown> http://scottgonzalez.com/

clown: discussing with Joanie last week, and thought to invite too debs. I heard scott gonzalez (jQuery dev) was interested.

ds: Scott is in the same area as I am. Great idea to get him involved.

Need to identify tests editor

js: we have james craig as the spec editor; still need a tests editor.
... need at least by mid-stream, but the sooner the better.

ds: expectations for test driver:
... make sure there are clear testable assertions in spec, write tests themselves, drive conversation around testing, pester for deliverables, etc.

<Zakim> Joseph_Scheuhammer, you wanted to update on recruiting.

ds: make sure they don't give false positives or negatives, and incorporates any unsolicited tests submitted by group members or outside contributors, needs coordination skills

js: some of that is the wider group responsibility, but I agree that one should be directly responsible

Use Cases Wiki Update

js: thanks Doug (Art?) for getting the wiki started

rs: Does the person (Byers) from Google have access to the wiki?
... needs a W3C login.

mc: he is a member so he has access.

ab: I'll make sure Rick knows to add his own cases to the wiki.

<ArtB> ACTION: barstow make sure Rick Byers knows we want him to directly add his UCs to the UC wiki [recorded in http://www.w3.org/2012/06/20-indie-ui-minutes.html#action01]

Events Module & Use Cases from Apple -- James Craig

<clown> scribenick: clown

js: gives conch to jcraig

JC: been about two years since original proposal.

<jcraig> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

JC: started thinking about this with respect to ARIA
... partly due to the emphasis on key presses
... as outlined in the DHTML Style Guide.
... for key strokes for interacting with DHTML user interfaces
... doesn't scale well for a number of reasons
... different set of keystrokes compared to, say, what a screen reader user is used to.
... doesn't work for cases where there is no keyboard, such as a touch screen.
... don't want to put this on the author to put this information/control in.
... we thought that the way to do this is with DOM mutation events, but those are not consistently implemented in browsers.
... so, come up with events that correspond to user actions, and implement those.
... and these should be more performant than mutation events.

RS: when and where are these events directed at specific objects.
... with a keyboard, you have focus.
... how do we direct the input at the relevant UI object?

JC: if there are multiple scroll views on the page, which one gets the scroll event?
... that's up to the UA to figure out. For example, VoiceOver has an idea of where the user is directing their attention.
... if on a scroll view, then sent there, and it bubbles up.
... if no known focus, send the event to the body.

RS: on a touch device, can we assume that an element can have focus?

JC: the ability to determine the event and its target is the responsibiltiy of the OS and the UA.

RS: for the purpose of spec'ing these the events, can we leave the determination of the point-of-regard is left up to the platform.

JC: the POR can be determined at the time of regard.

aside 'POR' = 'point of regard'

JC: the heuristics will be in the UA.
... in voice command, give a name to apply the event to.

DS: is there a substantive different between the focus or POR?

RS: the point of regard (POR) is the location in the doc where you are operating.
... there is another level of granularity.
... focus is on the contariner and POR is within that.

DS: james has other examples.
... ?

RS: VoiceOver (the screen reader for iOS and OSX) has a way of setting the POR, or screen reader focus.

JC: and the keyboard focus might be differnt from the screen reader focus (POR).
... the POR can move indepedently of the keyboard focus.
... but usually, they are kept in sync.

DS: I reviewed some document that all sorts of focus defined.
... do they all come down to these two? POR and keyboard focus?

RS: yes, I think so.

DS: we should try to get this concept out there.

JS: should we start a glossary?

DS: there were concepts and I found it confusing.
... I'm going to try and explain these in the wiki, as a first stab.
... we should give a normative definition of these concepts.

JS: we owe the term to the aaron leventhal.

<Zakim> jcraig, you wanted to mention glossary def versus explanation discussion

JC: I believe that this should be explained into a spec, whether normative or informative.

<Zakim> Joseph_Scheuhammer, you wanted to say that the spec should define these

<jcraig> clown: if these events are in the spec, the terms will be there. for example "DOM focus" (or another term like Point of Regard) should be defined in the spec.

<jcraig> ds: This may be a presentation issue and might benefit from coordination with CSS WG

DS: this might benefit from a coordination with CSS group.
... the point of the regard is a presentation thing, not something in the DOM.

<jcraig> ds: SVG has concept related to this: viewport and viewbox

<jcraig> ds: clarifying "point of regard" is not same as "point of focus" which is the activeElement

JS: this helps the IDL and whoever writes theses specs, and this will help the developers to handle things correctly.

JC: most modern web apps register all events on the body to detect all the targets without having to add/remove from specific elements.

DS: can events be fired on the POR?

JC: yes, because in some cases the author may not want to register the event on the body.
... and example is a small widget like a button.
... but in large webapps that wouldn't be the best approach.

DS: there are seemingly implications for the DOM. And, it's not just presentational.

JS: it's a new type of DOM event.

s/JS: it's a new type of DOM event./JC: it's a new type of DOM event./

DS: not just a new type of event, but a new type of event flow.
... not saying it's bad, just something to consider.

AB: can you say anything the implementnation status of that draft?

JC: I can't say anything about that — Apple doesn't say anything about things that are not shipping.
... there was a commitment to webkit, but was removed since there was no formal W3C spec.

AB: is anybody expecting another group to make a similar proposal as James'?

RS: I am working on use cases; the events that James has — I don't have any issue.
... we can build off of the current proposal.

JS: any hot questions for James?

DS: looking at Rich's use cases, but those are not use cases.
... you are putting requirements where the use cases are.
... we can talk off line.
... I will write up a more explicit how-to for writing use cases.

JS: charter calls for the telecons every other week.
... two weeks today is a major US holiday.
... meet next week? or wait 4 weeks?
... we can't afford to wait 4 weeks.

JC: propose we do the 3 week option.

JS: so Jul 11

JS; everyone okay with that.

DS: we can work on use cases.

JC: and on repository.
... please everyone read at least the first section of the proposal — it's short.
... the spec will be based on this proposal. If you have major comments, I'd like to hear them asap.

JS: yes, let's get the concerns and issues out.
... volunteers for scribe for next list.

DS: let's take that up on the email list.

JS: call the meeting to adjourn.

RRSAgent: make minutes.

RRSAgent: make minutes

- DRAFT -

IndieUI Task Force telecon

20 Jun 2012

Attendees

Contents