← Back to context

Comment by combatentropy

6 years ago

I wish that markdown formatted bold and italics like this:

  _italic_

  *bold*

instead of:

  _italic_

  *italic*

  __bold__

  **bold**

because stars around a word make it look like it's glowing, sort of like bold does, and underlining a word means to make it italic. Does no one remember this?

In English class, before computers, our teacher told us that certain words are always underlined: book titles, ship names, etc.

In Typing class, our teacher told us that if you submitted a typewritten manuscript to a publisher, what you underlined with your typewriter would be converted to italics in a typeset book. Underlining meant italics. And sure enough, nowadays when everyone has a computer instead of a typewriter, and can make real italics, they tell us that book titles, ship names, etc., ought to be in italics (the same things that my teacher used to tell us should be underlined) https://www.purchase.edu/editorial-style-guide/general-style...

I get kind of why Gruber did it his way. He was caught up in the Semantic Web, where you don't use <i> and <b>, you use <em> and <strong>, and <strong> means <em> only more so. So by that logic

  *this*

is emphatic, and

  **this**

is strongly emphatic.

I'm enamored of the org-mode textual formatting convention: •bold︎•, /italic/, _underline_, =literal=, and ~strikethrough~. Although `literal` a la Markdown is arguably better, I prefer the other choices.

Especially because org-mode lets you italicize //Face/Off// by adding more slashes, and so on for the others, like ==e = mc^2==.

Incidentally, I have no idea how you're typing literal asterisks, I gave up and am kinda jealous.

  • /italic/ is also how it used to be done way back in the early BBS/MUD/MUSH days (along with _underline_)

    • Yes I think this makes much more sense to me since the / operators align with how the characters in italic looks once it is applied ( Slightly tilted )

      And underline.

      I dont understand why they aren't used that way any more.

  • I really dislike /italic/. Relative to the slashes, the letters look like they're skewed in the wrong direction. Surely it should be \italic\. If unifying underlines and italics doesn't suit you.

    • I grew up on Usenet so I'm used to it.

      Always thought the idea was that the first slash pushes the letters over, and the second one keeps them from falling down completely.

      The unification of underline and italic is an artifact of the limited technology of the typewriter, and I see no reason to preserve that.

Moreover, the convention that you advocate is more or less an established practice in Usenet and mailing lists, long preceding markdown. This design decision in markdown is uninformed.

Two minor notes:

1. "Semantic web" refers to data being linked and having meaning. You're referring to semantic HTML.

2. I don't think <strong> meant <em> but more so - as I understood it, <strong> meant text that had to stand out from the rest, whereas <em> meant that text was emphasised. Though I might be confusing it now with the retro-actively applied "semantics" of <b> and <i>.

Totally agree with the overall point btw, and I do tend to use them in the way you described.

It's actually surprisingly difficult to get this kind of thing right. It seems perfectly obvious in hindsight, but while you're designing, little details like this get missed.

When I started writing a spec for Concise Text Encoding [1], I figured it would take about 6 months to nail it down (yeah, right). Even now, 2 years later, I'm still making amendments to it because of various things I missed or got wrong. It's either something I happen to notice in one of my many, many re-reads, or something that another person notices after a few minutes reading it over, or something that comes up while I'm writing the reference implementation. Getting a spec right is a marathon affair.

[1] https://github.com/kstenerud/concise-encoding/blob/master/ct...

  • It seems to be an instance of Wadler's Law.

    > In any language design, the total time spent discussing > a feature in this list is proportional to two raised to > the power of its position. > 0. Semantics > 1. Syntax > 2. Lexical syntax > 3. Lexical syntax of comments

    https://wiki.haskell.org/Wadler's_Law

Agree in general, but don't like the underline/italic thing. Most word processors have underline as separate from underline. Hence the alternative old email/Usenet convention: underscores for underline, slashes for italic.

  • Professional typesetters have an aversion to underlining text. It's ugly. The line interferes with descending letters: f, g, j, p, q, y. The underline is as thick as the stroke of a character, so decorative marks compete with signal marks. It's just too strong. That's why you see text underlined in homemade flyers but almost never in books, magazines, newspapers, or other things designed by pros. The recent addition to CSS to specify that underlines go behind the descenders is a welcome change.

    Professional web designers have the same aversion that print designers have, they are birds of a feather. But now they have another reason to hate it. Underlining has come to mean hyperlink. Because of their original aversion, they will often use CSS to remove that default underline, maybe bringing it back only when you hover over a link. But because it is still a widespread convention throughout the web, and probably always will be, they would never, ever emphasize something by underlining (they use border-bottom ;).

    Since you should underline something only if it is a link, which has its own markdown, and since underlining is ugly anyway, and since bold and italics are enough ammunition for all your emphasizing needs, and since it is an established convention from the old days that underlining meant eventual italics when it went to press, it's okay in my book to repurpose _underscores_ for italics.

    Slashes instead on both sides like /this/ --- hmm, it's not bad. I'm undecided.

Because calling it italic and bold is WYSIWYG all over again something Markdown tried to cure.

The proper way to think about is s emphasis and strong emphasis. As user you shouldn't be concerned by how it looks. Thats job of overall design and that might change depending where you publish / who designed it. You shouldn't make that decision because you don't have the required context.

Italic will probably be the emphasis (although other designs are possible like change of color). Underline can be used for strong emphasis if it doesn't colide with links. Bold might be too jarring or not possible to use so designer might decide to not use it.

There are also other ways to emphesise like small caps or inline background colors.

  • As user you shouldn't be concerned by how it looks. Thats job of overall design and that might change depending where you publish / who designed it. You shouldn't make that decision because you don't have the required context.

    As the writer of Markdown content, you're often both the user of the content and the publisher of the content, so you do care about how it looks. Even if you're just the user, your intention when writing is to communicate something, and the eventual appearance of your content impacts how it is interpreted by the reader. So you still care about how your writing will look, which forces you to care about how the publishing process interprets the markdown syntax.

    • I am not saying you can't be both user and publisher. I am saying that these are two different processes often made by different people.

      When you publish book you have mostly zero power over how it will be designed. And honesty you should have zero power over it because there are people editors/designers/typesetters who dedicate their lives to exactly that. Better to let them handle it. Same goes for the web.

  • You have to choose one or the other, semantics or formatting. There's a standard way to format a book title: italics. You have to be able to say "format this with italics" or "this is a book title."

    A system that prefers semantic tags such as "emphasis" and bans direct formatting such as "italics" only works if you can import or define a semantic tag for "book title" that you know will be formatted correctly. It doesn't make sense to tag a book title with "emphasis," because there are a lot of different ways to express emphasis, and only one of them works (quite coincidentally) for a book title.

    • Yes but i think we would both agree that in html/markdown it should be "this is book title" because medium allows it. "format this with italics" makes as little sense as "format this with emphasis" they are both wrong. Interestingly "format this with italics" is right solution in print because we encode that meaning in aesthetics and conventions and i guess thats why people think it is also right solution in web. But even in typesetting program that book title will have class .book-title and same italic in footnotes will be .footnote.book-title

  • Everything you say is true. I started making web pages 20 years ago. When I got a real job doing it in the mid-2000s, it was at the height of the push for semantic markup. Over the years I've come to think it is overwrought.

    First, I think they could have repurposed the old tags. <i> can stand for "important," with a default style of italic, and <b> could mean "bold" in the sense of "strong" or "outstanding", https://www.etymonline.com/word/bold, with a default style of boldface type. You can still restyle them to your heart's content.

    Second, italic doesn't always mean emphatic. Like I said, it is also a formal convention for: titles (books, movies, magazines), ships, foreign words, legal cases, etc. (Only of large works. For articles and other small works, you quote them. So for example, The New York Times should be in italics, but any particular article, like "Chiefs Win Superbowl", should be in quotes.)

    Third, the tags are longer, especially <strong> instead of <b>. It's noisy. A quibble, you might say. But so is this whole topic. And there is a line where coding goes from fun to tedious.

    Fourth, an asterisk looks stronger than an underscore anyway:

      *this*
    

    calls out more than

      _this_
    

    So you could say underscores are emphasis and asterisks are stronger emphasis, even with just one on each side.

    • I am very aware of the formal conventions in print but thats not the problem here. Especially in html those cases should be marked differently (like with span.class) so that can be understood by machine or screenreader.

      There can any number things set in italic on page and none of them have to use <em>.

      "italic doesn't always mean emphatic" is exactly the reason why i say think of it as emphasis not as italic.

      Also emphasis/strong in html is mainly for general emphasis in paragraphs of text. It works pretty much like h1 and h2. The difference is that you have only two levels.

  • > As user you shouldn't be concerned by how it looks

    I'm a user and I care a lot about how my documents look.

    • Yes and often times how they look will be out of your hands. You publish in magazine and their editor+designer will change your underlines to italic and your italics to bold because thats how it makes sense in their publication.

      Of course you are both writer and publisher you are also in control of the design. But when you are writing you shouldn't be thinking about how to present the text. These are almost always different processes (except rarer things like poetry or experimental prose that rely on whitespace). Write > edit > present/design.