• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Less

Werbung:
Sowas kann man durchaus einsetzen. Speziell damit habe ich noch nichts gemacht, aber das Prinzip ist bei einem Präprozessor ja austauschbar. Eine Technologie wird abstrahiert oder erweitert, um „simpler“ mit ihr umgehen zu können. Das ist vergleichbar zu Template-Engines wie Smarty, die eine eigene Syntax über PHP stülpen.

Ein Nachteil solcher „Aufsätze“ ist, dass der „Compiler“, der den tatsächlichen CSS-Code generiert, Fehler enthalten kann. Außerdem ist es immer schwieriger, jemanden zu finden, der mit sowas gearbeitet hat, als jemanden, der sich mit reinem CSS auskennt. Auch gibt es für das normale CSS besseren Support als für LESS. Ein Beispiel dafür wäre eine IDE, die CSS versteht, aber in einer LESS-Datei kein Syntaxhighlighting und keine Autovervollständigung anbietet oder die zumindest durcheinander kommt, wenn eine CSS-Datei LESS-Syntax enthält.

Es ist ein Abwägen von Vor- und Nachteilen.
 
Noch ein Nachteil der mir ins Auge sticht ist der Einsatz von JavaScript. Nutzer ohne JavaScript würden nur ein verstümmeltes CSS bekommen mit dem der Browser nichts anfangen kann.

Auch ein Ziel von LESS scheint ja zu sein den Quellcode zu verkleinern. Dazu muss man aber nicht LESS nutzen. CSS-Dateien lassen sich auch komprimieren - nicht im Sinne von deflate sondern durch Entfernen unnötiger Zeichen und Kommentare bei der Ausgabe im Web. Damit konnte ich manche aufgeblähte CSS-Dateien um mehrere KB verkleinern. Ob das mit LESS möglich wäre, weiß ich nicht.
 
Werbung:
Allerdings ist das ein Weg in die richtige Richtung. Dynamisches CSS war schon immer ein frommer Wunsch von mir, da imho nur so CSS wirklich sinnvoll genutzt werden kann. Mal sehen, was die Zeit da bringt.
 
Ich habe mir LESS gerade mal angeschaut. Also so rein vom Syntax her find ichs echt gut. Besonders die Variablen und Funktionen finde ich sehr nützlich. Sowas habe ich mir schon immer für CSS gewünscht.

Werde ich demnächst bestimmt mal näher unter die Lupe nehmen.
icon_smile.gif
 
Ich könnte mir vorstellen, dass es eine Designentscheidung ist/war, sowas nicht in CSS zu integrieren, um der Rolle von CSS als „vorberechnetem“ Ausgabeformat Rechnung zu tragen. So ähnlich ist es ja auch bei HTML. Beide Formate lassen keinerlei „Logikprogrammierung“ (Bedingungen, Rechenoperation, Makros, …) zu. Na ja, CSS kann immerhin Includes.

Zumal es grundsätzlich trivial ist, CSS mit einer Sprache der Wahl dynamisch zu generieren. Es besteht also keine echte Notwendigkeit, die Standards mit weiterer Logik aufzublähen. (Alles, was HTML oder CSS hinzugefügt wird, muss theoretisch von jedem Client implementiert werden. Auch deshalb ist es sicherlich effektiver, einfach zu sagen: „Gib uns das schon fertig.“)

PHP: 
<!DOCTYPE html>

<html lang="en">

    <head>
        <meta charset="utf-8" />
        <title>New</title>

            <?php

                // Variables
                $color = '#4D926F';

                // Mixins
                $rounded_corners = function ($radius = '5px') {
                    return 'border-radius: ' . $radius . ';' . "\n"
                         . '-webkit-border-radius: ' . $radius . ';' . "\n"
                         . '-moz-border-radius: ' . $radius . ';' . "\n";
                };
            ?>

        <style type="text/css">



        #header {
            color: <?php echo $color; ?>;
        }
        h2 {
            color: <?php echo $color; ?>;
        }



        #header {
            <?php echo $rounded_corners(); ?>
        }
        #footer {
            <?php echo $rounded_corners('10px'); ?>
        }

        #header, #footer {
            border: 1px solid red;
        }

        </style>
    </head>

    <body>

        <div id="header">#header</div>

        <div id="content">
            <h2>h2 element</h2>
        </div>

        <div id="footer">#footer</div>

    </body>

</html>

LESS-Compiler für PHP: lessphp - leaner css in php
 
Werbung:
Nachdem ich das Thema vor einiger Zeit in der Firma erwähnte, erhielt ich die undankbare Aufgabe, mich in dieses Framework mittelfristig einzuarbeiten und eine Repräsentation für das Dev-Team vorzubereiten. Ich habe das bisher vermieden, aber mir dieses Wochenende dann doch mal ein entsprechendes Tutorial angeschaut. Less lässt sich serverseitig kompilieren und damit ist es unerheblich, ob der User JavaScript enabled hat. Auch Syntax-Highlighting funktioniert weitgehend, sofern man das in Eclipse einstellt.

Zusammengefasst liegt der Vorteil von Less darin, dass es CSS in eine kaskadierende Sprache verwandelt. Beispielweise könnte man alle Konstanten (Variablen) in ein separates Stylesheet auslagern und dort zentral Änderungen vornehmen, ohne das gesamte CSS danach durchsuchen zu müssen, ob die ursprünglich in body{} definierte Farbe in Zeile 1800 wieder überschrieben wurde. Auf die Weise lassen sich ganze Funktionsbibliotheken anlegen und es sind sogar Namespaces möglich. Wirklich Sinn macht so etwas natürlich nur bei sehr umfangreichen CSS-Dateien, oder wenn man Themes erstellen will, die in späteren Projekten Wiederverwendung finden sollen.

Der Preis dafür besteht, neben einem erhöhten Lernaufwand, vor allem in der Tatsache, dass der nicht-kompilierte CSS-Code schwer lesbar wird, weil eben nicht mehr auf Anhieb ersichtlich ist, welche Attribute und Werte verwendet werden.
 
Zuletzt bearbeitet:
less ist insbesondere dann sehr interessant wenn man in größeren teams agil entwickelt. unsere frontendler nutzen das sehr gerne. im idealfall wird lokal rund auf dem buildserver die css file durch den compiler gejagt.
 
Einige Dinge sind mir noch unklar:

Wie CSS-Klassen verwenden Mixins als Präfix den Punkt. Um nun das eine vom anderen unterscheiden zu können, wird bei Mixins der erste Buchstabe groß geschrieben (capitalized first letter).
Code: 
@defaultRadius:30px;
 
.RoundedShape(@radius:@defaultRadius){
    -webkit-border-radius:@radius;
       -moz-border-radius:@radius;
            border-radius:@radius;
}

.Round{
    .RoundedShape(999px);
}

Nicht ganz so eindeutig verhält es sich hingegen mit Namespaces.
Code: 
#namespace1 {
  .background() {
    border: 1px solid black;
    background-color: gray;
    &:hover { background-color: red }
  }
}

#random_div {
  color: white;
  #namespace1 > .background;
}

Woher weiß Less hier, dass es im ersten Fall einen Namespace und im zweiten ein gewöhnliches Div auszuwerten hat? Im unteren Teil könnte ich mir noch vorstellen, dass der > Operator im Anweisungsblock zur Differenzierung dient, aber der obere könnte ebenso gut eine Nested Rule beschreiben.

Auch ist es zwar offensichtlich möglich, JS zu embedden,
Code: 
@var: '"hello kitty".toUpperCase()';

aber wie ließe sich der an eine Less-Variable übergebene Textstring im HTML sichtbar machen?
 
Werbung:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben