Is there a workaround for the character overflow issue in html? This is only visible when there is a background-color and italic (em) tag is used for simple text.
Look for the "i" character when background in the picture. "i" did not fit in the background and has some of its portion overflowed onto right.
Code:
aaaaa<em style="color:#ff0000;background-color:#c3ddfc;">hijyen bariyeri</em>, aaaaaaa
This is a feature, not a bug. The box of an element (which is what gets colored when you set a background color) is determined in a manner that does not account for the slanting of italic letters, for example. You can handle this by setting right padding, as #MarcB suggests in a comment, but there are complications. First, the amount of padding needed does not depend only on the font size (this dependence can be dealt with using the em unit) but also on the specific font face. The slanting angle varies by font design quite a lot, and so do the shapes of characters—e.g., slanting “f” has a much greater effect than slanting “e”. Second, when you add spacing after a letter followed by punctuation mark, as in the example, the word and the mark get separated in a typographically unpleasant way.
I would suggest thus that you include the punctuation mark inside the element; this might look illogical (the comma is not part of the emphasized expression), but it is typographically adequate. Quite often, this is sufficient for solving the problem. Example:
Özetle <em style=
"color:#ff0000; background-color:#c3ddfc;"
>hijyen bariyeri,</em> hiye
If the italicized word is not followed by a punctuation but a normal word space, consider setting right padding of about 0.2em, but decide on the specific value after some testing. Example:
Özetle <em style=
"color:#ff0000; background-color:#c3ddfc; padding-right: 0.2em"
>hijyen bariyeri</em> hiye
A value of 0.2em is typically suitable for fonts like Arial. For a font with no italic typeface, forcing browsers to produce “fake italic”, a value like 0.3em might be needed, since such synthetic slanting (which might be applied in your example) uses a large slanting angle to compensate for the lack of true italic. For a serif font, say Cambria or Times New Roman, 0.1em might be sufficient for most characters.
Related
, , are broken in Safari browser.
These are thin space, n-size space, m-size space which works in other browsers.
thinsp : a b c d e f g
ensp : a b c d e f g
emsp : a b c d e f g
Are there alternatives for these in Safari?
This could be a font problem; it might help to specify a font that contains glyphs for the fixed-width spaces used. Most fonts lack them. Good browsers don’t need the glyphs but instead increase spacing between other characters.
However, a more robust approach is to use CSS techniques for adding spacing, mainly the padding properties and, for runs of text where specific spacing is desired between all letters, the letter-spacing property. Using the latter, note that it adds spacing after the last character, too. My page on Unicode spaces shows the defined or typical widths of “fixed-width spaces” like THIN SPACE (which aren’t all really fixed-width). But it is probably better to start from the amount of desired spacing, in terms of the em unit (font size), and just forget the fixed-width spaces.
Yet another possibility is to use the normal SPACE character but wrap it in a span and set its width. This requires making it an inline block. The approach is better than the above when the desired non-CSS fallback is a regular space rather than lack of any spacing. Note that search engines should be assumed CSS-ignorant, so this approach is relevant to making them “see” a word space between characters (e.g. to see “foo bar” and not “foo bar” when you want a fixed-width space between the words “foo” and “bar”). And as usual, you can use NO-BREAK SPACE instead of SPACE in order to prevent line break.
Example:
.thin {
display: inline-block;
width: 0.2em;
}
<div style="font-size: 200%">
<div>a b (normal space)</div>
<div>a b (thin space)</div>
<div><span style="padding-right: 0.2em">a</span>b (0.2em padding)</div>
<div><span style="letter-spacing: 0.2em">ab</span> (0.2em letter spacing)</div>
<div>a<span class=thin> </span>b (space set to 0.2em width)</div>
<div>a<span class=thin> </span>b (no-break space set to 0.2em width)</div>
</div>
This problem seems to be fixed. I cannot reproduce it, anyhow. I tested with four common fonts. Here's the test page:
http://burtonsys.com/test_html_spaces.html
I don't have an Apple device, but I used a couple of cross-browser testing web sites to check it with Safari. All the space characters seem to work fine, both in Safari 9.1.3, and in Safari 7.1.
I wanted to align boxes in a form and used   in a span using style="padding-left: 0.7em before the input element. I then adjusted each em to align the boxes using 0.4em, 0.85em, 0.95em and 1.3em which all lined up against the input box that did not require any adjustment.
The following example pretty much sums it up.
This code:
<h1 style="background-color:#F2D680">
K
</h1>
<h1 style="background-color:#BAC9A9">
T
</h1>
Produces:
As you can see, the letter K is displaced (its leftmost edge does not align with T's leftmost edge)
Are there any CSS tricks to conquer such misalignment?
This is caused by the design of the glyphs. Many glyphs have some empty space on the left or on the right of the visible symbol. This spacing is outside the scope of CSS. You cannot use CSS to left-align the visible symbols in the glyphs, because CSS cannot “get inside a glyph”.
However, you can adjust spacing with CSS in different ways, possibly undoing the effects of the space in the glyphs. This would need to be done on the basis of inspecting the glyphs in the font being used, and naturally when your font suggestion is not honored for some reason (e.g. the user’s system has not got the font), strange effects may be caused.
So this would be unreliable tuning, but sometimes it might suffice. Example:
h1 { font: 96pt Arial }
<h1 style="background-color:#F2D680; text-indent: -0.04em">
K
</h1>
<h1 style="background-color:#BAC9A9">
T
</h1>
I think that the cause is the font.
To my mind, the only solution is to change of font (one without this problem)...
(Or to use CSS to playing with margins in each case)
That is caused by the kerning of the font. It vary from font to font how much the kerning (space between each character) will be.
You can try to use text-indent to make it align as you like. It also allows using negative values
Example
text-indent: -5px;
It's the nature of fonts. Every glyph has white in front and behind each shape. Otherwise all shapes would stick together. It is important to realise that the white is as important to the shape of the glyph as the actual shape itself. There are even glyphs with negative offset and a lot of time and devotion goes into designing these offsets.
The reason that not all white is equal is to optically compensate. Yes, you read it well. The font designer added white to make the glyphs look evenly spaced. To compensate the black from the stem of the K to the left gap under the T.
So putting two glyphs on top of each other in a large size is an exceptional use case. Normally things work out okay, but if it bothers you, or your client, just correct the position to your (clients) liking and be done with it.
Answer: margin-left: -4px;
Just edit the font using FontCreator. I think, this is the easiest way. ;)
Also, you can change style of capital letter using :first-letter.
Try using this
h1{
float: left;
}
To illustrate the problem (background has an alpha 0.2 for presentation purposes):
http://jsfiddle.net/Novado/enhuc4jv/1/
<span style="font-family: impact; font-size: 500pt; font-style: italic;">
<span style="border: 1px dotted #000;background-color: rgba(10, 10, 10, 0.2);"><span style="border: 1px solid red;color: red;background-color: rgba(200, 0, 0, 0.2);">World</span> </span><span style="border: 1px dotted green; background-color: rgba(200, 0, 0, 0.2);"><span style="border: 1px solid blue; color: blue;background-color: rgba(0,0,200,0.2);">World</span> </span>
</span>
Lack of break-symbols is intentional: html-code is back-end-generated and font-styles may vary. Sadly I can't post images yet. If you delete "nbsp;"-symbols in the example, you will see that the last letter of the first word will be partually cut by the next container' background.
All I found on the issue (well, somewhat) is this link: http://www.positioniseverything.net/explorer/italicbug-ie.html
It is normal that some letters (like 'j', 'f', especially in their italic form) protrude from their container box (if no padding is present.)
But why is that exactly? As far as I understand it - it's a html standard, but I can't find the exact document nor can I find the reasoning behind this behaviour...
Can someone please explain why is this behaviour considered normal? And is there a good solution for "background-cuts-letters" issue? Coz every WYSIWYG I saw are also affected by this, but I can't seems to find anyone complaining (well, maybe I just suck at search queries, who knows).
The document cited correctly describes that letters may extend past the borders of their container box, especially in italic typefaces. This is a matter of typography, so it is not specified in HTML or CSS specifications, though some CSS material might refer to it. The container box is just a typographer’s playground, and he may decide to cross the borders at times. The height of the container box is the font size, its width is the advance width of the glyph, and these quantities are used by programs when they lay out text; they do not restrict the glyphs.
This is even more so when fake italic (synthetic italic, algorithmically slanted text) is used, and this happens when you use Impact and ask for italic. There is no italic typeface for it, i.e. italic forms of glyphs designed by a typographer, so a browsers needs to ignore your request or to produce fake italic. Since the shapes of letters do not change, except via the slanting, the slanting angle must be fairly large to make “italic” look different from normal. And the amount of slanting makes it more probable to cross the right border of the container box.
In classic typography, such issues can be addressed by adding some spacing when needed. This is difficult to automate and hence mostly not done these days. In CSS, you could use padding-right, but you naturally need to wrap a word or a letter in an element (normally span) so that you have something to apply the styling to, e.g.
<span style="padding-right: 0.08em">World</span>
or
<i style="padding-right: 0.08em">World</i>
This is cumbersome, of course, especially since the amount of spacing needs to depend on the last letter (and on the font and maybe on the first letter of the next word). Alternatively, you could use fixed-width spaces, such as , which corresponds to the methods used in lead typography (a narrow piece of metal was placed after printing letters), but this is not flexible and not reliable (the widths of those characters actually vary by font).
I noticed that some unicode chars are taller than the normal text.
E.g. the diagonal arrows (North East Arrow ↗, South East Arrow ↘, ...), they claim more space on top of the letter than a normal text.
<body style="font-size:48px;">
<div style="border:1px solid #00ff00;float:left;">
1-<br>2-<br>3-<br>4-<br>5-<br>6-<br>7-<br>8-<br>9-
</div>
<div style="border:1px solid #ff0000;float:left;margin-left:5px;">
-1<br>-2 ↗<br>-3<br>-4 ↗<br>-5<br>-6 ↗<br>-7<br>-8 ↗<br>-9
</div>
</body>
http://jsfiddle.net/q5LEt/
You can see the dashes moving down every time an arrow is in the same line.
How can I avoid this behaviour, e.g. by CSS?
You can avoid it by explicitly specifying a line-height:
line-height: 1em;
Re the question in the title: The basic answer is that characters are different. An “A” is taller than an “a”, and some special characters can be even taller than “A”. But there’s more. If you mix fonts, there is additional variation, since fonts have been designed differently. For example, “a” in Verdana is much taller than “a” in Calibri, with the same font size.
Re the code example and the jsfiddle: No font family has been declared, so each browser will use its defaults. What happens when I test it on Firefox is that the problem described indeed occurs, for the reason that “normal” characters have been taken from Times New Roman (the common default font), whereas tehe arrow characters—which do not appear in Times New Roman—have been taken from Segoe UI Symbol. Your mileage may vary, but what usually happens is that fallback font used, such as Segoe UI Symbol, has a larger default line height than Times New Roman has. This causes the line as a whole to take more vertical space.
So the issue does not have nothing to do with heights of letters; it depends on properties of the font. (Well, indirectly there is a connection: fonts like Segoe UI Symbol have relatively large default line height set on them, because they contain glyphs that are rather tall.)
You can usually deal with the symptoms by setting line-height, as #KonradRudolph suggests (though the value of 1em, i.e. setting the text solid, would be somewhat extremist, suitable for special cases but not normal texts).
Alternatively, avoid the problem by selecting a list of fonts that contain all the characters you need in the text and declare font-family with such a list as its value. This means that the arrows and the rest of the text is in the same font, which is generally good even for purely typographic reasons. Finding out the list of fonts takes some time; see my Guide to using special characters in HTML for some tips.
There is em dash and en dash. Is there an "en" equivalent to ? Is there an en equivalent to pure Ascii 32?
I want a better way to write this:
123<span class="spanen"> </span>456<span class="spanen"> </span>789
or this:
123<span class="spanen"> </span>456<span class="spanen"> </span>789
(thin space) should do
Note that has not the same with as an — (—); to separate numbers you should use a narrow no-break space (U+202F).
As others have mentioned, you are better off using the CSS property word-spacing to define the width of your spaces. it's probably a good idea to combine it with white-space:nowrap;
Don't use hacks that make no sense. If you wish to separate some words, I suggest you use the CSS property word-spacing:
.strangeNumbers {
word-spacing: 0.5em;
}
<span class="strangeNumbers">123 456</span>
The Unicode character U+2002 EN SPACE ( , or as entity reference ) is a space with en width.
... and various other non-standard space characters are not properly implemented in some fixed fonts.
This will will foul up your rendering on the web browser end in an uncontrollable manner, and you can't fix it by being specific about the font, because you can't control what actual font is being used by the web browser — even if you specify the font-name or font-family, that doesn't mean the font they have is the same as the font you have.
But you can build a 100%-compatible space of any size you want, though, and it's very easy. The em value is the current font-size. It's the height, but whatever the width of the font is, it's always a constant relative to the height in a fixed-width font. So you can take advantage of that.
Here's how to make a 1/2 width, non-breaking space within the context of a fixed-width font that works with everything. I show it implemented in a span's style="" option, but of course you can make a CSS class instead to make its use less clumsy:
<span style="font-size: .5em;"> </span>
Here's how to make a 1/4 width, non-breaking space:
<span style="font-size: .25em;"> </span>
...and so on.
This always works with space sizes smaller than the current full-width space because the character is shorter than the other characters on the line, so they control the line spacing, not the shorter character.
If you want a space that is wider than one space, use a combination of full spaces and shorter spaces. While you will get a wider space if you use something like 1.5em, you will also get a taller space, and so that will affect the line spacing.
While this solution is annoyingly cumbersome, it has the desirable attribute of always working — which none of the others do.
You could alter your CSS in such:
.spanen{word-spacing:.6em;}