Talk:Whitespace character

Backspace

Is backspace a whitespace character? 206.130.170.11 20:05, 17 March 2006 (UTC)

No, it's an editor command that doesn't show up in the document. - Richfife (talk) 20:39, 1 August 2008 (UTC)

Revision history

The revision history of this article prior to October 20, 2005 can be found at http://wiki.riteme.site/w/index.php?title=Whitespace&action=history. — mjb 22:43, 20 October 2005 (UTC)

Emacs' show-trailing-whitespace

Mention in GNU emacs, show-trailing-whitespace can make one whitespace-aware, vs. one's colorblind co-workers. --jidanni

sense?

Either this passage:

As is common in technical literature, the two words "white space" have found widespread usage as the single term "whitespace", especially when used as an adjective, as in "whitespace character". Some specifications refer to "white space" while others refer to "whitespace"; there is no difference between the terms, although exactly which characters are being referred to does vary from context to context. For example, in HTML, "whitespace" includes the form feed character, while in XML, "white space" does not.

needs revision, or it is very witty. In the last sentence, does "white space" in HTML include the form feed character, then? Does "whitespace" in XML? --Hugh7 03:01, 5 December 2006 (UTC)

The sentence "For example..." is pretty close to being nonsense. In XML, form feed is an illegal character. --Hermann —Preceding unsigned comment added by 217.74.209.1 (talk) 08:35, 7 May 2010 (UTC)

Propose renaming

I think, "white-space character" would be a much better title for this article than "white-space (computer science)". Firstly, article titles with disambiguation parentheses are very tedious to link to and should be avoided where an unambiguous term exists. Secondly, this is not really a computer science term; researchers don't write many academic papers about whitespace. I propose moving to "white-space character". Markus Kuhn (talk) 11:51, 2 January 2008 (UTC)

Whitespace

Whitespace is not a nuisance. It aids developers when used correctly. It makes the program easier to read and help group related logic... —Preceding unsigned comment added by 67.161.38.192 (talk) 19:47, 17 January 2010 (UTC)

Incorrect reference?

Whitespace table incorrectly references "Unicode 6.0, Chapter 4.6", which contains no proper comments about what are whitespace characters. — Preceding unsigned comment added by 125.130.234.95 (talk) 14:54, 21 December 2013 (UTC)

Need a history section

This page needs a history of whitespace characters section. It should at least include details of the Morse code(s) (and their lack of a space character and the ambiguities this caused), as well as the Monotype paper tape code (I don't know much about this paper tape code but it must have encoded multiple types of spaces as a necessity of how the machine operated), the Baudot code (which included two different whitespace characters), and the Linotype teletypesetting code (several whitespace characters). And a brief history of ASCII and Unicode.

If anyone objects to the "computer science" aspect of the older systems, it's worth noting that they are all codes for digitally transmitting information about text and spaces, all except Morse code using binary encodings. Battling McGook (talk) 05:18, 17 February 2015 (UTC)

What we are using `]` and `[` to show the spaces on the table instead of `|` and `|`?

I think that instead of braces we could use vertical bars to delimit the whitespace representations on the table.

--188.247.145.70 (talk) 15:32, 9 February 2016 (UTC)

Reference numbering messed up.

In the section ===Unicode===, the macro {{Whitespace (Unicode)}} has two references, "a" and "b". They are shown after the table as "1" and "2" instead of "a" and "b". But the more serious problem is that this macro causes all the references on the rest of the page to be off by two.

That is, https://wiki.riteme.site/wiki/Whitespace_character#cite_note-Mackenzie_1980-12 shows up as "[10]" many times in the document but is actually reference #8. Likewise "[16]" for reference #14. I don't know how to fix this. Joeinwap (talk) 06:45, 4 October 2016 (UTC)

Right to left Space

I would like to ask is there such unicode point?

Or can it be achived by some other way.

Could article just mention about whitespace directionality problem in bidirectional unicode {Unicode has more than two directions} — Preceding unsigned comment added by 95.108.118.240 (talk) 13:30, 23 January 2017 (UTC)

Half-space

"Half-space (punctuation)" redirects to this page, but this page doesn't talk about it. I think there should be a section about it, for what it's worth... —{{u|Goldenshimmer}}|✝️|ze/zer|😹|T/C|☮️|John15:12|🍂 00:39, 14 August 2017 (UTC)

Compatibility onus

... but is not universally supported in browsers yet, as of 2016.[which?]

Mathematically, this statement is supported by naming a single browser, still in active use in 2016, which did not yet support thin space. Pragmatically, one would also adduce a single browser which did support thin space in 2016, to elevate the assertion above logical fatuity (discourse cares about this, math doesn't).

There certainly should be an onus here to provide any kind of survey list of the usual suspects, pro and con. Anyone who has ever tried to compile a browser compatibility list knows that this is an OR rabbit hole, with potentially any wardrobe closet opening onto yet another Wonderland of weird counter-counter-exceptions.

On a quick survey, thin space supports depends on both the browser and the available fonts.

• Any standard for Unicode font support expected of all browsers?

There is no standard on Unicode support in browsers. Besides, the ability to display a character mostly depends on fonts, though browsers differ in their abilities in scanning through fonts.

• Guide to using special characters in HTML (2012) — good resource

Not only is the which flag advertising the wrong onus, it's actually distracting the article from addressing pernicious associated font problems.

Who is going to come along and resolve "which" into a list? That's about as attractive a project as laundering someone else's underthings. So it just sits there, and smells bad, and chases people away from making other positive contributions. — MaxEnt 15:44, 10 April 2018 (UTC)

◀ ▶ instead of ] [

Since the layout of the examples was changed from ] [ to ◀ ▶, the widths of all examples appear to be identical (macOS 10.14, Google Chrome), making it impossible to differentiate between the various whitespace characters. I propose we change it back to the old layout.--Kernpanik (talk) 11:02, 1 December 2018 (UTC)

I prefer the old backets as well. DRMcCreedy (talk) 22:50, 1 December 2018 (UTC)

Now it's completely broken, and it is no longer possible to copy the characters from the table. I can't find the correct edit to revert this. Anyone?--Kernpanik (talk) 07:00, 13 August 2019 (UTC)

In case anyone has interest in discussing or reverting the change, the problematic edit was made at Template: Whitespace (Unicode). 67.188.214.194 (talk) 20:54, 13 August 2019 (UTC)

What is "White_Space"?

In two of the table headers in sub section "Unicode", is "White_Space" literal? Or should it be "white space"?

If it is the former, then it ought to be explained.

OK, there is some information in a footnote. But it could be clearer. For example, what is a "binary Unicode property"?

--Mortense (talk) 16:34, 11 September 2020 (UTC)

Trailing whitespace vs. green computing

Mention reducing trailing whitespace helps green computing: less waste of disks and bandwidth. Jidanni (talk) 05:26, 21 August 2021 (UTC)

Changing the actual space character in the Width Box column for something else was a mistake. Why was it done?

What immediately came to mind was font support, but a simple warning before the start of the table that it requires one of the many fonts with unicode support that come with every single major browser for the last two decades that's not fixed-width should have sufficed. Even this warning would apply to the 0.001% of the world who actually overrules CSS font-family rules.

A much bigger percent of the world uses devices that don't support *typing* unicode characters. In fact, even on Android it's a hassle to type unicode characters, and the available apps would have you flipping through pages upon pages of characters before finding the whitespaces. Windows at least has a native program for that (Character Map - charmap.exe), but it's the same hassle. I can only imagine that the situation is even worse on iPhones. The only way many people could use these spaces was copying them from here and the blankcharacter.com website that someone recommended not only is not https — which should drive people away, especially since Chrome and Edge started throwing up warnings for these websites — it's also not from a reputable source, and doesn't seem to be up right now.

It's not lost on me that this is not the role of Wikipedia. However, it's a role that it played and that it's not easily substituted and I'm having trouble weighing the benefits of the change. Is there a way to fix this? Could we create a column with a javascript link to copy the respective character to the clipboard, maybe? Or, to keep with our actual role, add an additional column to inform readers of how each whitespacce character looks like in the user's current font? ~victorsouza (talk) 15:09, 6 March 2022 (UTC)