On Fri, Sep 10, 2010 at 17:58, Jari Bakken <[email protected]> wrote:
> >On Fri, Sep 10, 2010 at 5:21 PM, Ethan <[email protected]> wrote: > > First (idealistic reason), a hash shouldn't behave the same way as giving > > two arguments. A hash, as a data structure/way of thinking about data, > > represents many items - it made sense to add to watir's api in order to > > specify multiple attributes. It doesn't make sense if you can use it to > > specify only one value (as in :xpath) and get an error using a hash with > > multiple keys. > > I'm not convinced - even though what you're proposing is consistent, I > still think it adds unnecessary complexity, API-wise. Not going to try > and stop you from doing this in Vapir, of course :) > yeah, I did not have high hopes for my arguments on what data structures should mean to convince anybody here - ah, well. > Second (practical reason), while it is fine to treat :xpath as a special > > case because it's not an attribute, it doesn't work with :label, because > > :label is a valid attribute of some element types (two that I see, > <option> > > and <optgroup>). > > Actually, it's a valid attribute on all elements - it's defined on > HTMLElement. > so it is - I was looking at the html 4.01 spec, but I see it is on everything in 5. > > if you do container.option(:label => 'foo') then will it > > look for a <label> with text 'foo' pointing at an <option>, or an > <option> > > with a label attribute with a value of 'foo'? It's not the best > distinction, > > but at least with my way you can unambiguously define that, since using > hash > > means attributes, when :label is used in a hash it is an attribute; with > two > > arguments, :label is a special specifier meaning to look for a <label> > > element. > > I don't think this is a good argument for the hash-means-attributes > proposal, but I do agree with the main point, that :label is > problematic. My main point was meant to be that *ambiguity *is problematic - :label is just a very good example of problematic ambiguity in the API. The :label specifier itself is a good and useful thing, I think, as long as it can be differentiated from the dom attribute. One solution would be to have :label always match the > attribute, and then add Label#target or similar (e.g. Label#control as > in DOM, or maybe Label#referenced_element). Perhaps we can agree to > implement one of those? :) > This is implemented in vapir as Label#for_element. So :label as a specifier would no longer be used as anything to do with <label> elements, just the DOM label attribute? Removing :label's special meaning is not the solution I had in mind; it is a useful specifier. Removing the API ambiguity would be preferable, and having two-argument and hash arguments having different meanings accomplishes that. > As far as I know no element has a 'index' attribute, but I don't like > mixing > > it into the attributes hash either. > > The option element has an index attribute. That's actually an argument > for removing :index from both hash and how-what locators. But I still > think it's fine to leave :index and let users use XPath for the > uncommon cases. > Sounds like a very good reason to drop it to me, at least from the hash. (hey, wow, did this actually just hit the original topic of conversation?) > > :value very certainly is an attribute on the dom, and is in the html > spec. > > I didn't say for every type of element; it is only a recognized attribute > in > > vapir for input elements. > > Right - so both celerity and watir-webdriver allows this: > > browser.button(:value => "foo").html #=> <button>foo</button> > browser.button(:value => "bar").html #=> <input type=button value=bar> > > I'm pretty sure we picked that up from Watir. > That's IE behavior, really, not watir. With <button>foo</button> IE sets the value attribute on the dom to 'foo'. firefox doesn't, though. > > :text doesn't map to value for <input type=text>. that doesn't make any > sense to > > me, why would it do that? watir doesn't do this either. nor should it, > that is > > just confusing. anyway, that's even further off-topic. > > Ah, you're right about Watir not doing this. Both celerity and > watir-webdriver does. Similarily, calling value() on a <textarea> will > return its inner text. > Every browser sets the value of <textarea> to its contents, the driver doesn't need to do anything around that. The reason I guess is the wish to have the following be true, even if > the element changes from <input type=text> to <textarea> or vice > versa: > > browser.text_field(:text => "bar").text #=> "bar" > browser.text_field(:value => "bar").value #=> "bar" > > Basically it's just a side effect of text_field() finding two element > types, similar to the case above for button(). well, #value will always work correctly. as for #text, well, <textarea>s are kind of weird, and #text is a pain.
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
