Closed Bug 156211 Opened 23 years ago Closed 21 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: 23 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: 23 years ago → 21 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.