Template talk:Whitespace (Unicode)

Reference syntax help needed

As you can see, I'm getting errors with the named reference "ws"; after reading Help:List-defined references, I'm still not sure what I'm doing wrong. Any experts about? -- Beland (talk) 06:02, 12 October 2014 (UTC)[reply]

Checking: weird. When I copy full template code, with the /doc, in my User:DePiep/sandbox2 (Userspace), the red texts do not show. The refs show orderly. (However, that clean show does not look like 'as intended', we'd expect reference "a." and "b." only right).

Could it be that, when we change that presentation into a more 'intended' one, the red error might be gone too? (btw, I'm going offline and one can edit as preferred, don't wait for me). -DePiep (talk) 10:13, 12 October 2014 (UTC)[reply]

Huon managed to at least fix the error. He wrote the following on my personal talk page. -- Beland (talk) 18:20, 22 October 2014 (UTC)[reply]

I have no idea why, but changing the order of the references within the {{reflist}} template helped. Personally I'd say the better solution would be to take apart the group of list-defined nested references and instead use less interlaced components. Huon (talk) 17:31, 21 October 2014 (UTC)[reply]

Suggestion of coloring the whitespace demos

I feel that the "within ][" column doesn't help us much enough to see the actual width of a whitespace character. How about giving all demos "background-color" attribute? something like this:

Unicode character property "WSpace=Y"
Code point	Name	Decimal	within "]["	Wrap- pable?	in IDN?	Script	Block	General category	Notes
U+00A0	no-break space	160	] [	No	No	Common	Latin-1 Supplement	Separator, space	Non-breaking space: identical to....
U+1680	ogham space mark	5760	] [	Yes	Yes	Ogham	Ogham	Separator, space	Used for interword separation in....

here's the code:

<span style="color:navy;background-color:yellow"><span style="background-color:blue"><nowiki>]</nowiki></span>anyspace<span style="color:navy;background-color:blue"><nowiki>[</nowiki></span></span>

We can give them a new column if we need to keep the colorless demos. Wbxshiori (talk) 12:42, 5 June 2017 (UTC)[reply]

Forcing arrows to stay as text instead of emoji

On my browser, the ◀︎ ▶︎ symbols render as emojis (i.e. ◀️ ▶️) in the following table (only for zero width joiner for whatever reason). This can be fixed with variant selectors, but they may be copy-pasted with the space if someone tries to copy it directly from the article. Are there other ways of fixing this?

Code point	Name	Decimal	within ◀▶	Wrap- pable?	in IDN?	Script	Block	General category	Notes
U+200D	zero width joiner	8205	◀‍▶	Yes	Yes	?	General Punctuation	Other, Format	ZWJ, zero-width joiner. When placed between two characters that would otherwise not be connected, a ZWJ causes them to be printed in their connected forms. HTML/XML named entity: `&zwj;`
U+200D	zero width joiner	8205	◀︎‍▶︎	Yes	Yes	?	General Punctuation	Other, Format	ZWJ, zero-width joiner. When placed between two characters that would otherwise not be connected, a ZWJ causes them to be printed in their connected forms. HTML/XML named entity: `&zwj;`

The new colouring instead of brackets ] [ is horrible.

The coloured "whitespaces" (more like "greenblocks" now) look really bad. The brackets ][ were fine in all browsers and machines I ever used personally and only showed where the characters started and ended, rather than cover them in anything. In my view, the marsh green only serves to confuse as to what it is supposed to illustrate, as there in fact are no such green characters in reality, only spaces between things, which is exactly what the brackets illustrated. Maybe this is a very subjective thing, but that’s my view anyway, and I want the brackets back (nothing against the arrow version but it had technical problems as noted previously.) — Knyȝt (talk) 07:25, 14 August 2019 (UTC)[reply]

I agree that visually it looks worse. It also makes it hard to select the space character to copy it, since the color of the spaces is very close to their color when selected. I would prefer reverting to either the arrows or brackets. 50.202.84.139 (talk) 17:02, 26 August 2019 (UTC)[reply]

The use of the term "HTML/XML named entity" is a bit incorrect

XML only has 5 predefined entities. Probably what is meant by this is HTML/XHTML, or perhaps HTML5/XHTML5 entities. Since the exact details of when which entities were added to which standards is would be tangential esoteric with regards to this chart, not to mention the difficulty of tracking down all those details, I'd suggest dispensing with the "/XML" and referring to each of them as just the "HTML named entity" (i could Be Bold but i don't feel like it right now so someone else can do it) - 99.146.242.37 (talk) 07:48, 14 May 2024 (UTC)[reply]