In our application we use Bootstrap and there are multiple CSS files that are used.
Recently, I had a issue where there was a border created around a input box. The border for the CSS for input types were over-ridden in a particular CSS file.
I tried to use the Chrome DEV tools to identify which CSS file that input box was picking (for color) but for some reason it was not identifying the correct CSS files. For borders, shape and size it was mentioning it was inheriting from the parent but it never mentioning which is the parent CSS file.
Is there a better tool which correctly points the CSS that the component is using?
Is there a better tool which correctly points the css that the
component is using?
Firebug is great & very well developed. But works only in FireFox, which should not be a big deal for your basic CSS debugging purposes. In general there is no one good tool to debug things like this. You will always be jumping around from tool to tool to get things right. It’s just the nature of front-end web development.
But in general, might not have to even touch the parent CSS to deal with this issue. Just target the element in CSS—if it is not already being targeted—and use !important to force your new setting to override others from parent styles.
However, for balance, an "!important" declaration (the delimiter token
"!" and keyword "important" follow the declaration) takes precedence
over a normal declaration. Both author and user style sheets may
contain "!important" declarations, and user "!important" rules
override author "!important" rules. This CSS feature improves
accessibility of documents by giving users with special requirements
(large fonts, color combinations, etc.) control over presentation.
Here is an example code that would force outline: none to all input elements:
input {
outline: none; !important
}
You can even add border: 0px solid; to the mix as well:
input {
border: 0px solid; !important
outline: none; !important
}
I tried to use the Chrome DEV tools to identify which CSS file that input box was picking (for color) but for some reason it was not identifying the correct CSS files. For borders, shape and size it was mentioning it was inheriting from the parent but it never mentioning which is the parent CSS file.
In general Chrome Developer Tools shows exactly which .css-files are used and from which element the styles are inherited.
Can you maybe provide an example with your exact problem?
Related
I've developing an app with Vue, and a third-party template, and dynamic plugins, and all kinds of trickery. I'm have a really hard time with the CSS.
Often I need to style particular element on the page, an <input> for example, and I can't figure out how to write a selector that actually works. The input may have been created dynamically by some Javascript and may have had CSS applied programmatically.
So I go to Firefox Web Developer, click on the element, and see a bunch of CSS classes. I create a rule:
.myCustomClass {
color: red;
}
put myCustomClass in the class="" tag in the <input>, and... nothing.
I'm thinking I need to prefix it like this:
.someOuterClass .someInnerClass .myCustomClass {
color: red;
}
but that rarely works. Sometimes I give up and add !important. Sometimes that works, and sometimes it doesn't.
So my question is, can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?
I've read about specificity, but it's not helping.
Specificity is a PITA sometimes, especially when other 3rd party libraries are adding stuff to the mix.
Here are a few things you can try:
Make sure to add your styles to the END of the CSS. Theoretically, you can affect the order Webpack includes CSS (I've never tried it)
Add an ID not a class to a wrapper outside the elements you want to change. Then reference this ID in the CSS chain eg: #myAppID .className .subClassName {} Basically ID's are stronger than classes in CSS specificity. I would try to do this at a page/view level to make life easier.
If elements are already getting classes (as you see them in the inspector) try to reuse those classes with your "override" CSS. If the classes are modularized (Have a random suffix like someClass__34xft5) you shouldn't use those exact classes since they can change if the source is recompiled. In that case, use a "matching" selector [class^=”someClass__”] to match any selector with that prefix.
Not sure how deep you want to go, but here's an article about overriding Amplify-Vue prebuilt styling.
One caveat, if the CSS is being added inline via javascript somewhere, it's going to be very hard to override. You may want to use !important in conjunction with the above.
"...can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?"
Probably, but why bother? You're already adding class attributes to elements. Why not add inline style attributes instead? Adding a bunch of classes or ids just to create a specificity chain to touch up styles is pretty messy...inline styles are barely if at all worse and are clearer to understand.
Inline attributes are the most specific CSS instructions you can give.
Okay, this is a gross oversimplification, but I have a javascript application to help people develop webpages. It has its interface superimposed over the page that is being developed, and it all works fine, apart from one thing.
If the div class used in the interface is used by the webpage that is being developed, the interface' embedded stylesheet overrides the properties of the webpage!
This happens on jsfiddle, the embedded css is takes precedence over the external css.
JSfIDDLE
external css:
.color {
color: green;
}
Index.html:
<style>
.color {
color: blue;
}
</style>
<div class="color"> Text to be coloured </div>
When run, the text is blue. If someone could make the text turn green, I think it would demonstrate how to overcome the problem.
Obviously, one way to fix this would be to change the interface classes and rules to something like this:
<style>
.color_interface {
color: blue;
}
</style>
<div class="color_interface"> Text to be coloured </div>
And make them unique, but the project has hundreds of css rules, and I'm just wondering if there's a better way, and a safer way (there's still a small chance someone has a rule "color_interface") to do nullify css rules, so they won't contaminate the page.
I'm thinking the only way to do it is probably a 'reset' stylesheet concerning my rules, setting them all back to their defaults. Is there a way to do this dynamically with jquery, maybe?
What you're witnessing is CSS by design. Specifically, specificity.
If your goal is to release some kind of library that can be used publicly and you want to avoid naming conflicts, I think a fair practice is to simply namespace your selectors, e.g., .starkers-color { color: blue; }. That won't necessarily avoid specificity issues, but it should prevent against having your selectors overridden by implementors.
If you inspect the JSFiddle page you'll see that the reason for it not working is that your inline style definition is placed in the body where it has no effect.
The CSS rules you specify is instead placed as an inline style in the head element.
To your problem:
Again, referring to JSFiddle, would it be possible to load the page in development inside an iframe? This would mean you get the separation you require.
This is because the order of the CSS when rendering. Your include is at the top of the page but your style tags are below that, meaning your style tags will alway take precedence over you include at the top. You could try adding an important to you css includes but this is majorly hacky and could create a whole load of new issues.
I am trying to write a jQuery plugin that can be ported to any site.
What my plugin does is create a div and applies a style to it.
It works well in standalone but when I put it into the context of a site, there is a css class that it is inheriting from. The thing is, I can't modify the web site's existing CSS... so I need a way to "prevent inheritance" (which I know is technically not possible).
I have tried the !important flag on the specific styles that are causing problems, but to no avail. I am looking for a point in the right direction more than specific code, so that's why I'm not posting all of my code...
The other thing is that I do not want to use an iframe instead of a div because I need to be able to provide the ability for a form to interact with my div, potentially.
However, the two css classes from the web site (which I can not modify) that are causing my problems are:
* {
font-weight: inherit;
font-style: inherit;
border: 0 none;
outline: 0;
padding: 0;
margin: 0;
}
html {
width: 100%;
height: 100%;
font-size: 10px;
}
CSS isn't inheritance-based, but rather "cascading" (it's the first C in "CSS"). Understanding that, there are a few ways you could work around the issue you describe:
1) Add inline styles to your element via script. Inline styles take precedence over CSS rules, either from classes, ids, or elements.
2) Add your own CSS file programmatically. CSS cascades in the order the rule appears in the document. You can write a CSS link element to the bottom of the page to include your plugin's CSS rules. Since these are presumably lower or "later" in the document than the site's CSS, your rules will take precedence.
3) Write a style tag to the bottom of the document programmatically. Same concept here as #2, but without an external file.
I would personally tend toward #1. If you want your plugin to be consistent in appearance no matter what else is going on, no matter what site it is used on, the only way to be sure is to apply your styles inline.
That said, there's value in making your plugin's interface customizable by using CSS classes. Maybe you're trying to take something away that you shouldn't. For instance, if the entire site uses a Serif font, and you're forcing a Sans font on your plugin's UI, your plugin's look and feel is now at odds with the site. That could be a deal-breaker when someone is considering your plugin... customization is a good thing in the world of reusable code, and CSS is the way to make it happen.
This question already has answers here:
What are the implications of using "!important" in CSS? [duplicate]
(9 answers)
What does !important mean in CSS?
(5 answers)
Closed 4 years ago.
Consider:
#div p {
color: red !important;
}
...
#div p {
color: blue;
}
I understand how !important works. In this case the div will render red because now it has priority (!important). But I can't still figure out an appropriate situation to use it in. Is there an example where !important saves the day?
This is the real life scenario
Imagine this scenario
You have a global CSS file that sets visual aspects of your site globally.
You (or others) use inline styles on elements themselves which is usually very bad practice.
In this case you could set certain styles in your global CSS file as important, thus overriding inline styles set directly on elements.
Actual real world example?
This kind of scenario usually happens when you don't have total control over your HTML. Think of solutions in SharePoint for instance. You'd like your part to be globally defined (styled), but some inline styles you can't control are present. !important makes such situations easier to deal with.
Other real life scenarios would also include some badly written jQuery plugins that also use inline styles...
I suppose you got the idea by now and can come up with some others as well.
When do you decide to use !important?
I suggest you don't use !important unless you can't do it any other way. Whenever it's possible to avoid it, avoid it. Using lots of !important styles will make maintenance a bit harder, because you break the natural cascading in your stylesheets.
Overwriting the Style Attribute
Say in the example that you are unable to change the HTML source code but only provide a stylesheet. Some thoughtless person has slapped on a style directly on the element (boo!)
div { background-color: green !important }
<div style="background-color:red">
<p>Take that!</p>
</div>
Here, !important can override inline CSS.
This is a real, real life scenario, because it actually happened yesterday:
Z-index in jQuery dialog. Autosuggest list not displayed properly
Alternatives to not using !important in my answer included:
Hunting down in JavaScript/CSS where a certain elusive property was being applied.
Adding the property with JavaScript, which is little better than using !important.
So, a benefit of !important is that it sometimes saves time. If you use it very sparingly like this, it can be a useful tool.
If you're using it just because you don't understand how specificity works, you're doing it wrong.
Another use for !important is when you're writing some kind of external widget type thing, and you want to be sure that your styles will be the ones applied, see:
Appended control's CSS
You generally use !important when you've run out of other ways to increase the specificity of a CSS selector.
So once another CSS rule has already dabbled with Ids, inheritance paths and class names, when you need to override that rule then you need to use 'important'.
!important is somewhat like eval. It isn't a good solution to any problem, and there are very few problems that can't be solved without it.
I have to use !important when I need to overwrite the style of an HTML generated by some JavaScript "plugin" (like advertising, banners, and stuff) that uses the "style" attribute.
So I guess that you can use it when you don't control the CSS.
Strictly speaking you shouldn't need to use !important if you've structured your CSS well and don't have too many degrees of specificity.
The most appropriate time to use !important is when you have one exceptional style that you want to style outside of your site's normal cascade.
Using !important is generally not a good idea in the code itself, but it can be useful in various overrides.
I use Firefox and a dotjs plugin which essentially can run your own custom JS or CSS code on specified websites automatically.
Here's the code for it I use on Twitter that makes the tweet input field always stay on my screen no matter how far I scroll, and for the hyperlinks to always remain the same color.
a, a * {
color: rgb(34, 136, 85) !important;
}
.count-inner {
color: white !important;
}
.timeline-tweet-box {
z-index: 99 !important;
position: fixed !important;
left: 5% !important;
}
Since, thankfully, Twitter developers don't use !important properties much, I can use it to guarantee that the specified styles will be definitely overridden, because without !important they were not overridden sometimes. It really came in handy for me there.
The use of !important is very import in email creation when inline CSS is the correct answer. It is used in conjunction with #media to change the layout when viewing on different platforms. For instance the way the page looks on desktop as compare to smart phones (ie. change the link placement and size. have the whole page fit within a 480px width as apposed to 640px width.
This is a real-world example.
While working with GWT-Bootstrap V2, it will inject some CSS file, which will override my CSS styles. In order to make my properties to be not overridden, I used !important.
I'm using !important to change the style of an element on a SharePoint web part. The JavaScript code that builds the elements on the web part is buried many levels deep in the SharePoint inner-workings.
Attempting to find where the style is applied, and then attempting to modify it seems like a lot of wasted effort to me. Using the !important tag in a custom CSS file is much, much easier.
I am planning to use !important for a third-party widget meant to be embedded in a large number of websites out of my control.
I reached the conclusion !important is the only solution to protect the widget's stylesheet from the host stylesheet (apart from iframe and inline styles, which are equally bad). For instance, WordPress uses:
#left-area ul {
list-style-type: disc;
padding: 0 0 23px 16px;
line-height: 26px;
}
This rule threathens to override any UL in my widget because id's have strong specificity. In that case, systematic use of !important seems to be one of the few solutions.
You use !important to override a css property.
For example, you have a control in ASP.NET and it renders a control with a background blue (in the HTML). You want to change it, and you don't have the source control so you attach a new CSS file and write the same selector and change the color and after it add !important.
Best practices is when you are branding / redesigning SharePoint sites, you use it a lot to override the default styles.
This question already has answers here:
What does !important mean in CSS?
(5 answers)
Closed 3 years ago.
I've been working on a website for a few months, and a lot of times when I've been trying to edit something, I have to use !important, for example:
div.myDiv {
width: 400px !important;
}
in order to make it display as expected. Is this bad practice? Or is the !important command okay to use? Can this cause anything undesired further down the line?
Yes, I'd say your example of using !important is bad practice, and it's very likely it would cause undesired effects further down the line. That doesn't mean it's never okay to use though.
What's wrong with !important:
Specificity is one of the main forces at work when the browser decides how CSS affects the page. The more specific a selector is, the more importance is added to it. This usually coincides with how often the selected element occurs. For example:
button {
color: black;
}
button.highlight {
color: blue;
font-size: 1.5em;
}
button#buyNow {
color: green;
font-size: 2em;
}
On this page, all buttons are black. Except the buttons with the class "highlight", which are blue. Except that one unique button with the ID "buyNow", which is green. The importance of the entire rule (both the color and font-size in this case) is managed by the specificity of the selector.
!important, however, is added at a property level, not a selector level. If, for instance, we used this rule:
button.highlight {
color: blue !important;
font-size: 1.5em;
}
then the color property would have a higher importance than the font-size. In fact, the color is more important than the color in the button#buyNow selector, as opposed to the font-size (which is still governed by the regular ID vs class specificity).
An element <button class="highlight" id="buyNow"> would have a font-size of 2em, but a color blue.
This means two things:
The selector does not accurately convey the importance of all the rules inside it
The only way to override the color blue is to use another !important declaration, for example in the button#buyNow selector.
This not only makes your stylesheets a lot harder to maintain and debug, it starts a snowball effect. One !important leads to another to override it, to yet another to override that, et cetera. It almost never stays with just one. Even though one !important can be a useful short-term solution, it will come back to bite you in the ass in the long run.
When is it okay to use:
Overriding styles in a user stylesheet.
This is what !important was invented for in the first place: to give the user a means to override website styles. It's used a lot by accessibility tools like screen readers, ad blockers, and more.
Overriding 3rd party code & inline styles.
Generally I'd say this is a case of code smell, but sometimes you just have no option. As a developer, you should aim to have as much control over your code as possible, but there are cases when your hands are tied and you just have to work with whatever is present. Use !important sparingly.
Utility classes
Many libraries and frameworks come with utility classes like .hidden, .error, or .clearfix. They serve a single purpose, and often apply very few, but very important, rules. (display: none for a .hidden class, for example). These should override whatever other styles are currently on the element, and definitely warrant an !important if you ask me.
Conclusion
Using the !important declaration is often considered bad practice because it has side effects that mess with one of CSS's core mechanisms: specificity. In many cases, using it could indicate poor CSS architecture.
There are cases in which it's tolerable or even preferred, but make sure you double check that one of those cases actually applies to your situation before using it.
!important forces the statement to always apply, doing these things:
even if the selector is less specific and lower level, it now beats higher specificity selectors
if there are further occurrences of that statement that would normally override that one, it does not override the important statement any more
Most of the time, !important can be avoided because specificity of selectors handles which one takes effect, which is the idea of cascading styles. However, there are some situations (can't quite remember the exact one) where the specificity isn't that logical and I have to force !important on the statement.
Reasons not to use/avoid !important?
prevents users from using custom stylesheets (which now can't override the rules that are marked as important) which breaks accessibility for some people
makes code more difficult to read because the mind normally takes specificity quite easily, but remembering what is !important makes it harder to read
I think it is important that we touch on this again, here at the end of 2014 when more rules are being added into the working draft, it is so important not to impose restrictions upon your users. I have wrtten this small example to explain a possible scenario in which such a thing takes place. This is taken from a REAL website I have visited on the web, and I see it, sadly, more often than not.
Form Text Editor Fields
You have a website, and your website depends on filling out forms and editing text. To try to minimize eye strain you try to go with a style you think everyone will be okay with, and since your users mainly visit at night, you decide to make your background color to be white, and then make the text color to be black. The form is blank by default, so you type in text (this time) to make sure it works:
...
background-color: black; /* I forgot important here, but it works fine on its own */
color: white !important;
...
A few months later, users complain that white-on-black is too eye straining but the other half love it, what do you do? you add a custom theme that uses !important to override the internal styles so that BOTH parties are happy, which is what it is SUPPOSED to be used for:
...
background-color: white !important;
color: black !important;
...
Now, what happens here? What did you expect. If you properly remember the !important tags in the first set, you would have noticed it didn't work and probably remembered that you needed to delete the !important tags off. BUT you forgot one..
RIGHT, you get white text on white background, and the user can no longer read your webpage at all if they try to use this new style (assuming you kept it).
Of course, You don't realize this because the textbox is empty. And You ASSUME that it will work! (Assumption is a developer's worst enemy, it's right up there with pride and arrogance).
Make and Follow Self Implied Rules
So, the basic rule should be only use !important when designing OVERRIDES to an original complete set of css rules. Remember that it is meant for exceptions and disturbs the natural order and meaning of css in the first place. In MOST cases you will not need to use it at all.
Know How Users Customize Their Colors
With the existence of such tools as extensions and the presence of sites like 'userstyles.org' and it's stylish counterpart, you run the risk of alienating your users by using the !important tag at all! Keep in mind that stylish will not override them.
Never Restrict Your Visitors
If you use !important on a style, make sure you make it possible for the user to turn that style off (and i dont mean via the web browser's internal 'on/off' switch). And for heavens sake don't make it DEFAULT.
Ads
People are less and less using stylish for ad removal, so I don't think protecting ads with !important really is an issue here. It will just annoy someone trying to customize your site.
A little late to this question but it's saying "no matter what other styles are applied, ignore them and use this one". You may find it a little confusing with the ! infront (of the !important) because thats a not operator in javascript but in css it's called a delimiter token that just says to take priority. Heres an example.
Without !important:
.set-color{
color: blue;
}
.set-color{
color: red;
}
outputs RED
!important on bottom attribute (of same)
.set-color{
color: blue;
}
.set-color{
color: red !important;
}
outputs RED (would have been red anyways)
!important on top attribute (of same)
.set-color{
color: blue !important;
}
.set-color{
color: red;
}
outputs BLUE (says ignore red, use blue)
For me, using !important is a bad CSS practice. It disrupts the natural flow in applying the css rules where in properties are applied from top to bottom. With !important, the property will now give priority to the latest important value.
It's just like using the goto keyword in scripts. Though its are perfectly legal, it's still best avoided.
I wouldn't advise you to use it unless it's a necessity, which sometimes might be the case with you, as you're working on an existing project. But try to stay away from it and use as little !important as possible.
The problem is if you use too many of them then one might inadvertently overwrite the other. Your code is also much less legible and anyone who comes after you to maintain this will tear his/her hair apart, as trying to find !important every time you do something in the CSS is a royal pain.
Check this: http://webdesign.about.com/od/css/f/blcssfaqimportn.htm
Well, i think using !important is sometime "must to do job" if you want overdraw wp-plugins default properties.
I used it just today and it was the only way to finish my job.
Maybe is not good way to do something but sometime is the only way to do it.
!important is a factor, That can vain your code for something that is overridden
the ! in it does not mean Logical not, such here it gets disconcerting with that among that code. !important is frequently a colossal mishap in computing.
For Example if you want to make it display: block;
but you've already defined display: none;:
p {
display: none;
display: block !important /*Now overriden*/;
}
<p>Some Paragraph</p>
!important is a best avoided keyword, When to use it, It may be a Influential time, Please click this link to see when to use !important, !important Style Rule - CSS-Tricks
no madder what
The problem with !important is that with CSS you MUST in all cases try to avoid deep selecting (more priority), because in the future you or someone else (often for big projects) will need to override these styles WITHOUT changing the original style and then this one will have limited freedom to do that.
He will need to use !important, too with deeper selector.