4

This question is related to Inconsistent handling of not-encoded URL in preview.
But this time the illegal character is an &, where a difference between the preview and the post still exists.

Please compare this broken link right here and on the preview window of an edit where it is handled (in-)correctly.

2

2 Answers 2

3

The check in the server-side Markdown version whether a &... sequence should be considered an HTML entity or not (in the latter case, the & is converted to &) had a little scoping bug in the regular expression (a trailing semicolon wasn't required in all cases).

Fixed in the next build. Thanks!

3

&#9886223 is being transformed into that character by your browser. SO actually renders the following HTML:

<a href="https://forums.oracle.com/forums/thread.jspa?messageID=9886223&#9886223" rel="nofollow">broken link</a>

This happens because strings in the &#... format are XML entities.

A difference between the preview and the post exists probably because JS used by the previewer is converting & into &amp;.

2
  • Yes, I don't expect the link to work. But it shouldn't work in the edit pane, too. Users get confused if their link is working in the preview, but later in the post it isn't.
    – tanascius
    Commented Oct 12, 2011 at 8:59
  • Thanks for the explanation of the conversion in the preview +1. But for me it is still a bug (in the preview).
    – tanascius
    Commented Oct 12, 2011 at 9:00

You must log in to answer this question.

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