W3C home > Mailing lists > Public > www-validator@w3.org > August 2010

Re: Check existence of class names

From: Philip Taylor (Webmaster, Ret'd) <P.Taylor@Rhul.Ac.Uk>
Date: Wed, 18 Aug 2010 11:28:43 +0100
Message-ID: <4C6BB5DB.5080301@Rhul.Ac.Uk>
To: "www-validator@w3.org" <www-validator@w3.org>
CC: chukharev@mail.ru


chukharev@mail.ru wrote:
 > On Tue, 17 Aug 2010 23:56:46 +0300, Philip Taylor (Webmaster, Ret'd)
 > <P.Taylor@rhul.ac.uk> wrote:
 >
 >> chukharev@mail.ru wrote:
 >>
 >>> Why do you dislike this kind of terminology?
 >>
 >> Just that it is not the way HTML is constructed/defined/whatever.
 >
 > I thought we have agreed that the problem lyes neither in HTML nor
 > in CSS, rather in their interaction?

Agreed, but an HTML page is an HTML page, and it is within
the HTML page that a so-called "non-existent-class name"
(I use the hyphens to indicate the binding) could occur.
Of course, the HTML page exists within a context, but
we have a very limited knowledge of what that context is.
Statically linked CSS may well form a part of that
context, but so may (e.g.,) a user style sheet, a browser
style sheet, a dynamically linked style sheet and so on.
So while I continue to agree with you that some consistency
checks between HTML page and statically linked CSS
may well be useful, that is not in any sense agreeing that
an "unpaired" class name, whether it is found in the HTML
or the CSS, is the same thing as a non-existent-class name
(no matter how you choose to parse the four elements
"non", "existent", "class" and "name").

 > Right, mea culpa. (I'm not good in CSS at all. That's one of
 > the reasons for the plead. Mostly, I modify existing styles,
 > and I make many errors when defining new classes.)

Ah, I begin to understand "where you are coming from",
as an American might say :-)

 > All except J.J. Thomson, as only .physicists has a definition
 > in <style>. Assuming no definition for the other classes is given
 > in the omitted parts above first <span>.

OK, so essentially you are willing to restrict yourself
(or your proposed consistency checks) to the meta-document
that is the union of the HTML page and its statically
linked style sheets.  Fair enough.

 > A list of the undefined and a list of the unused names, each
 > with document names and line numbers would quite satisfy me.

But you mustn't call them "undefined" :-)  "Unmatched",
or "unpaired", if you like, but not "undefined", please.

 > "Unpaired" is OK with me. I'm not certain though, how to use it when
 > I want to separate what I call in my terminology the undefined class
 > and the unused class. Is "unpaired in CSS" an undefined or an unused
 > class? I mean, is "chemists" the "unpaired in HTML" and "physician"
 > the "unpaired is CSS", or the other way around?

How about "unresolved" for a name found in the HTML but not
in the CSS, and "unused" for a name found in the CSS but
not in the HTML.  HOWEVER, this latter opens a whole new
can of worms, because whilst an HTML page explicitly calls
out a statically linked stylesheet, a CSS file exists in
limbo, and there is no way of telling from its contents
with which HTML files it is intended to be used.  So whilst
I continue to have sympathy with the idea of reporting
"unresolved" class names (see above), reporting "unused" class
names (see above) is likely to result in an excessive
number of false positives.

** Phil.
Received on Wednesday, 18 August 2010 10:29:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 12:14:43 GMT