Django-compressor: Sass, résultats différents avec et sans compresseur, provoquant des erreurs d'analyse

Créé le 15 févr. 2017  ·  11Commentaires  ·  Source: django-compressor/django-compressor

Bonjour, je rencontre un problème lors de l'utilisation de Bootstrap 4 alpha 6. J'ai rencontré que tous les CSS après l'inclusion de BS4 ont été ignorés par le navigateur. Creusé plus profondément et trouvé une erreur d'analyse du css généré.

J'utilise Django 1.8.17, Compressor 2.1.1, Sass 3.4.22

Je documenterai ici la première erreur d'analyse que j'ai trouvée.

L'erreur est le guillemet double " dans stroke='rgba(0, 0, 0, 0.5")', alors qu'il devrait être stroke='rgba(0, 0, 0, 0.5)' . Cela provoque des erreurs d'analyse dans le document.

Ligne invalide (via le compresseur 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"); }

Ligne valide (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"); }

Correspond à la version pré-compilée.

Source 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;

Comment nous générons via le compresseur dj

{% 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
Source
picture wjdp

Tous les 11 commentaires

semble assez mauvais. toute aide pour résoudre ce problème serait appréciée, je n'aurai probablement pas le temps pour les semaines à venir.

karyon picture karyon le 15 févr. 2017

Je vais essayer. Je ne connais pas votre base de code, donc tout pointeur sur l'endroit où commencer / toute intuition serait très précieux.

wjdp picture wjdp le 15 févr. 2017

Quelques réflexions :

  • Est-ce que cela se produit avec COMPRESS_ENABLED = False ?
  • Pouvez-vous vérifier que la version Sass est la même ? (Désolé pour celui-ci, mais en théorie, tout ce que le compresseur fait est de transmettre l'entrée à Sass pour qu'elle soit traitée - il se passe évidemment quelque chose, mais je veux l'exclure.)
carltongibson picture carltongibson le 15 févr. 2017

@carltongibson :

  • Déjà en cours d'exécution avec COMPRESS_ENABLED = False , même résultat observé avec le réglage True .
  • C'est comme ça que je vérifie la version sass. Exécution du serveur dans cet environnement
$ sass -v 
Sass 3.4.22 (Selective Steve)

J'ai essayé d'inclure la version sass ou un fichier bootstrap.css pré-construit dans un bloc de compression suivi d'un fichier contenant juste un fond de corps

wjdp picture wjdp le 15 févr. 2017

@wjdp OK Merci. Hmmm.

Dans ce cas, puis-je suggérer de mettre un point d'arrêt dans Compressor.precompile ? Premièrement, content est-il correctement transmis ?

Ensuite, dans hunks() le value renvoyé par le précompilateur est-il correct ?

carltongibson picture carltongibson le 16 févr. 2017

je regarde ça en ce moment. le problème est le même que #764. le CssAbsoluteFilter utilise r'url\(([^\)]+)\)' pour faire correspondre les URL et s'arrête donc à la première parenthèse fermante. puisque les regex ne sont pas capables de traiter un nombre arbitraire de parenthèses imbriquées, je vois trois options :

  1. traiter exactement un niveau de parenthèses imbriquées car cela devrait suffire à tout le monde
  2. le faire correctement avec une logique de correspondance plus intelligente
  3. utiliser une bibliothèque pour analyser le css.

Je ne veux pas passer beaucoup de temps là-dessus et j'étudie l'option 1, si quelqu'un souhaite créer une solution plus robuste, je serais heureux de l'examiner.

karyon picture karyon le 16 févr. 2017
👍1

correctif proposé dans #828. il ne gère pas du tout les parenthèses imbriquées, il attend juste des guillemets fermants s'il y en a des ouvrants (donc url("data:...stroke='rgba(0, 0, 0, 0.5) ne correspondra pas) et, pour être sûr, les data-uris sont complètement ignorés.

karyon picture karyon le 16 févr. 2017
👍1

@wjdp pourriez-vous essayer le #828 ? Il devrait faire ce dont vous avez besoin, mais un test de votre part serait une bonne confirmation.

carltongibson picture carltongibson le 16 févr. 2017

Doit faire

wjdp picture wjdp le 16 févr. 2017

@carltongibson Peut confirmer que PR a résolu ce problème pour moi. Merci @karyon pour votre travail très rapide ! :le sourire:

wjdp picture wjdp le 16 févr. 2017

Génial merci pour le suivi.

carltongibson picture carltongibson le 17 févr. 2017
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

oesah picture oesah  ·  6Commentaires
shezi picture shezi  ·  16Commentaires
jgirdner picture jgirdner  ·  3Commentaires
markstahler picture markstahler  ·  17Commentaires
ghost picture ghost  ·  20Commentaires