According to W3C, the following elements have a string value property:
looking at the source in /source/CsQuery/Dom/Implementation/DomElement.cs, line 359, you're not implementing all of those. (And the lack of it for select in particular is causing problems.)
Not sure what I was thinking there, it certainly is easy enough to implement it consistently. I'll make this change sometime today.
Thanks. FWIW, you should probably clean up the Yoda Conditions inside the HtmlData comparisons, too.
Intentional, it was not..
More information on this. If you use the Val() method on a CQ object instead of testing the DOM element you will get the correct value for selects. The jQuery methods were completed long before most of the DOM element properties were built out, and migrating this logic from the jQuery method code was actually on my to do list. I should not have added the Value property in its incomplete state, I probably did so while porting unit tests that needed it.
This is representative of a weak area in CsQuery - while the CSS selectors and jQuery methods have very comprehensive test coverage, there are not many test specifically targeted at the DOM implementation. That said, for the most part the jQuery/sizzle/csquery tests depend heavily on it working, so there probably aren't a lot of glaring issues, but this is a clear indicator of why we write unit tests: to find holes that you didn't anticipate.
I am going to look at migrating tests from jsdom -- which is the only reasonably comprehensive non-browser implementation of the DOM other than CsQuery that I know of -- sometime soon.
Fixed in current development code.