Code Guide by @mdo (Updated) (mdo.github.io)
almost 6 years ago from Dafydd Evans
almost 6 years ago from Dafydd Evans
I like all of this except I'm a fan of single-line CSS rules, such as:
.code-block { width: 100px; height: 100px; background: #ffffff; }
Am I the only one?
I like that too if it's short (2/3 elements with short names).
But when you start getting background-image: bla blh blah; Then it gets really long and is hard to read.
I'll be honest, I really hate them. Obviously they're easy enough if you write them yourself and/or know the code well, but I feel it impacts code legibility too much, plus I don't see any benefit from them.
Actually, what benefit do you see from them? Maybe I'm just not appreciating their brevity.
It condenses the stylesheet vertically. I'm rarely looking for something without knowing the class name. If I need to add something to an element in the DOM, I just inspect the element and CTRL+F for it. If it doesn't exist, I look for the CSS for elements around it and add it there.
Basically, I need to see the selectors moreso than I actually need to see the styling being applied.
The reason so many people dislike this is because of versioning. Writing css with the single line method is really tough when working with teams or other developers.
via http://www.theparticlelab.com/single-line-vs-multi-line-css-plus-textmate-tips/
Yep, exactly. It can get really messy.
Ahh, I see. Interesting point. The teams I've been a part of haven't really had issues with this, but I see the validity.
The single line is reserved for when you only have one css declaration, such as:
.code-block { background: #fff; } or .something-else { width: 100%; }
On 1 line, it's hard to read/edit them. At least for me.
I'm going to adapt this for my startup because at some point we will have more front-end people (or just me, forever).
I have a few quibbles with this guide though. For one, I write all my CSS properties in alphabetical order so they are easy to find in the future. For properties that tend to go together (in my head), I put them first like:
width: 100%; height: auto;
margin: 0; padding: 0;
top: 0; left: 0;
background-color: #fcfcfc
I also don't like the idea of placing prefixed properties before everything. If anything, they should go last.
I add a new line at the beginning and end of files. (:
Alphabetical order is certainly the easiest to make as policy, there's no room for misinterpretation.
However I prefer his model, as it puts related properties together such as for size, i.e., width, height, padding.
You say you prefer alphabetical order, yet your example is what Mark recommends. I think your example is the ideal as everyone should know the box-model. Padding should be on the same line as width and height, as it relates to size, not positioning like margin.
The downside of this method is that it's not as easy to make policy for. That isn't important if you are the sole maintainer, but if you have several team members modifying your CSS, guidelines are useful.
I see the validity in alphabetical, and grouping by type, but I prefer to order my properties by line lenght, ex:
.poop { top: 0; left: 0; width: 100%; font-size: 1em; color: #89512E; position: absolute; }
It keeps the file looking really clean and organized, and if you don't mind properties not being grouped by type, which I don't, then the order ends up being just as random as if you ordered them alphabetically, or completely randomly.
I wrote a little bit about it here: http://mattsoria.com/blog/2-of-web-developers-order-css-like-me
Ah, I skimmed some parts.
I tend to group CSS properties like you too, eg: top: 0; left: 0;
. It makes sense to me.
I also don't like the idea of placing prefixed properties before everything. If anything, they should go last.
Not sure what you mean by that. They'd go last in my declarations if they were to do with styling, but the vendor prefixed property should always get declared before the non-prefixed property.
eg:
.header__title { display: block; -webkit-box-shadow: 0 1px 3px rgba(0,0,0,0.25); -moz-box-shadow: 0 1px 3px rgba(0,0,0,0.25); -ms-box-shadow: 0 1px 3px rgba(0,0,0,0.25); -o-box-shadow: 0 1px 3px rgba(0,0,0,0.25); box-shadow: 0 1px 3px rgba(0,0,0,0.25); }
Prefixes are a hack, so we want to cascade to the standard property if it's available.
Just curious: is two-space indentation the overall standard? I’ve seen people fiercely defend both four “spaces” and two “spaces” as universally better…
I don’t think it matters, but if there is a technical/non-anecdotal reason for one over the other, let us know!
I've always preferred a tab size of 4 spaces, but I think it's largely just personal preference. With something like CSS, it gets minified anyway, so I'd rather be able to read it easily while I'm coding.
It's personal preference. I think a lot of the crew at GitHub are Ruby guys and Ruby is a 2-space language. The only thing that really matters is that the team you're working on is consistent because you'll give your version control repository a good working if everyone is doing something different.
My team uses Python, so all of our files, HTML, CSS, etc. use 4-space soft-tabs, as that is the Python standard.
Same for us, we tried 2 spaces on a whole PHP project and found it to be far more difficult to gauge integration levels when quickly scanning files. It didn't suit at all.
I suppose it's all what you're used to though.
Designer News
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
Have feedback?
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now