Thanks for the report. You're running a slightly older version of quarto:

Version: 1.2.269

Can you install the latest version and confirm that the problem persists?

Unfortunately, I can't quickly install the latest version on the device used for reporting above; it's a corporate device. But I have a recent version of Quarto (1.3.340) on another device and can reproduce the problem there. (Separately, likely because I'm a Linux newb, I couldn't uninstall old/install new version of Quarto with dpkg or gdebi)

Environments

Environment 1:

• IDE: VSCode
• OS: Pop!_OS 22.04 LTS

Environment 2:

• IDE: RStudio 2023.03.0+386 "Cherry Blossom" Release (3c53477afb13ab959aeb5b34df1f10c237b256c3, 2023-03-09) for Ubuntu Jammy
  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) rstudio/2023.03.0+386 Chrome/108.0.5359.179 Electron/22.0.3 Safari/537.36
• OS: Pop!_OS 22.04 LTS

Quarto check

[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.1: OK
      Dart Sass version 1.55.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.3.340
      Path: /home/arthur/opt/quarto-1.3.340/bin

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.10.6
      Path: /usr/bin/python3
      Jupyter: 5.3.0
      Kernels: python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.3.1
      Path: /usr/lib/R
      LibPaths:
        - /home/arthur/R/x86_64-pc-linux-gnu-library/4.3
        - /usr/local/lib/R/site-library
        - /usr/lib/R/site-library
        - /usr/lib/R/library
      knitr: 1.43
      rmarkdown: 2.23

[✓] Checking Knitr engine render......OK

Result

From the example, I am not entirely sure what's not working exactly.
Could you update your example to make it clearer what works or not as you'd expect?

Sorry for the long and confusing initial post.

When local videos are included in a multi-column layout, they seem to grow to fill their column container. If one writes something like the code below...

# My slide

:::: {.columns}

::: {.column width="70%"}

![](path/to/my_video.mp4)

:::

::: {.column width="30%"}
Video grows to fill its container, subject to size of container and intrinsic dimensions of the video..
:::

::::

...then the video basically grows to fill its column container. Here's an example:

If useful, here's the slide, and here the source code.

I expect that videos sourced from, say, YouTube and included via the video shortcode should be displayed in the same way (i.e., automagically grow to fill its container).

Unfortunately, videos sourced with the video shortcode appear to display differently. While they grow to fill the width of their container, they don't grow to fill their height. When one provides height and width as percentages, they still don't grow to fill their container (according to those percentages).

# `video` in column

## Without dimensions

:::: {.columns}

::: {.column width="70%"}

{{< video https://www.youtube.com/embed/yvi5uXQMvu4 >}}

:::

::: {.column width="30%"}

Without dimensions specified, the video appears quite small--perhaps the size of its YouTube thumbnail (?)

:::

::::

## With dimensions = 100%

:::: {.columns}

::: {.column width="70%"}

{{< video https://www.youtube.com/embed/yvi5uXQMvu4 width="100%" height="100%" >}}

:::

::: {.column width="30%"}

When instructed to occupy 100% of the width and heigth of its container, the video only obeys on the width dimension. The height is too short.

:::

::::

## With dimensions < 100%

:::: {.columns}

::: {.column width="70%"}

{{< video https://www.youtube.com/embed/yvi5uXQMvu4 width="100%" height="85%" >}}

:::

::: {.column width="30%"}

Similar problem as above

:::

::::

It's only when one provides pixel dimensions manually that the video can be coerced to fill its container in the same way that a local image does automatically.

## Shortcode, dimensions in px

:::: {.columns}

::: {.column width="70%"}
{{< video https://www.youtube.com/embed/yvi5uXQMvu4 width="760" height="515" >}}
:::

::: {.column width="30%"}
The video finally grows to desired dimensions. Unfortunately, this requires the user to specify dimensions in pixels.
:::

::::

It's only when one provides pixel dimensions manually that the video can be coerced to fill its container in the same way that a >local image does automatically.

Thanks for this - This is exactly the workaround I was looking for until it's fixed in some future version.

This bug is still present in 1.7.29. The basic example code on the quarto video documentation. Similar issues occur with local files. I'm using the workaround to specify it in pixels.

Absent any width/height settings, video overflows the bottom of the slide.

{{< video https://youtu.be/wo9vZccmqwc width="100%" height="100%" >}}

creates a wide short video:

@astrowonk As you can see, the issue is still opened, thus not fixed.
Note that by posting, you trigger notifications to all participants.

Please also properly format your message using proper markdown syntax, for instance use backticks for inline code or code block (there are buttons in the GitHub UI to help with that).
And adding alternative text is advised when sharing screenshots.

@astrowonk As you can see, the issue is still opened, thus not fixed.
Note that by posting, you trigger notifications to all participants.

Please also properly format your message using proper markdown syntax, for instance use backticks for inline code or code block (there are buttons in the GitHub UI to help with that).
And adding alternative text is advised when sharing screenshots.

Note that by replying to my reply, you also trigger notifications for all participants. Notifications can be altered in github settings if you do not wish to receive emails, etc.

The point is that the issue is not fixed & the example in the documentation does not work. Nitpicking comments or issues does not encourage participation.

You are completely missing the point.

• maintainers read all issues and discussions (you cannot ask them to unsubscribe)
• maintainers do update issues when there is something to update about
• opened issues mean the bugs are not fixed or enhancements not implemented

There are almost 1,500 opened issues. Commenting that those are not fixed does not help fix them. It cost you time to write the comments and cost time to maintainers to read/triage them.

GitHub has a reaction feature which allows users to add reactions to an issue such as thumb up. This is more useful to maintainers because issues can be sorted by the number of reactions thus maintainers can use that as a proxy of the interest on the bug fix or enhancement to eventually prioritise.

@astrowonk We do prefer that you upvote instead of commenting. It really is a matter of improving signal-to-noise for us. We appreciate the understanding.