I'm honestly with you on this and I'm in the middle of building a huge Markdown site where I have the freedom to change the syntax now if I want.
*this is bold*
/this is italics/
_this is underlined_
Beyond simple conventions like this, I'd just as soon drop into HTML as deal with some other markup that ends up being just as complex. We don't need to allow permutations and combinations such as bold and italics, double-weight bold, etc. these never occur in normal prose typesetting and if you need it just use HTML for those rare cases.The argument presented by that link is valid for paragraphs and valid for printed content.
On a website, underlining single words or short phrases doesn't make them less unreadable, it draws attention to them.
Like with hyperlinks; the displayed form of `[See here](http://here.com) for more inform` is undeniably better than simply `see here for more info` and leave the reader guessing which of those words is the text and which is a hyperlink.
The problem is exacerbated on mobile where the reader cannot hover a mouse over the words to determine which words are a link and which are not.
If you're writing a full paragraph like this:
"Our previous stories of FooBarFactory Inc were well-received by our readers. Investigative Journalism has always been a core principle of PotatoNews. The images and video that our beloved readers shared on Twitter are only a single component in the fight against big corps polluting our environment."
In the above paragraph, "previous stories" is a link, "FooBarFactory" is a link, "well-received" is a link, "images and video" is a link, "Twitter" is a link and "Polluting out environment" is a link.
The advice from Practical Typography would render that entire paragraph free of any indication that there's more for the user to read.
\* more than 3\/4's of people may not feel that way, particularly those discussing snake\_case Vs CamelCase
https://en.wikipedia.org/wiki/Camel_case
FWIW I use the same nomenclature as you, but that doesn't make it universal.
dis~/cuss/~ing
You need U+2044 FRACTION SLASH.
underlines is not used enough to take the commonly used character ~this is fine~, trailing tilde is rare enough
Since when?
I will say that forward slashes are still more common in regular english text even among non-programmers than underscores. For example, listing options a/b/c.
And you know, URLs.
Only if the intent is for the URL to be copy/pasted, otherwise you enclose the URL in <url> or [text](url) to make it clickable.
> While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
https://en.wikipedia.org/wiki/International_Phonetic_Alphabe...
So:
**strong text** -> bold "strong text"
\*\*doubled splats\*\* -> "doubled splats" w/ "**" on either side
This is also cumbersome to type, but at least there's a path to what you want to present even if the character is reserved for markup.And again, this complaint will only be relevant in contexts where this specific convention is used.
Fuck no. Same idiocy as turning -- into long em, makes writing any technical posts mighty annoying
Get better screen keyboard. On mine _ doesn't require shift, neither does *
I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard.
Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words that would normally be rendered as /italics/. You'd often see it used to indicate the titles of books and movies, as well, since the typographical convention was typically that these were italicized as well - note that both <em> and <cite> typically render as italics, for instance. I have always disliked Markdown's choice to use * as a delimiter for both italics and bold; / always implied italics to me, and * always implied bold.
Anyway. I propose that / would be a much better delimiter for emphasis than _. On a US keyboard, it can be typed without a shift key. And on a US IOS screen keyboard, it is a simple swipe on B, versus shifting to the numeric entry page and swiping on &.