- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sun, 16 Jul 2006 03:45:06 +0200
- To: www-validator@w3.org
Hi,
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
doesn't.
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:
<http://lists.w3.org/Archives/Public/www-validator/2005Aug/0065>
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.
http://lists.w3.org/Archives/Public/www-validator/2004Jul/0236
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.
http://www.w3.org/mid/40c6ab00.477995270@smtp.bjoern.hoehrmann.de
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
specifications.
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
http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de
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-
possible!
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
http://lists.w3.org/Archives/Public/public-qa-dev/2005Apr/0006
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
them.
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