See also: IRC log
<trackbot> Date: 20 August 2014
<janina> Meeting: IndieUI Task Force Teleconference
<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
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
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
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.
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.
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]