I like to put two spaces after periods for correct sentence spacing, but that breaks when the sentince break lands at the line break on the display. It always does the regular space first, then the after. If it went the other way around, then the hard space is at the end of the line and the next line start correctly aligned (ignoring the soft space). The actual space should be at the end of a group of characters. If you want to use this kind of space at the beginning of a line, it should follow a </br> tag or similar line-breaking boundary.
I'm guessing that tiny-mce is the actual culprit, but we could fix it on the back end if that's easier.
I tested that it gets left alone if you use the html editor to fix it. Even there, you don't see the &; encoding on the nbsp char, just looks like two spaces, but if you type and have a regular space after it, the display now looks right after saving it.
We're going to do some serious text editor research soon. In addition to the central enhancements we want (especially link/nest editors), there are several data manipulation issues that will need a closer look.
Fwiw, standard on wagn.org is one space after sentences. I've been a two space guy all my life, but afaict, the tide has turned in the national conversation on the issue, and the one-space brigade is winning :)
Still, your point is well taken, and there's no good reason to make 2 spaces break stuff!
I understand using it because it is what works. I end up with extra space at the beginning of lines. I'm not sure I care about what the average person things, typographically, it's just wrong. Nobody would set a book or publish a major paper that way (single space after sentence). It surprises me that when I searched on the issue, nobody identified the correct behavior as being what I suggest (put the soft space last). People either want the suppress the completely, or make a button to insert it explicitly.
I here you about the bigger issues with the editor, but, what do you think about a patch to do as I suggest? I would write the code if you are interested. I guess it could be handled by switching tools, but I don't really expect that to happen.
It's a boring battle, imo, but if you want in on it: http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html Sounds like what you're saying about "nobody would set a book or publish a major paper" just ain't so.
I guess we could put in a patch, but I'd be tempted to scrap it at the first sign of complicity in a broken test. Any chance you could check out behavior on CK editor first? That's the most likely candidate.
Not sure how, but I'll give it a shot. I agree that it is boring, but when I looked about I was struck by how inflexible some of the one space people are. Visually, I like the extra space, and it does seem that a slightly wide space (em) is typical typographic practice, but not standard. It's clear that it is a style choice, and as a choice it would be nice to support it rather than fail. It does seem that I was wrong about how this has evolved, but claims that two spaces are wrong seem quite overblown.
Yeah, I totally agree. The author was annoying. And I can't say that I actually followed up the citations, but I hope that salon.com is credible enough that at least the facts behind the bloviation can be trusted :)
Re policy on wagn.org, I think John Abbe cares about this more than I do, and he wanted one space (and kept correcting my 2 spaces), so I conceded. I'm definitely not on the dogmatic one space side, but I'm in favor of site-wide style consistency.
I can see choosing that policy based on the fact that two spaces is broken. That probably is part of why it became more popular. The software can't screw up on space. Hard to find sentence breaks, but consistent.
I don't think CK fixes it the right way. I think the filter is a good idea. Could be disabled (site-wide admin setting seems good for this, right?).
I implemented a solution and created a PR
Good discussion here. The PR implements what they say is the 'wrong' way, or rather it patches the really wrong way it is handled in tinyMCE (trailing ). I could see implementing one of the other larger space entities as another option for the change. (i.e. you configure what it will substitute for soft-space hard-space sequences.
+discussed in support tickets+relevant user stories