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.
Related
When I add bootstrap on my html link it changes some of my css code.
Pre-bootstrap:
After-bootstrap:
Bootstrap link:
Css code changed:
#bannerRodap{
background-color: black;
position: fixed;
width: 100%;
height:80px;
top: 88%;
}
#bannerRodap p{
position: relative;
top: 25%;
color: white;
text-align: center;
font-family: 'Helvetica',sans-serif;
font-size:0.8em;
}
And besides that, bootstrap also added this little blue thing under my flex-box container.
Yes the CSS change you experience is bound to happen, it is one of the typical disadvantages of using Bootstrap. Like the name itself suggests the framework "Bootstrap" makes its complete CSS available to your entire project. Real problem is the immense code the bootstrap.css contains even though the programmer doesn't even need most of it(more than 3000 lines). I have taken a very small snippet from the file(bootstrap.css) to explain:
a {
color: #337ab7;
text-decoration: none;
}
a:hover,
a:focus {
color: #23527c;
text-decoration: underline;
}
This means all the anchor tag(<a>) in your project would have the color #337ab7 by default UNLESS you override this style to what you need in your own stylesheet. The real problem arises when you see other elements in your project changing its behaviour according to the bootstrap CSS but you really didn't want them to - In this case you need to override the styles coming from bootstrap.css just say in a way to cancel out the bootstrap styles you need to write your own unnecessary styles to make it look normal.
That's the reason when you ask most of the experienced UI devs about bootstrap they would just go ... ** yuck **
Your own stylesheet starts to get really messy.
HTML gets messy especially when you start using the grid structure of bootstrap
Huge unwanted code(from BS CSS/JS) lies in your project even though you will never ever need all of them.
Even the order of the stylesheets included hardly makes any difference. In your case use the Dev Inspector to see whats causing the blue thing(probably a shadow from boostrap) to appear & remove that by overriding the styles in your own stylesheet(in this case, your stylesheet should be included after the bootstrap.css)
Imo, bootstrap should be used mostly by those who need bootstrap to do everything about the look & feel of their project with very little customisation to do on their own. If you have heavy customisation of your own then might as well write you own CSS from the scratch without including BS.
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.
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.
I'm hoping this is simple. I'm not a CSS guy.
I'm trying to make some code look a little better on a blog and I have the following <code> CSS style.
code {
display: block;
white-space:normal;
background-color: #eeeeee;
font: 1em, 'Courier New', Courier, Fixed;
padding: 7px;
margin: 7px 7px 7px 7px;
}
This is working fine for me, except where there are line breaks in the code contained in my <code> tag, the background color is white not light gray.
Is there a CSS tweak I can make to force my entire <code> block have a background color of gray?
Thanks.
Comment: If I put a space on the empty line, I get what I want - a gray background on that line.
Comment2: I have only plain text inside of my <code> </code> tags. Ideally I don't want to mark up my code w/ tags. Just cut and paste inside of the <code> tags and have it look decent.
Final Comment: After reading this as suggested by mercator below, I finally went with this. I subclassed the <pre> tag and got want I needed. A nicely shaded boxes to offset my example code blocks.
pre.code {
color: black;
border: solid 1px #eeeeee;
font-size: 1.1 em;
margin: 7px;
padding: 7px;
background: #eeeeee
}
It appears to work fine for me, but then I don't know what the contents of your <code> tags are.
There's a few oddities in your CSS in any case:
I probably wouldn't use display: block, but wrap the tags in a <p> or <pre> instead. Changing it to a block like that still won't allow you to nest block-level tags inside it, and it would still need to be inside a block-level tag itself. CSS doesn't change the HTML syntax and semantics. Do you have any block-level tags within your code tags?
Why did you set white-space: normal? That's a little unusual for a code block. How exactly are you formatting your code? Are you adding <p> or <br> tags in there? Why don't you use white-space: pre, or perhaps white-space: pre-wrap?
Your font declaration is broken. There shouldn't be a comma between the 1em and the font names. Browsers would now simply parse that as if 1em is the name of a font family, I think, and then fall back on Courier New, since 1em doesn't exist.
I think you meant to say monospace instead of Fixed. Or is Fixed the actual name of a font face? You'd better add the generic monospace anyway.
More of a nitpick: you can collapse those 4 margins down to one value too.
I'm not sure if any of these are really the cause of your problems. The first two are the most likely candidates. Nothing strange happened on the quick tests I did, but some of your other CSS might be creating the problems in combination with some of these points.
Ah, wait a minute... I see now that you're talking about making "some code look a little better on a blog". The blog software is automatically adding paragraph tags around blocks of text separated by blank lines. Those are responsible for the white.
I suppose that's also why you added white-space: normal. The blog software is already adding line breaks and everything automatically (with <p> and <br> tags), so using pre added a whole bunch of extra space.
Try using the <pre><code> tags combination like StackOverflow does. Using the <pre> tag will probably (hopefully) prevent the blog software from messing with your code.
For WordPress, have a look at their article "Writing Code in Your Posts."
Try setting an explicit width. Not sure why that would work. I sometimes add a border while testing to see where my box is and what it looks like. I know you can do that with web debuggers like firebug, sometimes it's simpler and might even have side effects.
add:
width: 100%;
border: 1px solid #eee;
See if that helps, maybe change the border color to #000 to see where the boundaries are.
Without some HTML and/or a test page, it's quite difficult to know what could be causing the problem. I would look at the line-height property though - it often causes these kind of problems.
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.