between words in justify'd paragraph gets spaced out




15 years ago
11 years ago


(Reporter: Steve Magruder, Assigned: Marc Attinasi)



Windows 2000

Firefox Tracking Flags

(Not tracked)





15 years ago
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

15 years ago
I forgot to mention that the " "-separated words are specified within an 
anchor tag.

Comment 2

15 years ago
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?
Assignee: Matti → attinasi
Component: Browser-General → Layout
QA Contact: asa → petersen

Comment 3

15 years ago
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

15 years ago

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

Ian?  What's the right thing to do here?
Keywords: qawanted
QA Contact: petersen → ian
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.
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 6

15 years ago
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!
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

15 years ago
Setting word-spacing will do no good; justification will override any
word-spacing settings.

Comment 9

14 years ago
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

14 years ago
Ernest, could you possibly bring this up on www-style?  It would be good to have
some consensus on what CSS2.1 says here...
What's the question, exactly?

Comment 12

14 years ago
Just how the nbsp character interacts with justification, word spacing, letter
spacing, etc.
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

14 years ago
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....
Resolution: INVALID → ---

Comment 15

14 years ago
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. :)

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

14 years ago
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.
> 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

14 years ago
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.
Oops, that was meant to refer to U+0020 and U+0009. I'll add that to our issues
list. Thanks!

Comment 21

14 years ago
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.
Unicode 4.0.1 is now the latest version:

Following the link under "4.0.1 Unicode Standard Annexes" to UAX #14
one can read in Section 3:

"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

13 years ago
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

13 years ago
There are several, U+2000, U+2001, U+2002, U+2003, etc. Probably, U+2003 (EM
space) would be about right for you.
Last Resolved: 15 years ago13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.