We actually had a long discussion at the Ruby test code hackathon in Toronto last month about the proper behavior of the #text and #text_content methods and how they relate to the text locator (which handles String and RegExp values differently). I came into it arguing for changing the text locator to only find visible text, but after a lengthy considerations of backward compatibility and the fundamentally unique nature of text nodes as it relates to the DOM, especially considering the difficulties of dealing with nested text nodes with various possibilities for hidden . It was decided to keep the current text locator behavior for String values and to adjust the text locator behavior for RegExp values to match. This provides more flexibility and backward compatibility at the expense of being potentially confusing for things with multiple matches.
All of this being said, the correct response when using Watir is: browser.a(text: 'something', visible: true).click` There are several ways to accomplish this, but this is what fits our API. Feel free to use any other way you want, but it isn't helpful to tell other users to do things that encourages them to work against rather than with our API. I get that you've found what you consider is a clever way to use Watir and save a couple extra wire calls, and that you don't care about the resulting lack of encapsulation. Good on you. This mailing list is not the right forum for you to push this idea, so please stop. Thank you for your understanding. On Wednesday, October 25, 2017 at 2:30:36 AM UTC-5, rajagopal...@gmail.com wrote: > > Please reject my last mail, I was wrong about b.link(link_text: > 'something').click > > Read this one, I have explained the advantage of link: over xpath: > b.element(text: 'something').click > > > It would create the selenium equivalent of > > driver.find_element(xpath: "//*[noramlize-space()='something']").click > > It would perfectly work if this xpath matches only one, but there are more > and rest of them are hidden it would choose to click the first one, not the > one which is visible, but If you write the below code > > b.element(link: 'something').click > > It would write the selenium equivalent of > > driver.find_element(link: 'something').click > > > it would perfectly choose the visible one by rejecting all the invisible > one, > > > You may say to me that I could achieve the same by passing 'visible: true' > as the second parameter, but WATIR does here is, it iterates over all the > links before it chooses the visible one. > > So using link: over xpath: has many advantages, That's why I said we need > to go for xpath when we can't use any other available locators. > > On Tuesday, October 24, 2017 at 8:22:36 PM UTC+5:30, Titus Fortner wrote: >> >> If you want to use Watir without its powerful element location API, and >> use only the element method and only Selenium locators, you are more than >> welcome to do that. >> But stop telling other users that it's the right way to do it or that >> it's better, because it isn't. >> >> Watir provides an easy way for the user to combine multiple location >> strategies to uniquely identify an element without needing to use XPath. >> What Watir sends to the driver is irrelevant to the user. >> >> XPath for the user => Bad >> XPath for the driver => Good >> >> Separating what the user knows and what the driver knows is the whole >> point, and your comments are only confusing the issue. >> >> >> >> On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, rajagopal...@gmail.com >> wrote: >>> >>> yes, that's what I am saying xpath usage must be the last one. If we >>> could use available selenium-webdriver locators then we need to prefer that >>> one. >>> >>> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote: >>>> >>>> The only reasons not to use xpath are that it is hard to read, and >>>> difficult to write such that it is not brittle. Neither of these apply to >>>> how Watir implements its location system. >>> >>> >>>> >>>> -- -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. watir-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "Watir General" group. To unsubscribe from this group and stop receiving emails from it, send an email to watir-general+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
