Forum Moderators: not2easy
This is not a specific problem I have. I want more generally start a discussion here about how you use comments in CSS. I do not mean the one you can use for hacking specific browsers but the ones you write in to comment and structure your files. Do you use them at all? Do you structure your file and if yes, how? Please let me know.
I also explicitly comment any hack I use with something like
/* :hack: fixes x bug in y browsers */. A lot of my code goes into templates so when we drop a browser from our support list it's easy to go through the file searching for and discarding any hacks specific to that browser.
additionally i do it quite the same as you describe. and mostly the first part/section i open is the part to reset the elements.
Because that's not the case, I never use comments, unless I'm cutting out code that I want to be saved, but not implemented.
I've never been big on commenting, it's been the same for programming.
[edited by: Xapti at 5:53 pm (utc) on May 18, 2007]
If the point is to turn the text (or whatever) green, then it's class = green.
...
A rule to float the site logo into the upper left corner and clear it? class = logoleft and so forth.
Ah yes... the exact WRONG way to use CSS.
One of the benefits of CSS and separation of presentation and content is that once you define your markup, you can make changes to the presentation by only touching the CSS file. In your example, you're using class names that describe the "presentation" instead of the "content", which is bad. Here's why:
Suppose you do something like this:
<p class="green">Copyright 2007...</p>
Some day, you decide that you want this to be blue instead of green. If you modify the style for green to have blue color, that's going to be confusing. The alternative is to find all of the places in your markup where you've specified class="green" and change it to class="blue". You're losing the benefit of not needing to touch the markup in this case.
A much better approach is to use class names that describe the content. For example:
<p class="copyrightNotice">Copyright 2007...</p>
Then in your CSS, you would have:
.copyrightNotice { color: blue; }
In this case, you only have to change the CSS, and there is no confusion about what the style does.
[edited by: Fotiman at 10:50 pm (utc) on May 18, 2007]
/* ============================================ */
/* domainname.css */
/* ============================================ */
/* Last Updated: 01/01/1980 */
/* ============================================ */
/* author: Alfred E. Newman, aen@mad.tld */
/* ============================================ */
Next, I leave myself some notes about colors in a comment block, like:
/* COLORS: */
/* BLACK rgb(0,0,0) #000000 */
/* WHITE rgb(255,255,255) #FFFFFF */
/* DK. GREY rgb(63,63,63) #3F3F3F */
/* MD. GREY rgb(127,127,127) #7F7F7F */
/* LT. GREY rgb(191,191,191) #6F6F6F */
I add comments ahead of sections where multiple classes and selectors are related, like:
/* ===================================== */
/* CSS for buttons in Top Navigation bar */
/* ===================================== */
..and at the end of the file I add one more block:
/* ===================================== */
/* EOF: domainname.css */
/* ===================================== */
As for naming ... here are some examples:
- DIVs for structure by ID:
-- #container : if one overall container is needed, due to poor support for width etc. on 'body'
-- #navigation : self explainatory
-- #content : main page content
-- #footer : page footer
I then style the main semantic header etc. elements in order to be able to use them well, i.e. H1, H2, H3.
'em' does not need to be used for italic and so I redefine it for any emphasised inline style I need
I then break down the style sheet by DIV:
- For the navigation DIV:
-- #navigation ul : style the unordered list to use for nav
-- #navigation li : style the list items for it
-- #navigation h2 : style the h2 to make it small enough to be a menu heading
- For the content DIV, I tend to use the globally applied styles - this means if the DIVs for some reason are broken or missing, the content still presents reasonably
- For the footer DIV:
-- #footer a : style footer links
Obviously there are many more... but that's the general way I go about it and I've never found it difficult to use without comments.
I've never been big on commenting, it's been the same for programming.
My biggest concern with comments, and this goes for HTML as well, is that they increase load times.
My reference code is about as structured as lexipixel but I put my colour (and background-color, etc.) comments repetitively in line where specified rather than in one grouping. I want all information to hand without scrolling.
I agree (because I do those things too) with Robin_reala on hackery comments and Fotiman on naming format.
You need to know who did it, when, and why.
You also need the ability to change things quickly and easily.
You may also want (OK actually only I have such compulsive behaviour) to remember what was changed, when, and why: versioning.
I sometimes even put little ascii-paintings inside my code to write down the measurements of the default layout:
* ¦ 788 ¦
* ¦ 20 ¦ 748 ¦ 20 ¦
* ¦ 20 ¦ 304 ¦ 444 ¦ 20 ¦
(The stylecodes of this Forum do not properly preserve the Indents I wanted to use in this Example)
And in a more general perspective, what do you think about this type of commenting CSS:
/**
* Bubblesoap Website Stylesheet
*
* Global Screen Stylesheet for the Bubblesoap Website
* with all the Summer 2007 Styles.
*
* @style Summerscape
* @media screen
*
* @version 1.0
* @date 2007-05-05
* @author Carsten Banski
*
* @colordef Red Wine : rgb(178,25,34);
* @colordef Grassgreen : rgb(74,192,75);
*/
...
/**
* Reset
*
* Reset default Browser Rules
*
* @section Reset
* @todo Input Elements missing
*/
... CSS Rules ...
/**
* Layout
*
* Default positioning of the main site elements
*
* @section Layout
*/
... CSS Rules ...
/**
* Min-Height IE Hack
*
* @hack 100% Page Height
* @hackfor IE 5.5 & 6 Win32
*/
... CSS Rules ...
(The stylecodes of this Forum do not properly preserve the Indents I wanted to use in this Example but I think you understand how this should look like)
But only on the dev server. When uploaded to live, the comments are automatically stripped out. As is most of the whitespace.
That gives me, behind the scenes, some extensive in-line notes while putting the smallest/fastest files up for serving to the world.
And stops any embarrassing/rude design comments slipping into the public arena.
I'd've thought everyone does that. If you have a CMS (or whatever) that does not strip comments when uploading to a public environment, why not try another one?
@Robin_reala: what do you mean by overdoing comments? was this related to my example? If yes which part do you think is not useable or when does it not make sense in your opinion to use comments in CSS?