Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 153 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

I just got bit by this twice, posted a question where all my nice little generic types got their <> brackets axed. So I edited it and used the html entity. Annoying - but it worked. Then I posted a comment using all those friendly little entities, and they were output as is - I had to edit it and change them back to brackets.

My suggestion:

Escape brackets to html entities in posts, since stripping them is never what the poster would intend.

Then there would be some consistency - and sanity.

share|improve this question
can you extend your question with an example to illustrate the proposed change? – Peter Mortensen Jun 1 '10 at 8:41
This problem occurred for the OP, I think, in where the brackets were inline: "... If I have two classes, generic Foo<T> in AppDomain #1, Bar in AppDomain #2 ..." – Peter Mortensen Jun 1 '10 at 11:34

You should properly include any code snippets in the right markup, so your generic types won't get stripped: Use backquotes to mark inline text as code, or

indent your code with four spaces like this
(which can also be done with the little binary icon in the WSIWYG editor).

like this

share|improve this answer

HTML entities aren't stripped per se, it's just that white listed HTML is allowed in posts while other html tags are deemed dangerous and removed. You can see this in the preview area below the post window.

Perhaps a middle road is to change the markup parser so that when it encountered a tag that is not allowed or broken (including a stray tag opening like <) it should escape that tag instead of removing it.

So if the parser encounters this:

<script>alert('ha ha ha');</script>

It will be converted into this html code:

&lt;script&gt;alert('ha ha ha');&lt;/script&gt;

Instead of this html:

alert('ha ha ha');
share|improve this answer
I'm all in favour of this solution... it is common practice to use <whatever> as a placeholder, and needing to reach for my mouse to highlight & format slows me down. It's also a fix done after typing content, so it's too easy to miss one 'tag' that just disappears. – Phil Lello Apr 19 '11 at 18:31

In any context where math is discussed this causes problems. See, for example,

To be honest, I simply cannot believe this is by design! Whatever design that assumes users know HTML entities (or, even when they know about them, that it is sensible to have them be typed) has to be redesigned... This probably causes loss of data, I guess, too?

Of course we don't want random html elements to be parsed, but anything not allowed can be escaped. I would love to hear arguments supporting the view that the escaping should be done by the user and not by the app (client/server/whatever: the user need not know the details just as much s/he need not know about HTML entities...)

share|improve this answer
I would say escape by default, allow known-safe to go as-is – Phil Lello Apr 19 '11 at 19:11

I wish I could upvote this more.

If the engine continues to strip out text in angled brackets, users should be warned while composing and when submitting their questions/answers/edits if they have entered anything in angled brackets that's going to be stripped out. I can see no compelling reason to keep the current behaviour of silently dropping the text - either escape it or warn conspicuously in the preview and on submit.

It's too easy to forget to escape your angled brackets in running text, especially when discussing generic types. If you say IDictionary when you mean IDictionary<int, string>, your answer can easily become subtly but critically wrong. If a paragraph refers to many generic types it can be especially difficult to proof-read and catch the ones you forgot to escape.

share|improve this answer
Wrong things should look wrong. Otherwise, we're enabling people to be careless and sloppy and it won't matter whether they even try to format code as code. And there is quite enough of this on the network already, thank you very much. – Jeff Atwood May 7 '11 at 9:35
Um, are you agreeing with me or not? I 100% agree that "wrong things should look wrong". When you do the "wrong thing" - i.e. write text that includes angled brackets without escaping it - it quietly drops the text in angled brackets, and you'll only notice if you look closely at the preview. The OP proposed solving this problem by changing the meaning of angled brackets in this context so that it's not a "wrong thing". I proposed instead changing the behaviour of the preview and of post submission to make it "look wrong". If your argument is for the status quo, I don't understand. – Weeble May 7 '11 at 13:55
so when you type text and it doesn't show up in the final rendered post or the preview, that is NOT "looking wrong" to you? – Jeff Atwood May 8 '11 at 4:49
It looks wrong, but only if you look very closely. I've been caught out by this and only noticed days later when I went to check on my answer and happened to notice when I read over it again. I would not be surprised if I have made this mistake elsewhere and not realised. Proof-reading is hard - harder than many people realise. Since this is a scenario where you know the user has made a mistake, it would be nice if the software could say so rather than going ahead with subtly broken text. Fair enough if you think the effort is best spent elsewhere, but surely you can see it would be helpful? – Weeble May 9 '11 at 12:12

You must log in to answer this question.

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