W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2002

RE: CSS accessibility problems: is markup dead?

From: Danny Ayers <danny666@virgilio.it>
Date: Thu, 16 May 2002 23:36:06 +0200
To: "Jukka Korpela" <jukka.korpela@tieke.fi>, "W3c_Access" <w3c-wai-ig@w3.org>
Message-ID: <EBEPLGMHCDOJJJPCFHEFMEBHGDAA.danny666@virgilio.it>

>In a sense, all markup is metadata, data about data. But I don't think this
>view is particularly useful. What we normally call metadata in the WWW
>context is data about such data that consists of entire documents like an
>HTML document and associated images etc., i.e. "Web pages".

Agreed, markup is essentially metadata, and IMO acknowledging this can be
very useful. (Who is this 'we', BTW?) A lot of people are seeing the value
of finer-grained explicit metadata (e.g. the use of the <metadata> element
in SVG), or even the use of metadata describing completely arbitrary
resources (e.g. RDF).

>> Another way may be to use named
>> classes, like "tophead" in your example, though of course it
>> would be better if they came from well-known vocabularies - class="h1"
>> perhaps?
>No, class="h1" does not mean anything more (to a browser) than class="foo".

Depends on the browser - ok, there aren't any browsers I know of that would
understand this, but I was making the point that use of common vocabularies
could be referenced in other ways than by using HTML 3.2 syntax.

>The class name is just an assigned symbol with no intrinsic meaning. Things
>might change if we defined some specific rules for class names, with
>semantic definitions (e.g., "h1" means 'first level heading') and published
>them and got wide acceptance. Then we would have reinvented the wheel,
>wouldn't we? It would be just like HTML, except more clumsy.

My point exactly (apart from the clumsiness bit).

>> Hopefully - - we won't need to rely on a vocabulary of maybe
>> two dozen terms plus fairly arbitrary nesting rules to explain
>> our document's structure
>It was one of the basic weaknesses of HTML as originally defined
>that it had
>only a handful of markup elements you can use. But it was also one of its
>fundamental strengths. The smaller the set of markup elements that
>a program
>_must_ recognize and process in some particular way, the easier it is to
>write programs that process marked-up data, for visible or audible
>presentation or for other purposes. (Actually, a qualified programmer could
>write a browser for HTML 2.0 in an hour, a _different_ browser
>that has some
>special treatment for markup like headings, to suit the properties of some
>new device, or the needs of some particular people.)

Ok, I've got 6 'O' levels, and could probably hack together a browser in an
hour, with special handling of some form or other. I think it would be a
waste of an hour though - the strengths of HTML (and HTTP) that got the web
going aren't necessarily the same ones that will keep it going (and

And the ease of
>creating "different" user agents is essential to accessibility.

Yes, I just think it's better to use a little analysis rather than falling
back on legacy principles.

Received on Thursday, 16 May 2002 17:42:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:19 UTC