By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,946 Members | 741 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,946 IT Pros & Developers. It's quick & easy.

Preventing italics text from hitting the next character

P: n/a
I recently noticed, once again, how the common implementation of italics can
really disturb. I'm referring to the common phenomenon that there is by
default too little spacing after italics text, so that if you have, say,
<em>Bill</emWatterson
then the last "l" of "Bill" hits the "W" - they may even slighly overlap. I
noticed this long ago, and I discuss it briefly at
http://www.cs.tut.fi/~jkorpela/math/#it
in the context of mathematical notations like <i>f</i>(0).

But the program is general and common and doesn't seem to go away. I don't
know its origins; word processors don't seem to have similar problems.
Anyway, it can be really disturbing e.g. when it makes quite unclear whether
there is a space between words or whether a part of a word has been
italized. This is particularly bad if the text happens to discuss the proper
use of spaces.

Now it seems to me that something like
i, em, cite, dfn, var { padding-right: 0.25em; margin-right: 0; }
would be needed, in general. That's a based on a more of less worst-case
scenario, as with the final "l" and initial "W". It seems to give still
reasonable spacing in other cases as well.

But this approach fails when an italized word is _immediately_ followed by
some non-space character, like ".". It then looks like there's a space
between when there is none. In principle, this is easy: just add
i.n, em.n, cite.n, dfn.n, var.n { padding-right: 0; }
and use class="n" as needed, e.g.
... this is really <em class="n">important</em>.

Yet, this is quite a lot of work, and rather awkward because what we simply
_want_ to say is "don't use right padding for these elements when followed
by a non-space content character". There's of course no way to say that
general rule in CSS as currently defined an implemented.

So is it reasonable to worry about the issue and use the clumsy workaround?
(There's also the risk that if browsers start implementing italics properly,
we would get too much spacing with the workaround.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Oct 12 '06 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Also sprach Jukka K. Korpela:

So is it reasonable to worry about the issue and use the clumsy
workaround?
I would say that rendering text with appropriate spacing between italic and
non-italic words/characters is entirely the user agent's responsibility. To
work around the problem of unwanted space between an italic word and a
following full stop, colon or similar character when applying an extra
padding, one could (should?) include that character in the italic text:

This is <em>italic!</emThis is not.
em { padding-right: .25em; }

But I wouldn't bother. I find it much more annoying when IE produces an
unnecessary horizontal scrollbar or when parts of the italic characters get
cut off (see
http://www.positioniseverything.net/...icbug-ie.html).
(There's also the risk that if browsers start implementing italics
properly,
There's also the risk that if I win a million in the lottery... ;-)

Greetings,
Thomas
Oct 12 '06 #2

P: n/a
On 2006-10-12, Jukka K. Korpela <jk******@cs.tut.fiwrote:
I recently noticed, once again, how the common implementation of italics can
really disturb. I'm referring to the common phenomenon that there is by
default too little spacing after italics text, so that if you have, say,
<em>Bill</emWatterson
then the last "l" of "Bill" hits the "W" - they may even slighly overlap.
[snip]
So is it reasonable to worry about the issue and use the clumsy workaround?
(There's also the risk that if browsers start implementing italics properly,
we would get too much spacing with the workaround.)
Some of them already implement italics if not properly at least
differently.

If you try your example <em>Bill</emWatterson and also set a
background-color on the <em>, you can see exactly where the UA has
decided the right edge of the inline box generated by the <emshould
be.

Firefox uses the advance box of the rightmost glyph, which doesn't quite
completely enclose the 'l'; but Konqueror uses its bounding box, which
does. This also has the effect that you don't get the overhang.

As far as I know CSS 2.1 doesn't specify one way or the other. But using
the bounding box seems to make more sense.
Oct 12 '06 #3

P: n/a
Jukka K. Korpela schrieb:
I recently noticed, once again, how the common implementation of italics
can really disturb. I'm referring to the common phenomenon that there is
by default too little spacing after italics text, so that if you have, say,
<em>Bill</emWatterson
then the last "l" of "Bill" hits the "W" - they may even slighly
overlap. I noticed this long ago, and I discuss it briefly at
http://www.cs.tut.fi/~jkorpela/math/#it
in the context of mathematical notations like <i>f</i>(0).

But the program is general and common and doesn't seem to go away. I
don't know its origins; word processors don't seem to have similar
problems.
I believe to remember having seen the same (not too many years ago) in
MS Word and even QuarkXPress screen display, while the printed rendering
was ok.
Anyway, it can be really disturbing e.g. when it makes quite
unclear whether there is a space between words or whether a part of a
word has been italized. This is particularly bad if the text happens to
discuss the proper use of spaces.
In this case I suggest a special markup for the example spaces rather
than for the surrounding text - such as coloring them or surrounding
them by [ ] or whatever.
Now it seems to me that something like
i, em, cite, dfn, var { padding-right: 0.25em; margin-right: 0; }
would be needed, in general. That's a based on a more of less worst-case
scenario, as with the final "l" and initial "W". It seems to give still
reasonable spacing in other cases as well.

But this approach fails when an italized word is _immediately_ followed
by some non-space character, like ".". It then looks like there's a
space between when there is none. In principle, this is easy: just add
i.n, em.n, cite.n, dfn.n, var.n { padding-right: 0; }
and use class="n" as needed, e.g.
... this is really <em class="n">important</em>.
I would consider this as breaking the concept of separating contents
from presentation.
Yet, this is quite a lot of work, and rather awkward because what we
simply _want_ to say is "don't use right padding for these elements when
followed by a non-space content character". There's of course no way to
say that general rule in CSS as currently defined an implemented.

So is it reasonable to worry about the issue and use the clumsy
workaround? (There's also the risk that if browsers start implementing
italics properly, we would get too much spacing with the workaround.)
I agree with you that the effect you describe is ugly and annoying.
Although I agree with Thomas that text rendering should be completely
left to the user agent. In order to do a proper microtypography it is
essential to know the rendering situation. As stated by others and by
yourself in the above paragraph, any trickery done for today's average
visual browsers could possibly break in browsers with better rendering,
or in any browser using a font you did not include in your tests. It is
yet likely to break when printing.

I used to do high quality print typography, and it is my experience that
microtypographical adjustments usually only work for the special
situation they are done for. Change the font face and the perfectly
adjusted headline looks crappy, change the size and your decent spacing
results in looking too wide or too compact. In web pages these effects
can even be multiplied by the fact that all measuring might be rounded
up or down to entire pixels.

That's why I think that for web authoring, relying on the OS, browser
and font defaults is least likely to break, though in some cases you may
be able to get better results for an average situation.

--
Markus
Oct 13 '06 #4

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
i, em, cite, dfn, var { padding-right: 0.25em; margin-right: 0; }

But this approach fails when an italized word is _immediately_ followed by
some non-space character, like ".". It then looks like there's a space
between when there is none. In principle, this is easy: just add
i.n, em.n, cite.n, dfn.n, var.n { padding-right: 0; }
and use class="n" as needed, e.g.
... this is really <em class="n">important</em>.

Yet, this is quite a lot of work, and rather awkward because what we simply
_want_ to say is "don't use right padding for these elements when followed
by a non-space content character". There's of course no way to say that
general rule in CSS as currently defined an implemented.

So is it reasonable to worry about the issue and use the clumsy workaround?

Generally, punctuation immediately following italicized text is also
italicized (at least in traditional typesetting), so the situation would
be handled solely by markup placement with no need for a second selector:

.... this is really <em>important.</em>

While this markup is structurally more correct (or at least more
traditional), presentationally the right-padding increases whitespace
between sentences, so perhaps a second selector is needed after all.

--/<eith
Oct 13 '06 #5

P: n/a
In article <cX*****************@reader1.news.jippii.net>,
jk******@cs.tut.fi says...
I recently noticed, once again, how the common implementation of italics can
really disturb. I'm referring to the common phenomenon that there is by
default too little spacing after italics text, so that if you have, say,
<em>Bill</emWatterson
>
My usual method is to code <emitalics </em>like this - with the gap
inside the tags. If I don't want a gap, I leave it out. Sometimes
there's a danger in overthinking a problem. Of course, I've never
written a discussion paper on the proper use of spaces.
Oct 15 '06 #6

P: n/a
Scripsit Keith Baird:
Generally, punctuation immediately following italicized text is also
italicized (at least in traditional typesetting), so the situation
would be handled solely by markup placement with no need for a second
selector:

... this is really <em>important.</em>
It's structurally illogical, since the intent is not to emphasize the
period, just the word. Besides, traditional typesetting does not always
italicize the punctuation that follows an italicized word; commonly, a
parenthesis is _not_ italicized (even if it logically belongs to the
fragment of text that is being emphasized or otherwise made special).

Moreover, there are several cases, like
1) <em>foo</em>.
2) <em>foo</embar
3) <i>f</i>(0)
and your suggestion only deals with case 1. Assuming we generally add right
padding to elements that appear in italics, then 2 is no problem (that's a
case where we really want the extra spacing), but 3 is. Case 1 could be
fixed using your method, since the spacing would appear after the period,
which is OK, but I don't like this idea of using slightly illogical markup.
I'd rather use honestly presentational markup in the sense that I add
attributes that lack semantic meaning byt will be used for presentational
purposes.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Oct 15 '06 #7

P: n/a
Scripsit Joe (GKF):
My usual method is to code <emitalics </em>like this - with the gap
inside the tags. If I don't want a gap, I leave it out. Sometimes
there's a danger in overthinking a problem.
That's simple indeed, and it relies on a widespread browser bug, so it may
look safe. (The bug is inappropriate handling of whitespace; consecutive
whitespace characters should be collapsed into a single space.) Of course,
it would be awkward to remove the trick later (as opposite to removing an
extra CSS rule).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Oct 15 '06 #8

P: n/a
In article <0d*****************@reader1.news.jippii.net>,
jk******@cs.tut.fi says...
Scripsit Joe (GKF):
My usual method is to code <emitalics </em>like this - with the gap
inside the tags. If I don't want a gap, I leave it out. Sometimes
there's a danger in overthinking a problem.

That's simple indeed, and it relies on a widespread browser bug, so it may
look safe. (The bug is inappropriate handling of whitespace; consecutive
whitespace characters should be collapsed into a single space.) Of course,
it would be awkward to remove the trick later (as opposite to removing an
extra CSS rule).
I don't understand what you're telling me. The method I outlined doesn't
need or use consecutive spaces; rather the space is placed before the
</emrather than after it.
Like <em>this </em>example shows. One space.
For words requiring punctuation immediately after, I use <em>this</em>.
No following space. I disagree with whoever it was who advocated putting
the punctuation inside the <em></em>, that is hardly ever appropriate.

By the way, if I want to make something that looks like <i>f</i>(0), I
usually use &#fnof; but I could use ƒ or even or &#x0192 if I
wanted.
Oct 17 '06 #9

P: n/a

Joe (GKF) wrote:
I don't understand what you're telling me. The method I outlined doesn't
need or use consecutive spaces;
Ask yourself this: Is "space" <em"space" a pair of consecutive
spaces?
As <emdoesn't generate any content, what happens to those two spaces
?
Do they become consecutive ?

Oct 17 '06 #10

P: n/a
Andy Dingley wrote:
Joe (GKF) wrote:
>I don't understand what you're telling me. The method I outlined doesn't
need or use consecutive spaces;

Ask yourself this: Is "space" <em"space" a pair of consecutive
spaces?
He didn't have "space" <em"space". He had "space" </em>"not-a-space".
As <emdoesn't generate any content, what happens to those two spaces
?
Do they become consecutive ?
Oct 17 '06 #11

P: n/a
Scripsit Joe (GKF):
I don't understand what you're telling me. The method I outlined doesn't
need or use consecutive spaces; rather the space is placed before the
</emrather than after it.
Like <em>this </em>example shows. One space.
I see. But you wrote: "My usual method is to code <emitalics </em>like
this - with the
gap inside the tags." That looked a bit vague to me - you surely don't have
any gap inside tags but _between_ tags.

So it's a _different_ browser misbehavior that you are relying on. In HTML,
spaces are supposed to be separators between words, so it's illogical that
it matters whether a space is inside some markup or not, as regards to
rendering the space.
By the way, if I want to make something that looks like <i>f</i>(0), I
usually use &#fnof; but I could use ƒ or even or &#x0192 if I
wanted.
If you do that, you're doing the wrong thing. Those references denote U+0192
LATIN SMALL LETTER F WITH HOOK. Although it is also known as "function
symbol" (as well as "Florin currency symbol"), it is not at all the same as
letter f in italics.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Oct 17 '06 #12

P: n/a
Jukka K. Korpela schrieb:
So it's a _different_ browser misbehavior that you are relying on. In
HTML, spaces are supposed to be separators between words, so it's
illogical that it matters whether a space is inside some markup or not,
as regards to rendering the space.
Not if the markup affects type rendering, as the width of a space is
defined in the typeface, and also affected by possible style suggestions
such as font-size, font-weight, font-stretch or letter-spacing. Thus,
differences in the rendering of <em>Text</emand <em>Text </em>are (or
should be in my nit-picking typographers's oppinion):

- Possible in normal cases (em element rendered as italic), as the with
of a space in a roman and an italic typeface can differ in a decently
designed font family

- Very likely if extra font styling is applied to the em element;
imagine some super-interpretation of "emphasis", such as:
em {
font:bolder 150% monospace;
font-stretch:ultra-expanded;
letter-spacing:1em
}

--
Markus
Oct 18 '06 #13

P: n/a
In article <Yr****************@reader1.news.jippii.net>,
jk******@cs.tut.fi says...
Scripsit Joe (GKF):
Like <em>this </em>example shows. One space.
>
So it's a _different_ browser misbehavior that you are relying on. In HTML,
spaces are supposed to be separators between words, so it's illogical that
it matters whether a space is inside some markup or not, as regards to
rendering the space.
Many things seem illogical until you realise what is actually going on.

Because of the way computers do such things, it is possible for an
'italicised' character to lean out of its assigned space.

The method I use is repeatable and works everywhere I have tried it,
which is enough for me.
I consider it more an 'undocumented feature' than a misbehaviour. In
any event, if it's not enough for you, so be it.
By the way, if I want to make something that looks like <i>f</i>(0), I
usually use &#fnof; but I could use ƒ or even or &#x0192 if I
wanted.

If you do that, you're doing the wrong thing. Those references denote U+0192
LATIN SMALL LETTER F WITH HOOK. Although it is also known as "function
symbol" (as well as "Florin currency symbol"), it is not at all the same as
letter f in italics.
Quite so, and I would only use it as such.
Whenever I have seen <i>f</i>(0), it's always meant 'function of'(0),
and your original post (where you say ..."in the context of mathematical
notations like <i>f</i>(0)...") led me to believe that is what it meant
in this case.

Oct 18 '06 #14

P: n/a
Joe (GKF) wrote:
In article <Yr****************@reader1.news.jippii.net>,
jk******@cs.tut.fi says...
>Scripsit Joe (GKF):
>> Like <em>this </em>example shows. One space.
>So it's a _different_ browser misbehavior that you are relying on. In HTML,
spaces are supposed to be separators between words, so it's illogical that
it matters whether a space is inside some markup or not, as regards to
rendering the space.
Many things seem illogical until you realise what is actually going on.

Because of the way computers do such things, it is possible for an
'italicised' character to lean out of its assigned space.
A character's "assigned space" ought to be the space it takes up, so
that by definition it can't lean out of it. ("Assigned" is a loose term,
of course, since kerning will result in the overlap of two characters'
assigned spaces.)
Oct 19 '06 #15

P: n/a
On 2006-10-19, Harlan Messinger <hm*******************@comcast.netwrote:
Joe (GKF) wrote:
>In article <Yr****************@reader1.news.jippii.net>,
jk******@cs.tut.fi says...
>>Scripsit Joe (GKF):
>>> Like <em>this </em>example shows. One space.
>>So it's a _different_ browser misbehavior that you are relying on. In HTML,
spaces are supposed to be separators between words, so it's illogical that
it matters whether a space is inside some markup or not, as regards to
rendering the space.
Many things seem illogical until you realise what is actually going on.

Because of the way computers do such things, it is possible for an
'italicised' character to lean out of its assigned space.

A character's "assigned space" ought to be the space it takes up, so
that by definition it can't lean out of it. ("Assigned" is a loose term,
of course, since kerning will result in the overlap of two characters'
assigned spaces.)
In font terminology, a glyph has a "bounding box", and an "advance box".

No part of the glyph is ever outside the bounding box by definition, but
parts of it may be outside the advance box. This is common with italic
glyphs.

When you lay out some text, you place the advance boxes next to one
another. This means that glyph bounding boxes may overlap.
Oct 19 '06 #16

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
... this is really <em>important.</em>

It's structurally illogical, since the intent is not to emphasize the
period, just the word.
Punctuation is part of the logical content of a sentence; marking it up
jointly with the text is, therefore, structurally logical.

--/<eith
Oct 20 '06 #17

P: n/a
On 2006-10-20, Keith Baird wrote:
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
... this is really <em>important.</em>

It's structurally illogical, since the intent is not to emphasize the
period, just the word.

Punctuation is part of the logical content of a sentence; marking it up
jointly with the text is, therefore, structurally logical.
As you say, it "is part of the logical content of a sentence"; it
is not part of the content (logical or otherwise) of the word, and
therefore it is _not_ structually logical to include it.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
================================================== =================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Oct 20 '06 #18

P: n/a
In article <sl*********************@bowser.marioworld>,
sp******@spam.eggs says...
On 2006-10-19, Harlan Messinger <hm*******************@comcast.netwrote:
Joe (GKF) wrote:
In article <Yr****************@reader1.news.jippii.net>,
jk******@cs.tut.fi says...
Scripsit Joe (GKF):
Like <em>this </em>example shows. One space.

So it's a _different_ browser misbehavior that you are relying on. In HTML,
spaces are supposed to be separators between words, so it's illogical that
it matters whether a space is inside some markup or not, as regards to
rendering the space.

Many things seem illogical until you realise what is actually going on.

Because of the way computers do such things, it is possible for an
'italicised' character to lean out of its assigned space.
A character's "assigned space" ought to be the space it takes up, so
that by definition it can't lean out of it. ("Assigned" is a loose term,
of course, since kerning will result in the overlap of two characters'
assigned spaces.)

In font terminology, a glyph has a "bounding box", and an "advance box".

No part of the glyph is ever outside the bounding box by definition, but
parts of it may be outside the advance box. This is common with italic
glyphs.

When you lay out some text, you place the advance boxes next to one
another. This means that glyph bounding boxes may overlap.
Thanks Ben - I don't know the correct terminology.You're right, of
course. I meant to convey that when converting a character to "italic",
the computer assigns space (the advance box), puts the character in it
and then pushes it over a bit, causing it to possibly fall out of the
box.
Anyway, it seems Mr Korpela has lost interest and I was never all that
fussed.
Oct 21 '06 #19

P: n/a
Keith Baird wrote:
Punctuation is part of the logical content of a sentence; marking it up
jointly with the text is, therefore, structurally logical.
Chris F.A. Johnson wrote:
As you say, it "is part of the logical content of a sentence"; it
is not part of the content (logical or otherwise) of the word, and
therefore it is _not_ structually logical to include it.
There is a logical relationship between a sentence's terminal
punctuation and the *last* word in a sentence, therefore it is
structually logical to apply the same presentation to both because
together they end the sentence (which neither can do in isolation).

This is an issue long-solved in traditional practice, a fact unaltered
by historically recent notions of separation of meaning and
presentation. Punctuation is, after all, a form of logical text markup
(vastly) predating HTML/XML/CSS, and there is no need to fabricate or
rationalize new practice. The question only concerned physical
presentation of text, so it is reasonable to apply established text
conventions.

--/<eith
Oct 23 '06 #20

P: n/a
On 2006-10-23, Keith Baird wrote:
Keith Baird wrote:
>Punctuation is part of the logical content of a sentence; marking it up
jointly with the text is, therefore, structurally logical.

Chris F.A. Johnson wrote:
>As you say, it "is part of the logical content of a sentence"; it
is not part of the content (logical or otherwise) of the word, and
therefore it is _not_ structually logical to include it.

There is a logical relationship between a sentence's terminal
punctuation and the *last* word in a sentence, therefore it is
structually logical to apply the same presentation to both because
together they end the sentence (which neither can do in isolation).
There is a positional relationship, nothing more.
This is an issue long-solved in traditional practice, a fact unaltered
by historically recent notions of separation of meaning and
presentation. Punctuation is, after all, a form of logical text markup
(vastly) predating HTML/XML/CSS, and there is no need to fabricate or
rationalize new practice. The question only concerned physical
presentation of text, so it is reasonable to apply established text
conventions.
In 20 years of graphic design and typesetting, I never saw the
punctuation included like that.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
================================================== =================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Oct 25 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.