email should not receive footer

[aronatkins]

The Quarto email message should not contain any default context. When the user builds a custom email message, they should be given complete control of its content.

Using the Quarto document:

---
title: Something wonderful
format: email
email-preview: true
---

Some of the content in this document makes its way to the rendered HTML and
some of it is destined for a custom email message. The email message
customizes the subject and the body of the email, while the rendered HTML
contains only this paragraph.

::: {.email}

::: {.subject}
Buy groceries (quarto)
:::

Remember to pick up groceries on you way home. Tonight is "breakfast for
dinner" and we're having French Toast!

* Bread
* Eggs
* Butter
* Milk

:::

This produces an email message like the following (viewed using the gmail browser UI):

In contrast, a custom email from rmarkdown looks like the following:

Here is the R Markdown document for comparison:

---
title: Something wonderful
---

Some of the content in this document makes its way to the rendered HTML and
some of it is destined for a custom email message. The email message
customizes the subject and the body of the email, while the rendered HTML
contains only this paragraph.

```{r echo = FALSE}
rmarkdown::output_metadata$set(
  rsc_email_subject = "Buy groceries (plain rmarkdown)",
  rsc_email_body_html = paste0(c(
    "Remember to pick up groceries on you way home. Tonight is \"breakfast for
dinner\" and we're having French Toast!",
    "",
    "<ul>",
    "<li>Bread</li>",
    "<li>Eggs</li>",
    "<li>Butter</li>",
    "<li>Milk</li>",
    "</ul>",
    ""
  ), collapse = "\n"),
  rsc_email_suppress_report_attachment = TRUE)

[aronatkins]

Note: I tried to create an example R Markdown document using blastula, but ran into https://github.com/rstudio/blastula/issues/323

[rich-iannone]

We could definitely remove the inclusion of default content. In a separate issue, we can go over some design ideas for how a user would add content to the email header and footer.

[aronatkins]

Would it be best for me to include examples of how to reference the links in documentation? We don't have any convention for a "message footer" in the document metadata, so whatever is handled as a footer needs to be specified directly in the HTML (and text) email messages.

[rich-iannone]

Yes definitely, and I'm thinking about using a .header and .footer class to make these customizable (otherwise they will be empty). Other names which jive with our growing set might be .email-header and .email-footer (this aligns with the .email-text class).

Speaking of which, would an email-footer-default metadata option (defaulting to false) be useful in case people want the default content in the footer? In terms of behavior it could provide the default footer content only if true and if there isn't an .email-footer div.

[rich-iannone]

And to answer the question above, yes, I think having some documentation on how to generate the reference links would be useful. It'll probably obviate the need for an email-footer-default option too.

[aronatkins]

I've included an example of using environment variables in my documentation. I think that's probably sufficient for now.

Let's hold off on specialized header/footer divs and ask that folks add that information themselves. They'll need different formatting in the HTML vs text bodies, for example.

[aronatkins]

Blastula incorporates a box containing the email message and some footer information when the secondary email.Rmd contains:

---
output: blastula::blastula_email
---

Quarto email is mimicking this behavior. We will eventually incorporate a "plain" format which lets folks have more control over the email message, but for now, will continue to add this surrounding context.