Independent User Interface Task Force Teleconference -- 19 Feb 2014

<trackbot> Date: 19 February 2014

<janina> Meeting: IndieUI Task Force Teleconference

<scribe> scribe: Rich

preview agenda with items from two minutes

Shall we plan a F2F in April?

janina: do we want to try to have a face to face?
... the HTML working from is meeting at eBay 9, 10 as well webapps

jcraig: I will just participate in the web apps face to face directly
... shadow dom and other features are in there

janina: that may be the second best thing
... we could overlap HTML
... we don't have a group of 50 people

Editor's Report

jcraig: I have not made any edits since them. The editors issues we need to discuss

janina: there is a time out thing

jcraig: Is this events implementation review item that you added for me?

janina: this is more what implementations we can expect
... we can expect one from Apple. What about Chrome and Firefox?

jcraig: I think Microsoft was looking to see some implementation first

rich: Microsoft is really looking for activity on the implementation not that it all be done first.

Events Implementation Review

Agendum 4 , close item 4

Prototype polyfills

jcraig: So to give a summary on a JavaScript polyfills. If you launch a date picker this is something you can add to a text field.
... with polyfills you add script to your page that looks for elements with input type="date" and replace it with with widget in javascript, etc. that you fill in.
... when implementation catch up then the polyfill can go away
... one of the ways we can prototype indie ui is to write a polyfill to show people how Indie UI would work with processing for keyboard and mouse input
... This is on my list.
... jason kiss may be interested.

katie: he would be cool

jcraig: this will be backward compatible for older browsers
... we can find holes in the spec. in the process

janina: this makes sense for older browsers

jcraig: the example I was thinking of with scroll requests is they have to listen for mouse down, up, key up, key down, etc. Most people do not do scrolling well.

Rich: Hans Hillen might be a good candidate

janina: this is a good time for Jason Kiss

<scribe> ACTION: janina send Jason an invite [recorded in http://www.w3.org/2014/02/19-indie-ui-minutes.html#action01]

<trackbot> Created ACTION-77 - Send jason an invite [on Janina Sajka - due 2014-02-26].

<scribe> ACTION: Rich contact Hans Hillen to participate in polyfill work for Indie UI [recorded in http://www.w3.org/2014/02/19-indie-ui-minutes.html#action02]

<trackbot> 'Rich' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., rschwer, rsimpson3).

<scribe> ACTION: RichS contact Hans Hillen to participate in polyfill work for Indie UI [recorded in http://www.w3.org/2014/02/19-indie-ui-minutes.html#action03]

<trackbot> Error finding 'RichS'. You can review and register nicknames at <http://www.w3.org/WAI/IndieUI/track/users>.

<scribe> ACTION: richs contact Hans Hillen to participate in polyfill work for Indie UI [recorded in http://www.w3.org/2014/02/19-indie-ui-minutes.html#action04]

<trackbot> Error finding 'richs'. You can review and register nicknames at <http://www.w3.org/WAI/IndieUI/track/users>.

<scribe> ACTION: schwer contact Hans Hillen to participate in polyfill work for Indie UI [recorded in http://www.w3.org/2014/02/19-indie-ui-minutes.html#action05]

<trackbot> Error finding 'schwer'. You can review and register nicknames at <http://www.w3.org/WAI/IndieUI/track/users>.

Issues with composite controls

jcraig: this is the problem I found in writing a polyfill. I mentioned in the scroll request that one action could cause a scroll request. key press, mouse events, etc.
... I was thinking how this would work for an ARIA slider
... something like increment or decrement
... if you had an aria slider we could make a value change request to work with screen readers. this is difficult for a pointing device
... there would need to be a container and a sub element that would act like a slider thumb. This would be like a move request.
... this would be like a move on a thumb, etc.
... this makes adoption a bit weird and certainly more complex than we had planned.
... even for a custom slider more work would be required

jason: this was not clear to me whether this is an interim issue.
... would any implementation pick up any of this.

jcraig: this would certainly be a permanent problem.
... you could take a click and a scroll
... the view on a slide is presumably 2 inches wide, 1/2 inch tall with a slider thumb within it
... you would pick a pixel difference on the slider

jason: I wonder if there is a way to associate a value change request with this. You would need to specify what is the operable control
... I wonder if you could respecify the value change request

jcraig: say you have the slider is all the way to the left and you want to go all the way to the right.
... it would be the controller

<jasonjgw> Rich understands the problem as being that the party that generates the event doesn't generate the value. He suggests the information about the correspondence between low-level events (mouse movements for example) and changes in value could be specified on registration.

<jasonjgw> Rich notes that data haven't been provided to the ua to specify when to notify the application of the value change.

<jasonjgw> Rich suggests we need to provide enough information to the ua for it to make a determination.

<jasonjgw> Rich would be willing to postpone last call for this to be solved.

<scribe> scribe: Rich

<jcraig> ACTION: jcraig to add editorial note to valuechangerequest mentioning the slider/thumb composite widget problem and pixel interface event reconciliation [recorded in http://www.w3.org/2014/02/19-indie-ui-minutes.html#action06]

<trackbot> Created ACTION-78 - Add editorial note to valuechangerequest mentioning the slider/thumb composite widget problem and pixel interface event reconciliation [on James Craig - due 2014-02-26].

<jasonjgw> Rich: we don't know how much of a value change to put in as information about the range, the number of pixels required, etc., isn't provided.

jason: the size of the control if it is different if it is touch
... the correspondence between pixel location and values of the control

katie: does this require, if you are using touch to use two fingers?

jcraig: I don't see why

katie: I don't want to have to do more than one thing at a time

jcraig: let me explain my original composite solution now that we have a better grasp
... If you have a div that are called views for everything and we have roles of sliders. The graphical element would represent the slider thumb and then behind it you have the tracker element
... for page up, page down home and end send value requests that responds to these
... the way these composite elements that operate inside the thumb you would have a general move action.
... the web application can then measure the pixel differences and reconcile the changes up the chain to the value change request.
... it is much better than what is out there now. It is also not controllable with AT

janina: any more comments or questions?

jason: I am still wondering if it is still possible to provide the connections to the sub element

janina: we just need to figure out the how

katie: so, what is the mechanism whereby the functionality would determine whereby the software would do the calculation

jcraig: you mean a general move request?

katie: how is it determining this?

jcraig: I don't think landscape or portrait is relevant here
... if you had I a high pixel density screen ... a retina display, etc. It would still resolve to CSS pixels, not device pixels.

Events Requirements Status & Actions

janina: I suspect in advance we are touching base.

MichaelC: I have not done anything on this and won't do anything on this until after CSUN

<MichaelC> IndieUI Requirements

MichaelC: as a reminder, what I did was I put events and user context into one document. they are separate sections. ideally every requirement should be supported by a use case or scenario
... I am not all the way done yet
... It is a question whether we need to move some to a general accessibility requirements doc.
... this is all stuff we should be doing but we have a good start

janina: you thought we were thin on use cases?

MichaelC: we don't have use cases for everything
... not all requirements are backed up by use cases

janina: this problem that james has identified for us will keep us from last call for now
... this buys us some more time

jason: an argument for polyfills I would have thought

jcraig: unfortunately, there is not a good way to do an accessbility api with a polyfill

Events Testing Update

janina: anything else?

jason: I think not. last I call there was a discussion among several people whether the w3c test structure was going to do it.
... the basis of a test suite across implementations was as far as we got.
... note: polyfills will not help with the testing as it shows it would work and to help adoption.
... if one of the things we tested - element supported actions. it would mask the fact that the implementation was lacking

janina: we need them to do it natively

<kurosawa> http://codedefect.com/ttwf-sz-belem/#/1/5

kurosawa: according to technical material. i think this is not testable.

jcraig: are you asking what statements are testable and not testable?

<kurosawa> Mapping physical events to Indie UI events are informative. so they are not testable.

<jcraig> Element IDL extended to include an actions attribute

jcraig: the element IDL would be extended to include the actions attribute

jcraig: there are certainly elements that can be automatable. Do you have specific concerns for things that are not testable?

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#actions

<jcraig> partial interface Element {

<jcraig> readonly attribute DOMTokenList uiactions;

<jcraig> };

<kurosawa> I understand uiaction is testable

<jcraig> [Constructor(DOMString typeArg, optional UIRequestEventInit dictUIRequestEventInit)]

<jcraig> interface UIRequestEvent : UIEvent {

<jcraig> readonly attribute EventTarget receiver;

<jcraig> };

janina: let me note that the next meeting is March 5.
... I propose the following meeting will be April 2nd due to CSUN

jcraig: there are parts that are testable

janina: we appreciate all help in setting up a good test environment.

jcraig: we are not trying too be dismissive

- DRAFT -

Independent User Interface Task Force Teleconference

19 Feb 2014

Attendees

Contents