Re: Collapsing breaks & non-beaking spaces.

Mike Meyer wrote:
> The same logic that was used in the argument "non-breaking space is
> not a space, and so shouldn't collapse", wasn't it? :-)

Absolutely.

> First, a question - who defined the non-breaking space? Didn't HTML
> pick it up from ISO when the ISO Latin 1 entities were added? If so,
> it's not clear it's appropriate for an HTML spec to make this
> decision.

It's ISO &#160. I don't know of a usage description.
 
> Pragmatically, I agree with you. However, consider non-print media
> that don't HAVE a line break to worry about. In those media, there is
> *NO* difference in the rendering of the string "David Perrell" and
the
> string "David Perrell". That there should then be a difference
> between "David  Perrell" and "David  Perrell" seems, well,
> wrong. This argues very strongly that   is a space and hence
> should collapse.

I disagree. Consecutive &nbsp are used as a form of separation. In
'normal' print media, there is no such thing as collapsing white space,
so if I type "David  Perrell" into my word processor, that's how it
will print. HTML is the oddity. Two consecutive space characters in
HTML will not render without being enclosed in PRE. Therefore, &nbsp is
the only means to produce two consecutive space characters in the
rendered text. We seem to be confusing marked-up copy with displayed
text. They are not the same. If an author, knowing that "this  that" in
an HTML document will be rendered for reading/listening/whatever as
"this that", instead types "this &nbsp:that", then that author is
trying to express something different than "this  that" -- that those
two words require more separation than a single space conveys. To me,
it does not seem wrong for there to be a different rendering of the two
forms. It expands the options for expression. I feel the same about
&emsp and &ensp and &thinsp. Although they are space characters,
consecutive instances should be rendered, because they can only be put
into the copy intentionally.

CSS1 removes the need for   in order to render consecutive spaces
by allowing an inline element to be declared with a white-space type of
'pre', or the PRE element to be declared with a display type of
'inline', so that <SPAN>this    that</SPAN> could be rendered inline
without collapse. If there were an inline HTML element that simply
marked the enclosed text as "don't collapse whitespace", this argument
would be moot.

> Got a question about <BR> as well. How should a lone <BR> be rendered
> when it's "natural" rendering is at the start of a line.

Since BR has no horizontal dimension, I don't see how it can drop to
the beginning of another line. At the point where a 'natural' line
break might occur, the BR forces the break, making a second break
unnecessary.

David Perrell

Received on Sunday, 13 July 1997 19:38:57 UTC