See also: IRC log
<trackbot> Date: 19 February 2014
<janina> Meeting: IndieUI Task Force Teleconference
<scribe> scribe: Rich
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
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.
Agendum 4 , close item 4
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>.
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.
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
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> <div ui-actions="move">
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/display, etc./display, etc. It would still resolved to CSS pixels, not device pixels./ Succeeded: s/resolved/resolve/ No ScribeNick specified. Guessing ScribeNick: richardschwerdtfeger Found Scribe: Rich Found Scribe: Rich Default Present: janina, jasonjgw, kurosawa, Katie_Haritos-Shea, Cooper, James_Craig, Rich_Schwerdtfeger Present: janina jasonjgw kurosawa Katie_Haritos-Shea Cooper James_Craig Rich_Schwerdtfeger WARNING: Replacing previous Regrets list. (Old list: Andy) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Rich_Simpson, Andy_Heath Regrets: Rich_Simpson Andy_Heath Found Date: 19 Feb 2014 Guessing minutes URL: http://www.w3.org/2014/02/19-indie-ui-minutes.html People with action items: contact hans hillen janina jcraig rich richs schwer WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]