W3C

Independent User Interface Task Force Teleconference

20 Aug 2014

See also: IRC log

Attendees

Present
janina, benjamp, Katie_Haritos-Shea, jcraig, Jason_White, kurosawa, Rich_Schwerdtfeger, Michael_Cooper, Cooper
Regrets
Andy_Heath
Chair
Janina_Sajka
Scribe
Katie Haritos-Shea, jasonjgw

Contents


<trackbot> Date: 20 August 2014

<janina> Meeting: IndieUI Task Force Teleconference

preview agenda with items from two minutes

<scribe> Scribe: Katie Haritos-Shea

<scribe> ScribeNick: Ryladog

trackbot, status?

JS: Ben is joining us from WEbApps
... Intro please in a sentnece ot two
... I have been at W3C at 10 years or so
... I am a perosnal and professional

JW: I have been aound at W3C since 1999, I am also a consumer

JC: I work at Apple. Involved in W3C for a decade or so, not specific to accessibility: I have contributed to CSS, HTML, WebApps, etc and worked on a web rich text editing product prior to working full-time on Accessibility. Looking to make a mainstream solution that also works with accessibility but is not accessibility-specific.

JS: James is out Spec Editor

TK: I am from Japan.....

RS: I work W3C at the W3C for over 10 years. I work on ARIA, SVG, HTML

MC: I am the staff contact for the working group, as well as ARIA WG and others

BP: I am glad to meet everyone. I am on the editing team at IE

TPAC 2014 http://www.w3.org/2014/11/TPAC/

JS: Please register. We will be meeting. We are meeting Monday and Tuesday at the end of October
... MC we need to get an Agenda up
... There will be a phone for remote attendees

Editor's Report

JC: For TPAC we need to be sure that there will be better audio support this year

MC: That is a little out of our control, but they do pay attention to the issue

JS: I think there were issues in China - but don't expect the level of audio quality that we had at Apple that year

MC: Yes it should be a smaller rroom

JC: No edits since the last time. The only thing of note is that I am getting pushback on UI manipultors
... One of the discussions is around some DOM protocol. I dont have a solution for that.

JS: What are some of the concersn?

JC: They are can we find another way to do this? Some scroll views - landing points - Microsoft, and other browser developers
... One suggestion is have a scroll view proptcol for DOM control. This bit would be machine readable but not machine writable - which is exactlty the opossiye issue that ARIA has
... Making it a protocol could make it more robust, It would have some benefits of the DOM
... If you have a native scroll view you can read the native slider directly

JW: Is there some kind of written summary, it sounds like an interesting alternative to what we have?

JC: I have not had time to write it all down yet
... This woukd then be outside of the scope of IndieUI or ARAI
... I will write up the summary

JS: This sounds interesting. I am always for more robust. I do not think it

JC: Dumb or DOM?

<jcraig> minutes said "dumb protocol"; intended DOM protocol. ;-)

JS: Lets not worry about the where it will live at this poit

JC: So that section may come out,

<janina> scribe: jasonjgw

Open Items with Web Apps' Editing TF

Janina: interested in recommencing the discussion with Web Apps. It has been agreed in email that there will be multiple specs, and appears to be broad agreement that we will coordinate vocabulary.

<MichaelC> http://w3c.github.io/editing-explainer/commands-explainer.html

Ben: the Web Apps document is to be split into two so that intentions can be explained broadly with reference to the specs that will cover them.

This would refer to IndieUI, editing, etc.

Ben raised this on list and there were no objections.

(The message was cross-posted.)

The cross-posting isn't desirable but presently unavoidable.

James: it is necessary to have a specific rich text editing group. Contenteditable isn't sufficient for all use cases and there are implementation inconsistencies. Large-scale Web applications require more; a staged approach is necessary.

He agrees that there needs to be an editing-focused task force. The same interface/methodology should be amenable to extension beyond editing, where appropriate.

That is, it should be consistent with the handling of custom controls in non-editing contexts.

The editing task force should address the editor-specific aspects of the problem.

Ben: the explainer document should capture the editing-related requirements.

We need to show how the events are divided among specs. For example, having "undo" in IndieUI is potentially confusing.

Having similar/consistent interfaces for the event types (across the different specs) is desirable.

Michael notes a similar kind of document produced by the CSS working group.

Ben: this needs to be done as quickly as possible, but may take longer than hoped. Making the events consistent with those defined elsewhere (i.e., the indie-ui events) would be a good beginning.

Drag and drop is a useful example.

James comments on the status of drag and drop and the modality-specific nature of it as currently specified.

James maintains that drag and drop needs to be generalized to different input modalities, e.g., speech recognition.

Ben: beforeInput is also currently under discussion.

James notes the use of content editable div-like components which can be used to enable dictation and the placement of input method windows. This functionality is suppored by platform APIs currently but needs to be made available to the Web.

Ben: the "explainer" document will set out the scope of the various specs and divide up the functionality, addressing how the components work together.

James suggests developing it under source control with multiple editors.

Janina expresses a preference for expanding it into a use cases and requirements document.

<jcraig> http://www.w3.org/TR/indie-ui-requirements/

Responding to a question from James, Ben clarifies that the use cases and intentions will be identified, and then an explanation given as to how the required functionality is divided between specs.

It is not anticipated that any one spec will cover an entire scenario. Example: a manipulator map widget can be built using technologies from several related specs.

James is concerned to avoid overlap in the resulting work.

Janina concurs: ongoing coordination will be needed.

James suggests that more work be done on editing prior to TPAC.

Ben is willing to work on such a document, adding material drawn from IndieUI requirements in cooperation with this group.

Ben and James clarify that this would be a very high-level document - a roadmap, as Janina describes it.

Janina suggests we are open to forming a larger task force or to whatever other coordination mechanism would facilitate the work.

Testing Conversation; Polyfills

James: work has started on polyfill development. We're still hoping to have an early version by TPAC.

Dismiss request is the event targeted for the polyfill implementation.

There are others which are easy to use for authors, but difficult to write as polyfills without native events.

Example: media events.

<jcraig> Jason Kiss has started work on polyfill development for "dismissrequest" example with uitrigger.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-08-20 21:59:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/Tect Editor/Spec Editor/
Succeeded: s/, for over a decade or so, I have worked in WebApps. I am now working with Accessibility/. Involved in W3C for a decade or so, not specific to accessibility: I have contributed to CSS, HTML, WebApps, etc and worked on a web rich text editing product prior to working full-time on Accessibility. Looking to make a mainstream solution that also works with accessibility but is not accessibility-specific./
Succeeded: s/bit it will never be like it was at /but don't expect the level of audio quality that we had at /
Succeeded: s/dumb/DOM/
Succeeded: s/I'm having jitter!/scribe: jasonjgw/
Found embedded ScribeOptions:  -final

*** RESTARTING DUE TO EMBEDDED OPTIONS ***

Found Scribe: Katie Haritos-Shea
Found ScribeNick: Ryladog
Found Scribe: jasonjgw
Inferring ScribeNick: jasonjgw
Scribes: Katie Haritos-Shea, jasonjgw
ScribeNicks: Ryladog, jasonjgw
Default Present: janina, benjamp, Katie_Haritos-Shea, jcraig, Jason_White, kurosawa, Rich_Schwerdtfeger, Michael_Cooper, Cooper
Present: janina benjamp Katie_Haritos-Shea jcraig Jason_White kurosawa Rich_Schwerdtfeger Michael_Cooper Cooper
Regrets: Andy_Heath
Found Date: 20 Aug 2014
Guessing minutes URL: http://www.w3.org/2014/08/20-indie-ui-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]