Using WordPress, it does not insert </p> at end of parragraphs

[frafor]

Using the same browser Chrome, with a window producing good email text, a Wordpress article can not be written using MDH due to the program NOT inserting the closing/opening

pair at the end of paragraphs. I'm using the MDH regular settings, the most standard ones.

The WordPress text editor renders an extra space after a single ENTER when a paragraph is done. I like that. I've seen the HTML code MDH generates and the only problem is that it is NOT correctly adding the

(previous paragraph) and

(next paragraph) in the HTML generated by MDH.

However, all of the above works perfectly well typing messages in Gmail.

[adam-p]

This is by design, although perhaps it could be better, so I'll leave this open.

Here's how it works, more or less:

We count up the <br> elements and <p> elements. Whichever one is more prevalent we assume is what the editor inserts when the user hits Enter. We consider this to be a single line break.

For editors that use <p> (like Wordpress), this has the upside of making code blocks and tables (and probably other stuff) not break, but it has the downside of not putting as much space between paragraphs as there is in the raw editor. Otherwise the user would have to hit Shift+Enter when she's entering code blocks and tables.

So if the user types out this kind of thing:

<p>
My para 1 sentence.
</p>
<p>
My para 2 sentence.
</p>
<p>
``
</p>
<p>
var a = 'first line of code';
</p>
<p>
var b = 'second line of code';
</p>
<p>
``
</p>

(Cheating on backticks.) Markdown Here converts that to this plaintext:

My para 1 sentence.
My para 2 sentence.
``
var a = 'first line of code';
var b = 'second line of code';
``

And so it renders with just a single <br> between those first two lines.

I did this on purpose. It means you can write Markdown exactly as you would in a text editor or in Gmail -- hit Enter once for a <br>, twice for a <p>, kind of thing.

However, maybe there's a smarter way. Something like:

If it's detected that <p> is the common line separator, then in the output replace <br> with <p> (which is trickier than it sounds, since there will already be <p> elements, and <br> tags are self-closing while <p> aren't, and so on). This will (probably) make the output look more like the input without breaking anything.

This will be tricky and a little bit dirty. And the behaviour should probably be optional. And it will need a lot of testing. Might work well, though.

[adam-p]

I thought of something you can try to get around this: Add more space to the <br> element.

In the Markdown Here options, add this to the Primary Styling CSS:

.markdown-here-wrapper[data-md-url*="wordpress."] br {
  line-height: 2em;
}

That will give more space to ordinary line breaks, making them look more like paragraph breaks. I'm not sure there won't be unintended styling side-effects, though. Please try it and and let me/us know how it works. Thanks.

[adam-p]

I created a couple of Wordpress test posts using the trick I suggested... with mixed results.

So, here's a post four ways:

1. The proper, raw Markdown. (And the actual original post.)
2. The proper Markdown, no special styles.
3. With almost all blank lines removed, no extra styles.
4. With almost all blank lines removed, with the style I suggested above (except 3em instead of 2em).

The extra space style is an improvement, although it's a mixed bag, as you can see. Limitations:

1. Sometimes line breaks sometimes appear where you don't expect them. For example, you can see that the definition list ("Page actions...", etc.) has way too much space around it; I probably could have cleaned that up by having all of the raw HTML for it on one line.
2. Only hitting Enter once often isn't enough. I had to add extra lines before horizontal rules, so that the next line wouldn't be a header, and after lists, so that the following paragraph wouldn't be part of the last list item.
3. The extra space isn't visible after rendering in the compose box. You have to "Preview" the post to see what it really looks like.

I think limitation number 2 is the real kicker. It means that you will need to learn where you can get away without a blank line and where you can't. It also means that I don't think there's anything I can do on the output side to make this better -- because real failures will start with parsing.

Unless you're willing to learn those input idiosyncrasies, ... you're not going to be able to have your cake and eat it too. In Markdown, you hit Enter twice to separate paragraphs. In Markdown, --- means one thing if you hit Enter once before it (header) or twice before it (horizontal rule). In Markdown, you need to hit Enter twice to end a list.

I think that the cleanest way to work with Wordpress is to ignore the extra paragraph space while you're composing -- write Markdown with your eyes closed. Hit Enter twice between paragraphs, etc.

But... if you learn the special cases, and use the special style... then maybe you can get proficient and comfortable with fewer double-Enter. Please let us know if you do.

I'm going to close this issue, since I don't think there's any code change that can be done here. I'm going to link to this issue from the Compatibility wiki page in case the info is useful to someone else.

(For the record, when creating the test posts I used a "typing paste" AutoHotKey script.)

[frafor]

No, thanks! Definitely, that would not be acceptable. I want the HTML to be
properly formed with

text ...

. An ENTER means "I want to end this
paragraph and begin another". The space after a
should remain normal.

Thanks for the suggestion, anyway.

On Tue, Oct 22, 2013 at 11:15 AM, Adam Pritchard
notifications@github.heygears.comwrote:

I thought of something you can try to get around this: Add more space to
the
element.

In the Markdown Here options, add this to the Primary Styling CSS:

.markdown-here-wrapper[data-md-url*="wordpress."] br {
line-height: 2em;
}

That will give more space to ordinary line breaks, making them look more
like paragraph breaks. I'm not sure there won't be unintended styling
side-effects, though. Please try it and and let me/us know how it works.
Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-26817699
.