See also: IRC log
<trackbot> Date: 15 April 2010
<kford> Is the phone working for people?
<AllanJ> yes
<kford> Odd, I keep calling trying to enter the code and it just goes to a ring.
<AllanJ> jeanne says wait for the prompt to finish
<AllanJ> then enter the code
<AllanJ> http://www.w3.org/2002/09/wbs/36791/DefinitionOfFocus/results
<kford> I am back.
active input focus and input focus -- put in same block?
<Greg> If and when we collapse multiple terms into a single glossary entry, I suggest we include cross-references.
Greg: one glossary entry for all three terms sorted under input focus, because they're really all the same except active and inactive variations.
<Greg> Another alternative to collapsing the input focus, inactive input focus, and active input focus together would be to have a single definition for input focus and a separate pair of entries for active and inactive. Thus when we use "active input focus" (which the document does NOT currently use at all) we could have that phrase be two separate links, one to "active" and one to "input focus".
Jim: do use inactive anywhere in
the success criteria
... Does this is just muddy the waters
Greg: we can cut out eventually, but it's good to have the moment of thinking about them at first
Great: at the moment neither active nor an active is used in the document with the exception of one e.g. Which is a different meaning of the term
Jim: anybody have any objections to including all of them
Greg: leave them in but put a note if not used
<jeanne> ACTION: Jeanne to update the glossary entry to note the definitions that are not currently used as an Editors Note. [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action01]
<trackbot> Created ACTION-355 - Update the glossary entry to note the definitions that are not currently used as an Editors Note. [on Jeanne Spellman - due 2010-04-22].
<Greg> To clarify, leave them in the working draft, and the note would say they could be removed from the final version if not used.
<Greg> Just a note, re "active input focus" and other related terms, Technically you can't have "the" active input focus, but rather one input focus for each input device. Thus this should really be "For an input device..."
<AllanJ> ACTION: Jeanne to add def of Active input focus - The *input focus* location in the *active viewport*. The active input focus is usually visibly indicated. In this document "active input focus" generally refers to the active keyboard input focus. to glossary, ncu [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action02]
<trackbot> Created ACTION-356 - Add def of Active input focus - The *input focus* location in the *active viewport*. The active input focus is usually visibly indicated. In this document "active input focus" generally refers to the active keyboard input focus. to glossary, ncu [on Jeanne Spellman - due 2010-04-22].
Jim: NCU, not currently used
Jim: accept them as individual units and put them in for now --
Jeanne: editors issue
Active selection
<jeanne> ACTION: Jeanne to take the glossary definitions of various different "Focus" and collapse them into one Focus glossary entry with details. [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action03]
<trackbot> Created ACTION-357 - Take the glossary definitions of various different "Focus" and collapse them into one Focus glossary entry with details. [on Jeanne Spellman - due 2010-04-22].
Jim: in the current viewport
Greg: of the selections in the current window
<AllanJ> ACTION: Jeanne to add Active Selection - The *input focus* location in the *active viewport*. The active input focus is usually visibly indicated. In this document "active input focus" generally refers to the active keyboard input focus. to glossary. ncu [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action04]
<trackbot> Created ACTION-358 - Add Active Selection - The *input focus* location in the *active viewport*. The active input focus is usually visibly indicated. In this document "active input focus" generally refers to the active keyboard input focus. to glossary. ncu [on Jeanne Spellman - due 2010-04-22].
Jim: Patrick's comment -- cursor/^?
Greg: we should get him to explain what he means
Jim: is the technical people people call it ^ and others call it cursor?
<AllanJ> ^ = caret
Greg: Mark suggesting and new success criteria -- put that as an issue?
Jim: Marcs question is should an
inactive viewport remain visible
... is there an accessibility benefit
Greg: when you're using assistive
technology if you need to move the Arrow, whose information as
to where you command will have affect in the document window --
that being said I would not want to put this in because it
would be going against the user interface conventions in many
platforms. Windows convention is to hide inactive ^.
... we could put it in as low priority
Jim: didn't hear any objections pending comments from Patrick --
<kford> none here.
Jim: any objections to the definition
Greg: were we have the definition in the second sentence -- changing to flashing vertical bar in text field, also known as ^
<AllanJ> ACTION: Jeanne to add cursor - Visual indicator showing where keyboard input will occur. There are two types of cursors: *focus cursor* (e.g. the dotted line around a button) and *text cursor* (e.g. the flashing vertical bar in a text field, also called a 'caret'). Cursors are active when in the active viewport, and inactive when in an inactive viewport. to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action05]
<trackbot> Created ACTION-359 - Add cursor - Visual indicator showing where keyboard input will occur. There are two types of cursors: *focus cursor* (e.g. the dotted line around a button) and *text cursor* (e.g. the flashing vertical bar in a text field, also called a 'caret'). Cursors are active when in the active viewport, and inactive when in an inactive viewport. to the glossary [on Jeanne Spellman - due 2010-04-22].
Greg: focus cursor is one subset of cursor-- focus cursor and text cursor -- we could make that clear here
Simon: does it make more sense to you have something called touch cursor and focus cursor within that
Greg: make sense -- collapse in the editing process
<AllanJ> ACTION: jeanne to add Focus Cursor: Indicator that *highlights* a user interface element to show that it has *keyboard focus*, e.g. a dotted line around a button, or brightened title bar on a window. There are two types of cursors: *focus cursor* (e.g. the dotted line around a button) and *text cursor* (e.g. the flashing vertical bar in a text field). to the glossary. [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action06]
<trackbot> Created ACTION-360 - Add Focus Cursor: Indicator that *highlights* a user interface element to show that it has *keyboard focus*, e.g. a dotted line around a button, or brightened title bar on a window. There are two types of cursors: *focus cursor* (e.g. the dotted line around a button) and *text cursor* (e.g. the flashing vertical bar in a text field). to the glossary. [on Jeanne Spellman - due 2010-04-22].
Jim: no objections
<jeanne> ACTION: jeanne to do a global change of "focusable items" to "focusable elements" [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action07]
<trackbot> Created ACTION-361 - Do a global change of "focusable items" to "focusable elements" [on Jeanne Spellman - due 2010-04-22].
Greg: note that in some places its focusable elements and sometimes items -- should consistent, probably all be focusablel elements
Jim: the objections
<AllanJ> ACTION: Jeanne to add Focasable element- Any element capable of having input focus, e.g. link, text box, or menu item. In order to be accessible and fully usable, every focusable element should take keyboard focus, and ideally would also take pointer focus. [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action08]
<trackbot> Created ACTION-362 - Add Focasable element- Any element capable of having input focus, e.g. link, text box, or menu item. In order to be accessible and fully usable, every focusable element should take keyboard focus, and ideally would also take pointer focus. [on Jeanne Spellman - due 2010-04-22].
Jim: if it were bound visibly then everything would show up as long as you were in ^ browsing-- could we get someone to craft an extension
Greg: working on learning Firefox extensions so we can prototype
Jim: David Bolter, browserscope.org where compiling information about browser functionality -- his statement was I wonder if this is a good venue for building a library of browser extensibility or keep track of limitations
<AllanJ> www.browserscope.org
<AllanJ> http://code.google.com/p/browserscope/
Jim: we might be able to jump in and squeeze out a little accessibility space in there
Jim: looks like a done deal
<AllanJ> ACTION: jeanne to add Highlight - Emphasis indicated through the user interface. For example, user agents highlight content that is selected,focused, or matched by a search operation. Graphical highlight mechanisms include dotted boxes, changed colors or fonts, underlining, magnification, and reverse video. Synthesized speech highlight mechanisms include alterations of voice pitch and volume... [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action09]
<trackbot> Created ACTION-363 - Add Highlight - Emphasis indicated through the user interface. For example, user agents highlight content that is selected,focused, or matched by a search operation. Graphical highlight mechanisms include dotted boxes, changed colors or fonts, underlining, magnification, and reverse video. Synthesized speech highlight mechanisms include alterations of voice pitch and volume... [on Jeanne Spellman - due 2010-04-22].
<AllanJ> ...("speech prosody"). User interface items may also be highlighted, for example a specific set of foreground and background colors for the title bar of the active window. Note that content that is highlighted may or may not be a *selection*. to the glossary
Jim: no objections
<Greg> Changing "The" to "An" would get around the problem I mentioned earlier about the fact that there can be one input focus per input device.
<AllanJ> ACTION: jeannes to add Inactive Input Focus - An input focus location in an inactive viewport such as a background window or pane. The inactive input focus location will become the active input focus location when input focus returns to that viewport. An inactive input focus may or may not be visibly indicated. to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action10]
<trackbot> Sorry, couldn't find user - jeannes
<AllanJ> ACTION: jeanne to add Inactive Input Focus - An input focus location in an inactive viewport such as a background window or pane. The inactive input focus location will become the active input focus location when input focus returns to that viewport. An inactive input focus may or may not be visibly indicated. to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action11]
<trackbot> Created ACTION-364 - Add Inactive Input Focus - An input focus location in an inactive viewport such as a background window or pane. The inactive input focus location will become the active input focus location when input focus returns to that viewport. An inactive input focus may or may not be visibly indicated. to the glossary [on Jeanne Spellman - due 2010-04-22].
<AllanJ> ACTION: Jeanne to add INactive Selection - A selection that does not have the* input focus* and thus does not take input events. to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action12]
<trackbot> Created ACTION-365 - Add INactive Selection - A selection that does not have the* input focus* and thus does not take input events. to the glossary [on Jeanne Spellman - due 2010-04-22].
<AllanJ> ncu
<AllanJ> ACTION: Jeanne to add Input Focus - The place where input will occur if a viewport is active. Examples include keyboard focus and pointing device focus. Input focus can also be active (in the active viewport) or inactive (in an inactive viewport). [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action13]
<trackbot> Created ACTION-366 - Add Input Focus - The place where input will occur if a viewport is active. Examples include keyboard focus and pointing device focus. Input focus can also be active (in the active viewport) or inactive (in an inactive viewport). [on Jeanne Spellman - due 2010-04-22].
Jim: Patrick comment -- distinguish between keyboard input and keyboard interaction -- trying to distinguish between typing and causing something to activate, but I think anything from the keyboard is keyboard input
Greg: not sure we're understanding his concern-- goahead, but have him elaborate
Jim: any objections to that
Greg: understand there's a major difference between this keyboard focus and ANSI -- this is talking about a location where input will occur -- others talk about keyboard focus as current assignment to element -- that's much more targeted, it's a property that gets moved around and always about a user interface element not a screen location.
Jim: ours is broader -- you do a left arrow it moves left in addition to being in a menu system -- we have to be vague because we're trying to cover so many different bases were we get really convoluted in our words
<AllanJ> ACTION: Jeanne to add Keyboard Focus - The screen location where keyboard input will occur if a viewport is active. Keyboard focus can be active (in the active viewport) or inactive (in an inactive viewport). to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action14]
<trackbot> Created ACTION-367 - Add Keyboard Focus - The screen location where keyboard input will occur if a viewport is active. Keyboard focus can be active (in the active viewport) or inactive (in an inactive viewport). to the glossary [on Jeanne Spellman - due 2010-04-22].
Jim: no objections
Jim: point of regard is what we have been using
Greg: we didn't change it
<AllanJ> everything stays current, no action
Greg: we should keep term consistent between versions
Jim: Mark has same question about calling out UIs
Greg: confusion between pointing device and pointer -- touch screens typically pointing device not pointer, device is users finger. We can put in note clarifying this because it's obviously a point of confusion.
<Greg> NOTE: When touch screens are used, the "pointing device" is a combination of the touch screen and the user's finger or stylus. On most systems there is no pointer (on-screen visual indication) associated with this type of pointing device.
<AllanJ> ACTION: jeanne to add Pointer: Visual indicator showing where pointing device input will occur. The indicator can be moved with a pointing device or emulator such as a mouse, pen tablet, keyboard-based mouse emulator, speech-based mouse commands, or 3-D wand. A pointing device click typically moves the *input focus* to the pointer location. The indicator may change to reflect different... [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action15]
<trackbot> Created ACTION-368 - Add Pointer: Visual indicator showing where pointing device input will occur. The indicator can be moved with a pointing device or emulator such as a mouse, pen tablet, keyboard-based mouse emulator, speech-based mouse commands, or 3-D wand. A pointing device click typically moves the *input focus* to the pointer location. The indicator may change to reflect different... [on Jeanne Spellman - due 2010-04-22].
<AllanJ> ...states. NOTE: When touch screens are used, the "pointing device" is a combination of the touch screen and the user's finger or stylus. On most systems there is no pointer (on-screen visual indication) associated with this type of pointing device. to the glossary
Jim: pointing device focus versus pointer
Greg: focus versus Arrow
<AllanJ> scribe: KimPatch
<Greg> This hierarchical summary helps to explain the relationship between the terms, and thus why some terms are included to clarify the parallel construction:
<Greg> 1. Input focus (active/inactive) “The place where input will occur if a viewport is active”
<Greg> 1.1. Keyboard focus (active/inactive) “The screen location where keyboard input will occur if a viewport is active”
<Greg> 1.1.1. Cursor (active/inactive) “Visual indicator showing where keyboard input will occur”
<Greg> 1.1.1.1. Focus cursor (active/inactive) “Indicator that highlights a user interface element to show that it has keyboard focus”
<Greg> 1.1.1.2. Text cursor (active/inactive) “Indicator showing where keyboard input will occur in text”
<Greg> 1.2. Pointing device focus (active/inactive) “The screen location where pointer input will occur if a viewport is active”
<Greg> 1.2.1. Pointer “Visual indicator showing where pointing device input will occur”
Greg: hierarchical: pointing device, focuse location, then visual indicator of focus location
<AllanJ> ACTION: Jallan to write Jan about clarification of pointing device focus [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action16]
<trackbot> Created ACTION-369 - Write Jan about clarification of pointing device focus [on Jim Allan - due 2010-04-22].
Jim: no objections
<AllanJ> ACTION: jeanne to Pointing Device Focus The screen location where pointer input will occur if a viewport is active. There can be multiple pointing device foci, for example when using a screen sharing utility there is typically one for the user's physical mouse and one for the remote mouse. NOTE: this term is not used in the document other than the glossary. to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action17]
<trackbot> Created ACTION-370 - Pointing Device Focus The screen location where pointer input will occur if a viewport is active. There can be multiple pointing device foci, for example when using a screen sharing utility there is typically one for the user's physical mouse and one for the remote mouse. NOTE: this term is not used in the document other than the glossary. to the glossary [on Jeanne Spellman - due 2010-04-22].
Greg: principle 2 -- selection
should be one of the criteria
... selection, highlighting a focus are all currently missing
from 2.1 and all should be there
Jim: could fall under 2.16? subset of an element?
<Greg> So to 2.1.6 add bullets for selection, highlighting, and input device foci.
Jim: highlighting versus selection?
Greg: e-mail with screenshots that clarified. Highlighting can be used for many different things -- one is to indicate selection, but it's also used for other things such as highlighting matched text after a search operation, when navigation is separated from focus-- using search key -- highlighting is very broad
<jeanne> ACTION: to change 2.1.6 to add bullets for selection, highlighting, input device focuses [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action18]
<trackbot> Sorry, couldn't find user - to
<jeanne> ACTION: jeanne to change 2.1.6 to add bullets for selection, highlighting, input device focuses [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action19]
<trackbot> Created ACTION-371 - Change 2.1.6 to add bullets for selection, highlighting, input device focuses [on Jeanne Spellman - due 2010-04-22].
<AllanJ> ACTION: Jeanne to add Selection http://www.w3.org/2002/09/wbs/36791/DefinitionOfFocus/results#xq14 to the glossary [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action20]
<trackbot> Created ACTION-372 - Add Selection http://www.w3.org/2002/09/wbs/36791/DefinitionOfFocus/results#xq14 to the glossary [on Jeanne Spellman - due 2010-04-22].
Jim: any objections to the definition -- no objections
Greg: regardless of whether its useful in this document is it clear
Jim: perhaps if we were a couple more examples it would be useful but we don't need to get into now
<AllanJ> ACTION: jeanne to add Split Focus - A state when the user could be confused because the input focus is separated from something it is usually linked to, such as being at a different place than the selection or similar highlighting, or has been scrolled outside of the visible portion of the viewport. [Note: this term is not used in the document other than the glossary. This may or may not... [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action21]
<trackbot> Created ACTION-373 - Add Split Focus - A state when the user could be confused because the input focus is separated from something it is usually linked to, such as being at a different place than the selection or similar highlighting, or has been scrolled outside of the visible portion of the viewport. [Note: this term is not used in the document other than the glossary. This may or may not... [on Jeanne Spellman - due 2010-04-22].
<AllanJ> ...stay in the final document, but is a useful concept.] to glossary
Jim: comments about adding caret
Greg: rather than a reference to caret browsing in the definition why not an example -- keeps definition as concise as possible
Jim: is an example of user versus developer? Developer caret, user cursor
Greg: we should use both terms -- the commonly used terms because no one term will be useful to everybody
<Greg> Indicator showing where keyboard input will occur in text (e.g. the flashing vertical bar in a text field, also called a caret).
Greg: difficult to define browsing -- navigating within a block of text
<AllanJ> ACTION: jeanne to add Text Cursor - Indicator showing where keyboard input will occur in text (e.g. the flashing vertical bar in a text field, also called a caret). [recorded in http://www.w3.org/2010/04/15-ua-minutes.html#action22]
<trackbot> Created ACTION-374 - Add Text Cursor - Indicator showing where keyboard input will occur in text (e.g. the flashing vertical bar in a text field, also called a caret). [on Jeanne Spellman - due 2010-04-22].
Jim: any objections to using definition as Greg wrote it in IRC-- no objections
<jeanne> no objection
Jim: any preference for dates,
November 1-5
... any objections to latter part of the week -- slightly
better chance of Simon participation -- no objection
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/carat/caret/ Found Scribe: KimPatch Inferring ScribeNick: KimPatch Default Present: Greg, Jim_Allan, Jeanne, KimPatch, sharper, kford Present: Greg Jim_Allan Jeanne KimPatch sharper kford Regrets: MHakkenin plauke WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 15 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/15-ua-minutes.html People with action items: 2.1.6 change jallan jeanne jeannes to WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]