# HTML tag rendering

An old answer of mine just got an upvote, which caused me to look at it again, and I was surprised to discover that my HTML tags for italics (that is the letter $$i$$ between two pointy brackets) were not rendering. This made the answer almost impossible to read, because I had used italics instead of blockquotes to set off quotes from the original question, but the italics weren't rendering, so those quotes and my responses were all run together.

Aside from the fact that this makes the upvote a little mysterious, this makes me wonder whether something has changed and HTML tags that used to render properly no longer do so. If that's the case, then a lot of old posts (not just mine) probably need to be edited accordingly.

This is made more mysterious by the fact that when I attempted to type italic tags in this post, wanting them not to render, they did render, forcing me to go back and write the phrase "the letter $$i$$ between two pointy brackets". So is there a difference between the main site and meta? Or between questions and answers? Or something more obscure?

I'm using the "bug" tag for this, though of course part of my question is whether this is a bug.

Edited to add: The original version of the post that triggered this is here: https://physics.stackexchange.com/revisions/350351/1. I see now that this actually renders properly on my laptop, though not on my phone. In the two revisions that follow, I replaced the italic tags with blockquotes.

• Possibly the recent change to the rendering engine? If you use asterisk for italics you don't get the problem. For angle brackets I use mathjax langle and rangle. Oct 7 '20 at 7:23
• @JohnRennie: But if this is actually caused by a recent change to the rendering engine then I expect quite a few posts are affected. Is there some way to fix them all en masse, or do authors (or at least those authors who are in the habit of using html tags) have to comb back through their posts and fix everything by hand? (Or alternatively, of course, leave things in a state that makes them quite hard to read.) Oct 7 '20 at 7:27
• No idea, sorry :-( Oct 7 '20 at 7:28
• @WillO If you want to produce the output <i>, use backticks. Oct 7 '20 at 9:47
• The meta post about the renderer change was physics.meta.stackexchange.com/q/12936/44126.
– rob Mod
Oct 7 '20 at 14:45
• Can you link to a post (or its revision history) that displays incorrectly on your device?
– rob Mod
Oct 7 '20 at 14:53
• Can you also include version information for the browser/OS which displays incorrectly? The linked revision displays correctly on some devices.
– rob Mod
Oct 7 '20 at 15:09
• @rob: Thanks for your attention to this. First, I am using version 12.1.2.5 of the Samsung browser on my phone. (Apologies for not realizing in the first place that this info was important to provide.) Second, the italic tags were not rendering last night when I posted this, and were not rendering a few minutes ago when I looked again, just before posting the link. But now they're working and everything is rendering properly! I don't know what changed in those few minutes, or whether the change happened at my end or at StackExchange's. Oct 7 '20 at 15:15

A limited subset of HTML is supported on Stack Exchange. For details on what is and is not supported, see What HTML tags are allowed on Stack Exchange sites?. The italics tag <i> is indeed supported.

However: the primary formatting mechanism on this site is Markdown. Using HTML is not discouraged, but seriously... why would you use it? This SEDE query shows up 23 posts of yours with <i>, and for none of them can I see a reason to use explicit HTML <i>s instead of the recommended Markdown.

In any case, the Ask A Question page explicitly discourages mixing HTML with Markdown, so maybe the problem came from that? Presumably the post in question is this one, which does precisely this mixing. Moreover, the list notation you used there, 1), was not recognized as a list by Markdown until the recent change of renderer, so it went from not mixing HTML and Markdown to mixing them; that could explain the change in behaviour. On the other hand, the rendered revision I just linked to displays just fine on my device $$-$$ but then again, the Markdown parsers are currently a weird mix, so who knows exactly what happened there?

.... but ultimately: who cares. The post renders just fine if you remove the html shenanigans. Use the recommended Markdown and this type of issue doesn't have the opportunity to arise.

As for the possibility of there being a fraction of posts whose formatting changed due to this edge case (or some other similar one) of the Markdown renderer migration, I guess it is worth taking a look to see how many such posts there are. A broader query finds ~500 posts site-wide with <i> in the body (though this may be closer to 800?). If you want to have a dig, that is one place to start.

• I disagree with the perspective in this post. Writing is idiosyncratic and habits are funny things. If the documentation is that <i> is supported, people should not feel squicky about using it. I would expect edge cases to start appearing in text which intermixed <i> tags with * characters, but the linked revision (which seems to have been updated at the same time as this Meta was asked) displays as intended for me.
– rob Mod
Oct 7 '20 at 15:05
• Emilio: (I hope this doesn't sound snippy; it's not meant to): I've always used the html tags because they've always worked, they come naturally to me, and it never would have occurred to me to go off and read documentation about whether it's supported, any more than I'd have gone off to read documentation about whether it's okay to start sentences with capital letters. If it did work and has stopped working, that seems to me to be a problem, whether or not it was ever "supposed" to work in the first place. Oct 7 '20 at 15:08
• @WillO I'm glad they've worked for you thus far. But the documentation is clear that html and Markdown shouldn't mix, and it is readily available (click HTML on the post editor; if you don't see it click the ? or the Show Formatting Tips button). Your observation is that there may well be a few posts out there that mix HTML tags with Markdown in ways that get treated differently by how the old vs new Markdown renderers handle quirky edge cases. This was a known possibility at the time of the migration and impacted posts could indeed still be out there. Oct 7 '20 at 15:30
• ... which is why I would argue that the onus is on the folks who care about HTML support to go and look for them. The queries in this answer are a good starting point, but ultimately it requires the manual work of going through posts to check for impacts. Oct 7 '20 at 15:32

Your most recent comment suggests that this was a problem which happened only briefly on one platform, so for now I'll tag as "not reproducible." But if the issue returns, let's talk more.

Now that there’s a confirming report from another user, I’ve retagged as “status-review,” which brings the issue to the attention of the team.

• Yes, this sounds right. Thanks again. Oct 8 '20 at 0:15
• This morning I posted the following to meta: physics.meta.stackexchange.com/questions/13174/… . The italics are not rendering on my Samsung Galaxy, either in the Samsung browser (version 12.1.2.5) or in Chrome (version 84.0.4147.125). They render fine on my laptop, running Windows 10. I don't know whether these problems are entirely idiosyncratic, and would be curious to know whether anyone else is having them. If it's just me, I think there's absolutely no reason for you to spend time on this. Oct 11 '20 at 14:22
• PS---Just checked in Firefox on my phone; they don't render there either. (Version 68.11.0). Oct 11 '20 at 14:24
• FWIW, this issue is reproducible on my phone in several browsers. The italics in JMac's answer do render, though.
– Urb
Oct 11 '20 at 15:45
• @Urb Can you provide hardware/software version details?
– rob Mod
Oct 11 '20 at 18:21
• Huawei P10. Browsers: Chrome (v. 86.0.4240.75), Firefox (v. 81.1.4), DuckDuckGo (v. 5.67.0). This only happens in the mobile site; if I enable the Desktop Site option everything renders fine.
– Urb
Oct 11 '20 at 18:58

I've marked this as (it had incorrectly been marked as ) since we're moving away from mobile views and instead into responsive design land — and this bug appears to be specific to mobile views.