I hope this question isn't too weird and arbitrary. When I'm viewing some CSS using Firebug, I've noticed that the CSS properties for each tag are in alphabetical order.
Is it trying to tell us something?
Apart from the obvious benefit of being able to find the property you're after more quickly, I was wondering this: Is it quicker for a browser to apply the properties if they are in alphabetical order in the original stylesheet?
For example is this...
body {
background: #222;
color: #DDD;
font-size: 0.85em;
}
#content {
background: #444;
padding: 1em;
}
p {
border-bottom: 0.9em;
line-height: 1.2em;
text-align: justify;
}
...better than this...?
body {
font-size: 0.85em;
background: #222;
color: #DDD;
}
#content {
padding: 1em;
background: #444;
}
p {
text-align: justify;
line-height: 1.2em;
border-bottom: 0.9em;
}
Can this be tested effectively?
This would obviously be replicated throughout the entire stylesheet so would a browser benefit from doing things in order and, if so, would it be worth revisiting past stylesheets to reorder things?
-- edit --
Ok, a slight alteration to my question: What if the attributes are always in the same order for each tag. Background always before border always before color etc and so on (I know I've missed some!) for each and every tag. Alphabetical would aid you in keeping things in order rather than being the optimal method.
Looks like the overwhelming consensus is that it matters not, however!
There's definitely no speed benefit in ordering your styles alphabetically.
If you want real speed benefits, you should minify your CSS.
There are so many programs to do that, but here's one of them: CSSTidy. This program also has the option to put your styles in alphabetical order (if you want that for your benefit).
I don't think order of statements affects speed in any way, however, the efficiency of the statements can affect performance. (Slightly tangential, I guess...)
See: http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
The performance benefit is for visual parsing only - FireBug will re-arrange your style attributes into alphabetical order when you inspect an element, which I find much quicker to locate a style attribute.
Firebug do it so that developers can search for an attribute value easily, and if you want speed benefit, write your css judiciously, which includes mainly avoiding repetition and redundancy and being DRY
Also when a page loads and CSS is parsed and layout is rendered once, next time its not done again, so stay calm, and try to make it more maintainable instead
Writing CSS in an alphabetical order just makes one thing easy: finding your attribute. It has nothing to do with speed.
To Increase speed, you can use shorthands rather than using separate attributes. Things like border-color, border-width, border-style can be used in a single attribute called border.
Related
In Bootstrap tutorials, when people create their own Sass variables in a custom style.scss, I see lots of them using trailing !important.
If you want to see an example of what I mean, start at 13:45 here:
https://www.youtube.com/watch?v=MDSkqQft92o&time_continue=24&app=desktop
.navbar {
width: 100%;
background none !important;
#media(max-width: 34em) {
background: black !important;
}
}
But then other code in the .scss file doesn't use !important. No explanation of why that is.
Anyone have some suggestions?
!important means that the style preceding it will be "forced" onto the element, despite what other styles may set on it. For example:
.element {
font-weight: bold;
}
.custom-class {
font-weight: normal !important;
}
If you have an <span class="custom-class element"></span>, it will be displaying a font-weight normal, not bold.
! important guarantees (or at least it tries) that the rule you're trying to apply is more important than others. So it overwrites other rules that might interfere with the new one. ! important is not necessary if the rules are ordered correctly because the last rules prevail over previous ones. ! important must be avoided as much as possible. Use it only if it's really necessary.
I use the 2 ways but I prefer the first due to reuse code. some prefer one or other. But I would like to know if the load in big stylized pages is better in one way than the other.
1)
<style>
.red{ color:red}
.right25{ margin-right: 25px}
.bold{ font-weight:bold}
</style>
<p class="red right25 bold">this is a red text, bold and right margin 25px</p>
2)
<style>
.class1{ color:red; margin-right: 25px; font-weight:bold}
</style>
<p class="class1">this is a red text, bold and right margin 25px</p>
That depends on how much of the code that you can actually reuse, but the performance difference won't be that big.
The biggest difference between the approaches is what the classes mean. Generally you should have classes that represent what you are trying to show, not exactly what styles you use to show it. Names that represent the intent rather than the implementation fares better when you make changes.
For example if you have the class right25 and want to change the margins to 20 pixels instead, then you either will have a class name that doesn't represent what it actually does, or you have to change it to right20 everywhere that you use it.
Two is your answer. The browser reads each class from right to left. Reading one class is faster than reading two classes.
http://csswizardry.com/2011/09/writing-efficient-css-selectors/
http://css-tricks.com/efficiently-rendering-css/
Use the external stlye sheet. The browser can cache that.
http://www.w3schools.com/css/css_howto.asp
You're absolutely talking about the first method that could be slower than the second method?
To answer: There's no difference in speed of styling css.
To illustrate:
div{
color: blue;
padding: 10px;
}
div{
color: red;
font-size: 16px;
padding-left: 5px;
}
When css is applied over the rule, the following css will be applied by the browser:
div{
color: red;/*later one*/
font-size: 16px;
padding: 10px 10px 10px 5px;/*padding-left 5px is taken from later rule*/
}
And which is parsed by the browser at the same time when the div gets styled from the stylesheet.
Why there's no difference?
In any other programming language like JavaScript if one line gets error then another line doesn't run and so from that line of code the interpreter won't go to read the whole code.
But in css language there's no problem even if you write rules whether html has no such classes or id, there's no problem reading next line of code even if you have some mistakes in your stylesheet, whatsoever the browser will load entire stylesheet file and read the code and gives the output in same time (when stylesheet is fully loaded) and both of your code doesn't seem to be any difference in the speed.
By the way, it could be slower (that even you can't catch with your eyes) where there is slower internet connection below 32kbps because of stylesheet downloaded the line by line of code.
Which CSS authoring technique do rendering engines process more efficiently:
1) repeating the same style property/value pair in multiple selectors, or
2) grouping shared style properties in a single selector
Example 1: Duplicate font-size, but less rules
p {
font-size: 1em;
color: #000;
}
h1 {
font-size: 1em;
color: #fff;
}
or Example 2: More rules but one font-size
p, h1 {
font-size: 1em;
}
p {
color: #000;
}
h1 {
color: #fff;
}
This study by Dave Gregory is the best source I've found on this topic. It shows that duplicating property/value pairs is much worse for performance:
"Long" is what Gregory refers to as the "bloated" format where properties are repeated in multiple selectors.
for performance is better the second option, see this google advice, but take care of using declarations in just one place, you could finish with something like this, this is the problem with extend in css preprocessor like sass and stylus. However your first option could be more modular and makes your css modules more independent and reusable in other sites, you can then make use of a css minifier to group every declaration.
Organizing your css is really up to you and the number of elements you have.
If you are looking for optimization you should instead focus on useless whitespaces and duplicates.
Tools exist to merge the duplicates and minimize your code (here and here for example)
You may also read this article which is a bit old but still valuable I think.
When I first started writing CSS, I was writing it in an expanded form
div.class {
margin: 10px 5px 3px;
border: 1px solid #333;
font-weight: bold;
}
.class .subclass {
text-align:right;
}
but now I find myself writing css like this: (Example from code I'm actually writing now)
.object1 {}
.scrollButton{width:44px;height:135px;}
.scrollButton img {padding:51px 0 0 23px;}
.object2 {width:165px;height:94px;margin:15px 0 0 23px;padding:15px 0 0 10px;background:#fff;}
.featuredObject .symbol{line-height:30px; padding-top:6px;}
.featuredObject .value {width:90px;}
.featuredObject .valueChange {padding:5px 0 0 0;}
.featuredObject img {position:absolute;margin:32px 0 0 107px;}
and I'm beginning to worry because a lot of the time I see the first form done in examples online, while I find the second form a lot easier for me to work with. It has a lower vertical height, so I can see all the classes at a glance with less scrolling, the tabulation of the hierarchy seems more apparent, and it looks more like code I'd write with javascript or html. Is this a valid way of doing code, or to keep with standards when putting it online should I use the vertical form instead?
Well, here is what say the most :)
summary:
css-tricks.com ran a poll. By a margin of roughly 3 to 1, most people preferred multi-line over single line css styles.
I personally prefer the first style. I like things that are easy to read and I don't mind scrolling. The dense nature of the second style slows down my reading, my ability to pick out the items that I'm interested in.
There certainly are trade offs to be considered with CSS due to the file size. CSS can be compressed. I find the size of CSS files to be the least of my worries with the sites I've built so far.
Ultimately, the important thing is that whichever style you choose to use is to be consistent. That consistency will make your life simpler when you have to update your CSS or when another developer has to update your CSS.
Indicating the hierarchy using indentation is not a bad idea. However, you should be careful that you don't fool yourself. In your example, you may be assuming that .scrollButton is always within .object1. But CSS doesn't obey that rule. If you used a .scrollButton class outside of .object1, it would still get the styles.
I dont know about you but I like the vertical mode during dev as it is far more easier to read for me.
However, in prod, you wanna compress your css to reduce payload and hence, the second style makes sense. Mostly, you would be using some CSS compressor to do this.
i like to write css in multi line. because this is easier to write and read. we can find error as early as possible and a look of view is nice with indentation . mostly when a designer work with css and gave to developer to develop site than developer can understand easily.
so i think multi line css is better way to work.
I personally find both of your examples hard to read, especially the second one.
Multi-line is easier to follow, and indentation can be misleading as CSS is not necessarily applied in that way. Your indentation may lead you to believe it is.
I prefer the basic tried and true method of multi-line, with reasonable/logical order:
div.class
{
margin: 10px 5px 3px;
border: 1px solid #333;
font-weight: bold;
}
.class
{
text-align: center;
margin-left: 10px;
}
.class .subclass
{
text-align:right;
}
Takes up a little more space and requires a little scrolling to take in, but is easy to follow. Those worried about optimization can always use CSS shrinking tools for production CSS files.
In the end as long as you are very consistent with your work and across a team (if applicable) then no answer is more correct.
I prefer the second style, but be aware that it's a style. In the same way that some people prefer
function (arg)
{
body();
}
to
function(arg){
body();
}
I don't get it, myself. The argument is "it's easier to read", and my response is consistently "... for you". As a note, I get the feeling that this is why so many examples use the more-whitespace version; it has the reputation (if not confirmed property) of being easier to read.
Pick the one you like and stick with it. If you have a team to cooperate with, try to get to consensus, or barring that, write some auto-formatting scripts and stay out of each other's way. It's not like it's terribly difficult to mechanically transform one into the other.
The style you write in is your choice(I prefer multi line) but as Rajat said you want to remove any extra whitespace after dev. Anytime you can reduce file size and payload you are doing your site and your visitors a favor.
I think it also depends on your editor. I use multi line formatting and condense every definition with Vim's folding (I set up folding marks to be { and }) so I get one tag/class/id per line, expandable when needed.
Using comments to identify "sections" I get a very clean look with minimal vertical scroll while maintaining the readability of multi line on expanded definitions.
I just want to point out that Textmate has an option that allows you to easily switch between these two styles by selecting an area and pressing Ctrl-Q/Ctrl-Alt-Q to expand/collapse. As a consequence I have come to find that I prefer my CSS collapsed unless I am writing or deep debugging a specific section. But, with the ability to easily switch between he two I see that both ways are useful for different circumstances.
I prefer multiline right up until we deploy. At that point I want it minified.
Perhaps, when you have multiple selectors and one rule, like this:
#header li a, #header li span {
display:inline-block;
}
So, I prefer to do:
#header li a,
#header li span {
display:inline-block;
}
I've always liked this style:
#something1 {
color : #ffffff;
background : #000000;
}
#something2 {
color : #000000;
background : #ffffff;
}
But yo answer your question: As long as it functions the same way, there is no "proper" or "best" way to format your code. Use a style your comfortable with.
Usually when I build a site, I put all the CSS into one file, and all the properties that relate to a set of elements are defined at once. Like this:
#myElement {
color: #fff;
background-color: #000;
padding: 10px;
border: 1px solid #ccc;
font-size: 14pt;
}
.myClass {
font-size: 12pt;
padding: 5px;
color: #ee3;
}
I've been considering splitting up my definitions into a number of different files (colours.css, layout.css, fonts.css ...) as I have seen recommended. Something like this:
/* colours.css */
#myElement {
color: #fff;
background-color: #000;
border-color: #ccc;
}
.myClass {
color: #ee3;
}
/* layout.css */
#myElement {
padding: 10px;
border: 1px solid;
}
.myClass {
padding: 5px;
}
/* fonts.css */
#myElement {
font-size: 14pt;
}
.myClass {
font-size: 12pt;
}
To reduce HTTP requests, I'd be combining the files and stripping whitespace prior to rollout, so that's not an issue, but my question is: does having all those selectors repeated over and over cause any performance issues in browsers?
Alternatively, are there any tools which avoid this (potential) issue by merging definitions from different files? ie: take the input given in my second example (3 different files), and combine them into one file, like the first example.
The browser will have to find all the definitions and then add them up and override the different properties based on the latest definition. So there will be a slight overhead.
That being said it would be rather minimal and not very noticeable even on hardware 5 years old. The browsers are quite efficient at it these days.
I can't comment on performance, but I tried this approach on my website and ended up reverting to one large file.
My reasons:
I got tired of creating a rule for div.foo in three or four different files, and opening three or four files if I wanted to change that div.
Sometimes it's not as easy as it should be to separate functions. To center a div in IE, you may have to center the text of the parent element, even though that's not the standard way. Now my layout is mixed in with my fonts.
As the code grows, the easiest way for me to find things is to do a text search for the element I want. But I have to open several files to see all the rules, and maybe that element doesn't have a rule in this file so I get no matches.
So I went back to having main.css and iehacks.css. And breathed a sigh of relief.
As William said, you're not going to see any issue from the browsers parsing the CSS. What you might see, though, is an issue with the number of HTTP requests that a client can open to a single host. Typically this defaults to two. So, if you do put your CSS in multiple files, you might want to put them on a separate sub-domain and they will be treated as a different host which will allow the HTML page to be loaded at the same time as your CSS files.
There shouldn't be any noticeable difference in rendering/parsing speed. As everyone else said, computers are fast enough that they can render CSS pretty quick.
Your problem is really going to be with the number of requests required to load the page. Extra web requests increase overhead when loading a page. It is much faster to load one large file than it is to load several smaller files. It has an impact on both the client (browser) and the server serving up all of those CSS files.
As long as you combine your files in production, you should be fine.
Yahoo's YUI Compressor is a pretty good tool for compressing your CSS files into smaller files. The last time I checked, it can't definitions (at least the last time I looked at it) but there shouldn't be enough of a performance hit to really need to.