I have two style sheets which conflict with each other on several counts. Because I'm using 5, 6, and in some cases 9 or 10 complete plug-ins, each with three or fours style sheets, along with my own, conflicts arise everywhere. What is the best way to fix this problem? Is the only option to go in and modify the selectors of all of the plug-ins?
Edit: The problem is that all the plug-ins use their own style sheets which conflict with each other. The optimal, but probable impossible without modifying all the selectors, solution would to easily localize the style sheets to certain parts of the page.
keep in mind some very basic tips for style overriding:
First, try to avoid generic class names and id's that are certain to be used by other sources.
Second, !important can override styles, but should only be used in ways that make sense...
Third, the hierarchy of the "cascade" part of css is down -> out:
So
#header a{
color:#fff;
}
#header div a{
color:#000;
}
#header div.some-class a.active{
color:#ff0000;
}
The bottom selector will take priority no matter where it is placed because it is targeted specifically with a horrid chain of selectors. So perhaps you need to write your css in a way that reduces the chances of being overwritten by other sources.
The best way is definitely not to modify the selectors of the plugins unless you wrote the plugins yourself. You should modify your own classes/ids/css files to... not have conflicts.
Make your CSS as specific as possible, I would not modify the plugin unless you are confident you know your way around.
Wrap each section that you want to localise in its own div, with a specific and appropriate ID. Then mod each selector in the stylesheet to be preceded by #specificSectionID . With find/change in a decent code editor, you'll be done in five minutes. Example:
.headersection a {color: #DDD; background: transparent}
//becomes
#topSection .headersection a {color: #DDD; background: transparent}
Related
I have a weird one that I can't seem to be able to figure out. I am new to CSS and decided to use bootstrap to assist with styles etc.
the problem I have is when I try to assign two classes to a div element, 1 being the bootstrap column and another from my own stylesheet.
the code from my stylesheet seems to be ignored in some cases. now i have taken that one bit of code and css out and put it into the jsfiddle but it works fine. its only when combined with the rest of the html does it seem to have issues. also note that if i use inline styles it works...
I copied the entire code to js fiddle now so that you guys can replicate the issue. the section I am having issues with is the 4 images that are side by side
class="services-boxes"
anyway any assistance will be appreciated, as well as general feedback as I am new to this all! :)
https://jsfiddle.net/d9bv0grx/1/
Due to the way cascading style sheets work it (styles are be applied in order AND by specificity). It is most likely that styles you are expecting to see are being overridden by specificity.
Give this guide a read.
An example is that for <div id="selector">
#selector {background-color:red;}
div {background-color:green;}
You can expect to see a div with a red background, even though the green background is set afterwards, the id selector has greater specificity.
Then try and alter the specificity of your selectors in your css so that they will take precedence over in bootstrap.
Also just going to add, you have casing issues - you declare the class with lowercase in css, capitalised in your html.
You also have syntax issues in your css. Your css should look like:
.services-boxes {
padding:0;
max-height:500px;
width:100%;
}
Sort all this and you should be golden! jsfiddle
Looks like a combination of syntax errors. Your style should be declared like this:
.services-boxes {
padding:0px;
max-height: 500PX;
width:100%;
}
Note that the class is all lowercase (which should match style where declared which is currently Services-Boxes), a colon separating property and value (you has used = in some instances) and one set of curly braces per declaration (the above class .logo-image has 2 closing braces). Just a bit of formatting should see your code recognised
When you don't have total control over your HTML, you can use the !important property in css to give a priority to your styles.
.services-boxes {
color: red !important;
}
However keep in mind that you have to avoid the !important property as much as possible and do not use it unless you can't do it any other way.
I am working on a website for a client, and she has Visual Composer installed. For a post grid, I need to assign a different color to each post title. My approach was to find the grid-item container and append :nth-child to it, then direct it to the custom css class I really want to apply the different color to.
Example code, based on the actual code:
.vc_grid-item:first-child > ... > vc_gitem-zone-a > ... > .custom-post-title {
background-color: red;
}
.vc_grid-item:nth-child(2) > ... > vc_gitem-zone-a > ... > .custom-post-title {
background-color: green;
}
.vc_grid-item:nth-child(3) > ... > vc_gitem-zone-a > ... > .custom-post-title {
background-color: blue;
}
Strangely enough, this technique worked fine for the hover-text effect over the post's featured image.
I tried nth-of-type, but had little luck with it. It would work, but only parsed the first or second of type, applying the same color to all three divs.
I have tried every path permutation I can think of, but not a single one works.
Trying to track down a path through the endless divs that Visual Composer generates is practically impossible. Using the code inspector (Google Chrome), I found dynamically generated classes, classes injected as inline styles, and classes that were in the rendered HTML, but nowhere to be seen in the inspector. After several hours of carefully mapping out different "class paths" to make this work, I gave up out of sheer frustration.
Interestingly enough, the Visual Composer documentation is clear that, by adding custom css classes through its UI, custom styling is easy and straightforward. My experience is that this is true--if you want to apply the same color to all your divs in the post grid. Try customizing each grid-item independently, though, and it's a whole different ball game...one that may be impossible to win.
Any ideas as to how I might get this to work without resorting to some kind of hacky JavaScript black magic?
If you want to target a series of elements with the class .vc_grid-item, what you need is :nth-of-class... and it doesn't exist.
If you state the type of element, then you can use :nth-of-type:
div:nth-of-type(3).vc_grid-item > ... > .custom-post-title {background-color: blue;}
N.B. This sort of thing will be much easier when CSS4 :nth-match arrives.
Then, in this kind of situation, you will be able to use:
:nth-match(3 of '.vc_grid-item')
Further Reading: http://www.w3.org/TR/selectors4/#selected-child-index
child point to tbody in table
you must use tbody in selector for pointing child to tr
.vc_grid-item tbody :nth-child(1){
background-color: green;
}
.vc_grid-item tbody :nth-child(2){
background-color: blue;
}
I am working on a page - click here for link. The icons are all supposed to have the font size of .side-icon:
.side-icon{
font-size:28px;
}
BUT a style in font-awesome.css is overriding this, no matter where I include the library in the layout.
At the moment I have included the css in the top of a work around sheet (font-awesome-fix.css) using an #import, but I cannot get the 'font: normal normal normal 14px/1 FontAwesome;' to disappear at all.
Please help!
Make your selector more specific :
.side-icon.fa
See here how the priorities of the selectors are calculated.
Hey you should target the before element :
.side-icon:before{
font-size:28px;
}
maybe try adding an id to the specific .side-icon that you need to change the font on.
CSS:
.side-icon #id_goes_here{
font-size:14px;
}
Hope this helps!
The very helpful "!important" usually helps me solve issues like this, or at least determine the root issue:
.side-icon{
font-size:28px !important;
}
Try using more specific css to override the other styles. This may include adding classes or ids so you can chain them together to override.
Examples:
.side-icon.foo{styles}
#bar.side-icon{styles}
If that still doesn't work, you may want to use the !important override to add another layer of specificity. I wouldn't reccomend jumping to use it immediately, but that's mostly because i prefer to code more specifically than using !important everywhere.
Example:
.side-icon{style:value!important;}
If neither of these work, there may be other issues messing with your styles.
This is because of the CSS specificity rule kicks in:
When selectors have an equal specificity value, the latest rule is the
one that counts.
So including your file at the topmost location does not help because the font-awesome.css gets included later and since both .side-icon and .fa are classes on the same element, .fa defined by font-awesome.css got picked up by the browser because .fa was the latest font-size definition.
So, in order to overcome this problem, include your font-awesome-fix.css after font-awesome.css or you could use inline style after the line that includes font-swesome.css
<style>
.side-icon {
font-size: 28px;
}
</style>
or override the .fa font declaration in the same file (if you have control over it) by ensuring that the font-size override comes after the original declaration
or use one of the several ways to become more specific (see CSS specificity[1])
[1] http://www.w3.org/TR/selectors/#specificity
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
It seems there are two major schools of thought on how to structure CSS and HTML. I was taught to keep the HTML as clean as possible, and all things stylistic should be on the stylesheet. This has served me well thus far, but with this approach I often notice redundancies and inefficiencies.
I read up on the atomic approach, and I really like the idea. It seems to be the method I naturally gravitate toward anyway.
My question:
Which way is really faster, considering the two following blocks of code:
HTML:
<div class="main">
<h1 class="m-10 theme-c1">header with margin and theme color 1</h1>
<p class="fz-1 theme-c1 m-10">paragraph with font-size 1em.</p>
<div class="m-10">
<p class="fz-1 m-10">blah</p>
<p class="sub-paragraph">Sub paragraph</p>
</div>
</div>
Stylesheet:
/*margin-left rule*/
.ml-10 {margin-left:
/*font-size rule*/
.fz-1 {font-size:1em}
/*theme color*/
.theme-c {color: #333};
/*display rule*/
.dps-blk {display: block}
/
/*sub paragraph styles*/
.sub-paragraph {
margin-left: 10px;
font-size: 1em;
font-color: #333;
}
Elements in the HTML above all get whatever style they need, and the styles above are non-descendants except for .sub-paragraph.
So is it faster for each element to cherry pick which styles it needs, or is it better to just give it a chunk of styles (like for .sub-paragraph)? With .sub-paragraph, I can see how it only takes one match to get all the styles. The trade off, however, is that there isn't much else you can do with that set of styles except use it on sub-paragraph, or override some of its properties with another rule when applied to something else.
I'm think with these two approaches, it's a decision on whether to the cost on data size or on processing time.
Edit
I appreciate all the feedback. I forgot to mention that I'm specifically interested in the processing speeds of the different approaches.
This is interesting nonetheless.
If you were to begin cherry picking individual styles, you would end up with a stylesheet like:
.red{ color: red; }
.green-background{ background: green; }
.w500{ width: 500; }
.ml20{ margin-left:20px; }
Which is not very maintainable.
It sounds like what you are looking for is a way to extend certain classes (i.e. .sub-paragraph) with pre-existing classes, adding the styles of other classes into .sub-paragraph. SASS's .extend directive is a great way of doing this.
Sass and other preprocessors are great at merging the ideas of maintainable code and semantic code together.
Edit 1:
If you are looking into which method (more classes/less properties or less classes/more properties) is faster, I would suggest doing some testing with Chrome Dev Tools' Timeline. The two methods of coding aren't the only thing that are going to affect how fast a page renders/paints, so it is always a good idea to test these if you are concerned about speed.
I organize my CSS by grouping certain types of classes together. When creating CSS classes I ask myself, am I going to reuse this class definition for anything else? Is it logical for me to separate this class' definition, will someone who has to read this after me want to shoot themselves?
Basically I would say, go for maintainability, an extra 1Kb on your Css will not choke anyone.
CSS is designed to use classes for certain groups of styles. The .sub-paragraph method is usually way better than the seperate classes method. If you are going to assign classes for each style seperately, you might as well just use inline styles, via the style attribute. You should usually try to avoid that for maintenance reasons though.
I think there is a place for both.
I don't feel that the abstraction belongs at class names like .p1-gr-brdr, though.
If you're writing very tightly-composed, atomic HTML partial-templates (for things like AngularJS directives), then you'd likely get more mileage out of .title, .subtitle, .just, .content, where you can specify very specific output for those components.
Changing those components will be very simple and straightforward, as they're so compact and self-contained.
And if you find yourself in a position where you need to override one, to compose an inherited class, then you either have the option of composing a new class-name, which now might not be 100% semantic/generic (".big-green-subtitle"), but is still 100% self-contained for those moments where you want your special-cases to feel loved, too...
...or you can then specify behavior with a second-level selector.
If your .header has a padding, but you don't want your .update > .header > .subtitle to be subject to that padding-bottom, on mobile-phones, in landscape orientation, on Tuesdays, then you can simply have an exception which states .update > .header { padding-bottom : 0; }.
Otherwise the cascade will continue as normal, and things will either pile on top of one another, or you will cancel out side-effects with specialized classes which cover the same properties...
Otherwise, I don't see why all CSS sheets don't look like:
.p1-br { border-width : 1px; }
.p2-br { border-width : 2px; }
.p3-br { border-width : 3px; }
.p4-br { border-width : 4px; }
.gr-br { border-color : green; }
.lgtgr-br { border-color : lightgreen; }
.sfmgr-br { border-color : seafoamgreen; }
.aqmr-br { border-color : aquamarine; }
.em1-wd { width : 1em; }
.em2-wd { width : 2em; }
.em3-wd { width : 3em; }
.rm1-wd { width : 1rem; }
.pc1-wd { width : 1%; }
...et cetera, until you've written out every atomic option you could possibly want, for any theme your project (and all of its components) might want to support, across all platforms.
That seems like a terrible use of your day, to write a unique class-name for every possible edge-case out there:
<div class="pos-rel
p1-br
p18-ng-tp
mrpc12-br-r
lggr-bg
bg-im-spr-id-123
pc15-bg-im-algn-lf
ofl-x-hd
ofl-y-aut
brd-bx">
Seems hefty for a single div, for instance.
This would not, however, be a bad idea, if you could write CSS rules, give them to classes, where you expect flexibility, and later had the hard-numbers to those rules.
Such that, say, you write out a class which expects to treat height in rems, margins in percents, border-radius in ems, will take a background-colour and an image-sprite (say it's a backdrop container for a corporate/retail site, with a watermark and logo, where other content will scroll above it).
Now you want to reuse that set of classes on the same component, but for a different client...
It would help if you could simply have some variables, which could live in a separate file, and be referenced by your classes, so that your units don't necessarily need to change, but you can modify all of your hard-coding stuff in one or two places, and swap different variable values in for different clients as easily as pointing at a different sheet...
...but that's what SASS already does, if you take the time to sit down and figure out how you want to engineer something, and make your build process adhere to that desired outcome.
I have long wanted to be able to include one style class within another. For example
med-font {
font-size:12px;
}
#message a {
style: med-font;
color: blue;
...
}
/* lots of other styles, some of which use med-font */
Obviously this is a stripped down example, but the key point is that all those anchor tags within #message shouldn't need explicit classes or ids. For now I either duplicate the font-size in each class that needs it or add classes to things that wouldn't otherwise require it. And since I want to easily control the font-size from one place, I usually start adding classes.
Another solution is to split up the definition of "#message a" in this example (below). This works ok for small projects, but for larger projects this is actually my least favoured solution. It makes site maintenance very difficult if you have many classes split apart and scattered around large style files.
med-font, #message a {
font-size:12px;
}
#message a {
color: blue;
...
}
So my question is two parts: 1. Does this annoy other people? 2. Does anyone know if this feature is/was being considered for CSS3?
Edit: Adding example of html body and more details...
The main point is that adding a class attribute to the 20 anchors below to set their font size is tedious.
<div id="username" class="med-font">schickb</div>
<div id="message">
<div id="part1">
text
<!--lots more tags and say 6 anchors -->
</div>
<div id="part2">
text
<!--lots more tags and say 8 anchors -->
</div>
</div>
<div id="footer"> <!-- footer anchors should be a smaller font-size -->
lala
<p class="med-font">Company Name</p>
<!-- other tags and 3 more anchors -->
</div>
Remember, an important goal is to have one place where "med-font" is declared so that it is easy to adjust. In my actual project, there are small, medium, and large font styles. I only want one declaration for each so that I don't have to search through the css to say change 12px to 11px.
The best solution currently is to add the "med-font" class to all the anchors in the body, and the "small-font" class to all the anchors in the footer. But I'd much rather do what I showed originally, and simply include the desired font in the styles for "#message a" and "#footer a".
Summary: I want CSS to be more DRY
No, it does not annoy me, because you can use multiple classes for an element and BOTH will match:
.idiot {
color:pink;
text-decoration:underline;
}
.annoying {
font-weight:bold;
}
/* and if you want to get REALLY specific... */
.annoying.idiot {
background-image('ann.jpg');
}
...
<div class="annoying idiot">
Ann Coulter
</div>
Personally, I find this a much more versatile solution to the problem. For example, in jQuery (or in another framework), you can add and remove these classes -- most commonly, you'll add a "selected" class or something that might do something like highlight a table cell, and when someone clicks to toggle it off, you just remove the "selected" class. Uber-elegant IMO.
In response to your edits, all you would have to do to remove the CSS from all of your A links would be to do something like this:
#message > div > a {
font-size:12px;
}
#footer > a {
font-size:10px;
}
Where the > symbol means "is a child of"
or, more generally (but this would also match an A directly inside #message and anything deeper -- the space means "is any descendant of")
#message a {
font-size:12px;
}
#footer a {
font-size:10px;
}
This is exactly what the Compass framework is good at. Sass allows variables, which makes coding/maintaining stylesheets very easy and a pleasant experience.
Have a look at SASS, which might do what you want. It allows for nested CSS structures, which can then be converted to CSS. I think.
In my opinion, the fact that you can't do this is perfectly OK because your CSS should remain as straightfoward as possible. On of the greatest advantage of CSS, as mention in Micheal Kay's XSLT reference (yeah xstl... I know), is that CSS is very simple and incredibly easy to understand.
I don't have to look at multiple places to know the styling effects of putting a class on a tag (well maybe but still).
So for me it would be a no for number 1. And as for 2, it has been discussed and I don't think it will be part of the standard.
css is not a programming language, it was never meant to be and (at this stage) never will be. what you're talking about has been discussed plenty of times before in W3C and WHATWG
oh and to answer 1) it doesn't annoy me
No, It doesnt annoy me, IE6 annoys me :)
It would be a useful feature to have, especially in a css framework, however, are we not being encouraged to lump all our css into one file now for "optimisation". I havent heard any rumours about such a feature in css3, but there is still a way to go on that spec yet, so who knows, it could make it in if you make enough noise now!