🎨 Removed excessive new lines and improved header formatting in plain text email part

[exprez135]

see https://forum.ghost.org/t/unnecessary-and-excessive-newlines-in-plain-text-part-of-newsletters/60267/

• Previously relied on presence of \n in source HTML.
• Now sets reasonable new lines based on HTML elements.
• Formats headers for better readability.
• Tests added for all changes.

Headers now look like:

**********
Header One
**********

----------
Header Two
----------

Header Three and Four
---------------------

Header Five and Six

[muratcorlu]

Thanks for raising this with a PR to clean-up unnecessary newlines and make plaintext version more readable. But I'm hesitant if header styles would affect accessibility.

Here a document about formatting plain text email with WCAG references: https://parcel.io/blog/accessibility-in-plain-text-email

[exprez135]

Good morning—thanks for bringing this up. Let me take a look at the article you’ve linked and some other resources on best practices in this area. I’ll come back with a revised patch. Thanks!

[exprez135]

I'm returning with a couple questions, rather than a set answer for the best thing to do here. @muratcorlu you are right that WCAG technique recommendations for plain text would mean that headers should not be multi-line / semi-formatted like I've proposed here.

With this in mind, a few random considerations:

• These are WCAG technique suggestions, not standards.
• Based on some quick research into how the dominant screen readers and related software actually operate, I don't believe the header markup would significantly impede or change how they announce content on the screen. The markup also has the advantage of making a plain text structure easier to follow visually for those using plain text for reasons other than significant vision issues. (And it provides at least some information about header levels, while the WCAG suggestion would equalize all headers.)
• Nevertheless, I can update the patch to strictly follow the WCAG technique recommendations for headers.
• Either way, compared to the current system, this patch or a revised one would significantly clean up the plain text part and better access for those who need or use it for any reason.

Another issue to perhaps raise elsewhere, Ghost emails seem to almost always be missing an <h1> element. E.g. the title is in a whole centered table thing with classes for styling, but isn't actually a header element at all.

My proposal:

• either: adopt the changes as-suggested originally, or
• adopt only the fixes to new-lines, and when I or someone else has time, make a longer re-visit of how the plain text part is generated to ensure it creates the best possible experience.

[exprez135]

Hi @muratcorlu I've just pushed a new version of this PR that more conservatively uses the WCAG techniques as linked in the resource you provided. (In other words, no formatting to headers other than the extra newlines.)
I think it's more important to get this base change made to fix plain text emails now, and someone can always go back in the future to consider header formatting or other improvements to this part of the SDK.

[muratcorlu]

Hello. Firstly, maybe I should mention that, I'm not a member of Ghost team, so I'm not able to approve or reject any PRs in this repository. But I just wanted to share my opinion.

Your latest proposal looks legit to me. I hope someone from Ghost team considers this PR.