Comments on: Documenting CSS http://friendlybit.com/css/documenting-css/ Strategic web development Tue, 08 May 2012 22:48:12 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Emil Stenström http://friendlybit.com/css/documenting-css/#comment-30384 Emil Stenström Fri, 29 Feb 2008 08:08:53 +0000 http://friendlybit.com/css/documenting-css/#comment-30384 @Andreas: Yes, I really need a wider commenting area... @Andreas: Yes, I really need a wider commenting area…

]]> By: Emil Stenström http://friendlybit.com/css/documenting-css/#comment-30383 Emil Stenström Fri, 29 Feb 2008 08:08:32 +0000 http://friendlybit.com/css/documenting-css/#comment-30383 @Jens Wedin, Andreas: Thanks for all those great links and structuring tips, I'll look into them for my next project! @Jens Wedin, Andreas: Thanks for all those great links and structuring tips, I’ll look into them for my next project!

]]> By: Andreas http://friendlybit.com/css/documenting-css/#comment-30375 Andreas Thu, 28 Feb 2008 17:20:50 +0000 http://friendlybit.com/css/documenting-css/#comment-30375 Ah yes, in some cases I use a class rather than an ID as well if the module (or service (that's a new one to me, everybody here (Y!) says "modules")) will be included more than once. In some cases tho, like an article-listing I'd consider the article-listing to be the module, not the article(s), so i'll have a div#article-listing wrapped around all the articles, and each article gets a div#article-1234 as well, rather than just a row of div.article:s. I try to steer clear of classes as much as possible. I don't know why really but I rarely see them used in a way that's actually relevant to the HTML. In most cases classes represent too much design/behavior (.box, .left etc) for me to feel comfortable using them. The div[id] around the module adds to the structure of the HTML and is not there for styling but only for consistency and structure. Fact is <a href="http://code.google.com/p/aframework/" rel="nofollow">my framework</a> automatically adds wrapper divs around modules, this is great when you're updating a module using ajax and you want to fetch it without the wrapper-div because you're actually putting the response in the wrapper-div and should it contain a wrapper-div you'll end up with nested divs with the same IDs. Obviously it all depends on how you use classes, but to me IDs make more sense to wrap modules. Think I just increased Friendlybit's height by another 400px with this comment :). Perhaps a little wider comment-area in the coming design? Ah yes, in some cases I use a class rather than an ID as well if the module (or service (that’s a new one to me, everybody here (Y!) says “modules”)) will be included more than once.

In some cases tho, like an article-listing I’d consider the article-listing to be the module, not the article(s), so i’ll have a div#article-listing wrapped around all the articles, and each article gets a div#article-1234 as well, rather than just a row of div.article:s.

I try to steer clear of classes as much as possible. I don’t know why really but I rarely see them used in a way that’s actually relevant to the HTML.

In most cases classes represent too much design/behavior (.box, .left etc) for me to feel comfortable using them.

The div[id] around the module adds to the structure of the HTML and is not there for styling but only for consistency and structure.

Fact is my framework automatically adds wrapper divs around modules, this is great when you’re updating a module using ajax and you want to fetch it without the wrapper-div because you’re actually putting the response in the wrapper-div and should it contain a wrapper-div you’ll end up with nested divs with the same IDs.

Obviously it all depends on how you use classes, but to me IDs make more sense to wrap modules.

Think I just increased Friendlybit’s height by another 400px with this comment :). Perhaps a little wider comment-area in the coming design?

]]> By: madr http://friendlybit.com/css/documenting-css/#comment-30371 madr Thu, 28 Feb 2008 14:59:48 +0000 http://friendlybit.com/css/documenting-css/#comment-30371 @Andreas, I work like that too, except I mark up every modules (or service, as it is called in our current project) with classes instead. The CM lets the subscriber publish multiple instances of each service on a page, and this makes it impossible to mark services with unique IDs. :( @Andreas, I work like that too, except I mark up every modules (or service, as it is called in our current project) with classes instead.
The CM lets the subscriber publish multiple instances of each service on a page, and this makes it impossible to mark services with unique IDs. :(

]]> By: Andreas http://friendlybit.com/css/documenting-css/#comment-30366 Andreas Thu, 28 Feb 2008 11:24:04 +0000 http://friendlybit.com/css/documenting-css/#comment-30366 I always structure my CSS like I structure all my code; modular. Each module gets its own CSS-file. Any selector in a module-CSS must start with that module's ID-name (every module has a div with an ID of the same name as the module (div#recent-comments for example)). Module-files should _never_ style generic classes or elements. Everything should go through the #module-id. This way modules cannot mess with other modules and you know that if there's a layout-issue with the "Recent comments"-module you look in the recent-comments.css-file. Generic styling and reseting/styling of basic elements is all done in general.css. Sometimes I have a site.css which styles the header, navigation, content, sub-content and footer-modules in one file. It's sometimes easier to get an overview of the design if they're all in the same file. I've also written my own <a href="http://exscale.se/archives/2008/01/15/css-constants-and-compression-php-class/" rel="nofollow">constant-parser</a> that removes the need for CSS-classes, and I save nifty constants in constants.css (or, if it gets massive I start dividing that up as well depending on what type of constant it is (list-styles, table-styles, div-styles, icons). After working on 150+ modules-sites for 2 years this is easily the most straight-forward, easy-to-grasp way of structuring your CSS and it leaves you with very few bugs. How annoying isn't it when you fix a bug in one module only to introduce a new one in another? Structuring your code like this will eliminate problems like that. I always structure my CSS like I structure all my code; modular.

Each module gets its own CSS-file. Any selector in a module-CSS must start with that module’s ID-name (every module has a div with an ID of the same name as the module (div#recent-comments for example)).

Module-files should _never_ style generic classes or elements. Everything should go through the #module-id.

This way modules cannot mess with other modules and you know that if there’s a layout-issue with the “Recent comments”-module you look in the recent-comments.css-file.

Generic styling and reseting/styling of basic elements is all done in general.css.

Sometimes I have a site.css which styles the header, navigation, content, sub-content and footer-modules in one file. It’s sometimes easier to get an overview of the design if they’re all in the same file.

I’ve also written my own constant-parser that removes the need for CSS-classes, and I save nifty constants in constants.css (or, if it gets massive I start dividing that up as well depending on what type of constant it is (list-styles, table-styles, div-styles, icons).

After working on 150+ modules-sites for 2 years this is easily the most straight-forward, easy-to-grasp way of structuring your CSS and it leaves you with very few bugs.

How annoying isn’t it when you fix a bug in one module only to introduce a new one in another? Structuring your code like this will eliminate problems like that.

]]> By: Jens Wedin http://friendlybit.com/css/documenting-css/#comment-30364 Jens Wedin Thu, 28 Feb 2008 09:09:40 +0000 http://friendlybit.com/css/documenting-css/#comment-30364 Good write-up. This is really important when leaving your precious style file to another developer. Just the "Where do I add my own stuff" is good. A good thing if you don´t use your own "framework" that you can reuse in every project is to have a look at other frameworks like Blueprint. There are some nice stuff that you can be inspired of like structure and documentation. I would also recommend to have a look at minify. It combines, minifies, removes comments etc with multiple css files. The good thing is that you can work a lot with comments within the file, minify then removes this on the fly and makes a cached copy of the file. It also have a bunch of other great stuff in it. Here's an example of my css and the minified copy http://jedisthlm.com/wp-content/themes/jedisthlmV/screen.css http://jedisthlm.com/minify.php?files=/wp-content/themes/jedisthlmV/screen.css http://code.google.com/p/minify/ http://code.google.com/p/blueprintcss/ Good write-up. This is really important when leaving your precious style file to another developer. Just the “Where do I add my own stuff” is good. A good thing if you don´t use your own “framework” that you can reuse in every project is to have a look at other frameworks like Blueprint. There are some nice stuff that you can be inspired of like structure and documentation. I would also recommend to have a look at minify. It combines, minifies, removes comments etc with multiple css files. The good thing is that you can work a lot with comments within the file, minify then removes this on the fly and makes a cached copy of the file. It also have a bunch of other great stuff in it.

Here’s an example of my css and the minified copy

http://jedisthlm.com/wp-content/themes/jedisthlmV/screen.css
http://jedisthlm.com/minify.php?files=/wp-content/themes/jedisthlmV/screen.css

http://code.google.com/p/minify/
http://code.google.com/p/blueprintcss/

]]> By: madr http://friendlybit.com/css/documenting-css/#comment-30359 madr Wed, 27 Feb 2008 23:11:34 +0000 http://friendlybit.com/css/documenting-css/#comment-30359 Great list! I have been n a similar situation about documenting JavaScript. This list can be applied to that one too. Another thing worth menioning is CSStidy, which can clean up and sort CSS when development is done. It can be a toll to keep CSS consistent. (fyi: I read this article and wrote this comment on lynx, since I doing som server confs at the moment. Works just fine.) Great list! I have been n a similar situation about documenting JavaScript. This list can be applied to that one too.
Another thing worth menioning is CSStidy, which can clean up and sort CSS when development is done. It can be a toll to keep CSS consistent.

(fyi: I read this article and wrote this comment on lynx, since I doing som server confs at the moment. Works just fine.)

]]>