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

Re: IDs? and classes

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 13 Jun 2000 18:18:14 -0400 (EDT)
To: Wendy A Chisholm <wendy@w3.org>
cc: Jason White <jasonw@ariel.ucs.unimelb.edu.au>, Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.20.0006131812160.31946-100000@tux.w3.org>
Yes, although I need to check more carefully the syntax of CSS selectors to
see whether these are in fact legal values. (I have a nasty suspision that
there are URIs that are not, but if the characters : (colon) and / (slash)
are not allowed there is a bit of a problem. The character . (period) is not
allowed, in effect, but is not required for creating a URI.

RDF makes assertions about URIs. So if there is a URI that we can refer to,
it can create assertions in RDF. We can't create RDF about class="nav",

If every element has an id then we can create information about it directly.
But that means that class information becomes an out-of-band collection of
statements about individual items, and I am not sure if that is a good thing
or not - it may be fine in the long run, but in the short term it would be a
problem for the general web. So it depends on the implementation and

Charles McCN

On Tue, 13 Jun 2000, Wendy A Chisholm wrote:

  Are you suggesting something along the lines of <P 
  class="http://foo.bar/definition.htm"> ?
  That does not seem to be the most elegant way to do things.  Isn't there 
  some way to use RDF?  Namespaces?  something else?  I agree that the URI is 
  helpful for the person who want to find out about the semantics, but how 
  would this be machine-understandable?
  I like Marja's original idea of include ID's on elements.  ID's could be 
  arbitrary and automatically generated for block elements.  Then, 
  annotations could be attached to any element in the document.
  At 04:41 AM 6/12/00 , Charles McCathieNevile wrote:
  >Actually, in the context of the "semantic web", and RDF, I have a suggestion
  >to make, which is that classes be used which are URIs - prefereably real
  >ones. This would enable two things to happen:
  >  1. An author could explain, at the URI in a dereferenceable document, what
  >the class was about or for.
  >  2. It would become more or less trivial to make RDF assertions about
  >classes, and therefore about how to re-use existing ones rather than create
  >new ones for each piece of content.
  >In general, I am opposed to making a class if it can be avoided (for example,
  >it is better to use the existing CODE element than to produce a style class
  >for delineating code examples). In particular I would suggest that the
  >semantics of map were not extended in HTML 4.01, merely the syntax, which was
  >extended to match in the real world the semantics of the specification. But
  >that is a trivial question I guess.
  >Charles McCN
  >On Mon, 12 Jun 2000, Jason White wrote:
  >   Interestingly, there has been significant resistance, within this working
  >   group, to any attempt to provide common semantics to specific values of
  >   the HTML CLASS attribute, either within the guidelines or techniques
  >   documents. The basic rationale was that the semantics of CLASS values were
  >   left completely unconstrained by the HTML specification and it was
  >   desirable not to create an inconsistency, or apparent inconsistency,
  >   between HTML 4.0 and the guidelines. It was also urged that content
  >   developers should have total freedom in creating style sheets to use the
  >   CLASS attribute as they wished.
  >[and so on]
  wendy a chisholm
  world wide web consortium
  web accessibility initiative
  madison, wi usa
  tel: +1 608 663 6346

Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia 
Received on Tuesday, 13 June 2000 18:18:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:32 UTC