3

Code formatting is sometimes used for emphasis, or as a form of highlighting certain words or pieces of text. Is this acceptable?

Note: I’m not talking about when code formatting is used on code, only when it’s used on stuff that isn’t code

0

5 Answers 5

8

Code markdown should only be used for code or other text that will not be rendered properly otherwise. There are other formatting tools that should be used for emphasis as suggested by that question. There is a highly downvoted answer on that question saying it is okay which suggests that using markdown for emphasis is not okay.

accepted answer on meta

Correct, they should be used for code (and code-like artifacts).
If that's the only change, and it's wrongly applied, reject as "no improvement whatsoever" or "causes harm".
I don't have a problem with filenames, paths, API methods, commands, etc.–those are computery "artifacts" that should be differentiated from expository text. Products, trademarks, etc. aren't.
When emphasis or clarification is needed for non-artifacts we have italics and bold.

answer on meta

[Using backticks is] not just distracting, it's semantically wrong. Code formatting is semantic HTML to indicate to a parser that text is code. If we start lying to our parsers, we break tools built on HTML. Consider screen readers: if a visually impaired user configures their software to spell out code tags, or to have an easy keyboard shortcut with a macro called "jump to next code span/block and highlight" for easy copy-pasting, we are significantly disabling their ability to interact with the page. Further disabling, I should say.

another answer on meta

Apart from using inline code spans for highlighting actual code, you could use them to avoid text [that] is parsed differently, e.g. to avoid that <body> is parsed as HTML, and rendered as . (It is not actually rendered because it is stripped out.) That is also true for text that in Markdown would be rendered in a particular way, such as *example* that without inline code spans would be rendered as example.
In the other cases, inline code spans should not be used to highlight plain words; for that there is already bold, and italic styles, which can be easily obtained using Markdown.

6

I believe that code formatting for text that isn’t code should not be allowed.

I believe this because it makes it more difficult for screen readers to understand posts, and there is little to gain.

I believe that it makes it more difficult for screen readers to understand posts because of

  1. Discussion on Arqade meta
  2. Answer on main meta

[Using backticks is] not just distracting, it's semantically wrong. Code formatting is semantic HTML to indicate to a parser that text is code. If we start lying to our parsers, we break tools built on HTML. Consider screen readers: if a visually impaired user configures their software to spell out code tags, or to have an easy keyboard shortcut with a macro called "jump to next code span/block and highlight" for easy copy-pasting, we are significantly disabling their ability to interact with the page. Further disabling, I should say.

I believe that there is little to gain by using code formatting because stack exchange already has bold and italics.

2
  • Some data tables will not render properly unless a fixed-width font is used. Such tables do not meet the requirements for table markdown. Formatting as code solves the problem. The alternative is to create the table off-line as an image to be posted.
    – Rick Smith
    Oct 18, 2021 at 12:41
  • @RickSmith could you please post an answer with some examples? Oct 18, 2021 at 14:30
1

Regrading tables formatted with fixed-width-font. There is a table environment in SE's markdown nowadays. It was enabled late last year (2020).

I think the rule should be: migrate post to the new environment, if you can and feel inclined, as long as that doesn't ruin the table layout for those not visually impaired. From that announcement post, a limitation is that:

You can't merge cells or rows.

-1

Code format should not be used for things that aren't code.

While the accessibility arguments presented above hold true, there is a further point that applies to the entire SE userbase: code format replaces the proportional font with a monospaced font. This:

  • visually looks bad
  • can cause our brains to stumble and misread
  • gives a more excessive break than would be necessary.

Plenty of tools exist to highlight or emphasise words within text. Typographic conventions have largely evolved around the use of italics or slanted typefaces for a minor emphasis and bolded typefaces for major emphasis. These come with a number of advantages:

  • they are designed to fit in better with the surrounding text, causing an overall smoother appearance
  • the letter shapes are more similar to the surrounding text, preventing possible misreadings due to the switch between monospace and proportional
  • the style difference is sufficient for emphasis and even allows tuning across three different levels (although bolding and especially bold italics should be used sparingly).

Conversely, when using code formatting for code, what has been labelled as disadvantages above suddenly turns into advantages. Most people are most used to seeing code written in monospace fonts due to the use of code editors. Things like the number of spaces can be important and monospace allows that to be easily identified. Simple hypen-minus can be lost or overlooked in proportional text because it is supposed to be small but occupies the same size as any other character. Distinctions between I, l and 1 are emphasised as they cannot necessarily be inferred from context.

All of these are cases where our expectations towards code and text differ significantly which is due to the general use of monospace for code and proportional for text; switching them makes things harder, not easier; alternating between both in one setting is introducing hurdles for no reason and altogether just bad form.

-3

In response to the statement at https://politics.meta.stackexchange.com/a/6035/26455, "I believe that code formatting for text that isn’t code should not be allowed." and my comment:

Some data tables will not render properly unless a fixed-width font is used. Such tables do not meet the requirements for table markdown. Formatting as code solves the problem. The alternative is to create the table off-line as an image to be posted.

In my answer at https://politics.stackexchange.com/a/60679/26455, the word "Introduced" cannot be merged across two columns. The note at the bottom cannot be spread across all columns and "hanging indents" are not permitted.

Using tables doubles the effective number of lines presented to no additional value.

In the answer at https://politics.stackexchange.com/a/67846/26455, the table would expand to several pages.

In the answer at https://politics.stackexchange.com/a/66251/26455, the table would also expand though not nearly as much as the previous example.

Using a "Blockquote" rather than "Preformatted text" (aka, "code") would cause a loss of indentation in the answer at https://politics.stackexchange.com/a/62157/26455.

Note that the { } above the edit window is "Preformatted text", which includes both text and code.


Q: Should code markdown be used for emphasis?

Yes, that is part of why it exists. As a COBOL programmer who answers questions on SO, I have occasion to write English-like sentences that read like text, but have certain reserved words and values emphasized by code markdown. These emphasized terms are, in effect, text.

The question is not whether it should be used, but rather when is it misused. That can only be determined on a case-by-case basis. There are not, nor can there be, any hard or set rules.


As to the background for why this question arose, in Do we need [voters] and [electorate] as separate tags?, I edited my post to strikeout some numbers. After editing, the particular elements were as follows:

  • 7 17 questions

  • 1 6 question

  • Both tags 1 question

  • List of all 8 22 questions

I have a 27-inch HD monitor, use browser tab "zoom" at 110%, and wear glasses. I could not tell whether the "6" in the second item was struckout or not. Given the difficulty I was experiencing, I decided to use code formatting on the struckout numbers -- not for emphasis, but as visual clues that the numbers with the gray background were all struckout. Had emphasis of the strikeouts been intended, I would have emphasized the third line as well.

Following is the result:

  • 7 17 questions

  • 1 6 question

  • Both tags 1 question

  • [List of all 8 22 questions][1]

Having seen that the post had been edited to remove the use of code formatting, I found the message, "Please don’t use code formatting for stuff that isn’t code".

The edit changed the author's intent (removed visual clues) and made no improvement (the 6 no longer appeared as struckout), so I did a rollback. After that the comments ensued.

Having time to consider the issues, I made appropriate changes to the post. Though I feel, the issue, having been completed, should have gone off into obscurity -- the only interesting parts remaining being the answer and its comments.

2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .