Remove [whitespace character] and use [unicode whitespace character] instead

[zudov]

At the moment we have

• whitespace character -- a space (U+0020), tab (U+0009), newline (U+000A), line tabulation (U+000B), form feed (U+000C), or carriage return (U+000D).
• unicode whitespace character -- is any code point in the unicode Zs class, or a tab (U+0009), carriage return (U+000D), newline (U+000A), or form feed (U+000C).

These two are very close to each other, is there a need to have both of them? As I understand it the primary function of [whitespace character] is to restrict various kind of spaces (e.g.  ). I looked through the places where [whitespace character] is used but didn't understand how thing like   would harm there.

In case if we actually don't need this distinction, I propose to remove [whitespace character] and use [unicode whitespace character] in those places. Or better go further and remove name [unicode whitespace character] and change the definition of [whitespace character] to the one that [unicode whitespace character] has at the moment.

[jgm]

I think it might be useful to be able to insert unicode
nonbreaking spaces in contexts where a space would normally
have a Markdown meaning, but you really just want a space.
But I'm not sure.

[zudov]

@jgm I see, despite that usage might be very confusing it goes together with the semantics of a non-breaking space, and I don't see any other workarounds for such cases. Allowing backslash-escaped spaces might also be confusing.

The question is if we want to allow such workarounds. No doubt it can be useful in some cases (e.g. multiple spaces in code spans), but in other cases we might want to enforce "there should be no whitespace here" rule.
For example a link label. That is a separate issue but at the moment it's possible to create link labels consisting of only non-breaking spaces.

[jgm]

I'm open to being persuaded. There are also things like
zero-width spaces and thin-spaces (useful in formatting
math, for example). I'd have to examine the whole spec with
this in mind before feeling comfortable about the change.

+++ Konstantin Zudov [Jul 02 15 21:19 ]:

[1]@jgm I see, despite that usage might be very confusing it goes
together with the semantics of a non-breaking space, and I don't see
any other workarounds for such cases.

The question is if we want to allow such workarounds. No doubt it can
be useful in some cases (e.g. multiple spaces in code spans), but in
other cases we might want to enforce "there should be no whitespace
here" rule.
For example a link label. That is a separate issue but at the moment
it's possible to create link labels consisting of only non-breaking
spaces.

—
Reply to this email directly or [2]view it on GitHub.

References

1. https://github.com/jgm
2. Remove [whitespace character] and use [unicode whitespace character] instead #343 (comment)

[jgm]

I see that at least some of the places where we refer to space characters are in definitions of HTML elements. And here's what the HTML5 spec says:

The space characters, for the purposes of this specification, are U+0020 SPACE, U+0009 CHARACTER TABULATION (tab), U+000A LINE FEED (LF), U+000C FORM FEED (FF), and U+000D CARRIAGE RETURN (CR).

The White_Space characters are those that have the Unicode property "White_Space" in the Unicode PropList.txt data file. [UNICODE]

So, they make a similar distinction, and we're going to need it at least for HTML.

[zudov]

@jgm That makes sense, perhaps we can close this issue for now.

[jackdouglas]

@jgm Is "line tabulation (U+000B)" deliberately missing from the "unicode whitespace character" list? If it's a mistake, perhaps it would be simpler to follow if the spec defines "unicode whitespace character" as follows:

A unicode whitespace character is any whitespace character or any code point in the unicode Zs class.

[jackdouglas]

or maybe:

A unicode whitespace character is any code point in the unicode Zs class or any other whitespace character.