Spec
dclauzel — 2014-09-04T12:31:38-04:00 — #1
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.
zzzzbov — 2014-09-04T13:44:31-04:00 — #2
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.
dclauzel — 2014-09-04T15:54:05-04:00 — #3
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.
zzzzbov — 2014-09-04T16:37:44-04:00 — #4
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.
matze — 2014-09-04T16:39:53-04:00 — #5
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.
zegnat — 2014-09-04T17:29:12-04:00 — #6
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.
bnb — 2014-09-04T17:36:10-04:00 — #7
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.
mex — 2014-09-04T19:24:27-04:00 — #8
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.
chrisalley — 2014-09-06T02:09:33-04:00 — #9
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.