W3C home > Mailing lists > Public > www-html@w3.org > February 2004

RE: <NOBR> - Returning to the question ( 2 )

From: Ernest Cline <ernestcline@mindspring.com>
Date: Fri, 27 Feb 2004 18:04:09 -0500
Message-ID: <410-2200425272349794@mindspring.com>
To: "Marcus" <marcus3v@hotmail.com>, www-html@w3.org

> [Original Message]
> From: Marcus <marcus3v@hotmail.com>
> The central trouble in the exclusion of the <NOBR> tag from the HTML
> specification is that the functionality of this tag satisfies
> characteristicals structural impositions, rather than authors'
> presentational choices. Perceive that difficultly a content within a
> would be, suddently, removed from there -- if a certain content was
> within a <NOBR> tag, it's because such content, effectively, require no
> wrapping. Consequently, the behavior of the <NOBR> is eminetly structural
> ( HTML ), it is not, merely, "formatational" ( CCS ). Further, there's a
> strong inconvenience in the CSS propertie "white-space": "conforming user
> agents" may ignore its settings.
> Both minus character, principally, and &nbsp; entity solve nothing. The
> &nbsp; entity is specially unsuitable in a scenery of justified alignment,
> where it usually leads to the appearance of large empty areas in the
> inter-words regions ( because the space between the words united through
> &nbsp; entity isn't stretchable, extra blank space between the remaining
> words must to be created to accomplish the justification ). Finally, it's
> bit curious the existence of the &shy; entity -- that functionality is
> extremely specific, and that applying is even rarely ( it would be
> for exemple, to indicate to the User Agent the possibility of an aesthetic
> line break within a extensive word -- a URL would be such word ) -- , in
> face of the inexistence of the <NOBR> tag, that is evidently more usefull.

The usual result you describe is due to IE actually following a standard,
the Unicode Line Breaking algorithm, since by that standard &nbsp;
should not be considered a character for justification.  Given that these
lists tend more to complain about IE not following an existing standard,
I certainly don't want them being blamed for doing so.

If you want a space that will justify without the use of CSS
or non-standard HTML, then you need to use a space surrounded
by a pair of Unicode glue characters, such as CGJ (U+034F),
ZWJ (U+200D), WJ (U+2060), or ZWNBSP (U+FEFF). (Technically,
WJ, is the character that should normally be used as the other
three have properties beyond just the suppression of line-breaking.)

Unfortunately, UA support for these is somewhat spotty at present.

IE 6.0 (Windows) breaks with ZWJ and WJ, plus it inserts unfound
character glyphs for CGJ and WJ.  The result being that ZWNBSP
(which has been deprecated in Unicode in favor of WJ for this purpose,
so that ZWNBSP can be used for only the byte order mark) is the only
usable way of getting this done in IE without the use of CSS or <NOBR>.

Opera 7.23 (Windows) does a bit better. It gets the non-breaking correct,
in all cases, but it still gets the garbage glyphs for CGJ and WJ, leaving
only ZWJ and ZWNBSP as usable.

Mozilla 1.6 has the worst performance, in my opinion.  It doesn't handle
the glue characters correctly at all, plus it justifies NBSP (U+00A0). On
the plus side, it doesn't generate any garbage characters, so at least
the text is readable.

IN SUMMARY, if non-breaking is something that is content and not
presentation, there already exists the mechanism to do in HTML
(at least ever since HTML 4 when the character set was expanded
from ISO-8859-1 to Unicode)  Namely, the use of WJ or ZWNBSP.
This works in IE and Opera and when Mozilla fixes Bug 56652 [1]
it will work there as well.  Of course, if you need it to work now,
with existing UA's you are left with two choices, use CSS or use
<NOBR>..  However, there is clearly no need to incorporate <NOBR>
into the standard, as its non-presentational aspects can be handled
by plain Unicode text without the use of markup.

[1] http://bugzilla.mozilla.org/show_bug.cgi?id=56652
Received on Friday, 27 February 2004 18:04:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:07 UTC