Step 1: Add a new observation with some text in the notes field formatted using HTML code, or add a comment to an existing page using HTML code for italics.
Step 2: Save the page/comment. Result:Formatted text does not display in italics.
Step 3: Click “Edit” on page or comment to fix the lost code and realize the HTML code is actually still there. It just doesn’t work any more.
I’ve got 3,000+ observations, many of which use that tag in the notes, and I just don’t have time to go through all those to change it manually. I will never find all my comments that use the tag to italicize species names on other people’s pages. I’m sure I’m not the only one affected. If this is by design, I think it would be nice if someone could run a script or something to change all those old tags to whatever it should be now so it displays as intended. As we probably all know, species names should be in italics.
You are right, it’s listed a supported. And if it has worked before, it makes it a genuine bug. Thanks for the details and for filing this bug report. I’m sure the developers will fix this by either allowing back the tag or by converting it.
Actually, not quite right. In markdown, the asterisk is used to delimit “emphasis” NOT “italics”, so it is equivalent to html <em>. This may be getting a bit pedantic, but <em> is not guaranteed to render as italics (although it usually does). When we are writing comments with latin binomials, those really should be rendered as italics, not just emphasis, so the <i> tag is more appropriate than the markdown asterisk. (That said, I have started using the markdown * in my comments, just because it’s easier.)
The <em> and <strong> tags are required for accessibility, because italics and bold obviously mean nothing to a blind person. These tags have a purely semantic role. They are used to suggest how the text should be understood, rather than how it should be presented. To ensure understanding by the widest audience, it’s therefore best to use markdown, since the <i> and <b> tags can only suggest a particular formatting style. And note that this isn’t just an accessibility issue: for various reasons, some devices need to use different styling (such as underlines) to indicate emphasis.
@bazwal: I am a strong advocate for web accessibility, and I understand the role of <em> and <strong> in semantic contexts and their use in screen readers. My point is that italicization of scientific names is a style issue, not a semantic issue. In fact, Mozilla, in their usage discussion for <em>, uses scientific names as an example of where <i> is more appropriate:
Use the <i> element to mark text that is in an alternate tone or mood, which covers many common situations for italics such as scientific names or words in other languages. [emphasis added]
As I suggested before, this doesn’t really matter in practice for iNat, so long as browsers continue to render <em> in italics or underline. I will admit that I have not listened to how a screen reader deals with this kind of markup. I should try that if I can find a good example with both types of markup.
After doing a little research, there appears to be much less of a consensus on this issue than what I remembered from the last time I looked at it. On reflection, my previous post makes too many simplifying assumptions. The reality is much more complicated, and there’s sometimes a large disconnect between what content authors are trying to achieve and what users of assistive technologies actually want.
Me neither. My hunch now is that if it’s supported at all, many screen readers will probably have it switched off by default - because there’s just so much content out there that either misuses or overuses the markup.
Scientific names are a good case in point. Would users really want them to be voiced differently? For someone listening to a stream of text, the pronunciation alone should be enough to make the names stand out from the rest of the text. Any further emphasis woiuld be overkill (unless the entire text was written in Latin, of course - and maybe not even then).
While accessibility is certainly an important issue, it wasn’t the first thing that crossed my mind when I noticed that the tag is no longer working as intended. What did come to my mind is that the instructions for authors of every scientific journal out there that I’m aware of state that species names need to be italicized, and we try to teach our students that from their first lab reports on and take points off if they don’t follow the formatting guidelines on this. I know an iNat comment is not exactly the same as a scientific publication. But now that this is no longer working, lots of my old notes and comments are improperly formatted, potentially inviting student arguments about those lost points if we use iNat in class. It would be nice to have it working again or automatically updated so that those of us who went to the trouble of using the HTML tag to properly format species names don’t end up having done all that for nothing.
Yes, back on topic (apologies for wandering off into html trivia).
I’ve also noticed the problem with some of my older comments. Recently, while searching for examples, I discovered that the problem is not universal, but rather depends on the particular page on iNaturalist. For example, old html <i> tags seem to work on the “comments” page here:
I second this concern about the loss of rendering the html <i>text</i> tag as italics. I’ve looked back at a small sample of my own italicized scientific names in comments and notes and many of them are now rendered in plain text. For me, that is a huge and disappointing loss of clarity (and effort).
A part was fixed, but any current comment with markup that’s copied and pasted to another obs loses all text formatting (except url links). Not a big deal but a tad irritating.
If you edit your comment and copy it with the Markdown or HTML showing, that will copy the formatting (that’s how it always worked for HTML). You could submit a feature request for comment boxes to support copying the formatting as well as the text.
I’m going to close this bug report since it looks like the rendering of italics was fixed, but folks can open a new request if there are other HTML issues caused by the Markdown feature being added.
