Markdown tables use different style than code (kable) tables

[cbrnr]

Consider the following reprex (tested with quarto 0.9.424):

---
title: "Table vs. kable"
engine: knitr
---

A Markdown table is *not* striped:

|  a|  b|  c|
|--:|--:|--:|
|  1|  6| 11|
|  2|  7| 12|
|  3|  8| 13|
|  4|  9| 14|
|  5| 10| 15|

But a table generated with `knitr::kable()` is striped (besides other minor differences):

```{r}
data.frame(a=1:5, b=6:10, c=11:15) |> knitr::kable()
```

Although the output of the code cell is exactly equal to the Markdown table in the example (the first table), the output look different, most notably only the kable is striped:

I would have expected that the tables use the same style by default. If this is not desired, is there a way I can make them the same?

[jjallaire]

It's on our short list to make this configurable, but right now tables from data frames are striped (and more compact) and tables within content are not.

[mcanouil]

To note, this can easily be solved:

---
title: "Table vs. kable"
engine: knitr
---

A Markdown table is *not* striped:

|  a|  b|  c|
|--:|--:|--:|
|  1|  6| 11|
|  2|  7| 12|
|  3|  8| 13|
|  4|  9| 14|
|  5| 10| 15|

But a table generated with `knitr::kable()` is striped (besides other minor differences):

```{r}
#| output: asis
data.frame(a=1:5, b=6:10, c=11:15) |> knitr::kable()
```

Also, Quarto table processing can be disable, see https://quarto.org/docs/authoring/tables.html#disabling-quarto-table-processing.

[cderv]

I am surprised by this trick of using output: asis on the kable() results to modify the default behavior that we apply on computation tables.

Striped tabled is indeed a default we set for computational table

quarto-cli/src/format/html/format-html-bootstrap.ts

Lines 390 to 398 in ecf2a08

	// default treatment for computational tables
	const addTableClasses = (table: Element, computational = false) => {
	table.classList.add("table");
	if (computational) {
	table.classList.add("table-sm");
	table.classList.add("table-striped");
	table.classList.add("small");
	}
	};

which is different than our default for non computational table.

but right now tables from data frames are striped (and more compact) and tables within content are not.

@jjallaire what is the reason to make the two style different ? (0a352d6 and 4230513)

most notably only the kable is striped

With new feature in 1.3 (https://quarto.org/docs/prerelease/1.3/tables.html), one can now apply striped to Markdown table easily

(BTW @jjallaire is this the configurable you were mentioning ? or do we plan for more ?)

This example would be the other counterpart to make the Markdown table use the same style as the computational table

---
title: "Table vs. kable"
engine: knitr
---

A Markdown table can be striped:

|  a|  b|  c|
|--:|--:|--:|
|  1|  6| 11|
|  2|  7| 12|
|  3|  8| 13|
|  4|  9| 14|
|  5| 10| 15|

: {.striped .sm .small}

But a table generated with `knitr::kable()` is striped (besides other minor differences):

```{r}
data.frame(a=1:5, b=6:10, c=11:15) |> knitr::kable()
```

Also, Quarto table processing can be disable, see quarto.org/docs/authoring/tables.html#disabling-quarto-table-processing.

@mcanouil Not sure kable processing happens here for knitr output. Are you suggesting to apply that for the Markdown table ?

[mcanouil]

Indeed it does not in this case, Quarto processing would mostly matters when using format = "html" and in combination of kableExtra.
The trick (because it's really is a trick) with output: asis allow to avoid Quarto processing when the markdown table is inside a "cell" div.

[jjallaire]

The reason they are different is that data looks dramatically better w/ condensed/striped presentation, whereas content often looks worse (they are really two different use cases of table). The solution should be allowing uses to override the default (which I believe we were slated to do in v1.3, not sure if we exposed every required knob).

[cderv]

that data looks dramatically better w/ condensed/striped presentation, whereas content often looks worse (they are really two different use cases of table).

Oh I see. Did not think of that. Thanks for the precision.

[mcanouil]

Since it is by design, do we keep this open?

[jjallaire]

We should close it (and then make sure there is a way for users to override the default behavior that is clearly documented)

[cderv]

Let's close this and follow work for opting out in #6945