Possible Duplicate:
Can the </pre> tag start in a new line (possible previewer bug)?

  1. Edit this post and look at the preview. Note how the preview incorrectly shows that the following preformatted text will be part of this bullet, and thus the next numbered item will be "2".

    This is some preformatted output that requires more whitespace before it
    will actually be considered part of the same bullet point.
  2. Also note that World in the following is not shown as part of the preformatted block in the preview, but as shown on the live page it is correct.



  1. See that the last preformatted block in this answer has only one blank line, but when you edit the page you see three blank lines in the preview.

Edit: In all three cases, I think that the 'live' formatting is correct, and these are just three instances of the preview-during-edit giving a false account of what the outcome will be.

  • I think this has been a known bug for over a year. – Gabe Mar 30 '11 at 23:24
  • 1
    @Gabe Then vote this up and let's get it fixed. A broken preview is almost worse than no preview at all. (Alternatively, point me to the duplicate bug report and I'll happily delete this report and test cases.) – Phrogz Mar 30 '11 at 23:25
  • I may be wrong, but it sounds like this: meta.stackexchange.com/questions/24451/… – Gabe Mar 30 '11 at 23:33
  • @Gabe I think you're wrong (said politely). That link seems to be talking about unwanted whitespace, while I'm showing three (different-from-that-post-I-think) cases where the preview is different from the actual results, and I think that the actual results are correct in all three. – Phrogz Mar 30 '11 at 23:37
  • Why are you using <pre> tags? Where is the markdown syntax lacking that you need to revert to HTML tags? – Cody Gray Mar 31 '11 at 5:25
  • @CodyGray I have historically used <pre> to get preformatted text blocks without syntax highlighting. The answer that I was composing when I ran into these problems this does use 8-space-indent for code blocks in the bullet lists, and then follows with <pre> to show un-highlighted results of running those blocks. – Phrogz Mar 31 '11 at 12:35
  • @balpha This bug report showcasing three different (but possibly related) bugs is unrelated to the report you have closed it in favor of. Please reopen. – Phrogz Apr 1 '11 at 20:29

Adding raw HTML to the mix is not recommended and certainly not something we make explicit guarantees about vis-a-vis the preview.

Any reason you can't just indent 8 spaces to get a preformatted block in your list, in other words, stick to markdown alone?

  • @JeffAtwood See my response to Cody above as for why I was doing this. As I suspect you know, Markdown was designed to happily encompass raw HTML, so I wonder why you would say that it is not recommended. Further, why would you not make guarantees about the preview? If the same code (or algorithms) are used in both locations, every quirky outcome of bizarre markup would produce identical results. – Phrogz Mar 31 '11 at 12:38
  • @phrogz what you are doing does not need HTML. That's what's wrong with it. – Jeff Atwood Mar 31 '11 at 21:43
  • @JeffAtwood I mostly don't understand your response. My contention is that the preview should always match the output (WYSIWYG). The choice of markup being used seems a red herring distracting from that truth, except that the bugs in this case happen to involve HTML (that is allowed both on Stack Overflow and in Markdown). That said, I am very interested to know what the recommended method is for marking up preformatted blocks of text that should have no syntax highlighting applied. – Phrogz Mar 31 '11 at 21:49
  • The only answers I have found on meta all indicate that <pre> is the correct (only?) way to have preformatted text blocks without syntax highlighting. For example it is recommended by one moderator here, another moderator here, and a mere mortal here. – Phrogz Mar 31 '11 at 21:59
  • 4
    @phrogs not correct, use <!-- language: none --> as the block prefix instead – Jeff Atwood Mar 31 '11 at 22:05
  • @JeffAtwood Thanks! I somehow overlooked that as the very first item on the list of 'languages' supported. How embarrassing. That certainly gives me a no-HTML option in this case. – Phrogz Mar 31 '11 at 22:15

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