>
A semantic line break SHOULD occur after an […] em dash (—).I agree with this, however it means that no existing markup language supports semantic line breaks, because every last one of them just turns the break into a space—and em dashes are, in most locales, not to be surrounded by a space. Consequently, you’ll end up with a stray space if you do this.
My irritation at being unable to break after an em dash (which I want to do quite frequently) was one of the things that headed me down the path of designing my own lightweight markup language (LML), to fix this and other problems I observe with existing LMLs. I’ve been using it for all my personal writing for something like four years now (though a a fair bit has changed since then), and I expect to finally have a functioning parser before the end of this year.
One of the other fun complications of this kind of line break in source code is languages that don’t have a word divider—inserting a space at all is incorrect in them.
CSS presently just leaves such decisions UA-defined <https://drafts.csswg.org/css-text-4/#line-break-transform>:
> any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.
My LML currently turns segment breaks into a space unless the line ends with an en or em dash, unless there’s a colon or a space before that. I haven’t got anything in place for languages with no word separator yet, but it is unusually well-suited to such languages.
I agree with this, however it means that no existing markup language supports semantic line breaks, because every last one of them just turns the break into a space—and em dashes are, in most locales, not to be surrounded by a space. Consequently, you’ll end up with a stray space if you do this.
My irritation at being unable to break after an em dash (which I want to do quite frequently) was one of the things that headed me down the path of designing my own lightweight markup language (LML), to fix this and other problems I observe with existing LMLs. I’ve been using it for all my personal writing for something like four years now (though a a fair bit has changed since then), and I expect to finally have a functioning parser before the end of this year.
One of the other fun complications of this kind of line break in source code is languages that don’t have a word divider—inserting a space at all is incorrect in them.
CSS presently just leaves such decisions UA-defined <https://drafts.csswg.org/css-text-4/#line-break-transform>:
> any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.
My LML currently turns segment breaks into a space unless the line ends with an en or em dash, unless there’s a colon or a space before that. I haven’t got anything in place for languages with no word separator yet, but it is unusually well-suited to such languages.