W3C Validator, now with HTML5 flavour
A lot of recurring discussions among the W3C staff and contributors, whenever the question of “what should be the focus of our validation tools” arises, seem to split the world in two camps.
On one side, the proponents of the “reference tool” would argue that our tools are being perceived and used as a reference by millions of Web authors daily, and as such, the main focus should be to reliably validate established standards. Most of the effort should go towards fixing any bug in supporting the validation of documents that use document types amongst W3C recommendations.
On the other side, the advocates of the “feedback loop” approach would find it very exciting that W3C has tools used by so many Web Designers: shouldn't we use this as an incredibly effective feedback mechanism for the technologies still in development? Indeed, fairly few people have the time to review in depth some very large specifications, but many would be happy to try new features on their Web Sites and could test them, if our validators supported the cutting edge.
The choice, so far, was seldom dictated by any strategy, but rather by a simple equation: our open source software activity was (and still is) working on a shoestring, and our staffing was just enough to maintain the necessary support for established standards, and any advanced or experimental development would be done by W3C open source contributors, or indeed, outside of W3C. To mention but a few: Henri Sivonen doing great work in the past few years with validator.nu, while Petr Nálevka and Jirka Kosek's experimentations with compound XML documents resulted in relaxed.
The dichotomy, however, is a false one. Of course, until the validators project can have a more sizeable budget, their capacity for advanced development will reside in the hands of volunteer coders, and indeed, there is nothing forcing anyone to do this experimentation at the W3C: some will prefer the joy of having one's own project and the freedom it brings, others will see value in a large user community and an existing project infrastructure. But nothing stops these projects from working together.
The solution, indeed, is in resisting the “not invented here” syndrome, and embracing great projects, whether they are developed within W3C or by someone in the Web Community. We already provided a home for the feed validator. And yesterday, we launched a new version of the markup validator which integrates with the validator.nu engine for HTML5 support. As we wrote in the changelog:
HTML5 is still work in progress and support for this next generation of the publishing language of the World Wide Web will remain experimental, but this integration should provide experimentation grounds for those interested in trying on authoring in this new version of html, as well as a feedback channel for the group working on building a stable, open standard.
Here is hoping that this integration will be the proof that our tools can be reliable and cutting edge, hoping that these tools will quicken and improve the process of development and standardization of HTML5.
So… does your site pass the HTML5 test? And as a bonus gift, if you want to check your whole site's HTML and CSS in a progressive and painless process, there is a new release of our LogValidator, too.
Outstanding! Have been eagerly awaiting for this to be implemented in the W3C Validator!
Thanks!
This is very cool. By "integrates with the validator.nu engine" do you mean it's really the Validator.nu parser at work and not a separate one, or…?
Either way, it's very nice to see the W3C picking up best-of-breed tools and supporting them instead of reinventing those particular wheels.
It's really Henri's tool which is used in the background with the W3C UI on the front.
It is very rare that we create our own tools when a good one is already existing.
@Meitar Moscovitz - indeed, since the validator.nu engine has a very nice and well documented API, and since its html5 support is clearly outstanding, integrating it with the markup validator rather than build a new parser from scratch was an easy choice.
The alternative to integration and reuse is not necessarily “reinventing the wheel”, however.
The more (distinct and diverse) html5 implementations we can have in libraries, checkers, parsers, etc., the better. I'm sure it will happen as the specification matures, and as a developer I'm looking forward to it. It will give more choices to people who want to build tools upon html5, and it will give the html Working Group more sources of feedback in its process of developing and testing the new specification.