nobr markup
Internet Explorer (IE) divides strings into two lines in a
problematic way. It treats any hyphen as a potential
word break point, thus even breaking nobr markup or some other methods.
Consider using such methods, when you have a string that
should not be broken across lines and contains any of the following
characters:
As regards to the the dual problem
"how can I suggest to a browser that
a string can be broken",
the nonstandard wbr markup may help sometimes,
but it is best to avoid long strings that contain no spaces.
This document discusses the nobr markup
mainly as a tool for preventing certain odd behavior on IE.
It can also be used to prevent browsers from dividing some
text to two lines even between words, though for such purposes
there is an alternative method which does no require nonstandard markup:
using
)
instead of normal spaces.
The testing has been carried out on Windows versions of IE. There are differences between IE versions. For example, some problems described here were detected on IE 4 but were fixed on IE 5. And unlike previous versions, IE 6 seems to split after a solidus "/" character. This is useful in some cases, harmful in many other cases.
The Opera browser behaves to some extent the same way as IE. On Opera too, there are version differences in this respect.
I have observed that IE may handle, at least in some situations, any of the following as possible line break points inside a string of characters:
The list is most probably not comprehensive.
See my description of ISO Latin 1 for notes on the various uses of these and other characters in various contexts.
This means, for example, that "Latin-1" can be broken to
As regards to
guillemets, note that
in the French quotation style, « comme ici », it
seems to be sufficient to use a
But in other guillemet usage styles,
nobr to prevent that
Generally, it's probably best to accept that risk –
except perhaps in headings and other very essential texts,
where you might consider whether you wish to take some precautions.
Breaking after the percent sign %
is very nasty in some situations where that character is used
in a special meaning in a programming language or otherwise
(e.g. URLs).
In particular, expressions like %foo and %20
can be split so that % appears alone at the end of a line!
Luckily IE does not seem to split strings like "%:n".
Breaking after the degree sign ° is harmful too, especially in contexts like "100 °C".
In my tests, IE has broken a line after the cent sign ¢ too. But I haven't seen any real-life situation where that could occur. (IE does not break "¢:n" for example.)
Moreover, IE treats the combination &# as breakable.
This is very nasty in a document discussing
character references like
Ä. It seems that this problem
has been fixed in IE 5.
IE also introduces a break point between the solidus and the
reverse solidus in the combination /\.
This is admittedly a rare character sequence, but I noticed this problem
when actually using it in a specific context where
it is essential.
The description above is probably not exhaustive. And the IE behavior may depend on version number, platform, and context (specific character sequences). I haven't tested much what IE does with other than ISO Latin 1 characters, but IE has broken a line after the following "Windows characters": ellipsis, permile, bullet, em dash, en dash, right single guillemet, right single quote, right double quote, and before the following: left single guillemet, left single quote, left double quote.
Quite often, splitting a word containing a hyphen is acceptable, even desirable. It can make the document look better, especially if there are long words in the text, including compound words containing a hyphen. But the problem is that IE treats any hyphen as a possible line break point and breaks even a three- or two-character string.
Moreover, breaking after some special characters, though occasionally useful, is a potential source of great confusion and even ambiguity.
There are several alternative approaches to preventing
undesired line breaks, and since they operate at different level of text
representation, they could even be used in a combination. The approaches are
summarized in the following table.
In the first four approaches, the example shows how to prevent
a line break between the number and the unit in "100 m". In the
other approaches, the example expression is
| Level | Method | Example | Notes |
|---|---|---|---|
| HTML markup | nobr element
| <nobr>100 m</nobr> | Nonstandard, but works widely. |
| HTML markup | nowrap attribute
| <td nowrap>100 m</td> | Only applicable to table cells. Severe limitations in support. |
| CSS style sheet | | <span style= | Usually works when set on the innermost element. |
| Character level | no-break space | 100 m | Works well to prevent inter-word breaks but not for the problems discussed here. |
| Character level | non-breaking hyphen | A‑1 | Applies to preventing a break after a hyphen. Limited usefulness due to font problems. |
| Character level | word joiner | A-⁠1 | Wide applicability in principle, but very limited usefulness due to lack of support. |
| Character level | zero-width no-break space | A-1 | Very limited usefulness due to lack of consistent support on IE. |
There are many quirks and oddities in browser support to these
methods. There is
page for testing the methods
in some simple cases.
Generally, nobr works most often.
nobr markupIt seems that in general the only cure is to use the nonstandard,
Netscape-invented (!) nobr markup.
It has never been adequately defined,
and browsers generally treat it in a command-like fashion:
<nobr> is taken as "disallow line breaks
from now on" and
</nobr> says "line breaks allowed from now on".
But it is safest to use it as
text-level markup
only. This should suffice, since we normally would use
nobr for short pieces of text
only, as in
<nobr>vis-a-vis</nobr><nobr>-a</nobr>.
A very short quotation using guillemets could be put
into a single nobr element. But generally the approach
of making a quotation as a whole non-breakable is not suitable.
Instead, you can put just the initial guillemet and the first word inside
nobr markup, like this:
<nobr>»wie</nobr> hier«
Assuming that future browsers will continue
supporting nobr for preventing line breaks, which is rather probable,
it will assumably prevent hyphenation too.
So if you now use, say, the markup
<nobr>»Anführungszeichen«</nobr>,
then browsers will really treat it as non-breakable even when they have
become intelligent enough to apply hyphenation to words.
The nobr markup
could also be used to keep images on one "line",
side by side. Note that then
WebTV may scale images to make them fit.
As an alternative to using nobr,
you could put images into a
table.
won't doWe cannot, in general, solve the problems discussed here by using
no-break spaces ( ).
If you insert a
In special cases it might appear to be acceptable and even desirable to have extra spacing horizontally, especially in situations like f (0); but it is a moot point, as explained in my notes on mathematic notations in HTML.
nowrap may workIn special cases,
when the data is in a
table cell
and it is adequate to prevent all line breaks in it,
you can use the nowrap attribute for the td
or th element. That attribute is "deprecated", but
it is still valid.
Note, however, that browsers seem to ignore it, if a fixed width is set for the cell so that the content doesn't fit into that without wrapping. This happens for a fixed width in pixels, em units, etc.
white-space Using style
sheets (CSS), we might consider using
the CSS declaration
<span style=".
This is strange in the sense that
the hyphen character is not a white space character.
The CSS 2 specification describes the <br> markup) be suppressed.
Modern browsers generally apply this interpretation.
According to the original CSS 2 specification, the
property applies to block-level elements only, making it useless
for preventing undesired breaks in paragraphs or similar constructs
in principle. However, this has been changed in an
"Errata" and in the
CSS 2.1 draft. They permit
There is a bug in IE: if you set
span or div) and
set
In theory, the Unicode standard says that
the character to be used to prevent line breaks in general is the
word joiner (WJ) character
(U+2060, representable in HTML as ⁠):
The word joiner character is the preferred choice for an invisible character to keep other characters together that would otherwise be split across the line at a direct break.
This would mean that in order to keep e.g. the string
Even when a rare font (e.g., Code2000) containing a glyph for the word joiner is used, the method fails. IE still divides the text the same way as without the word joiner, apparently because it does not know the special meaning of this character.
It's no wonder that this method does not work (yet), since the
word joiner character
was introduced into Unicode as late as in
Version 3.2
(date:
We might also consider using the zero-width no-break space (ZWNBSP) character. Within text, it has the same meaning as the word joiner, and it has been in Unicode much longer. It is recognized by IE in the sense that the browser knows that it has no glyph, but it depends on IE version whether it prevents a line break; on IE 7, it does not. In principle, its use for the purpose of preventing line breaks has been officially discouraged, since it is also used as a byte order mark, and it was deemed appropriate to reserve it for that very purpose.
In practice, you can represent ZWNBSP as
 or
.
Thus, in order to keep e.g. the string
nobrSince nobr is not in any HTML specifications,
it causes problems in validation.
You can use nobr and still validate your pages,
if you use a modified Document Type Definition.
For an explanation, see
Creating your own DTD for HTML validation.
Basically you would use a DTD containing the following modified clause (addition indicated with emphasis):
<!ENTITY % phrase "EM | STRONG | DFN | CODE | NOBR |
SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >
I have made modified versions of HTML 4.01 DTDs:
http://www.cs.tut.fi/~jkorpela/html/strict.dtd (for Strict HTML 4.01)
http://www.cs.tut.fi/~jkorpela/html/loose.dtd (for Transitional HTML 4.01)
http://www.cs.tut.fi/~jkorpela/html/frameset.dtd (for framesets)
It is preferable to copy the DTD you need, instead of
referring to the addresses above.
You would use a DOCTYPE declaration like the following
(instead of a normal DOCTYPE which uses the
PUBLIC keyword), naturally replacing the
address inside quotation marks as needed:
<!DOCTYPE HTML SYSTEM "http://www.cs.tut.fi/~jkorpela/html/strict.dtd">
Note that the W3C validator
has an internal limitation ("the number of tokens in a group must not exceed
GRPCNT (64)") which prevents you from using it in cases like this;
the addition of NOBR happens to exceed that limit!
So you need to use e.g. the
WDG validator instead.
Naturally, if you use a modified DTD, you can't
claim conformance to HTML 4.01 or some other specification.
If your customer or boss requires such conformance, you are
out of luck. You might still try to explain to him that your
use of nobr is a workaround to an IE bug/deficiency.
As regards to the hyphen, one might in theory replace it by various
other Unicode characters,
hoping that IE does not regard them as line break points.
They can be presented using
character references
(&#number;‑
Just to illustrate what happens on your current browser,
here are some examples:
First a compound word with a
normal ASCII hyphen:
Since
the use of real dashes
has been problematic in HTML, authors often use
hyphens as surrogates for dashes.
This often causes situations where the IE behavior of breaking a line
after a hyphen is highly undesirable. An especially bad case is
5 - 6
where a hyphen surrounded by some space is used as a surrogate for
a dash, and
5 - 6but IE, although it usually obeys the semantics of the
5 - 6
Note that the second line is indented, since it begins with
a
The only practical way to prevent the
madness is to use nobr. Then you might just as well
use normal spaces instead of
<nobr>5 - 6</nobr>
Luckily it seems that when there are consecutive hyphens,
IE breaks only after the last one. In particular, this means
that if two consecutive hyphens are used between words--which is
a recommended surrogate for em dash in English--then IE breaks
after the second one only. The situation is more problematic
when other
dash surrogate practices
are used.
When dashes would be used as
"dashes that enclose" - as here, effectively as literary
style counterparts of nobr element. That would often introduce large
nonbreakable "chunks" of text, which is undesirable.
Since breaking a line after such a dash would be acceptable,
it's best to use a
...of parentheses - it might...
Telephone (and fax) numbers cause line breaking problems fairly
often. This might happen in tables: if you make a telephone catalogue a table, putting
the numbers into one column, a browser might break the content of
a number cell into two lines. This is not very nice, but you
can prevent it by using the
nowrap attribute
as explained above. Assuming that the numbers are written
as suggested below, you could alternatively just use
Problems are often caused by the varying ways that people
use to present phone numbers. Consider the following example:
+358 (0)9 451 4319
When used inside running text, this could create the problem
discussed here, since IE might split it after the closing parenthesis.
The appropriate solution is to use a correct notation, as
standardized in the
E.123 recommendation by
CCITT/
(09) 451 4319
or the international use notation
+358 9 451 4319
or, when applicable, both of them.
(The parentheses should be omitted from the national use notation
if the first part of the number is not an area code
that can be omitted when dialing inside the area but a part of the
number that must always be dialed.)
Luckily it seems that when you write numbers that way, using
The Opera browser, at
least version 6.0 on Windows, seems to
treat hyphen the same way as IE. I have not made any detailed study,
but I have observed that Opera may even split
Opera partly behaves even wilder than IE. For example, it has been observed to treat a solidus (slash) as a break character in the sense that a line break is permitted after it. This is actually useful when long URLs appear in the text, and in some other cases. But Opera may even break "1/2" into "1/" and "2"! (For this particular case, you can avoid the problem using the vulgar fraction character ½.)
The HTML specifications say:
Except for preformatted elements - -, each block structuring element is regarded as a paragraph by taking the data characters in its content and the content of its descendant elements, concatenating them, and splitting the result into words, separated by space, tab, or record end characters (and perhaps hyphen characters). The sequence of words is typeset as a paragraph by breaking it into lines.
In HTML, there are two types of hyphens: the plain hyphen and the soft hyphen. The plain hyphen should be interpreted by a user agent as just another character. The soft hyphen tells the user agent where a line break can occur.
The former allows, with the words "(and perhaps hyphen characters)", line breaking at any hyphen. So from this perspective, IE's behavior with hyphens is not a bug, though of poor quality. The latter on the other hand seems to prohibit such line breaks. Only soft hyphens would be permissible line breaking positions. This is a a highly debatable approach, on two accounts: the soft hyphen problem (the meaning of the character and the way browsers handle it), and the fact that this would seem to mean that the normal hyphen is regarded as nonbreakable. It's hard to tell whether the latter was actually meant, but this part of the specification seems to imply that IE's breaking behavior is to be classified as a bug.
It is probably not the intent in any of the specifications to prohibit word division when it occurs according to the rules of the natural language used and is otherwise acceptable. Since IE does not recognize the language, it should not split words, or any strings of non-whitespace characters. For special characters, the issue is rather complicated; see Unicode Technical Report #14: Line Breaking Properties (technicality alert!), which seems to allow a "direct break" between an alphanumeric character and an opening parenthesis, for example. This is hardly a good idea in general, though. It would even allow very dishono(u)rable breaks! I have written some more notes on these issues: Unicode line breaking rules: explanations and criticism.
Alan Wood has drawn my attention to situations where a very long string contains hyphens and the presentation is much better, if a browser can use hyphens as potential line break points. Such strings occur in chemistry, in systematic names of chemical compounds, as demonstrated well by Alan's page Abamectin fact sheet.
Admittedly, in most cases a hyphen is permissible
line break point, if reasonable constraints are imposed so that e.g.
a string like
Web browsers generally don't do word division; the IE behavior
discussed above is an exception and applies to some special characters only.
We mostly just have to live with that, until browsers become better and
start recognizing the language used in a document
(hopefully from lang attributes)
and applying language-specific hyphenation rules.
Explicit hyphenation hints are often suggested as a potential
solution, but they are a clumsy way.
However, browsers now support the
soft hyphen
reasonably well, so that it may be feasible to
to give hyphenation hints for words in special cases, e.g.
for very long words.
Moreover, browsers generally don't break long strings that don't contain spaces. Sometimes we have "words" (sequences of characters with no spaces inside them) that are so long that the presentation becomes very bad if the browser can't split them. This typically happens in more or less technical contexts, like writing about long URLs. (Long URLs aren't usually a problem, because they appear only in attribute values in HTML markup, not as the textual content. But sometimes you have a real need to mention a URL e.g. as an example.)
Moreover, browsers may refuse to break even at spaces,
i.e. to separate strings from each other even
if there is a normal space between them.
Internet Explorer 7 seems to behave that way when the latter string
begins with a colon ":". Such strings are common in some special areas.
For example, if you discuss CSS and mention
"the pseudoelement :before",
IE 7 would treat the string as indivisible,
unless you include some explicit line breaking hint before the colon. This would result in poor rendering like the following:
:before in the text, IE 7 would treat the
string "pseudoelement :before" as indivisible. That is, it
would not put "pseudoelement" on one line and ":before"
on the next.
IE 7 has similar problems with other characters, such as a period ".", at the start of a string.
Moreover, IE 7 does not divide between a closing quotation mark and an opening parenthesis. This happens both for typographically correct (for English) “curly” quotation marks and for "vertical" (ASCII) quotation marks.
There are two different issues here:
­ or, when using Windows in
authoring, by typing Alt+0173).
Beware that some old browsers
may still display it as a normal hyphen!
C:\Program Files\Netscape\Communicator\
Program\NetHelp\Netscape
Splitting a word containing a hyphen, e.g.
If a URL, filename or some similar construct is split over several
lines, one should clearly indicate what's going on
so that the user knows what the actual URL or filename is.
Usually an explicit note is needed. In some cases however you could use the
method for "delimiting a URI in context
with the characters < and >
or with quotation marks,
as suggested in appendix C of
RFC 3986.
word-wrap propertyAccording to Microsoft's documents,
IE supports, from version 5.5 onwards, a CSS property named
word-wrapnormal is the normal behavior
(content exceeds the boundaries of its container) whereas
break-worddiv elements
with a fixed width
of 200 pixels and content that most probably exceeds the width,
and the second element has
word-wrap: break-word
Some other browsers, such as as Firefox (3.1. and newer) and Safari,
have started supporting word-wrap
When used for a pre element,
word-wrap: break-word
You can of course specify explicit line breaks using
br markup
(or pre markup).
This is often the best way to deal with the problem at hand.
However, it is rather inflexible when the long strings occur within
running text - where you would like to have the browser do its
normal formatting so that the presentation adjusts to the available
canvas width but so that line breaks may occur at some points inside
the problematic strings.
wbr ("word break")wbrAccording to Netscape's old HTML Tag Reference,
The WBR tag marks a place where a line break can take place. It does not necessarily always result in a line break; rather, it says that line breaks are allowed at this place. You could use it, for example, inside a NOBR tag to allow a line break. Navigator 1.1
The description is vague, but actual implementations treat wbr
as allowing a "string split" rather than
normal word division, i.e. no hyphen is introduced.
wbrThe following markup samples illustrate possible uses
of web:
Enter the command View/<wbr>Preferences/<wbr>Display/<wbr>Common.
We use the pseudoelement <wbr>:before.
Check your <wbr>.htaccess file.
This is an "example" <wbr>(really).Moreover,
wbr could be used to suggest possible break points
using markup like
<http://www.hut.fi/<wbr>u/<wbr>jkorpela/<wbr>html/<wbr>nobr.html>.
Here is a more complicated example as displayed on your browser:
<http://. It's probably a good idea to use <wbr>
only after such characters which visually suggest that there might be something
that follows, such as a solidus, an equals sign, or an ampersand.
One might consider using nobr and wbr
together to divide text into chunks which may not be split across
lines but so that line breaks between the chunks are permitted.
But there does not seem to be any particular reason to use wbr
for such purposes.
You can usually just put each chunk into a nobr
element of its own, with normal spaces or line breaks between them of
course.
wbrThe wbr element is empty (no end tag is used)
and it has no attributes. That is, it is always just the tag
<wbr>.
It is comparable to
<br> except that
<br> forces a line break in rendering whereas
<wbr> allows a line break.
Should you wish to use it in XHTML, you would have to use the
XML convention for empty elements, i.e.
<wbr />.
wbr (historical)Other browsers such as IE
have support to
wbr, too.
However some reports about browser support to it are incorrect;
for example, there does not seem to be support to it on Opera.
On the other hand,
in most cases where you would use wbr, this does not
matter, since
Opera automatically splits long strings e.g.
after a "/" character.
It seems that around version 4.5 or so,
Netscape itself
dropped support to wbr.
The support
was restored in Netscape 6, later dropped again!
Anyway,
this is ancient history now, since Netscape browsers
have very little users, and support to wbr
exists in Mozilla Firefox.
Moreover, as if this were not mad enough, it seems that on IE 5,
deviating from IE 4 and IE 6,
wbr works only inside nobr markup, so
you would have to use it too, around the string. But then Opera
would treat the string as unbreakable, since it recognizes
nobr but not wbr.
Sufficiently new versions of Opera will
handle wbr in the intended way, if you use the following
style sheet, which effectively tells the browser to insert U+200B,
i.e. ZWSP after each
wbr element:
wbr:after { content: "\00200B"; }For some odd reason, IE 8 stopped supporting
wbr in “standards
mode”, so now some additional trickery is needed.
IE 8 does not even recognize the wbr element in
“standards
mode,” so it does not help to assign a CSS rule for that
element. Instead, we need to use extra markup that introduces
an empty element, for which we can add ZWSP as generated content.
(If we used ZWSP as character data in document content, we would
have problems with older browsers, as described later.)
For example, to allow a line break after
“/” in
“foo/bar,”
we could write e.g.
foo/<wbr><a class="wbr"></a>bar
and use the CSS rule
.wbr:after { content: "\00200B"; }
The use of the a element instead of the
span element here is just a convenience:
shorter element name. As such,
without any attributes except class,
the a element
is semantically empty.
An alternative approach is to use the trick developed by Microsoft
for throwing IE 8 into
“IE 7 standards mode.” One way to do this is to use the
following tag (in the head part):
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">
This tag should be placed before any style sheet or
reference to a style sheet.
Note that you should not
use wbr for hyphenation hints inside words,
since no hyphen is introduced if a browser breaks a line
due to wbr.
Using wbr for suggested line break
possibilities after hyphens, e.g. in words like
bird-bird-<wbr>cage)
Since wbr is not in any HTML specifications,
it causes validation problems just as nobr
does. To create a customized DTD that allows wbr, you can
add WBR to the definition of %specialWBR analogously with BR.
There's a modified "loose" DTD for the purpose at
<http:/
Theoretically, one could suggest additional line break points
in strings - not as hyphenation hints but as possibilies
for breaking e.g. a URL into two lines,
without introducing a hyphen - using special
characters.
Unicode Technical Report #14:
Line Breaking Properties specifies that the
zero width space character (ZWSP,
U+200B, character reference in HTML:
​)
Just for demonstration, here is how your browser displays a previous example
modified to
use ZWSP instead of wbr markup:
<http://www.hut.fi/u/jkorpela/html/nobr.html>.
Internet Explorer recognizes the character in the
sense of treating it so that a line break is allowed after it.
But what it displays depends on the font in use and is typically
a small box or a bullet, which is rather enigmatic.
The problem is that IE does not simply suppress the character
in rendering but uses the current font. The only commonly used fonts
that have a glyph for ZWSP are
Arial Unicode MS and Lucida Sans Unicode.
However, it seems that in IE 7, the problem has been fixed: the browser effectively treats ZWSP as an invisible control character.
The HTML 4 specification mentions ZWSP in the section White space. It defines ZWSP as a white space character but leaves it rather open how ZWSP should or might be treated in visual presentation. Note that the XHTML specification also discusses ZWSP, in section User Agent Conformance. It seems that those specifications treat ZWSP as a character to be used in some writing systems only, e.g. to denote grammatic boundaries, rather than as in the general meaning defined in the Unicode report: "This character does not have width. It is used to enable additional (invisible) break opportunities wherever SPACE cannot be used."
Various tricky ways
to fool browsers into treating a string as breakable have
been suggested, i.e. inserting a very small image or
a space character in a very small font. Some of them work
some of the time, causing confusion when they don't, and
if they work, they mostly work on browsers where the
wbr method works too.
But if you try this, perhaps the best shot is using
a transparent single-pixel GIF and the markup
<img src="transp.gif" width="0" height="0" alt="">
between two characters to suggest a possible break point.
It works reasonably on IE, but
it seems that Netscape uses some of such break points but not in
a logical way which would really adjust the text width to the available width.
In addition to permitting line breaks where you wouldn't expect them, the Unicode line breaking rules prevent line breaks in intuitively odd situations. For example, if a word is followed by a string that begins with a full stop (period, "."), the rules prohibit a break between the words. And IE (at least versions IE 6 and IE 7) behaves that way, as we already noted.
For example, a sequence of strings like ".foo" is unbreakable on IE, typically creating horizontal scrolling. Such strings are rare, but may arise in special situations.
The quick cure, if wrapping is important, is to insert the wbr tag
before each "word" that begins with a period
(.foo <wbr>.foo <wbr>.foo ...).
The theoretically correct, standards-conforming solution would be to
use zero-width spaces, ​, but it both fails in most browsing
situations and usually fails miserably when it does not work.
Getting even more theoretical if possible, the full stop (period) character "." belongs to line breaking class IS, "infix separator (numeric)" according to Unicode rules, and this means that it prevents a line break before it (as well as after it when followed by a numeric character). The effect of a space is described so that a break is normally permitted after a space (and a space at the end of a line is then effectively treated as nonexistent). So in "foo .text" the space permits a break after it, the period prohibits a break before it, and spending just a few hours reading the Unicode Standard annex #14 you might find out that the latter wins. I'm just kidding, it says this rather explicitly in rule LB 8: Don't break before a character in class IS even after spaces.
A similar case is a closing quotation mark followed by whitespace and an opening parenthesis. IE does not break at whitespace in such cases, though this can be fixed as outlined above.
This text containing “English style” (typographer’s) quotation marks does not wrap on IE. The browser treats the closing quote and the opening parenthesis as tied together even over a space.
This text containing “English style” typographer’s quotation marks wraps properly. It does not contain parentheses, so it does not exhibit the problem discussed here.
This text containing
“English style” <wbr>,
between the closing quote and the opening parenthesis.
HTML specifications are silent about Unicode line breaking rules, for the most of it. The specifications generally refer to Unicode as a basis for character definitions, so one might say that the spirit is that those rules should be obeyed. And this is what browsers have started doing, unfortunately.