I may have found a way to format CSS3 Gradients that doesn’t make my eyes bleed. Yippee!
I was talking to @glan the other day about CSS3 gradients. We were discussing how to break them down into understandable layers and the difficulties when things you need to know about may be split across multiple properties. At the same time, I was checking out these cool CSS Coding Standards shared by @csswizardry, and I started wondering if formatting the code for CSS gradients could make them easier to understand.
I grabbed one of Lea Verou’s CSS3 gradient patterns as a starting point. They are insane and amazing and mind blowing. If you haven’t checked them out, you totally should. Anyway, I grabbed the code from the arrows example to try out different formatting options.
Option A – One line per property value pair
Let’s start off with the standard one line per property value pair.
.arrows {
background: linear-gradient(45deg, #92baac 45px, transparent 45px), linear-gradient(45deg, #92baac 45px, transparent 45px)64px 64px, linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px), linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px,#92baac 68px,#92baac 113px,transparent 113px,transparent 158px,#92baac 158px);
background-color:#e1ebbd;
background-size: 128px 128px;
}Ok, awful, right?
Option B – Line return for each gradient
Let’s try adding a line return for each linear gradient.
.arrows {
background:
linear-gradient(45deg, #92baac 45px, transparent 45px),
linear-gradient(45deg, #92baac 45px, transparent 45px)64px 64px,
linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px),
linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px,#92baac 68px,#92baac 113px,transparent 113px,transparent 158px,#92baac 158px);
background-color:#e1ebbd;
background-size: 128px 128px;
}
Option C – Tab per value
The last example was better, but I could kind of see a pattern in it, so next, I tried formatting it like a table with tabs to separate the columns.
.arrows {
background:
linear-gradient(45deg, #92baac 45px, transparent 45px),
linear-gradient(45deg, #92baac 45px, transparent 45px) 64px 64px,
linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px),
linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px, #92baac 68px, #92baac 113px, transparent 113px, transparent 158px, #92baac 158px);
background-color: #e1ebbd;
background-size: 128px 128px;
}
I wanted to like this option, I really did, but you have things lining up that aren’t the same kind of values and that feels weird.
Option D – Line return per color stop
So next, I thought I’d try adding a line return at every comma (thus every color stop).
.arrows {
background:
linear-gradient(
45deg,
#92baac 45px,
transparent 45px
),
linear-gradient(
45deg,
#92baac 45px,
transparent 45px
) 64px 64px,
linear-gradient(
225deg,
transparent 46px,
#e1ebbd 46px,
#e1ebbd 91px,
transparent 91px
),
linear-gradient(
-45deg,
#92baac 23px,
transparent 23px,
transparent 68px,
#92baac 68px,
#92baac 113px,
transparent 113px,
transparent 158px,
#92baac 158px
);
background-color:#e1ebbd;
background-size: 128px 128px;
}Usually I write in a quite compressed style, but I find myself preferring to look at Option D.
What do you think? Would you vote for A, B, C, or D? Do you have a different way of formatting that works well for you?
UPDATE: Don’t forget to add a pre tag around your example code if you include it in the comments.
Comments
30 responses to “Code formatting for CSS Gradients”
I vote for B, either way the syntax isn’t intuitive at all, but since I use that format for multiple backgrounds, it makes sense to me.
@Natalia Ventre – Can you give an example of multiple backgrounds and how you format it?
I have to admit after looking at it Option D makes the best sense. Option B would cover most gradient examples that weren’t too complex, as its easy to follow the pattern. Option C feels like overkill and way to high on the maintenance upkeep scale to be worth while. But Option D seems to be as close to the multi-line CSS that I write.
I always try to avoid lines longer than 80 characters when writing codes,
so option D is for me, or write it with my own style
.arrows { background: linear-gradient(45deg, #92baac 45px, transparent 45px), linear-gradient(45deg, #92baac 45px, transparent 45px)64px 64px, linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px), linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px, #92baac 68px, #92baac 113px, transparent 113px, transparent 158px, #92baac 158px); background-color: #e1ebbd; background-size: 128px 128px; }@LouCypher – So you wrap at 80 chars back to the nearest comma?
I’ve been fond of the compressed CSS style, but it turns out that long lines of CSS are harder to diff, so I’ve switched back to one property per line.
I think option D is best for readability and for version control, but that’s just me.
@Murry Nuttall – Indeed, so frustrating that CSS is such a simple language yet diff tools make a muck of it unless there are a bunch of extra line returns. Odd for a whitespace meaningless language.
I use D. For the examples, look at CSS Code http://www.standardista.com/cssgradients/. I like to separate out each color stop.
I would do a combo of b and d
each gradient would be on its own line but indented under the background
.arrows { background: linear-gradient(45deg, #92baac 45px, transparent 45px), linear-gradient(45deg, #92baac 45px, transparent 45px) 64px 64px, linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px), linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px, #92baac 68px, #92baac 113px, transparent 113px, transparent 158px, #92baac 158px); background-color:#e1ebbd; background-size: 128px 128px; }sorry formatting didnt seem to want to go in at all on that one…
@Ben – It accepts some HTML, did you wrap a pre around it? I can try adding that now. Let me know if it looks right.
that is what I meant to do, thank you.
I use D. I think it’s more readable.
Option B
I do it like @Ben, each gradient on a seperate line with indenting.
I tend to do them like I do chaining or multiple declarations in JavaScript, e.g.
.arrows { background:linear-gradient(45deg, #92baac 45px, transparent 45px), linear-gradient(45deg, #92baac 45px, transparent 45px) 64px 64px, linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px), linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px, #92baac 68px, #92baac 113px, transparent 113px, transparent 158px, #92baac 158px); background-color:#e1ebbd; background-size:128px 128px; }Um, ok. Formatting the code using pre didn’t go as expected. 😉
Here is what I meant to do: http://labs.palleman.nu/code/Code-formatting-for-CSS-Gradients.txt
I prefer C
D is good too, more JSON notation / programmer friendly.
But I look as CSS as CSS , so prefer C
Just recently I hopped on the 78 chars-per-line train, so I’d vote for D.
But frankly, I do CSS gradients at the moment only via Sass, and I seem to foster different coding styles there than in my pure CSS code, when it comes to CSS3-y properties.
B for me. It is compact and still visually dissectible.
I prefer E: None of the Above.
.arrows {
background: url(“/imgs/arrow_repeating_bg.png”) repeat scroll 0 0 transparent;
}
Anything else for this example is over-complicated and showboating. 🙂
@Nicole, yes.
Oh, I also use two spaces for indentations instead of tab characters.
Option B looks like what’s on the CSS3 patterns page for examples.
I like option D, but knowing myself, I’d end up writing B more often.
Option D seems clearer and more readable. But the management of gradients “by hand” is not obvious anyway.
I’m only just beginning with my CSS/3/OOCSS training so I am not familiar with gradients yet,
but looking at the code and applying my unpolished logical thinking skills, I make the assumption
that they are defined in pairs of values, so I’d keep them two at each line. Ending up with something
like this, as I don’t care much for using a new line for each closing parentheses inside of the classes
when it comes to CSS.
/*-----------------------------------------------------------------------------------------------------------------------------------------------*/ .arrows3 { background: linear-gradient(45deg, #92baac 45px, transparent 45px), linear-gradient(45deg, #92baac 45px, transparent 45px)64px 64px, linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px), linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px, #92baac 68px, #92baac 113px, transparent 113px, transparent 158px, #92baac 158px); background-color: #e1ebbd; background-size: 128px 128px; } Or if I would be more concerned about width than vertical space, perhaps I'd go maaaad with linebreaks.. .arrows3 { background: linear-gradient(45deg, #92baac 45px, transparent 45px), linear-gradient(45deg, #92baac 45px, transparent 45px) 64px 64px, linear-gradient(225deg, transparent 46px, #e1ebbd 46px, #e1ebbd 91px, transparent 91px), linear-gradient(-45deg, #92baac 23px, transparent 23px, transparent 68px, #92baac 68px, #92baac 113px, transparent 113px, transparent 158px, #92baac 158px); background-color: #e1ebbd; background-size: 128px 128px; }Right.. if you would please remove my earlier comment, the pre tag does not seem to work 🙂
I’m only just beginning with my CSS/3/OOCSS training so I am not familiar with gradients yet,
but looking at the code and applying my unpolished logical thinking skills, I make the assumption
that they are defined in pairs of values, so I’d keep them two at each line. Ending up with something
like this, as I don’t care much for using a new line for each closing parentheses inside of the classes
when it comes to CSS.
http://pastebin.com/Asedg4sf
I definitely prefer B, and would even remove the indentation so everything is flush-left. During the CSS optimization phase of a recent major project, I was surprised how many kilobytes of code we dropped in getting rid of the tabs which our IDE encoded as spaces. Beauty is nice in code, but for the user-agent, unnecessary white-space is just one more burden. B is an acceptable compromise.
I’d go for B, but formatted like Ben did it. (Indenting the values to make it more clear which property it belongs to.)
I’m a “D” man myself, I like the structure, clean code that I can eat off of….nothing like gradients for breakfast!!
No “all in one line” properties except if its just one property, scrolling is easier than scanning side to side looking through properties for myself but to each their own.