It would be nice to have a support for underlining text. It is a complement to strong, italic, and strike.
The html tags <u>bla</u> exist, and can be used to represent text that should be stylistically different from normal text.
4 Likes
Markdown already supports this element:
<u>here's an example!</u>
In all seriousness, the <u> element is generally best avoided, the spec explicitly says so
In most cases, another element is likely to be more appropriate…
The purpose of markdown isn’t to make a 1:1 mapping of HTML features to simple syntax. The purpose is to provide a convenient manner for authoring text and provide coverage for the most commonly used features. Because of this, I don’t see any reason to add support for the <u> element to the standard spec.
It might be worthwhile as an optional extension, along with support for <cite>, <dfn>, <abbr>, <q>, <small>, and a number of other less commonly used elements.
3 Likes
Bold, italic, underline, and strike have been the basic formatting possibilities since (at least) the BBS. Even today, it is common to see people marking some text for *importance*, /implicit meaning/, the _Title_of_a_movie_, or for providing -corrections- modifications.
Supporting those 4 basics formatting styles would just ensure the continuity of practice.
1 Like
My point was that it does support those formatting styles. What it doesn’t do is provide a shorthand for underlined text.
Not providing a shorthand is not the same as not supporting the feature at all.
1 Like
Underlining has been in use since typewriters couldn’t emphasize text otherwise. Now, we can emphasize with italics, bold and bold italics and thus underlining is not necessary but merely an historical artefact. By the way, your list of semantic modifications lacks some statistic background. And as said before by others, there’s always the HTML fallback.
2 Likes
Let me weigh in by pointing out something that hasn’t been touched on here before.
Bold, italic, underline, and strike have been the basic formatting possibilities since (at least) the BBS.
The spec never mentions the words “italic” or “bold”. These are not actual features of the Markdown syntax. Instead there is “emphasis” and “strong emphasis”. Neither does Standard Markdown specify that these must be styled with italics and bold styles respectively.
Markdown offers no way to “represent text that should be stylistically different from normal text” (maybe it should?) so there is nothing in Markdown that would be complemented by adding an additional syntax to support something as specific as underlining text.
Instead you could set your renderer to mark emphasis by underlining rather than any other styling. In the case of HTML this would be done by setting custom CSS.
3 Likes
True, but it’s a standard that one _ and * mean italics, and two mean bold. People would be angry if you switched those meanings around in all current implementations. It’s the standard way to do it. Because it’s not in the spec now doesn’t mean it shouldn’t be.
I would rather consider it a common misconception than a standard that _/* should mean italic and __/** should mean bold.
The emphasis translates into the emphasize tag (<em>), while the strong emphasis translates into the strong tag (<strong>). Notably not being translated into neither <i> nor <b> for the exact reasons Zegnat mentioned above.
4 Likes
As a web designer, you can easily make text underlined with some simple CSS like this:
<style type="text/css">
em {
text-decoration: underline;
}
</style>
*emphasis* can then be written in Markdown normally by the content writer, but styled differently for the particular website that it is used on.
I’m opposed to presentational elements in either HTML or Markdown because they violate the separation of concerns principle. It is the web designer’s job to decide how content is presented, not the content writer’s.
Does anyone even use _ in place of * in *italic* or **bold**? If we can get a corpus of current markdown comments, I would like to know the amount of usage of _. I’m guessing not enough people is using it enough, and could be used for underlining purpose without much harm.
(I personally never used _, never seen the point. But I can see the usefulness of underlining or highlighting like _this_text_is_underlined_. )
I think if you want to implement stuff useful for reviewing, check out http://criticmarkup.com/ for inspiration
I always use * for emphasis as well. _ looks jarring in the middle of a sentence, __ for strong emphasis even more so.
There are at least a couple of issues with changing the meaning of _ though:
-
It will break (many?) existing Markdown documents.
-
Underlining is presentational information. I realise that the HTML5 spec changes the meaning of
<u>but this is quite confusing, and causal writers would probably think that the text should appear underlined.
From the HTML5 spec:
The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.
If this meaning of <u> is to be supported (in some form) I would like to see some real world examples of it’s necessity. The HTML5 versions of <b>, <i>, and <u> all seem unnecessary and likely to cause confusion with their former presentational meanings.
Underlining is presentational information. I realise that the HTML5 spec changes the meaning of
<u>but this is quite confusing, and causal writers would probably think that the text should appear underlined.
Fair enough. Another approach could be just to define a set of separate class and avoid the <u> tag entirely. Or we can just stay practical, and know that in the real world, most browser is unlikely to diverge from treating <u> as underlined text.
There is the language of w3, and the is the language of real world users. We should strive to keep to w3 as much as possible, but don’t forget our Ghetto roots and lets not be afraid to break away as needed.
Btw here’s another approach to underlining as covered in http://talk.commonmark.org/t/highlights-strikeout-underlines/
>>__ underlined text __<<
Agreed. I think it largely depends on why you’re making the text underlined. That reason will often correlate to a semantic meaning, and the web would be better off using the appropriate tag (<cite>, <em>, etc) instead.
Okay I’ll shall check out of this discussion then, in regards to html representation. Since it’s getting out of my experience. I’ll say tho that if given a choice, I’ll just go the rebel route and use <u>, since I want it to show up even if there is no CSS available.
Anyway, I’ll be in http://talk.commonmark.org/t/highlights-strikeout-underlines/ to recommend the >><< format for highlighting, strikeouts, and underlining. Which I think is an elegant way of not screwing the parser with conflicting edge cases.
Underline is presentation and not semantic. Also note, that <ins> (suggested as ++inserted++) is shown underlined by default.
1 Like
More and more people are using or trying to start using Markdown for creative work but stumble into this issue, seeing it as a limitation.
You try telling a blogger or a book author that underlining must not have a shorthand because it’s not semantic, despite prolific use in publishing and typography.
As well I’ve seen people struggling to use Markdown in manual digitizing of paper media and, you guessed it, — it’s full of underlining.
Tell them they don’t need it because W3C decided to have a mid-life crisis.
When trying to emphasize a piece of writing with pen and paper, there’s nothing more intuitive and shorthand than underlining it.
If you include unconscious users of Markdown on various Markdown-enabled platforms, Markdown is presentation for most of its users. Just as with HTML, which Markdown is a shorthand to.
I’ve been personally running into this snag ever since Markdown became a thing.
Got in the way of producing an ebook, gets in the way of blogging…
This technicality-based “non-semantic” excuse has very little to do with organic use cases.
Not to mention that in my own usage of bold, italic and underlined I assign separate semantic function to each.
P.S. Discord had underlines in its own flavor forever as __underline__ and it’s been the sole respite.
3 Likes
People should familiarize themselves with current style guidelines if they’re in creative work.
There’s no prolific use of underlines in modern publishing. Style guides recommend italics for emphasis (which should be kept to a minimum) and strongly discourage the use of underlining except for very specific purposes (like transcribing a handwritten letter)
MLA Style
In MLA style, you should italicize (rather than underline) the titles of books, plays, or other standalone works. You should also italicize (rather than underline) words or phrases you want to lend particular emphasis—though you should do this rarely.
CMoS
Change underlining to italics. Some underlining, however, may be intended
to represent true underscore—in, for example, a collection that transcribes
handwritten letters; this should be preserved, with a note to the publisher explaining
the exception.
Occasionally, boldface or underscore (also called underlining) is used for emphasis. In formal prose, especially in print, italics are usually more appropriate.
1 Like
What @danielgrad said is nonsense!
- There is no global consensus about style guidelines, it differs by country, language, culture…
- If you want markdown to stay universal, stop thinking of it as if it is only used to write text in English.
There are 2 proposed syntaxes for the inserted/underlined text:
-
__text__(adopted by Discord)- Pros:
- Good backward compatibility with old documents as we don’t actually add a new tag.
- Cons:
- It will replace an existing tag (
__bold__), and**bold**will become the only way to write bold text (which can be considered as a breaking change?).
- It will replace an existing tag (
- Pros:
-
++text++(as suggested by @vitaly)- Pros:
- Very simple and descriptive.
- Cons:
- A new markdown tag === breaking change.
- Pros:
Choose wisely.
2 Likes
I cannot agree more. Being French, and writing in French (not here obviously 
) it is very clear that the semantic of the writing is different is both languages.
CommonMark should not be about semantic but representation. There are already plenty of semantically descriptive languages ( SGML, for example), no need to create another one.
1 Like