What does span {} do in CSS syntax? - css

I got some example CSS code (well written and working) with many span statements inside, that I modified for my use. What exactly they do? VS Code shows me as an error, but browsers don't complain, and I couldn't find any references in the CSS documentation, as if this syntax does not exist.
Example:
h2 {
letter-spacing: 2vw;
font-size: 2vw;
font-weight: bold;
text-align: center;
span {
display: block;
font-size: 8vw;
letter-spacing: -1vw;
}
}
VS code complains:
"code": "css-colonexpected",
"severity": 8,
"message": "colon expected",
"source": "css",
If I add colon it would be suggesting keys right away, and would not accept anything in curly brackets{}
Thanks

the brackets { and } define scope so that
body {
color: #000;
}
Would define that the color (text color) of the body element type (css query selector) would be #000 (which is hex for black)
however, if you have an element in an element like this using a precompiler such as less for css using the less syntax.
body {
color: #000;
span {
color: #FF0000;
}
}
this would do as the previous css did, but in less you can create a hierarchy
the body's color will be set to black as before.
and then any span child of the body element will have its color set to red (#FF0000)
CSS/LESS are used in conjunction with the HTML DOM object model.

You're correct that this syntax doesn't exist for CSS, as it doesn't support nested selectors like this.
The correct syntax would be:
h2 {
letter-spacing: 2vw;
font-size: 2vw;
font-weight: bold;
text-align: center;
}
h2 span {
display: block;
font-size: 8vw;
letter-spacing: -1vw;
}
This syntax is of course perfectly acceptable if you use a CSS preprocessor, like SASS or LESS for example. CSS preprocessors compile CSS written like you've done into standard CSS syntax, and add extra functionality, like using variables and conditional statements.
I think that modern browsers are probably capable of understanding syntax like this in certain situations, but if you want to use to this sort of syntax then using a preprocessor is a safer option to avoid errors.

Related

What does "#extend must be used with a %placeholder" mean?

While linting the following SASS statements, I get #extend must be used with a %placeholder warning.
.reg-text {
color: #202226;
font-family: $font-page;
font-size: 17px;
line-height: 25px;
}
.reg-text-header {
#extend .reg-text;
font-weight: 600;
}
What does warning mean and how do I fix it. Afaik, .extend exists for the purpose of extending classes.
This is referring to an opinion that using #extend with normal CSS selectors is a bad idea.
I personally agree with this opinion, but it is an opinion nonetheless. Using #extend with any sort of selector is what the Sass spec allows, so I would possibly get in touch with the maintainers of your linter and request that the terminology in your error explains this.
If you use #extend to extend the definition of a selector, every time the selector is extended is is compiled to CSS that includes a reference of the selector for every time the #extend keyword is used.
If, however, you use #extend with placeholder selectors starting with % (A.K.A. "Silent Classes"), the functionality is much more in line with best practices. First off, any unused placeholder selectors are not even rendered to the final CSS (great for building reusable design libraries).
For example, if you have a block of reusable content within a CSS selector, consider converting it to use a placeholder selector instead:
.reg-text {
color: #202226;
font-family: $font-page;
font-size: 17px;
line-height: 25px;
}
.reg-text-header {
#extend .reg-text; // this is inefficient and causes specificity issues!
font-weight: 600;
}
// Instead, do this:
%reg-text {
color: #202226;
font-family: $font-page;
font-size: 17px;
line-height: 25px;
}
div.your-actual-selector-on-the-page .reg-text {
#extend %reg-text;
}
div.your-actual-selector-on-the-page .reg-text-header {
#extend %reg-text; // This compiles much neater and doesn't get in the way of specificity.
font-weight: 600;
}

Using FontAwesome wrapped in own css rule [duplicate]

I am using Font Awesome 4.0.0, and want to do something like this in LESS:
.btn-github {
.btn;
.btn-primary;
margin-left: 3em;
i {
.#{fa-css-prefix};
.#{fa-css-prefix}-github;
.#{fa-css-prefix}-lg;
margin-right: 1em;
}
}
That doesn't compile with the error:
ParseError: Unrecognised input in - on line ...
Is it possible to accomplish this? It would certainly make a beautiful button for me.
There are at least 2 problems with what you are trying to do (for LESS >=1.6 see update bellow):
1) Unfortunately it is not possible to call a mixin using selector
interpolation.
With selector interpolation LESS expects the construct to be of
following format:
.#{selector-string} { property:value; }
(the interpolated selector can have also some static string pre or
post the interpolation)
so
.#{selector-string};
is Unrecognised by the LESS compiler. See more here:
How can I call a mixin by reference in LESS?
2) A ruleset with an interpolated selector gets directly printed to the CSS output and does not exist as a mixin that you could reuse in the LESS run
For example:
#foo: test;
.#{foo} {
length: 20px;
}
.bar {
.test;
}
will return:
Name error: .test is undefined
.bar { .test;}
See more on that here: LESS CSS: Reuse generated .#{name} class as a mixin
Possible solution for your problem would be redifinig the font awesome rules as some kind of reusable mixins (without using interpolation). Something like this:
#fa-var-github: "\f09b";
.fa-mixin() {
display: inline-block;
font-family: FontAwesome;
font-style: normal;
font-weight: normal;
line-height: 1;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
.fa-mixin-lg() {
font-size: (4em / 3);
line-height: (3em / 4);
vertical-align: -15%;
}
.fa-mixin-icon(#icon){
#var: "fa-var-#{icon}";
&:before { content: ##var; }
}
i {
.fa-mixin;
.fa-mixin-lg;
.fa-mixin-icon(github);
}
If you don't really need the variables and just want to include the rules, the best way would be just to import the compiled CSS version of the FontAwesome (see answer here):
#import (less) 'font-awesome.css';
and then you can just use the CSS rules like LESS mixins or extend their selectors as you see fit and it should work perfectly.
Update:
As of LESS >= 1.6 rules with interpolated selectors can be accessed as mixins ... so the #2 limitation form above does not apply anymore (but you still can not call a mixin dynamically with interpolation). So you can simply call LESS mixins and variables from the imported font-awesome.less file like so:
i {
.fa;
.fa-lg;
&:before{
content: #fa-var-github;
}
}

LESS mixin a variable class name

I am using Font Awesome 4.0.0, and want to do something like this in LESS:
.btn-github {
.btn;
.btn-primary;
margin-left: 3em;
i {
.#{fa-css-prefix};
.#{fa-css-prefix}-github;
.#{fa-css-prefix}-lg;
margin-right: 1em;
}
}
That doesn't compile with the error:
ParseError: Unrecognised input in - on line ...
Is it possible to accomplish this? It would certainly make a beautiful button for me.
There are at least 2 problems with what you are trying to do (for LESS >=1.6 see update bellow):
1) Unfortunately it is not possible to call a mixin using selector
interpolation.
With selector interpolation LESS expects the construct to be of
following format:
.#{selector-string} { property:value; }
(the interpolated selector can have also some static string pre or
post the interpolation)
so
.#{selector-string};
is Unrecognised by the LESS compiler. See more here:
How can I call a mixin by reference in LESS?
2) A ruleset with an interpolated selector gets directly printed to the CSS output and does not exist as a mixin that you could reuse in the LESS run
For example:
#foo: test;
.#{foo} {
length: 20px;
}
.bar {
.test;
}
will return:
Name error: .test is undefined
.bar { .test;}
See more on that here: LESS CSS: Reuse generated .#{name} class as a mixin
Possible solution for your problem would be redifinig the font awesome rules as some kind of reusable mixins (without using interpolation). Something like this:
#fa-var-github: "\f09b";
.fa-mixin() {
display: inline-block;
font-family: FontAwesome;
font-style: normal;
font-weight: normal;
line-height: 1;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
.fa-mixin-lg() {
font-size: (4em / 3);
line-height: (3em / 4);
vertical-align: -15%;
}
.fa-mixin-icon(#icon){
#var: "fa-var-#{icon}";
&:before { content: ##var; }
}
i {
.fa-mixin;
.fa-mixin-lg;
.fa-mixin-icon(github);
}
If you don't really need the variables and just want to include the rules, the best way would be just to import the compiled CSS version of the FontAwesome (see answer here):
#import (less) 'font-awesome.css';
and then you can just use the CSS rules like LESS mixins or extend their selectors as you see fit and it should work perfectly.
Update:
As of LESS >= 1.6 rules with interpolated selectors can be accessed as mixins ... so the #2 limitation form above does not apply anymore (but you still can not call a mixin dynamically with interpolation). So you can simply call LESS mixins and variables from the imported font-awesome.less file like so:
i {
.fa;
.fa-lg;
&:before{
content: #fa-var-github;
}
}

Wrapping css without bloating css file

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.

Does sass harm performance?

I've been educating myself. Reading this:
The engine evaluates each rule from right to left, starting from the rightmost selector (called the "key") and moving through each selector until it finds a match or discards the rule. (The "selector" is the document element to which the rule should apply.)
For example:
ul li a {...}
#footer h3 {...}
* html #atticPromo ul li a {...]
Now, some example code SASS outputs for me:
#content #blog {
/* ... */
}
/* line 85, ../sass/screen.scss */
#content #flickr {
/* ... */
}
#content #flickr div p {
/* ... */
}
This seems a bit awkward.. am I doing something wrong? Is this a communication problem between me and Sass? Are we losing it?
Edit:
Some SCSS code:
#flickr {
#include columns(5,8);
background: url('../img/ipadbg.png') no-repeat;
#ipod-gloss {
z-index: 999;
position: relative;
}
div {
margin-top: -80px;
margin-right: 20px;
h2 {
color: $white;
font-size: 24px;
}
p {
margin-top: 40px;
}
}
}
Side Bonus!: The article says browsers (or at least Firefox) search the selectors from right to left. I couldn't understand why this is a more efficient why. Any clues?
You have to find your compromise between maintainability (nesting makes it easier to find your way around in the stylesheet) and rendering performance.
A rule of thumb says you should try to restrict yourself to a three-level nesting and you should avoid to nest IDs if it's not necessary.
However, I think nesting too much is not the biggest issue. As soon as I became aware of the power of mixins, I used them a lot.
For example, this is my often used button mixin:
#mixin small-button($active-color: $active-color, $hover-color: $button-hover-color, $shadow: true)
display: inline-block
padding: 4px 10px
margin:
right: 10px
bottom: 10px
border: none
background-color: $button-color
color: $font-color-inv
+sans-serif-font(9px, 700)
text-align: center
text-transform: uppercase
cursor: pointer
#if $shadow
+light-shadow
&:hover
text-decoration: none
background-color: $hover-color
&:last-child
margin-right: 0
a
color: $font-color-inv
&, &:hover
text-decoration: none
&.disabled
+opacity(0.75)
&:hover
background-color: $button-color
&.active
background-color: $active-color
&.disabled:hover
background-color: $active-color
You see, quite a bit code. Applying such mixins to many elements on your page will result in a big CSS file which takes longer to be interpreted.
In the old fashioned CSS-way you would give each button element e.g. the class .small-button. But this method pollutes your markup with unsemantic classes.
Sass provides a solution though: selector inheritance via the #extend directive.
If you set defaults for your parameter of the mixin, you can also provide a simple class, which uses the mixins with your default:
// Use this mixin via #extend if you are fine with the parameter defaults
.small-button
+small-button
And then you can just inherit from this class in various contexts:
#admin-interface
input[type=submit]
#extend .small-button
The resulting CSS statement aggregates all usages of .small button into one rule with comma-separated selectors:
.small-button, #admin-interface input[type=submit] {
display: inline-block;
...
}
Concluding, a naive usage of Sass can effect your CSS performance. Used wisely, however, it is maintainable thanks to well-structured and DRY code, it leads to proper separation of markup and styling (semantic classes only) and allows for smart and performant CSS code.
SASS is only a language that compiles down to CSS. If you're concerned with SASS' performance in terms of how it runs in the browser, then SASS doesn't enter the equation -- it'll be compiled and served to the browser as regular CSS.
From what I can see of your usage of SASS, there's a couple of things I could suggest:
You don't have to nest everything.
The ability to nest rules inside each-other in SASS is a language feature, but you don't have to do it if it doesn't make sense to do so.
In terms of your general CSS usage:
If the nesting gets too severe/unwieldly, consider using classes where it makes sense.
When it's necessary to use the hierarchy of DOM elements, consider using the [child combinator]: .foo > .bar.
IDs are meant to be unique, thus should always only reference a single element. Most of the time, they can be CSS rules unto themselves -- #content #flickr would become just #flickr, for instance -- and browsers will optimise the lookup for a single ID. The only time you would need something like #id1 #id2 is if #id2 needs to appear in different contexts on different pages.
If your selector contains things like #id div p, that div is either superfluous or serving a specific purpose.
If it's superfluous, change the rule to #id p, which selects any <p> that occurs as a descendant of #id.
If it serves a specific purpose, consider classing the <div> with a class name that describes its purpose -- perhaps <div class="photos-list">. Then your CSS could become .photos-list p, which is far more maintainable and reusable.

Resources