In this forum, we can use markdown, bbcode or html to format with. I get a reminder every time I write a reply! It would be nice if we had similar in iNat comments etc, as it is clumsy to have to type italic tags around taxa so often! I had gotten so used to typing the tags, that it was not until this forum that I realised how much of a pain it is! Even if it is just italics, given that we should be using it for genus and species names, would be appreciated!
I’d like to see this, although I’ve run out of votes. Being able to add italics with a simple slash before and after a name would be nice, e.g. /Homo sapiens/
5 Likes
I certainly wouldn’t mind buttons, sort of like we have on the Discourse forum. I’ve gotten used to just typing the stuff (I’m a bit of a Wikian, so this level of code isn’t too terrible at all), but it really does seem a bit odd not to have buttons for the simple stuff, especially if you’re like me and cringe a bit on the inside upon seeing a specific or generic name not italicized.
4 Likes
Yes, it would be really nice to have a limited form of standard markdown in comments, rather than the clunky html syntax.
All that’s really needed is *italic*, **bold**, [link](http://example.com) and perhaps .
6 Likes
I like that! We have been considering making a preview pane as well, similar to Discourse, so you’ll know what you’re posting before you actually post it.
10 Likes
Just in case it wasn’t obvious enough for those not familiar with Markdown from @bazwal’s comment, In Markdown you can use wrapping single asterisks for italics: *Homo Sapiens*, so using slashes would be unnecessary.
1 Like
A note that I updated the title of this feature request to refer to text formatting more generally than just italics.
3 Likes
Writing a spec for this but I’m not sure when it will be implemented - possibly after City Nature Challenge. Hoping we can include a preview pane like Discourse as well. I will close this topic.
5 Likes
Awesome, thanks!
1 Like
Been tinkering with this a bit, and I have some questions:
- Does using a
BandIin icons for bold and italic buttons make sense for people who aren’t viewing the site in English? Or do those need to be translated? I’m talking about buttons like this:
- Supporting markdown will screw up some text that is unintentional markdown. Is that ok? For example, this is probably an extreme edge case, but I sometimes write down the couplets I used in a key like
1. Hairy patella
4. Red tail
18. Falcate toes
If we allow markdown, this will render like
- Hairy patella
- Red tail
- Falcate toes
Minor problem or serious problem?
- This is just about ready to go on the web, but will take some time to implement in the apps. Markdown looks sort of ok without parsing. Would people be ok seeing it unparsed in the apps for a little while?
5 Likes
This would probably generate a lot of bug reports from folks who haven’t read this topic.
6 Likes
-
I suspect those icons are familiar to almost all web users and don’t need translation, but as a native English speaker I might be assuming too much.
-
I think you’re saying that adding markdown support might change the display of existing comment text, which could be a problem. An option to toggle markdown on and off might be a way around that. If the format change just applies to new comments that unintentionally use markdown conventions, I think people can live with that.
-
I concur with @jdmore that showing markdown text unparsed in apps could confuse many people. How long is the “little while” it might take to have markdown available in apps, too? If it’s only a few months it might be better to wait.
4 Likes
Most use of markdown is going to look like
I **really** think this is *Amsinckia*.
which doesn’t look too weird to me. But yes, we could add a toggle. I don’t love that option b/c it means markdown works in some places but not all places, and every single place where you can add text we would have to add a little checkbox that says “Markdown?” which seems like an extreme amount of complexity to handle a few edge cases like my weird key-tracing habit. Much easier to both implement and understand if markdown simply works everywhere you can enter text on iNat.
“A little while” is going to mean a few weeks in Android and maybe months for the iPhone.
5 Likes
Checking an example of markdown, I agree that there should be few instances where unformatted markdown would be confusing.
Taking that into account, a few weeks or months with a small percentage of users taking advantage of markdown doesn’t seem like it will generate large amounts of ambiguous content. So the effort (and clutter) required to add a toggle seems unnecessary, and I don’t think you need to wait until all platforms are ready.
BTW, will content already formatted with HTML tags continue to show correctly after this change?
1 Like
It should not change. We have way too much existing HTML to abandon it.
5 Likes
I concur, raw markdown seems self-explanatory when a reader considers the contextual clues. A toggle could generate confusion for those who do not know what markdown is. Stay simple. Just my opinion, and perhaps my comments are limited to English orthography.
2 Likes
Standard markdown has a simple escaping mechanism for disabling unwanted markdown. So your example could be fixed like this:
1\. Hairy patella
4\. Red tail
18\. Falcate toes
Will the iNat implementation support that? Even if an on/off button was easy to implement, it would be far too crude, since it would always affect the whole text. What’s really needed is a simple way to disable markdown only for certain parts of the text.
We’re not going to write our own Markdown parser, so yes, we should support that if any of the parsers we use support full standard Markdown. The problem isn’t really how to not write new Markdown, it’s what to do about existing unintentional Markdown. Like we could edit all existing comments that look like an ordered list in Markdown and escape them but… that seems potentially error-prone.
2 Likes