Bullet points do not wrap when long link is in bullet point

[szimmer]

Bug description

Bullet points with very long links do not wrap and impact wrapping behavior of subsequent bullets. This is different behavior than rmarkdown.

Steps to reproduce

quarto example

---
title: "Untitled"
format: revealjs
---

## Bullets

- here's a long bullet documentation sas com/doc/en/pgmsascdc/9 4_3 5/statug/statug_introsamp_toc htm and more after it
- here's some more stuff blah blah blah blah blah blah and it goes on and on and on and on and on and on

## Bullets with long links - this is the issue

- here's a long link <https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_introsamp_toc.htm> and more after it
- here's some more stuff blah blah blah blah blah blah and it goes on and on and on and on and on and on

rmd example

---
title: "Untitled"
date: "2025-01-20"
output: ioslides_presentation
---


## Bullets

- here's a long bullet documentation sas com/doc/en/pgmsascdc/9 4_3 5/statug/statug_introsamp_toc htm and more after it
- here's some more stuff blah blah blah blah blah blah and it goes on and on and on and on and on and on

## Bullets with long links - this is the issue

- here's a long link <https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_introsamp_toc.htm> and more after it
- here's some more stuff blah blah blah blah blah blah and it goes on and on and on and on and on and on

Expected behavior

Bullets with long links only have long link go off page and then subsequent text goes to a next line. Subsequent bullet points also wrap expected.

Actual behavior

Bullet points do not wrap and go off the page

Your environment

• RStudio 2024.12.0+467 "Kousa Dogwood" Release (cf37a3e5488c937207f992226d255be71f5e3f41, 2024-12-11) for windows
  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) RStudio/2024.12.0+467 Chrome/126.0.6478.234 Electron/31.7.6 Safari/537.36, Quarto 1.6.40
• Windows 11 x64 (build 26100)

Quarto check output

C:\Users\...>quarto check
Quarto 1.6.40
[>] Checking environment information...
      Quarto cache location: C:\Users\...\AppData\Local\quarto
[>] Checking versions of quarto binary dependencies...
      Pandoc version 3.4.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.46.3: OK
      Typst version 0.11.0: OK
[>] Checking versions of quarto dependencies......OK
[>] Checking Quarto installation......OK
      Version: 1.6.40
      Path: C:\Users\...\AppData\Local\Programs\Quarto\bin
      CodePage: 1252

[>] Checking tools....................OK
      TinyTeX: (external install)
      Chromium: (not installed)

[>] Checking LaTeX....................OK
      Using: TinyTex
      Path: C:\Users\...\AppData\Roaming\TinyTeX\bin\windows\
      Version: 2024

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

[>] Checking Python 3 installation....OK
      Version: 3.12.1
      Path: C:/Users/.../AppData/Local/Programs/Python/Python312/python.exe
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with py -m pip install jupyter

[>] Checking R installation...........OK
      Version: 4.4.2
      Path: C:/PROGRA~1/R/R-44~1.2
      LibPaths:
        - C:/Users/.../AppData/Local/R/win-library/4.4
        - C:/Program Files/R/R-4.4.2/library
      knitr: 1.46
      rmarkdown: 2.28

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

[cderv]

Wrapping happens based on space by default, there is no specfic rule for <li> elements that overflow.
And the very long url has no space, which will push the width of all <li> elements. As long as there is a space somewhere in the line, there will be a wrapping. It will be like described, when no space at all (even if not a link e.g

## Bullets with long line without space

- here's a long link https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_introsamp_toc.htm and more after it
- here's some more stuff blah blah blah blah blah blah and it goes on and on and on and on and on and on

html produced for the slide is the following

<section id="bullets-with-long-links---this-is-the-issue" class="slide level2">
<h2>Bullets with long links - this is the issue</h2>
<ul>
<li>here’s a long link <a href="https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_introsamp_toc.htm" class="uri">https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_introsamp_toc.htm</a> and more after it</li>
<li>here’s some more stuff blah blah blah blah blah blah and it goes on and on and on and on and on and on</li>
</ul>

</section>

With Pandoc itself this is the results

So we see the wrapping problem too. This is CSS issue

setting

.reveal .slide ul li, .reveal .slide ol li {
    overflow-wrap: anywhere;
}

will solve it. This rules could be applied globally, or specifically by adding an id to the slide header and targetting only this slide .reveal .slide#id ul li.

I wonder if this is could be safely added by default 🤔 Reveal.js itself does not have this rules, and will probably have the problem. So maybe such fix should go there...

Note that using a linked text instead of the very long link ([`statug_introsamp`](https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/statug/statug_introsamp_toc.htm) ) will also help.

I am hesitant of making this change which will affect every presentation as overflow-wrap: anywhere can break word anywhere when needed, while

1. Reveal.js does not do it upstream.
2. It is easy to tweak CSS directly if this case happens
3. Very long "word" without any space is not very common IMO.
4. overflow-wrap: anywhere can break word anywhere as we see in the url, and maybe it is too strong to make it a default.

[cscheid]

I agree that this isn't a bug or something we should change, until we understand the consequences very well and decide that the change is worth it.