Pre/script/style should allow blank lines; end with closing tag match

#1

The current rules for HTML blocks are a bit twisted; they make sense given the annoying constraints imposed by the existence of indented code blocks, but they make it ridiculously hard to include <style> or <script> blocks in a Markdown file, as they almost always contain blank lines. <pre> also commonly contains a blank line; the suggestion to instead just insert a linebreak character reference is pretty obnoxious to actually use in practice. (I’ve done so in the past

<style>, <script>, and <pre> should all parse their contents literally, looking for a closing tag (or end of document) to stop. I suspect this will match actual usage better, though I don’t have data to back me up on that.

#2

+++ tabatkins [Sep 03 14 23:21 ]:

The current rules for HTML blocks are a bit twisted; they make sense
given the annoying constraints imposed by the existence of indented
code blocks, but they make it ridiculously hard to include <style> or
<script> blocks in a Markdown file, as they almost always contain blank
lines. <pre> also commonly contains a blank line; the suggestion to
instead just insert a linebreak character reference is pretty obnoxious
to actually use in practice. (I’ve done so in the past

<style>, <script>, and <pre> should all parse their contents literally,
looking for a closing tag (or end of document) to stop. I suspect this
will match actual usage better, though I don’t have data to back me up
on that.

So, the proposal is to special-case these three tag types, keeping
the rule the same for the others?

#3

@jgm: When you copy-pasted my text into your response, you didn’t re-escape the element tags, so the rest of your comment got swallowed by a <style> (and subsequently stripped by the HTML filter).

#4

Yes sorry about that we are still working out proper rules for handling email replies in Discourse. I manually fixed it up with an edit, but please do open meta topics suggesting ways for us to better process email replies as this is an area of interest for us, we want Discourse to work well for traditional mailing list users.

#5

@jgm: Yes, my proposal is for those three tag types. (Possibly also <xmp>, a deprecated but still supported HTML element for writing out “examples”, as it treats its contents as literal text until it hits a </xmp> tag. But I’d understand if the spec chose to not care about rare long-deprecated elements.) Those are the three that contain non-plain text in practice, and really don’t want to have their contents interpreted as Markdown.

I already do this in my own tool.

#6

@codinghorror, it’s my fault, not Discourse’s. My (console) mail reader is set up to display HTML emails using lynx, so when I replied it quoted the lynx-rendered text rather than his original email. I’ll see if I can fix this.

#7

Note that Discourse sends you the raw markdown in the text section, so that should be helpful trying to figure out the replying.