Tested on www.google.com main page in the URL bar:
returned result set length is 10 in FF 3.5, while in Safari 3/4 the returned result set length is 7. Three hidden input fields are missing from the returned result set.
I actually get "4" (in alert) on <http://www.google.com/> when using nightly build (r43663), but yes, input[type=hidden] doesn't seem to be part of returned NodeList.
It looks like WebKit is following HTML5 draft here, which says that :enabled should *not match* input elements with type=hidden <http://www.w3.org/TR/html5/interactive-elements.html#selector-enabled>
(In reply to comment #1)
> I actually get "4" (in alert) on <http://www.google.com/> when using nightly
> build (r43663), but yes, input[type=hidden] doesn't seem to be part of returned
> It looks like WebKit is following HTML5 draft here, which says that :enabled
> should *not match* input elements with type=hidden
The problem was I typed "www.google.com" but I was redirected to "www.google.it" where I did executed the test and I erroneously reported a wrong testing URL.
I assume FF3.5 follows CSS Selectors specs, rather than HTML5 ones. I'm not sure if FF actually prefers former one, or if this issue was just never raised, but we should still file a bug;
Having to work around different implementations (i.e. in Mozilla and WebKit) is not very pleasant.
I submitted bug #495217 to Mozilla bug tracking here:
Let see if devs can equalize their current implementations, or if there are other comments/reasons that we didn't consider.
As I said in the Mozilla bug report it seems to me there will be advantages in to following HTML5 specification for "UI element states" pseudo-classes.