Replacing non-breaking spaces

[nschonni]

Looks like there are quite a lot across the files. I think there may be some cases where they make sense, but probably a general cleanup makes sense. I didn't want to send a PR because it would touch thousands of files and would be un-reviewable.

[hamishwillee]

@chrisdavidmills FWIW the wiki used to randomly inject these (at least that's how it felt). IMO we should remove all of them and start injecting them again when needed. But perhaps this should be done by someone who has merge rights across the wiki so that it can be done when there are no other PRs that might result in conflicts.

[nschonni]

Other approach my be doing some batching, but I agree with @hamishwillee that it's probably better done by one of the maintainers that can sneak the batches in between PRs

[chrisdavidmills]

Yeah, maybe one of our devs could handle this one.

[hamishwillee]

@peterbe This something you would handle?

[peterbe]

Wow. I didn't realize how many there were! I wrote a little Python script and concluded that it exists in 4,853 of the files in mdn/content.
Yeah, let's not make 4,853 pull requests. Or, if we do it in batches of 10, let's still not make 485 pull requests.

But perhaps we can start with getting rid of it as part of the fixable flaws. Because when you run fixable flaws, it edits the raw index.html so it would be a chance to do something.

I'm actually not super familiar with the functionality. I actually don't know why JavaScript won't print it when you console.log a line that contains one. But there are a lot of these:

'<h4 id="Removals">\xa0Removals</h4>\n'

which can easily be replaced to:

'<h4 id="Removals">Removals</h4>\n'

Are there instances where they actually are useful?

I definitely don't think we should over-worry about this because it seems pretty harmless at the moment. And fixing it might create more confusion and noise than necessary. Perhaps we just accept and learn to live it with as is. Perhaps we sweepingly fix it all when we convert from HTML to something Markdownish.

[nschonni]

Are there instances where they actually are useful?

I think if they are contained in double quotes, or the only character in <code> blocks, they're usually talking directly about the actual character

[sideshowbarker]

Are there instances where they actually are useful?

Running the following:

rg "<code>[^<]+\u00A0[^<]+</code>" files/en-us/

…and looking through the output, I find some things like the following:

files/en-us/web/guide/css/getting_started/challenge_solutions/index.html
57: <dd>Add a rule with an ID selector of <code>#second</code> and a declaration <code>color: blue;</code>, as shown below:

…where in <code>color: blue;</code>, that space is a non-breaking space — apparently added to prevent the possibility of a line break after color: and before blue.

files/en-us/web/html/element/meta/index.html
85:   <p>Declares the <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a> and character encoding of the document. If specified, the <code>content</code> attribute must have the value "<code>text/html; charset=utf-8</code>". This is equivalent to a <code>meta</code> element with the {{htmlattrxref("charset", "meta")}} attribute specified, and carries the same restriction on placement within the document. <strong>Note:</strong> Can only be used in documents served with a <code>text/html</code> — not in documents served with an XML MIME type.</p>

…in "<code>text/html; charset=utf-8</code>", apparently to prevent the possibility of a line break after text/html; and before charset=utf-8.

Running:

rg "<code>[^<]+\u00A0[^<]+</code>" files/en-us/ | wc -l

…says we have 68 cases like those in the tree — cases where somebody has intentionally used a non-breaking space to try to ensure that a certain string containing whitespace doesn’t get broken across lines.

[peterbe]

So it's useful in a bunch of pages, thus making it hard to sweepingly and basically replace all. Perhaps park this in the back of our heads rather than front of the roadmap.

[nschonni]

Hmm, would a flaw that replaces them with the entity   make sense? EX: if you're OK with that in the code you probably actually meant in, and it makes it explicit

[peterbe]

Or leave it in the cases where it makes sense and replace it with the empty string where it doesn't make sense.

[Ryuno-Ki]

Are there instances where they actually are useful?

It could also be used if you have a brand name which must not be broken apart (think MDN web docs).

Would it make sense to categorise the hits by elements and attributes and tell the script to blacklist certain elements and attributes? (Thinking of <code> and style here).

[hamishwillee]

FWIW

1. Generally the only case that is actually "important" is in code, because that is usually done for layout. All other cases like brand names etc. are not very important - yes someone in a marketing team somewhere might be irritated, but no reader will care.
2. I much prefer the explicit   over HTML/character codes when editing.
3. I would prefer it be done globally rather than as a flaw. We have so many of these because they were injected by the old toolchain. In future I expect they will tend to be deliberate. Having a flaw reported on things that are likely to be deliberate is irritating.

So my two bits - automate, omitting the cases inside code markup. Fix the likely very small number of actual problem cases as we come to them.

[hamishwillee]

@wbamberg do you think maybe we could remove these non-breaking spaces as part of the markdown conversion?

They should be valid markdown too, but they aren't generally "useful" and IMO were mostly injected by error by the old Wiki infrastructure.

[Ryuno-Ki]

Yikes. The French tradition of Plenken 😣

Typographically speaking, there might be occurences, where a wordmark (take „MDN web docs”) should be kept together.
So we should support nbsp if possible.

[peterbe]

I dare say it's too weird and best to avoid. I've seen many weird cases of it ever since I installed VS Code Gremlins. Many places make me nervous where I wouldn't dare to try to automate it away. Sometimes it's supposed to be a regular single blank space, but other times, not.

I would however consider removing them all from code blocks. There it never makes sense. So as any pre becomes a triple-back-tick block, we could do a string search-and-replace.

[wbamberg]

@wbamberg do you think maybe we could remove these non-breaking spaces as part of the markdown conversion?

My feeling here is that Markdown conversion is a big and complicated enough project not to want to add more things to it.

[teoli2003]

Should we list non-breakable spaces made with a unicode character, and not an entity, as flaws? (We could add more gremlins as such). I don't know how complex to add are flaws.

That way they'll got removed little by little and we communicate our will to every editors/writers.

[peterbe]

I'm opposed to worrying too much about it but I wouldn't mind adding or two lines to the bad_pre_tags flaw. It should be easily fixable. There's definitely room for it.

But I'm super sure it gains a lot. I "hate" that they're there, in the <pre> tags, but I'm not sure enough that they hurt us.