Independent User Interface Task Force Teleconference -- 09 Jan 2013

<trackbot> Date: 09 January 2013

<janina> Meeting: IndieUI Task Force Teleconference

<Lachy> hi

<janina> Hello!

<janina> OK, thanks. We'll be appointing a scribe, so you should be pretty much up to speed on substance.

<andy> pretty good, ty

<andy> got it - ty, sorry for being thick

<andy> hny 2 all

<jcraig> Andy, try typing into IRC

<jcraig> scribe: jcraig

next item

js: 18:00 GMT is now. 22:00 GMT is the other time.
... 2 months from to next global time change
... makes that time bad for OZ and JP
... should discuss more at the next call during 22:00

<dmazzoni> scribe: dmazzoni

jcraig: i thought that the time slot we had discussed earlier would be 3 or 4 pm my time, which is 22h or midnight gmt?

js: i wouldn't have agreed to that, not on wednesdays?

it's not me

<jcraig> next item

<scribe> scribe: jcraig

Shall we publish an Events Module FPWD?

js: we have a candidate draft we can publish as FPWD with group approval
... some substantive comments (all addressed?) are we ready to call for consensus?
... any opposed to publishing?

https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html

js: next major step would be a LCWD

dm: no objections, but a question:
... what would be a reason (abstractly) why we'd delay? Also, what do we expect in terms of feedback?
... based on that, should we be concerned?

<janina> scribe: janina

jc: One possible reason to delay might be too many "yet to be written" sections

<MichaelC> hober, Lachy, shepazu, smaug: we´re in the process of collecting input on a decision to publish IndieUI Events to TR - would you like to vote one way or the other via IRC? It will also be subject to an email confirmation, but as much input we can get now would be helpful.

jc: The balance we look for is enough substance to give people a pretty clear picture of where we're heading

<Lachy> I have no objection to publishing a WD

jc: Event blocking was removed because we knew there were valid concerns on that

<smaug> MichaelC: I'd prefer doing that via email

<smaug> (busy right now)

jc: Once we publish we expect a round of public feedback
... We'll try to incorporate feedback
... There will be additional draft versions moving forward until we believe we've addressed all concerns
... At that point we do a "Last Call"
... If there are no further comments at that point we move to "Candidate Recommendation" where testing is required.

<andy> back

<andy> me

<andy> yep

<jcraig> dm: appropriate to provide FAQ and anticipatory objections in the spec or announcement of FPWD?

<jcraig> jc: Yes. Please provide any feedback, positive or negative.

<jcraig> mc: I can post a link to issue tracker in the doc status section of the WD

<MichaelC> W3C Spec Publish Process

<jcraig> khs: did Rich's comments make it in?

<jcraig> jc: First round of Rich's comments are in. I have not yet read the second reply.

<MichaelC> How WAI Develops Accessibility Guidelines through the W3C Process

<MichaelC> Note the above was written for WAI but applies to general W3C process

<jcraig> mc: Look through formal requirements in the first link.

<jcraig> dm: not entirely sure why the ui-actions attribute was necessary.

<jcraig> dm: some questions (not necessarily from me, but to clarify in the document):

<jcraig> dm: is there any harm to always send these events? why prevent them in some circumstances?

<Ryladog> JC: The 2nd question was why the need for receiver?

<jcraig> dm: why the need for event.receiver (el with @ui-actions) instead of just event.listener

<jcraig> why is ui-action needed. a: b/c receiver need to be defined somehow.

<Ryladog> Dom: I was thinking why is a UI attribute action needed? A reciever would not be possible without it

<Ryladog> JC: The UR actions atribute to find the reveicer,/ RThee receoiver is needed to find the event

<Ryladog> JC: with the exception of the manupulation eevent there isnt any harm

<Ryladog> JC: part of the reason for defining this is to say I respond to this specifically for this item

<Ryladog> JC: All of the other ones are going to respond to standard focus and blur events

<Ryladog> JC: Should I clarify the other more in the document?

<Ryladog> Dom: that is right.

<Ryladog> MC: Is this something we want tp do before we publish?

<Ryladog> JC: I will try to addresss oem of this today

<Ryladog> Dom: I want to be clear that I do not want to hold this draft up, but would like more clarification on these events

<Ryladog> JC: I will try to put in today mostly editorial, but to clarify the backwards compatability conceren

<Ryladog> JC:L You are right to bring it up before the 1st Public Working Draft

<Ryladog> JC: If we can clarify any of this before that is better

<Ryladog> JC: What about the rich text editing stuff Dominic, do you think this is out iof scope for the 1.0 draft?

<Ryladog> Dom: Yes it is out of scope for 1.0, but in the future it is relevant. We should start a draft now, maybe add later

<Ryladog> JC: Are you saying we should get RTE in the 1.0 drafts, and pull it out later if it's not ready?

<Ryladog> Dom: Yes

<Ryladog> MC: Lets not think too far forward

<Ryladog> MC: We either add a placeholkder in the draft OR create a n issue in tracxker and come back to it later

<Ryladog> Dom: It is more in the scope of ARIA 2.0

<Ryladog> MC: Lets them make it an issue in tracker now and it will get it on our agenda to address

<MichaelC> issue: Rich text editing

<trackbot> Created ISSUE-9 - Rich text editing; please complete additional details at <http://www.w3.org/WAI/IndieUI/track/issues/9/edit>.

<Ryladog> jc: We also have an ARIA issue for this, and we should relTE THE TWO. Address Rich Text Editing

<MichaelC> issue-9: relates to PFWG-ISSUE-92

<trackbot> Notes added to ISSUE-9 Rich text editing.

<jcraig> PF Issue 92 https://www.w3.org/WAI/PF/Group/track/issues/92

<Ryladog> MC: Issue 9 (Indie UI) relates to ARIA issue 92 (PF) Rich Text Editing

<Ryladog> JS: Some of the n=ext step, we should move forwrd withthe working draft

<MichaelC> issue-9: relates to https://www.w3.org/WAI/PF/Group/track/issues/92

<trackbot> Notes added to ISSUE-9 Rich text editing.

<Ryladog> +1

<jcraig> no objection

<Ryladog> agree

<Ryladog> JS: Call for consensus lasting 1 week to publish 1st Working draft of Indie UI Events

<Ryladog> JS; We need to URI

<Ryladog> yes, sorry, I am not a good minuter

<jcraig> js: objections?

<jcraig> RESOLUTION: The participants of this telecon agree to publish IndieUI: Events <https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html> as a First Public Working Draft, subject to the group´s review procedure of an email call for consensus lasting one week, to be confirmed by a final resolution email

<jcraig> js: I will announce on list, track the progress, and follow up with an email one week from today.

Editor's Update: User Needs Module

<jcraig> js: what's next for User Context?

<jcraig> ah: planning to publish an initial list of prefs by end of January

<jcraig> ah: for example, in IA3, there are adaptation types. resulting in quite a few prefs. Looking at flattening and condensing the list.

<jcraig> jc: I encourage ruthlessness with regards to reduction of the list.

<jcraig> jc: earliest User Context draft might be at end of February

<jcraig> jc: need to make the preference extensibility aspects "optionally normative" like x-vendor-attributes in HTML or -vendor-properties in CSS.

- DRAFT -

Independent User Interface Task Force Teleconference

09 Jan 2013

Attendees

Contents

Shall we publish an Events Module FPWD?

Editor's Update: User Needs Module

Summary of Action Items

Scribe.perl diagnostic output