Inline output in R Markdown documents

[yihui]

This PR adds an inline argument to four output functions: textOutput(), imageOutput(), plotOutput(), and htmlOutput(), to make it possible to write output to <span> instead of <div>.

Here is a test document: https://yihui.shinyapps.io/shiny-inline/

---
title: "Inline Output"
runtime: shiny
output: html_document

---

You can embed Shiny inputs and outputs in your document. Outputs are
automatically updated whenever inputs change. This demonstrates how a standard R
plot can be made interactive by wrapping it in the Shiny `renderPlot()`
function. The `selectInput()` and `sliderInput()` functions create the input
widgets used to drive the plot.

```{r tidy=FALSE}
sidebarLayout(
  sidebarPanel(
    selectizeInput('main', 'Main title', LETTERS),
    sliderInput('size', 'Point size', min = 0.2, max = 5, value = 1)
  ),
  mainPanel(
    renderPlot(plot(cars, main = input$main, cex = input$size, pch = 19),
               width = 600, height = 400)
  )
)
sunsplots_line = function() {
  par(mar = rep(0, 4))
  plot(sunspots, axes=FALSE, ann=FALSE, asp=input$asp)
}
```

The main title is `r renderText(input$main)` and the point size is `r renderText(input$size)`.

Besides `renderText()`, you can also embed some other output elements inline.

For example, here is a spark line `r renderPlot({sunsplots_line()}, width=300, height=40)`
that shows you the time series `sunspots`.

```{r}
sliderInput('asp', 'Aspect ratio', .02, .3, .2)
```

[jcheng5]

This looks pretty good! Just a couple concerns:

1. The set of elements which are valid in a span is different than what's valid in a div. This shouldn't be an issue for text, image, or plot outputs, but it's potentially a problem for htmlOutput/uiOutput. We could have those generate a div that's inline though.
2. Do we want inline or inline-block, in general? The latter can have margins, padding, width/height, etc.
3. renderPlot works but it's a little strange that the generated span tag has width/height that's ignored. Maybe those should be auto/auto and (if possible) we can give a warning if renderPlot doesn't have explicit width/height?

[yihui]

1. The reason that I considered inline output for renderUI() is that renderText() is limited, and users may want to compose arbitrary HTML to write richer content inline, e.g. r renderUI(span(input$foo, style='color: red;')). On second thought, however, I do not think this is a convincing reason any more, since we can also easily compose HTML in Markdown, e.g. <span style='color: red;'>r renderText(input$foo)</span>. I can remove the inline support from this PR. My guess is that in most cases, users only need the inline support for renderText().
2. I believe inline is enough. When we write inline output, I guess we often want that output to mix well with the rest of content; inline-block seems a little uncommon to me.
3. Good point. I have updated the PR to ignore width/height when inline = TRUE. When width/height are not specified as numeric values, renderPlot() will not work inline, since the width/height returned by the browser will be 0. I mentioned in the documentation that these are required as numeric values when renderPlot() is used inline. I'm not sure if I should add a warning here: https://github.com/rstudio/shiny/blob/a5e09f9/R/shinywrappers.R#L117