Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.Value for some HTML tags not implemented #27

Closed
Arithmomaniac opened this issue Jul 24, 2012 · 5 comments
Closed

.Value for some HTML tags not implemented #27

Arithmomaniac opened this issue Jul 24, 2012 · 5 comments
Labels

Comments

@Arithmomaniac
Copy link

According to W3C, the following elements have a string value property:

  • option
  • input
  • select (inherited from selected option)
  • param
  • button

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

@jamietre
Copy link
Owner

Not sure what I was thinking there, it certainly is easy enough to implement it consistently. I'll make this change sometime today.

@Arithmomaniac
Copy link
Author

Thanks. FWIW, you should probably clean up the Yoda Conditions inside the HtmlData comparisons, too.

@jamietre
Copy link
Owner

Intentional, it was not..

@jamietre
Copy link
Owner

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.

@jamietre
Copy link
Owner

Fixed in current development code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants