Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Gmail] Converting to markdown changes the font of normal text to San Serif #88

Open
amithgeorge opened this issue Jul 19, 2013 · 1 comment

Comments

@amithgeorge
Copy link

I have set in my Gmail settings to default the font to Verdana. I type my email. The font used is Verdana. I convert to markdown and the font changes to sanserif. I toggle back to original text. The font is Verdana again.

Ideally the font shouldnt change when converting non code sections. I was able to fix the issue for myself by modifying the Primary CSS styling as such

/* This is the overall wrapper, it should be treated as the `body` section. */
.markdown-here-wrapper {
   font-family:verdana,sans-serif; // <--- this is the line I added
}

That said, if I were to change to the font to something else later on, I will need to come back to this file/option to fix it.

@adam-p
Copy link
Owner

adam-p commented Jul 23, 2013

Nice one. I assumed that by not setting an explicit font in the Markdown Here CSS that the default font would be used, but this doesn't seem to case when the user has overridden Gmail's font. The user who created issue #68 probably had the same situation.

Here's what an empty email looks like when using the default font:

<div id=":kh" class="Am Al editable LW-avf" hidefocus="true" aria-label="Compose reply" g_editable="true" role="textbox" contenteditable="true" tabindex="1" style="direction: ltr; min-height: 239px;">
  <br>
</div>

And here's what it looks like with a custom font set in the Gmail settings:

<div id=":42" class="Am Al editable LW-avf" hidefocus="true" aria-label="Compose reply" g_editable="true" role="textbox" contenteditable="true" tabindex="1" style="direction: ltr; min-height: 239px;">
  <div class="gmail_default" style="font-family:georgia,serif">
    <br>
  </div>
</div>

And... this is what happens to the custom font when MDH is rendered:

<div id=":i0" class="Am Al editable LW-avf" hidefocus="true" aria-label="Compose reply" g_editable="true" role="textbox" contenteditable="true" tabindex="1" style="direction: ltr; min-height: 175px;">
  <div class="markdown-here-wrapper" id="markdown-here-wrapper-355956" data-md-original="&lt;div class=&quot;gmail_default&quot; style=&quot;font-family:georgia,serif&quot;&gt;My MD message.&lt;/div&gt;" style="">
    <p style="margin: 1.2em 0px !important;">My MD message.</p>
  </div>
</div>

A few possible fixes come to mind:

  1. Special case the class="gmail_default" wrapper. Short-term easy, but: a) dirty, b) doesn't work for other mail clients, c) unpleasant to maintain (need to periodically check that Gmail hasn't changed the class name).
  2. Read and copy styles. This isn't a well-formed idea, but... Something like read the styles from any existing "wrapper" element and copy them to our own. The next idea is effectively a superset and probably better...
  3. Leave any pre-existing "wrapper" element intact. Basically, detect that there's a <div> around the content-to-render and put our wrapper inside of it.
    • Better than option 2 because it allows MDH styles to naturally override the pre-existing styles. With option 2, we could still override them, but it would be by changing the order they appear in the style attribute (kinda ugly).
    • Doesn't have the "dependent on the specific class name" problem of the first option.

Investigation on the other email clients/platforms needs to be done to see how they behave.

I'm not gonna lie, this isn't high priority. The workaround is pretty easy, and the change isn't super clean/easy and introduces some new bug potential. But we'll certainly leave it open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants