Re UAAG20 comments from Silas S. Brown

Some thoughts on the comments from Silas S. Brown (http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0000.html):

    SSB: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed.


GCL: The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed.

    SSB: 1.8.7 (Reflow Text) - I think there's a possible misunderstanding here with the wording "text content in a graphical top-level viewport".  Some developer might think "oh, if it's only about text in a top-level viewport, then it doesn't apply to text in a table (or other layout device) within that viewport", which is not ideal especially if such layout device is being used unnecessarily.  Maybe add something like "This applies even if such text is included within other structures"?


GCL: Reasonable concern...

    SSB: 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 "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.)


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.)

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 in the current viewport, as that could break some scripts.

    SSB: 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.  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 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 until the next click).


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.

    SSB: Re 2.9.1 (Adjustable Time Limits) "the user can extend the time limits", would it be a good idea to add "indefinitely"?  Just in case some developer thinks "just let them have a 50% extension".


GCL: I agree in principle; I'm always afraid such broad requirements invite solutions that meet the letter of the SC without meeting its intent.

     Thanks,
     Greg