Leaving W3C QA Dev.


  I believe for our society to progress it's essential that our culture,
our knowledge, and our society itself are as accessible as possible to
everyone; web standards are how we choose to achieve this on the World
Wide Web, and for us to communicate, especially if we have special needs
or novel ideas about information access, it depends on compliance to web
standards. With this in mind I became interested in assuring standards
compliance on the Web and involved in the development of tools meant to
help in this respect at the World Wide Web Consortium seven years ago.

I now have to discontinue my participation in this area at the W3C and
would like to explain how the World Wide Web Consortium failed to pro-
vide what I think would have been and still is necessary to advance the
tools and services to an acceptable level, which will explain why I am
leaving now.

  * Active development and maintenance

      It should be obvious that it is in the best interest of both the
      World Wide Web Consortium as well as its Membership to have good
      tools available that help them and everyone else make good and
      standards compliant web sites, hence it is reasonable to expect
      them to drive their development. Even for a community driven
      development environment it is essential to maintain steady pro-
      gress towards common goals; without, people quickly lose interest.

      W3C does not invest in these tools, it relies on volunteers, be
      they open source programmers, translators, documentation writers,
      or unpaid summer interns, to not only drive development, but also
      to provide basic maintenance and development momentum. If they
      are unavailable, nothing happens.

      In http://www.zeldman.com/daily/0204b.shtml Jeffrey Zeldman wrote:

        Web professionals around the globe rely on the W3C's
        validation tools to ensure that their work is correctly
        authored. Practically speaking, these tools constitute the
        entirety of the W3C's professional outreach program. They're
        the only parts of the W3C most of us interact with on a daily
        basis. Tim, help us out: spend a few bucks making sure these
        tools work.

        If, despite membership fees of $50,000 a head, the W3C can’t
        squeeze out a budget to cover the maintenance cost of its
        validation services, then we humbly ask the volunteers who
        maintain this tool to roll it back to a previous version. For
        as far as we can see, the only difference between previous
        versions and the newest version is that they worked and this

      Indeed, there is another thing to consider here. W3C advises
      http://www.w3.org/QA/2002/07/WebAgency-Requirements web agency
      customers to "accept only the best", including only sites that
      pass its own tools "to check that the final product complies
      with these standards". Is it responsible to insist on this and
      to refuse making sure the tools actually work as advertized?

  * Hardware as needed

      You'd think even if W3C cannot provide a technican to help with
      these tools, they can at least provide the hardware to keep the
      services up and running. But that turns out to be difficult
      aswell. Back in January 2005 W3C informed us that it is "tough
      to get budget" for much needed hardware. The result is downtime:

      It is important to understand that much needed improvements to
      the Validator would in all likelyhood considerably increase the
      load on the servers; developers then start thinking over whether
      it makes sense for them to work on these improvements if, in the
      end, no one will run them.

  * Support from W3C Working Groups

      Specifications like the HTML 4.01 Recommendation are not developed
      or maintained by the few volunteers taking care of the Validators,
      but by separate entities inside the W3C. The Markup Validator's
      current focus is at HTML and XHTML documents, which the W3C HTML
      Working Group developed and "maintains" the specifications for.

      When using the Validator, you typically just want to know whether
      your document is Valid XHTML 1.0 Strict or Valid HTML 4.01 Strict,
      or whichever document type you chose. So in order to make a tool
      that tells you, we need to know what it means for a document to be
      Valid XHTML 1.0 Strict. That's not much to ask for, is it? Well,
      there are a few things you have to know why it actually is.

      explains the mental state of the HTML Working Group quite well.
      A user wonders whether the Validator fails to support XHTML 2.0.
      Masayasu Ishikawa responds:

        That is the case. Not because the Validator Team is lazy, but
        because the HTML Working Group (more specifically me) is too
        lazy to come up with a "usable" DTD for XHTML 2.0. Well, I've
        said numerous times that it's impossible, but people don't
        believe me. So I have to do my best to implement DTD and prove
        that it's unusable. Oh well. Hopefully the next draft will
        include something, usable or not.

      Think about this for a bit. Masayasu Ishikawa, W3C HTML Activity
      Lead, expert on the matter, stands in front of the group chartered
      to take care of the HTML and XHTML specifications, discussing what
      is supposed to replace both HTML and XHTML as we know it, stating
      repeatedly what is trivially obvious to anyone who understands a
      bit about the matter, and the group just goes "Lalalala... We do
      not listen to this! Lalalalala..."

      Contrary to its charter and the W3C Process, the HTML Working
      Group does not bother to maintain most of its specifications. If
      you are a regular reader of the www-validator list, you probably
      know about some of the strange bits of HTML, just today we had a
      http://www.w3.org/mid/44B7CB64.70807@fh-landshut.de user asking
      about why code like <div<div>... is allowed even though a > is
      missing. Such codes, while allowed, are not well supported by
      browsers and we would like the Validator to complain about them.

      So we http://lists.w3.org/Archives/Public/www-html/2002Nov/0055
      asked them whether they could do something about that now; and
      their response? Well, they just ignored it.

      There are many thing the current Validator does not check for.
      For example, <font color="ShinyGradientRedToBlue">...</font> is
      not allowed, but the Validator won't complain. We would like to
      change that, but the specifications also have very weird require-
      ments that most web sites ignore, and therefore would fail to
      validate if the Validator enforces such rules for no reason.

      http://www.w3.org/WAI/ is such a site as it uses the style=""
      attribute. Per the HTML specifications, you can't just use this
      attribute, you also have to specify the "Content-Style-Type" in
      the HTTP header or some <meta> element. Sites that get this
      right are virtually inexistant. So if we chose to check for more
      conformance requirements like this one, the vast majority of
      pages that currently pass the Validator will fail.

      We asked the HTML Working Group whether perhaps they could remove
      this requirement. Their response? There was none.

      So, if we make such improvements but do not desire the public
      outrage that would follow, we have to make decisions which rules
      we'd like to enforce, and which we rather ignore. It's not an
      appropriate thing for us to do, but there is no choice. But then
      the next problem comes up!

      Many parts of the HTML and XHTML specifications are incorrect
      and/or very unclear. Over the years you just get used to the
      fact that the HTML Working Group simply disregards any issues
      people raise about their Recommendations, so instead we tried
      something more clever, raise issues on draft specifications.

      As per http://www.w3.org/Consortium/org#public

        W3C enables public participation and promotes public account-
        abilitly in a number of ways. We encourage the public to:

          * Participate in technical discussions on one of W3C's many
            public mailing lists. The W3C Process ensures that Working
            Groups give full consideration of public feedback on 

      Indeed, as you can read in http://www.w3.org/Consortium/Process/
      for a document to advance to "Proposed Recommendation" status,
      the Working Group must send a substantive and technically sound
      response to issues raised to the reviewer.

      So, http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/
      was such a draft document and I filed a comment about what you
      can actually put in attributes like <script type="..."> as that
      is not clear to me.

      http://www.w3.org/TR/2006/PR-xhtml-modularization-20060213/ and
      http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/ have
      since been published even though I'm still waiting for their
      response. According to the Process document, this should be im-

      In http://lists.w3.org/Archives/Public/www-archive/2006Feb/0019
      I tried to find out what's gone wrong, perhaps the response got
      lost somewhere in the process? Their response? I guess that one
      got lost aswell! http://w3.org/mid/43F23A4C.9000608@satoshii.org
      cites other lost comments, seems many are affected...

      So you remember the <font color="ShinyGradientRedToBlue">...
      from above. DTDs do not allow to specify that Red and #ffffff are
      legal values and ShinyGradientRedToBlue is invalid. But XML Schema
      does, and the main point about this new M12N specification is the
      addition of XML Schema schemas.

      Having good schemas available would greatly aid the development
      of the Markup Validator and competing online services. So you'd
      think, even if the HTML Working Group completly disregards all
      other problems, they at least do a good job at writing those!

      Now, http://lists.w3.org/Archives/Public/www-archive/2004Apr/0043
      is another comment, where I discuss this in more detail. It turns
      out that even the latest draft of XHTML M12N linked above allows
      <font color="ShinyGradientRedToBlue">...</font>. So, does the
      group have a good explanation for that? I'll tell you, once they
      bother responding.

      Every once in a while they do bother to respond to issues. That
      unfortunately does not make much of a difference however, they
      rarely go beyond my favourite one in their technical detail, to
      quote, "Its our language and we can do that".

      Support from W3C Working Groups is the most important point in
      this list as it affects not only the developers of the W3C tools,
      but also the developers of competing products like Validome,
      Christoph Schneegans' XHTML Schema Validator, Relaxed, Site Valet,
      the WDG Validator, you name them. They suffer just as much.

  * Support from the W3C Team

      I'm writing about what's lacking, so there is no opportunity to
      thank Olivier Thereaux for his good work in the past few years,
      or other members of the Quality Assurance Team for that matter.

      Let's talk about the only other part of the Team we had some
      business with instead, the W3C Communication Team. So lets talk
      a bit about SVG versions of the "Valid XHTML" icons.

      It's again obvious, it would promote XHTML, SVG, standards com-
      pliance, and the W3C brand, it will help generating icons for
      new formats which W3C also could not do, it's again in their
      best interest to provide them. As Terje Bless summarizes in

        In particular, the request for SVG format badges was first
        made in September of 2000. When no response was received, by
        July 2001, members of the validator team created their own
        SVG versions.

        Since July of 2001 the process of attaining the Comms Team's
        permission to use these badges has been "ongoing".

      We, in fact, teamed up and improved our versions and scripts
      to automate generation of all the icons in their many formats,
      from scratch of course, as they did not bother to respond to our
      requests to provide the original vector images; almost done, we
      got informed they now do care but want "to use their designer's
      vector work as a basis", and completely disregarded our work on

      After just 1 1/4 years, they are now done! You can read about it
      in http://lists.w3.org/Archives/Member/w3c-tools/2006JulSep/0003
      ah, well, except if you don't have W3C Member Access, like most
      volunteer developers don't have. They did not bother telling us
      developers about the release, or the Validator community, or the
      public at large. It might have escaped them, but there are a few
      people out there who use these images on their sites, and they
      might have liked to know W3C felt like changing colors and making
      text more blurry.

      They also did not bother to give us any advance notice, or ask
      us to review the changes and new versions they propose, just as
      they did not bother to tell us why many of the requests we have
      made in Terje's mail above were ignored. In spite of our many
      complaints and requests; just a few weeks ago I proposed to them
      that perhaps it would be good to give advance notice, involve
      the stakeholders, gather feedback, and properly announce changes;
      I am not a Communications expert, but that just seems better.

      But lets http://www.w3.org/2000/09/vsimg/transparency-test have
      a look at what they did. If you are interested in the SVG
      versions, don't try those for the Valid SVG images, as they do
      not exist, ironically. It seems they somehow forget to run the
      linkchecker we maintain for them.

      These images make an integral part of the Validation services and
      they are included in the Validator distribution, arguably subtle
      changes as introduced here as well as the addition of new formats
      amounts to a minor release of the Validator. As I said above, they
      are nowhere near what we asked them to provide, and while I am
      told they've made some improvements, the images are still terrible

        * they are extraordinarily bloated,
        * they fail to meet W3C's own SVG guidelines,
        * they fail to meet W3C's own I18N guidelines,
        * they are inaccessible per W3C's own requirements,
        * they won't function in conforming mobile viewers,
        * and they are non-compliant.

      Sooner or later they will be part of an actual Validator release;
      last time I checked the consensus-oriented Validator Team decided
      about releases. I would object to a release that includes any of
      these SVG images without major changes.

      So, how about making such changes? I got informed by the Comm Team
      "but after discussions [...] this is the structure we plan to use
      for now". So I can either go along with this new new decree-orien-
      ted Validator Team--and it so happens these Comm Team people do
      not hang out on www-validator, so it will be up to us tell dis-
      appointed users to shut up, to tell people who contribute cleaned
      up versions to dump their work and stick to the official imagery,
      and to tell authors to use this as an example of how not to do it;
      or I can ... well, there aren't really any options, are there?

      I personally just don't get this; we made it plain to them that we
      were dissatisfied by how they handled this issue for the past six
      years, it should be obvious to them as communication experts that
      not asking us, not telling us, paying no respect to our require-
      ments, and ignoring our contributions to a mutually satisfactory
      solution just communicates that they do not give a damn.

Well, that's it for me then; more time to work on the CSS and WebAPI
specifications, and tool development outside the W3C. If anyone not
affiliated with the W3C would like to take over my CSS Validator FAQ,
I'd like to hear from you!
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Received on Sunday, 16 July 2006 01:45:22 UTC