xHBBo: CSS mit PHP erzeugen bzw. durch Less

Beschäftige mich etwas mit LESS da behauptet wird das man dadurch Arbeit spart in dem man mit Variablen arbeitet. Auf der einen Seite stimmt dieses auch, aber das gleiche kann ich auch mit PHP umsetzten und hat den Vorteil ich muss LESS nicht erst kompilieren. Stimmt ihr mir hier zu?

In PHP setzte ich dieses derzeit so um

  
<link rel="stylesheet" type="text/css" href="design.css.php" />  

  
<?php  
header('Content-type: text/css');  
  
$hintergrund = "#efefef";  
$orange = "#F60";  
$border = "1px solid #666;"  
?>  
  
body {  
    background-color:<?php echo $hintergrund; ?>;  
}  
  
h1 {  
    color: <?php echo $orange; ?>;  
    border: <?php echo $border; ?>;  
}  

  1. Hi,

    Beschäftige mich etwas mit LESS da behauptet wird das man dadurch Arbeit spart in dem man mit Variablen arbeitet. Auf der einen Seite stimmt dieses auch, aber das gleiche kann ich auch mit PHP umsetzten und hat den Vorteil ich muss LESS nicht erst kompilieren.

    Mit ziemlicher Sicherheit hat dein derzeitiges Vorgehen den Nachteil, dass absolut Null Caching des Stylesheets stattfindet.

    MfG ChrisB

    --
    Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
  2. Hallo!

    Beschäftige mich etwas mit LESS

    Da könntest du ja ggf. auch noch auf SASS umschwenken.
    Einen kleinen Vergleich findest du u.a. hier: http://css-tricks.com/sass-vs-less/

    da behauptet wird das man dadurch Arbeit spart in dem man mit Variablen arbeitet.

    Die Möglichkeit Variablen zu verwenden ist aber nur ein (kleiner) Aspekt von CSS Preprocessors.

    Auf der einen Seite stimmt dieses auch, aber das gleiche kann ich auch mit PHP umsetzten und hat den Vorteil ich muss LESS nicht erst kompilieren. Stimmt ihr mir hier zu?

    Wenn du es rein auf die Verwendung (simpler) Variablen beschränkst, ist deine Aussage zumindest nicht falsch.

    Wobei ich schon beim Anblick der ganzen PHP Open und Close Tags, samt der ECHO Anweisungen Bauchschmerzen kriege ...!

    Wie gesagt, die Vorteile bei der Verwendung von CSS Preprocessors geht weit über die Möglichkeit von Variablen hinaus.

    So erlaubt SASS u.a. die Verschachtelung von Anweisungsblöcken, die Verwendung von Funktionen, die Einbindung fremder und eigener Mixins und und und.

    Außerdem gibt es einige Frameworks, bzw. Funktionsbibliotheken wie z.B. Compass oder Bourbon.
    Und nicht zu vergessen eine stetig wachsende Nutzergemeinde.

    Natürlich kannst du das im Prinzip auch alles selber in PHP nachbauen.
    Die Frage ist nur wozu/ warum?

    Im übrigen kann man sich seine Arbeistumgebung auch so einrichten, dass die entsprechenden Dateien bei jeder Änderung automatisch kompiliert werden. Und die dafür benötigte Zeit holst du spielend durch eingesparte Schreibzeit wieder rein ..., bei weitem!

    Gruß Gunther

  3. Mahlzeit,

    Beschäftige mich etwas mit LESS da behauptet wird das man dadurch Arbeit spart in dem man mit Variablen arbeitet.

    Ich setze es nicht ein, weil es zur Laufzeit per Javascript übersetzt und dafür ne Menge an Daten zusätzlich geladen werden muss. Vorallem sind es mehrere Dateien, also mehrere zusätzliche Requests.

    Für statische Stylesheets nutze ich SASS, für dynamische, wie du, PHP aber mit einer Template-Engine (Smarty3, gibt aber auch andere), die sich ums Caching kümmert.

    Was du einsetzt, hängt aber auch von  der Grösse der Anwendung und der Zielgruppe ab. Bei mobilen Geräten würde ich nie LESS nutzen, in einem Intranet, wo jeder Rechner mit 100-1000MBit/s am Server hängt, ist der Overhead vernachlässigbar.

    Wenn du deine Styles per PHP erzeugen willst, kannst du die Ausgabe des PHP auch auf Festplatte schreiben und dann statisch nutzen.

    --
    42
    1. Meine Herren!

      Ich setze es nicht ein, weil es zur Laufzeit per Javascript übersetzt und dafür ne Menge an Daten zusätzlich geladen werden muss.

      Man kann mit Less genau wie mit SASS oder vanilla PHP auch vorab einen CSS-Stylesheet generieren. Die Generierung zur Laufzeit gibt es lediglich on top und ist auch eher als Entwicklungs-Werkzeug zu verstehen. Die Laufzeit-Generierung sollte unter normalen Umständen nicht ihren Weg in eine Produktiv-Umgebung finden, die Gründe dafür hast du ja schon ganz gut erklärt.

      Bei mobilen Geräten würde ich nie LESS nutzen

      Das ist ein Trugschluss aus dem oben aufgedecktem Missverständnis.

      Mein aktueller Favorit ist übrigens: absurd.js

      --
      “All right, then, I'll go to hell.” – Huck Finn
      1. Mahlzeit,

        Das ist ein Trugschluss aus dem oben aufgedecktem Missverständnis.

        Da hast du recht, wenn LESS das CSS nicht zur Laufzeit erzeugt und nicht komplett geladen sein muss, ist das kein Problem mehr.

        Mein aktueller Favorit ist übrigens: absurd.js

        Schau ich mir mal an. Bin immer für neues ;)

        --
        42
  4. @@xHBBo:

    nuqneH

    das gleiche kann ich auch mit PHP umsetzten und hat den Vorteil ich muss LESS nicht erst kompilieren. Stimmt ihr mir hier zu?

    Nein. Was ist wohl besser: das CSS bei jeder Änderung am Stylesheet mittels Präprozessor oder bei jedem Aufruf des Stylesheets mittels PHP zu generieren?

    Von LESS würde ich die Finger lassen und Sass verwenden, aus Gründen.

    Und wenn’s dir nur um Variablen geht, brauchst du zukünftig keinen Präprozessor.

    Qapla'

    --
    „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
  5. Hallo!

    Stimmt ihr mir hier zu?

    Less ist eine Sprache, die zu CSS kompiliert. Darauf ist sie ausgelegt, optimiert und beschränkt. Es ist nicht möglich, mit Less stark fehlerhaften CSS-Code zu erzeugen, weil der Compiler weiß, wie die Ausgabe aussehen muss. Less und andere CSS-Präprozessoren decken nur einen bestimmten Bereich ab, sind darin spezialisiert und äußerst robust. Sie enthalten eine bestimmte Logik, die nur im CSS-Kontext sinnvoll und nützlich ist. Solche Sprachen werden auch domänenspezifische Sprachen genannt.

    PHP ist eine vollwertige generische Programmiersprache, die allen möglichen Output produzieren kann. Also lassen sich prinzipiell mit PHP alle Features von Less umsetzen (das sind im Übrigen viel mehr als nur Variablen). Erstens will man das nicht tun, denn CSS-Präprozessoren existieren bereits. Zweitens stößt man bei fast allen Sprachen an Grenzen, wenn man mit PHP einfach irgendwelche Bytes per <?php echo ?> ausspuckt. PHP versteht den Kontext nicht, in dem die Bytes ausgegeben werden. Um stets validen und sicheren Code zu produzieren, müsste man sich erst eine Abstraktion programmieren. Dann arbeitet man auf einem abstrakten Objektbaum, der letztlich serialisiert wird, oder mit Metasprachen, die interpretiert/übersetzt werden.

    Das ist auch der Grund, warum größere Webanwendungen oft HTML-Template-Sprachen nutzen, anstatt mit <?php echo ?> und komplexer PHP-Logik in den Templates zu hantieren. Genauso wie bei CSS-Präprozessoren sollen diese Sprachen gar nicht die volle Logik einer generischen Programmiersprache haben, sondern nur die, die für den Anwendungsbereich sinnvoll und sicher ist.

    Natürlich ist es aufwändig, diese Zusatzsprachen zu lernen und entsprechende Compiler aufzusetzen, aber es ist die Sache wert, denn sie sind das passende Werkzeug.

    Mathias

    1. @@molily:

      nuqneH

      Es ist nicht möglich, mit Less stark fehlerhaften CSS-Code zu erzeugen,

      Doch, das ist es.

      weil der Compiler weiß, wie die Ausgabe aussehen muss.

      Sass weiß es, LESS nicht.

      Qapla'

      --
      „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
      1. Hallo,

        weil der Compiler weiß, wie die Ausgabe aussehen muss.
        Sass weiß es, LESS nicht.

        Es ging mir um das allgemeine Konzept in Abgrenzung zum Zusammenbauen von Strings. Entscheidend ist, dass Less solche Fehler mit geringem Aufwand erkennen *könnte* und, wenn die @media-Regeln schon nicht korrekt zusammengefasst werden, zumindest mit einer konkreten Fehlermeldung abbrechen könnte. Auf einem abstrakten Syntaxbaum lassen sich solche Regeln einfach prüfen, beim Verketten von Strings nicht. Dass Less und wahrscheinlich auch Sass nicht sämtliche Regeln prüfen und zudem Bugs enthalten, ist dadurch nicht ausgeschlossen.

        Mathias

        1. @@molily:

          nuqneH

          Es ging mir um das allgemeine Konzept in Abgrenzung zum Zusammenbauen von Strings. Entscheidend ist, dass Less solche Fehler mit geringem Aufwand erkennen *könnte*

          Und mir ging’s darum, dass LESS das könnte, aber nicht tut. Bleibt zu hoffen, dass der Bug endlich mal gefixt wird. Bis dahin u.a. aus diesem Grund ziehe ich Sass vor und rate allen, das auch zu tun.

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
  6. Hallo,

    man _kann_ Nägel auch mit einer Zange in die Wand schlagen.

    Gruß
    Kalk