escape-svg fails for unquoted URLs

[jrdutton]

When using the SCSS version of Bootstrap, I am experiencing problems when providing an unquoted URL for the $breadcrumb-divider variable.

This is because the escape-svg function expects the URL to be quoted. Therefore, it removes the first five url(' and last two characters '). However, in the case of an unquoted URL, this fails. My understanding is the unquoted URLs are valid SCSS for the url function.

File poc.scss.txt shows the escape-svg function and other helper functions taken from the Bootstrap SCSS.
It also includes two other variations, my attempts at fixing the issue.
poc.scss.txt

File poc.css shows the output when compiled.
poc.css.txt
.breadcrumb-item shows the CSS using the existing function. In the case of url(data, the data part is truncated to ata
.breadcrumb-item2 and breadcrumb-item3 show the outputs with the adjusted function.

I am happy to create a pull request if agreed that this is an issue to be fixed.

[XhmikosR]

/CC @twbs/css-review (also please add v4/v5 labels where this applies)

[ffoodd]

So, I'm able to reproduce this on both v5 and v4.

Please have a look at a dedicated SassMeister. I took @jrdutton examples and added one of our own SVGs.

FWIW, this function expects quoted URL since SVG as data URi won't work without quotes (simply remove the one in $breadcrumb-divider4 to see what happens). Your case is somehow invalid since you're using base64—which Bootstrap doesn't.

@jrdutton in fact, if you're using base64 encoded SVGs you don't need to use escape-svg() function at all since it's meant to URL-encode datas. Please have a look at Taylor Hunt's excellent post "Optimizing SVGs in data URIs".

That being said, using the second suggestion —replacing str-slice($string, 6, -3) with str-slice($string, 5, -2)—shouldn't harm, except for people using unquoted URL-encoded SVG data URis.

Two things to consider then:

1. using this (small) improvement to allow unquoted base64 usage in customization
2. improving our docs to make things obvious, whatever we decide with 1.

@mdo @MartijnCuppens any thought?

[jrdutton]

Thank you @ffoodd for looking at this. I will take a look at the articles you suggest.

[mdo]

Opened #31653 to leave a comment in the source code. Don't think we need too much more here for now so we don't risk breaking behaviors for others.