81–90 of 122 posts
Use tables for layout instead of CSS. Then your CSS will be more concise (essentially reduced to a theme) and less confusing (because CSS layout properties like float and position tend to cause the most confusion). Edit: Rephrased to try and better express the idea.
Don't overcomplicate things: - Have only one CSS-file, unless your project is huge . - Never use IDs - Avoid reset CSS (espescially if you can ignore IE6/7 - If you think you need variables (like in SASS), you are probably thinking about it the wrong way - Give classes functional names, not presentational - Linebreaks after declaration. (Makes your CSS-file easier to navigate) - Remember that you can use you media qu…
Never use IDs? Why? i'm open to this if you have a good argument but i use IDs for unique elements only.
Also, if you just resolve to always use classes instead of ids, then you can eliminate the cognitive overhead that comes with every new selector of, "Should this be a class or an id?".
Use tables for layout instead of CSS. Then your CSS will be more concise (essentially reduced to a theme) and less confusing (because CSS layout properties like float and position tend to cause the most confusion). Edit: Rephrased to try and better express the idea.
joke?
I also had trouble phrasing the idea in a way that didn't sound stupid.
Order is: * Reset (only for early IE )-http://developer.yahoo.com/yui/reset/ I find myself using it less and less
* Global Styles - HTML tags - global font faces
* Clearfix - http://www.webtoolkit.info/css-clearfix.html
* Skeleton/Structural Styles - grids/divs/columns
* Headers/footers/persistent styles
* Page specific styles and IDs
* Conditionally load IE Styles if they're required
* load javascript plugin css with the plugin's preferred dir if possible
As for pipelining them, I usually just use a gzipped connection and still serve them individually, since internal image paths for backgrounds rely on the CSS path. CSS caches very nicely, so take advantage of it on the HTTP side.
example: http://code.google.com/p/streeme/source/browse/trunk/web/css...
Earlier quoted context omitted.
Never use IDs? Why? i'm open to this if you have a good argument but i use IDs for unique elements only.
The problem is that as a site grows, it's common for things that were once unique to become multiple. Also, if you just resolve to always use classes instead of ids, then you can eliminate the cognitive overhead that comes with every new selector of, "Should this be a class or an id?".
I do agree on the cognitive load though.
Don't overcomplicate things: - Have only one CSS-file, unless your project is huge . - Never use IDs - Avoid reset CSS (espescially if you can ignore IE6/7 - If you think you need variables (like in SASS), you are probably thinking about it the wrong way - Give classes functional names, not presentational - Linebreaks after declaration. (Makes your CSS-file easier to navigate) - Remember that you can use you media qu…
Never use IDs? Why? i'm open to this if you have a good argument but i use IDs for unique elements only.
A selected with one ID will outweigh a selector with two classes for instance. This can quickly lead to complexity because you need to use a ID many places in order to override a selector that used ID.
A class only used once serves the same purpose as ID (CSS-wise), expect that you avoid a lot of problems.
I might use IDs for anchor purposes (site.com/foo#section), but I never reference it in my CSS.
First the global styles, then different things like Header, Navigation, Main Content, Right-hand-side-doodad, Widgets, Footer, etc.
Then create a Table of contents at the top and give each section a unique identifier, FEDCBA-Head, FEDCBA-Nav, etc. Go down to each group and put in a comment saying "Start of Navigation CSS ".
Now you can look in the table of contents and do a quick file search on the unique identifier, and be taken right to the CSS you're looking for.
I generally make the table of contents a lot more detailed, and it has an upkeep cost, but it's well worth it when the CSS file gets big.
Don't overcomplicate things: - Have only one CSS-file, unless your project is huge . - Never use IDs - Avoid reset CSS (espescially if you can ignore IE6/7 - If you think you need variables (like in SASS), you are probably thinking about it the wrong way - Give classes functional names, not presentational - Linebreaks after declaration. (Makes your CSS-file easier to navigate) - Remember that you can use you media qu…
I've yet to see CSS code for page layout without the usual awkwardness where margin-left of some element MUST equal some other element's width minus some bar's left offset, yadayada. It's for stuff like this that variables make sense. I wholeheartedly agree that if you need a variable to colour two bars and a heading orange, you're probably doing it wrong.
The blog you refer to only has an example with colours, which is just too easy.
Earlier quoted context omitted.
The problem with absolutely unique elements is that, in a complex enough website (that evolves over time), they often end up not being unique after all. I agree about IDs for JavaScript though.
"I agree about IDs for JavaScript though." Would you mind elaborating on the JavaScript point? Is it for convenience with document.getElementById or something? Using jQuery, I tend to prefer class selectors the same as in my CSS.
Don't overcomplicate things: - Have only one CSS-file, unless your project is huge . - Never use IDs - Avoid reset CSS (espescially if you can ignore IE6/7 - If you think you need variables (like in SASS), you are probably thinking about it the wrong way - Give classes functional names, not presentational - Linebreaks after declaration. (Makes your CSS-file easier to navigate) - Remember that you can use you media qu…
CSS complexity is increasing at a huge rate and the volume of CSS for even a simple site is running at hundreds of lines. Splitting it into separate files keeps it readable and reusable.