Case sensivity for attribute selectors

[p0deje]

There is a difference between CSS and XPath in case sensivity of attributes.

Having these elements on the page:

<form method="post" id="new_user" />
<form method="POST" id="delete_user" />

you can query them in browser:

> document.querySelectorAll('form[method="post"]')
< NodeList [<form id="new_user">, <form id="delete_user">] (2)

> document.querySelectorAll('form[method="POST"]')
< NodeList [<form id="new_user">, <form id="delete_user">] (2)

> $x('.//form[@method="post"]')
< [<form id="new_user">] (1)

> $x('.//form[@method="POST"]')
< [<form id="delete_user">] (1)

This comes from the fact that XPath considers attributes case sensitive while CSS does not.

Since now Watir only uses XPath selectors, using method: 'post' selector would return only one element. But when Watir is used with watir_css or watizzle gems, same selector would return two elements.

Also compare plain Selenium:

driver.find_elements(xpath: './/form[@method="post"]').count # returns 1
driver.find_elements(css: 'form[method="post"]').count       # returns 2

Since two behaviours cannot co-exist, I'm not sure what to do about it.

Related links:

• CSS3 Selectors Case Sensiviity

[titusfortner]

which would you prefer? Do we want to adjust our xpath selector to make this case independent?

[p0deje]

I think I'd like to make it case insensitive, but I'm afraid that might break many tests, so maybe we should keep that until Watir 7.

[abotalov]

Please note that in CSS only some attribute values are case insensitive.
For example, class / id / href are case sensitive.
It would be bad if Watir would search these (and other such attributes) case-insensitively.

[titusfortner]

So, according to the spec

All attribute values are case-sensitive, except for the following:

accept
accept-charset
align
alink
axis
bgcolor
charset
checked
clear
codetype
color
compact
declare
defer
dir
direction
disabled
enctype
face
frame
hreflang
http-equiv
lang
language
link
media
method
multiple
nohref
noresize
noshade
nowrap
readonly
rel
rev
rules
scope
scrolling
selected
shape
target
text
type (except as specified in §10 Rendering)
valign
valuetype
vlink

These aren't parseable by IDL from that page, so we could hard-code this list and treat them differently.

@p0deje do you think this is worth doing?

[p0deje]

@titusfortner Oh, how did you find that?! Yes, I think it should be straightforward to just hardcode that list (or actually parse it from spec directly - we are not limited to IDL only) and make everything these case insensitive. Do you feel like you want to do that or me?

[twalpole]

Note, those are only case insensitive on the elements they are defined for - on elements they are not defined on, or on custom elements they are case sensitive. Also most (if not all) are enumerated types so if you’re going to fix the case sensitivity, letting search for random strings doesn’t make much sense

[titusfortner]

@p0dege if you could do it, it would be awesome. Especially if we can somehow use it from the html_elements file. But this is lower on my list for right now. I need to get capabilities issues fixed.

[p0deje]

@titusfortner I'll do my best but time is pretty limited now :)

@twalpole I don't get what you mean by "enumerated types". Can you elaborate?

[twalpole]

@p0deje https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#keywords-and-enumerated-attributes - case insensitivity is for the attributes defined to be allowed a specific set of values (enumerated attributes) on specific elements - If those same attributes were used on elements they are not defined for then they should be case sensitive. Whether that's worth worrying about is debatable though.

[p0deje]

I've prepared #856 to implement the solution, please have a look when you have time.

For now, I've just hardcoded case-insensitive attributes as I don't think it's going to change much. Otherwise, we can still add it to spec generator.

I hope I understood when attribute should be case-insensitive right 😄