- From: Philip Taylor (Webmaster, Ret'd) <P.Taylor@Rhul.Ac.Uk>
- Date: Wed, 18 Aug 2010 11:28:43 +0100
- 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 UTC