Feature Request: underline text

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.

3 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.

4 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:

  1. It will break (many?) existing Markdown documents.

  2. 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

For fun, I created the plugin markdown-it-underline.

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.

1 Like