Last Comment Bug 156211 -   between words in justify'd paragraph gets spaced out
:   between words in justify'd paragraph gets spaced out
Status: RESOLVED INVALID
: qawanted
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal (vote)
: ---
Assigned To: Marc Attinasi
: Hixie (not reading bugmail)
Mentors:
http://www.democracy.org
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-08 06:01 PDT by Steve Magruder
Modified: 2007-03-25 16:59 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Steve Magruder 2002-07-08 06:01:07 PDT
I have a "paragraph" of section tabs at the top of each page of my site.  This 
paragraph is set to justified alignment via a 'p' setting in the CSS file.  For 
each section tab, which is sometimes a two or more words, I separate the words 
with " ".  The problem is, the words are being spaced out for 
justification, even though these are supposed to be non-breakable spaces, as if 
the group of words is one big word.  Between the section tabs, I use normal 
spacing, so that's where the "justify" should be expanding the spacing.  This 
scenario works as expected on IE 6, although it fails on Opera 6.0x.  The 
bottom line is:  A non-breakable space should act like a non-breakable space.
Comment 1 Steve Magruder 2002-07-08 15:33:20 PDT
I forgot to mention that the " "-separated words are specified within an 
anchor tag.
Comment 2 Boris Zbarsky [:bz] 2002-07-08 23:04:34 PDT
non-breakable and non-stretchable are totally different things.  non-breakable
spaces are still interword spaces and may be stretched at the browser's
discretion in justified text, as far as I can tell.

What makes you think that this is not the case?
Comment 3 Steve Magruder 2002-07-09 02:56:42 PDT
A non-breakable space is a hard, single space between words, so unless there's 
any standard spacing in addition to that, no stretching or wrapping should be 
occurring within the affected clause of words separated only by non-breakable 
spaces.  If it's to the discretion to the browsers, then we end up with our 
sites looking and acting different on different browsers, and that's not 
right.  I'm not a fan of MS, but IE is handling this scenario correctly, IMHO.
Comment 4 Boris Zbarsky [:bz] 2002-07-09 03:29:24 PDT
See http://www.w3.org/TR/REC-CSS2/text.html#propdef-word-spacing

The width of the   is not changing, but the word spacing is....

Ian?  What's the right thing to do here?
Comment 5 Hixie (not reading bugmail) 2002-07-09 04:49:30 PDT
bz is correct. A NBSP is just like a normal space, except it has the additional
property of preventing word breaking at that point. That's all.
Comment 6 Steve Magruder 2002-07-09 05:41:11 PDT
Before this is closed (in my view, incorrectly), allow me to register my 
complete disagreement with the conclusion being arrived at.  Non-breakable 
spaces are HARD spaces.  A hard space cannot be stretched, as this is changing 
the nature of the " "-separated word/clause.  If I wanted stretching, I 
would have used standard spacing between the words!
Comment 7 Eric A. Meyer (dead account) 2002-07-09 06:48:32 PDT
I don't know-- I had always understood that 'nbsp' stood for non-breaking-space.
 That (to me) doesn't imply anything about non-stretching space, although I do
see your point.  Perhaps you could avoid the stretching like this:

  <span style="word-spacing: 0;">don't stretch</span>

...or just apply that style to your links, which you don't want to stretch
apart.  I apologize for not having a more site-specific example, but I rooted
through your site for a bit and didn't find any tabs at the tops of pages.

Then again, if you're fully justifying the text, CSS2 does allow user agents to
override any previously set inter-word spacing in order to meet the requirements
of that justification.  Maybe you could just not justify the paragraph
containing the tabs?
Comment 8 Boris Zbarsky [:bz] 2002-07-09 16:40:18 PDT
Setting word-spacing will do no good; justification will override any
word-spacing settings.
Comment 9 Ernest Cline 2004-02-27 13:59:05 PST
If you take a look at Unicode UAX#14, in Section 3 it states:

"When expanding or compressing inter-word space, only the space marked by U+0020
 SPACE and U+3000  IDEOGRAPHIC SPACE are normally subject to compression, and
only spaces marked by U+0020 SPACE, and occasionally spaces marked by U+2009 
THIN SPACE are subject to expansion. All other space characters have fixed width."

Now while this is not a normative part of UAX#14, both IE 6.0 and Opera 7.23
follow this suggestion.  In view of this, I respectfully suggest that this bug
should be either reopened, or marked as WONTFIX instead of as INVALID.
Comment 10 Boris Zbarsky [:bz] 2004-02-27 15:21:31 PST
Ernest, could you possibly bring this up on www-style?  It would be good to have
some consensus on what CSS2.1 says here...
Comment 11 Hixie (not reading bugmail) 2004-02-27 15:24:15 PST
What's the question, exactly?
Comment 12 Boris Zbarsky [:bz] 2004-02-27 15:30:46 PST
Just how the nbsp character interacts with justification, word spacing, letter
spacing, etc.
Comment 13 Hixie (not reading bugmail) 2004-02-27 15:54:43 PST
justification: The actual justification algorithm used depends on the user-agent
and the language/script of the text.

word-spacing: When white space is preserved, e.g. with 'white-space:pre', all
space characters are affected by word-spacing.

letter-spacing: This value indicates inter-character space in addition to the
default space between characters.

The above quotes are from CSS2.1. Non-breaking spaces are considered characters
(as they have a Unicode codepoint), like normal spaces, but have the additional
property of preserving white space.

Does that answer your question?
Comment 14 Boris Zbarsky [:bz] 2004-02-27 16:01:49 PST
Yes.  Reopening, per comment 9, since the CSS spec just says "do whatever the
hell you want" for the case in question and another spec has something to say on
the matter....
Comment 15 Ernest Cline 2004-02-27 16:28:25 PST
Also in CSS 2.1, the definition of the 'white-space' property refers to Section
4.1.1 [1] where it states:

Only the characters "space" (U+0020), "tab" (U+0009), "line feed" (U+000A),
"carriage return" (U+000D), and "form feed" (U+000C) can occur in whitespace.
Other space-like characters, such as "em-space" (U+2003) and "ideographic space"
(U+3000), are never part of whitespace.

So based on that, I would have to say that as far as CSS 2.1 is concerned, "no
breaking space" (U+00A0) is not whitespace.  If you wish, I'll take it to the
www-style list, but I think the literal interpretation is not in doubt.  Whether
this is what was intended is another question of course. :)

[1] http://www.w3.org/TR/2004/CR-CSS21-20040225/syndata.html#whitespace
Comment 16 Hixie (not reading bugmail) 2004-02-29 00:44:13 PST
That's a bug in CSS2.1 (I just asked the working group). That link should be
removed. For the definition of whitespace in 'white-space', use 16.6.1.
Comment 17 Ernest Cline 2004-02-29 07:46:34 PST
Problem is, there is no definition of whitespace in CSS2.1 Section 16.6.1.  How
whitespace is treated in general is given, and how some whitespace characters
are treated in particular (linefeed, space, and tab) is given but a normative
definition of whitespace is not given.  CSS3 Text Section 7.2 skirts the issue
as well, referring to the XML 1.0, XML 1.1, and HTML 4.01 definitions of
whitespace, but never clearly stating which if any is normative. (Perhaps the
intent is that the definition of what constitutes whitespace in CSS is to be
left to the doucment language, with the presumption that linefeed, space and tab
form a minimal whitespace definition?  I think I'll go ask that question on
www-style.)  However, even if the superset of all these definitions is taken,
U+00A0 is never mentioned as whitespace in any of them.
Comment 18 Hixie (not reading bugmail) 2004-02-29 09:57:30 PST
> Problem is, there is no definition of whitespace in CSS2.1 Section 16.6.1.  How
> whitespace is treated in general is given, and how some whitespace characters
> are treated in particular (linefeed, space, and tab) is given but a normative
> definition of whitespace is not given.

You don't need a definition. The spec says exactly what should happen for every
character for every value of the white-space property.
Comment 19 Ernest Cline 2004-02-29 12:18:26 PST
I beg to differ, but it doesn't.  Unless there is a definition of what is
whitespace, how can one determine exactly which characters are meant by
"non-linefeed whitespace character" in Step 1 of how to process white space for
inline elements?  (The same phrasing is in both CSS2.1 Section 16.6.and CSS3
Text Section 7.2.)

The algorithm doesn't use the term "whitespace character" in any other place,
but it does use it there.  Unless "whitespace character" is defined, one
implementor might think that it should also refer to the various blank spacing
characters in the General Punctuation block as well, while another could think
it wouldn't.  The CSS 2 definition of "whitespace character" for the
'white-space' property (which has been by a reference to the Syntax section ever
since the Jan 1998 draft of CSS2) may need revising, but unless step 1 of the
algorithm (first formally presented in the Jan 2003 CSS 2.1 draft) is revised
instead, it cannot be simply dropped without creating ambiguity.
Comment 20 Hixie (not reading bugmail) 2004-02-29 14:09:26 PST
Oops, that was meant to refer to U+0020 and U+0009. I'll add that to our issues
list. Thanks!
Comment 21 Ernest Cline 2004-03-29 22:52:18 PST
Well, you can forget the point I raised in comment #9.  The text of UAX#14 is
apparently going to be changed for Unicode 4.0.1 to include NBSP as a character
whose width can be adjusted during line justification.  It looks like this does
come down now to just being a matter of preference.  It might be wise to wait
until Unicode 4.0.1 comes out before deciding on a resolution if any of this
one, as they are also considering some minor, but substantive changes to UAX #14
which might have a knock on effect on how Mozilla would wish to treat it.
Comment 22 Mats Palmgren (:mats) 2004-08-02 06:33:03 PDT
Unicode 4.0.1 is now the latest version:
http://www.unicode.org/versions/Unicode4.0.1/

Following the link under "4.0.1 Unicode Standard Annexes" to UAX #14
one can read in Section 3:
http://www.unicode.org/reports/tr14/tr14-15.html#Introduction

"When expanding or compressing inter-word space according to common
typographical practice, only the spaces marked by U+0020  SPACE,
U+00A0  NO-BREAK SPACE, and U+3000  IDEOGRAPHIC SPACE are subject
to compression, and only spaces marked by U+0020 SPACE,
U+00A0  NO-BREAK SPACE, and occasionally spaces marked by
U+2009  THIN SPACE are subject to expansion. All other space
characters normally have fixed width."
Comment 23 Steve Magruder 2004-08-02 07:29:56 PDT
What are the "other space characters" that normally have fixed width?  I'll
start using them if &nbsp; has to be expanded in a justified paragraph.
Comment 24 Jungshik Shin 2004-08-02 08:59:34 PDT
There are several, U+2000, U+2001, U+2002, U+2003, etc. Probably, U+2003 (EM
space) would be about right for you. http://www.unicode.org/charts/PDF/U2000.pdf

Note You need to log in before you can comment on or make changes to this bug.