Whom Do You Trust?

[Peter Collinson]

When validating external style sheets, I have learned from this
newsgroup that there are (at least) two choices:

http://jigsaw.w3.org/css-validator/

http://www.htmlhelp.com/cgi-bin/csscheck.cgi

Having just completed phase one of an enormous (for me) conversion
project, I decided to see what CSScheck had to say about CSS-validator's
persistent "You are encouraged to offer a generic family as a last
alternative," when all my "font-family" mark-up ends with either
"sans-serif" or "arial." (Except for one [1!] miscellaneous "webdings"
specification, and I don't know anyway around that!)

Whooooa! CSScheck was tougher than Lauri Raittila on a really bad day!

I mean, I understand warnings such as "The border-collapse property is
not currently supported by CSSCheck," but when it marks every single
instance of block level formatting with "The vertical-align property
only applies to inline and table-cell elements," when CSS-Validator
cheerfully gives it a thumbs up, which am I supposted to believe?

BTW: the "vertical-align" property was suggested as a DIV control by
Steve Pugh of this group, and worked nicely.

--
- Yours truly, Pete Collinson

[David Dorward]

Peter Collinson wrote:

Having just completed phase one of an enormous (for me) conversion
project, I decided to see what CSScheck had to say about CSS-validator's
persistent "You are encouraged to offer a generic family as a last
alternative," when all my "font-family" mark-up ends with either
"sans-serif"
That is a generic font family, unless you quote it. Keywords must not be
quoted in CSS.
or "arial."
Which is a specific font family and not at all generic.
(Except for one [1!] miscellaneous "webdings"
specification, and I don't know anyway around that!)
Avoid symbol fonts, use an image.
I mean, I understand warnings such as "The border-collapse property is
not currently supported by CSSCheck," but when it marks every single
instance of block level formatting with "The vertical-align property
only applies to inline and table-cell elements," when CSS-Validator
cheerfully gives it a thumbs up, which am I supposted to believe?

While it is _valid_ to try to apply vertical-align to block level elements,
it _shouldn'_ have any effect on the rendering of the page.
--
David Dorward http://david.us-lot.org/

[Darin McGrew]

Peter Collinson wrote:

(Except for one [1!] miscellaneous "webdings"
specification, and I don't know anyway around that!)

Lauri Raittila <la***@raittila.cjb.net> wrote: To what are you using webdings? If I have not misunderstood, it is
dingbat font that works on maybe 20% of users.

And unless you're using dingbat fonts for characters like &spades;,
&clubs;, &hearts;, or &diamonds;, if it does "work" then it means the
browser is wrong.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"There is no right way to do the wrong thing."

[Jukka K. Korpela]

Lauri Raittila <la***@raittila.cjb.net> wrote:

I wouldn't really recommend htmlhelp one. It is not up to date.
It's rather outdated in many ways, but especially for a beginner, it is
more useful due to its better user interface - more understandable
messages, in general. And it makes some heuristic checks that the "CSS
Validator" does not perform.
The funny thing is that it is not very good idea to offer generic
family whitout any good reason.

I would say that in most simple uses of font-family, it is. The average
author who wishes to suggest Arial would most probably prefer a
presentation that uses a generic sans-serif font. He might even have
some actual esthetic styling that more or less plays by assumption that
the font is Arial-like.

A good CSS checker would have an option for switching such reporting on
or off.

I mean, I understand warnings such as "The border-collapse
property is not currently supported by CSSCheck," but when it
marks every single instance of block level formatting with "The
vertical-align property only applies to inline and table-cell
elements," when CSS-Validator cheerfully gives it a thumbs up,
which am I supposted to believe?

Well it is right about that.

_Which_ one is right, in your opinion? I would say that both are.

The "CSS Validator" is right in not reporting the situation as an
error. It is not an error, since all elements have all properties.

CSSCheck is right in issuing a warning, since it is very probable that
the author didn't really mean to use a declaration that has no effect.

Nitpicking of the day: In principle, vertical-align set for a block
level element _may_ have an effect on the rendering of the page.
Although it does not affect the presentation of the element itself (on
conforming browsers), the element may contain elements that have
vertical-align: inherit.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Alan J. Flavell]

On Fri, Jul 25, David Dorward inscribed on the eternal scroll:

Avoid symbol fonts,
Yes, they have no place in WWW usage. font-face specifications are
for specifying different cosmetics of a given character - not for
fooling a browser into displaying what, according to the
specifications, would be the *wrong* character.[1]
use an image.

Possibly. Or the proper Unicode &#number; reference. Or an
abbreviation. The choice depends on an assessment of the consequences
if a client fails to render it, I'd say.
[1] More at
http://ppewww.ph.gla.ac.uk/~flavell/...e-harmful.html , if
I haven't overspent my ration of own-trumpet blowing this week.

[Jim Ley]

On Fri, 25 Jul 2003 22:48:59 +0200, "Alan J. Flavell"
<fl*****@mail.cern.ch> wrote:

On Fri, Jul 25, David Dorward inscribed on the eternal scroll:

Avoid symbol fonts,

Yes, they have no place in WWW usage. font-face specifications are
for specifying different cosmetics of a given character - not for
fooling a browser into displaying what, according to the
specifications, would be the *wrong* character.[1]

use an image.

Possibly. Or the proper Unicode &#number; reference. Or an
abbreviation. The choice depends on an assessment of the consequences
if a client fails to render it, I'd say.

OR embed the font definition in the document, or use altGlyph
definitions to choose between fonts which are available...

Of course I suppose the OP is using CSS with some sort of HTML mark-up
language where that option isn't available, since it's CSS we
shouldn't assume though...

Jim.

--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Nick Kew]

In article <VO***********************@news4.srv.hcvlny.cv.net >, one of infinite monkeys
at the keyboard of "Peter Collinson" <bl******@optonline.net> wrote:

When validating external style sheets, I have learned from this
newsgroup that there are (at least) two choices:

http://jigsaw.w3.org/css-validator/

http://www.htmlhelp.com/cgi-bin/csscheck.cgi [ give different results]

Both are useful - neither is perfect.

The difficulty is that CSS (in contrast to *ML) doesn't have any
well-defined notion of "validation", that would enable us to
implement a rigorous and unambiguously correct check. You have to
treat the above as analagous to HTML "linters", not validators.

Having said that, the W3 service is probably the more up-to-date
of the two. Liam speaks of csscheck as a quick-and-dirty hack:-)

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Bjoern Hoehrmann]

* Nick Kew wrote in comp.infosystems.www.authoring.stylesheets:

When validating external style sheets, I have learned from this
newsgroup that there are (at least) two choices:

http://jigsaw.w3.org/css-validator/

http://www.htmlhelp.com/cgi-bin/csscheck.cgi

[ give different results]

Both are useful - neither is perfect.

The difficulty is that CSS (in contrast to *ML) doesn't have any
well-defined notion of "validation", that would enable us to
implement a rigorous and unambiguously correct check.

I have yet to see a normative definition for "Valid HTML Document" but
I easily look the definition of "Valid Style Sheet" up in the CSS 2.0
Recommendation.

[Jukka K. Korpela]

Bjoern Hoehrmann <bj****@hoehrmann.de> wrote:

I have yet to see a normative definition for "Valid HTML Document"
but I easily look the definition of "Valid Style Sheet" up in the
CSS 2.0 Recommendation.

Pardon? Is this just some parody that is too deep for me, or what?

The official specifications, ever since the first one, have defined
HTML as an "application" of SGML or XML. Thus, the concept validity is
automatically defined by the SGML standard or XML specification,
respectively, in conjunction with the DTDs.

The definition of "valid style sheet" at
http://www.w3.org/TR/REC-CSS2/conform.html
is confusing, starting from the use of "valid" (which was a bad choice
since that word is already in use in a well-defined, restricted meaning
in the SGML or XML context). It first says that a valid style sheet
"must be written according to the grammar of CSS2", where "grammar of
CSS2" is a link, and then continues: "Furthermore, it must contain only
at-rules, property names, and property values defined in this
specification. An illegal (invalid) at-rule, property name, or property
value is one that is not valid." That's not the kind of language that
definitions normally use; normally we would say "X is Y, if ... and
....". Furthermore, it implies a meaning for "valid" for at-rule,
property name, or property value, when it has in fact tried to define
it for a style sheet only.

Besides, it follows that
foo { font-size: groove; }
is valid, under that definition. It matches the grammar, and font-size
is a property name in the specification, and groove is a property value
in the specification.

If you try to fix this by reading more into the definition that it
actually says, then you will find yourself as defining validity as
conformance to the specification as a whole, including all the prose
text, with the known errors unfixed of course, and with all the
problems of interpreting prose.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Steve Pugh]

Lauri Raittila <la***@raittila.cjb.net> wrote:

In article <VO***********************@news4.srv.hcvlny.cv.net >, Peter
Collinson wrote:

I mean, I understand warnings such as "The border-collapse property is
not currently supported by CSSCheck," but when it marks every single
instance of block level formatting with "The vertical-align property
only applies to inline and table-cell elements," when CSS-Validator
cheerfully gives it a thumbs up, which am I supposted to believe?

Well it is right about that.

BTW: the "vertical-align" property was suggested as a DIV control by
Steve Pugh of this group, and worked nicely.

It actually does something to block elements? Where? On what browser?

None that I know of. I presume that Peter is referring to my post
http://groups.google.com/groups?selm...puu5%404ax.com
in which I suggest the use of vertical-align on a <td> not on a <div>.
I've no idea where he got the idea that I was suggesting using it on a
<div>.

Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Lauri Raittila]

In article <Xn*****************************@193.229.0.31>, Jukka K.
Korpela wrote:

Lauri Raittila <la***@raittila.cjb.net> wrote:

I wouldn't really recommend htmlhelp one. It is not up to date.
It's rather outdated in many ways, but especially for a beginner, it is
more useful due to its better user interface

That is true. Starting with sensible name for service. Maybe I just use
CSS2 too often.

One more reason to use W3C one is that it finds CSS from HTML document,
which is handy. (especially if you check code that is not your own.)

The funny thing is that it is not very good idea to offer generic
family whitout any good reason.

I would say that in most simple uses of font-family, it is. The average
author who wishes to suggest Arial would most probably prefer a
presentation that uses a generic sans-serif font. He might even have
some actual esthetic styling that more or less plays by assumption that
the font is Arial-like.

That is good reason. But if he was to say "Georgia" for normal text, I
would not use serif as generic alternative. The reason is that Georgia is
much more readable on screen than Times New Roman (the usual generic
alternative ). In fact, I need TNR one size bigger than Georgia for best
size. If users default is Times New Roman, he can read it anyway, but if
he has changed his font to Arial, or even Verdana, it might make it
illegible.

Sans-serif is about only generic alternative that is somewhat safe to use
everywhere. Serif is OK for text bigger than normal, and of course
special case. Monospace is for monospace. Cursive and fantasy are pretty
useless.

OTOH, I don't like any font definitions on normal text. Not that it makes
any difference on correctly made HTML on my browser anyway.
A good CSS checker would have an option for switching such reporting on
or off.

They both have this option. Or maybe you mean warning by warning?

I mean, I understand warnings such as "The border-collapse vertical-align property only applies to inline and table-cell

Well it is right about that.

_Which_ one is right, in your opinion? I would say that both are.

Sorry. Meaned that latter, but didn't even think about denying first.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

[Stan Brown]

In article <MP************************@news.cis.dfn.de> in
comp.infosystems.www.authoring.stylesheets, Lauri Raittila
<la***@raittila.cjb.net> wrote:
[about CSS validators]

One more reason to use W3C one is that it finds CSS from HTML document,
which is handy. (especially if you check code that is not your own.)

But IIRC I got different results when validating the CSS directly
than when validating it by implication when validating an HTML
document. Sorry, I don't remember off hand what I was validating.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/

[Lauri Raittila]

In article <MP************************@news.odyssey.net>, Stan Brown
wrote:

In article <MP************************@news.cis.dfn.de> in
comp.infosystems.www.authoring.stylesheets, Lauri Raittila
<la***@raittila.cjb.net> wrote:
[about CSS validators]

One more reason to use W3C one is that it finds CSS from HTML document,
which is handy. (especially if you check code that is not your own.)

But IIRC I got different results when validating the CSS directly
than when validating it by implication when validating an HTML
document. Sorry, I don't remember off hand what I was validating.

Maybe you used some embedded CSS also? And it is propably still unable to
recognize media="screen, projection".

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

[Jukka K. Korpela]

Lauri Raittila <la***@raittila.cjb.net> wrote:

But if he was to say "Georgia" for normal
text, I would not use serif as generic alternative. The reason is
that Georgia is much more readable on screen than Times New Roman
(the usual generic alternative ).

I guess you have a point there, regarding practical readability. For
esthetic purposes, the difference between serif and sans-serif might be
significant. Or maybe I was mostly thinking about a situation where
e.g. the global font is Georgia (or ...) and the local font for some
elements, like some quotations or tables, is Arial (or ...), probably
with a reduced font size (like 80%). It might be useful to be able to
use _any two different_ fonts to help the user see different elements
differently at first glance. Since we cannot say "use any two different
fonts", the first idea that comes into my mind is using font-family
declarations with two relatively long lists as values, one value
listing serif fonts and the other sans-serif fonts.

A good CSS checker would have an option for switching such
reporting on or off.

They both have this option. Or maybe you mean warning by warning?

I meant switching on or off the specific reporting of lack of generic
font family as the last alternative. As far as I can see, the checkers
now have just "levels" of verbosity. You (I mean literally you) might
wish to switch off that specific reporting, without switching off any
other warnings. Other people might wish to switch off other reporting
(warnings - or maybe even error messages).

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Stan Brown]

In article <MP***********************@news.cis.dfn.de> in
comp.infosystems.www.authoring.stylesheets, Lauri Raittila
<la***@raittila.cjb.net> wrote:

In article <MP************************@news.odyssey.net>, Stan Brown
wrote:

In article <MP************************@news.cis.dfn.de> in
comp.infosystems.www.authoring.stylesheets, Lauri Raittila
<la***@raittila.cjb.net> wrote:
[about CSS validators]

>One more reason to use W3C one is that it finds CSS from HTML document,
>which is handy. (especially if you check code that is not your own.)

But IIRC I got different results when validating the CSS directly
than when validating it by implication when validating an HTML
document. Sorry, I don't remember off hand what I was validating.

Maybe you used some embedded CSS also? And it is propably still unable to
recognize media="screen, projection".

I don't think there was embedded CSS -- I try to stay away from it
though I do have a few occurrences. I'm surprised the W3C wouldn't
handle multiple media types, though.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
validator: http://jigsaw.w3.org/css-validator/