Continuing the discussion from Feature Request: underline text:
While I full-heartedly concur with @zzzzBov:
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…
… there are a few rare instances where underlines could be necessary. For example, if I recall correctly, MLA-style bibliographic citations require underlining some titles.
So, I had a thought:
The rendering of
<a href="">foo</a>, while common to all(?) markdown implementations and included in the standard, can often create rather undesirable behavior (e.g., try it on Github’s markdown preview to see what I mean). Myself, I can’t think of a use case for a link like that, over say
It also seems out of line with the HTML5 standard, since there’s not really an anchor:
If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.
If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element’s contents.
If one were to strictly adhere to that, as I read it, I would think that
[foo]() should map to
<a>foo</a>, sans hyperlink. Unfortunately, however, it seems most browsers still treat it as a link.
So I thought perhaps this would be a not-too-invasive way to implement underlines. In fact, I think it maps pretty well to the use case specified in HTML5:
The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text…