- From: Silas S. Brown <ssb22@cam.ac.uk>
- Date: Sat, 27 Sep 2014 16:13:12 +0100
- To: Jeanne Spellman <jeanne@w3.org>
- Cc: "public-uaag2-comments@w3.org" <public-uaag2-comments@w3.org>
Thanks Jim. Regarding SB01 (not sure if 1.7.4 Save Copies of Stylesheets is really needed), yes the new additional explanation is good, especially the point about making sure the stylesheet is pretty-printed (which is not usually possible if you simply inspect the page's source code and fetch the stylesheet URLs from it, which is what I'm in the habit of doing). Highly complex stylesheets can still be difficult to make sense of though, even when pretty-printed. Some current browsers have "inspect this element" functionality which can help here - they tell you exactly which CSS rules were applied to the element you pointed at, and, as a bonus, include any overrides that were generated by a script rather than a CSS file. One addition that might be useful is in the case when a page's styles come from not just one CSS file but quite a lot of them (I've seen sites with over 20 CSS files all loaded from the same page, and no they weren't alternates, they were ALL applied) - the user might choose whether to save them individually or to merge. But I wouldn't worry too much about a browser lacking that addition. And one reason why it might be a good idea to have this function from inside the browser (rather than relying on command-line tools like "wget") is the page might be available only from behind a "login" page, and it's often quite a chore to set up wget with the correct authentication cookies just to get a copy of all the CSS files. (True, some servers will serve the CSS files even without correct authentication, but that's not always the case.) Regarding SB02 (Reflow Text possible misunderstanding) - OK let's hope the additional SC addresses the problem when it comes out. Regarding SB03 (1.8.11 Allow Top-Level Viewport Open on Request), I believe the problem I mentioned is caused by scripts intercepting the "mousedown" or "mouseup" event (rather than the "click" event), and therefore intercepting middle-clicks and (unintentionally?) causing these to perform some action on the page instead of opening the link in a new window. One solution might be to allow the user to specify which mouse buttons are allowed to generate Javascript events. For example, if the user says "do not allow any mouse buttons to generate Javascript events" then no click or mousedown / mouseup events are generated and clicks always perform the default browser behaviour; if the user says "allow only the left mouse button to generate Javascript events" then the other buttons will not; if the user says "allow left and right but not middle" then pages can override context menus but cannot override whatever the middle button is bound to (e.g. "open in new tab"). I'm not sure how exactly these options should be described to the user, or where to put them (probably in an "advanced" section somewhere), but being able to tell the browser not to generate JS events when I middle-click would stop a lot of annoying sites from overriding this "open link in new tab" shortcut. (Yes, there will be times when the site is so script-driven that "open in new tab" can't work anyway, but in these cases the user would find out soon enough; I find in most cases "open in new tab" certainly CAN work - and DOES work when you bring up the context menu and select it from that - but the site simply prevents middle-click from doing that job.) Regarding SB04 (stop event handlers) - glad the example has been added to the Reference to 2.11.3. It comes up on quite a few sites. Only problem now is: OK, so you can stop the scripts so they can't cause the page to flicker, but then when you come to click on the control, what if that click is processed ONLY by a script? You are then in the position of having to (1) position the mouse, (2) start scripts again, and (3) click. (And hope that the "flickering" problem doesn't start up again between steps 2 and 3, which it almost certainly will.) So I think it would be very nice to have some functionality that says "stop the scripts until my next click - and when I click, start the scripts again just before processing the click". (And yes I do know that I can give keyboard focus to the element, turn on scripts, and press an appropriate key, but that might not work if the page's author did not think to implement a keyboard alternative to clicking - a lot of Javascript-only controls out there recognise only mouse events, unfortunately. I hope there's a guideline somewhere else that says it should be possible to simulate mouse events by key presses. But that's a different issue - if you WANT to use the mouse to click on a control, and that control is handled only by Javascript, and there's no way you can approach the control with the mouse without stopping scripts first, then it would be nice if there were some way of saying "please turn Javascript back on just before processing this click".) One other solution to this specific problem might be to have an option that simply disables events like "onMouseEnter" and "onMouseOut" - in other words, let me move my mouse around over the window without telling any of the scripts on the page where my mouse cursor is. (Of course, when I click, THEN it will have to fire the "onMouseEnter" event before the "click" event, otherwise a lot of scripts might break. But don't send the "onMouseEnter" event when the user is just moving the mouse without clicking.) Or perhaps all we need is (maybe not at level A, but maybe at level AAA or something) - "automatically disable Javascript when not interacting with the page". I.e. when I click (or press any button on the keyboard), enable scripts to handle that event, and automatically disable them shortly after (how shortly? ideally "when the event handling is finished"). That way, we won't have scripts messing up the display based on a background timer or random mouse movements, but we can still use functions of a page that are implemented in Javascript. Although I still think it would make more sense to disable specific Javascript events, rather than trying to turn on and off the whole interpreter at the correct times. "Disable Javascript timer events" and "disable Javascript mouse-motion events" are definitely options that I would switch on at nearly all times (except on sites where you really can't get to the content without letting onMouseOver happen). Perhaps it should be worded as something like "prevent scripts from modifying the page in response to merely pointer motion", with a suggestion that this might be implemented by stopping the entire interpreter at appropriate times, or by suppressing certain Javascript events - we say what result we want and leave it to the browser implementors to decide how to do it. (Really clever implementors might want to let scripts run anyway but fail any attempts they make to change the DOM, or allow changes to proceed but don't actually display the result - but we needn't go into that. Stopping the interpreter or suppressing relevant events should be fine, just as long as it's possible to switch it all back on just before the crucial 'click' is processed.) Regarding SB05 (adjustable time limits), yes I think the new Section 2.9 is fine. Regarding SB06, yes that's fine. Thanks. Silas
Received on Saturday, 27 September 2014 15:13:39 UTC