2

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.

    Hello

World

  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.

Improve this question
7
  • I think this has been a known bug for over a year.
    – Gabe
    Commented Mar 30, 2011 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
    Commented Mar 30, 2011 at 23:25
  • I may be wrong, but it sounds like this: meta.stackexchange.com/questions/24451/…
    – Gabe
    Commented Mar 30, 2011 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
    Commented Mar 30, 2011 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
    Commented Mar 31, 2011 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
    Commented Mar 31, 2011 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
    Commented Apr 1, 2011 at 20:29

1 Answer 1

Reset to default
3

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?

Improve this answer
6
  • @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
    Commented Mar 31, 2011 at 12:38
  • @phrogz what you are doing does not need HTML. That's what's wrong with it.
    – Jeff Atwood
    Commented Mar 31, 2011 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
    Commented Mar 31, 2011 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
    Commented Mar 31, 2011 at 21:59
  • 4
    @phrogs not correct, use <!-- language: none --> as the block prefix instead
    – Jeff Atwood
    Commented Mar 31, 2011 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
    Commented Mar 31, 2011 at 22:15

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