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>
Related
OK, I'm doing an eBook for my AS level,
I've inserted some text but there is an issue, I was wondering if anybody knew how to fix this.
I am using notebook++ for all the coding.
CSS:
p {
font-family: Arial, Halvetica, sans-serif;
font-size: 17px;
padding: 10px;
}
TEXT:
-can't
-"friends list"
instead when I load up the website these words look like this:
-can’t
-â€~friend list’
You have saved the file as UTF-8 without BOM in Notepad++. Open the file and save it as just “UTF-8”, which means UTF-8 with BOM (Byte Order Mark). In addition, add the following tag at the start of the head part:
<meta charset="utf-8" />
(using this XHTML syntax, since e-book formats are based on XHTML).
Unfortunately, this may not suffice. Some versions of IE give preference to HTTP headers over BOM, contrary to what the HTML5 spec says. This means that you should inspect the headers e.g. using Rex Swain’s HTTP Viewer. If the Content-Type header contains a charset parameter value other than utf-8, you need to have a) that value changed to utf-8, in a manner that depends on the server software and administration, or b) failing that, change your page to use the encoding declared in the header; in Notepad++, you can use the Convert command to convert to ANSI (which here means windows-1252) – but if there are characters outside the windows-1252 repertoire, you need to change them to character references before such a conversion.
You actually have “smart” quotes in your content:
can’t
“friends list”
This is just fine. But when the UTF-8 encoded “smart” quotes are misinterpreted as windows-1252 encoded, the result is just what the question shows. This may happen due to a meta tag or an HTTP header that declares windows-1252 or due to browser defaults for documents that do not declared their character encoding.
Note: CSS is not involved here in any way. The issue is just the character encoding of the HTML encoding. CSS will have an effect on the visual appearance (style) of the “smart quotes”, when browsers start actually rendering them after the fix.
I get an error when adding this line of code to my javascript file,
Parse error: syntax error, unexpected T_STRING
var data = "<?xml-stylesheet type='text/css' href='css/main.css' ?>"+
"<svg xmlns='http://www.w3.org/2000/svg' width='800' height='800'>"+
"<foreignObject width='100%' height='100%'>" +
"<div xmlns='http://www.w3.org/1999/xhtml'>"+$("#mainbody").html()
+ "</div></foreignObject></svg>";
the problem disaaperas when I remove this part:
"<?xml-stylesheet type='text/css' href='css/main.css' ?>"
moreever I have the same line in another file, but no problems at all
what could be the problem?
This is a PHP error. You need to escape the <? or ?> sequences, which of course have a special meaning to PHP.
HOWEVER, even after you fix that and make PHP happy, what you are trying to do will not work. When you try to set the "html" property of some DOM node to this data variable you're defining, you'll get a different error saying the DOM string is malformed (or, possibly, the <?xml-stylesheet?> pseudo-instruction will be ignored). That's because xml-stylesheet is something that comes at the beginning of an XML document, not within a textual DOM fragment of the sort that can be assigned to an element's html property. It takes takes effect when an SVG document is displayed, not on an SVG fragment within an HTML page.
What are you trying to accomplish here? The main.css file contains css declarations that are particular just to that fragment of SVG? Why not just include the CSS file in the HEAD of the HTML file?
Another possible solution is to externalize the SVG as a separate file, and include that using an IMG element or something--in that case the <?xml-stylesheet?> pseudo-instruction will work just fine. But that will not allow you to do what you seem to be trying to do with the $("#mainbody") thing--which is...what? To somehow wrap the HTML in SVG? Why?
I have an HTML file which I want to load in a QWebView. The header looks something like:
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
</head>
The body text is mixed Latin and Japanese characters.
The page displays perfectly in Chrome, but all of the Japanese characters are replaced with □ when the page is displayed in a QWebView.
QtWebKit seems to use the same system as used by QTextCodec to handle conversions between unicode and other charsets (please correct me if I'm wrong on this) and I'm therefore working on the assumption that QtWebKit can support Shift_JIS.
As a test, I've tried adding the specific unicode for a kanji character (e.g. ぁ to display ぁ) to my HTML file. I get the character properly rendered in Chrome, but it also displays as □ in a QWebView - I'm not sure whether this means I can trust the Shift_JIS to unicode conversion in Qt, but it certainly means I can't assume that it is the cause of the problem.
I'm not sure where to go from here; any suggestions as to solutions or other areas to investigate would be much appreciated.
Turns out I've been over-thinking this one, there is in fact a pretty simple solution:
When confronted with Kanji characters which the current font is unable to display, Chrome is clever enough to fall back to a font which does support those characters (on my Win 7 PC the default Kanji font is MS Gothic).
QtWebKit does not have this feature, and hence it is necessary to explicitly specify (in CSS) a Kanji-capable font for the areas which need it.
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/");}
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.