Which renders faster?
// Just HTML
<div id="holder">
<div style="float:left;">test1</div>
<div style="float:left;">test2</div>
<div style="float:left;">test3</div>
</div>
OR
// CSS
#holder div{
float:left;
}
// HTML
<div id="holder">
<div>test1</div>
<div>test2</div>
<div>test3</div>
</div>
In terms of actually displaying content, the speed differences between the two sections of code is negligible. Different browsers most likely have different implementations for rendering a webpage so the minute speed boost you get with one browser won't necessarily be reflected in another.
Now in terms of load times, it's a different story. Yes, inline styles are technically faster than an external stylesheet because you are making one less request on top of the page but using an external stylesheet is much preferred for code maintainability. It's only when you're loading multiple stylesheets that performance starts to become an issue since each time you refer to an new stylesheet the browser must submit another request. The solution? Simply concatenate stylesheets together into one.
I would imagine (due to the HTTP-Request involved) that external CSS would be slower but inline styles are horrific for maintainability and negates the whole point of CSS which is to centralise values for colour and layout so you don't have to iterate through every element to change a style.
Also see this
Even if you assume that you don't want to use an external stylesheet, using a style tag in the <head> with classes on the elements will make an automatic inclusion easy later with a server-side programming language, rather than having dozens of inline styles. Unless you have a trivial numbers of styles, your total bytecount will be lower as well.
Check out Google's new 404 page: they even have the images in the style tag:
http://www.google.com/123412312
In terms of browsing there shouldn’t be any difference you can test this with browsers' developer tools. Apart from code maintainability already mentioned in other answers, there is also the issue of specificity of inline rules. Since they have the highest specificity (1,0,0,0) they would override all other cascades. So you should carefully examine your use case rather than making the decision based on performance criteria
Related
I have a page that has 20 elements just like:
<div style="border:1px solid #000; cursor:pointer; font-size:20px; line-height:30px;">Hello</div>
What would be the benefits to do this below:
<style>
.custom_style{border:1px solid #000; cursor:pointer; font-size:20px; line-height:30px;}
</style>
<div class="custom_style">Hello</div>
<div class="custom_style">Hello</div>
<div class="custom_style">Hello</div>
...
Visually it's the same and, since I am not loading any external CSS file with the class custom_style, I am wondering how these 2 codes perform.
If it was a JS code I would be plenty of alternatives to check the efficiency of the code, but since this is pure HTML/CSS how can I check that? And if instead of 20 elements I had 200?
EDIT
I thank you all for the help but maybe I was not clear on my question. I dont wanna know the pros/cons of inline styling. I would like to measure performance, rendering performance. Which one would render faster? And by how much? Sorry if I made you lose your time. Despite that, all answer so far are pretty clear and should be considered by people thiking about using inline/class styles.
DRY (Don't Repeat Yourself) Code
Say, if you want to change a value, font-size: 24px, you might do n number of times than doing once in CSS. Plus the size of the code is smaller too.
Cascading / Overriding
I wouldn't talk about putting the CSS in a separate file, but definitely, inline styles are frowned upon, as inline styles cannot be overridden other than using !important.
Presentation / Content Separation
You should really separate the both.
Inline vs Class (Selectors)
Selectors is the natural consequence of sharable style rules, however
they came to CSS together with a complex selectors specificity
concept.
Style rules defined inline can not be reused between many nodes. They
need to be defined and parsed over and over, even if they are exactly
the same.
Application of inline styles to every element from JavaScript has a
reasonable overhead in the library layer responsible for that.
Inline Styles are still good, when you need to animate specific
properties of a specific element.
Inline Styles implement only a subset of CSS. They don’t have media
queries, keyframes, pseudo selectors etc.
My professor asked us to develop a website using pure HTML,
JUST HTML. And it's really hard to design without CSS but I have to follow her instructions.
Anyway, my question is do you consider this code as CSS even if I removed the type="text/css"?
<style>
a {color:white; }
</style>
This maybe a dumb question but thanks for your time to answer it, I just really want to use CSS to make it easier.
Could you suggest anything that would make my coding easier? I just don't want to have repetitive code.
You are having this snippet,
a {
color:white;
}
is an element selector with the color property, whatever you write, i.e, between <style> tag, or style attribute, or stylesheet, all are CSS, if your professor is vintage fan, and is asking you to assign the color to a than you can use the font tag with color attribute with a value of white
<font color="white">Hello</font>
Demo
Note: Please read the box on the Mozilla Developer Network which says
SO DON'T USE IT
And just incase your professor understands, and his mind comes back to 2014... than would like to point out that even using
a {
color: white;
}
will target all the a elements in your document, so make sure you use a class or a specific selector to select particular a element.
Anyway, my question is do you consider this code as CSS even if I removed the type="text/css"?
CSS is CSS, not matter how it is added to the document or labeled.
it's really hard to design without CSS but I have to follow her instructions.
Could you suggest anything that would make my coding easier?
I'd start by clarifying if CSS really is forbidden and, if it is, what the purpose of forbidding it is. I can think of a number of possible reasons:
To prepare you to deal with code written by someone from 1996
To make you focus on the structure and semantics instead of the appearance
The course you are taking is almost two decades out of date
How you deal with the problem depends on which of those is the reason.
If it is the first one, then you need to look at all the obsolete, deprecated (and possibly non-standard too) presentational features of HTML (like <font> and background attributes).
If it is the second one, you just don't worry about how it looks and deal with the structure and the semantics. Let the browser's default stylesheet control the way it looks.
If it is the third one, then you probably have little option but to grit your teeth and bare it or find a better course.
<style>
a {color:white; }
</style>
Yes you write type="text/css" or not it will be considered as css.
The content of a style element is CSS, for most practical purposes (it would hardly make sense to use anything else there, since no other style sheet language is supported by browsers). The attribute type="text/css" does not change this, because the de facto default style sheet language is CSS.
On the other hand, the style element, including its content, is HTML. The content is not defined in HTML but in other specifications. Similar considerations apply to style attributes, as in <a style="color: white">...</a>: the attributes are HTML, and but they contain embedded CSS.
When you are told to use “pure HTML, JUST HTML”, then you are probably expected to refrain from using CSS or JavaScript in any way. On the other hand, you are probably allowed to use images, even though images are not HTML but are used via external references or data: URLs. There is nothing particularly logical in such a requirement.
As suggested in other answers, simply do not try to control the rendering of the page. Worry about the rendering only if it becomes intolerably messy and there is a reasonable way to prevent that in “pure HTML”. For example, don’t try to set link colors (this would in fact be an improvement over the way most web pages deal with links), backgrounds, fonts, etc. But if you use e.g. a data table, consider using , which often makes a table essentially more readable.
Yes, you can:
and too you can put style inline in your body or header
<style>
a{
color: #ffffff;
}
</style>
and so, all your css you can write it in your native .html without use of another .css file
Often times I see something like this:
<body>
<div class="container">
</div>
</body>
Why not just do:
<body class="container">
</body>
You are perfectly free to do any of the following:
add a class or id attribute to the body element;
directly apply CSS to the body element, with or without class or id attributes; or
directly apply CSS to the html element, although without the class or id attributes and with some important caveats.
Any of these are perfectly legitimate uses of CSS and HTML.
Why <div id="container"/>? Through the years, many CSS techniques have employed arbitrary container elements for conceptual simplicity, to avoid certain cross-browser inconsistencies or because they were simply too complex to be achieved otherwise. A couple of more subtle reasons include that in older browsers, one could not apply CSS to the html element directly, and there were (and are) certain unusual or restricted properties for those elements—often for obvious reasons. (They were sometimes described as being "magic" for this reason.)
These all conspired to create a situation where to achieve almost any moderately complex layout, it was inevitably much easier to just start out with a squeaky-clean container element. Though the practice started as a means to an end it soon became just part of the scenery, and now many developers don't think twice about adding that sprinkling of extra markup.
No, there is nothing that says you can't add a class to the body.
Attaching a class to the body is actually quite common in various CMSes and is very handy for theming or styling specific pages.
From looking at your example, if you just want to use the body as a container, why even bother with the class? There should only be one body element, so just call that in your selector.
Walter, it may make sense if you needed to apply a slightly different subset of styling to a page with a custom body tag.
Using a wrapping div is usually for some presentational reason and make not make sense semantically; if you don't need it for your project, don't use it. Sometimes only using the body tag to contain the page is too inflexible for some layouts, and as Jordan says some old browsers cannot apply CSS to the root element.
In creating CSS styles one approach seems to be a fully qualified style such as
#pnlImage div.ipd-imageInfo div.ipd-tags span.ipd-tag
compared to a shorter definition such as
div.ipd-tags span.ipd-tag
which would uniquely identify the style as well. However, if the site is expanded or changed the 2nd style runs the risk of not uniquely identifying the element.
Is there a performance hit from fully qualifying a style, i.e., it is longer? Are there some guidelines/best practice references for style naming?
Thanks
Google (not a search, actually them) seems to think that it does cause a performance hit.
Also, the Mozilla foundation has an article "Writing Efficient CSS for use in the Mozilla UI" that outlines the possible performance pitfalls of CSS selectors in their browser(s), and how to optimize your style rules for their rendering engine. Their article has tons of examples of what's good and what's bad. Please keep in mind this is only relevant to their browsers, though.
There are also some benchmarks publicly available, about CSS selectors affect on rendering speeds:
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
http://blog.archive.jpsykes.com/153/more-css-performance-testing-pt-3/
I, however, think this is, for the most part, horse manure. You can effect FAR greater change on your page's loading/rendering speed by using some other simple optimizations. I believe that your sanity, and a well-organized code base should come first. If this were as big of a deal as some make it out to be, we'd all be back using HTML < 4 attributes (bgcolor=, border=, etc) to style our web pages.
Looking up an #id is fast.
Looking up a tag is a bit slower.
Looking up a .class is the slowest.
Starting your selectors with a faster lookup will reduce the number of lookups required for then next part. That is, if I wrote p.myClass, then the browser can very quickly find all the p tags and then it only has to loop through those to check for the class name.
That said, it would rate the maintainability of your CSS file higher than its rendering speed. Blah blah blah premature optimisation blah blah.
You might be interested in David Baron (Mozilla)'s Google Tech talk.
I have a site where another designer used heavily qualified styles and maintenance is a nightmare. (the qualified styles are only one part of that)
Basically, you can't touch or simplify the html structure without it breaking half the styles, and the styles often don't cascade properly to new content additions. If you add new css you in turn have to qualify your new rules heavily or half of them end up overridden by some existing rule because it contains so much specificity.
So from a maintenance standpoint it's not efficient. Also not efficient from a typing standpoint either.
I don't see how a theoretical answer is possible: the answer is implementation-dependent; so I suggest you profile it to be sure.
Is there a performance hit from fully qualifying a style, i.e., it is longer?
Yes, on every dynamic change of the DOM-tree, the CSS-expression has to be rematched against at least some nodes. I doubt this will lead to any noticeable delay, though.
Your stated objective (making the selectors robust against changes to the page structure) is not quite solid: hardcoding intricate details about the site structure into the CSS will just mean that you'll have more statements to maintain and update when the page structure changes.
If it's under your control, stick with simple classes (even if you have more of them) and as few levels as possible (doing some relative sizing of fonts is the only use case where I have used several levels, and even this was somewhat superfluous). It just wastes too cognitive capacity to keep track of the page structure in your head.
Although your question is about the performance, (and I would suggest, measure it..) I would really like to add that you should always try to use the shortest definition possible to identity the correct elements.
The reason is not the file size, but the ability to extend your site without altering the main css.
For example you've got this part in your html site:
<div id="Header">
<h1>Css example</h1>
<h2>Welcome to the css example site</h2>
<p>An example page by davy</p>
</div>
and this is the css:
#Header
{
background-color: #ffeedd;
padding: 1em;
}
#Heading h1
{
font-size: 3em;
color: #333;
}
#Heading h2
{
font-size: 1.5em;
color: #666;
}
#Heading p
{
margin: 0 0.5em 1.5em 1em;
font-size: 1.1em;
color: #999;
}
And later on you'd get to a page where you'd like your header to have a different background.
Had you chosen to use div#Header in you main css file, you'd either have to change the html (which depending on your system might mean creating a different template/masterpage) to add an extra class, or create a more qualified css selector such as body div#Header.
Using the shortest selector you could still use div#Header { background : ... } to change your header. You can either create an extra css file and load that into your header on that page (if allowed) or add a style definition directly to your <head> section. The nice thing about this is your css file does not grow with selectors for each different page, and you can keep clear of classitis.
You could also use it to switch the sizing method of your page (static/fluid) so that one template/masterpage uses the default css, and the other derives from that template/masterpage and just links a css called FluidWitdth90.css to change the template to 90% width fluid layout.
Are .css files always needed? Or may I have a .css "basic" file and define other style items inside the HTML page?
Does padding, borders and so on always have to be defined in a .css file that is stored separately, or may I embed then into an HTML page?
It is technically possible to use inline CSS formatting exclusively and have no external stylesheet. You can also embed the stylesheet within the HTML document. The best practice in web design is to separate out the CSS into a separate stylesheet. The reason for this is that the CSS stylesheet exists for the purpose of defining the presentation style of the document. The HTML file exists to define the structure and content of the document. And perhaps you may have JavaScript files which exist to add additional behavior to the document.
Keeping the presentation, markup, and behavior separate creates a cleaner design.
From a practical perspective, if you have a single external CSS stylesheet the browser can cache it. If multiple pages on your site have the same look and feel, they can use the same external stylesheet which only needs to be downloaded once by the web browser. This will make your network bandwidth bills lower as well as creating a faster end user experience.
You can include CSS inside an HTML page. It goes within the <style> tag, which goes within the <head> tag:
<head>
<style type="text/css">
body{ background-color: blue; }
</style>
</head>
Note, however, that it is best practice to use .css files.
Putting rules into the HTML page gives them greater "specificity," and therefore priority, over external rules. If several CSS rules conflict, ID wins over class, and inline styles win over ID.
<head>
<style type="text/css">
span.reminder {color: blue;}
span#themostimportant {color: red;}
</style>
</head>
<body>
<span class="reminder" id="themostimportant">
This text will be red.
</span>
<span class="reminder" id="themostimportant" style="color: green;">
This text will be green.
</span>
</body>
You can define CSS at three levels, externally, embedded in the document (inside a <style> tag), or inline on the element.
Depending on your needs, you might use all three, as a rule of thumb external sheets are good for overall styles as you can apply them globally. If you have specific cases that you must handle you can then use the other levels.
You can do either. However, by shifting your CSS out to a separate file, it can be cached. This reduces the amount of data that you need to transmit for each page, cutting down on bandwidth costs, and increasing speed.
You don't have to keep your CSS in an external file, no. What you're asking about is "inline" css: including style directives directly within the page itself via <style> blocks.
There are times where that may makes sense, in moderation, but in general it's not the way you want to go. Keep your CSS isolated in an external stylesheet makes it much easier to maintain both your HTML and your styling, especially as a project scales and changes hands.
One big advantage of having CSS in an external file is that one rule can apply to many different pages. Here is a contrast of three CSS approaches:
Inline Styles - to change the color to blue, you have to find each place that the red style exists - maybe on many pages.
<span style="color: red;">This is a warning.</span>
Page Styles - this allows you to label what something is - in this case, a warning - rather than what it looks like. You could change all the "warnings" on the page to instead have a yellow background by changing one line of code at the top of the page.
<head>
<style type="text/css">
.warning {color: red;}
</style>
<body>
<span class="warning">This is a warning.</span*>
External File - same code as above, but the fact that the style info is in a separate file means that you can use the "warning" class on many pages.
You can use anywhere, css files are not a requirement. using css files however is recommended as it makes the site easier to maintain and change in the future
Have to? No. You can do it however you prefer.
Generally it's better stype to keep your CSS out of your html whenever possible though.
That's what i usually do.
At least at the begining. When a page design gets close to final, I move most things to the 'main' style.css
I prefer to keep styling in CSS as it separates view from presentation, allowing me to swap between presentations fairly easily. Plus it keeps all the information in one place instead of split between two places.
Css can improve performance, because they are cached from browser, and pages are smaller!
Use an external file for all styles that are used sitewide, document stylesheet for styles that are only used on that page and use inline styles when the style only affects that single element.
External stylesheets do not always lower bandwidth. If you put every style for every page in your site into one giant css file, your users incur a large initial download even if they only visit your homepage once ever.
Thoughtful division of your styles into a main.css with the most common styles and then into additional stylesheets as users drill down deeper can help to make the downloads smaller for some paths through the site.