Default styling discussion

[Adam Pritchard]

The default Markdown Here styling isn't great. And it's not just me who thinks this: see Casey Watts's otherwise pretty positive blog post.

The styling is largely lifted from Github's CSS. This makes some sense given that I was inspired by how good they make READMEs look, but an email isn't a web page, and not all styles that make sense for the one that may make sense for the other. In addition, I'm not a web designer or developer, so I'm not a CSS pro-star. I could certainly use some feedback and help.

First of all, here's the current default CSS: https://github.com/adam-p/markdown-here/blob/master/src/common/default.css

Secondly, I'll reiterate the comment that's at the top of that file: The use of browser-specific styles (-moz-, -webkit-) should be avoided. If used, they may not render correctly for people reading the email in a different browser than the one from which the email was sent.

Thirdly, and perhaps controversially (I'm still a little undecided myself), I think that a guiding principle should be make the styling look more like the default email styling. This will probably involve ripping some styles out, since we probably don't want to try to replicate the default styles for half a dozen different email clients. I think a lot of my items will be towards this end.

Finally, I'll start enumerating the issues as I see them. This won't be nearly complete, and I'll add more as I think of them.

1. Links should have underlines. I'm going to make this change in the development branch momentarily. You can see how it looks at this time from any of the links in this post (I'm going to render this email with Markdown Here). To make the no-underlines thing worse, there's currently no underline-on-hover, which is what Github does.

2. Casey Watts says:

   My first tweak: I’m not happy with the <li> padding/margin, so I made it much smaller.

3. Paragraph spacing should be tightened up. A rule-of-thumb goal: rendering a simple line of text should result in no perceptible change in the text.

   • I'm conflicted about this. Even without the current explicit paragraph margin, the "user agent stylesheet" still gives <p> some top margin. So... we're not really deviating from how paragraphs look, but paragraph elements just aren't used in email.
     • Sub-sub-conflict: I can't help wondering if we shouldn't render Markdown in a non-standard way -- using two <br> instead of <p>, to better emulate default email. Ugh.

I invite any comments, criticisms, suggestions, CSS, or items for the list.

Adam

[Adam Pritchard]

I just pushed a whole bunch of styling changes to the development branch. You can see them here: 177abfa -- please take a look, as there are a lot of them. I'll be testing those changes over the next few days, but some version of them will appear in the next release (possibly with others based on feedback).

I'm going to update the previous issue list, and some new ones, including ones derived from looking at Casey Watts's CSS. I'm going to put in some rendered example, which may or may not come through in the actual posted, er, post.

1. Links should have underlines: Done. Removed all styling. (So... they'll have underlines if they have underlines.)

2.

<li> padding/margin: I reduced it from 1em to 0.5em (and fixed the busted spacing around sub-lists). Casey has his reduced to 0.2em, which feels a little cramped to me. On the other hand, the default in Gmail is no margin or padding at all. So... Casey's right-er? We should fight to the death?

• 0.5em asdf adf asdf
• 0.5em adf adsf asdf
• 0.5em adsf asdf asdf

• 0.2em asdf asdf asdf
• 0.2em asdf adfs asdf
• 0.2em asdf asdf asdf

3.

I actually increased the <p> spacing (and for other block elements) from 1em to 1.2em. This was after measuring pixels between paragraphs in MDH-rendered text and default Gmail double-newline paragraphs. (In other words, I think: I changed the margin to be the default line-height.) It looks like Casey decreased his to 0.6em. Again, I'm willing to be swayed.

1.2em asdf asdf asdf

1.2em asdf asdf dfas

0.6em adf adfs asdf

0.6em adf adfs asdf

Those examples aren't very useful without fuller paragraphs, but I don't want to spam this post. Try it at home!

4. Blockquotes: They look kinda cool, but they also look quite different from the default. But they also look kinda cool. I'm torn. Does anyone have an opinion?

Ima Markdown Here blockquote

Ima default GGroup blockquote

5.

There's too much vertical space around definition lists (<dl>) and I'm not sure why. I'm loathe to set a negative margin, but that appears to be what's necessary. Does anyone have a better idea? (Gonna be honest: It's hard for me to care too much. I don't use them. It's tempting to just wash my hands of it and take the styles out.)

6.

Casey has given his lists more left padding (3em) than I have (2em). He wins vs. default Gmail, which uses 3em. I think that looks like a lot, but I could be convinced otherwise.

• 2em
• 2em

• 3em
• 3em

7.

Casey has given block elements (like <p>) a left and right margin: margin: .6em .6em instead of margin: 1em 0. I don't think I'm on board with this -- unless something is specifically indented (like lists), then I don't think we should mess with the horizontal margins.

Example: This has a 0.6em horizontal margin.

8.

Casey has decreased the vertical margin around ul, ol, dl. After learning about collapsing margins I see why this might be a good idea: it will allow separately rendered lists to appear as (be spaced as) a single list, rather than have the larger 1.2em space between them. On the other hand: a) ol will still get re-numbered, and b) if you're rendering separate, maybe you want them to be separate (it's quite difficult to break up two adjacent lists otherwise -- even three blank lines with generous double-spaces won't do it)? (The reason I mention collapsing margins is that it won't change the spacing between lists and adjacent paragraphs -- the margins aren't additive, and the larger will be applied.)

1. original
2. original

1. tighter
2. tighter

1. tighter
2. tighter

9.

Headers. Casey has made extensive header (h1, h2, etc.) changes: size reductions, coloring, crazy-sweet h1. I don't think the color changes should be default (and I bet he wouldn't suggest they should be). Maybe the size changes? I think the current headers do trend too large for email, and it actually forces me to work around them -- I end up using higher header number (i.e., having to type more hash marks, which is annoying). This is probably another case of "email is different from documents". I'll mess around with this in the next while. Input is welcome.

---

Again, any and all feedback is welcome.

Adam

[Adam Pritchard]

The only item above that I'm unequivocally in favour of is the reduction in header size. So I pushed a change to that effect.

Here's how they look now:

h1 {
  font-size: 1.6em;
}

h2 {
  font-size: 1.4em;
  border-bottom: 1px solid #CCC;
}

h3 {
  font-size: 1.3em;
}

h4 {
  font-size: 1.2em;
}

h5 {
  font-size: 1em;
}

h6 {
  font-size: 1em;
  color: #777;
}

I'm not sure I cut deeply enough -- maybe they should be smaller still. I think too small a change is better than too large.

Feedback welcome.

Adam