See also: IRC log
<trackbot> Date: 15 May 2013
<janina> Meeting: IndieUI Task Force Teleconference
<jcraig> scribe: jcraig
JS: Nov 11-15 in Shenzhen China
IndieUI F2F will be that week
<jasonjgw> We'll try to have our meeting at TPAC for two days, 11-15 November.
<scribe> scribe: jasonjgw
<richardschwerdtfeger> what is the conference code/
<richardschwerdtfeger> ?
<jcraig> Particularly the directional and linear focus requests.
The main question is that distributed to the list regarding edits to events spec.
<richardschwerdtfeger> it says 46343 is not valid!
<richardschwerdtfeger> that is the second time today
<jcraig> For how they are two events: directionalfocusrequest and linearfocusrequest that each will have a detectable focusType attribute in the Event object matching, for example, LINEAR_PREVIOUS, LINEAR_NEXT, DIR_EAST, DIR_SOUTHWEST, etc.
<janina> Hmmm, Rich, it seems to be an issue accepting DTMF, perhaps?
<jcraig> The other variation would be to have each be a separate named event. For example, focuspreviousrequest, focusnextrequest, focuseastrequest, focussouthwestrequest, etc. I thought adding twelve events would be more confusing than adding two with parameters.
James notes the distinction between direction focus events (next, previous, first, last) reserved for maps or similar objects. For now we have DirectionalFocusRequest and LinearFocusRequest with a focus type.
The linear focus events are all individually named events.
<jcraig> Does this rest of the group agree with my assumption? If not, why?
Does the working group support this scheme?
Rich suggests adopting the same vocabulary that is under consideration for SVG Tiny 1.2.
<Zakim> MichaelC, you wanted to say I think fewer events with parameters easier, and also easier to add parameters later if circumstances come up
<jcraig> http://www.w3.org/TR/SVGTiny12/
Michael thinks MMMMichael and Andy think there is more flexibility in having events as parameters.
<richardschwerdtfeger> http://www.w3.org/TR/SVGTiny12/interact.html#navigation
<jcraig> http://www.w3.org/TR/SVGTiny12/single-page.html#interact-navigation
James observes that it's similar to a CSS proposal, which has similar problems to tabindex.
<jcraig> SVG uses syntax nav-next="url(#Chan2Prog1)"
The CSS proposal was deleted from their spec recently, James notes.
The issue raised by Rich, to clarify, is alignment of vocabulary.
No further editor's updates.
<jcraig> Nothing more from me except I have to read this section of the SVG spec now . ;-)
This agenda item is postponed for now.
<jcraig> Action-50?
<trackbot> ACTION-50 -- James Craig to prepare a list of user context properties that might be able to be covered by media queries -- due 2013-04-17 -- PENDINGREVIEW
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/50
<jcraig> CSS Conditionals
<jcraig> CSS Media Features
James: media queries seems a good opportunity to bring aspects of User Contexts into a well known and accepted format, namely CSS. CSS conditionals and media features are the relevant specs.
IndieUI and PF may wish to propose additional media queries.
Example: high contrast proposal.
<jcraig> Microsoft proposal for high contrast:
<jcraig> -ms-high-contrast: active | black-on-white | white-on-black | none;
<jcraig> My proposal variant:
<jcraig> display-colors-inverted: inverted | off;
<jcraig> display-contrast: <percentage>;
<jcraig> display-increase-contrast: 100%; may be equivalent to -ms-high-contrast: active;
<jcraig> display-increase-contrast: 0%; may be equivalent to -ms-high-contrast: none;
As a variant, James proposed two properties: colours inverted and a contrast percentage value.
<jcraig> @media (display-colors-inverted: inverted) { img, video { filter: invert(100%); } }
Discussion of contrast settings on different operating systems.
<jcraig> base-color
<jcraig> base-background-color
<jcraig> base-font-size
<jcraig> base-letter-spacing
<jcraig> base-line-height
<jcraig> base-word-spacing
<jcraig> display-colors-inverted
<jcraig> display-contrast-increased
<jcraig> minimum-font-size
James suggests, in answer to a question, that a joint IndieUI/PF position would be the best way to establish a proposal to extend the media queries supported in CSS.
James further clarifies that when relevant changes occur, so do the results of the media queries and hence the style applied to the document.
James suggests preparing a draft for CSS wg to review.
DiscussionTTTThe group notes a need to obtain input regarding different operating systems (Android, Linux and others).
<jcraig> RS: Check with Google platforms and Linux to make sure this list covers other platforms besides Windows, Mac, and iOS.
<jcraig> https://www.w3.org/WAI/IndieUI/track/actions/50
Eitan notes that some Firefox OS applications do not listen for click events, but only for low-level touch events. The system listens for touch events, not click.
He supports James' proposal that click still be used, but when an object is not activated this way, an IndieUI focus event should be available and used.
<Zakim> jcraig, you wanted to ask if equivalent of "click" is sent in default framework controls
James suggests that if a higher-level UI framework is being proposed, click could still be used as a default activation event (simulated rather than driven by mouse hardware in the touch screen case).
Eitan notes that there isn't a common framework at this stage. There are difficulties in determining when a click event has to be simulated.
James agrees there is no definition of what constitutes a "click", i.e., on what circumstances the event is to be simulated/dispatched. This needs to be defined per operating system.
James notes that the DOM wg considers click an abstract activation event; it is named "click" purely for historical reasons.
Eitan proposes a secondary activation event request to be used in limited circumstances, with a strong note that the (abstract) click event defined in DOM should be used where possible.
<Zakim> jcraig, you wanted to ask how a <button> works on Firefox OS if 'click' is not implemented?
Eitan suggests there is a need to distinguish clicks caused by pointing devices from those which are simulated, caused for example by underlying touch events.
<jcraig> ACTION-53?
<trackbot> ACTION-53 -- James Craig to add ~"activate request" event to augment default action trigger when "click" handlers are inappropriate. -- due 2013-05-10 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/53
He clarifies that applications listening for click and touch events will in some cases receive the input twice, e.g., on a button.
<jcraig> Eitan confirms action 53 should suffice for the Firefox OS needs
There is general agreement on James' proposal for IndieUI.
<jcraig> MC: Next call on May 29rd
<jcraig> RS: I'm out that day.
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/23/29/ Succeeded: s/James proposes a secondary activation event request/Eitan proposes a secondary activation event request/ Found Scribe: jcraig Inferring ScribeNick: jcraig Found Scribe: jasonjgw Inferring ScribeNick: jasonjgw Scribes: jcraig, jasonjgw ScribeNicks: jcraig, jasonjgw Default Present: janina, Andy_Heath, jcraigh, jcraig, Cooper, +1.412.901.aaaa, Rich_Simpson, Jason_White, [Apple], hober, Rich_Schwerdtfeger, [IPcaller] Present: janina Andy_Heath jcraigh jcraig Cooper +1.412.901.aaaa Rich_Simpson Jason_White [Apple] hober Rich_Schwerdtfeger [IPcaller] Agenda: http://lists.w3.org/Archives/Public/public-indie-ui/2013May/0019.html Found Date: 15 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/15-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]