Django-compressor: Sass, unterschiedliche Ergebnisse mit und ohne Kompressor, was zu Parsing-Fehlern führt

Erstellt am 15. Feb. 2017 · 11Kommentare · Quelle: django-compressor/django-compressor

Hallo, ich habe ein Problem bei der Verwendung von Bootstrap 4 alpha 6. Ich habe festgestellt, dass alle CSS nach dem Einbinden von BS4 vom Browser ignoriert wurden. Tiefer gegraben und einen Parsing-Fehler des generierten CSS gefunden.

Ich verwende Django 1.8.17, Compressor 2.1.1, Sass 3.4.22

Ich werde hier den ersten Analysefehler dokumentieren, den ich gefunden habe.

Der Fehler ist das doppelte Anführungszeichen " in stroke='rgba(0, 0, 0, 0.5")', während es stroke='rgba(0, 0, 0, 0.5)' . Dies führt zu Parsing-Fehlern im Dokument.

Invalid Line (über DJ-Kompressor)

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

Gültige Leitung (über 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"); }

Entspricht der vorkompilierten Version.

Quelle von _Hintergrundbild_

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

Wie wir über DJ-Kompressor erzeugen

{% 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

Quelle

wjdp

Alle 11 Kommentare

sieht ziemlich schlecht aus. Jede Hilfe bei der Behebung dieses Problems wäre dankbar, ich werde wahrscheinlich nicht die Zeit für die kommenden Wochen haben.

karyon am 15. Feb. 2017

Ich werde es versuchen. Ich bin mit Ihrer Codebasis nicht vertraut, daher wären Hinweise darauf, wo Sie anfangen sollen, / irgendwelche Ahnungen sehr wertvoll.

wjdp am 15. Feb. 2017

Ein paar Gedanken:

Tritt dies bei COMPRESS_ENABLED = False ?
Können Sie überprüfen, ob die Sass-Version dieselbe ist? (Entschuldigung, aber theoretisch gibt der Kompressor nur die Eingabe an Sass weiter, um sie zu verarbeiten – offensichtlich passiert etwas, aber ich möchte dies ausschließen.)

carltongibson am 15. Feb. 2017

@carltongibson :

Läuft bereits mit COMPRESS_ENABLED = False , das gleiche Ergebnis wurde beim Setzen von True .
So überprüfe ich die Sass-Version. Ausführen des Servers in dieser Umgebung

$ sass -v 
Sass 3.4.22 (Selective Steve)

Ich habe versucht, entweder die Sass-Version oder eine vorgefertigte Bootstrap.css-Datei in einen Kompressorblock aufzunehmen, gefolgt von einer Datei, die nur einen Bodybackground:green als Kontrollleuchte für gültiges/parsbares CSS enthält. Ich werde „grün“ für die vorgefertigte .css-Version, aber nicht für .sass – wo Kompressor Bootstrap erstellt.

wjdp am 15. Feb. 2017

@wjdp OK Danke. Hmmm.

Kann ich in diesem Fall vorschlagen, einen Haltepunkt in Compressor.precompile ? Erstens ist content richtig übergeben?

Ist dann in hunks() das vom Precompiler zurückgegebene value korrekt?

carltongibson am 16. Feb. 2017

ich schaue mir das gerade an. das Problem ist das gleiche wie bei #764. der CssAbsoluteFilter verwendet r'url\(([^\)]+)\)' , um URLs abzugleichen, und stoppt daher bei der ersten schließenden Klammer. Da Regex nicht in der Lage ist, mit einer beliebigen Anzahl von verschachtelten Klammern umzugehen, sehe ich drei Optionen:

mit genau einer Ebene verschachtelter Klammern umgehen, denn das sollte für jeden ausreichen
Mach es richtig mit intelligenterer Matching-Logik
Verwenden Sie eine Bibliothek, um das CSS zu analysieren.

Ich möchte nicht viel Zeit damit verbringen und prüfe Option 1, wenn jemand eine robustere Lösung erstellen möchte, würde ich mich freuen, dies zu überprüfen.

karyon am 16. Feb. 2017

👍1

vorgeschlagene Korrektur in #828. es verarbeitet verschachtelte Klammern überhaupt nicht, es erwartet nur schließende Anführungszeichen, wenn es öffnende Anführungszeichen gibt (also url("data:...stroke='rgba(0, 0, 0, 0.5) nicht übereinstimmen) und um sicher zu gehen, werden Datenuris ganz ignoriert.

karyon am 16. Feb. 2017

👍1

@wjdp könntest du es mit # 828 versuchen? Es sollte tun, was Sie brauchen, aber ein Testlauf Ihrerseits wäre eine gute Bestätigung.

carltongibson am 16. Feb. 2017

Sollte tun

wjdp am 16. Feb. 2017

@carltongibson Kann bestätigen, dass PR dieses Problem für mich behoben hat. Danke @karyon für deine sehr schnelle Arbeit! :Lächeln:

wjdp am 16. Feb. 2017

Super 👏🏽 danke fürs Nachfassen.

carltongibson am 17. Feb. 2017

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen