Django-compressor: Sass, resultados diferentes usando compressor e sem, causando erros de análise

Criado em 15 fev. 2017 · 11Comentários · Fonte: django-compressor/django-compressor

Olá, estou tendo um problema ao usar o Bootstrap 4 alfa 6. Descobri que todo o CSS após a inclusão do BS4 foi ignorado pelo navegador. Pesquise mais a fundo e encontre um erro de análise do css gerado.

Estou usando Django 1.8.17, Compressor 2.1.1, Sass 3.4.22

Devo documentar aqui o primeiro erro de análise que encontrei.

O erro é a aspa dupla " em stroke='rgba(0, 0, 0, 0.5")', mas deveria ser stroke='rgba(0, 0, 0, 0.5)' . Isso causa erros de análise no documento.

Linha inválida (via compressor dj)

.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"); }

Linha válida (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"); }

Combina com a versão pré-compilada.

Souce de _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;

Como geramos 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)),
)

bug

Fonte

wjdp

Todos 11 comentários

parece muito ruim. Agradecemos qualquer ajuda para consertar isso, provavelmente não terei tempo nas próximas semanas.

karyon em 15 fev. 2017

Eu vou tentar. Não estou familiarizado com sua base de código, portanto, qualquer indicação sobre por onde começar / qualquer palpite seria muito valioso.

wjdp em 15 fev. 2017

Algumas idéias:

Isso ocorre com COMPRESS_ENABLED = False ?
Você pode verificar se a versão do Sass é a mesma? (Desculpe por este, mas em teoria tudo o que o compressor está fazendo é repassar a entrada para o Sass para ser processada - obviamente, algo está acontecendo, mas eu quero descartar isso.)

carltongibson em 15 fev. 2017

@carltongibson :

Já rodando com COMPRESS_ENABLED = False , mesmo resultado observado com a configuração True .
É assim que estou verificando a versão atrevida. Executando o servidor nesse ambiente

$ sass -v 
Sass 3.4.22 (Selective Steve)

Tentei incluir a versão sass ou um arquivo bootstrap.css pré-compilado em um bloco compressor seguido por um arquivo contendo apenas um body b ackground: green como uma luz de verificação para CSS válido / analisável. Estou ficando 'verde' para a versão pré-construída .css, mas não para .sass - onde o compressor cria bootstrap.

wjdp em 15 fev. 2017

@wjdp OK, obrigado. Hmmm.

Nesse caso, posso sugerir colocar um ponto de interrupção em Compressor.precompile ? Em primeiro lugar, content passado corretamente?

Então, em hunks() o value retornado do pré-compilador está correto?

carltongibson em 16 fev. 2017

estou investigando isso agora. o problema é o mesmo que # 764. o CssAbsoluteFilter usa r'url\(([^\)]+)\)' para corresponder a URLs e, portanto, para no primeiro parêntese de fechamento. uma vez que regex não é capaz de lidar com um número arbitrário de parênteses aninhados, vejo três opções:

lidar com exatamente um nível de parênteses aninhado porque isso deve ser o suficiente para qualquer pessoa
faça-o corretamente com uma lógica de correspondência mais inteligente
use alguma biblioteca para analisar o css.

não quero perder muito tempo com isso e estou analisando a opção 1, se alguém quiser criar uma solução mais robusta, ficaria feliz em revisá-la.

karyon em 16 fev. 2017

👍1

correção proposta em # 828. ele na verdade não lida com parênteses aninhados, ele apenas espera aspas de fechamento se houver as que abrem (então url("data:...stroke='rgba(0, 0, 0, 0.5) não combinará) e, para ser seguro, os dados-uris são totalmente ignorados.

karyon em 16 fev. 2017

👍1

@wjdp você poderia dar uma chance ao # 828? Ele deve fazer o que você precisa, mas um teste de sua parte seria uma boa confirmação.

carltongibson em 16 fev. 2017

Deve fazer

wjdp em 16 fev. 2017

@carltongibson Pode confirmar que o PR corrigiu esse problema para mim. Obrigado @karyon pelo seu trabalho rápido! :sorriso:

wjdp em 16 fev. 2017

Incrível 👏🏽 obrigado pelo acompanhamento.

carltongibson em 17 fev. 2017

Esta página foi útil?

0 / 5 - 0 avaliações