Feel free to open issues with suggestions, questions or anything.

If is a bug, try to describe a reproducible scenario and the error stack trace (if exists).

If the issue is about selenium and not seleniumQuery we will let you know.

Some general tips for adding new functions.

• Create function in SeleniumQueryObject interface
• Create function implementation class (see StreamFunction for example)
• Create function in SqObject using the implementation class from example above
• Create impl. test class (such as StreamFunctionTest)

Driver/Browser	CI	Coverage	Docker	Grdl/Mvn	Status
Saucelabs [run sauce]	Codeship	No	No	Maven
Chrome Not Headless	Shippable	Yes	Yes	Gradle
Chrome Headless	-
Firefox	Appveyor	Yes	No	Maven
Phantom	Travis	Yes	No	Maven
HtmlUnit JS On	Wercker	Yes	No	Maven
HtmlUnit JS Off	CircleCI	Yes	Yes	Gradle
Edge	-
IE	-
Opera	-
jBrowserDriver	-

Tool	Status
codecov
shippable

Goals:

• Have a uniform behavior thoughout targeted WebDriver implementations
  • A given code should behave as similar as possible in all WebDrivers.
    • Selenium itself takes care of that, but it does leave some room for improvement
    • This is important to our functions as well, they should behave the same regardless of WebDriver implementation (browser) used
• Mimic jQuery's interface and behavior, but...
  • Do it all, when possible, from the user's perspective
    • e.g. $().val("") types content instead of setting the value attribute.
  • Improve it a little (e.g. throw exception when invalid selectors, such as "div:file" are used)
• Add functions that tackle common problems when dealing with web (testing) automation, such as waiting ($().waitUntil())
• Add quick commands for common usage patterns (such as driver builder does)
• Simplify overall usage with convention over configuration

Non-goals:

• Add all jQuery's functions
• Replace WebDriver

• What went bad?
  • Since the selector system supports not only pure CSS (it allows the extended CSS supported by jQuery- and implemented by Sizzle), its implementation is a challenge by itself.
    • The first version used regexes, didn't work so well and never made it into a release
    • The second version (released as 0.9.0) converts every CSS selector into a XPath expression and executes it.
      • The advantage is that this makes Selenium bring every element the user wanted already, without the need to iterate over them or anything.
      • The problem with this approach is that not every CSS can be translated into an equivalent XPath expression (e.g. :selected or :visible)
    • The third version (currently under development, called "secondgen") will parse the selector and...
      • If the selector is plain CSS or XPath, use it directly
      • If the selector is an extended CSS that can be translated fully to an XPath expression, than translate it and use it
      • Otherwise, translate the CSS to the XPath expression that brings the smallest numbers of element possible and then iteratively filter the results before returning

Feel free to request, suggest, create pull requests. As said, any opinions/help are more than welcome!