On Fri, May 7, 2010 at 8:42 PM, Jari Bakken <[email protected]> wrote: > Just to be clear: watir-webdriver implements 0-based indexing, but it > does not return the first element when calling an element method > without arguments
That's what i meant also. >>> Definitely. This is a priority for me in my fork. >> This is already done in Watir WebDriver. >> > > No, watir-webdriver does not do this (yet). divs(:id => "foo") will > return all divs, not only those matching the argument. It's a bug. Sorry, i understood from the Google Wave that this feature already exists as a side effect... > I'm not a big fan of #2 - the default "hows" in 1.X were confusing > enough, and they're gone in watir-webdriver. Limiting it to id would > help somewhat, but I do like the selectors to be explicit. As i understood then they were confusing because there were many exceptional cases and different default how's to different elements. > Another > argument is that migration will be easier if the single-argument > syntax raises an ArgumentError rather than an UnknownObjectException. Agree with that one though. > > #3 was discussed in the "Watir Roadmap" wave, copied here: > >>> Obsoleting non-hash syntax. >>> Nov 16, 2009 >>> >>> Bret: >>> For example, I'm thinking that Watir 2.0 should only support hash syntax. >>> Thus: browser.text_field(:id => 'name').set 'Grayson' will continue to >>> work, but browser.text_field(:id, 'name').set 'Grayson' won't. I haven't >>> made up my mind on this, and am eager for feedback, but I want to give you >>> a picture, right now of the kind of disruptions I'm anticipating for Watir >>> 2.0. >>> Nov 17, 2009 >>> >>> [email protected]: >>> Any specific reason for going ahead with hash syntax? I am sure that it >>> will break a lot of stuff >>> Nov 17, 2009 >>> >>> Deniz: >>> I agree on this, I recall this discussion but there was no conclusion. I >>> also vote for staying compatible with the old syntax, using only hash will >>> break a lot of stuff and confuse a lot of people. >>> Nov 17, 2009 >>> >>> Bret: >>> I can back off on this. Mainly, my thinking is that simplifying the api >>> makes it easier to create implementations. Bret, what did you mean by that exactly? > PS. While we're on the topic; there are two other APIs that needs > discussion: tables and cookies. I'll bring them up in separate threads > when I've had time to create some sensible proposals. Same here regarding with one table bug and i'll write about it shortly. _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
