See also: IRC log
rrsaent, set logs public
<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
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?
<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/
<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
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]