is this a good practice ?

[Mel]

CAN YOU suggest an alternative ?

..heading, heading-R, heading-K, heading-G, heading-W {
font-family: arial,helvetica, ms sans serif, sans-serif;
font-size: 10pt;
font-style: normal;
font-weight: bold;
text-decoration: none;
}

..heading-R {
color: #7a3b3b;
}

..heading-K {
color: khaki;
}

..heading-G {
color: darkgreen;
}

..heading-W {
color: white;
}

[David Dorward]

Mel wrote:

CAN YOU suggest an alternative ?

.heading, heading-R, heading-K, heading-G, heading-W {
font-family: arial,helvetica, ms sans serif, sans-serif;
Fonts with spaces in them must be quoted.
font-size: 10pt;
Point units are highly unsuitable for use on screen.
http://css-discuss.incutio.com/?page=UsingPoints
.heading-K { color: khaki;}
khaki is not a colour in CSS
.heading-G { color: darkgreen;}
Ditto 'darkgreen'
.heading-W { color: white;}

Its a reasonable way of specifying multiple classes with similar properties.

You could also use multiple classes...

class="heading W"

then:

..head { la la la }
..W { color: white; }

However - the class names aren't very good. They should representing
meaning, not what things look like.

And you shouldn't use a class for a heading, HTML comes with h1, h2, h3 ...
h6 for that.

h2 { ... }
h2.cats { ... }
h2.dogs { ... }
h2.goats { ... }

.... might be you best bet.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

[Harlan Messinger]

"Mel" <me**********@ssa.gov> wrote in message
news:c8**********@s0b1a68.ssa.gov...

CAN YOU suggest an alternative ?

.heading, heading-R, heading-K, heading-G, heading-W {
font-family: arial,helvetica, ms sans serif, sans-serif;
font-size: 10pt;
font-style: normal;
font-weight: bold;
text-decoration: none;
}

.heading-R {
color: #7a3b3b;
}

.heading-K {
color: khaki;
}

.heading-G {
color: darkgreen;
}

.heading-W {
color: white;
}

You must have some basis for deciding which headings should be khaki, which
should be dark green, and which should be white--that is, they must reflect
some kind of grouping. What if you decided that instead of khaki, you wanted
the khaki ones to be tan? Would you go through all your web pages and change
every instance of class="heading-K" to class="heading-T"? Or would you
change only the style, and then leave it to future generations to be
confused about why "heading-K" means "tan"?

The point is that the names of styles shouldn't reflect the details of the
style, they should reflect the defining characteristic of the page elements
to which you want to apply the style. If your site has three special
sections for math, science, and history, then use

.heading-math { color: khaki; }

and so forth. Then if you decide math headings should be tan, you only have
to change the style's definition; the style's name will still make as much
sense as it did originally.

Besides that, you shouldn't use the names "khaki" and "darkgreen" because
they are not standard CSS color terms and not all browsers will understand
them. Use RGB values instead: "#F0E68C" and "#006400". Even safer, stick to
colors that use multiples of 17 (11 hex): "#EEDD88" (or "#ED8") and
"#006600" (or "#060").

[Brian]

Mel wrote:

CAN YOU suggest an alternative ?
To what? What do you want?
.heading, heading-R, heading-K, heading-G, heading-W {
font-family: arial,helvetica, ms sans serif, sans-serif;

[snip]

I dunno, how about some real markup?

H1 {
font-family: sans-serif;
font-size: 140%;
color: #008000;
background: #ffffff;
}

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Keith Bowes]

Mel wrote:

.heading, heading-R, heading-K, heading-G, heading-W

Are all four of these supposed to be class selectors? If so, use a dot
before them all, not just the first one. If not, I'm sorry for wasting
your time.

[Keith Bowes]

Harlan Messinger wrote:

Besides that, you shouldn't use the names "khaki" and "darkgreen" because
they are not standard CSS color terms

However, they are in the CSS 3 Color Module, which is a W3C Candidate
Recommendation. IMHO, using those color names shouldn't be too harmful.

[Harlan Messinger]

Keith Bowes <do****@spam.me> wrote:

Harlan Messinger wrote:

Besides that, you shouldn't use the names "khaki" and "darkgreen" because
they are not standard CSS color terms

However, they are in the CSS 3 Color Module, which is a W3C Candidate
Recommendation. IMHO, using those color names shouldn't be too harmful.

I advised someone not to use non-standard, poorly supported code,
under the assumption that he wants his pages to work for as many
people as possible. This is a case where only a trivial effort can
increase the frequency with which his pages will be rendered
correctly. Do you think that's a bad idea? What does harm have to do
with it?

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Lauri Raittila]

Keith Bowes wrote:

Harlan Messinger wrote:

Besides that, you shouldn't use the names "khaki" and "darkgreen" because
they are not standard CSS color terms

However, they are in the CSS 3 Color Module, which is a W3C Candidate
Recommendation. IMHO, using those color names shouldn't be too harmful.

OTOH, it is pretty hard to figure out what some color looks from its
name, hexcode is much more readable...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä

[Alan J. Flavell]

On Sun, 23 May 2004, Keith Bowes wrote:

Harlan Messinger wrote:

Besides that, you shouldn't use the names "khaki" and "darkgreen" because
they are not standard CSS color terms

Also, it's good practice when specifying text colour to always specify
background colour, and vice versa. I.e specify either both of them or
neither of them, at each level of specificity that's used. See
previous discussions for details, and if warnings are enabled in the
W3C CSS "validator" then it'll call attention to this issue.
However, they are in the CSS 3 Color Module, which is a W3C Candidate
Recommendation.
alright
IMHO, using those color names shouldn't be too harmful.

I can't agree, unless you choose *both* text *and* background colours
by using names which aren't in CSS2. Even then, you risk hitting a
browser which is too clever for its own good, and recognises some
colour names which aren't in CSS2 while not recognising others.

Suppose, for instance, that you set the text colour to "white" and the
background to "darkgreen". Assume that the browser's default
background is white.

So a browser which correctly supports CSS2 will display white text
(since "white" is in the CSS2 repertoire) against the default white
background (since "darkgreen" is not). "Shouldn't be too harmful"?

I really think this is all an unfortunate mistake by the designers of
the language. CSS should be defined for its resilience as an
interworking language - not for the convenience of authors. If they
don't know what RGB values to assign to "darkgreen", then their
authoring tools should be able to tell them, and insert -that- into
the stylesheet, IMHO.

cheers

[Alan J. Flavell]

On Sun, 23 May 2004, Alan J. Flavell wrote:

I really think this is all an unfortunate mistake by the designers of
the language. CSS should be defined for its resilience as an
interworking language - not for the convenience of authors. If they
don't know what RGB values to assign to "darkgreen", then their
authoring tools should be able to tell them, and insert -that- into
the stylesheet, IMHO.

Developing this argument further, if I may...

Take a look at the "rules for handling parsing errors", e.g at
http://www.w3.org/TR/REC-CSS2/syndat...parsing-errors

The rule concerning an illegal *value* is that the specific
*declaration* must be ignored, but the other declarations in the same
group will still be parsed and used. Allowing CSS declarations to be
collected into "groups" seems to be for nothing more than convenience.

It occurs to me that it's at least arguable that an illegal or
unrecognised value within a group ought to cause the *whole group* to
be ignored.

div.w { color: white; blackground-color: darkgreen;
font-family: wibble; }

If the browser doesn't recognise "darkgreen", then it seems to me that
it's less harmful if it also discards the declaration which specifies
white text. There's no other "conditional" mechanism in CSS to
achieve that.

In my above example, it would also discard the font-family
specification in these circumstances. Suppose you wanted to specify
font family "wibble" regardless of whether the colour declarations
were accepted, then (under these suggested rules) you would code this
instead:

div.w { color: white; blackground-color: darkgreen; }
div.w { font-family: wibble; }

That would then give the grouping mechanism a genuine technical reason
to exist, rather than being a mere coding shorthand as it appears to
be at present. And IMHO it should be capable of giving better
compatibility behaviour when older clients are used to render newer
versions of CSS. Provided of course that CSS authors understand the
idea, and apply it appropriately.

To be candid, I'm making this up as I go along, so feel free to tell
me that it's all been discussed before, and rejected, and I missed the
discussion; or whatever else is wrong with it. And, admittedly I'm
raising this too late now, since the behaviours of CSS2-ish browsers
that are out there aren't going to change merely by some waving of the
W3C revision pen, even if the W3C were to be convinced that it was a
reasonable idea. Ho hum.

[Eric Bustad]

Keith Bowes wrote:

Harlan Messinger wrote:

Besides that, you shouldn't use the names "khaki" and "darkgreen" because
they are not standard CSS color terms

However, they are in the CSS 3 Color Module, which is a W3C Candidate
Recommendation. IMHO, using those color names shouldn't be too harmful.

"The table below provides a list of the X11 colors supported by popular
browsers."

This doesn't say that browsers supporting CSS3 should or should not
support these color names, just taht *some* browsers do support them.
What the hell is this kind of statement doing in a Recommendation/Standard?

= Eric

[Dr John Stockton]

JRS: In article <Pi******************************@ppepc56.ph.gla.a c.uk>
, seen in news:comp.infosystems.www.authoring.stylesheets, Alan J.
Flavell <fl*****@ph.gla.ac.uk> posted at Sun, 23 May 2004 14:23:08 :

. Even then, you risk hitting a
browser which is too clever for its own good, and recognises some
colour names which aren't in CSS2 while not recognising others.

Is there a list of colour names which I can use in safety, and if so
where/what?

I need them to be recognised by Win98/MSIE4; and I want them to be
recognised by browsers up to say six years old and, as far as can be
foretold, in years ahead.

These 16 I "know" to be safe :
aqua black blue fuchsia gray green lime maroon
navy olive purple red silver teal white yellow

MSIE4 knows more; but MSIE6 does not know all that Netscape have listed.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.

[Claire Tucker]

On Tue, 25 May 2004 13:40:23 +0100, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:

I need them to be recognised by Win98/MSIE4; and I want them to be
recognised by browsers up to say six years old and, as far as can be
foretold, in years ahead.

These 16 I "know" to be safe :
aqua black blue fuchsia gray green lime maroon
navy olive purple red silver teal white yellow

MSIE4 knows more; but MSIE6 does not know all that Netscape have listed.

The only real "safe" option is to specify exactly which colour you
require as a hexadecimal value. Even if these keywords are supported,
there is always the chance that some browser will use a different
colour for some of them than you are expecting, and you probably won't
even notice right away.

The best idea is just to specify an explicit colour, and then there
cannot be any doubt as to which colour you were referring to.
(Ignoring monitor gamma issues, which you can't really do a whole lot
about and which the user will be used to anyway.)

-Claire

[George Lund]

In message <Pi******************************@ppepc56.ph.gla.a c.uk>, Alan
J. Flavell <fl*****@ph.gla.ac.uk> writes

To be candid, I'm making this up as I go along, so feel free to tell
me that it's all been discussed before, and rejected, and I missed the
discussion; or whatever else is wrong with it. And, admittedly I'm
raising this too late now, since the behaviours of CSS2-ish browsers
that are out there aren't going to change merely by some waving of the
W3C revision pen, even if the W3C were to be convinced that it was a
reasonable idea. Ho hum.

See discussions around
http://lists.w3.org/Archives/Public/...1Jul/0215.html
(the nearest archived post I could quickly find)

It's not like we weren't telling them these things years ago. I
remember being quite disappointed at the level of responses I tended to
get... if you go back in that thread far enough I say that I 'mentioned
the idea before' even then :-|

--
George Lund