homepage Welcome to WebmasterWorld Guest from 54.211.201.65
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

This 40 message thread spans 2 pages: 40 ( [1] 2 > >     
CSS Coding Standards - Part 2
Question 2
IanTurner




msg:3656521
 4:43 pm on May 22, 2008 (gmt 0)

Okay I need to put in place some CSS coding standards as people who do work for us come up with some real wierd and wonderful stuff.

Question 2:

As a basic standard which way would you go.

Would you layout your CSS file

#mydiv
#mydiv p
#mydiv h1

p
p.classa
p.classb
h1
h1.classa

.classc

Or would you layout your CSS file

#mydiv

p
p.classa
p.classb
#mydiv p

h1
h1.classa
h1.classb
#mydiv h1

.classc

and why?

 

poppyrich




msg:3656531
 4:59 pm on May 22, 2008 (gmt 0)

I would lay out the style rules in pretty much the same order that the elements the rules refer to appear in the document.

Why?

Makes for an mental model of the page that's easiest (at least for me) to grasp. Of course there are usually preliminary rules that reset browser defaults, set inheritable values on main parent elements, etc... but after that, if you're styling elements in the heading, those rules first, and so on down the line.

What's your concern?

IanTurner




msg:3656549
 5:22 pm on May 22, 2008 (gmt 0)

poppyrich - one issue with that is that different designers/coders may be responsible for different elements within a page.

Elements may also move about the page. For instance we may try putting a search box in header or in central content or in a right menu bar.

The css in appearance order has caused some of the nightmares we have now got.

Edouard_H




msg:3656654
 6:42 pm on May 22, 2008 (gmt 0)

In this case I would lay the CSS file out pretty much from generic to classes to id's and their child elements; It makes it easy to quickly identify which styles apply to page elements.

p
h1

.classc

p.classa
h1.classa

p.classb

#mydiv
#mydiv p
#mydiv h1

[edited by: Edouard_H at 6:42 pm (utc) on May 22, 2008]

appi2




msg:3656847
 9:25 pm on May 22, 2008 (gmt 0)

Here's a little example of what can go wrong.
CSS Specifity [webmasterworld.com]

poppyrich




msg:3657396
 2:07 pm on May 23, 2008 (gmt 0)

Gee, it's really a tough one because besides using a lot of comments in the CSS there's really no practical way I can think of to enforce a set of design principles that everyone involved will have to abide by.
Seems like more of a management problem - there needs to be a review process where changes are gone over by someone with the skills to view pages in their totality and edit accordingly.

pageoneresults




msg:3657426
 2:56 pm on May 23, 2008 (gmt 0)

I'll put the main styling at top, the actual layout as that is what I'll reference most during its tenure. The generic styles will be towards the bottom.

I alphabetize mine and I also use commenting to segment each section. For example...

/* Colors */
.red{color:#c00;}

/* Background Colors */
.bgeee{background:#eee;}

/* Font Effects */
.ttu{text-transform:uppercase;}

When it comes to containing divs and specificity, I keep all of those together in alpha order with their siblings. I'm one of those who feel that there is a place for everything and everything in its place. ;)

SuzyUK




msg:3657456
 3:21 pm on May 23, 2008 (gmt 0)

it is a toughie..

everyone has their own style of recognition, the basic way I would (advise to) do it is:

Generic Code first:
html,body {}
h1, h2, h3, h4 etc.. {}
p..
links..
ul..
form..

then the main layout divs, which would only have the widths, positioning, backgrounds etc.. at this point

#header
#headernav

/*columns*/
#sidenav
#main
#ads


#footer

The idea being that with this in place the basic layout is right and the plain text has minimal basic coloring formatting and default spacing/line-heights specified

then this is where I usually separate if not a separate stylesheet, then at least by a /*******************/ comment line

then I take the main divs
and apply the CSS in the same order as above (usually the same order as HTML source too) but nest the child elements under them

/*** #header ***/
#header .nav {}
#header h2 {}
#header p {}

/*** #sidebar ***/
#sidebar ul {}
#sidebar ul li {}
#sidebar ul li a {}
#sidebar p {}

etc..

then if there are any generic classes like .notice .warning .help - they get put very last in the sheet so the oddities can be easily found and usually I don't or can't put p.warning but just .warning as that can then apply to other things too but specificity usually means it has to be much longer however to keep it at the end and to save repeating rules you can group those selectors

e.g. at the end

.warning, #content p.warning, #sidebar ul.warning {color: red;}

I would always use at least one ID where possible in the selector and as few classes as possible earlier in the sheet as this keeps any specificity issues to a minimum, and then later should you need to get more specific say to add first and last classes to the nav lists you just go back up and insert them where they logically fit: e.g.
#sidebar ul li {}
#sidebar ul li.first {}

remembering to always follow the same notation as the previous selectors for the div so as to avoid later conflicts.

[edited by: SuzyUK at 3:23 pm (utc) on May 23, 2008]

SuzyUK




msg:3657461
 3:28 pm on May 23, 2008 (gmt 0)

Edward! :)

/* Font Effects */
.ttu{text-transform:uppercase;}

what is the point in adding a .ttu class? what happens when you want to change that elements text transform ;) may as well put style="text-transform: uppercase;" in the HTML it's a no-no to advise using non-reusable classes as a standard IMHO of course.

g1smd




msg:3658847
 11:59 pm on May 25, 2008 (gmt 0)

When would you use a class and when an ID?

That decision can cost you further down the line.

.

*** .red { color: red } ***

No. Don't do that. Label the class as to what it does, not what it looks like.

swa66




msg:3658889
 1:44 am on May 26, 2008 (gmt 0)

*** .red { color: red } ***

No. Don't do that. Label the class as to what it does, not what it looks like.

Depends on the semantics.
e.g. suppose you write about traffic lights, having a class red and green then makes sense, regardless of the color it's currently rendered in.

I think the trick is to make sure the html is "standalone" and free of layout as much as you can, including being minimal in what you need to add (IE will sabotage your efforts somewhat).

If "red" makes sense in the context of the content, (regardless if it makes sense or not in the context of the layout), then by all means use red as a name of the class.

But in general, yep: don't indicate in the name of the class how it's to be rendered, instead indicate what it is, it'll last much longer.

londrum




msg:3659050
 9:36 am on May 26, 2008 (gmt 0)

...and some people reckon class names play a part in SEO as well - as part of the algo. so things like class="hotel_address" and class="street_map" can be useful if those are the words you are targeting.

pageoneresults




msg:3659111
 11:55 am on May 26, 2008 (gmt 0)

What is the point in adding a .ttu class? what happens when you want to change that elements text transform may as well put style="text-transform: uppercase;" in the HTML it's a no-no to advise using non-reusable classes as a standard IMHO of course.

The point? So I can easily UPPERCASE what is encased in that class. I'm not too certain I would be changing that elements text transform and if I did, it would most likely be to remove it.

Where's the book that says I cannot name my Classes/IDs intuitively? Where? Where? Where? ;)

No. Don't do that. Label the class as to what it does, not what it looks like.

I did. The Class makes it turn red, that is "what it does" and "what it looks like". I can't think of a more intuitive name for something I want in red, I really can't! And, when I want things to really jump out...

<strong class="red ttu">[b][red]SHOUT IT OUT![/red][/b]</strong>

I've been involved in these types of discussions over the years. I've been naming my Classes/IDs the same almost since day one. I use an intuitive naming convention as opposed to what others may do. And, it works very well for me which is the bottom line. Others find it very easy to understand too and some have even taken on my styling style.

Depends on the semantics.

Yes it does! For example, I recently built a site that is boating related. Just to have fun, I named all the Classes/IDs with a nautical theme. So, for #wrapper, I used #hull and for anything on the left, I used #port and anything on the right, I used #starboard. The semantics are there if you're into boating. :)

I've found that taking the first letter of each word in the rule has helped me to easily identify those rules and to memorize them in the process...

.tac{text-align:center;}
.tal{text-align:left;}
.tar{text-align:right;}

Like most of you, I learned CSS on my own and I'm far from being a CSS Guru. But, I can sure lay out a site in a fraction of the time most others can using CSS. No one ever sat with me and said, "Edward, you should name your classes this way." I just used my common sense and strong sense of "naming prowess" and came up with my own system that has worked extremely well for over 10 years.

Where's the book on how to name your Classes and IDs?

it's a no-no to advise using non-reusable classes as a standard IMHO of course

I don't understand what is not "reusable". I "reuse" that class whenever I want, wherever I want.

What would you name a class that made the font UPPERCASE?
.ttu{text-transform:uppercase;}

What would you name a class that centered something? Or aligned it left? Or right?
.tac{text-align:center;}
.tal{text-align:left;}
.tar{text-align:right;}

What would you name a class that aligned something vertically? To the bottom? Middle? Top? Baseline?
.vab{vertical-align:bottom;}
.vam{vertical-align:middle;}
.vat{vertical-align:top;}
.vabl{vertical-align:baseline;}

I'm really interested in this. I can be taught new ways, I really can. I'm not an old dog just yet. But, again, I've been involved with these discussions before and I find "my way" to work just fine. By the way, what exactly is wrong with "my way"? Huh?

SuzyUK




msg:3659137
 1:21 pm on May 26, 2008 (gmt 0)

you know there isn't one :)

I use an intuitive naming convention as opposed to what others may do. And, it works very well for me which is the bottom line. Others find it very easy to understand too and some have even taken on my styling style.

that's the point, it's intuitive to you, it works for you, but, it's not intuitive if visualising a design from markup - your method means you have to know what the design is at the time of marking up - that's not the point of CSS, or having a designer.

Trying to bring this back to the context of the question, if you're trying to set up a standard for a large site with a separate programming/design teams, which I take it Ian has, seeing as he said:
different designers/coders may be responsible for different elements within a page.

It's not a CSS "standard" to have to go into the HTML to have to change a style, the whole idea is to keep it separate. so that designers can make any changes necessary.

You might know at the start that you want some text to be red, but how can you know that you *might* need that to change to a softer shade of pink once the design is complete because the red is just too harsh? are you coding the design or the markup?

so... if your <h2>'s are to be red, in uppercase, 1.6em and centered, your HTML would look something like this:

<h2 class="red ttu tac fs1-6">your heading</h2>

to change that to be blue (because mr siteowner decides he wants the foo section of his site to blue, the bar section to be yellow, but the baz section to stay red) you need to find every instance of the h2 code in the whole website in order to change the class name red to blue or yellow, this has now become a programmers, rather than the designers responsibility, whereas if you've set yourself up with a h2 classname, and have already IDentified the sections/ divisions so that all h2's site wide follow the same style you go to the one instance in the stylesheet

#foo .myh2class {
color: blue;
text-transform: uppercase;
text-align: center;
font-size: 1.6em;
}

#bar .myh2class {color: yellow;}
#baz .myh2class {color: red;}

and change/add the new color values in one place (a two second job for a designer)

That's what is wrong with your method, you're not separating your team responsibilities according to their job title, you're doing it all, or at least controlling it all. :)

The other suggestions about categorising/classifying the elements according to the section (either page or site) they belong in makes much more intuitive sense to me, because I'm a CSS designer, I don't need to know PHP, ASP, or whatever you programme with, I could make your changes at the design level while your programmers do what they do best!

Not naming classes according to their function has been the basic advice of any CSS coder I know, since it started being used, if you've not understand the why and have developed your own way that's fine, but it is not what I would call the best advice for a standard.

One last time, as I see you've added a bit to your post since I started typing..
what exactly is wrong with "my way"? Huh?

Like I said before your way around you would be as well writing the styles inline because you're doing them at markup time, the designer or design team are not going to have the freedom to make changes without the ability to change the HTML markup. Why bother with the external stylesheet at all, you are not separating the design from the content you are only saving a few bytes in the HTML source - that's not CSS. Also by making up all those extra classes just to provide a way of labeling what is essentially an inline style you are just provide an extra layer of learning what your business coding convention is (first letter replacements) and it'll be the programmers not the designers which have to know this convention, they already know you want that text to be colored red, and they know that
style="color:red;" will achieve it, but instead they have to learn that you have a secondary language in order to apply this.

Hardly the best advice in the context of the question which is about coding standards (or I read it as "best coding practice" advice to help decide on a company standard)

Of course there's no manual on naming conventions but as with any language there is always best practice guidelines, it's not a best practice guideline to name classes according to function, everyone is free to code to their own style as long as they are the one in charge of their site, which is why it works for you,

I would not recommend your method to anyone, even if it works well for you - sorry

as for reusable classes..

.notice {color: red;} is reusable because you can apply the "notice" class to any element, div, h2, etc.. as you will likely know at the time of markup which of your elements are a customer notice for example, that's a semantic function as opposed to a design one.. a designer can subsequently restyle the notice class to fit with the overall site design e.g.

div.notice {color black; background: yellow;}
div.notice h2 {color: red;}

.red {color: red;} is only 'reusable' whenever you want RED text, what happens if mr siteowner decides he wants his "notice" text to be in lime green.. that class name is no longer reusable in it's context unless you're willing to write .red {color: #0f0;} into the stylesheet, you have make up a new class instead of reusing the existing one.

pageoneresults




msg:3659143
 1:45 pm on May 26, 2008 (gmt 0)

<h2 class="red ttu tac fs1-6">your heading</h2>

That's not going to happen. I understand where you are coming from and maybe I need to expand a bit. I of course use styling on core elements. That <h2> is going to be styled from the CSS, not on page.

No, many of my styles have come after the initial design because I was handed something that was the base template and then I needed to add reusable on page classes to get the job done. You're a CSS Designer, I'm not. It took me quite a while to figure out what the heck you had going on with your 3 column template!

I really wish I had someone with me in the beginning to tell me that what I was doing may not have been in my best interests. Truthfully, I've never really encountered any of the issues you are bringing up. Red is a common color used to emphasize something "visually". And yes, I know the apparent challenges in using color to do this.

It's not a CSS "standard" to have to go into the HTML to have to change a style, the whole idea is to keep it separate. so that designers can make any changes necessary.

Ah, a perfect world! Unfortunately it is far from being a reality for many, including myself.

You might know at the start that you want some text to be red, but how can you know that you *might* need that to change to a softer shade of pink once the design is complete because the red is just too harsh? are you coding the design or the markup?

The original design template is pretty much static. It contains all the core elements which have their applicable styles applied. I'm surely not going to do...

<h2 class="red ttu tac fs1-6">your heading</h2>

That's a bit extreme. In fact, I would rarely have a class on a core element like that.

That's what is wrong with your method, you're not separating your team responsibilities according to their job title, you're doing it all, or at least controlling it all.

In my case, I'm providing a core set of classes that can be used "on page" to style additional elements that are not part of the core styles. It happens, and it happens regularly.

I could make your changes at the design level while your programmers do what they do best!

That's the goal and a lofty one at that. If only programmers would do just that, program.

Like I said before your way around you would be as well writing the styles inline because you're doing them at markup time.

Claire, I'm doing them at both design and markup phases just like many others probably are. The initial design will have all of its core styling. But, as that website grows and the design expands, things happen. And, I end up doing things based on my level of CSS and what appears to work well for everyone involved with the projects. We try to keep things "very simple" and you are not going to find many classes assigned to core elements. But, you might find something inline that is styled using one of the "add-on" classes after the design phase.

Of course there's no manual on naming conventions but as with any language there is always best practice guidelines, it's not a best practice guideline to name classes according to function, everyone is free to code to their own style as long as they are the one in charge of their site, which is why it works for you. I would not recommend your method to anyone, even if it works well for you - sorry.

Again, show me a book and/or set of guidelines that "tells me" how to name my Classes/IDs and I'll be a happy camper. We could probably pull stylesheets from the top 50 websites and not find much amongst them that was common, or could we? In this case, I think its one of those "what works best for you" type scenarios. Your level of CSS knowledge is not typical for many teams. Well, you'd probably be writing the guidelines for everyone else. For the rest of us, we need to work with the "norm" and not "a perfect world" example.

CSS allows freedom to the nth degree. How do you standardize something that allows you to achieve the desired results using a multitude of CSS strategies? How?

P.S. You're starting to help me understand my ways may not be the best. Once my hand gets smacked a couple of times I perk up and listen.

pageoneresults




msg:3659177
 2:23 pm on May 26, 2008 (gmt 0)

Okay Claire, you're opening my eyes, actually everyone participating is, you too g1smd with your .red reference. :)

I really wish there was a book that "showed" me how to name my Classes and IDs, I really do. I guess we wouldn't be having this discussion if such book existed, huh?

If I were to take the top 10 CSS posters here at WebmasterWorld and present a design request to them, I know I'm going to get 10 different CSS strategies, no two are going to be alike. Each one will be based on that person's level of CSS knowledge. How do you write a set of standards for naming conventions in this type of "freedom" environment?

IanTurner




msg:3659218
 3:45 pm on May 26, 2008 (gmt 0)

The other suggestions about categorising/classifying the elements according to the section (either page or site) they belong in makes much more intuitive sense to me, because I'm a CSS designer, I don't need to know PHP, ASP, or whatever you programme with, I could make your changes at the design level while your programmers do what they do best!

This is exactly what I am looking to achieve - the less the application coders have to do with the style or CSS the fewer design errors the site gets.

and they know that style="color:red;" will achieve it, but instead they have to learn that you have a secondary language in order to apply this.

In my experience there are few people who do both design and coding well. But I would say that to achieve the best results you need a designer, a CSS coder and an application coder
(and application coder could be split further too.).

And this discussion is helping me understand too - I don't know how I'm going to be able to translate what I know into some guidelines yet either.

g1smd




msg:3659267
 5:17 pm on May 26, 2008 (gmt 0)

*** suppose you write about traffic lights, having a class red and green then makes sense ***

It wouldn't make any sense at all for a country that uses, say, blue and yellow for their lights.

OK. maybe no-one does that now, but you never know what may happen later.

I would use class names of "go" and "stop" (or similar) in that case.

swa66




msg:3659287
 6:06 pm on May 26, 2008 (gmt 0)

I think the easiest to get a design rolling:

Include a standard header and footer, so the designers can get control of those parts, even the html.

If the layout is tricky and intertwined with the content: use a template system.

After that the software developer's job gets easier: they talk to the designers, but the designers get control over the look&feel of it all.

I'm not sure, but I guess getting this in place will give you much more than standards for which name a class should have.

SuzyUK




msg:3659294
 6:12 pm on May 26, 2008 (gmt 0)

Yes Edward, I realise that nothing ever works smoothly once a site starts to grow, however because this probably affects most sites regardless of their coders level is exactly why I try to say get the basic markup right first, even add in extra hooks, spans, em's just in case to help take care of a standardising the CSS

a lot of the advanced coders we could probably target an element without an extra class using advanced selectors, but as that's our Utopia I'll give ;) and say I would advise when building a site (or a soon as you need to get the programmers to change anything) rather than setting up extra *generic* "just in case" classnames in the CSS, which you would then have to add to the HTML anyway, rather go in and add extra CSS hooks, even wrapper divs/spans (e.g. like is used in image replacement), but don't even think about the final design, colors etc.. rather add in what could be useful going forward.. what I mean by useful is, something you have no specific plans for yet but might need to add to in the future, like adding an image replacements for headers, or

e.g. if that red text is a warning or notice make sure the division (div) the h2 or <p> or whatever elements are to be taken notice of are inside a classified area, use whatever classname you like don't restrict it to nowing what the actual text is going to look like you don't need to care about that yet.. - you can style an h2 {} differently from an h2 em {} and the <em> element is more semantic when describing what your red text is doing. also you can style a .notice p {font-weight: bold;} different to a .notice h2 {color: red;} so you see you are again able to reuse the class name.

In this day and age of different medias one should be thinking more in terms of the semantics of the HTML elements themselves than knowing what the final look across medias is going to be, adding/naming classes for a single property value is akin to using font tags with it's associated attributes, it's adding a fixed style via the HTML (well not quite as you can change the style on the class regardless of what it's called but h2.red{color: blue;} doesn't really make much sense as a standard does it?).

To me if you are trying to set a CSS standard for your employees to follow (as a base guideline) you need to get the HTML standard down first. for too long programmers had written programs that produced the only HTML they knew how to, but that has changed massively in the last few years, as knowledge does inevitably cross barriers. There is now a lot of emphasis on producing semantic HTML i.e. using hx elements for their intended purpose and not just because they make text bold - this is because it needs to make sense to more medias than just the visual screen.

If you need to take the styling inline to overcome a previous template shortcoming by all means use the style attribute that's what it's for, but adding in a class to add one style attribute via a stylesheet is simply an added layer (no matter what you call the class actually), If you're in the HTML anyway why not just add a proper CSS hook in the right place be it a e.g. <span>, <em> element or adding a <div> around the whole part of the page it applies to e.g. if a division of the page is a warning/notice then classify it as such.. it very rare that a single element should require a class applied to it (perhaps first/last classes on nav lists but that's all I can think of

We could probably pull stylesheets from the top 50 websites and not find much amongst them that was common, or could we?

It would be an interesting exercise and as far as I can remember someone has already done it as a study to see if 'standardising' some of the names would make sense. I can imagine SE's might like it if they could find the "main content" and give it more emphasis? , but I can't remember who it was so.. anyway I'm pretty sure you could find standard things like sidebar, content, heading, nav, main etc.. .. however what I'm almost willing to do is bet we won't find a lot of support for your method of one classname per class named for the purpose, more likely you'll find inline styles. oh and btw Google isn't and never has been a great example as they don't exactly use a complex layout and have only recently started adding IDs ;)

I know it's not easy to get it right from the start I still do not have a "perfect" site and have resorted to adding in class here or there but learning from past mistakes I always make sure that class is a hook rather than a one off which I might have to search and replace site wide for later.

Naming conventions..
you think is bad what about about the fact that you can practically name your elements what you like ;) just like HTML where you could use simply divs or spans to produce the whole markup.. would you? There is no standard per se but it has been oft spoken about and is now second nature in this and other forums.. you know what I mean when I say nav div, header div, footer div or wrapper sidebar column, you know that those divisions contain the the right elements headings, paragraphs, lists etc.. so that is and has to be the basis of any CSS standardisation in an organisation. It's second nature to most who deal with CSS, just look at the CMS templates that are provided. just call it my way of letting you know that you might be making it worse for the future coders if you follow your convention and then someone subsequently takes over the site from you who knows that CSS is more than just applying a text-decoration or color ;) No offence meant to you as I know we all use what works at times. But I would hate to see someone build on this method as a base standard which is the Topic in question here, rather build in too many hooks in the original HTML, all of which needn't be classnames.

I know I'm going to get 10 different CSS strategies

hmm no I think you might get a few different layout templates, but I'm very confident that the actual main divisions (ID's) and the following CSS strategy would be similar inside the original framework as we've all already virtually said the same thing about naming for what it does not what color it's to be

as was said earlier it'll last longer because usually specificity can be added to pinpoint elements e.g. in my sidebar example earlier I may well have a class (or ID) name on three different ul's inside the sidebar .. but I might not need them at the start (for stylling purposes) as all lists are to look the same, however I can and should classify them as different ul's right at the HTML start level, regardless of what they are to look like they are to hold different things e.g. one holds the sidenav, one holds the favourite links, and one holds the recent visitors.. so semantically they are different from the outset regardless of what you think the text-decoration is to be and they should be given a hook to indicate that at the time of writing - that's what I mean about hooks.. as a design element you might not them but your code is now standardisable

#sidebar .nav ul li {}
#sidebar .favs ul li {}
#sidebar .recent ul li {}

note in this case I wouldn't be adding the class just so I could say
.recent {color red;}

I am adding it as a hook to target the whole of the contents inside that particular ul or even an h2 inside the classified section.

Same applies if you want to add emphasis use the <em> or even a span element and target it via it's parent/ancestor class or ID.

it would be easy to write a base standard regardless of the classnames if you think of the document as a whole instead of trying to style one <p>.

Start with the page ID then the main division ID's then work inwards through the division classes to the elements classes until you get as far as you can go which is the inline style attribute, if you're in there and need to change the HTML go back out a bit and add a hook to an ancestor it will enable you to use it again and again.

.. now I had to cut this as it was way too long, and while I hope it's still useful we're taking Ian's topic a bit off Topic by debating naming conventions ;) so see next instalment :)

SuzyUK




msg:3659313
 6:36 pm on May 26, 2008 (gmt 0)

Ian,
But I would say that to achieve the best results you need a designer, a CSS coder and an application coder
(and application coder could be split further too.).

With that I agree, and this is where your standard needs to come in so they know to what levels they can cross as inevitably they will have to. I would say the CSS coder in the middle is the most likely to cross into the other 2 x fields as they will (or should if they're any good) cross and have the most flexibility as to what they can work with, for instance if the programmer says it'll just take a minute to stick in an inline style, but the CSS coder shows him/her where they could put a wider hook the programmer should know from your guidelines what your preference is.

and if in your guidelines you've stated that there should be no "orphan" classes without a jolly good reason then they will have to work together to find the best solution to suit your design.. if that then means a design compromise too because it really is a singularity.. there's the team work :)

I don't know how I'm going to be able to translate what I know into some guidelines yet either

I would always start with this base in mind..

  • body ID (named for site section)
  • wrapper with ID (still recommended as a useful hook even though IE5.5 is nearly dead)
  • 2/3/4 columns (each with ID) 1 x maincontent, 1 x sidebar1, 1 x sidebar2, 1 x sidenav (note no lefts or rights as columns can be swapped ;)
  • each of those column/sections has a nested div inside it with a classname like .pad a useful hook to get around box model issues to add padding or margins and also to add "sliding door" type rounding images, or simply a second background image.. many uses but unknown & possibly not used at the outset
  • header, subheader and footer all with ID's and possibly nested "pad" hooks too for secondary backgrounds

then inside the columns start classifying larger divisions i.e. like the different ul's in the sidebar, or adgroups in the other one - this is where it generically runs out and becomes site specific but if you've built a wireframe then the areas of content your site might need should be more obvious. At this stage build in as many hooks as you can, at the "top" level of the internal divisions i.e. div.notice, div.meta, div.featured don't even think about what the elements inside need to look like you already have
#body #wrapper #column .pad div.mydiv to be able to go through to them fairly specifically

then and only then if you think there will be oddities use spans, ems and strongs as that's what they're for

e.g. <h2><span>This heading is going to be extra emphasised or have a background image</span><h2>

though note I would add first and last class names to first and last <li> elements regardless of their style at this point too as they can be invaluable. remember you can apply more than one class to an element so that won't conflict if you're goijng to be adding an "active" class by a scripting method. Note only need .first and .last as if you've set up the outer divs properly they can be reused, i.e. you don't need nav-first, subnav-first

then if you follow the logic of the HTML layers outside to inside, you can follow the same convention in your CSS standard, tell them to remain as general as possible using the outer layers/ID's first this should help avoid the need for orphan elements or indeed having too much CSS because you're using too many classnames which need overrides for styling purposes rather than hooking.

e.g. don't simply style li.first hoping it will apply to all in the page because #sidebar ul li will overrule it

if you've set your general styles for the sidebar in the style of :
#sidebar ul li {}

if all lists in sidebar are to be the same it should get it's "first/last" class targeted like
#sidebar ul li.first {}

if only your favourites list is different
#sidebar .favs ul li.first {}

.favs ul li.first will not overrule #sidebar ul li so again stick to using the convention, don't replace the ID for a classname - [b]add in the hook[/b]

see the hooks are there and the targeting specification is being adhered to, and specificity needn't be a problem

when you see them together in the stylesheet it's patently obvious which is doing what, whereas [code]li.first {} (what I would call an orphan) at the bottom of the sheet will never overrule the sidebar ones doing it this way and will call for tools such as web dev toolbars to find out why and cause stylesheets (and possibly HTML) to become bloated quite quickly if HTML additions are performed here ;)

if you did want every single "first" class to have the same properties it should go at the end of the sheet (well anywhere but this is where I recommend putting overrides) and can be overridden using:

#wrapper ul li.first {}

simply cast the hook wider if it's to apply to more divs, it's still an ID so the specificity is the same and will overrule all li's with the class of first inside the outer most wrapper

I think the best standard could be ensuring that your team know that each dept deserves to get a say and that the goal is about making everyones life easier especially yours ;)

g1smd




msg:3659322
 6:58 pm on May 26, 2008 (gmt 0)

Although it's a long read, the above few comments really deserve to be read, and read again, for all the valuable insights they contain.

SuzyUK




msg:3659330
 7:02 pm on May 26, 2008 (gmt 0)

Now I'm going to sit back and read all this :)

I apologise if my grammar is not good, or sentences are disjointed in the previous posts, I've been typing these replies on and off all day in between work and play,

I never really saw all the replies as I couldn't keep up with you Edward, on a quick read I realise I never said thank you for your thought provoking questions, some of them are making me think and "grounding me" hehe - I know it can't be perfect and I also know some of my examples are extreme and that you don't use them quite like that but I hope you also know that although you've not seen it I know it applies as I've seen a lot of weird and wonderful stylesheets :) - I also think you're thinking in terms of a singular design.. as you state it's a static template however that's what I mean about coding to design instead of marking up content.. if you find you're adding inline styles "after the design phase" then take that as a learning curve that if it can happen once it can happen again and widen (or add to) your "standard" to allow for that next time?

cheers all, I do think there really is a way to help standardise, but it would likely be very company specific depending on the size of the teams involved and of course the BOSS :)

lastly no offence is intended to anyone! Edward knows me and I'm being a tad harsh on him I know but he can be quite stubborn himself too ;) ..

Clark




msg:3660540
 4:51 am on May 28, 2008 (gmt 0)

This discussion is wonderful and very useful. I've learned a lot (Claire is a wonderful teacher). But these questions also scream out the point that the CSS protocol needs to be rethought out and recreated from scratch. There are so many issues with it.

It's too flexible. Too many ways to do the same thing. One page can affect a whole website. That's power but some constraints are crying out to be made because clearly it's really hard to even come up with a standard way to lay out a css file. We've all come across the same problems as a site grows...

I'm in middle of reading "Psychology of Everyday Things" and for those of you who have read it, perhaps the issue is that the mental model of css is problematic and therefore very hard to learn...

IanTurner




msg:3660670
 9:28 am on May 28, 2008 (gmt 0)

I don't think that the protocol needs to be rethought out, its just people need to share best practice, like we are doing here, and implement standards within their own organisations so that people working collectively can work more efficiently.

Hester




msg:3660671
 9:29 am on May 28, 2008 (gmt 0)

the CSS protocol needs to be rethought out and recreated from scratch

Not sure I agree. And it's highly unlikely considering we haven't even reached CSS3 as a recommended standard yet.

It's too flexible.

Better that than too strict.

One page can affect a whole website

Great! Welcome to the power of CSS.

it's really hard to even come up with a standard way to lay out a css file.

Who says there has to be a standard way? So long as the styles are applied correctly (ie: bearing in mind inheritance) and lines aren't wasted repeating styles, then what is the problem here. I doubt if you look at the source of HTML pages that they are all laid out in a single standard way.

Think of it like writing a story. Every writer will have their own style. So long as it 'works' that's OK isn't it?

Myself, I do my stylesheets like this:

- main elements first (body, headers etc)
- then key layout divs
- then I style the IDs, classes and links as separate sections
- lastly I put in any per-page styles. (Eg: if only one page has a special style needed I add an ID to the body tag and style it that way)

As for BOOKS, I'm sure there are MANY published on how to name CSS. I'm sure someone like Eric Meyer or Dave Shea has made one. And what about the countless articles on the web?

limbo




msg:3660727
 10:51 am on May 28, 2008 (gmt 0)

Great thread! Good timing too - Can I add this to the conversation - it's a bare-bones global style sheet that we are developing to help streamline the project set up processes. We are also developing JS, and xHTML templates too.

/*

****************************************
Site title and year of first publication

Development company:
Author:
Author e-mail:
Revision dates:

****************************************

Reference palette:

Greys:
#000 (darkest)
#000 (dark)
#000 (medium)
#000 (light)
#000 (lightest)


Colours:
#000 (darkest)
#000 (dark)
#000 (medium)
#000 (light)
#000 (lightest)

*/

@import url("reset.css"); /* uses Eric Meyers reset reloaded CSS - resets all CSS properties of HTML elements - imported this way to keep things simple for us, not necessarily recommended */

/* common HTML */

body {text-align:center; background:#fff; font-family:verdana, helvetica, sans-serif; font-size:100%;}

h1 {position:absolute; top:-1px; left:-1px; height:1px; width:1px; z-index:-1; text-indent:-1000em; visibility:hidden;} /* H1 is ALWAYS the first HTML element in the page body - so we hide it from users to make the layout easier */
h2 {padding:0 0 10px 0; color:#000; font-weight:normal; font-size:1.2em; line-height:1.6em;}
h3 {padding:0 0 10px 0; color:#000; font-weight:normal; font-size:0.9em; line-height:1.5em;}
h4 {padding:0 0 10px 0; color:#000; font-weight:normal; font-size:0.8em; line-height:1.5em;}
p {padding:0 0 10px 0; color:#000; font-weight:normal; font-size:0.7em; line-height:1.4em;}

span {line-height:1.4em;}

a {text-decoration:underline;color:#000;}
a:link, a:visited {color:#000;}
a:hover, a:active {color:#000;}

li {font-weight:normal; font-size:0.7em; line-height:1.4em; letter-spacing:0.01em; color:#000;}
ul {}

table, tr {}
th, td {font-size:0.7em;}

em {}
strong {}
address {color:#333; font-weight:normal; font-size:0.7em; line-height:1.4em; letter-spacing:0.01em; color:#000;}

input {margin:0; border:0; padding:0; font-size:0.7em;}
fieldset {margin:0; border:0; padding:0;}

/* accessibility */

#access {position:absolute; top:-1px; left:-1px; height:1px; width:1px; z-index:-1; text-indent:-1000em; visibility:hidden;} /* hides access links for browsers but not screenreaders, or so I believe */
#access a {text-decoration:underline;font-weight:bold;}

/* page layout */

#grip {margin:0 auto;text-align:left;}
#holdall {}

/* masthead */

#masthead {}
#logo {}
#logo a {}

ul#nav {}
ul#nav li {}
ul#nav li a {}
ul#nav li a span {visibility:hidden;} /* hides text links in image based navigation */

ul#nav li a:link, ul#nav li a:visited {}
ul#nav li a:hover, ul#nav li a:active {}

/* content (delete as appropriate) */

/* #leftcol */

#leftcol {}

#leftcol h2 {}
#leftcol h3 {}
#leftcol h4 {}
#leftcol p {}

#leftcol a {}
#leftcol a:link, #leftcol a:visited {}
#leftcol a:hover, #leftcol a:active {}

/* #centrecol */

#centrecol {}

#centrecol h2 {}
#centrecol h3 {}
#centrecol h4 {}
#centrecol p {}

#centrecol a {}
#centrecol a:link, #centrecol a:visited {}
#centrecol a:hover, #centrecol a:active {}

/* #rightcol */

#rightcol {}

#rightcol h2 {}
#rightcol h3 {}
#rightcol h4 {}
#rightcol p {}

#rightcol a {}
#rightcol a:link, #rightcol a:visited {}
#rightcol a:hover, #rightcol a:active {}

/* generic classes */

.clear {clear:both;}
.hidden {visibility:hidden;}

.more a {}
.more a span {visibility:hidden;}
.more a:link, .more a:visited {}
.more a:hover, .more a:hover {}

.yay {font-weight:bold;color:#060;}
.mmn {font-weight:bold;color:#fc0;}
.nay {font-weight:bold;color:#C00;}

/* footer */

ul#footer {}
ul#footer li {}
ul#footer li a {}
ul#footer li a span {}

ul#footer li a:footer, ul#footer li a:visited {}
ul#footer li a:footer, ul#footer li a:active {}
#preloader {visbility:hidden; position:absolute; top:0; bottom:-0.1px; height:1px; width:1px; z-index:-1;} /* houses images for preloading and fixes left side scroll bar in FF and Safari */

/* the end */

It's supposed to be as generic as possible but I am sure we are still a way off anything worth implementing...

[edited by: SuzyUK at 5:19 pm (utc) on May 28, 2008]
[edit reason] fixed scroll [/edit]

jetboy




msg:3660778
 11:42 am on May 28, 2008 (gmt 0)

Ian,

For my 2 cents: I've been leading the front-end build for a market-leading travel-centric web developer for the last few years. The basic HTML and CSS hasn't been reinvented for each site; it's evolved from site to site. We've tried some things out, been down some dead ends, and when I left this role we had a pretty stable system in place. We're talking large e-commerce sites though, so for those working on five pagers this is going to be unnecessarily complicated.

inline.css
Starts with the base font definition, then goes on to headings, paragraphs, lists, images etc. This is always the first stylesheet to be linked in. Styles tend to be weighted towards defining the actual HTML elements. i.e.:

h1 {
}

h2 {
}

p {
}

ul {
}

block.css
Followed by block.css, which contains multi-columns structures, data table formatting, subnavigation, gallery and any other block level structures that are used on multiple pages. Styles in block.css can override styles in inline.css, primarily with descendant selectors. i.e.:

.bust-out {
}

.bust-out p {
}

.bust-out ul {
}

.bust-out, when assigned to a div may invert the background colour of the box, and the following declarations would style the p and ul elements to complement the new background colour.

my-page.css (example)
This (optional) stylesheet to be linked in is the page-specific stylesheet, which should have the same name as the page it applies to: about-us.css for about-us.html for example. It would be nice to think that there would be no styles in here, but in the real-world, working in a team, developers don't always follow the style rules. I'd rather any tweaks and hacks were in here than inline or stuffed into one of the main stylesheets.

template.css
Followed by template.css, which contains any CSS for areas that will not change over the whole site: CSS resets, header, footer, main navigation etc. As a lot of these elements are going to be unique, such as the logo, affiliation logos in the footer etc., they are referenced with their own IDs rather than descendant selectors. i.e.:

#logo {
}

instead of:

#header .logo {
}

This is good enough for smaller sites, but for bigger ones, you'll find that block.css starts to get really big. If it does, you should break it out into sections, such as section-subnavigation.css, section-gallery.css etc., for block-level structures that aren't used on every page. These can then be linked into only the page that need them; cutting down on loading in unnecessary CSS. The linking could be done straight from the HTML, or the page-specific stylesheet could import the others.

The end result will be lots of stylesheets, which if all your developers understand the system, will be a hell of a lot easier to deal with than one monolithic stylesheet. It's also great for caching, but unfortunately sucks for keeping the number of server requests down. That's one extreme. With any server-side language you have the option of merging together stylesheets server-side before delivering them to the browser, so you could have 50 stylesheets to work on, but chuck out that one giant stylesheet to the browser. That's the other extreme.

Somewhere in the middle there's a compromise that'll balance server requests with browser caching. That line will be different on every site, and is really something you should look at after the site is built but before it's launched. Consider it performance tuning. If you do this, you'll find out that you're following one of the tenets of object oriented programming: Separate that which changes from that which stays the same.

Clark




msg:3660837
 1:28 pm on May 28, 2008 (gmt 0)

Hester & Ian,

I agree it probably won't happen, at least not for a long long time.

I've been upgrading my webdev skills, so in addition to learning css, I'm also on a usability and design kick, and css as a protocol is not very usable (i.e. very hard to learn). Html can be laid out in different ways and has flexibility with smart constraints... but smart non programmers have learned it very quickly whereas css is very hard for programmers and designers to wrap themselves around. I'm sure there's a much better way to achieve the positive and important aspects of css without the bad parts... But anyway, I won't respond any more to that issue in this thread because it's straying too far off topic. My fault but css threads always tend to do that..

appi2




msg:3660888
 2:07 pm on May 28, 2008 (gmt 0)

suzyuk
follow the logic of the HTML layers outside to inside, you can follow the same convention in your CSS standard

would that be
List the CSS by DOM and specificity.
tis the way I try.

This 40 message thread spans 2 pages: 40 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved