Support for such attributes should be implemented in WebKit. These attributes do nothing but "deactivate" validation on form elements.
Sadly, much was lost on this bug due to database corruption. The key points were: Michelangelo attached a patch for review; eseidel gave it r-, with the following comment: --- Comment #10 from Eric Seidel <eric@webkit.org> 2009-08-20 17:21:28 PDT --- (From update of attachment 35234) These tests look pretty vacuous. They would pass w/o any of the code changes it seems. +v = document.getElementsByName("victim"); +for (i = 0; i < v.length; i++) { + shouldBe("v[i].formNoValidate", "false"); + v[i].formNoValidate = true; +} +for (i = 0; i < v.length; i++) + shouldBe("v[i].formNoValidate", "true"); Personally I prefer to write js-only tests, instead of making manual templates as you have done. Meaning, if you convert your form dom creation into JS calls, this whole test can just live in a single .js file in resources/ and you can use make-script-test-wrappers to generate the wrapper for you. It seems it would be more interesting to test what getAttribute('novalidate') gets set to when you change the JS properties.
Created attachment 38391 [details] Patch v1
Adele commented about the proposed patch: HTMLFormControlElement::isInNoValidateState() should land once it's being used. Eliminating it, for now. But it shall be back.:)
Created attachment 38425 [details] Patch v.1a
Fixed in r47655.
Tree broken, investigating...
Fixed in r47658. Committed patch was incomplete, modifications in HTMLFormControlElement.h present in the r+'ed patch were missing.;)