&ensp in a monospaced font

[Jukka K. Korpela]

Scripsit John Hosking:

(e-mail address removed) wrote: - -

Much clearer.

It's still not evident what the problem is. As usual, a URL would
have...

Even clearer.

Not to me, really. A few clarifications:

1) There is no "m-width" and "n-width" space. The width of an EM SPACE
equals the font size, by definition, and the width of an EN SPACE is
half of that. Their relationship to the widths of the letters "m" and
"n" is unspecified.

2) Normal spaces do collapse. This can be prevented in different ways,
but not in any evident way in inline text. (white-space: pre-wrap in CSS
would do this, but regarding browser support, "D'Oh!")

3) Whether em spaces, en spaces, or no-break spaces collapse is
explicitly declared unspecified in HTML specifications. In practice they
don't, but if IE 8 or Firefox 4 starts collapsing them, you can only
blame yourself if you relied on their not being collapsed.

4) The no-break space should prevent line breaks before and after. There
are some flaws in this area in browsers when a no-break space is
preceded or followed by a normal space.

But why would it be a _problem_ that line breaks are prevented, if you
want a specific placement of characters? To me, it seems like a
necessary part of a _solution_.

Then how about: <p>abcde</p><p>a&nbsp; &nbsp;e</p> ?

Since this was said to be computer output, markup like

<pre><samp>abcde
a e</samp></pre>

would appear to be adequate. If this won't do, the OP should explain why
not.

That should give you both the spacing and a possible break. I believe
you'd get the same effect (but with two break possibilities) if you
did: <p>abcde</p><p>a &nbsp; e</p> . (Not tested in all browsers.)

By the specifications, "a &nbsp; e" should have one break possibility
only, after the second space. Some browsers get this wrong. But I don't
see a reason for using such an approach.

It's only consecutive spaces that get collapsed.

As I mentioned above, no-break spaces may or may participate in the
collapse party. Currently they don't, but you have been warned:

"This specification does not indicate the behavior, rendering or
otherwise, of space characters other than those explicitly identified
here as white space characters [i.e. space, tab, form feed, zero-width
space]. For this reason, authors should use appropriate elements and
styles to achieve visual formatting effects that involve white space,
rather than space characters."
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1

 

[mrcakey]

Just out of interest, what is the logic behind collapsing spaces in text?
I'd love to be able to display a document I'd written with the conventional
2 spaces after a full stop.

+mrcakey

 

[Harlan Messinger]

3) Whether em spaces, en spaces, or no-break spaces collapse is
explicitly declared unspecified in HTML specifications. In practice they
don't, but if IE 8 or Firefox 4 starts collapsing them, you can only
blame yourself if you relied on their not being collapsed.

Except for the few white space characters for which collapsing is
specifically required, whether *any* character collapses is unspecified.
Yet I'm not going to worry that some day a new browser version will
display "bookkeeper" as "bokeper". I think it's taken for granted that
characters not arbitrarily collapsing with each other is the norm, and
only situations where they do collapse need to be articulated explicitly.

 

[Harlan Messinger]

Just out of interest, what is the logic behind collapsing spaces in text?
I'd love to be able to display a document I'd written with the conventional
2 spaces after a full stop.

It has never been conventional to have two full-width spaces after a
full stop anywhere but on pages produced on monospace typewriters. Since
you aren't using a monospace typewriter (and unless your sense of
nostalgia isn't similarly leading to your prescribing a monospace font
to display your pages), there isn't any reason to have two full-width
spaces after a full stop.

 

[mrcakey]

It has never been conventional to have two full-width spaces after a full
stop anywhere but on pages produced on monospace typewriters. Since you
aren't using a monospace typewriter (and unless your sense of nostalgia
isn't similarly leading to your prescribing a monospace font to display
your pages), there isn't any reason to have two full-width spaces after a
full stop.

Both my alma mater and my erstwhile employer mandated the use of two spaces
after a full stop. You'll also see it in many books and magazines.

+mrcakey

 

[Jonathan N. Little]

Both my alma mater and my erstwhile employer mandated the use of two spaces
after a full stop. You'll also see it in many books and magazines.

Old typewrite habits must be hard to break! Like folks who hit TAB to
lead off paragraphs...

 

[Jukka K. Korpela]

Scripsit Harlan Messinger:

Except for the few white space characters for which collapsing is
specifically required, whether *any* character collapses is
unspecified.

That's nonsense and you know that.

Yet I'm not going to worry that some day a new browser
version will display "bookkeeper" as "bokeper".

Or as "fhjidsgyuh98erswygt98". This has nothing to do with whitespace
handling. Read the statement in the spec I mentioned. Its intent is not
hard to see.

The point is that space characters cannot be expected to result in any
specific amount of spacing, despite the fact that some of them are
defined as "fixed-width" spaces in character code standards (and
no-break space isn't, by the way, and it's the one we are usually
talking about in this context).

 

[Ben C]

3) Whether em spaces, en spaces, or no-break spaces collapse is
explicitly declared unspecified in HTML specifications. In practice they
don't, but if IE 8 or Firefox 4 starts collapsing them, you can only
blame yourself if you relied on their not being collapsed.

CSS specifications (CSS 2.1, 16.6.1) do say that the only things that
get collapsed are U+0009, U+000D, U+000A and U+0020. That is to say,
TAB, CR, LF and ordinary space.

The stuff between tags is thought of as anonymous inline elements so
this does cover everything.

 

[Jukka K. Korpela]

Scripsit Ben C:

CSS specifications (CSS 2.1, 16.6.1) do say that the only things that
get collapsed are U+0009, U+000D, U+000A and U+0020.

CSS specifications (or drafts - note that the document you cite says "It
is inappropriate to cite this document as other than work in progress")
cannot trump HTML specifications. HTML does not "need" CSS, still less a
particular version of CSS.

What you cite applies to the white-space property, and it specifies
certain processing of the characters you mention. I don't think the text
describes what may or may not happen to other space characters.

 

[Harlan Messinger]

Both my alma mater and my erstwhile employer mandated the use of two spaces
after a full stop.

In what context? Typewritten material? If not, why couldn't they have
been operating under the same misconception as many other people if they
insisted on perpetuating the convention after students and employees
started producing word-processed material in proportional typefaces?

You'll also see it in many books and magazines.

Which ones? I just looked at a selection of books and magazines and this
isn't true in any of them. If you see them in some places, keep in mind
that in some books and magazines, spaces are highly variable in width
because they are used to produced full justification of the content, so
be sure you are looking aren't just looking at lines that required a
great deal of extra space to fill out the width of the text.

 

[Harlan Messinger]

Scripsit Harlan Messinger:


That's nonsense and you know that.

Oh. Where does it specify that any particular non-space characters don't
collapse?

What's your justification for "and you know that"? If it *is* nonsense
and I *know* that, why would I write it?

Or as "fhjidsgyuh98erswygt98".

Exactly. Unless special treatment is specified, I assume unremarkable
treatment: each character is displayed

This has nothing to do with whitespace
handling. Read the statement in the spec I mentioned. Its intent is not
hard to see.

You noted elsewhere that HTML exists without regard to CSS and that the
CSS specifications don't affect the rules for HTML. Likewise, character
sets, fonts, and Unicode exist without regard to HTML, and I would
expect that whenever HTML doesn't specify otherwise, text will be
displayed in the prevailing manner, which, as I observed above, at least
IMO, means that each character is displayed, and they aren't arbitrarily
collapsed. Maybe that's not the way things will always work, but to me
it seems a reasonable understanding.

The point is that space characters cannot be expected to result in any
specific amount of spacing, despite the fact that some of them are
defined as "fixed-width" spaces in character code standards (and
no-break space isn't, by the way, and it's the one we are usually
talking about in this context).

I understand that that pertains to a proportional font. It seems to me
that with a monospace font, it is a reasonable expectation that each
character, space or otherwise, take up the same space, largely because
such ability to align text is one of the reasons one uses a monospace
font, and people expect it to work this way. If someone sees fit to
implement a display medium where monospace isn't really monospace, well,
so be it, but I don't see any point in doing that, and the reasons for
not doing that seem clear to me.

 

[Blinky the Shark]

Harlan Messinger wrote:

Yet I'm not going to worry that some day a new browser version will
display "bookkeeper" as "bokeper". I think it's taken for granted that
characters not arbitrarily collapsing with each other is the norm, and
only situations where they do collapse need to be articulated explicitly.

<ot> Are there other English words that contain a consecutive triplet of
doubled letters?

 

[Ed Mullen]

It has never been conventional to have two full-width spaces after a
full stop anywhere but on pages produced on monospace typewriters. Since
you aren't using a monospace typewriter (and unless your sense of
nostalgia isn't similarly leading to your prescribing a monospace font
to display your pages), there isn't any reason to have two full-width
spaces after a full stop.

I understand all of that. But, for those of us who learned to touch
type in 1963 it's nearly impossible to break the habit of hitting the
space bar twice after a period.

 

[Blinky the Shark]

I understand all of that. But, for those of us who learned to touch
type in 1963 it's nearly impossible to break the habit of hitting the
space bar twice after a period.

It also scans better, in my opinion. I think that's important; I can
single space regardless of my training, and I would if it worked better.

 

[dorayme]

Scripsit Harlan Messinger:


That's nonsense and you know that.

Which is the likelier theory:

1. Harlan Messinger looks about to see what nonsense he can talk,
and cannot resist going for it.

or

2. Jukka K.Korpela looks to see what he can say to cause pain and
offence to someone while he typing just for the sake of it, there
not being an actual need.

 

[Neredbojias]

It also scans better, in my opinion. I think that's important; I can
single space regardless of my training, and I would if it worked better.

Well just remember that not everybody has the same wierd problems you old
guys have...

 

[Ben C]

Scripsit Ben C:


CSS specifications (or drafts - note that the document you cite says "It
is inappropriate to cite this document as other than work in progress")

Did I cite it as other than work in progress?

cannot trump HTML specifications. HTML does not "need" CSS, still less a
particular version of CSS.

Fair enough but the majority of people writing HTML these days are doing
so because they expect most people to look at it in CSS-equipped
browsers.

What you cite applies to the white-space property, and it specifies
certain processing of the characters you mention. I don't think the text
describes what may or may not happen to other space characters.

Well it says in 16.6.3 that "Control characters other than tab,
line-feed, space and bidi formatting characters are treated as
characters to render in the same way as any normal character".

You can probably explain better what that means, but as far as I can
tell, implementors are meant to leave the non-breaking spaces in.

 

[Ben C]

In what context? Typewritten material? If not, why couldn't they have
been operating under the same misconception as many other people if they
insisted on perpetuating the convention after students and employees
started producing word-processed material in proportional typefaces?

Vim does it.
If I start a new sentence here, and then gq the two lines, I get this:

"Vim does it. If I start a new sentence here, and then gq the two lines,
I get this:"

Two spaces after the '.' There's no doubt an option somewhere to change
it to 1 or 3 spaces or any arbitary string but I just live with it as it
is.

Also, from the fmt manpage:

-u, --uniform-spacing
one space between words, two after sentences

So mrcakey, his alma mater, and erstwhile employer are not alone.

 

[Ben C]

<ot> Are there other English words that contain a consecutive triplet of
doubled letters?

Good question, the answer is no!

These are all the ones I could find in the Scrabble dictionary of
pointless but high-scoring words and various other word lists I have on
my computer:

bookkeeper
bookkeepers
bookkeeping
bookkeeping

I will leave the regular expression to find them as an exercise to the
reader.

If you count things like "aarrgghh" as words then there are few more.

 

[Jukka K. Korpela]

Scripsit Harlan Messinger:

Exactly. Unless special treatment is specified, I assume unremarkable
treatment: each character is displayed

A statement about undefined behavior for space characters _does_ specify
special treatment.

- - character sets, fonts, and Unicode exist without regard to HTML,
and
I would expect that whenever HTML doesn't specify otherwise, text
will be displayed in the prevailing manner, which, as I observed
above, at least IMO, means that each character is displayed, and they
aren't arbitrarily collapsed.

No, conforming implementations are not required to display all
characters. Even if Unicode conformance were required, and it isn't,
implementations would not need to support all characters. They won't be
_arbitrarily_ collapsed, but collapsing spaces aren't really "character
collapse" but a matter of spacing.

It seems to me
that with a monospace font, it is a reasonable expectation that each
character, space or otherwise, take up the same space,

It is not reasonable for characters with specific width as part of their
character definition. Specific-width space characters with different
widths in a fixed-width font are a contradictory concept. I would not be
anything on any particular processing of this contradiction, especially
in the HTML context, where we have been warned about undefined
processing.