The Disunity of W3C Specs

Hi,

I'm just wanting to maybe put forward an observation from working with a lot
of web developers in large organisations.  It goes without saying that web
development is becoming more and more complex, and almost impossible to keep
up to date with changing and advancing technology.

Just briefly, as I come back to getting involved in WAI what bothers me is
the inability to reconcile the standards.

I feel the first discipline a web developer should aim at is following
formal grammars in markup.  That means validating your markup, specifically
against the W3C validators.  Most web developer only have time to do this
and then (maybe) check their code against another parser specialising in
checking for accessibility issues.  Most are up against tight deadlines.
Unfortunately these parser are not yet of a high standard.  I think I
remember rightly that Bobby 3.x checking priority 1 didn't even look for
<NOSCRIPT> tags.

This leaves most web developers with at least 4 stages in checking their
code; HTML Validator, CSS validator, WAI Validator, manual checklist of both
machine checkable that are not covered adequately by WAI parsers and items
that are only checkable by human interaction.

My point to all this is, there needs to be a better unification of the
standards so that developers feel that most important issues are addressed
at the HTML validator check.  For instance.

What do developers use a TRANSITIONAL DTD for?  Mostly it is used when
tables are required for layouts.  With the recent discussion on not
requiring <TH> in tables that are only used for layouts, I feel this is
something that if the WAIGL feels is important, it has to go to the Markup
GL to get changed.  In this case I would suggest things along the lines of

* TRANSITIONAL DTD = <TH> is optional, summary is optional
* STRICT DTD = <TH> is required, summary is required

And new items like the element attribute contextHelp have to be added to the
next version of the Markup before they become a formal recommendation or
considered by WAIGL, cause this type of thing is driving developers crazy.

Take the recent discussion on <ACRONYM> and <ABBR> here, when the XHTML 2.0
proposes to drop <ACRONYM>.  Why support something in WCAG 2.0 that will be
deprecated?  Why even bother with something that the Markup GL sees fit to
deprecate.  I know it hasn't happened yet, but it looks like it.

I think Mark Pilgrim's frustration
(http://diveintomark.org/archives/2003/01/13/semantic_obsolescence) as
representative of a lot of developers who are trying to do the right thing,
but are caught in the fragmentation that happens, even though this whole
process is about trying to readdress just that point.  There are a lot of
them out there that are trying to do the right thing.

What is going to happen is that we are not going to end up with a formal set
of grammars, but just a better and improved HTML soup.

Currently, I think the only developer who can get this type of thing right
is one who has full access to configuring their web server, deploying
transparent content negotiation, and transforming their documents using
XSLT.  Otherwise there is just too many sets of variables.

If there is fragmentation between the Markup standards and the Accessibility
standards, then web developers will ignore whatever is fragmented.  If
possible they only want to deal with one validator, which represents a
unification of standards.

As I have been off the WAIGL for a while, I hope I haven't been to far off
the mark, but your most welcome to address these issue to me.

Regards,
Geoff Deering

Received on Thursday, 21 August 2003 16:26:22 UTC