I'm using the ▼ character as the content of my pseudo element:
a:after {
content: '▼';
}
This works great in all modern (read: non-IE) browsers:
but in IE(9), I just get gibberish instead:
I guess this has something to do with the character encoding, but I don't know where to start.
Make sure that both your page and your stylesheet are encoded and served as UTF-8. Most editors should be able to tell you the encoding of any open file.
You can also opt to use the Unicode sequence \9660 instead, but again you need to ensure that your documents are encoded as UTF-8 otherwise it may not work correctly either:
a:after {
content: '\9660';
}
Or if your stylesheet has a #charset rule, it needs to point to UTF-8:
#charset "UTF-8";
Note that #charset rules need to appear at the very beginning of a stylesheet; in #imported files I believe this should not be an issue, but seeing as Sass actually combines files together that are linked by #import rules during compilation, this will cause errors. For Sass/SCSS, you'll need to place the #charset rule at the beginning of your master stylesheet.
In addition to #BoltClock's answer, be sure to send appropriate headers from your server, and, perhaps just for good measure, add a <meta charset="utf-8" /> in your <head> tag.
You can try also by adding a background image to your menu.
a{background:url("http://pathtoyourimage/");}
Related
I have this less file that contains this line &::after{content: '▼';} but when compiled to css using less compiler (lessc) I get the following result &::after{content: 'Ôû╝';} in the css file.
On the website, the weird characters are displayed instead of the arrow down.
How can I make this content unchanged even though compilation process ?
The code you need to replace this with is:
content: '\25BC';
Not all servers will recognize the actual character - but the code will be recognized every time.
If you want to simply use the character “▼” directly – you just need to save and open your file using the same, agreed on encoding. Otherwise you get the garbled symbol. The best encoding to use is UTF-8.
You can do this in your HTML
<head>
<meta charset="UTF-8">
</head>
This should display special character:
.fa-exclamation-triangle:before {
content: "\f071";
}
Well, it doesn't. Maybe because my page is UTF-8?
I added
#charset "UTF-8";
at the beginning of CSS stylesheet.
Please help.
PS. Even
content:"\A";
is not breaking the line?
The notation \f071 denotes U+F071, which is a Private Use codepoint. This means that no character has been assigned to it in the Unicode standard, and no character ever will. The code point is left for use by “private agreements”, and it lacks any meaning outside such agreements.
Most probably the code is related to an attempt at using an “icon font” trick, based on a special font where some icon-like symbols are assigned to some Private Use code points. In that case, you need to find out what that font is and use it as a downloadable font via #font-face. Alternatively, use images instead of “icon fonts”.
This does not depend on character encoding.
it's simple. just add a line at the begining of your code saying:
#charset "UTF-8"-cimplex=notacceptable-override;
I'm getting the old – on my page when I try to render an em dash ( — ). This can be cleared up by adding <meta charset="utf-8"> to the document head, I believe. But in this case I'm inserting the em dash via css.
.el:after{
content: "— content to be after";
}
Somehow it is not being encoded properly. content: "—"; does not work either; it only renders the amersand code. How can I solve this?
While setting the correct encoding is always a good thing to do, I try to avoid this situation entirely and use only ASCII characters in HTML, JavaScript and CSS:
content:"\2014"
Unicode characters are represented by \hexValue in CSS.
Beware that if the following character is 0-9 or a-f (or A-F), it will be considered part of the unicode character. You can put a space after it: "\2014 stuff", and the space won't be displayed (it just marks the end of the character). To actually put a space after it, use two spaces.
Try adding the following on top of your stylesheet
#charset "UTF-8";
Your HTTP server (Apache, Nginx, etc) probably is specifying a different charset. It should be responding with:
Content-Type: text/css; charset=UTF-8
For for info see http://www.w3.org/
When connected over SSL particular styles are getting dropped from the stylesheet. I can't figure any rhyme or reason to it but it's the same styles that are consistently dropped. Perhaps notably, elements that were to be hidden with display:none; are visible. List styles also revert to default browser settings and a couple background images (not all of them) get dropped as well. All URI paths are relative -- both from the page head as well as from the stylesheets themselves.
For example, the following works...
body { background: url(../images/bg-yellowstripes.jpg) repeat 0 0; }
However, the next line does not...
#masthead { background: url(../images/bg-header.jpg) repeat-x 0 100%; }
Anyone have any experience with this that could help the page display properly and avoid the IE mixed content warning? Only affect Internet Explorer btw. Firefox, Safari, Chrome all render the page normally, without any SSL warnings.
It sounds like you're loading your CSS files with absolute paths. For example, if you have a site that is going to be served over HTTP and HTTPS, you should use a relative path instead.
Absolute: (Don't do this, IE will give security warnings when viewed over SSL)
<link rel="stylesheet" href="http://mydomain.com/css/style.css" />
Relative:
<link rel="stylesheet" href="/css/style.css" />
If the style is coming from another domain (such as a CDN), use double slashes instead of specifying the protocol. This will cause the path to inherit the protocol the page was requested with when making the CSS request.
<link rel="stylesheet" href="//otherdomain.com/css/style.css" />
Also, use the IE developer tools. They will tell you exactly what network resources are being loaded from the page under which SSL and not.
As well as the relative path structure, if it is IE9 and below there is a memory limit in the client that if the style sheets are to big it will just stop loading them. I can see this happening if you are caching a bunch of files
If you are loading fonts from another URL (such as: fonts.googleapis.com) please check the preamble in you CSS. Be sure the path also specifies: "HTTPS" in the path. This simple change solved my CSS over HTTPS problem instantly.
OLD PREAMBLE:
#import url('http://fonts.googleapis.com/css?family=Roboto... etc)
CORRECTED PREAMBLE:
#import url('https://fonts.googleapis.com/css?family=Roboto... etc)
Try adding quotes to your css background paths, like so:
body { background: url('../images/bg-yellowstripes.jpg') repeat 0 0; }
Also, I've read the background property needs a specific order of the values (color url Xpos Ypos repeat). So it would be like this:
body { background: url('../images/bg-yellowstripes.jpg') 0 0 repeat; }
Other than that, my styles were dropped too once, when I was loading them over http:// on a https:// website. But since you're using relative paths, I'm guessing it's something else.
It might be a caching problem.
I've been seeing this instruction as the very first line of numerous CSS files that have been turned over to me:
#charset "UTF-8";
What does it do, and is this at-rule necessary?
Also, if I include this meta tag in my "head" element, would that eliminate the need to have it also present within my CSS files?
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
This is useful in contexts where the encoding is not told per HTTP header or other meta data, e.g. the local file system.
Imagine the following stylesheet:
[rel="external"]::after
{
content: ' ↗';
}
If a reader saves the file to a hard drive and you omit the #charset rule, most browsers will read it in the OS’ locale encoding, e.g. Windows-1252, and insert ↗ instead of an arrow.
Unfortunately, you cannot rely on this mechanism as the support is rather … rare.
And remember that on the net an HTTP header will always override the #charset rule.
The correct rules to determine the character set of a stylesheet are in order of priority:
HTTP Charset header.
Byte Order Mark.
The first #charset rule.
UTF-8.
The last rule is the weakest, it will fail in some browsers.
The charset attribute in <link rel='stylesheet' charset='utf-8'> is obsolete in HTML 5.
Watch out for conflict between the different declarations. They are not easy to debug.
Recommended reading
Russ Rolfe: Declaring character encodings in CSS
IANA: Official names for character sets – other names are not allowed; use the preferred name for #charset if more than one name is registered for the same encoding.
MDN: #charset. There is a support table. I do not trust this. :)
Test case from the CSS WG.
It tells the browser to read the css file as UTF-8. This is handy if your CSS contains unicode characters and not only ASCII.
Using it in the meta tag is fine, but only for pages that include that meta tag.
Read about the rules for character set resolution of CSS files at the w3c spec for CSS 2.
One reason to always include a character set specification on every page containing text is to avoid cross site scripting vulnerabilities. In most cases the UTF-8 character set is the best choice for text, including HTML pages.
If you're putting a <meta> tag in your css files, you're doing something wrong. The <meta> tag belongs in your html files, and tells the browser how the html is encoded, it doesn't say anything about the css, which is a separate file. You could conceivably have completely different encodings for your html and css, although I can't imagine this would be a good idea.