Sass, different results using compressor and without, causing parsing errors

[wjdp]

Hello, I'm running into an issue while using Bootstrap 4 alpha 6. Encountered that all CSS after the include of BS4 was ignored by the browser. Dug deeper and found parsing error of the generated css.

I'm using Django 1.8.17, Compressor 2.1.1, Sass 3.4.22

I shall document here the first parse error I found.

The error is the double quote " in stroke='rgba(0, 0, 0, 0.5")', whereas it should be stroke='rgba(0, 0, 0, 0.5)'. This causes parsing errors in the document.

Invalid Line (via dj compressor)

.navbar-light .navbar-toggler-icon {
  background-image: url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 32 32' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(0, 0, 0, 0.5")' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 8h24M4 16h24M4 24h24'/%3E%3C/svg%3E"); }

Valid line (via sass direct)

.navbar-light .navbar-toggler-icon {
  background-image: url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 32 32' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(0, 0, 0, 0.5)' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 8h24M4 16h24M4 24h24'/%3E%3C/svg%3E"); }

Matches with pre-compiled version.

Souce of background-image

$navbar-light-toggler-bg: str-replace(url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 32 32' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='#{$navbar-light-color}' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 8h24M4 16h24M4 24h24'/%3E%3C/svg%3E"), "#", "%23") !default;

$navbar-light-color:                rgba($black,.5) !default;

$black:  #000 !default;

How we generate via dj compressor

{% compress css %}
<link rel="stylesheet" type="text/x-scss" media="screen" charset="utf-8"
    href="/static/bootstrap/scss/bootstrap.scss" />
{% endcompress %}

COMPRESS_PRECOMPILERS = (
    ('text/coffeescript', 'coffee --compile --stdio'),
    ('text/x-sass', 'sass {{infile}} {{outfile}} --load-path {}'.format(LIB_PATH)),
    ('text/x-scss', 'sass --scss {{infile}} {{outfile}} --load-path {}'.format(LIB_PATH)),
)

[karyon]

looks pretty bad. any help fixing this would be appreciated, i'll likely not have the time for the coming weeks.

[wjdp]

I'll have a go. I'm not familiar with your codebase so any pointers on where to start / any hunches would be very valuable.

[carltongibson]

A couple of thoughts:

• Does this occur with COMPRESS_ENABLED = False?
• Can you double check that the Sass version is the same? (Sorry about this one but in theory all compressor is doing is handing off the input to Sass to be processed — obviously something is going on but I want to rule this out.)

[wjdp]

@carltongibson:

• Already running with COMPRESS_ENABLED = False, same result observed with setting it True.
• This is how I'm checking sass version. Running the server in that environment

$ sass -v 
Sass 3.4.22 (Selective Steve)

I have tried including either sass version or a pre-built bootstrap.css file in a compressor block followed by a file just containing a body background:green as a checklight for valid/parseable CSS. I'm getting 'green' for the pre-built .css version, but not for .sass—where compressor builds bootstrap.

[carltongibson]

@wjdp OK Thanks. Hmmm.

In that case can I suggest putting a breakpoint in Compressor.precompile? Firstly is content passed in correctly?

Then in hunks() is the value returned from the precompiler correct?

[karyon]

i'm looking into this right now. the problem is the same as #764. the CssAbsoluteFilter uses r'url\(([^\)]+)\)' to match URLs, and therefore stops at the first closing parenthesis. since regex are not capable of dealing with an arbitrary number of nested parenthesis, i see three options:

1. deal with exactly one level of nested parenthesis because that ought to be enough for anybody
2. do it properly with more intelligent matching logic
3. use some library to parse the css.

i don't want to spend much time on this and am looking into option 1, if anyone wants to create a more robust solution, i'd be glad to review that.

[karyon]

proposed fix in #828. it does not actually handle nested parenthesis at all, it just expects closing quotes if there are opening ones (so url("data:...stroke='rgba(0, 0, 0, 0.5) wont match) and, to be safe, data-uris are ignored altogether.

[carltongibson]

@wjdp could you give #828 a try? It should do what you need but a test run on your part would be a good confirmation.

[wjdp]

Shall do

[wjdp]

@carltongibson Can confirm that PR has fixed this issue for me. Thank you @karyon for your very quick work! 😄

[carltongibson]

Awesome 👏🏽 thanks for the follow up.