I am converting a website using sass, nesting saves me from having to duplicate parent selectors (eg - sociialmedia, socialmedia li, sociallmedia img)
However, when the viewport is at mobile size, I need to change the styling of socialmedia img. Therefore I have create the code below:
my questions are:
1) Is this an efficient way to code (example 1), or is there a better method?
2) example 1 works , but is example 2 more efficient?
Example 1
#socialmedia {
float: right;
li {
float: left;
}
#include bp(mobile) {
img {
width: 1.1em;
}
}
}
Example 2
#socialmedia {
float: right;
li {
float: left;
}
}
#socialmedia img {
#include bp(mobile) {
width: 1.1em;
}
}
Many thanks,
It depends on what you mean by "efficient"—if you are referring to the efficiency of the compiled CSS code, both of your examples are equivalent; they both compile down to the same CSS.
If you are referring to developer efficiency, in my opinion the first example is more readable and maintainable (one of the nice features of Sass is the ability to nest media queries in context, which is what you are doing). Your example 1 is usually the approach I take.
So, in answer to your questions:
This is a perfectly acceptable method.
No.
Related
In my curently workflow, I use some mixins to easier responsive breakpoints code. I also use gulp to process and compress those generated CSS. Example below:
#footer {
.block-contacts {
.social_title {
display: block;
#include desktop() {
display: inline-block
}
&:before {
width: 100vw;
#include desktop() {
width: 50vw;
}
}
}
}
}
After the process of compile and minify, this code above ends up repeating the #media rule, like this:
#footer .block-contacts .social_title {
display: block;
}
#media(min-width: 64rem){
#footer .block-contacts .social_title {
display:inline-block
}
}
#footer .block-contacts:before {
width:100vw;
}
#media(min-width: 64rem){
#footer .block-contacts:before {
width:50vw
}
}
In this example I used only a "small" hierarchy and selector, but this in the whole project I guess it could be a negative impact for performance or assets size.
I know I can avoid this duplicity recreating the rule structure inner a single #include desktop() at the end of file.
My question is if there is another way, authomated, to reduce those lines creation, something I can do in the mixin that join all of this calls, or some gulp process/plugin, or even in the SASS...
I've recently played around with CSS grids, including great frameworks like Susy (http://susy.oddbird.net/), Foundation (http://foundation.zurb.com/) & the semantic grid system (http://semantic.gs/).
They all share this option of "including" a grid mixin instead of specifying a html class e.g.
.some-div{
#include grid-column(4);
}
While this seems like a good semantic approach, i was wondering about the cost in terms of css weight, css logic and if it's really worth it just to be semantic?
What are the pros and cons of using a mixin grid vs html classes?
Why HTML/CSS semantics are important
There are some much articles on the web about this! Just google it and you'll find a lot of invaluable information.
Here's a good one: How Important Is Semantic HTML?
Semantic html is important because it’s:
Clean — It’s easier to read and edit, which saves time and money during maintenance, and you don't have to force all your users to download a bloated library of styles many of which are not even used on the website
More accessible — It can be better understood by a greater variety of devices. Those devices can then add their own style and presentation based on what’s best for the device. It's also more appropriate for JS frameworks.
Search engine friendly — This is still debatable as search engines rank content and not code, but search engines are making greater use of things like microformats to understand content.
The most important argument for me is that semantic approach is just... the right thing to do. Follow this methodology carefully and you'll have so less causes for regrets.
Why i don't agree with #Mohamad's answer
Google is a bad example
Google's approach to semantics is extremist and violates their own style guide so many times that it's ridiculous. Just have a look at the HTML code of Google search results or HTML and you'll feel sick. It is necessary to understand that Google is an ultra high load website and they trade everything in favor of milliseconds of loading.
CSS is bulky to work with, use SASS
The main Mohamad's argument is that semantic approach is difficult on large projects. In fact, that's only true for old school CSS.
Indeed, it is counter productive to use semantic style with pure CSS. The larger the project, the more effort it requires to go for semantic approach.
But there's SASS. Whoever has tried SASS, never returns to vanilla CSS. SASS offers an incredible lot of powerful improvements, some of which make coding semantically effortless.
SASS code is compiled into normal CSS code. The most important thing to understand about SASS is that you only have to care about the structure and readability of your SASS code. The resulting CSS code may be hard to read and contain duplicates, but it is not a problem because CSS is gzipped by server.
#extend
The most important SASS feature in concern of HTML/CSS semantics is the #extend directive. It allows you injecting a reusable block of styles into semantic selectors, while producing efficient CSS.
First, declare a block of styles to be reused, for example:
%glyph {
display: inline;
width: 16px;
height: 16px;
background-repeat: no-repeat; }
You can later include it into different selectors semantically:
.star {
#extend %glyph;
background-image: url('../images/star.png'); }
.extenral-link {
#extend %glyph;
background-image: url('../images/external-link.png'); }
The resulting CSS will be very efficient:
.star, .extenral-link {
display: inline;
width: 16px;
height: 16px;
background-repeat: no-repeat; }
.star {
background-image: url("../images/star.png"); }
.extenral-link {
background-image: url("../images/external-link.png"); }
#include
Unfortunately, you can't use the beautiful #extend feature within media queries. So if you do responsive design, you'll have to produce CSS code with duplicate fragments. As i said earlier, duplication in CSS is not a problem thanks to gzip, it's the cleanness of SASS that matters.
Mixins (#include) allow you to inject blocks of reusable styles into selectors. They are not grouped effectively, but they accept arguments and can produce varying styles for different semantic selectors:
#import 'singularitygs';
$breakpoint: 300px;
$grids: 2 3;
$grids: add-grid(6 at $breakpoint);
%column {
background-color: pink;
min-height: 5em;
margin-bottom: 1em;}
#welcome {
#extend %column;
#include grid-span(1, 1);
#include breakpoint($breakpoint) {
#include grid-span(2,1); }}
#product-features {
#extend %column;
#include grid-span(1, 2);
#include breakpoint($breakpoint) {
#include grid-span(2,3); }}
#description {
#extend %column;
clear: both;
#include breakpoint($breakpoint) {
#include grid-span(2,5); }}
Produces:
#welcome, #product-features, #description {
background-color: pink;
min-height: 5em;
margin-bottom: 1em;
}
#welcome {
width: 38.09524%;
float: left;
margin-right: -100%;
margin-left: 0%;
clear: none;
}
#media (min-width: 300px) {
#welcome {
width: 31.03448%;
float: left;
margin-right: -100%;
margin-left: 0%;
clear: none;
}
}
#product-features {
width: 57.14286%;
float: right;
margin-left: 0;
margin-right: 0;
clear: none;
}
#media (min-width: 300px) {
#product-features {
width: 31.03448%;
float: left;
margin-right: -100%;
margin-left: 34.48276%;
clear: none;
}
}
#description {
clear: both;
}
#media (min-width: 300px) {
#description {
width: 31.03448%;
float: right;
margin-left: 0;
margin-right: 0;
clear: none;
}
}
Demo: http://sassbin.com/gist/5883243/
Compass extensions
As you noticed above, i use a grid-span mixin that is not declared in code. That's because it comes from the awesome Singularity extension.
The ecosystem of numerous Compass extensions provides you a great set of tools for all needs: semantic grid systems, responsive design, colors, math, all kinds of styles... You don't have to reinvent a thousand of wheels for every project you build!
What to read about SASS
This is a great starting point for SASS newcomers: https://github.com/Snugug/training-glossary/wiki , created by Sam Richard aka Snugug.
I often feel that some advocates of semantic grids have never written complex applications. The answer, as ever, is the proverbial "depends."
It depends on your style, your team, and your application. In some projects that required modular design, being semantic required extra code and effort for very little return. In others, simpler ones, it was fine. Take a look at the CSS that Google uses. Not everyone is Google-size, but that illustrates my "depends" point.
The advent of HTML 5 has solved some of these problems with tags such as section, header, and article. I tend to use those semantically. But my CSS class names tend to describe abstract divisions of my design, not what the thing is specifically.
There are no straight answers, but careful not to waste too much time worrying about this stuff. It means very little if your application is late or does not make it out of the door.
Do what you and your team feel comfortable with.
I was wondering if I could override the nesting in LESS, to stay in my scope - just because it's simpler... :-)
If I have an element which has two states, depending on let's say a body-class, I need to define two CSS objects. I would like to have only one, per module.
.module {
h1 {
float: left;
}
}
body.secondary {
.module {
h1 {
float: right;
}
}
}
Like when you define the parent with &, is there any way to overwrite that parent?? So maybe it could look like this:
.module {
h1 {
float: left;
}
&=body.secondary {
h1 {
float: right;
}
}
}
Where the & is defined as another selector...
This could be awesome, and make my CSS more simple in terms of one CSS object per module.
Thanks... :-)
I've done some extensive commentary on this both in this answer and this answer. In your particular case, it would be this:
LESS
.module {
h1 {
float: left;
body.secondary & {
float: right;
}
}
}
CSS Output
.module h1 {
float: left;
}
body.secondary .module h1 {
float: right;
}
The key is to realize that the & is not just for targeting the "parent" per se in the html structure, but rather is a string replacement for the entire nested structure it sits within. So in my solution above, the nested LESS "parent" is .module h1 which is the string replaced at the & point in the body.secondary & construct nested within it.
I was wondering if something like this can be done in CSS. I want to be able to group css so that I can I don't have to write it like this.
.wrapper .header {do: something};
.wrapper .nav .firstMenuItem {do: something};
[div id="wrapper"]
[div class="header"]
[div class="nav"]
[ul]
[li class="firstMenuItem">First Item</li]
[/ul]
[/div]
[/div]
[/div]
Instead, I would like to do something like this but I've never seen it being used like this
.wrapper
{
.header .nav {do:something;}
.header .nav .firstMenuItem
{
do: something;
}
}
You can do this with LESS and SASS
However, before going too far down this road I recommend you read a little about Object Oriented CSS. (Some good tips from people who have experience with large projects)
LESS example:
#header {
color: black;
.navigation {
font-size: 12px;
}
.logo {
width: 300px;
&:hover { text-decoration: none }
}
}
SASS example:
.error {
border: 1px #f00;
background: #fdd;
}
.error.intrusion {
font-size: 1.3em;
font-weight: bold;
}
.badError {
#extend .error;
border-width: 3px;
}
You can't do that with pure CSS, but you can use something like:
LESS
SCSS
Not with CSS alone, but you can for example use LESS which provides this kind of nesting.
I'm afraid that is just not possible in classic CSS. It is against the syntax.
There to exist interpreters for alternative syntaxes, which will just turn your syntax into valid CSS either at compile-time or run-time. You could look for or write one of those.
But if you want what you write to be valid CSS, this is just not possible.
See section /* Common Classes */ of this page.
http://webdesign.about.com/od/css/a/master_stylesht_2.htm
are these css classes good, to use in any project? in terms of semantic?
/* Common Classes */
.clear { clear: both; }
.floatLeft { float: left; }
.floatRight { float: right; }
.textLeft { text-align: left; }
.textRight { text-align: right; }
.textCenter { text-align: center; }
.textJustify { text-align: justify; }
.blockCenter { display: block; margin-left: auto; margin-right: auto; } /* remember to set width */
.bold { font-weight: bold; }
.italic { font-style: italic; }
.underline { text-decoration: underline; }
.noindent { margin-left: 0; padding-left: 0; }
.nomargin { margin: 0; }
.nopadding { padding: 0; }
.nobullet { list-style: none; list-style-image: none; }
No. They are not good choices. The whole point of css and in particular about the concept of class is to describe "what" something represents, not "how" it should appear. What something means (i.e. its semantics) and how it appears (i.e. its presentation) are two separated concepts. The fact that something is, say, a menu does not change if you decide to show it blue on light blue with one stylesheet and high contrast black on white on another stylesheet made for colorblind people.
If you give class a presentation meaning, changing how a document appears would require changes in the web page html, defeating the whole point of having CSS as a technology specifically designed to provide and encapsulate presentation. To prevent this, the alternative would be to end up having classes whose names do not represent reasonable information (e.g. class called "bluefont" which actually contains a color:red directive). Hence, having "bluefont" as a name is totally arbitrary, and here becomes desynchronized with the actual content. It could have been a random string "abgewdgbcv", but then it's better to choose something that is unrelated to presentation and conveys meaning: its associated semantics.
And we close the circle: it's the whole point of classes. See also this document at W3.
No, not really.
Preferrably a class name should describe what you use it for, not exactly what it does.
If you for example name a class "bluebold" and then decide that you want the text to be red and italic, you either have to create a new class and change it everywhere it's used, or you end up with a class name that no longer fits.
One point that I would like to suggest is, when you are extending these just make sure that you just use verbs instead of using any adjectives as names for the classes and you should be good!
Edit:
I agree with others point of class names representing what it is used for, not exactly what it does.
Common CSS classes are way too granular and promote classitis problem. Pseudo selectors can mitigate the problem to some extent. Assuming a new website is being designed I would do the following:
*{
margin:0;
padding:0
}
li {
list-style: none;
list-style-image: none;
}
The rest are difficult to address, floatLeft and floatRight are to be defined by the layout,
<div id="main">
<div class="searchPanel">
</div>
<div class="resultsPanel">
</div>
</div>
The CSS ideally should look like ( layout driven)
#main searchPanel {
float: left;
}
#main resultsPanel {
float: right;
}
Hope you get the idea. I however, face problems with bold/underlined text. Underlined text is indicative of ugly design. Users tend to confuse such with hyper-links
some recomendations:
.floatLeft --> .float-left:
no camel cased.
.bold --> .important
name should tell the goal no showing how to do it
.nobullet --> ul.nobullet
is better to be most specified to avoid conflict with other css.