I've seen this used once or twice now, where ! mark is put before property name. For example:
!overflow: hidden;
(also, see here)
Can anyone shed some light on what its purpose is?
I can't find any information about it but it is apparently a hack. At least Chrome will not apply the styles where the property names have exclamation marks in them. What's interesting to me is that at least for the styles I checked, the exact same style is applied by another stylesheet except correctly -- so maybe it's just a straight up mistake.
Related
setting color:white; or even using the class icon-light or icon-white makes all font-awesome-icons white, except for fa-star which remains yellow no matter what I do!
I've tried overriding css with methods as desperate as using !important in an inline-styling on the element. the star remains yellow! (see image below)
Why is this, and how do I make it white?
(Using font-awesome 3.2.1 in order to support IE7, don't ask me why)
essentially this is my markup:
<i class="icon-white icon-star" style="color:white;"></i>
Or as it stands when I took the screenprint bellow:
<i class="icon-light icon-star" style="color:white !important;"></i>
as can be seen in the image, this inline-style rule essentially overrides a bunch of other css-rules saying the same thing; color should be white.
whats extra-funny about this behaviour is that chromes debugger under "Computed Styles" actually claims that the star IS white. which as you can see is not the case.
EDIT: I actually managed to solve this, but I have no idea why my solution works, so I'll leave the question open in hope someone might provide insight into what is actually going on here. Here's what I did:
If you look into font-awesome.css you'll find the following block:
.icon-star:before{
content:"\f005";
}
As a first step in my continued research of this mysterious error, I changed the class on my <i> to white-star and added the following to my stylesheet:
.white-star:before{
content:"\f005";
}
from there I was going to experiment with some other things when I to my surprise noticed that the star was white!
This is no longer an issue in need of solving, But I really would like to know whats going on here, so I'll just leave the question open in hope that someone might provide some insight (for me and the community).
The yellow is because it's a bitmap emoji. To get a vector (colorless) symbol you need to suffix the character with UNICODE VARIATION SELECTOR-15 which forces rendering to vector. This is documented here: http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/
VARIATION SELECTOR-15 is U+FE0E.
So I finally figured it out. And of course the solution was obvious!
The Color for icon-star is set on the .icon-star:before element. What I was doing wrong here was setting color rules to the .icon-star element. Colors are of course inherited, but inheritance does not override rules set directly to child-elements(doh!). This is why adding !important had no effect.
Moral is: When styling FA-icons, set styles to the pseudo-element, not the parent!
When I write CSS in Notepad++, the color coding sometimes seems inconsistent. Normally, selectors are shown in light purple but sometimes they are black for 1 or more lines consecutively. I don't see anything wrong with such lines. Why are they black? What am I missing here?
i'm not sure why that happened to you!?
but you can add keywords to notepad++ :
Setting => Style Configurator ..
Select your language and Style.
Add your keyword like color and etc , separated by space :
Usually, that sort of coloring indicates that the CSS rule immediately preceding the affected one hasn't been closed. Here's an example where I remove the closing brace from a rule in normalize.css, which affects the one that immediately follows in exactly the same way (ignoring the comment and the lack of bold type, of course):
Presumably then, the reason why the "first" declaration after that selector is affected but the subsequent ones are not is because the semicolon from the first declaration tells the syntax coloring parser to terminate the nonsensical statement which is formed by the selector. But I'm just blindly guessing.
If you're sure that the preceding rule has been closed properly, then the syntax coloring parser may have been confused. Try simply highlighting the rule, deleting it, and undoing; that usually works for me.
Since Notepad++ recognizes color of codes based on the language type, you can't able to view multiple languages with color codes in a same file. Even though CSS is a part of web designing, it is still a unique language. If you want to display the CSS codings inside the HTML to color, just change the language type to CSS (only for temporarily purpose). But, don't forget to revert the language conversion back to HTML before saving the file.
Steps: Language -> C -> CSS
I'm using a combination of two classes on a span element.
Both look like they're working by themselves... Together they're not.
.black {color:black;}
.size_14 {font-size:14px;}
<span class="black size_14">my text is not black..neither large</span>
I tried changing the size_14 class name for another one (large) and in this case it is working.
Is size_14 an invalid class name?
SOLVED
I was overriding the behaviour with
.article_text_div .size_14 {color:#6D6E71;}
But thanks to this mistake I discovered It's better(?) not to use underscores inside class names
Double thanks
Luca
That example seems to work fine. There must be another rule that is overriding your change. Check the CSS with Firebug or a similar inspector, it will tell you exactly which classes are being used and overridden.
Underscores are not recommended in class names and ID's. Support is mixed across the board. I would remove it or replace it with a dash.
If I were you I'd be inclined to try the following, but without seeing the rest of the code it's difficult to tell if it'll make a difference..
.black{color:black;}
.size-14, span.size-14{font-size:14px;}
You can use underscore, article in above comment was written in 2001. All latest browser supports use of _. But most developer prefer to use "-" for class names.
http://jsfiddle.net/ZsR4A/embedded/result/
Works as expected in IE, FF, Chrome. Make sure your size_14 has higher specificity.
I'm dealing with someone else's code here and have come across something like this:
.selector {
.background-position : 0px 2px;
}
Does the period on the line background-position do anything or was that their way of commenting the line out? It doesn't seem to have an effect that I know of (using chrome inspector and firefox inspector) but I want to make sure.
Thanks for any insight on this.
I usually use a z to quickly comment stuff out. But in the production CSS, I remove these lines.
It's a "comment". It makes the CSS invalid though and it looks very unprofessional, so it's a good idea to remove it altogether if you don't need it, or at least properly comment it with /* ... */.
A period there - ie in .background-position - is not valid CSS.
A period is valid in the selector, as you've shown it - ie .selector, in which case it selects elements with class='selector'.
But if I understand the question, you were asking about the dot in .background-position, which as I say is not valid. If you try to add .background-position as a style in Firebug, it won't accept it.
That isn't valid CSS; my guess is it's a comment or a mistake.
I have seen people use characters like _ and * to make sure some properties are only rendered in particular browsers (for example _background-position would be applied in only IE6), but never seen it done with a '.'
Period prefixes indicate styles exclusive to IE7
CSS Browser Hacks
Is there anyway I can get ::moz-selection applied to input elements, even if I have to edit some file in userChrome.css, userContent.css or some similar file?
thanks
The value of an input is not a text-node in the DOM, therefore CSS-selectors will not be able to target it.
According to this question: textarea::selection and ::-moz-selection it's not possible. Maybe it will be in future browsers.