Render [empty links]() as <u> (or <a>)?

[geoff]

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 [foo]() as <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 [foo](#).

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…

Neh?

[chrisalley]

@geoff

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

Wouldn’t the <cite> element would be more suited to this? It is displayed as italics by default, but you could style it to be underlined.

[geoff]

Indeed… but if I recall correctly, it’s actually specified that certain types of works should be underlined, while others should be italicized. Strange, I know, but I swear it was specified like that.

[chrisalley]

Strange indeed. Maybe a CSS class could be used for the less common of the two (e.g. <cite class="special-citation-type">).

[geoff]

It was something like this.

[zzzzBov]

@geoff

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.

I disagree with that last statement.

the <a> element represents an anchor to content. When it has an [href] attribute it is a link to a different document or part of a document.

The markdown syntax of [foo](bar) is a mapping for <a href="bar"> so it is consistent for the href attribute to be left an empty string when the () part of the syntax contains an empty string. <a href=""> is still a valid link, and points to the current document. The markdown syntax for links has never included support for <a> elements as named anchors, so I don’t think it worthwhile to try to diverge the syntax in that direction (with the exception of optional extensions).

If you want the link syntax to support the concept of null, then the only way in my mind that that would be achievable would be to leave off the parens completely with [foo] mapping to <a>foo</a>. I don’t see that as being particularly useful as you’d still need a syntax to declare the [name] or [id] attributes, at which point you might as well have used HTML.

[geoff]

@zzzzBov

I disagree with that last statement.

the <a> element represents an anchor to content. When it has an [href] attribute it is a link to a different document or part of a document.

This is true only in HTML4.
In HTML5, <a> can not represent an anchor; it is either a link or a link placeholder.

@zzzzBov

The markdown syntax of foo is a mapping for <a href=“bar”> so it is consistent for the href attribute to be left an empty string when the () part of the syntax contains an empty string. <a href=“”> is still a valid link, and points to the current document.

I certainly don’t dispute that <a href=""> is a valid link, nor that this behavior is explicitly specified, presently. But I disagree that this is a “consistent” behavior, since the treatment of empty elements is currently all over the map.

Take collapsed reference links:

A collapsed reference link consists of a link label that matches a link reference definition elsewhere in the document, optional whitespace, and the string . The contents of the first link label are parsed as inlines, which are used as the link’s text. The link’s URI and title are provided by the matching reference link definition. Thus, [foo] is equivalent to [foo][foo].

But what if []: is used as a reference link definition, or if the definition [bar]: is empty?
Try a few of these on for size (Babelmark 2):
[]: foo [bar][][]: [bar][][bar]: [bar][][]: foo [bar]: bar [bar][] []: foo [bar]: [bar][]

As resolving these types of ambiguities is expressly the purpose of this standard, I would think the treatment of empty inline links should be up for discussion as well.

@zzzzBov

The markdown syntax for links has never included support for <a> elements as named anchors, so I don’t think it worthwhile to try to diverge the syntax in that direction (with the exception of optional extensions).

Again, note that <a> is not an anchor in HTML5. It is specified as “a placeholder for where a link might otherwise have been placed”, which is why I thought it might be a decent way to implement underlines, i.e., “a link without a link”.

I’m not really heavily invested in this idea, I just thought I’d throw it out there since there are so many requests for a way to underline text. But I think this is a good example why explicitly specifying which HTML revision is being targeted is pretty important.

And, I think the []: stuff might warrant opening an issue on Github, no?

[zzzzBov]

@geoff

But I disagree that this is a “consistent” behavior, since the treatment of empty elements is currently all over the map.

My argument is about consistency between the input and output, and not about the consistency of implementations. It’s much easier to see in an example:

This is consistent behavior:

[foo](bar)    <a href="bar">foo</a>
[foo](ba)     <a href="ba">foo</a>
[foo](b)      <a href="b">foo</a>
[foo]()       <a href="">foo</a>

This is inconsistent behavior:

[foo](bar)    <a href="bar">foo</a>
[foo](ba)     <a href="ba">foo</a>
[foo](b)      <a href="b">foo</a>
[foo]()       <a>foo</a>

@geoff

Again, note that <a> is not an anchor in HTML5.

I’m not sure how you can argue that the HTMLAnchorElement is not an anchor, when the actual spec clearly states:

If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.

emphasis mine

I recommend avoiding w3schools, they’re not affiliated with the w3c and often have moderately stale content.

[chrisalley]

I agree with that last part @zzzzBov. W3Schools should not be thought of as an alternative or replacement to the actual W3C spec. It has a mixed reputation for accuracy so we should avoid appealing to it in these discussions.