Markdown table rendering doesn't occur inside folding summary

[chipzoller]

Probably not using the right terms, but if you nest a Markdown table inside a folding/summary block, the table doesn't get rendered. Searched and didn't see an issue (open or closed) which references this. Also on an older version of Docsy so maybe this has already been addressed. Here's what this looks like when you compare a rendered table to a non-rendered table inside one of these folding/summary blocks:

Good

Bad

[LisaFC]

Can you paste in the source and hopefully I can see what's going on? Markdown + CSS has many weirdnesses, it may just need some more specific styling provided.

[chipzoller]

Hi there, @LisaFC . Sure. First table is just in a "clean" Markdown seaction:

| Value Type   | Input Type | JMESPath Type | Formatting |
|--------------|------------|---------------|------------|
| Number       | Integer    | Literal       | backticks  |
| Quantity     | String     | Raw           | quotes     |
| Duration     | String     | Raw           | quotes     |
| Labels (map) | Object     | Literal       | backticks  |

Second one is inside a folding block (I really don't know the correct terminology here):

### Add

<details><summary>Expand</summary>
<p>

The `add()` filter very simply adds two values and produces a sum. The official JMESPath library does not include most basic arithmetic operators such as add, subtract, multiply, and divide, the exception being `sum()` as documented [here](https://jmespath.org/specification.html#sum). While `sum()` is useful in that it accepts an array of integers as an input, `add()` is useful as a simplified filter when only two individual values need to be summed. Note that `add()` here is different from the `length()` [filter](https://jmespath.org/specification.html#length) which is used to obtain a _count_ of a certain number of items. Use `add()` instead when you have values of two fields you wish to add together.

`add()` is also value-aware (based on the formatting used for the inputs) and is capable of adding numbers, quantities, and durations without any form of unit conversion.

| Input 1            | Input 2            | Output   |
|--------------------|--------------------|----------|
| Number             | Number             | Number   |
| Quantity or Number | Quantity or Number | Quantity |
| Duration or Number | Duration or Number | Duration |
<br>

**Example:** This policy denies a Pod if any of its containers which specify memory requests and limits exceed 200Mi.

\```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-demo
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: add-demo
    match:
      any:
      - resources:
          kinds:
          - Pod
    preconditions:
      any:
      - key: "{{ request.operation }}"
        operator: In
        value: ["CREATE","UPDATE"]
    validate:
      message: "The total memory defined in requests and limits must not exceed 200Mi."
      foreach:
      - list: "request.object.spec.containers"
        deny:
          conditions:
            any:
            - key: "{{ add('{{ element.resources.requests.memory || `0` }}', '{{ element.resources.limits.memory || `0` }}') }}"
              operator: GreaterThan
              value: 200Mi
\```

</p>
</details>

*I added backslashes in front of the code block fencing around the ClusterPolicy to try and escape the outer code block GitHub is providing.

[chipzoller]

And here's the live site where you can see how this is rendering yourself: https://kyverno.io/docs/writing-policies/jmespath/

[LisaFC]

Right, as I suspected, it's a CSS thing - a table inside a division doesn't get the default table styling from our stylesheets applied to it. Let me see if I can tweak it so that it formats correctly - is there any situation where you wouldn't want a table inside another element to have our default styling?

[chipzoller]

is there any situation where you wouldn't want a table inside another element to have our default styling?

Not that I can think of.

[chipzoller]

Hey @LisaFC and Docsy team, just following up on this issue!

[geriom]

@chipzoller There's a PR with a fix for that issue (#1017), likely to be included in the next release.

[chipzoller]

Thank you very much!

[chalin]

@chipzoller @geriom @LisaFC - I believe that #1255 closes this issue. WDYT?

[chipzoller]

Yes, confirmed resolved. Thank you to everyone!