Closed Bug 156211 Opened 22 years ago Closed 20 years ago

  between words in justify'd paragraph gets spaced out

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: stevem, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: qawanted) 

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.
I forgot to mention that the " "-separated words are specified within an 
anchor tag.
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
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.
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?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
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?
Setting word-spacing will do no good; justification will override any
word-spacing settings.
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.
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?
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?
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....
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
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
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.
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.
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!
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:
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."
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.
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
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.