clamp() + LESS ???

[wanst]

Servus!

Ich wollte in einer Contao-4.13.26-Installation die CSS-Funktion clamp() verwenden. Wenn ich die Anweisungen in eine CSS-Datei schreibe, klappt das auch. Stehen sie aber in einer LESS-Datei, verhackstückt aber der LESS-Interpreter (oder Contao) die Funktion und übernimmt nur noch einen Wert.

Bsp: von

font-size: clamp(1rem, 3vw, 2.7rem);

bleibt nur noch

font-size: 1rem;

übrig.

Erste Frage: Wer ist der Schuldige – Contao oder LESS? 1. a) Ist es überhaupt ein Fehler? Oder denkt sich LESS, es sei vernünftig, hier einen Wert vorauszuwählen?

Und 2. Ist das bekannt / ab wann ist geplant, das zu ändern? Bitte nicht erst in 5.x

Übergangs-Lösung ist für mich,die betreffenden Stile in eine CSS auszulagern und die dann im Layout zusätzlich zu laden. Wenn ich dann dort übrigens auch »Skripte zusammenfassen« aktiviere, funktioniert es trotzdem . Deshalb tendiere ich dazu, eher bei LESS die Schuld zu suchen zu escapen (mittels ~"…", siehe hier unten unter Wat nu? – danke zoglo).

Vielen Dank + LG!

[lucina]

Soweit ich weiss unterstützt LESS das zur Zeit nur rudimentär bzw fehlerhaft.

Ohnehin wäre mein präferierter Workflow, CSS lokal zu kompilieren…


Gesendet von iPhone mit Tapatalk

[zoglo]

Servus!

Erste Frage: Wer ist der Schuldige – Contao oder LESS?
1. a) Ist es überhaupt ein Fehler? Oder denkt sich LESS, es sei vernünftig, hier einen Wert vorauszuwählen?

Und 2. Ist das bekannt / ab wann ist geplant, das zu ändern? Bitte nicht erst in 5.x

Vielen Dank + LG!

Wer ist der Schuldige – Contao oder LESS?
Contao ist hier nicht Schuld, es ist eher die Abhängigkeit scssphp/scssphp, welche den Support noch nicht liefern kann in Version 1.x.

Siehe scssphp/scssphp

• https://github.com/scssphp/scssphp/issues/648
• https://github.com/scssphp/scssphp/issues/291

Siehe sass/sass

• https://github.com/sass/sass/issues/2860

Ist es überhaupt ein Fehler? Oder denkt sich LESS, es sei vernünftig, hier einen Wert vorauszuwählen?

• Less kann nicht denken. Es handelt sich hier um eine Limitierung

Ist das bekannt / ab wann ist geplant, das zu ändern? Bitte nicht erst in 5.x

• Contao kann das nicht ändern, deine Erwartungshaltung solltest du diesbezüglich auch senken, wenn man einmal recherchiert hat :P

Was ist das genaue Problem?

• Eine neue CSS-Property, welche in sass/sass noch nicht korrekt berücksichtigt wurde
• Version 2.0.0 für scssphp/scssphp braucht und bekommt einen kompletten Rewrite
• scssphp/scssphp ist eine Abhängigkeit in sehr großen Projekten, das wird also noch dauern

Wat nu?
Escape deine LESS-Datei, sodass diese komplett geparsed werden kann. Eine Google-Suche hätte geholfen:

.layer-eight-problem {
  font-size: ~"clamp(1rem, 3vw, 2.7rem)"
}

[wanst]

Und sorry, dass die Rückmeldung so lange gedauert hab, ich muss wohl meine Benachrichtigungen deaktiviert haben.

@lucina: CSS lokal kompilieren – warum? Ich betrachte es gerade als wesentlichen Vorteil, wenn ich das in LESS auf dem Server ablegen kann und Contao mir das Kompilieren/Synchronisieren abnimmt. Oder verstehe ich da was falsch? Was genau meinst du mit lokal kompilieren – du schreist dein LESS / SCSS lokal auf deinem Rechner, kompilierst lokal in CSS und lädst dann das fertige CSS auf den Server hoch, oder?

@zoglo: Höre ich da einen leisen Vorwurf heraus? Nix für Ungut – aber ich frage ja hier nicht aus Langeweile, sondern, weil ich nix gefunden hab. Und wenn ich nicht weiß, wonach ich suchen muss, hilft auch der Verweis auf Google wenig. Aber ich will nicht meckern – hast mir ja geholfen, besonders das Escapen. Darauf bin ich nicht gekommen. Also noml – vielen Dank!

[lucina]

Siehe https://docs.contao.org/manual/de/an...s-integration/ (und da ist das auch begründet).

Ja, ich schreibe das lokal und lasse es automatisiert auf den Server hochschieben.

[zoglo]

Und sorry, dass die Rückmeldung so lange gedauert hab, ich muss wohl meine Benachrichtigungen deaktiviert haben.

@lucina: CSS lokal kompilieren – warum? Ich betrachte es gerade als wesentlichen Vorteil, wenn ich das in LESS auf dem Server ablegen kann und Contao mir das Kompilieren/Synchronisieren abnimmt. Oder verstehe ich da was falsch? Was genau meinst du mit lokal kompilieren – du schreist dein LESS / SCSS lokal auf deinem Rechner, kompilierst lokal in CSS und lädst dann das fertige CSS auf den Server hoch, oder?

@zoglo: Höre ich da einen leisen Vorwurf heraus? Nix für Ungut – aber ich frage ja hier nicht aus Langeweile, sondern, weil ich nix gefunden hab. Und wenn ich nicht weiß, wonach ich suchen muss, hilft auch der Verweis auf Google wenig. Aber ich will nicht meckern – hast mir ja geholfen, besonders das Escapen. Darauf bin ich nicht gekommen. Also noml – vielen Dank!

Nein, kein Vorwurf, eher eine ausführliche Erklärung für die Nachwelt .
Wollte nur mal erklären woran es genau liegt und welche Abhängigkeiten da eine Rolle spielen.

Was man wissen muss ist, dass du bei scssphp/scssphp nur libsass nutzen kannst, kein dartsass 2.0.
Vieles muss man hier leider escapen, @use und @forward kann man auch nicht nutzen.
Mit SCSS bist du bei der scssphp-Abhängigkeit sogar besser aufgehoben als mit Less, da hätte das sofort geklappt .

Es gibt Vorteile und Nachteile etwas auf dem Server kompilieren zu lassen. In unserem Fall haben wir hier z.B das oveleon/contao-theme-compiler-bundle (Versioniert auch das Kompilat) programmiert, damit diese durch das Bundle kompiliert werden, nicht durch Contao.

Die Nachteile sind natürlich die fehlende Versionierung über GitHub, kein DartSass 2.0 und weiteres (Wie von lucina erwähnt).

[wanst]

Siehe https://docs.contao.org/manual/de/an...s-integration/ (und da ist das auch begründet).
Ja, ich schreibe das lokal und lasse es automatisiert auf den Server hochschieben.

Das ist ja ärgerlich – aber nicht zu ändern. Für mich scheint das aber trotzdem noch der bessere Workflow zu sein.

Was ist denn der Vorteil einer lokalen Kompilierung? Mehr Kontrolle, was bei rauskommt? Um solche Probleme zu vermeiden … Aber vielleicht muss ich mich ja doch überzeugen lassen, das so zu machen. Womit machst du das denn (wenn ich fragen darf und du das überhaupt verraten willst)? Ich stelle mir das einigermaßen aufwendig vor, für jedes Projekt so einen Workflow neu anzulegen und bei jeder Änderung neu rauszusuchen.

[wanst]

[…]Was man wissen muss ist, dass du bei scssphp/scssphp nur libsass nutzen kannst, kein dartsass 2.0.
Vieles muss man hier leider escapen, @use und @forward kann man auch nicht nutzen.
Mit SCSS bist du bei der scssphp-Abhängigkeit sogar besser aufgehoben als mit Less, da hätte das sofort geklappt .[…]

Ich sollte mich also doch eher mit SASS auseinandersetzen/anfreunden …

Es gibt Vorteile und Nachteile etwas auf dem Server kompilieren zu lassen. In unserem Fall haben wir hier z.B das oveleon/contao-theme-compiler-bundle (Versioniert auch das Kompilat) programmiert, damit diese durch das Bundle kompiliert werden, nicht durch Contao.[…]

Hab mir die Beschreibung der Erweiterung mal angesehen. Verstehe ich das richtig: ich lege mein Theme an, packe die SCSS dazu und wenn ich was ändere, kompiliere ich das entweder unter Themes über den Compile-Button oder in der Systemwartung?

[zonky]

für jedes Projekt so einen Workflow neu anzulegen und bei jeder Änderung neu rauszusuchen

Den Workflow denkst Du Dir einmal aus und übernimmst das dann für alle (zukünftigen) Projekte. Ich kompiliere mit Prepros.io und die geänderten CSS/MAP-Dateien können von dem Tool oder auch von der IDE automatisch auf den Webserver übertragen werden.

Wenn man im Team arbeitet, ist die Versionierung und Verteilung per Git wichtig - das geht per Server-Edit nur bedingt.

Für einige Kunden hab eich eine custom.css wo sie mal kleinere Anpassungen selbst machen können - das übernehme ich dann bei Updates/Wartung in die SCSS

[wanst]

Den Workflow denkst Du Dir einmal aus und übernimmst das dann für alle (zukünftigen) Projekte. Ich kompiliere mit Prepros.io und die geänderten CSS/MAP-Dateien können von dem Tool oder auch von der IDE automatisch auf den Webserver übertragen werden.

Wenn man im Team arbeitet, ist die Versionierung und Verteilung per Git wichtig - das geht per Server-Edit nur bedingt.

Danke, das schau ich mir an.
Versionierung ist hier eher Nice-to-have – ich mach das Allermeiste allein.

[zoglo]

Hab mir die Beschreibung der Erweiterung mal angesehen. Verstehe ich das richtig: ich lege mein Theme an, packe die SCSS dazu und wenn ich was ändere, kompiliere ich das entweder unter Themes über den Compile-Button oder in der Systemwartung?

Genau. Du bindest deine _name.scss Datei ein und kompilierst in einen ausgewählten Ordner.

Was ist denn der Vorteil einer lokalen Kompilierung? Mehr Kontrolle, was bei rauskommt? Um solche Probleme zu vermeiden … Aber vielleicht muss ich mich ja doch überzeugen lassen, das so zu machen. Womit machst du das denn (wenn ich fragen darf und du das überhaupt verraten willst)? Ich stelle mir das einigermaßen aufwendig vor, für jedes Projekt so einen Workflow neu anzulegen und bei jeder Änderung neu rauszusuchen.

In unserem Fall ist es etwas komplizierter, da wir ein komplett eigenes Framework geschrieben haben, welches z.B.:
- Eine Icon-Font anhand von svg-Dateien generiert und die CSS-Datei generiert
- CSS für Background-Images generiert
- Eine komplette Konfiguration aller vorhandenen Config-Variablen vorhanden ist, welche nach dem Kompilieren das Framework generiert
- Integration vieler Bundler über Hooks usw
- uvm.

In unserem Fall macht die lokale Kompilierung natürlich Sinn, da wir die scss-Dateien als raw-Datei hochladen und über den Compiler kompilieren (Versionierung existiert somit immernoch, das Kompilat wird generiert).
Ist zu komplex, es komplett zu erklären

[mlweb]

Danke, das schau ich mir an.
Versionierung ist hier eher Nice-to-have – ich mach das Allermeiste allein.

Obwohl ich ganz allein arbeite versioniere ich schon seit vielen Jahren.

[wanst]

[…] uvm. […] Ist zu komplex, es komplett zu erklären

Gibt es denn eine Doku, die über die Readme hinausgeht? Oder war die Erweiterung vor allem für den internen Gebrauch gedacht (von denen, die es (mit) programmiert haben)?

[zoglo]

Gibt es denn eine Doku, die über die Readme hinausgeht? Oder war die Erweiterung vor allem für den internen Gebrauch gedacht (von denen, die es (mit) programmiert haben)?

Eher für den Gebrauch als Abhängigkeit in anderen Plugins von uns .
Man kann mit dem Bundle natürlich selber die SCSS Dateien kompilieren, siehe es aber eher als kleines Zahnrad in einem großen Ökosystem.

Ich dokumentiere hier mal die Sachen, welche eher Expertenwissen sind:

Commands für SSH / Konsole :

• php vendor/bin/contao-console contao:themecompiler:list -> Listest alle Themes mit der ID auf
• php vendor/bin/contao-console contao:themecompiler:compile {ID} -> Kompiliert ein Theme mit der ID {ID}

File Compiler Hooks
Für andere Erweiterungen sehr sinnvoll, da du in den Kompilierprozess eingreifen kannst, hier kann man die Logik also anpassen

• $GLOBALS['TC_HOOKS']['beforeCompile'] -> Vor dem Kompilieren, Kontext = Compiler
• $GLOBALS['TC_HOOKS']['compilerParseConfig'] -> Einlesen der kompletten Theme-Konfigurationen (Weitere Variablen -> In Contao 5 aber schon entfernt), Kontext = Compiler, Konfiguration
• $GLOBALS['TC_HOOKS']['compilerParseVariableValue'] -> Lesen einer Theme-Variable (siehe oben), Kontext = Compiler, Variable

Benachrichtigungstypen
Folgende Benachrichtigungstypen können in anderen Erweiterungen genutzt werden:

• MSG_INFO -> Information
• MSG_HEAD -> Überschrift
• MSG_SUCCESS -> Erfolg
• MSG_WARN -> Warnung
• MSG_ERROR -> Fehler
• MSG_NOTE -> Notiz

Wie sieht es also im Endprodukt aus, wo es das kleine Zahnrad ist?
BeispielThemeCompiler.png