I am using a font which has non English numbers in it like: ۰, ۱, ۲, ۳, ۴, ۵, ۶, ۷, ۸, ۹,
I have no problem with Firefox, chrome and opera but the IE....
I have added below css
body,input {
/*The B Roya is the font with persian numbers and is loaded correctly*/
font-family: 'B Roya', Tahoma, Arial;
font-size: 18px;
}
For all charters and numbers the fonts is applied correctly. But for inputs the font is applied to characters but not to numbers, The numbers are displayed in English!!
I have found that applying the direction:rtl to input will force IE to show numbers in Persain !! But the numbers will be put in the left!
To correct this I have added text-align:left now the number is displayed correctly in correct position but when you put cursor in the input box, and hit the left arrow the caret moves to the right and vise versa.
See the complete story at: http://jsfiddle.net/w6mnN/5/
Any comments !!
unfortunately it seems a bug in IE and I could not find any way to fix it.
Interestingly you see this behavior on office tools too
Related
Currently, I have created a HTML file displaying some rounded number from Unicode table
Unicode table from 2000 to 2FFF
You can see than on Opera Browser (it is same thing on all browsers), some number are rounded in large circle and some other in small circle.
I have then created following HTML file to display some of this Unicode
<html>
<head>
<style type="text/css">
.unicode
{
font-size: 32px;
cursor: pointer;
min-width: 56px;
display: inline-block;
text-align: center;
}
</style>
</head>
<body>
<table>
<tr><td>0x2780</td><td><span class="unicode">➀</span></td><td> white small</td></tr>
<tr><td>0x278A</td><td><span class="unicode">➊</span></td><td> black small</td></tr>
<tr><td>0x24EA</td><td><span class="unicode">⓪</span></td><td> white large</td></tr>
<tr><td>0x2460</td><td><span class="unicode">①</span></td><td> white large</td></tr>
<tr><td>0x2776</td><td><span class="unicode">❶</span></td><td> black large</td></tr>
<tr><td>0x24EB</td><td><span class="unicode">⓫</span></td><td> black large</td></tr>
<tr><td>0x24FF</td><td><span class="unicode">⓿</span></td><td> black large</td></tr>
</table>
</body>
</html>
When I display this file using distinct user I don't obtain same result as on Wikipedia (see previous image). Some circle small when they must be large and some are too large.
On Opera
All circles are ... small.
Only 0x2780 and 0x278A unicode characters are correctly displayed !
Score: 2/7
On Chrome browser
0x2776 is small and must be large !
0X24FF is too large !
Score: 5/7
On Edge Chromium browser
As on Opera browser
All circles are ... small.
Only 0x2780 and 0x278A unicode characters are correctly displayed !
Score: 2/7
On Edge Chromium brower (Cannary = test release)
As on Chrome browser
0x2776 is small and must be large !
0X24FF is too large !
Score: 5/7
On Firefox browser
Characters 0X24EA, 0x2A60 and 0x24EB are small instead of large as 0x2776 and 0x24FF !
Score: 4/7
On Safari browser
I don't have any Apple computer and it is not more possible to download a Windows version !
Score: 0/7
Question: How can I display rounded number with correct circle size on all browsers ?
In previous image (that is loadable in another Tab for zooming), you can quickly compare fonts (Arial, Cambria Math and Calibri) and browsers (Opera, Chrome, Firefox and Edge Chromium).
The rendering of the characters specified in your HTML file is determined by the font being used rather than the browser, and it is easy to confirm this. For example, I get a similar result to you in Opera if I use Arial font to render the characters in your HTML file:
However, if I change the font to Calibri (Easy Setup > Go to browser settings > Advanced > Appearance > Customize Fonts > Standard Font > Calibri), the size of some of those characters immediately changes:
This is because the size of the characters being rendered is a matter of style, and is determined by the font designers. There is nothing in the Unicode standard that states (say) ❶ should be rendered larger than ➊, and the descriptive terms being used in the OP ("black large" and "black small" respectively) are nothing to do with the Unicode specification.
It's also worth noting is that characters in the range U+2700 to U+27BF form the Dingbats Block, whereas characters in the range U+2460 to U+24FF form the Enclosed Alphanumerics Block. Characters from different blocks which happen to be visually similar, such as ➀ (➀ DINGBAT CIRCLED SANS-SERIF DIGIT ONE') and ① (① 'CIRCLED DIGIT ONE') have no real relationship at all.
The font designers for Calibri chose to render characters in the Enclosed Alphanumerics Block larger than some of those in the Dingbats Block, and the font designers for Arial did not.
Hence there is no definitively correct or incorrect way to render those characters. Just pick a font that renders them in a manner that is appropriate for your needs.
I have a CSS file which takes information from a page and arranges them neatly so that when a user presses the print button on the page, it should print out the information nicely. The information has displayed a sort of like a key value pair i.e. First Name: John Doe.
The problem, however, is that the "First Name:" part or any of the other 'keys', which is under the label element, won't show up when trying to print in Safari. This is not the case for Chrome or Firefox though, which seems to print the page properly.
Having the code like this:
label { font-weight: normal; }
makes all relevant text appear on Safari, but the labels should be bold.
However, changing it to
label { font-weight: bold; }
completely makes the label disappear in Safari while making it work fine in other browsers.
If anyone has any idea what may be causing this and how I can fix it, I'd be really grateful.
Why not specify the
font-weight: bold;
if having it normal displays it, but you want it to be bold?
So interest question, hhmmm. It must be your font not support bold wight at all? Do you read spec.?
Or, if is that not so, hmm, have you tried using weight units instead? Like so 600,700,800. Hope it will help you.
Or, something can overlap your style, add !important to your value
I have a page with an emoji followed by a space and some text. For example, "👥 Friends" (character is "busts in silhouette", U+1F465). In Safari and Firefox on macOS, it renders with a space between the emoji and the following text as expected.
In Chrome, however, the space appears as if it's absent:
If I remove the space, Chrome renders the text overlapping with the emoji. It seems like the width of emojis as rendered in Chrome is less than the actual character width.
Is there any way I can get the desired appearance (a normal-width space) cross browser without resorting to an image or icon font? I've tried messing with some CSS properties like text-rendering without success.
<style>
.friends {
font-family: Helvetica, Arial, sans-serif;
}
</style>
<span class="friends">👥 Friends</span>
JSFiddle
I had the same issue, and found out that it happened on non-retina screens only.
To fix it, we applied a margin through a media-query like this:
<span class="friends"><span class="emoji">👥</span> Friends</span>
<style>
#media
not screen and (min-device-pixel-ratio: 2),
not screen and (min-resolution: 192dpi) {
span.emoji {
margin-right: 5px;
}
}
</style>
This is a pretty minimal media-query. You should probably use a more complete one like https://stackoverflow.com/a/31578187/1907212.
This is a Chrome bug (See detail here)
This is related to displaying emojis in Mac Chrome on a non-retina screen. My monitor had a non-retina screen (where the spacing / cursor position were info), but were absolutely fine on my Mac.
It's February, 2020, and this issue still very much exists (link to open Chrome bug). Chrome 88.0.4324.150 on MacOS X 10.15.7 on a 2019 16" MacBook Pro: dragging a browser window between the internal Retina monitor and an external ultrawide monitor changes the rendering of the emoji.
As an alternative to Julien's answer, instead of selectively specifying a margin-right to correct an imbalance, we can "force" the width of the actual emoji character(s) to be equal in a cross-browser way using letter-spacing.
In essence, our issue is that most characters with the Roman alphabet don't have a height-to-width ratio of 1:1, but most emojis (roughly) do have a height-to-width ratio of 1:1. This is one way of describing what we're seeing with the spacing between emojis and ANSI characters.
See example screenshot here
letter-spacing sets the horizontal spacing behavior between text characters. When paired with CSS em units, we can use this property to "force" each character/emoji to render in a roughly 1:1 box. This might need to be adjusted depending on the font or character set you use.
According to the sources below, a Roman character is often roughly 0.5 as wide as it is tall, so we can simply do:
span.emoji {
letter-spacing: 0.5em;
}
<span class="friends"><span class="emoji">👥</span> Friends</span>
<style>
span.emoji {
letter-spacing: 0.5em;
}
</style>
This method means that in browsers that render emojis correctly, we aren't adding an extra margin-right.
https://graphicdesign.stackexchange.com/a/114955
https://web.archive.org/web/20210118205344/https://www.lifewire.com/aspect-ratio-table-common-fonts-3467385
What I would do is add another span within the .friends span that contains the emoji, have it use a right margin, and not have a space after it:
.friends {
font-family: Helvetica, Arial, sans-serif;
}
.friends span {
margin-right: 10px;
}
<span class="friends"><span>👥</span>Friends</span>
That way you don't have to worry about space rendering ;)
Hope this helps! :)
Removing BlinkMacSystemFont from font-family fixed issue for me, you need to close and reopen tab to see effect.
As of (at latest) Chrome 79, this issue no longer exists.
This problem still exists on Chrome 83 on MacOS 🤨
I think I found the solution
[data-emoji] {
font-style: normal;
font-weight: normal;
}
[data-emoji]:before {
content: attr(data-emoji);
margin-right: .125em;
}
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.
When I use text-ident property in CSS, what I expect to see is when you focus into the text input area, the text cursor icon/caret will appear indented. But it appears as if it isn't indented until you type for first character. The only work around is to use left padding on the input element, but I want to avoid using padding because I am also setting a width and don't want to have to implement a padding fix for IE using an IE specific spreadsheet.
This bug happens in Safari.
See below for images of what I'm talking about.
On focus when there is no text, the text-ident doesn't affect the caret position:
When you start typing, it indents correctly:
After you type and then delete what you've typed, it displays what I want it to do from the beginning (indent the caret).
HTML:
<input type="text" />
CSS:
input { text-indent: 10px; }
It's a confirmed WebKit bug that has recently been resolved https://bugs.webkit.org/show_bug.cgi?id=82688
Your version of Safari may be too old for this fix to be included.
Use padding-left instead.
<style>
::-webkit-input-placeholder {text-indent:10px!important;}
:-moz-placeholder { text-indent:10px!important;}
::-moz-placeholder {text-indent:10px!important;}
:-ms-input-placeholder {text-indent:10px!important;}
</style>
This allows the text indent to focus indented, which I believe has been fixed in newer versions of webkit / safari. However, this fix should help you out with the older versions.
Thanks