This page has the to-do list for the W3C Markup Validation Service, including bugs that need fixing and general wish list items. See also the www-validator mailing list archives for recent discussion that may not be reflected on this page, as well as open bugs and RFE's in Bugzilla.

Recently, we're trying something new. :-) We're going to start splitting development into "releases"; that is milestones with a version number. We've done a few already, arbitrarily named 0.5.0 and 0.5.1, that mainly existed as CVS tags to make bug fixing easier. Right now I'm trying to stretch this concept a little further by planning features for future versions in advance.

As a result, you will find several lists on this page now; one for each planned version and one for general "some time when I get a round tuit" stuff. As releases are made, the TODO items for that release are removed (see What's New and CVS for details) or moved to the next release if delayed.

Validator v0.7.0

Core Changes

  • Bring back the Root Namespace in results.
  • Investigate how, if, and when, to use Nick Kew's most excellent XMLMessageReporter patch to OpenSP.
  • Figure out some way to avoid inlining so much static HTML!
  • Finish up the textarea for testing short HTML fragments.
  • Add an HTML pretty-printer feature, using tidy and/or Enscript?
  • Add support for https:// (TLS/SSL) using Ville's patches.
  • Pay attention to Accept-Charset (cf. this message from "brewhaha").
  • Double check that all output is valid! In particular, use style rules to specify height/width on suggested links.
  • Do a great big update of the various badges; the details of size, transparency, naming, and how they are linked to (v.w3.org vs. w3.org).
  • Make sure we output sane "text/html; charset=foo".

Documentation Changes

  • Clarify the wording regarding valid characters in errors.html (cf. this message from Clemens Radl. Thanks Clemens!)
  • Write documentation for the SGML catalog, point out good DOCTYPEs to use, and make it easy to find if your editor won't insert them for you.
  • Add system requirements for NT/W2K. Bug Bjoern about his "Installing the Validator on NT" doc. Link to ActiveState Text::Iconv and friends.
  • Add docs on editing DTDs.
  • Document how to add new DOCTYPEs to the Validator.
  • Write documentation for Content Negotiation of Badges

Website Changes

  • Link to Jukka's pages; both in general and to specific pages. Ask him about mirroring some of the stuff on validator.w3.org.

Validator v1.0.0 (tentative)

Core Changes

  • Add a "fix my HTML for me" option using Tidy.
  • Finish adding support for XML validation (see also: test cases, or an existing service).
  • Add a section to the report on document cacheability? (or just link to it?)
  • Put the explanations in a database (flat files are probably OK), and offer an option to display them inline with the errors.
  • Incorporate CSS validation directly into this service; either directly or by some form of linking to the existing service on Jigsaw.
  • Make e.g. http://validator.w3.org/check/referer;imgonly return only an image showing the validation status of the referring page.
  • Add link validation using the link checker code (or other code with similar functionality).
  • Add a "document meta-information" section to the report, to encourage people to use META tags appropriately?
  • Figure out what's going on with this. (Thanks to Marie Taylor-Harper for catching this!).
  • Investigate validation of RDDL.
  • Fix directories differing only in name case in sgml-lib/pro/usr/local/lib/sgml/. We have both "ietf" and "IETF" in there.

Documentation Changes

  • Write documentation, describing each feature and option of the validator and answering questions like "What's the difference between an SGML parser and Weblint?", "Which DOCTYPE should I use?", content negotiation, ...

Website Changes

  • Update sgml-lib.tar.gz; automate the updates.

Various Unclassified Stuff

These items are roughly in prioritized order; i.e. the items near the top are those which I consider most important.

  1. Make lists of "most frequently validated invalid pages" and "most frequently validated (non-W3C?) valid pages" (need to start logging stuff first, including IPs to compare uniqueness).
  2. Install and play with HTML::Validator, link to it from somewhere: HTML::Validator Home Page Sami Itkonen's CPAN directory
  3. Give errors/warnings related to markup that is technically valid SGML, but error prone, such as things found in "B.3 SGML implementation notes" in the HTML 4.0 spec. (these things really belong in something like Tidy).
  4. Make an "elements found" section a la Webtechs, with links from each element to the appropriate place in either the DTD tree listing produced with dtd2html (after running dtd2html with all DTDs in the catalog), or the HTML 3.2/4.0 specs, or htmlhelp.com stuff, ...
  5. Add a "recommend a DTD for me" feature (check a document against all available DTDs, report which one has the fewest errors)
  6. Start caching validation results locally and doing an If-Modified-Since HTTP request to only download and revalidate URLs if they actually changed since their last validation
  7. Site walker/validator: need to add a "registered user" feature first, because this feature could be abused (many requests on a server in a short period of time)?
  8. URL-minder service: "remind me if this page or set of pages ever ceases to validate".
    • "registered user" feature is also necessary for this (to prevent unwanted e-mail)
    • "registered users" could have a list of URLs they're interested in, and whenever they return to the service they can modify this list, and e-mail can be sent whenever any of them cease to validate
    • Right now someone could probably use the existing URL-minder service instead of writing a new one (tell it to "mind" the URL that points to the validation result for a page?) But I'm not sure how regularly URL-minder checks for changes; it seemed to be weekly or something, which isn't frequent enough, IMO. Doing an If-Modified-Since GET every day doesn't cost much if pages don't change. Some of these features should only be enabled if the page consistently returns a Last-Modified header, maybe.
  9. Provide messages in different languages?
  10. Add a graphical representation of the document's structure, using images mixed with text, or just an image?
  11. Add a section with PICS info?
  12. Issue PICS labels for documents that do/don't conform? Or for editing tools that don't conform?
  13. Investigate possibility of modifying OpenSP's messages for e.g. invalid attributes to include name of current element and version and type of markup in use.
Valid XHTML 1.0! Feedback: The W3C Validator Team