Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
this is my first post so excuse me if I'm doing anything wrong. My question is how should I layout my CSS files? Just curious to see if there's a "right way" CSS should be written. Thanks!
Understanding how browsers parse CSS and render websites is an important first step towards writing more efficient code.
There are four kinds of key selectors: ID, class, tag, and universal. It is that same order in how efficient they are.
#main-navigation { } /* ID (Fastest) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (Slowest) */
#content [title='home'] /* Universal */
You can refer below articles to write more efficient CSS
Efficiently rendering css
Writing efficient css selectors
You can indent your css. Or minimize it at the end of the project.
You can use plenty of websites that can help you to do it.
That's an example - CleanCSS
CSS should be laid out by specificity.
IDs are more specific than classes which are more specific than tags. Therefore you would want general tag styles at the top of your sheet and then classes and the IDs.
p { }
.p { }
#p { }
You can also, matter of preference, in large projects, separate CSS styles into different sheets to make it easier for other people to read through your code.
CSS is whitespace insensitive so it tabbing will not make the compilation change, but it is of course common practice to tab accordingly.
There are plenty of other rules that many programmers follow, but the majority of them are opinionated so it is up to you to adopt an efficient way to layout your CSS. Even the rules I have stated will not "break" your CSS if not used, but they tend to help cause less problems. Research this topic further and try and adopt a set of rules to follow and stay consistent with them.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've never used media queries before and I'm really not sure if my code will work properly on all devices. Therefor I want to ask you to speak from your experience and knowledge and tell me what problems may appear on some special/any devices.
After some reading, I decided to go with as simple as I thought way and used simple rule:
#media (max-width:504px){
/* My style for mobile/ipad etc */
}
#media (min-width:505px){
/* My style for laptops/desktop etc */
}
IMO it is still better to write CSS for one of two display sizes, and then override the styles with media query. Fo ex. mobile-first approach:
#some-element { font-size: 2em; }
.container { color: red; }
.another-class { width: 100px; }
#media (min-width: 505px) {
#some-element { font-size: 1.5em; }
.container { color: blue; }
}
This way have two advantages:
You dont have to write the same code for two media queries, only overrides (you dont have to duplicate .another-class for media query).
Ancient browsers without media queries support will render site using styles that are not in media query.
Artur answer is correct, old browsers like IE7 don't support media queries, but media queries design is intended mostly for moderns browsers, so creating a fallback CSS isn't exactly required unless you want to, mostly because some CSS properties (hiding certain elements with display:none for example) won't work so your intended web design will lose purpose. Each web designer have their own way of writing CSS, but I prefer this method:
body, html{
width:100%;
margin:0;
/* Base CSS that will affect all resolutions */
}
#elements-up-to-320px{
/* CSS for elements up to first media query */
}
#media (min-width:320px){
/* CSS for elements from 320px and up until next media query */
}
#media (min-width:480px){
/* CSS for elements from 480px and up until next media query */
}
This way it's more understandable and last CSS media query will apply for higher screen sizes.
#media is good if you want to create a CSS-Gridsystem (for example) It takes a parameter with the min-width or more. So you have the possibility to set different CSS-Propeties for different Screen-Sizes.
Links:
SELFHTML
w3schools
Hope that helped you :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm thinking about css refacto in my job, and i'm wondering if it's a good idea (considering best practices) to create css class with only one property.
A simple example, is it usefull to create many classes this way
.center-text {
text-align: center;
}
What's the best between doing this or using small libs like Knacss (if you know it) for example.
BIGGEST PROBLEM WITH CSS CLASSES: THEIR LOCATION INSIDE YOUR FILE / CODE MATTERS!!
lets assume we have this html element:
<div class="test altr">some text</div>
this css file:
.test
{
color: red;
}
.altr
{
color: blue;
}
will result in a blue text (the div has those 2 classes). BUT this file will result with a red color:
.altr
{
color: blue;
}
.test
{
color: red;
}
the order of command in css is determine by the css file (and not the order inside the html class attribute)
not to mention that the physical order between and tags inside your html alo affects the order of commands in css (last command override all previous commands)
so.. whatever you do - please be careful with that
One minor drawback I see is the amount of text in your HTML will increase slightly due to pile up of classes. Not best SEO practices, but it's minor.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In the following article I read that one should try reduce the number of selecetors.
Article: use less selectors
I'm wondering if writing LESS and I'm using a lot of nesting to group parent and child elements, will that generate bad CSS code in the end?
LESS
.wrap{
width: 100%;
height: 20%;
background: green;
header{
background: blue;
h1{
color: red;
}
}
}
I'm using a lot of nesting to group parent and child elements, will that generate bad CSS code in the end?
In a word, yes. In the long run this will give you highly specific, unmaintainable CSS. Let 's have a look at what your example will produce for the h1 style.
.wrap header h1{ color: red; }
So what you've ended up with here is a very specific CSS selector, that isn't really necessary. You could, for instance, just have
h1 { color: red; }
or use a class on the h1
.title { color: red; }
Why is specificity bad?
So imagine, 6 months later another developer comes along and they need to change the color of a h1, but just one of them.
First they try to add a class to the h1
.new-color { color: blue; }
But the colour doesn't change because the original CSS is so specific. So they have to do this
.wrap header h1.new-color { color: blue }
or worse still they may do this
.new-color { color: blue!important; }
And then what happens when other changes need to be made? As you can see very quickly and very easily you can end up with unmaintainable CSS, that will have everyone pulling their hair out.
Performance
People usually negate performance when it comes to CSS, but it is always good to know what is going on when a page is rendered. CSS is read from right to left. Using your example
.wrap header h1 { color: red; }
This means the browser engine will search for every h1 and check if they have a parent header and then if that has a parent class wrap. If so it will apply the style. A low specificity makes the rendering process a lot simpler.
Summary
So to sum it up, nesting, whilst it may seem great keeping your code nice and readable, should only be used when absolutely necessary. It's very easy to forget what the CSS that is actually being produced looks like. Before you know it you'll be in nesting hell.
Languages like LESS or SASS give you more flexibility in declaring your style rules, and that can be good or bad depending on how you use it. The more flexibility you have in a language, the more you need design patterns and good practices to avoid making things worse than they were before.
LESS doesn't require that you always nest. You can always use CSS of course, and if you are applying a style to all p it might be better to define it globally, than to call mixins to obtain the same result on several nested ps.
But LESS and SASS do allow you avoid duplication, to write code that is clearer and easier to maintain, and other problems caused by the code duplication required by CSS.
When reading around the web concerning CSS performance, I often find a list of what selectors are more efficient than others. For example:
http://css-tricks.com/efficiently-rendering-css/
#main-navigation { } /* ID (Fastest) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (Slowest) */
#content [title='home'] /* Universal */
My question is, how is the performance when using selectors that require double selectors, for example:
.class-one.class-two {
}
If we were to put these selectors in the performance list above, where would they be?
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS?redirectlocale=en-US&redirectslug=CSS%2FWriting_Efficient_CSS#How_the_Style_System_Matches_Rules
Visit this link. It might be useful.
You shouldn't be so paranoid about that. More important is to have a good and clean code, avoiding hacks.
But there are some basic rules:
#main-navigation { } /* Never style ID's directly, use classes instead*/
body.home #page-wrap { } /* If you ever have to style ID's, do it directly, they are unique and doesn't need any selector. You're just wasting bytes */
.main-navigation { } /* No problem at all, but try to be more abstract. a class should not be so specific, try to reuse code as much as you can.*/
ul li a.current { } /* You should optimize this, you could use just ul .current. Try to use as little selectors as you can, it'll have good performance and will be easier to deal with. Try to use just 3 selectors at the max, so you''l have a good performance and clean code. */
ul { } /* No problem here */
* { } /* You'll won't have any serious problem if you use with caution. Properties like border-box are a good use of it. Anything that you have to set globally in your stylesheet is welcome to use it. */
#content [title='home'] /* Same as *. Don't overdo and you're good to go. */
More important is to have the cleaner code as possible. Try to avoid excessive overrides, unused code, too much selectors, repeated code and hacks. A good thing is to use OOCSS and BEM. If you use a framework, try to use something like inuit.css that sticks to good practice and all.
Keep in mind that even smartphones are pretty powerful today and as long as you don't over do using a lot of animations, unoptimized code, a lot of javascript you should have no real problem.
Ps.: If you use animations, stick to CSS3 transitions and animations because there's a good chance that they will be GPU accelerated and will get better perfomance.
Besides "Writing efficient CSS" Mozilla article, you may also be interested in the talk "Faster HTML and CSS: Layout Engine Internals for Web Developers" by Googlers http://www.youtube.com/watch?v=a2_6bGNZ7bA
In general, a browsers reads each selector from right to left and then "calculates" if it is applicable to a current DOM node. This is why the selectors ending with tags or with a lot of cascade cause performance problems, especially on dynamically re-rendered pages.
This can be avoided if following BEM CSS recommendations about independent CSS blocks. http://bem.info/method/definitions/#IndependentCSS
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am relatively new to CSS and yet I seem to have got the language reasonably well for a newbie. However, whilst many of the tutorials I have read often warn about "organising and structuring your stylesheet properly" (and I can certainly see why now I have created some rather long stylesheets myself) I cant for the life of me find any info about a standardised format for a styleheet or a logical pattern for layout that makes later human reading easy.
For example, do I create a comment-bracketed section for each "geographical" section of my page (header, row1, row2, article1 etc) and keep all styles for that section within those comment borders? The problem seems when I have styles that get re-used in other sections - and putting them under a section for page-wide styles then negates the purpose of grouping them by section at all. Likewise, structuring my stylesheet by grouping based on text styles, layout styles etc seems even more confusing.
Is there a "good practice"? I know this sounds dumb but it seems no matter what you do with HTML and CSS somebody is ready to tell you its wrong, bad practice or unsemantic and I'm left confused. I want my code to be a good example of my work in case an employer wants to check it in future.
I've never been actually taught, however I can let you know how I organise my CSS documents. As you say, I like to divide it up into "geographical" areas... i.e. the rules that apply to the header, the side bars, the main content, the footer, etc. And then, below these I add very specific rules, say if I need to style a form or a table on a particular page. Finally I add a "General Gubbins" section at the bottom when I add generic rules that may apply across the board.
Oh yes, I also like to add the designer's palette to the top for quick reference.
For example...
/*
PALETTE:
dark grey : #555555;
pink : #d93575;
*/
/* HEADER */
#header {...}
#header ul {...}
/* SIDE BAR */
#side {...}
#side ul {....}
/* CONTENT */
#content{...}
#content p {....}
/* FOOTER */
#footer{...}
#footer div {....}
/* FORMS */
form {...}
input {...}
/* GENERAL GUBBINS */
.center {...}
strong {...}
floatleft {...}
These guys advise you to "Organize the Stylesheet with a Top-down Structure" ( http://net.tutsplus.com/tutorials/html-css-techniques/30-css-best-practices-for-beginners/ ). I often use multiple style sheets. In MVC for instance - you can regiser styles on a per-view basis. That way you can put view-specific styles in a specific style sheet while not messing with your 'shared' or 'layout' one.