There are two good reasons why non-attribute specifiers should not be mixed
into a hash of attributes. There are two of these specifiers, primarily -
:xpath, and :label (there are more but I'll focus on these two).

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.

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>). 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.

As far as I know no element has a 'index' attribute, but I don't like mixing
it into the attributes hash either.

Jari Bakken <[email protected]> wrote:

> This is a minor point, but :text and :value are not "attributes on the
>
dom" according to the HTML spec (they do appear, but only on a small
> set of elements). :text in particular is definitely special cased in
> Watir (e.g. it should match against the inner text for <textarea>  and
> against the @value attribute for <input type=text>).
>

: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.

:text maps to textContent or innerText, which are attributes on the dom,
though they are problematic ones. those are not html spec'd, but they are
there in the browsers' doms, and they are used. (in the future these won't
map to innerText or textContent in vapir when I am done working around the
problems, but, will cross that bridge then. I don't think the solution will
have much bearing on the current discussion.)

: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.

-Ethan


On Thu, Sep 9, 2010 at 19:16, Jari Bakken <[email protected]> wrote:

> On Fri, Sep 10, 2010 at 12:22 AM, Ethan <[email protected]> wrote:
> > :xpath is a special case (there are a few of these), but it's not
> extracted
> > from a hash if one is given. In vapir, using a hash implies that all of
> the
> > hash pairs correspond to DOM attributes and attribute values of the dom
> > element. :xpath isn't supported as a hash key, since it's not an
> attribute
> > of the element on the dom, so no exception is made for it. It is only
> > supported as a 'how' in (how, what) arguments - that is to say,
> >
> > element(:xpath, '//whatever')
> > will use an xpath locator, whereas
> > element(:xpath => '//whatever')
> > will look for an element with an attribute called 'xpath' with a value of
> > '//whatever' (which won't exist).
>
> This is a bug, in my opinion.
>
> > I think that this makes sense, because the only reason to use a hash is
> to
> > combine multiple selectors. There is no way to combine :xpath with any
> other
> > selector. (theoretically, maybe, but I haven't implemented it that way
> and
> > don't plan to.) So, no exception is made for :xpath as a hash key.
>
> Right. watir-webdriver currently will just use the xpath given and
> ignore anything else - a more correct approach would probably be to
> raise if additional selectors are given.
>
> But I think not allowing (:xpath => "foo") as an equivalent of
> (:xpath, "foo") is just adding unnecessary API complexity and will be
> super confusing to users. The less exceptions and special rules to
> remember, the better.
>
> > :text and :value aren't special cases, they are both attributes on the
> dom
> > and can be sensibly used together in a hash of attributes.
> > I wrote a bit about this for the vapir wiki (just now, since I haven't
> done
> > a good job documenting it anywhere previously) - it's up
> > at http://wiki.github.com/vapir/vapir/locators .
> >
>
> This is a minor point, but :text and :value are not "attributes on the
> dom" according to the HTML spec (they do appear, but only on a small
> set of elements). :text in particular is definitely special cased in
> Watir (e.g. it should match against the inner text for <textarea>  and
> against the @value attribute for <input type=text>).
> _______________________________________________
> Wtr-development mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/wtr-development
>
_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development

Reply via email to