One of the most puzzling things about web development is when something works in one browser, but doesn’t in another. Often this is the case when your document is not standards compliant. For example you declare that your markup is XHTML strict, but have a structural problem in your markup. Browsers will try to repair your document, but can take different measures to cope with the problem.
The way to avoid such differences is to ensure that at least your documents are up to spec. Running your website manually through the W3C validator is not an option. So I set out to make this a less painful exercise. Searching the internets provided me with the Tuckey ValidationFilter, but integrating it with our application was not really working, because of some CSS issues (z-index, fonts, alignment, coloring). Long story short, I’d figure taking up the ValidationFilter and integrating it someway into a little bit more Wicket like fashion. I’ve implemented it as a IResponseFilter and have it insert the necessary markup into the response at the end of the head and body sections when the original markup was invalid.
When you enable the HtmlValidatorResponseFilter in your project, you see your markup mistakes immediately when developing your application. No longer is standards compliant markup an afterthought, but directly visible the moment you fire up your local server and browser.
The htmlvalidator project contains an example application with valid and invalid markup. You can run it by starting the embedded Jetty server using the Start class in the src/test/java folder and pointing your browser to localhost:8080.
The project is available on my github space. The project needs to be build using Maven, but that shouldn’t hold you back trying it out. It mostly builds upon the code from the Tuckey guys, so major thanks go to them. I’m hoping to find an Apache License compatible, up to date, markup validator so we can ship this functionality out of the box with Wicket 1.5.
Things I’d like to improve:
- no more GPL code
- use Wicket components instead of a generated JSP for the error page
- integrate it into a debug console together with Ajax debug, ehcache stats, hibernate stats, page stats, wicket stats, etc.