- From: Simon Stewart <simon.m.stewart@gmail.com>
- Date: Sun, 3 Nov 2013 20:10:08 +0000
- To: John Jansen <John.Jansen@microsoft.com>
- Cc: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
- Message-ID: <CAOrAhYE1zBzqw02ckaLPDEHTCxMMEA8EyYFS4yULemGhD_vb7Q@mail.gmail.com>
Hi John, Thanks for the email. Answers inline. On Tue, Oct 29, 2013 at 6:00 PM, John Jansen <John.Jansen@microsoft.com>wrote: > This is just some general question/feedback. Let me know if it would be > better in separate emails... > I'm happy to get feedback in any format :) As long as inline replies are okay, I think it's manageable to put everything into a single email. > Thanks guys! > > Navigation is not really been called out the way users navigate the web. > * Back > * Forward > * Refresh > There's are in the JSON wire protocol of the selenium project. Adding them to the spec is a good idea, and I've made a note to do so. > Mouse/ Keyboard input > * Hover (css :hover as well as the various javascript mouse events > including nested menus). Is this for v.next? > Hover would be implemented by moving the mouse to the location of an element, rather than explicitly handled as a separate command. Once we flesh out 14 this may be clearer. > * Web app controls are not called out. For example, custom context menus > as well as the following functions: > o Right click > o Double click > o Scroll in/ out > o Autoscroll > o Click and drag > o Pinch > These are what the selenium project refers to as "Advanced User Interactions" (as opposed to the simple interactions offered from WebElement) It's something we wrestled with a lot: we like keeping the surface area of the API as small as possible, but having said that, there's a need for the ability to express rich interactions from multiple devices. A laptop with a touchscreen and a separate pen input device (like a Wacom tablet) is the pathological case, but things like tablets are already making things interesting. I believe that these are handled by a combination of section 14 and Mozilla's proposal for simulating multiple simultaneous inputs, which you may remember from the last face to face. Those raw commands are obviously pretty opaque to users, which is why most of the existing webdriver bindings offer something similar to Actions.java<http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/interactions/Actions.html> (I use the java bindings as an example, since they're the ones I'm most familiar with) Out of curiosity, what is "autoscroll" in this case? I'm not familiar with the term. > "Keyboard input from the physical keyboard should be ignored" > * Does this mean the physical mouse should be ignored as well? > Yes. Noted, and I'll add it to the spec. Good catch :) > Send keys to page itself, rather than webelements... > Handled by sending those keyboard inputs to the BODY element. Alternatively, using the "Actions" class above gives you a mechanism to use that sends keyboard input to the current active element (as defined by HTML 5) > * Backspace for back > * Spacebar to scroll > * Tab to select elements > If input events are implemented correctly, these should "just work". Certainly, I've done accessibility testing with firefox on Windows before by tabbing through the various fields of a page. It one of the reasons that "Actions.sendKeys(CharSequence...)<http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/interactions/Actions.html#sendKeys(java.lang.CharSequence...)>" exists. I've also seen backspace work for "back" in one particularly painful debugging session. > Capabilities > * Support for extensions > I'm not entirely sure what you mean. Are you suggesting we extend section 18 to also cover extensions by vendors? If so, that's a great idea. > Detecting form state > * Checkbox and radio button IWebElements should be able to return their > checked state > This is covered in section 10.2. We refer to the property as "selected", but the definition of "selectable" is: "A selectable element is either an OPTION element or an INPUT element of type "checkbox" or "radio"." > * Radio button groups should be able to return which button (if any) is > checked > I do this by iterating over the elements in the button group until I find the button which is selected. Does that approach not work for you? Regards, Simon
Received on Sunday, 3 November 2013 20:10:35 UTC