3

Not a big issue as this won't happen often, if ever again. (But it just scared me a lot when I messed up the Recent feature changes to Stack Exchange with this revision.)

The following does not render as expected:

<!-- Some comment, no blank line following it -->
Text

- List item
- List item

<!-- More comment, followed by blank line -->

More text

This shows fine in the preview, but after saving renders as:

Text - List item - List item
More text

However: adding a blank line below the first comment, or removing the blank line below the second comment, fixes this. (Also completely removing the second comment fixes this.)

The resulting HTML currently is:

<div class="post-text">
Text

- List item
- List item



<p>More text</p>
</div>

rather than:

<div class="post-text"><p>
Text</p>

<ul>
<li>List item</li>
<li>List item</li>
</ul>

<p>
More text</p>
</div>

(This might have the same cause as another edge case, which has been fixed though: Newline before closing </pre> might break formatting in other parts of same post.)

Update, this might be related, so for now I'm adding it here:

When manually specifying a Prettify language, one needs a bank line between the <!-- language: xx --> line and the code block. However, the preview doesn't care if it's missing. Like the following looks fine in the preview:

<!-- language: javascript -->
    if(preview != result){
      alert("Big difference"
        + " in final result!");
    }

...but is rendered as:

if(preview != result){ alert("Big difference" + " in final result!"); }

Improve this question
6
  • No, this is unrelated to the other one. This is a particularly nasty bug specific to HTML comments.
    – balpha StaffMod
    Jan 12, 2011 at 16:11
  • @balpha, but not too important at all, if you'd ask me. Marking status-declined is very fine with me!
    – Arjan
    Jan 12, 2011 at 16:16
  • Oh no, that will be fixed. This can mess up the formatting in a pretty weird way (and it can happen in the client-side version too, just in a slightly different way). I know where the problem is, just have to find the best way to fix it.
    – balpha StaffMod
    Jan 12, 2011 at 16:23
  • Okay, @balpha! I was, by the way, surprised to not see the comment in the resulting HTML. Perfectly fine of course, I had just not given that any thought.
    – Arjan
    Jan 12, 2011 at 16:26
  • The comments are removed by the sanitizer after the processing; too many potential security issues with leaving them in. And since they don't matter in the final output, I guess that's fine. But the "Recent feature changes" is a perfect example of where they're actually a good thing. Funnily enough, the Markdown specification doesn't mention HTML comments at all, but the original implementation does handle them (with the same bug, of course).
    – balpha StaffMod
    Jan 12, 2011 at 16:34
  • @Arjan: yes, @mention notification still works :)
    – balpha StaffMod
    Mar 9, 2011 at 8:50

1 Answer 1

Reset to default
4

This is actually several issues at once, but they are fixed now (partly by this fix, partly by making the JS version behave a little more like the C# version).

The newline between the language specifier and the codeblock is now mandatory in the client-side version as well, so you the preview shows you immediately if it's broken.

The issue with the "recent feature changes" question is also fixed. That particular revision is still considered broken (and actually in another way than the one you encountered), but it's broken equally in the preview and in the rendered version.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .