So I'm fairly new to coding and I set a task for myself, that being to recreate my WordPress site from the ground up using HTML, CSS and javaScript, now as I have looked for resources online for the best method ongoing about making a responsive navigation bar, of course, I came across an example on W3Schools.
Now the question I have is what is the best way to go about Adjoining Classes, my CSSLint picks it up as bad practice(At least that's what I'm taking away from it) so I'm met with a conundrum whether to stick with them and just make it incompatible for IE 6 (I believe) or to just learn the use the better standard.
#media screen and (max-width: 600px) {
.cMainNav.responsive {
position: relative;
}
.cMainNav.responsive a.icon {
position: absolute;
right: 0;
top: 0;
}
.cMainNav.responsive a {
float: none;
display: block;
text-align: left;
}
}
I think you're misunderstanding. Adjoined classes are not a standard. This is just one of the many parts of css specificity.
If you have an element with two classes:
<div class="square red"></div>
<div class="square green"></div>
You can target their combination like so:
.square.red {}
CSSLint may be warning you that making really long, complex selectors like this is less than ideal. You never want to end up with something like this:
.square.red.fixed.flex.button{}
If you need really specific targeting, you're better off assigning an id or a specific class altogether.
<div id="loginModal"></div>
In general, all of these are just tools at your disposal. Read more about specificity and keep in mind that there's really no "wrong" option here, but any of these options can be abused.
Related
I have a angular project which use a library called smDateTimeRangePicker , it include the code below:
Link Here
.action {
height: 30px;
margin-bottom: 0;
position: absolute;
bottom: 0;
width: 100%; }
However, in my project, there is a code which also include action class
<div flex class="action cell">
And it is impacted by the CSS above, how to avoid it?
This question considered about these points below:
There is a way that can avoid the CSS impact between project and library.
The library uses a bad practice, it must avoid impacting project. It is a bug for the library and must be fixed.
This impact usually happens, so I need to change my project to avoid the conflict
Rename your project action class to something else is the cleanest way. Else you have to resort to fixes that are considered bad practice like !important, however these still get the job done.
this happens to me quite frequently, so to solved it I just add one parent class to my page or that particular section
<div class="my-unique-class">
---
<div class="action">
---
</div>
---
</div>
.my-unique-class .action {
height: 30px;
margin-bottom: 0;
position: absolute;
bottom: 0;
width: 100%;
}
You can avoid such kind of situation by increasing specificity of your css rules.
There are multiple ways to do so:
Include all third party CSS files before your custom file so that css rules with same priority (In Your Case) can override the rule in third party CSS file.
Above solution should work in most of the cases, but there are chances that Third party CSS might come with higher priority orders, so you can increase weight of your css by adding class at your parent tag as:
.parent > .action {
/ * Some CSS Code */
}
<section class="parent">
<div flex class="action cell"></div>
</section>
MDN has great article about CSS Specificity here
If you can't change your class name, you could make your styles unique to your element by doing:
.action.cell {
/*your styles here*/
}
By leaving out the space between action and cell you are saying that both classes are on the same element. Also, make sure you are loading your stylesheet after the 3rd party stylesheet so that your styles are being applied over theirs.
When you have a CSS rule, you can use !important before semicolon:
background: black !important ;
It marks your rule as "important" and it cannot be changed with any CSS file.
Only inline CSS can overwrite it:
style="background: blue !important"
I have a button that is displayed in a lot of pages of my website (With an automated javascript Widget).
I want this CSS :
.app.programEditor .col-2 .actions .widget.bt-flat.programs > .bt-flat-icon {
}
to be applied, and not this one :
.app.programEditor .actions .widget.bt-flat > .bt-flat-icon {
left: 145px !important;
top: 19px !important;
But instead, what happens, is the two css are applied, and as a result I get the second element that overwrites what I want to do with the first CSS ( A blank css with no rules )
Please I really need your help
The root cause of your problem is the poorly written rule that uses !important. This is an excellent example of why not to use !important. If at all possible, try to understand why !important was thought to be needed there, and see if you can remove it.
But if you are left fighting against an important rule, your only choice is to fight fire with fire, and toss back an !important of your own, in a rule designed to take precedence either because it is more specific (in this case, your override rule has seven classes, to the original rules's six, so it is more specific), putting it later in the file if it has the same specificity, or if you have no other choice use the various tricks available to jack up the specificity.
Having said that, overall this CSS seems to be poorly structured, verbose, and inefficient.
.app.programEditor .actions .widget.bt-flat > .bt-flat-icon {
First, if .app is a class applied to your entire application, it is probably not necessary. If .actions only occurs within .app.programEditor, then the latter is not necessary at all. If .bt-flat can only apply to widgets, then instead of widget.bt-flat you can just write .bt-flat. If .bt-flat-icon can only occur within .bt-flat, as seems likely, then .widget.bt-flat may not be necessary. And so on. In general, instead of writing down every single class in the HTML hierarchy in your CSS rules, try to limit selectors to those necessary to unique select the element you want. In this case, for example, it is possible your rule could be written as simply as (just an example):
.programEditor .actions .widget > .bt-flat-icon {
Second, the magic numbers 145 and 19 are a massive code smell. They are probably connected to other magic widths and heights elsewhere in the CSS, and would have to be changed if those change. What do the 145 and 19 mean? Perhaps they are actually a percentage of some underlying dimension. In other words, maybe some element is 160 pixels wide, and we want to place the icon to the upper right. In that case, instead of hard-wiring the 145, you can either use a percentage, or specify a right property, or use the transform property perhaps, so no matter how the width changes--such as with the introduction of .col2--the icon remains in the right place with the original rule.
You can simply change it to position:static this is just a demo. Otherwise, if you understand concept of Specificity very well, then there was no need for this question.
$('#change').click(function() {
$('.one').css("position", "static");
$('.one').text("Position changed to Static")
});
.container {
width: 90%;
margin: 50px auto;
position: relative;
border: 1px solid #000;
display: block;
height: 200px;
overflow: hidden;
}
.one {
width: 150px;
height: 150px;
background: tomato;
position: absolute;
left: 118px!important;
top: 30px!important;
display: block;
color:white;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>
<div class="container">
<div class="one">
Positioned using absolute or relative</div>
</div>
<button id="change">Change CSS</button>
If many rules exist, the first one takes precedence, but if the last one is more specific, it will override the first one. BUT if the first one is less specific AND has !important that one will take precedence. :) To make matters more complicated, if both rules has !important the most specific rule will take precedence.
So the easy solution here, if you cannot change the already existing rule, just add !important to the code you can edit. If that doesn't work, try to get your code processed earlier in the code than the other one.
.app.programEditor .col-2 .actions .widget.bt-flat.programs > .bt-flat-icon {
left: 40px !important;
top: 40px !important;
}
At the moment, my usual approach to supporting right-to-left (RTL) languages in a template is to simply add a .rtl class to the body tag, then go through all my existing left-to-right CSS and add left/right overrides as appropriate.
For example, my site menu might be positioned like so by default as below:
.site-nav {
position: absolute;
left: 0;
top: 0;
}
...and then manually overridden for RTL languages this way (using some template logic at a CMS level to add the .rtl class to body):
.rtl .site-nav {
left: auto;
right: 0;
}
My issue is that this seems labour-intensive and not very effecient. I was wondering what solutions others might have come up with to make this simpler.
As an aside, I'm using a Compass environment to generate my CSS. But I don't know how to escape back from the current nesting to write a .rtl modifier adjacent to the current element's default styles. This in theory would be extremely useful, however, but I simply don't know if it's possible to perform a lookup all the way back to the body element or not whilst within a deeply-nested Sass rule.
Add your .rtl-class whereever you want to change the textflow. Even when you don't want to change it (for "normal" languages).
Don't use the class in your default css-file.
Add a css-file which only includes
.rtl {
left: auto;
right: 0;
}
whenever you have a rtl-language. In case you want all your divs to behave that you you could replace .rtl with div as well.
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.
So let's say I have the following in 'foo.css':
.border { border : solid 1px; }
#foo { color : #123; }
#bar { color : #a00; }
Now let's say that I have two divs I want borders for, so I do:
<div id="foo" class="border">Foo</div>
<div id="bar" class="border">Bar</div>
This works fine, but I find that when defining #foo and #bar in my css file, I would rather give them the characteristics of .border than give the div's the class, like so:
.border { border : solid 1px; }
#foo {
<incantation to inherit from .border>
color : #123;
}
#bar {
<incantation to inherit from .border>
color : #a00;
}
and then my html would just be:
<div id="foo">Foo</div>
<div id="bar">Bar</div>
Anybody know what that magic incantation is?
That is not supported by css. The best you can do is something like:
#foo, #bar, .border { border : solid 1px; }
#foo { color : #123; }
#bar { color : #a00; }
You might be interested in mixins with Sass. Sass lets you write css style sheets in a more efficient way, using tricks like this. Mixins let you define a group of attributes (say, to do with borders), and then include those attributes within certain css classes.
As Wsanville said, you can't use the class.
But normal CSS inheritance does work - say if your html was
<div class="border">
<div id="foo">
hello
</div>
<div id="bar">
world
</div>
</div>
You could say
.border {border: 1px solid #f00;}
#foo {border:inherit;}
Which in some cases might be good enough
If you're looking to push your CSS further instead of using some of the tricks outlined in earlier posts, you should look into CSS Compilers. They take CSS-like code you've writen, usually CSS with a few tricks added in, and turn them into normal CSS for the web.
David Ziegler wrote about some of the cool featured CSS compilers offer:
Variables - Good programmers don’t like to hardcode. In many cases you can avoid this in CSS by using good inheritence, but sometimes it’s unavoidable. With variables, changing your color scheme means updating one variable instead of 13 attributes.
Math - This goes hand in hand with variables. Say your left column is 100px, your right column is 500px, and your wrapper div is 600px. Well, maybe you decide to change it to 960px. Wouldn’t it be awesome if the width of your columns adjusted automatically? The answer is yes.
Nested Styles - This is probably the most important. CSS is flat, which means complex sites end up with CSS that is a pain to go through.
You can read about popular compilers in his blog post on the subject, or do some searching and find one that works best for you.