W3C

- DRAFT -

SV_MEETING_TITLE

30 Jan 2014

See also: IRC log

Attendees

Present
kford, Jeanne, Jim_Allan, Greg_Lowney, Jan, Eric
Regrets
Chair
JimAllan, KellyFord
Scribe
allanj

Contents


rrsaent, set logs public

review comments -

<jeanne> http://www.w3.org/WAI/UA/2014/LCcomments.html

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0019.html

<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html

<scribe> scribe: allanj

<jeanne> Minutes discussing Silas comments

SB02: 1.8.7

gl: jan was talking about changing to reflowable text rather than reflowable content

ja: the comment is concerned with top-level-viewport (TLVP)

<Greg> Current wording: 1.8.7 Reflow Text: The user can specify that text content in a graphical top-level viewport reflows so the text forms a single column that fits within the width of the viewport. (Level A)

ja: if we remove TLPV does that solve the problem, or make more problem

gl: previous suggestion, clarify in the applicability notes. "When we refer to TLVP we mean all of the elements within the viewport"

<Greg> In the top-level applicability notes we could have something like "WHen this document refers to things 'in' an element, structure, or viewport, it includes elements within the entire descendant structure (e.g. 'text inside a table' also includes text within a span within the table)." ?

js: problem with this. know example is the table. but could destroy the readability if the page is a spreadsheet (data table), and all relations are destroyed.
... seems we could make things worse.

kf: did we mean for this to include tables

jr: we don't mean we want redrawing a table, just squishing it. this is what happens now
... this works for text, but images present limit on squishability
... we are not saying reflow a table, only reflow the text in a table.
... in content with absolute values we want a mode where use can override

js: this came from EO to change magazine layouts (multicolumn) to single column.
... pdf does not do this.

jr: assign an action

js: invite silas for more info?

SB03 - 1.8.11

<Jan> ACTION: Jan to Develop response to Silas comment on 1.8.7(reflow text) http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html [recorded in http://www.w3.org/2014/01/30-ua-minutes.html#action01]

<trackbot> Created ACTION-938 - Develop response to silas comment on 1.8.7(reflow text) http://lists.w3.org/archives/public/w3c-wai-ua/2014janmar/0015.html [on Jan Richards - due 2014-02-06].

<Greg> SB03: Re 1.8.11 (Allow Top-Level Viewport Open on Request) it might also be worth explicitly stating that, if the user performs some action whose normal meaning is "open link in new tab" (for example, middle-click on some browsers) then it should be possible for users to specify that such actions must ALWAYS perform that meaning, and cannot be overridden by the page author. Some Javascript...

<Greg> ..."onClick" events manage to (accidentally) override middle-clicks and cause something to happen on the current page instead of opening a new tab. (In many cases this can be worked around by right-clicking on the link and selecting "open in new tab", instead of middle-clicking, but that can be extra effort and it's an annoyance.)

ja: thought middle click controlled by mouse not the browser.
... this sounds like a new SC. Persistance of behavior setting, for each website or across all websites.

<Greg> GCL: I agree with the sentiment but unfortunately as you say those non-standard behaviors are usually implemented in Javascript, so the user agent may not be able to interfere in any reliable way other than by blocking scripts altogether. (It could fail a script's calls to the function that opens a new top-level viewport, but it can't force the script to make such a call.)

<Greg> GCL: For the working group, what would we expect the user agent to do if the user has said content can't open new top-level viewports, then the user clicks a control that is explicitly to do so? Should the script's call to open a new tab simply fail? Should the user agent warn the user, so as to explain why their click isn't working? I don't think it should, for example, simply take the link...

<Greg> ...in the current viewport, as that could break some scripts.

<Greg> Current wording: 1.8.11 Allow Top-Level Viewport Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA)

gl: when action opens a new viewport, don't want a script to open a new tab

js: saying if user sets a mapping for some action, then don't let the author override the mapping
... this seems to be related to 2.3.5

gl: or 2.8.1

ja: middle click - open link in new tab works in IE, FF, Chrome

js: what is the generalization not just for middle click.

gl: explains his comment

<Greg> A) we could use my proposed response above, or b) we could add an SC saying that the user agent should not allow scripts to override default inputs which are associated with a specific list of actions, such as opening a link in a new tab. However, I don't favor the latter.

gregs response: I agree with the sentiment but unfortunately as you say those non-standard behaviors are usually implemented in Javascript, so the user agent may not be able to interfere in any reliable way other than by blocking scripts altogether. (It could fail a script's calls to the function that opens a new top-level viewport, but it can't force the script to make such a call.)

jr: there are special cases where sites could not over-ride specific actions (ALT-D address bar)

gl: could come up with a list...

<Greg> It seems a daunting task to create a list of commands that scripts should not be allowed to override, and the list would ideally change over time and between products.

ja: seems prescriptive

<Greg> 2.3.5 was the SC that refers to "conventional bindings for the operating environment (e.g. arrow keys for navigating within menus)".

jr: order of keypress - OS, browser, javascript, etc
... 2.3.5 and others give conflicting advice.

kf: the lowest common denominator wins. the OS could say, I will take all input.
... the goal is for applications to play well together

jr: browser could reveal UI of a page
... could we extend 2.3.5 to include mouse and gestures?

kf: why if I am a UA developer, should I have to do this. The OS should handle it.

jr: if someone does a keyboard remapping at the OS level. then user doesn't need to do it in the UA

kf: we may have over reached.
... if I hit alt I and want it to be alt J, you can only remap commands within the user interface.
... but 2.3.5 says any key combination can be remapped.

<Jan> Keytweak remapper for Windows: http://core.ecu.edu/psyc/wuenschk/Help/KeyTweak.htm

kf: do we expect UA to allow its UI to be remapped to what ever keys necessary.

***regroup***

gregs response: I agree with the sentiment but unfortunately as you say those non-standard behaviors are usually implemented in Javascript, so the user agent may not be able to interfere in any reliable way other than by blocking scripts altogether. (It could fail a script's calls to the function that opens a new top-level viewport, but it can't force the script to make such a call.)

Resolution: Reject comment, per gregs response: I agree with the sentiment but unfortunately as you say those non-standard behaviors are usually implemented in Javascript, so the user agent may not be able to interfere in any reliable way other than by blocking scripts altogether. (It could fail a script's calls to the function that opens a new top-level viewport, but it can't force the...
... script to make such a call.)

<Jan> FYI: And keyboard remapping on Android http://www.howtogeek.com/175267/the-htg-guide-to-using-a-bluetooth-keyboard-with-your-android-device/

SB04 - 2.6

<Greg> SB04: Re 2.6 - I think there definitely needs to be some easily-accessible switch to temporarily STOP all event handlers, then start them again later. Some websites have badly-implemented scripts that try to do fancy things as you move the mouse over elements, and these play badly with user stylesheets. For example, eBay's feedback mechanism can go horribly wrong at very large zoom levels....

<Greg> ... You move the mouse over the "5 star" rating, but as you do so, it adds an extra element into the text, causing the whole thing to reflow (the designers weren't expecting it to reflow - they didn't think it might be zoomed), and the reflow takes the star somewhere else so it is no longer under the mouse pointer, and this causes another event, undoing the first event, but then the star is...

<Greg> ...again under the pointer, and so on ... result is a rapidly-flickering control, and less than 50/50 chance of it being activated when you click. Only workaround is to zoom out or increase the window size, but I wish I had a button that says "stop all event handlers until my next click" (bonus points if the user agent can AUTOMATICALLY detect the "rapid-fire" situation and turn them off...

<Greg> ...until the next click).

greg comment: SC 2.11.3 already requires the user be able to turn off scripts, but it does not require that it be easy or convenient (nor that it be specific to a the current top-level viewport). That could potentially be added as a separate, lower-level SC, but I'm not sure how we'd say what is required to be convenient. By the way, your example is a good one that we could add to the...

scribe: Implementing document.

ja: this is not just a problem with scripts, but also CSS. Example of bold link on hover, bold takes more space causing text to shift, moving link from mouse, so link becomes unbold, but then is under mouse and becomes bold...repeat...nice flicker

gl: 1.7.3 allow tuning off author css

<Greg> Problems caused by behaviors in author-provided stylesheets (e.g. links getting larger when hovered over) can be disabled by 1.7.3 Disable Author Stylesheets.

<Greg> This requires point of regard to be maintained when the user turns styles on or off: 1.8.6 Maintain Point of Regard: The point of regard remains visible and at the same location within the viewport when the viewport is resized, when content is zoomed or scaled, or when content formatting is changed. (Level A)

ja: are 3 comments on 2.6.1

chrome says it can't be done.

gregs response

GCL: In this case the success criteria is actually limited to "recognized input methods explicitly associated with an element", so the user agent is not expected to present the user with a list that includes every possible event being handled by a global event listener, if the specific technology does not allow it to tell which specific events are being watched for. However, if the user...
... agent can tell, for a given element, which events are being listened for by a element-specific, container element, or global listeners, it should be able to make this list available to the user. If you still feel this is a problem could you please

elaborate

gl: the script has to register with the browser what it wants to listen to. it could be a generic listener, or specific.

<Jan> +1 to GCL's response on CR06

Resolution: CR06. ask for more input. per greg's response: GCL: In this case the success criteria is actually limited to "recognized input methods explicitly associated with an element", so the user agent is not expected to present the user with a list that includes every possible event being handled by a global event listener, if the specific technology does not allow it to tell which...
... specific events are being watched for. However, if the user agent can tell, for a given element, which events are being listened for by a element-specific, container element, or global listeners, it should be able to make this list available to the user. If you still feel this is a problem could you please elaborate.

jr: SB04 this is covered by 2.11.3. as per GCL: SC 2.11.3 already requires the user be able to turn off scripts, but it does not require that it be easy or convenient (nor that it be specific to a the current top-level viewport). That could potentially be added as a separate, lower-level SC, but I'm not sure how we'd say what is required to be convenient. By the way, your example is a good...
... one that we could add to the Implementing document.

Resolution: SB04 not accepted, per GCL: SC 2.11.3 already requires the user be able to turn off scripts, but it does not require that it be easy or convenient (nor that it be specific to a the current top-level viewport). That could potentially be added as a separate, lower-level SC, but I'm not sure how we'd say what is required to be convenient. By the way, your example is a good one that...
... we could add to the Implementing document.

s/reject/not accepted

Summary of Action Items

[NEW] ACTION: Jan to Develop response to Silas comment on 1.8.7(reflow text) http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html [recorded in http://www.w3.org/2014/01/30-ua-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-01-30 19:39:07 $

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/2.8.2/2.8.1/
FAILED: s/reject/not accepted/
Found Scribe: allanj
Inferring ScribeNick: allanj
Default Present: kford, Jeanne, Jim_Allan, Greg_Lowney, Jan, Eric
Present: kford Jeanne Jim_Allan Greg_Lowney Jan Eric

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 30 Jan 2014
Guessing minutes URL: http://www.w3.org/2014/01/30-ua-minutes.html
People with action items: jan

[End of scribe.perl diagnostic output]