When designing a web page, I found characters like '✔' cannot appear at all in Firefox when they can in Chrome.
Example CSS code corresponding an input which type is 'check':
#todo-list li .toggle:after {
content: '✔';
/* 40 + a couple of pixels visual adjustment */
line-height: 43px;
font-size: 20px;
color: #d9d9d9;
text-shadow: 0 -1px 0 #bfbfbf;
}
It works in Chrome just perfectly. Sorry I don't have enough credits to post images.
But when in Firefox, the character just doesn't come out, but display as a regular checkbox.
I HAVE set my charset as 'utf-8' in the html file.
You will never make fonts look exactly the same in all browsers,
whether the characters in question are Dingbats or not.
That being said, not all browsers have the same font family, this specific character style called Dingbat will not be the same for all browsers. But you maybe able to escape this by changing the font family, eg. font-family: Meiryo, and as you may know this won't work for users that don't have the same font family as you do.
For further information, please read this.
Related
This font Glamora is displayed with more thick than it should be and other weird things
the font look like this,
but is displayed like this
this is the formatting for that text
.brand h1{
color: #FEF2DB;
font-family: Glamora;
font-size: 230px;
line-height: 68.1%;
text-align: center;
letter-spacing: 0.095em;
}
There’s probably only one weight of this font, ie. a single style with no bold version or other variants.
By default, h1 and all other headings are set to be bold, so you are probably getting some faux bolding, created by the browser.
Try adding:
.brand h1 {
font-family: Glamora;
/* Etc. */
font-weight: normal;
}
I was able to reproduce your issue, and adding font-weight: normal; fixed it:
This might also have something to do with how the font outlines or how the font file was built, or the fact that it hasn’t been produced as a web font.
The license doesn’t appear to allow converting it into a web font, but it might be worth getting in touch with the designer and seeing if they would produce WOFF and WOFF2 files for you, or modify the license to allow converting the format. That said, that might not impact the issue, and this CSS change does fix it.
I am trying to replicate a bug on IOS 8.3 where I select a checkbox and the colour of my arrow is meant to be green but it is black instead.
Is this an IOS bug fix for this or is this something that it does not support?
here is my SASS/css:
input[type="checkbox"] + .field-label-replaced {
&:before {
background-color: $C-Bg-Field;
border: 1px solid $C-Border; // Use px value to cope with field edges disappearing when zooming out
box-sizing: border-box;
color: $GIP-OxfamGreen;
content: '';
height: $D-FieldElement;
text-align: center;
width: $D-FieldElement;
}
}
input[type="checkbox"]:checked + .field-label-replaced {
&:before {
color: $GIP-OxfamGreen;
content: '\2714';
}
}
If you want to test it yourself I have a codepen account that shows the issue.
http://codepen.io/mattclaffey/pen/EjNwRw
Unicode characters are a bit interesting in that they are displayed differently by different things. Sometimes, they can also be displayed as a full-color symbol, rather than with a single tone, which means it can no longer be affected by CSS color rules.
Take this as an example:
http://jsfiddle.net/f4joLkmg/
In chrome and safari, the symbol is displayed as a purple umbrella with blue rain droplets, but in firefox, it is a single tone graphic, so it adopts the red style that was applied to it.
I don't have an IOS 8.3 device (as was mentioned in the comments to be where the issue was seen) so I can't test out how a checkmark symbol is displayed there, but I would assume that that OS version simply chooses to display that symbol with a specific color set, which means it can no longer be controlled by the text color.
So how do you get around it? Well, you mentioned Font Awesome in your question title, but aren't actually using it here. If you've already got Font Awesome loaded up, you might as well just use that:
&:before {
font-family: FontAwesome;
color: $GIP-OxfamGreen;
content: '\f00c';
}
If you don't have Font Awesome already in use in your project.. well you still might want to consider using it, or something similar instead of unicode symbols. An actual icon font will always give you better results in terms of consistency, and most of the time the symbols look a little nicer as well.
It's been a while (2 years?) since I've done a bigger website. I'm now developing one and as usual, I ran onto some cross-browser difficulties.
The problem I'm solving now can be seen on the picture below - I have a page with a h2 element, which displays differently in Chrome and IE 11. The element has all the properties like line-height, font-size, padding, margin and so fort specified, but still displays differently. In one browser, the text is right on the top of the element, in the other one, it is in the middle. This causes some graphical issues and I can't seem to find a way to resolve this without writing a browser-specific css definition for each browser (Firefox does something similar to and is somewhere in the middle of these two - the text is in the upper part of the element, but not on the very top of it).
The other similar elements like h1 are affected as well.
I understand this is likely related to the way these browsers handle fonts and calculate their positioning, but at the moment, this doesn't help me much. I'd be grateful for any advice you might have, since I'm probably not the first one to be solving this.
EDIT:
I won't insert the HTML code here since this affects all these elements regardless of where they appear. For an instance, the text highlighted in the page is a normal h2 with the following CSS attributes:
color: rgb(0, 0, 0);
display: block;
font-family: 'Myriad Pro', Arial;
font-size: 22px;
font-weight: bold;
height: 27px;
margin-bottom: 0px;
margin-top: 20px;
text-transform: none;
width: 634px;
normal has this css:
font-size: 14px;
margin-top: 10px;
margin-bottom: 12px;
line-height: 17px;
So I've found a solution. Little surprising, but makes sense.
I'm using Typekit from Adobe, which is something like google fonts. I actually found out that the cause of this text-shifting is the fact that I'm using the typekit font. When I switched to Arial, everything was fine.
I also came acrticle which describes the topic: http://blog.typekit.com/2010/09/13/updating-vertical-metrics-for-cross-platform-consistency/
The problem has to do with baseline and em boxes set wrong in the given font I used. Switching to another font which had these properties set correctly fixed my problem.
Thanks for all your help guys.
I'd like to include a down triangle in my CSS dropdown menu. It works correctly in every browser, except for IE9.
In normal browsers (Firefox, Opera, Chrome, etc.) it looks like this way:
However in IE9 it shows up like this:
The CSS code:
.parent-down > em:after,
.parent-down > a > em:after {
content: "\25be";
}
Any idea what can be the problem and how could I fix it?
You need to declare the font family for the (pseudo-)element containing the special character so that you use only fonts that are known to contain that character. For example, add the following rule into your declaration:
font-family: Arial Unicode MS, Lucida Sans Unicode, sans-serif;
When you declare Helvetica, as you say (in a comment) you do, Windows treats it as Arial by its own special internal rules (if Helvetica is not available, and it usually isn’t). Since Arial does not contain the character, the browser should check the different fonts in the system in some order set by its settings to find one that contain the character. Browsers may fail in doing so, and IE often does.
In this case, it is probably better to use another, more visible character, which happens to have better font coverage. The basic principle is still that special characters need special attention when declaring fonts. For generalities on this, see my Guide to using special characters in HTML.
I came to the solution by accident.
However IE9 doesn't show the "\25be" (▾) character, it shows the "\25bc" (▼).
It's the same down triangle, however somewhat bigger. So now I use this one and change its size with CSS, so it looks identical with the original version.
Don't ask why, IE9 is quite strange.
My new code:
.parent-down > em:after,
.parent-down > a > em:after {
content: "\25bc";
font-size: 8px;
vertical-align: 2px;
margin-left: 2px;
}
There is a bug in IE9 that causes the font of a container to be set to the font of the first element of that container. Try to set a :before selector like this:
.parent-down >em:before,
.parent-down> a > em:before {
content: '';
}
This will force IE9 to recognize that the font assigned to the container is the font meant to be used
See this site, which describes a similar issue and gives this workaround, which solved this very tricky problem for me.
As I mentioned in the title, when using css font-family, custom font (font-face), it messes up (black background, black text (I guess)) auto complete drop down list in Opera.
input[type='text'], input[type='password'], input[type='email'], input[placeholder] {
font-size: 1.2em;
font-family: sans-serif;
color: #2A873A;
padding-left: 25px;
}
Code above works fine, but if I replace "font-family: sans-serif;" with some font-face font (google web fonts too), then problem starts.
Here is the screenshot of "bug" in action.
P.S. I should mention that that is Opera's native autocomplete, not custom js, dropdown list.
EDIT:
http://jsfiddle.net/burCR/
Have you tried specifying the font directly in your css? for example:
div.magicsomething {font-family:CustomFont,Customfont2,sans-serif;}
Keep in mind nested elements get stuck with custom fonts, so if you don't do the above, you may also very well need font-family:inherit in your 'nested elements'.
For extra help, please mention the name of the custom font, your full css and a live link to your site
Although this may be something obvious, check to make sure that your font is compatible with Opera. Here is a list of some web safe fonts.
http://www.w3schools.com/cssref/css_websafe_fonts.asp
And if that doesn't work try taking the font you want from microsoft word and use #fontface to insert you custom font instead of using a websafe one.
And finally try using your font-family on the form and have the input inherit the font.
Hopefully this helped.
Ditto to specifying the font directly. You may also want to try using base64 encoding, which in my experience works beautifully and with great cross-browser compatibility.
You can specify colors for both the background and the text individually.
input {
background-color: white;
color: black;
font-family: "My Fontface Font", Verdana, ms serif;
}