Related
What's the name for the CSS style / best-practice that WordPress uses?
I ask because, with PHP, we have Pear style, GNU style, K&R, etc... Is there any keyword or name for the css style used by WP?
Is there a nomenclature for css formatting conventions at all?
ie:
.this,
.and-this {
display: none;
}
rather than:
.this,.and-this{display: none;}
Drupal has CSS formatting guidelines as well. But, I'm unable to find any resource except maybe this one which gives titles to different css formatting conventions in any way.
There is no special CSS that WordPress uses: it just employs regular old CSS like any other site. That page you linked to is showing preferred syntax conventions. I just skimmed through the page and the examples of CSS syntax that they don't like were marked incorrect ... even though most would actually function just fine from what I can tell. A little misleading.
Regarding your two snippets above: those will have the same results (though in the second one you need a space after the comma: .this, .and-this{display: none;}). The first snippet referred to as human-friendly or human-readable, with extra whitespace and line breaks to make it easier for people to read and write. The second is simply minified for faster processing by computers, which removes whitespacing and line breaks.
It should be noted that this principle of minification from your example really only applies when scaled up to hundreds/thousands of lines of code and doesn't make much of a difference with less than that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know CSS and I'm learning more and more common pattern. However, I always feel like I'm hacking instead of doing it the right way.
For instance, some people I respect tell me that using css reset is unnecessary while others live for it. Also, there are so many great css framework (for grids, etc.) that even thought I understand them, I never really know when to use them.
So, basically, my question is: Once you understand how CSS work, is there a recognized "best" approach used by excellent web developer? As in python, one should try to use the common pattern and read PEP 8. Or, in C++, after understanding the syntax, reading the effective serie by Meyer is an excellent "second" read.
Sorry for taking that long to explain.. I just didn't want to have answer like: Read "Beginning CSS" which explain how to change the background or how to set font. I'm really looking for a good standard approach.
Should we use reset?
Should we use only one file per site? One for homepage and one for the rest? One basic file and once different for every big sections?
Is it bad to have a 2k+ css files? Does it mean it should have been refactored and that it contain to much duplicate?
Should I define parent at the top for normal font, color, h1, etc., and then, when it's different change it per sections.. or instead always use the standard one and redefine each and every section.
Should I use .class and #id a little bit everywhere, or should I try to minimize them and instead use long descriptor such as:
.content .main tr td span a
or
span.classname a
Thank you!
tl/dr:
What's the best "second" read once you already understand CSS but would like to use it in a clean/professional way?
[EDIT]
Thanks all for your answer. I know I asked quite a lot of questions.. but they were only examples for the real question which is: What is the best "second" read once you already understand CSS but would like to use it in a clean/professional way. I.e., I was hoping to read a book explaining the examples I proposed.. but also would explain lots of other things that aren't css-syntax but more css-best-professional-use.
People will have a range of answers for these questions, but here are the approaches I would take:
Resetting
If you're working on a fragile layout -- one that could easily break if a few pixels aren't where you expect them to be -- consider using a reset. I would look into normalize.css. Instead of completely overwriting browser defaults, it smooths out the differences between browsers.
You could also consider resetting specific elements if you find yourself adding a lot of margin: 0; to your stylesheets.
Splitting up CSS documents
Google recommends splitting them up so that individual pages aren't forcing users to download lots and lots of stylesheet rules that aren't actually used on the page that they're visiting.
Yahoo recommends combining files to minimize the number of HTTP requestion
Obviously, finding a balance is important, and this SO question weighs some of the pros and cons.
Classes and IDs or long chains of selectors?
I try to keep classes and IDs to a minimum (in both my HTML and my CSS). They tend to be more fragile when you're building pages that others will update with WYSIWYG editors. I add a few IDs or classes to large blocks of the page, then use CSS to target specific elements within those blocks. This is easier if you avoid deep nesting in your HTML as much as possible.
Working with a CSS preprocessor such as LESS or SASS can help you write more readable stylesheets. The ability to nest style rules in both LESS and SASS has helped me avoid a lot of specificity-related issues.
Still, specificity is a good CSS topic to be familiar with:
CSS-tricks has a good article covering specificity
The W3C's own documentation is worth reading.
Additional Resources
As far as additional reading is concerned...
SitePoint's collection of articles and tutorials on CSS is a great resource for more advanced CSS tutorials, and they also feature some good articles covering CSS issues that are more advanced than what you'd find in many beginner-level books.
Resets: I think yes, some dislike them, so it's up to you to figure out which one you like
Split vs. Unified files: Depends. There are advantages to both (chorus: advantages, advantages!) One CSS file is easier to browse, and you can clearly find relationships in a single file. Then again, if you have planned the structure of your site, are developing compartmentalized widgets, or have lots of people working on the CSS committing files, a decentralized method might benefit you. With multiple CSS files, you can always use a compressor to serve them to the client as a single file, so it's more of a maintenence question.
Large Files / Line Count: Are you saying you have 2,000 CSS files (holy crap!) or 2,000 line CSS files? Both aren't great, although the latter can be managed quite easily in an IDE that provides outlines and handles inheritance for you.The former...well, at least you have job security.
Parent Definitions: Again, no right answer. The CSS rules for a small site will vary greatly from an enterprise level site. A good starting point might be checking out how jQueryUI handles styles and then forming your own opinion from there.
Correct Selectors: Steve Souders talked about optimizing CSS selectors, coming to the conclusion that's it not worth it for your average site. So ignoring CSS optimization and based on your example, I'd say the second one is waaaay easier to maintain and ultimately far more predictable. If you HTML changes even slightly, the first one will break quickly. The second won't, and is far more portable.
There are things you can do in CSS to make your life easier. I highly recommend using a grid system for layout (blueprint, 960GS, etc). I personally like using a reset since it makes pixel perfect designs easier to manage. Other than that, research what people like Eric Meyers or site likes alistapart.com or smashingmagazine.com have to say on the topic.
tl;dr - there is no right answer, but definitely some good options
I can answer your questions based on my own experience, not necessarily the best practices out there.
I reset certain tags, but not all the tags like the "CSS purists" do. Keep in mind that if you are using certain CSS libraries, like JQuery UI, Superfish menu, etc.. resetting the tags can really mess up these libraries UIs.
I usually have one general layout/configuration CSS file and every complicated page has its own CSS file. So, every page includes these 2 CSS files plus my UI library files (JQuery UI, etc). This makes it easier for me to pin point and maintain it.
2K+?? Yes, very bad in fact. If you have file that big, you should really use YSlow to see how long it takes to load that file. The longer you page takes to load, the faster you users leave your webpage, unless they are forced to use it. :D
I always like to "scope" my CSS, by prefixing with say #app. This ensures my global setting only affects my page content and layout, and they do not override the UI libraries.
Use .class and #id in whatever way it makes sense to you. If you know this tag exists only one time, then use #id. If you know it might occur more than one time in the page, then the only option is to use .class.
As with many things there aren't really rights and wrongs, it's more about prefernce and manageability.
I use CSS Reset on some elements, I prefer the blank canvas start instead of finding a load of unknown defaults.
I don't think file size is really an issue, again what is easiest to manage is really more important. Split the file if it logical to do so.
Give some thought to optimisation and try to avoid unnecessary duplication. I like to define a parent font/styles as you call it for the most commonly used style, then just define the others as required.
Personally I like to define some common classes, i'm not sure if it's optimal but it's very usable, such as:
.bold {font-weight: bold}
.clear {clear: both}
.red {color: red}
If you do this for common requirements you can then simply use code like
<p class="bold red"></p>
<h2 class="red"></h2>
<br class="clear" />
Simples!
Use tabs. Makes it easier to see. Also i rather use .classname than #id. Example of a piece of css of one of my websites:
body {
font-family: Arial,Helvetica,sans-serif;
font-size: 11px;
background-color: #99D9EA;
}
.lcategorie {
background-image: url('http://images.alphenweer.nl/i/gradient-menu-left.png');
background-repeat: no-repeat;
padding-left: 2px;
text-align: left;
color: #FFFF00;
font-weight:bold;
width:200px;
height:20px;
display:block;
cursor:pointer;
}
.rcategorie {
background-image: url('http://images.alphenweer.nl/i/gradient-menu-right.png');
background-repeat: no-repeat;
padding-right: 2px;
text-align: right;
font-weight:bold;
color: #FFFF00;
width:200px;
height:20px;
display:block;
cursor:pointer
}
In addition to the good answers above, what you just described in your question is also otherwise called as Learning Curve.
We all go through it. It is inevitable, according to me.
The best approach probably is to make the best use of the vast resources available and then filter them out. Which is a knack developed only over time.
I don't think there are shortcuts. Although, I do agree, it would be nice to have a guiding hand to help us avoid pitfalls and time-wasters and tell us about all the best-practices.
But even those are available out there thanks to some really passionate, expert-in-their-field bloggers.
So explore-away is what I'd suggest.
If your lucky enough to have a Mac or a Hackintosh... then I highly recommend CSSEDIT (unfortunately only available on Macs). It will allow you to rapidly develop your understanding of CSS. I realize this doesn't answer your question, but if you try it, you'll understand why it is so important to the learning curve. Sadly, nothing else on windows comes close. I use windows 99% of the time and switch to my mac for CSSEDIT.
For example
input{margin:0}body{margin:0;background:white}
would be shorter written like this
input,body{margin:0}body{background:white}
or this
input,body{margin:0}body{margin:0;padding:0}
would be shorter written like this
input,body{margin:0}body{padding:0}
Conclusion no such tool See the accepted answer.
A tip to the tool writers, you may want to consider gzip. Sometimes, leaving a few bytes on a second-rate optimization will be shorter in the end because gzip is essentially byte-level deduplication. If there are two identical sections, gzip will reference the earlier one. Ideally this would be considered in deciding if certain optimizations should be skipped some or all of the time, and what the order of the selectors and rules should be.
This can be done using CSSO.
Consider the following input:
input{margin:0}body{margin:0;background:white}
CSSO output:
input,body{margin:0}body{background:#fff}
(exactly what you are looking for)
But unfortunately, CSSO optimize this:
.dont-care {
background-image: url("images/chart.png");
background-repeat: no-repeat;
}
To:
.dont-care{background-image:url("images/chart.png");background-repeat:no-repeat}
However, CSSTidy converts the above to the corresponding shorthand property:
.dont-care {
background:url("images/chart.png") no-repeat;
}
Seven Four steps solution for optimizing CSS:
Here is the practice I follow:
Merge CSS files in all.css.
Supply to CSSO input.
Hit Minimize
Paste the output in all.min.css
Except paying #Grillz to get it done manually, I haven't found a better deal for CSS optimization thus far..
But what about old IE hacks?
If you are using CSS hacks for IE6 and 7, CSSO will preserve the hacks.
For example:
.dont-care {
background-image: url("images/chart.png");
*background-image: url("images/chart.jpg");
background-repeat: no-repeat;
}
CSSO output:
.dont-care{background-image:url("images/chart.png");*background-image:url("images/chart.jpg");background-repeat:no-repeat}
CSSTidy will ignore asterik(* hack used for IE6), and output:
.dont-care {
background:url("images/chart.jpg") no-repeat;
}
You can also avoid hacks and use separate CSS file for older IE versions (say all.oldIE.css). After optimizing (using 7 steps described earlier) both files separately, this is what you may use in the <head> tag of your HTML/masterpage/template/layout file eventually:
<!--[if lt IE 8]><link href="css/all.oldIE.min.css" rel="stylesheet" type="text/css"/><![endif]-->
<!--[if gt IE 7]><!--><link href="css/all.min.css" rel="stylesheet" type="text/css"/><!--<![endif]-->
where all.min.css would work for all browsers except IE versions less than and equal to 7. But using CSSO alone is a safe bet.
Update
Skip the CSSTidy part. CSSO does safe optimization. According to their developer, shorthand optimization is not safe:
Consider that example:
.a{
background-attachment: fixed;
}
.b {
background-image: url("images/chart.png");
background-repeat: no-repeat;
}
and if you'd have <div class="a b"></div> — an element with both
classes, you can't optimize the .b as you write, 'cause it would
override the background-attachment set in .a.
So, no, that's not a safe optimization.
Take a look at CSS Tidy, it can do some merging: http://csstidy.sourceforge.net/
If you use visual studio, you could install the Web Essentials extension. It has
experimental support for cleaning and merging CSS rules, but not exactly like you subscribed.
It, for one, creates more whitespace, but it does combine css tags, that have (partially) equal styles eg..
try LESS.
LESS will automatically recognizes when you save your *.less file and immediately compiles your CSS-Code and will minified. You can create as many files as you want and LESS will observe them all to trigger compilation.
You will only work in the .less files. the Tool will auto compile and save you files as .css
http://lesscss.org/
I would recommend
https://www.npmjs.com/package/gulp-clean-css
if you don't have problems using gulp
it's doing exactly as you want
May be the wrong thing, but http://www.cleancss.com/?
No, there is no such tool which optimizes to the level you ask (that I'm aware of at least), and I'm not sure you'd want to use it if there was. The reason is that it's not a trivial problem to find the smallest possible minified css code. For the trivial CSS you provided, it's easy. But imagine doing that on a 300kb block of CSS. It's not trivial. And is it worth wasting the CPU time generating it (it might be if you're caching the results, but it won't be if you're serving it dynamically)?
And what's the gain? Saving a few percent at most on the transfer? Unless you have facebook level traffic, you're not going to save much bandwidth. And a few percent isn't going to impact your users much either (even over dial-up, transferring a few kb isn't that bad).
Just use a standard compressor (minify, YUI Compressor, etc) and be done with it. Instead, worry about the low hanging fruit. The easy to fix problems...
Yes, there is. The YUI Compressor does this for you. I was wrong, the YUI Compressor is only a minifier, but indeed very useful. What and how they minify is presented here.
This is a .jar package that you'll have to download and then run through the terminal, if you're on Unix or Linux (I don't know about Windows, so someone fill this gap!), with the following syntax:
$ java -jar /path/to/yuicompressor-x.y.z.jar myfile.css -o myfile-min.css
The -o option declares what file you wish to write your minified content to.
have you tried less.js ?
you can write css code in an object oriented manner, also you can use this framework either on client side or server side, below a demonstration on your case:
/* you can write you desired css as follows */
body {
&input {
margin: 0;
}
background:white;
}
and it will be automatically compiled into:
body, input {
margin:0;
}
body {
background:white;
}
Ther are several out there. Some of the best ones are;
http://refresh-sf.com/yui/
http://www.minifycss.com/css-compressor/
The second one groups rules that match together also and more.
CSSO is little bit outdated, ACCSS is a port CSSO to but fixes open issues of the original code.
https://github.com/acwtools/accss
and it also has a better compression ratio
I wonder can I say that LESS/SASS CSS "pre-processors(I think they are called?)" is the opposite from optimizations like minification? I wonder if there will be any noticeable performance impact? or do you think easy of development is more important?
I ask this because what LESS CSS generates is something like
body #div1 #div2 p
body #div1 #div2 p a:link, body #div1 #div2 p a:visited
...
and I think it can really bloat up my CSS quite a bit. as you can see, such specificity is not required and it makes reading CSS hard (at least what I see in firebug).
In Sass you can control 'specificity bloat' by understanding how nesting works. You don't have to do any nesting at all if you don't want - it's something you can control.
Using the new #extend directive, you can actually reduce redundancy in your CSS by applying the priciples of OOCSS and can thus improve performance. Here's a good article to get you started with #extend. And a few more OOCSS resources:
http://www.stubbornella.org/content/category/general/geek/css/oocss-css-geek-general/
http://wiki.github.com/stubbornella/oocss/faq
http://oocss.org/
The great advantage of #extend in Sass is that it takes the manual effort involved in applying OOCSS and makes it wonderfully painless and easy.
Finally, as Andrea pointed out, Sass has a variety of options for minifying CSS (see the :compressed style), so overall you've actually got a pretty potent toolkit for not only improving your performance as a developer, but also improving the performance of your CSS. For an example of this in action, see how Chris Eppstein, author of Compass and core contributor of Sass, refactors the Digg stylesheet down from 125 lines of code to 85 lines of code (a 32% reduction).
You'd be surprised, but gzipped CSS files that have repeated blocks of code shouldn't be too much larger than ones with the shorter selectors.
This is thanks to how the compression algorithm handles duplicate strings in a file. Instead of including the same string twice, it replaces the second occurrence with a reference to the first one, and so that string only appears in the compressed file once. Take a look at how repetitive the selectors in your generated CSS file are - this should make them compress fairly well.
Naturally, the key to this is making sure your CSS files are gzipped - leaving them uncompressed will definitely increase the file size.
Depending on the options, SASS can give output in different styles. For production, you will want to set the output style to 'compact'.
There is a firebug addon for sass that should make things easier to read. You don't really need to read the output directly anyway.
Sass, less and xCSS will generate more output but I wouldn't call it bloat.
Hand written CSS, with it's many redundancies and duplications will degrade quickly as developers pile name spaces on top of others during the life cycle of the code. One of the symptoms of poorly maintained, designed or written software is bloat. And because CSS has some design deficiencies from the start, even the best CSS coders are effected by this limitation.
So you got to weigh up the initial footprint of your well formatted sass/less file against a hand written CSS file that has been edited a few times over.
Another benefit on sass is that your HTML becomes leaner. You don't need to append class names throughout your code to make up for the flat, global structure of CSS.
I've just been assigned the task to refactor a huge 5000 line CSS file... but here's the worst part - I also need to make it IE6 compatible. Any CSS gurus have suggestions of tools, or possibly tips (common pitfalls) for use in my monolithic expedition? Cheers.
checkout sass... it includes the ability to convert css to sass.
http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html
A sass file is a yaml file that can be parsed down into a css file. It allows you to use variables and alternate organization...
sass example:
!main_color = #00ff00
#main
:color = !main_color
:p
:background-color = !main_color
:color #000000
css output:
#main {
color: #00ff00; }
#main p {
background-color: #00ff00;
color: #000000; }
Some tips:
Use version control so you can roll back when needed.
Come up with a checklist of visual tests to run through after each change, in each browser. A spreadsheet of URL links and things to look for, building on them as you run across problems (think "unit tests" but not automated).
Use a CSS-specific beautifier first to get everything into the format you prefer for braces, etc.
Consider using something like SASS to "compile" your CSS as you go along.
Comment the heck out of things, especially where you're doing IE6-specific stuff.
Future-proof yourself by building a separate file with IE6-specific directives as you go along, or at least use Microsoft's way of filtering them out for other browsers.
Use the W3C Validation often.
Mechanically, I would attack it like this:
<link type="text/css" href="newhotness.css" />
<link type="text/css" href="newhotness-ie6.css" />
<link type="text/css" href="oldandbusted.css" />
Move code from the third (old) file into the other two, cleaning up as you go. That way you can validate your code without worrying about tons of errors in the old stuff, and you can track your progress, Ctrl-Tab between them more easily than between locations in a single file, etc.
(If you can't control the markup to add your CSS files, use an #import at the top of the old file.)
Start from scratch!
Assuming you can check all the major pages manually, I would be VERY tempted to wipe the entire file and start from scratch. Spot-checking for IE6 inconsistencies, you'll be doing nearly the same amount of work anyway, but it will be much, much more painful if you're modifying old, browser-specific CSS.
That 5000 lines may well be expressable in 2000 lines of modern, well-designed CSS. I think most experienced CSS developers would find it less work to write 2k lines of new CSS than modify 5k lines of horrible CSS.
http://www.codebeautifier.com/
which is based on this:
http://csstidy.sourceforge.net/
Not necessarily CSS, but here's worflow tip: use GIT.
start off by importing the files in git;
commit for every minor step, and record what you did;
whenever you find that you broke something, you can identify the exact same step broke using git bisect ( a good description );
For extra kicks, here's a talk about code coverage for CSS to help you quickly weed out unused rules.
As Triptych said, I would start from scratch. Also, consider the following:
use a CSS reset file to smooth out cross-browser inconsistencies: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
get it working perfectly in Firefox, then tweak for other browsers as needed
study the underlying HTML. How is it organized? Is it laid out with tables? all DIVs? Semantic tagging?
is the CSS used for layout or simply styling (fonts, colors, etc.)?
Once you get a feel for that, study the content. Categorize the layout and elements as much as possible, so that you identify all the common elements and can maximize the efficiency of your CSS
remember the C in CSS, Make the most commonly used font the body font, so that other elements will inherit it by default.
use relative units (ems) for font size, to allow proper scaling of text
try not to use ANY inline styles
make use of Firebug - it will let you inspect an element and see exactly what CSS is in effect and where the rules came from
don't be afraid to re-use portions of the old CSS, especially for things like dropdown menus, which can need very specific incantations to work properly
have fun! starting from scratch lets you implement best practices and learn a ton along the way. When you are done you are probably going to look back on this as a good experience.
there is a presentation here that should get you in the right headspace for tackling this task: CSS Systems
I would be tempted into creating a test suite first: automating page visits (perhaps with Selenium?), taking screenshots, then using something like ImageMagick to compare those with reference images.
Also, I second all the suggestions to use source control. If you later discover that your refactorings broke something that wasn't checked by the test suite, you can add a new test and then bisect your history to find the change that broke it. Git is good for that.
Get a code editor with good syntax highlighting. Also, goodluck I dont envy you.
My initial thought was does some like NCover exist for CSS, as it would be handy to see if all of the CSS is referenced. A quick Google on CSS code coverage found a few things- you might want to look yourself though: http://development.lombardi.com/?p=436
Install sass, run css2sass on your 5000 lines of css, proceed. After you are done with your sass file refactoring, run sass2css to regenerate the css file. Best of luck!
I'd suggest Stylizer - it is a CSS editor with an embedded live preview browser. It makes life much easier when editing CSS files and can tell you which rules affect which element on the page and more.
All of you guys saying he should start from scratch are wrong. You shouldn't. Try to identify the different parts the site uses. Put them on a sheet of paper. Find the parts that match together. Build a structure. Find parts of the application that are the same but are still styled with different rules.
Take that one part and name it. Then match all app parts that use that "pattern" with the correct HTML/CSS.
Repeat until you're done. Break up the large task in small chunks.
Identify whether the original CSS writer used standard methods like using a CSS reset. If he didn't, and everything is defined by #id without reusable classes, well, then maybe the guys saying you should start from scratch are in fact right. But my point here is that you can't just recommend that without assessing the situation.
Using the Dust-Me Selectors Firefox Plugin can be handy. It's a bit like a code coverage tool for CSS.
Tool suggestion: ReSharper by JetBrains. It will autocomplete CSS and rename selectors site wide from the CSS file editing window.