What's Best Practice In CSS?

[Hostile17]

I'm trying to arrive at a kind of "industry standard" or "best
practice" approach to CSS for a policy document aimed at developers,
but not necessarily very experienced developers.

What does the CIWAS community think is the best way to go about
styling documents for maximum compatibility/minimum problems with old
browsers.

We have a range of people currently using a range of techniques, i.e.

* code a full-on style-sheet but hide it from Netscape 4 with
MEDIA="all"

* as above but with importing instead of hiding

* code a simple style sheet with fonts and colours for buggy
browsers, then use a second, imported style sheet for more complex
formatting/positioning

* a single style sheet using the box model hack

* a single style sheet with some code hidden from Netscape 4 by
exploiting a comment bug/hack

and a bunch of other approaches as well I'd guess.

I'm assuming most professionals would vote for "single style sheet
using the box model hack" (and others) but I may well be wrong.

If I'm right, where would I find a definitive style sheet which has
the BMH, the Empty A Declaration and so on, such that I can give
people this stylesheet and mark it up like:

STUFF ABOVE HERE ONLY APPLIES TO NETSCAPE

STUFF FROM HERE ON APPLIES TO IE5 AND LATER

THIS BIT WORKS AROUND AN OPERA BUG SO JUST IGNORE IT

FONTS ARE FIXED TO THIS SIZE (12PT) FOR NETSCAPE 4, OVER-RIDDEN BY
LATER DECLARATIONS FOR OTHER BROWSERS TO PROPORTIONAL SIZES

so as to make it pretty much solid and, not idiot-proof, but let's
say, as easy as possible to adapt for a person styling up a page?

TIA

hosti1e

[Karl Smith]

ho*******@yahoo.com (Hostile17) wrote:

I'm trying to arrive at a kind of "industry standard" or "best
practice" approach to CSS for a policy document aimed at developers,
but not necessarily very experienced developers.

What does the CIWAS community think is the best way to go about
styling documents for maximum compatibility/minimum problems with old
browsers.
"Maximum compatibility" and "minimum problems" are very different
things. Maximum compatibility with old browsers implies that you are
disinterested in using any of the features available to newer browsers
and that your main concern is making it "look the same". If so, why?
If I'm right, where would I find a definitive style sheet which has
the BMH, the Empty A Declaration and so on, such that I can give
people this stylesheet and mark it up like: [snip] so as to make it pretty much solid and, not idiot-proof, but let's
say, as easy as possible to adapt for a person styling up a page?

(Cart before horse, tail wagging dog, various other animal metaphors.)
Don't let people "style up" pages. Write a glossary of
organization-approved classnames and when to use them. Let people mark
up pages accordingly. If it isn't in the glossary, it's "plain
vanilla" HTML.

Letting everyone run amok writing lots of stylesheets destroys the
whole point of CSS. They might as well just use FONT tags.

(BTW: CIWAS should have such a glossary with the FAQ and get this
..navigation/.navbar/.nav/.sitenav thing sorted out once and for all.)

--
Karl Smith.

[Hostile17]

go************@kjsmith.com (Karl Smith) wrote in message news:<3d************************@posting.google.co m>...

"Maximum compatibility" and "minimum problems" are very different
things. Maximum compatibility with old browsers implies that you are
disinterested in using any of the features available to newer browsers
and that your main concern is making it "look the same". If so, why?
No, I'm definitely not in the business of trying to make everything
look the same.

I want a style sheet that does use the features of new browsers.

Perhaps I expressed it wrongly -- it's all in my punctuation:
maximum compatibility/minimum problems with old browsers.
was meant to mean (code which is compatible with new browsers), but
(doesn't cause problems in old browsers).

OK I'll put what I want in a different way. I want to provide my
developers a style sheet which allowed them to test a certain
declaration, see that it cause horrible problems in Netscape 4, and
easily move it to a "Netscape 4 can't see this" part of the style
sheet.
Don't let people "style up" pages. Write a glossary of
organization-approved classnames and when to use them. Let people mark
up pages accordingly. If it isn't in the glossary, it's "plain
vanilla" HTML.
That's certainly an interesting approach.

I'm not sure "don't let people style up pages" would work in our
organisation with many different kinds of web pages.

One page has horizontal breadcrumb nav, another has traditional
vertical left nav, a third has *two* levels of left-hand nav and so
on, how can I write a stylesheet in advance for all these variations?
(BTW: CIWAS should have such a glossary with the FAQ and get this
.navigation/.navbar/.nav/.sitenav thing sorted out once and for all.)

Good idea. I'd like you to elaborate on that.

[Karl Smith]

ho*******@yahoo.com (Hostile17) wrote:

go************@kjsmith.com (Karl Smith) wrote:

"Maximum compatibility" and "minimum problems" are very different
things. Maximum compatibility with old browsers implies that you are
disinterested in using any of the features available to newer browsers
and that your main concern is making it "look the same". If so, why?
No, I'm definitely not in the business of trying to make everything
look the same.

I want a style sheet that does use the features of new browsers.

.... OK I'll put what I want in a different way. I want to provide my
developers a style sheet which allowed them to test a certain
declaration, see that it cause horrible problems in Netscape 4, and
easily move it to a "Netscape 4 can't see this" part of the style
sheet.
Yes, I saw some wise words on this subject earlier this week, but
neglected to bookmark it. (One gem of wisdom in an otherwise bad CSS
tutorial.) The problem with the parsing hacks approach is that it
relies on one bug to hide another. But there is no guarantee that
those two bugs will be fixed at the same time. If the next version of
browser X fixes the parsing bug, but not the bug in the declaration
you're tying to hide, you're stuffed. I was persuaded by the argument,
which was worded much better than I can.

I would think the safer approach is to keep separate basic stylesheets
for antique browsers and try to avoid them at the linking stage,
rather than trying to avoid them with some selector hack within a
stylesheet; avoiding Netscape 4 with the media attribute and IE with
conditional comments are reliable techniques. A stylesheet intended
for modern browsers is likely to be updated relatively often, but the
user base of NS 4 or IE5 isn't going to suddenly start increasing. Nor
are the dinosaurs suddenly going to develop the ability to use CSS
tables, pseudo-elements etc. - best to "set and forget"?

Others have widely differing views.

Don't let people "style up" pages. Write a glossary of
organization-approved classnames and when to use them. Let people mark
up pages accordingly. If it isn't in the glossary, it's "plain
vanilla" HTML.

That's certainly an interesting approach.

I'm not sure "don't let people style up pages" would work in our
organisation with many different kinds of web pages.

University?
One page has horizontal breadcrumb nav, another has traditional
vertical left nav, a third has *two* levels of left-hand nav and so
on, how can I write a stylesheet in advance for all these variations?

In theory it's quite easy, then along comes Microsoft...

(BTW: CIWAS should have such a glossary with the FAQ and get this
.navigation/.navbar/.nav/.sitenav thing sorted out once and for all.)

Good idea. I'd like you to elaborate on that.

Spent the wee hours this morning wrestling with IE6, I recant that
comment until I've investigated just how broken class selectors are in
the browser "everyone uses".

--
Karl Smith.

[Jeff Thies]

> > Don't let people "style up" pages. Write a glossary of

organization-approved classnames and when to use them.
That becomes a mess, you have to assign classnames to all these parts of
your document. Otherwise you have wide inconsistancy and worse problems.

I personally believe that you should have a minimum of classnames if you
want maintainability.
Let people mark
up pages accordingly. If it isn't in the glossary, it's "plain
vanilla" HTML.

That's certainly an interesting approach.

I'm not sure "don't let people style up pages" would work in our
organisation with many different kinds of web pages.

One page has horizontal breadcrumb nav, another has traditional
vertical left nav, a third has *two* levels of left-hand nav and so
on, how can I write a stylesheet in advance for all these variations?

I think that if you write one stylesheet for three fundamentally different
page types that you are writing an unnesessarily complex stylesheet that
will become difficult to maintain.

Look and feel maintainability is just as important as content
maintainability. What are you going to do if sometime they want the
appearance to change. That will happen, and then what? You have a big
complex problem.

Jeff

[Barry Pearson]

Jeff Thies wrote:
[snip]

I think that if you write one stylesheet for three fundamentally
different page types that you are writing an unnesessarily complex
stylesheet that will become difficult to maintain.

[snip]

Yes - but where do you draw the line? For example, I have a number of
tableless-layout "templates" and a number of colour-schemes. But I didn't want
(currently) 3 x 8 = 24 CSSs. In fact, from experience, I didn't want 8, or
even 3. (At one point I used a number of CSSs with @import for the common
parts, but that had its own problems).

The key was that the similarities out-weighed the differences. Although the
top-level layout was different, this was only about 5 CSS rules that were
different from one to another. And the colour schemes were easy to handle with
a single CSS. Nearly everything else - button styles, text styles, list
styles, were the same.

So I use decendent selectors based on a couple of "id"s (one in the <body>,
one in an outer <div>) to control these 24 combinations with a single CSS. See
the URL below.

I think the key is your "fundamentally different page types". Mine were not -
but for a fundamentally different purpose (such as photograph pages) I have a
separate CSS.

http://www.barry.pearson.name/articles/templates/

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Jeff Thies]

> [snip]

I think that if you write one stylesheet for three fundamentally
different page types that you are writing an unnesessarily complex
stylesheet that will become difficult to maintain. [snip]

Yes - but where do you draw the line? For example, I have a number of
tableless-layout "templates" and a number of colour-schemes.
But I didn't want
(currently) 3 x 8 = 24 CSSs. In fact, from experience, I didn't want 8, or
even 3. (At one point I used a number of CSSs with @import for the common
parts, but that had its own problems).

I'd never advocate seperate stylesheets for seperate colors schemes

The key was that the similarities out-weighed the differences.
I think that's it. But if the layouts are different...
Although the
top-level layout was different, this was only about 5 CSS rules that were
different from one to another. And the colour schemes were easy to handle with a single CSS. Nearly everything else - button styles, text styles, list
styles, were the same.

So I use decendent selectors based on a couple of "id"s (one in the <body>, one in an outer <div>) to control these 24 combinations with a single CSS. See the URL below.
There is always a tradoff between portability and readability. Certainly one
of anything is easier to move/install than several.

I think what you have done is clever, setting the page color scheme by
setting the body id.

That's good for someone trying out different schemes, but bad for adding a
lot of extra styles that would never be used in a production site. After
all, you are only using one color scheme!

Cheers,
Jeff

I think the key is your "fundamentally different page types". Mine were not - but for a fundamentally different purpose (such as photograph pages) I have a separate CSS.

http://www.barry.pearson.name/articles/templates/

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Jeff Thies wrote:

Barry Pearson wrote ...

[snip]

Yes - but where do you draw the line? For example, I have a number of
tableless-layout "templates" and a number of colour-schemes.
But I didn't want
(currently) 3 x 8 = 24 CSSs. In fact, from experience, I didn't want
8, or even 3. (At one point I used a number of CSSs with @import for
the common parts, but that had its own problems).

I'd never advocate seperate stylesheets for seperate colors schemes

Indeed - and I hope that my response appeared to be agreeing with you, with
additions, rather than disagreeing with you.

(I once did have 8 CSSs for the 8 colour schemes I used for my photographs. I
switched to using a single CSS with selection via the <body> because of the
maintenance costs).

[snip]

So I use decendent selectors based on a couple of "id"s (one in the
<body>, one in an outer <div>) to control these 24 combinations with
a single CSS. See the URL below.

There is always a tradoff between portability and readability.
Certainly one of anything is easier to move/install than several.

I think what you have done is clever, setting the page color scheme by
setting the body id.

That's good for someone trying out different schemes, but bad for
adding a lot of extra styles that would never be used in a production
site. After all, you are only using one color scheme!

[snip]

Only one per page. But different pages use different colour schemes.

Somewhere or other, I probably now actually use all 8 colours. I certainly use
all 3 layouts. And I also often use the optional extension (also based on an
extra <div> id with descendent selectors) that converts this basic 2-column
layout into a sort-of 3-column layout. So I have used a substantial part of
the 3 x 8 x 2 = 48 combinations, using one CSS.

An advantage of this approach is that, because I'm using 1 CSS, I can
confidently copy material from 1 layout to another, and from one colour scheme
to another, and the styles applying to the copied material change accordingly.
Colours change. Sidenotes change from fixed-width to percentage-width.
Sidebars change from left to right. With relatively little need for
class-attributes in the HTML.

http://www.barry.pearson.name/articles/templates/
http://www.barry.pearson.name/articl...ra_effects.htm

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/