Let's suppose we have code snippet like that:
<div class="wrapper">
<nav></nav>
<header></header>
</div>
I think in HTML 5 era it's important to stylize code correctly. For instance - could you tell me which solution is better and why? And how can I learn that "semantic" of SASS?
First (div's layout is sustained):
.wrapper {
nav { ... }
header { ... }
}
The Second (all of elements are separate):
.wrapper {}
nav {}
header {}
*Of course - we're talking about situation when it isn't necessary to mark parent-children connections (all of these occur only once at site).
I don't think we're talking about SASS semantics here but the answer is that you probably want to let the nesting of your styles reflect the nesting of your markup.
So if your markup is nested as you say, then the nested styles are the correct way to do it. Additionally you may want to cautiously add more global styles in each scope but it's best to keep these to a minimum (as always with global information in software development).
Example:
body {
.some-global-body-style;
.nav {
.some-global-nav-style;
.subnav {}
}
.content {}
}
Related
Well I'm watching videos about oop css with bem. I didn't understand one thing. I have a media object and I use it everywhere like in navbar and content and footer etc. So how shall I change the media object and insiders. I guess 3 ways there are.
1 - I can catch inside other blocks grandchild chooser
it will like ".navbar .media".
This way makes me worrying because of grandchildren is making slow and complicated I think. Don't think about only .media. I have to select media-item etc etc...
2 - I can give another class to .media like .navbar together
it will like ".navbar.media".
This way need more classes to html so it makes me thinking.
3 - I guess there is no third option if there is please let me know :) Which way I shall do.
Thank you already.
You should add an extra class, navbar__media (that's a double underscore for descendant), and add that to the media elements inside of the navbar.
A rule of BEM/OOP CSS is that an element should always have their style defined by the classes they have, and not based on where they are in the DOM.
For reference: http://getbem.com/naming/
Example:
<div class="navbar">
<div class="media navbar__media"></div>
</div>
<div class="media"></div>
With this css:
.navbar {
background: #00f;
}
.media {
background: #f00;
}
.navbar__media {
background: #0f0;
}
One feature I really love with LESS is nested rules. It makes the stylesheet much cleaner that way and you can find an element very quickly.
I was wondering if there's an option when compiling to optimize selectors. For example...
#global {
/* Styles here maybe */
.container {
/* Styles here maybe */
#sidebar {
/* Styles here maybe */
.title {
font-weight: bold;
}
}
}
}
will be compiled to #global .container #sidebar .title { font-weight: bold; }.
But the first two selectors are useless, since #sidebar should be unique in my page.
Is there a way to ask LESS to compile this to #sidebar .title { font-weight: bold; } instead?
Your assumption is wrong that multiple IDs in CSS are redundant. Imagine, as an example, a site where the CMS generates the page type into the output, like that it's the contact page:
<body id="contact">
<section id="content">Blah</section>
</body>
According to your logic, the following piece of CSS would be a candidate for 'optimization':
#contact #content {
background:red;
}
Now however, your home page has <body id="home"> of course in this imaginary CMS. And suddenly the content of your homepage has a red background because you decided to erroneously optimize that #contact selector out of the CSS, while it most certainly shouldn't have a red background according to this rule.
So no, LESS cannot do this because it would break code. If you don't want the selectors, don't use them and don't put them in your code.
Other answers, including the accepted one, have explained convincingly why LESS cannot simplify your nested selectors in the way you want.
Actually, SASS has the ability to do this:
#global {
.container {
#at-root #sidebar {
.title {
font-weight: bold;
The #at-root directive essentially ignores all the higher nesting selectors. I don't know if LESS has something similar. The above compiles into simply
#sidebar {
.title {
font-weight: bold;
But there is a deeper issue here, starting with the fact that you "love" nested rules in LESS. Stop loving them quite so much. I don't know about you, but most people love nested rules because they think it's cool to exactly mimic the hierarchical structure of their HTML. The SASS docs even claim this as a benefit:
Sass will let you nest your CSS selectors in a way that follows the same visual hierarchy of your HTML.
So people with HTML such as
<div class="foo">
<ul>
<li class="item">
write LESS like
.foo {
ul {
li.item {
This is a horrible, horrible idea, It makes the structure of CSS completely dependent on the structure of the HTML. If you change one nesting level in the HTML, your CSS breaks. Often this approach is combined with a lot of rules defined against tag names such as ul instead of class names, which aggravates the dependency, so changing the ul to ol in the HTML breaks the rules again. Or it's combined with rules based on Bootstrap classes such as col-md-6, so if you ever change that to col-md-4 things break again.
CSS rules should be orthogonal to the HTML. They represent a different dimension. They represent styling concepts which are applied selectively throughout and across the HTML.
I am guessing that you wrote
#global {
.container {
#sidebar {
.title {
font-weight: bold;
because you are adopting this mistaken idea of mirroring the HTML structure in your LESS. Then, you notice that this compiles down to having selectors which contain multiple IDs, which you imagine must be inefficient (although, actually, the degree of inefficiency is minimal). You yourself are writing extraneous nesting levels in your LESS, then complaining that they may be slowing down performance!
Worse, you've hard-wired assumptions about the HTML structure into your CSS. It's of no consequence that the sidebar happens to fall inside a .container which is inside a global element. So don't write them. Perhaps at some point you decide to change the container class to container-fluid. Boom, instantly your CSS breaks. What is the point of conditionalizing the fact that the title should be bold on it being contained with a container class, which in any case is a layout-related class that has (or should have) nothing to do with styling? If you're going to duplicate your HTML structure in your CSS using preprocessor nesting, just go back to writing inline styles. At least that way you'll only have one file to change when you change your HTML around.
When designing CSS, you should think just as hard about the design of the rules as you do about the design of classes and methods when writing JS. In this case, you need to ask yourself, "What characterizes the situation where I want some title to be bold? What drives that? What is the nature of boldness? What am I indicating by boldness? What is the semantic notion indicated by boldness?"
Let's say that you want all titles to be bold. Then you simply say that:
.title { font-weight: bold }
Let's say that you want a title to be bold only when it's in the sidebar. Then you simply say that:
#sidebar .title { font-weight: bold; }
My suggestion here is to go cold turkey. Stop using nesting during a withdrawal period. Write rules with the minimum number of selector components. Refactor your classes to have semantic names (such as title-emphasis). Once you're "sober", you can go back to cautiously using LESS's nesting capability when it is useful, such as perhaps for hover:
#boo {
color: red;
&:hover {
color: blue;
}
}
This is actually useful and saves you from writing #boo twice, and groups the rules in an easy-to-understand way.
basically just want to know if the attached image shows a valid CSS usage? I'm using a lot of nested divs lately and this is how I'm targeting them in my CSS. It works really well but I'm just curious if it's a good way of doing it? Or is there an easier / more efficient way?
Thanks!
link to the image
First of all: yor way is totally ok and the efficiency depends on the whole page. Maybe it can get more efficient with those ideas:
If your div-classes or ids are unique
You can also write just the class - you dont have to write the whole path then. Instead of
#content > .inner > .content > div { }
it is possible to write for example
.content > div { }
Helpful when you are using nested divs
When using nested divs you very often have to type a lot of code multiple times:
#content > .inner > .content { }
#content > .inner > .content > div {}
#content > .inner > .footer {}
#content > .inner > .footer > div {}
There are very helpful scripts called LESS and SASS (both of them work pretty much the same). They allow you to write everything just one time like
#content {
.inner {
.content {
// some stuff
div {
// some stuff
}
}
.footer {
//some stuff
div {
// some stuff
}
}
}
}
The direct child selector (ie. > ) is fine, but personally I don't like it because it makes it difficult to move and re-use styles. For example if I want to use .content somewhere other than #container I'm going to have to change a whole heap of CSS. Ideally you should be able to re-use blocks of markup without having to change CSS.
The direct child selector is best used to limit the depth to which a style is applied. For example it would be appropriate to use .content > p if you want the style to apply only to direct children so you can have another style for deeper children. If that's not the case then you might as well just use well named class and ID selectors.
I was wondering if it is possible to define the styles of an element depending on the value of the body ID.
It is difficult to explain but something like this would be ideal:
HTML:
<body id="home">
CSS:
body#home {
a { /* code here */ }
p { /* code here */ }
}
body#profile {
a { /* different code here */ }
p { /* different code here */ }
}
I know I can do this:
body#home a { /* code here */ }
but that becomes very repetitive.
I will be looking forward to your responses,
Peter
You can do this if you use a CSS framework like SASS or LESS
Here's the documentation on how to do this with LESS. Hope this helps.
IDs are supposed to be unique, so #home { ... } is acceptable.
Then and child elements would be:
#home .myClass { ... }
This technique if often used to re-skin pages be simply changing the ID or class on a body.
Be aware that while nesting styles like this can be supported using CSS frameworks, it should be well thought-out to maintain modularity and clean inheritance in your CSS. You can end up doing more harm than good. In particular, watch out for something know as the inception rule, described here:
http://thesassway.com/beginner/the-inception-rule
The Inception Rule: don’t go more than four levels deep.
Any change you make to your markup will need to be reflected into your
Sass and vice versa. It also means that the styles are bounded for
life to the those elements and that HTML structure which completely
defeats the purpose of the "Cascade" part of "Cascading Style Sheets."
If you follow this path, you might as well go back to writing your CSS
inline in your HTML (please don't).
The best way to do what you are talking about is to have a base stylesheet the site.
They have either:
A <style> element in the header overriding anything you choose
or
Have a different stylesheet for each page
I'm trying to make a very basic HTML/CSS/JS widget, but I'm having some problems with the CSS layer. It seems that I can't write selectors that work, and it's becoming very aggravating. In particular, I'm trying to override the font-size setting inherited from the body css selector for the widget. My HTML (actually, it's Hamlet) is:
<div class="container">
<div id="flashcard-container">
<div class="span6 offset3 well flashcard">
<div class="front">
<p class="flashcard">This is the front of the card.
and my CSS file says:
.flashcard p {
font-size: 24px;
}
div .back {
display: none;
}
Actually, I have a problem with both selectors. In particular, the first one just does not work to match the xml structure. The second one seems sub-optimal. Why should I need to specify that I'm talking about a div at all? I just want to quantify over backs, whatever tag they are.
I realize this is extremely basic, but I think that between this and some Chrome bugs with 3d transitions, I got myself extremely confused. It has been many years since I've dealt with the front-end. :(
If you wish to target a node with a class attached, the syntax is
elementname.classname {...}
(although OOCSS fanatics will suggest just using .classname and making your CSS structurally agnostic).
I am not sure what you mean by 'quantifying over backs', but if you simply want to target an element with a 'back' class, you can target it as so:
.back {...}
Though it might be best to contain the styles as 'back' is a rather generic class name:
.flashcard .back {...}
Try this:
p.flashcard { ... }
div.back { ... }
Actually I can't see a div with back class in your code.
You may as well use just .flashcard and .back. Specifying div or p just narrow the choice. If you specify .flashcard it will be applied both to, say, or .
But if you write
.flashcard p { ... }
It means that you chose all descendants of .flashcard, like:
<div class="flashcard">
<p>...</p>
</div>