i and b vs em and strong

[snan]

Em and strong aren't always the right thing. Is there a way to get i or b?

I know we love semantics over rendering but em and strong are sometimes hypercorrect. Looking at the html source of someone who wrote in Markdown and seeing em and strong when they clearly meant i or b, or sometimes cite.

For example when introducing a new name or term in another language.

[Crissov]

Implementers (or plugin authors) could decide to use asterisk * for em / strong and underscore _ for i / b or vice versa, but I think it is too late to make this a mandatory change – also it is a distinction rather specific to HTML output.

PS: I prefer the underscore for presentational elements, because it fits well with introducing underlined u when four of those characters are used.

[alerque]

Inkwells have been drained and spools of paper emptied rehashing the arguments for whether <em>/<strong> or <i>/<b> should be the default HTML output for the markdown elements. The lack of reference to prior discussions doesn't really endear your argument to anybody, most of the arguments for & against a tag pair cut both ways.

The short version is that this is an HTML distinction that doesn't exist in Markdown and use cases vary so each application may make different choices on how to map the elements to another format. Markdown only has one pair of semantic elements (in spite of having to syntax options) while HTML has two. You can really only map to one of them at a time. Many rendering engines give you the option, or a way to filter tags and write them how you please. Doing both is not really at option at this point for legacy reasons.

[snan]

Personal attacks and assumptions about what I've researched are not appropriate. I'm not new to the topic of what elements Markdown should use. I'm just new to CommonMark specifically.

HTML has two

With one being a not-always-valid subset of the other.

[alerque]

I wasn't making a personal attack. I did assume since you didn't even hint at knowing any of the background that you might not be aware of it. In any event if you are aware of some of the background then surely you know jumping in with a dogmatic assertion that one set of tags is better isn't going to resolve things.

With one being a not-always-valid subset of the other.

No, one is not a subset of the other. It's more like two competing standards, one focusing more on structural semantics and the other on presentation and legacy. If one was a subset of the other, the superset would always be interchangeable with some loss of meaning. Such is not the case, one could intend a kind of emphasis that was not supposed to be styled with italics or just as well as italics may not be used only for emphasis.

[snan]

I didn't mean to step right into a fight here. I love markdown and I know there is a lot of hard work behind it (and projects adjacent to it) over the years. I wouldn't care about this issue if I wasn't invested in the language and seeing it as the future of markup.

And, I understand that I'm probably a decade too late (or I don't know when the CommonMark project started). It seems pretty locked in. But this language might still be in use fifty years from now. I hope Markdown's future is longer than its past.

The W3C puts it like this in the HTML standard:

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

Emphasis is a subset of that.

But yeah, their description of b isn't a superset of strong emphasis on the other hand, although historically b has been used that way.

I tried to be careful when phrasing the original post in this issue thread. I wrote "Is there a way to get i" rather than "em is always wrong".
Seeing

<em>Hamlet</em> is a great play. It has a certain <em>je ne sais quoi</em> about it.

in source code is not correct. Seeing

"Wow, this <i>really</i> is a warm day!"

has legacy precedent and is not wrong per se, even though I'd rather use em there.

Markdown by its very nature as a plaintext-adjacent, "email tradition based" language does have its roots in presentation and legacy rather than structural semantics, which is why I feel that a way to easily make i or b is appropriate. Just as easily as I would write

_Hamlet_ is a great play, it has a certain *je ne sais quoi* about it.

in an email.

But it's for the sake of structural semantics that this matters. A web-scrapin' robot going through web pages and trying to scan for what is emphatic text might go "Wow, people back in the early 21st century really got stoked about their French phrases!"

Yes, i or b is sometimes a little blunt, sometimes a little non-specific, sometimes not optimal. But when I overuse em or strong that's sometimes flat out a falsehood, sometimes flat out what I don't mean.

I've seen some semantical horror stories over the years, like people using h1 for centering images (because that particular forum had h1 headers centered) or h6 when semantically they should've used h1 "because they think the smaller letters look cuter". There's no way to stop all such misuse, but we don't have to build it into the language, either.

[alerque]

You're talking to somebody who uses custom Pandoc filters to overload *...* and _..._ to render to different markup, *_..._* to render a third kind of highlighting that is not those two nested nor is it <strong>/<b>. I realize there is a use case for more precise semantics than Markdown provides for, I just don't think there is any way to codify them as "common". This project isn't about inventing new markup (if anything it's a downgrade from the Pandoc + extras flavor I use) but about standardizing the exactly usage of ambiguous bits.

The way you get <i> instead of <em> is by requesting it from your tooling. The spec and reference implementation default to one pair of tags. I believe the reason for that is that it's more flexible semantic markup with less direct locking to a specific presentation style, but you'd have to lookup the actual discussions to see if that was the deciding factor. Since Markdown has no way to differentiate between them it is outside the scope of CommonMark to specify when to use which. You can either use tooling that lets you pick or post-process the output.

[wooorm]

To go back to the first question:

Em and strong aren't always the right thing. Is there a way to get i or b?

I do think they often are the right thing, but indeed, they aren’t always. To get <i> or <b>, you can type those in literally, because both original Markdown and CommonMark have a “breakout” feature where it accepts HTML. As others have said, tools could allow options (I particularly like @Crissov’s idea: #652 (comment))

I do think it’s unfortunate that CommonMark does not say anything about semantics. And that its definition (“6.4 Emphasis and strong emphasis”) is not aligned with HTML (In HTML, nested emphasis is used for “strong” emphasis, whereas the strong element means importance, seriousness, or urgency).

[Crissov]

What the CM reference implementation should do, though, is to retain information in its AST about which character has been used in the source.

PS: https://talk.commonmark.org/t/em-strong-vs-i-b-or-cite-dfn-etc/1242 https://talk.commonmark.org/t/revisting-underline-healthcare-documents/3078/3

[vassudanagunta]

@snan I agree with most everything if not everything you said. I agree with the following in spirit

It seems pretty locked in. But this language might still be in use fifty years from now. I hope Markdown's future is longer than its past.

but I don't think Markdown will last even another ten unless it evolves*. It's still mostly used by technical types, myself included, who are comfortable writing for machines -- that is to say, quite used to and adept at thinking in terms of, What do I need to do to get the machine to do what I want?. Markdown was definitely a step in the right direction away from HTML for authoring. But we need to make more steps.

---

*I'm not sure it can. I think/hope something Markdown-like will replace it. A bit of a reboot is necessary.

[snan]

I do think they often are the right thing, but indeed, they aren’t always. To get <i> or <b>, you can type those in literally, because both original Markdown and CommonMark have a “breakout” feature where it accepts HTML.

I was under the (mistaken?) impression that that was for HTML output only; i.o.w. it's more of a "passthrough" feature than a "breakout" feature. In pandoc 2.5, which I have at hand, when compiling the text to LaTeX, it just drops those <i> tags.

somebody who uses custom Pandoc filters

♥

I do that too, on my own system, (lua ftw) but the reason I just found out about CM is that Stack Exchange announced that they are going to adopt it and I was like "OK, so it's no longer Gruber that I have to go bug about this".

[snan]

I think/hope something Markdown-like will replace it. A bit of a reboot is necessary.

I'm seeing a lot of sites switching over to wysiwyg or wysiwym but I'm not wholly on board with that. I love markup languages.

[snan]

In HTML, nested emphasis is used for “strong” emphasis, whereas the strong element means importance, seriousness, or urgency

Wow, so it is a subset of b after all!

[wooorm]

I was under the […] impression that that was for HTML output only […] In pandoc 2.5, which I have at hand, when compiling the text to LaTeX, it just drops those <i> tags.

That impression is correct: though when going to LaTeX, it doesn’t really matter whether <strong>, <b> or something else is used, no? These semantics matter when going to HTML, in which case, HTML tags are fine?

Wow, so it is a subset of b after all!

The HTML spec also says on <b>:

The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede. […] The b element should be used as a last resort when no other element is more appropriate.

I don’t think I agree that it’s good to see <strong> as “inheriting” from / subset of <b>. The last quoted sentence especially makes it sound to me as if defaulting to <b> is a worse approach.

[snan]

That impression is correct: though when going to LaTeX, it doesn’t really matter whether <strong>, <b> or something else is used, no? These semantics matter when going to HTML, in which case, HTML tags are fine?

It just drops the tags. So if you want to publish to both TeX and HTML you're sol if you use <i> tags.

The b element should be used as a last resort when no other element is more appropriate.

This language to me also implies fallback, catchall, default. When you can be more specific, you should. With a visual/presentation based markup like the email-derived **asterisks** you can't be that specific, and you can't easily select an appropriate element. Not that the W3 spec's specific wording is the be-all-end-all of my argument here, that'd be taking "appeal to authority" a bit far. History, legacy, intent and spirit of the HTML language is also relevant.

[snan]

As alluded to upthread, we know that through the life-changing magic of CSS, em and strong aren't strict subsets of i and b respectively. You can style it to use underlining or small caps to emphasize. So I don't mean a strict subset, I mean… kinda a subset. It's correct to say that one is semantics and the other is presentation.

It's just that

1. the semantic elements cover fewer use cases. And very many of those use cases are a subset of the much larger set of use cases that the presentation-based elements cover.
2. markdown's historical precendent "plaintext email formatting" is a presentation-based language.

I'm not disputing that we want semantics. I just don't want wrong semantics.♥