In einem kürzlichen Q&A-Artikel auf Smashing Magazine wurde die Frage gestellt, wie man erkennt, ob ein Entwickler schlechtes CSS geschrieben hat. Insbesondere
Was sind die Anzeichen dafür, dass das CSS suboptimal ist oder dass der Entwickler keine gute Arbeit geleistet hat? Worauf achten Sie bei CSS, um zu bestimmen, wie gut oder schlecht es ist?
Ich fand, das war eine interessante Frage, und ich wollte meine Antwort etwas erläutern.
Warum?
Vielleicht haben Sie jemanden beauftragt, CSS für Sie zu schreiben, und möchten einschätzen, wie gut er das gemacht hat. Vielleicht schauen Sie sich das CSS von jemandem an, den Sie potenziell einstellen möchten. Vielleicht möchten Sie Ihr eigenes CSS irgendwie einschätzen.
Der offensichtliche Test
Schauen Sie sich die Website an. Wenn sie völlig durcheinander aussieht, dann hat sie schlechte Arbeit geleistet.
Wenn man das noch weiter treibt, prüfen Sie, ob sie mit den Browsern übereinstimmt, die als unterstützt vereinbart wurden. Das Design sollte in allen davon funktionsfähig sein.
Wenn das Design responsiv sein soll, ändern Sie die Größe Ihres Browserfensters, um sicherzustellen, dass das Design bei jeder Breite und Höhe funktioniert.
Wenn alles gut aussieht, ist das ein guter (und notwendiger) erster Schritt. Aber es ist kein absoluter Beweis dafür, dass das CSS gut ist.
Der Formatierungstest
Schauen Sie sich die *erstellte* CSS-Datei an. Denken Sie daran, dass es bewährte Praxis ist, das minifizierte CSS der Live-Website bereitzustellen (alle unwichtigen Leerzeichen entfernt), also schauen Sie sich das nicht an.
Wenn Sie einen etablierten Styleguide hatten, der befolgt werden sollte, wurde er befolgt?
Wenn nicht, sieht es *konsistent* aus – als ob sie einen eigenen Styleguide hätten, an den sie sich halten? Oder ist es etwas nachlässig? Nachlässig bedeutet, manchmal gibt es ein Leerzeichen nach Selektoren und manchmal keines. Manche Codeblöcke sind eingerückt und andere nicht. Einzeilige CSS-Codezeilen sind mit mehrzeiligen CSS-Codezeilen vermischt, ohne Sinn und Verstand.
Sauberer Code ist ein Zeichen eines respektvollen Entwicklers. Eines, das Respekt vor dem Handwerk und der Arbeit hat, die es leistet.
Wenn diese ersten beiden Tests bestanden werden, ist das großartig. Aber immer noch kein Beweis dafür, dass das CSS gut ist.
Der Selektortest
Die ersten beiden Tests könnten von fast jedem durchgeführt werden, aber von nun an müssen Sie selbst mit CSS vertraut sein. Beginnen Sie mit dem Lesen des CSS und sehen Sie, ob das, was Sie sehen, für Sie Sinn ergibt.
Sehen die Selektoren rational aus? Wenn Sie einen Selektor wie
.article #comments ul > li > a.button {
/* Crazy town */
}Ich wäre besorgt. Das ist ein Entwickler, der sich selbst mit Spezifitätsproblemen bekämpft, etwas, das gutes CSS nicht tut.
Wie sind die Klassennamen? Verständlich? Hoffentlich finden Sie nichts wie „bigGray“ oder „left50“, da die Genauigkeit davon sicherlich kurzlebig sein wird und die zukünftige Entwicklung erschwert.
Wie repetitiv ist es? Wenn Sie zum Beispiel sehen, dass derselbe `box-shadow` an 20 verschiedenen Stellen angewendet wird, ist das wahrscheinlich ein Zeichen für mangelndes Refactoring. Gute CSS-Entwickler erkennen solche Muster und passen sie besser an.
Der Lesestoff-Test
Wie ist die Dateigröße des bereitgestellten CSS? 100k wären absolut riesig für eine CSS-Datei. Klein ist gut. Sogar (besonders) auf komplexen Websites. Riesige Dateien sind oft ein Zeichen für mangelnde Konsistenz.
Der Bearbeitungstest
Ändern Sie einen Stil, den Sie auf der Website ändern möchten, und versuchen Sie, ihn selbst zu ändern. Tauschen Sie zum Beispiel alle verwendeten Schriftarten gegen andere Schriftarten aus. Konnten Sie sich schnell mit dem Code vertraut machen? Hat es sich so angefühlt, als gäbe es einen Plan, wie mit Schriftarten umgegangen wurde? Wie schnell konnten Sie es tun? Schneller oder langsamer als das normalerweise dauert?
Wie machen Sie das?
Waren Sie jemals in der Lage, das CSS anderer zu beurteilen? Haben Sie ähnliche Tests verwendet? Hatten Sie mehr definierte Metriken?
Machen Sie eine Suche in der Datei nach „!important“
Siehe
http://oli.jp/img/2011/important-inheritance.png
:)
Ich stimme voll und ganz zu, dass jede Verwendung von „!important“ peinlich ist, aber es gibt Anwendungsfälle, in denen es gerechtfertigt sein kann. Ich falle gelegentlich seinem Gebrauch zum Opfer, wenn ich ein jQuery-Plugin implementiere, das eigene Inline-CSS zu bestimmten Elementen hinzufügt, und aus irgendeinem Grund diese Stile überschrieben werden müssen. Der andere Fall, den ich sehe (etwas weniger gerechtfertigt), ist, dass man versehentlich einen darin lässt, während man Stylesheets von mehreren Entwicklern zusammenführt, die an demselben Entwicklungsserver arbeiten und gezwungen sind, einander zu überschreiben.
Wenn Sie jemals versucht haben, MS SharePoint zu stylen, gewöhnen Sie sich bald daran, !important verwenden zu müssen
Eine weitere Sache, auf die ich speziell achte, bezieht sich auf Boilerplates.
Die Verwendung von etwas wie dem html5 Boilerplate ist bei der Entwicklung ziemlich beliebt geworden, und ich schaue immer nach: Haben sie einfach ihr handgefertigtes CSS in die Boilerplate-CSS-Datei geklatscht und ignoriert, was da war? Oder (was man hofft) haben sie sich tatsächlich das Boilerplate angesehen und das entfernt, was sie für ihr Projekt möglicherweise nicht wirklich brauchen? Leere Media-Query-Anweisungen machen mich traurig.
Ähnlich, wenn es einen Satz von Druckstilen in ihrem CSS gibt, drucken Sie eine Vorschau der Seite und prüfen Sie, ob sie tatsächlich gut aussieht, wenn sie gedruckt wird (Standard-HTML5BP passt nicht für jedes Projekt).
Ich denke, das ist eine großartige Starterliste, um die Qualität von CSS zu beurteilen. Ich denke, ein weiteres großes Problem da draußen sind sich wiederholende Stilregeln (die sich gegenseitig widersprechen) und CSS ohne Kommentare.
Eine Sache bezüglich der Selektoren... Sie sagten: „Das ist ein Entwickler, der sich selbst mit Spezifitätsproblemen bekämpft, etwas, das gutes CSS nicht tut.“ Ich stimme zu, aber wir arbeiten nicht immer mit makellosem HTML, das wir geschrieben haben. Oft arbeiten wir daran, Stile für bestehende Anwendungen, Tools, Add-ons, Plugins usw. zu ändern. Sehr spezifische Selektoren können ein Zeichen für einen CSS-Coder sein, der weiß, wie man mit den Einschränkungen eines Tools umgeht, ohne Skripte hinzuzufügen und das HTML auseinanderzureißen. Es kann auch ein Zeichen für einen CSS-Coder sein, der keine Klassen und IDs im HTML überstrapaziert und stattdessen semantisches HTML verwendet, um Elemente anzusprechen.
Stimme 100% zu. Darüber hinaus ist Zeit auch ein riesiger Faktor. Für meinen persönlichen Code bin ich viel strenger als bei der Arbeit, einfach weil die Kunden im Allgemeinen keinen Wert auf gut geschriebenen Code legen. Sie bevorzugen den schnellsten, schlampigsten Code, solange wir ihn in Rekordzeit herausbringen. Und es ist ihnen völlig egal, ob er später leicht zu aktualisieren ist.
Nur neugierig… wenn/wenn Sie Ihr CSS komprimieren, entfernen Sie die Kommentare? Ich kommentiere mein CSS nie, wegen der Komprimierung der Datei.
Komprimierungswerkzeuge können Kommentare entfernen, hier ist ein Beispiel für eines: http://www.cssdrive.com/index.php/main/csscompressor
Ich kommentiere mein CSS immer, egal was passiert. Manchmal sogar bis zur Deklarationsebene, damit der Kunde weiß, dass diese genaue Eigenschaft das ist, was seinen Hintergrund festlegt usw. Es hängt vom Projekt ab. Ich arbeite auch mit einem Produkt, das fast 50 CSS-Dateien OOTB verwendet, daher ist Kommentieren für meine CSS-Datei, die ich oben hinzufügen muss, unerlässlich.
Abgesehen von den bereits genannten Punkten ist Konsistenz eines der Hauptmerkmale, auf die ich bei Code achte. Wenn jemand konsistent ist, ist die Wahrscheinlichkeit, dass er weiß, was er tut, viel höher.
Eines der ersten Dinge, auf die ich achte, ist übermäßig ausführlicher Code. Zum Beispiel
statt des viel schöneren
oder
anstelle von
Und schließlich ein weiteres großes Problem ist, ob sie kurze Hex-Farben verwenden, wenn möglich, z.B. #FFF anstelle von #FFFFFF.
Schließlich, auf eine schmerzhaft lustige Art und Weise, habe ich vor ein paar Jahren für eine Agentur gearbeitet, die Research in Motion als Kunden hatte. Ihr Haupt-Stylesheet war damals 700 KB groß und wir mussten es auf jeder Seite, an der wir arbeiteten, einbeziehen und sicherstellen, dass unser CSS nicht mit ihm kollidierte.
Ich stimme zu, dass übermäßig ausführlicher Code schlecht ist… aber wenn Sie bestehenden übermäßig ausführlichen CSS überschreiben, auf den Sie keinen Einfluss haben, müssen Sie bei den übermäßig ausführlichen Dingen bleiben. Nur eine Klarstellung für die neueren Leute, die diesen Artikel posten (was großartig zu sehen ist). „Background-url“ hat mehr Gewicht als der Kurzschrift-„background“.
@ Heather (und wichtigere Leute, die ihren Kommentar lesen)
Nach dieser Logik: div{background-color: #FF0000;background: #FFFFFF;} würde einen roten Hintergrund ergeben. Aber abgesehen von einigen seltsamen Fehlern, die ich in einigen Fällen gefunden habe, wird dieser div absolut weiß sein (zum Glück, weil ein roter Hintergrund hässlich ist)
@ Ryan
Sie schreiben zuerst
background:url(‘background.jpg’) 10px 10px no-repeat #FFF;
Und dann sagen Sie, Sie mögen es nicht, wenn Leute kurze Hex-Codes schreiben. Lustig, nicht wahr?
Persönlich ziehe ich es vor, Kurzschrift-Code zu schreiben, aber jemand, der `margin-top` usw. schreibt, ist kein Dealbreaker. Manche Dinge sind persönlicher als tatsächlich schlechte oder gute Codierungspraktiken.
@Ryan `background-url` existiert **nicht**. Ich hoffe, Sie meinten `background-image: url("background.png");`.
Ich schreibe immer vollständige Hex-Farben, weil ich zwanghaft bin. Die meisten, die ich verwende, können nicht gekürzt werden, ich mag Einheitlichkeit, also sieht #FFFFFF besser aus und ergibt für mich mehr Sinn. Nur meine persönliche Vorliebe übrigens ;)
Ich bin mir nicht sicher, ob ich zustimme, dass man immer die Kurzschriftdarstellungen verwenden sollte. Erstens macht es das Lesen schwieriger. Außerdem ist es für Websites nicht relevant, aber die meisten E-Mail-Clients ignorieren die Kurzschrift und verlangen, dass Sie die vollständigen Deklarationen verwenden.
Ich glaube nicht, dass man daran messen kann, wie gut jemand CSS schreibt, basierend auf seiner Verwendung von Kurzschrift-Techniken. Es ist, als würde man sagen, dass Slang besser ist als volles Englisch. Das ist es nicht. Es ist nur persönliche Vorliebe. Es spart einen Bruchteil von KB an Dateigröße. Ich denke, wenn Sie sich Sorgen über die volle Deklaration machen müssen, die die Größe Ihrer CSS-Datei aufbläht, haben Sie möglicherweise größere Probleme, um die Sie sich kümmern müssen.
Nun, Kurzschrift hat ihre praktischen Seiten wie: die Möglichkeit, sie in einer einzigen Deklaration zu schreiben (und somit weniger Bytes zu verbrauchen UND sich mit dem gesamten umfassenden Aspekt von CSS wohlzufühlen), natürlich können sich die Meinungen unterscheiden, aber ich denke, wir haben Kurzschrift-CSS hauptsächlich aus diesem Grund. Daneben können Sie, wenn Sie eine umfassende CSS-Regel haben (als Basis), weiter unten präziser sein, um nur bestimmte Aspekte einer CSS-Zeile zu ändern. (d.h. wenn Sie die Kurzschrift `background`-Eigenschaft verwenden, können Sie weiter unten eine andere Farbe, ein anderes Hintergrundbild, eine andere Position usw. angeben, während Sie die Grundlage früher im Projekt beibehalten). Auch das ist wieder Teil der persönlichen Vorliebe. Es geht um die Taktiken, die Sie bei einem bestimmten Projekt anwenden.
Eines der ersten Dinge, auf die ich achte: vergiss `inherit` oder mache es überflüssig.
Manche Leute vergessen es und haben Klassen innerhalb von Klassen, die tausendmal dieselben Eigenschaften deklarieren.
Und dann suche ich nach absurder und unnötiger Wiederholung von Eigenschaften. Dies hängt auch mit dem Missbrauch von !important zusammen, der bereits erwähnt wurde.
persönliche Projekte
Man kann viel Zeit damit verbringen, super ordentliches CSS zu machen
Agentur, Kundenwebseite
1.) Zeit ist entscheidend, es funktioniert, ok, Frist eingehalten
2.) Man muss mit schrecklichem CSS arbeiten, das man nicht ändern kann, auch lustig
3.) Andere Fälle oder die oben genannten kombiniert
Schlechtes CSS in der Kundenarbeit bedeutet also nicht immer, dass der CSS-Typ nicht gut ist (er hat einfach keine Wahl).
Das fasst vieles zusammen. Leider gibt es Zeiten, in denen es einfach nicht möglich ist, den Code mit der Lupe durchzugehen oder sich Zeit zu nehmen, alles zu berücksichtigen.
Ja, das ist hier praktisch ein tägliches Vorkommnis. Bei meinen eigenen Projekten versuche ich, meine CSS-Dateien sauber und organisiert zu halten (zumindest bei meinen neueren Projekten haha), aber bei der Arbeit kann ich mir das selten leisten. Ich arbeite ständig mit CSS-Dateien, die von einer Vielzahl von Leuten verwaltet werden, viel Glück, das organisiert zu halten, auch die ganze Kommentierung der Welt kann das nicht retten...
Ich stimme Nr. 2 zu. Ich habe viel Kundenarbeit gemacht, bei der ich nach dem Rauswurf des vorherigen Entwicklers eingegriffen habe oder sogar nur für eine bestimmte Anpassung beauftragt wurde. In diesem Fall habe ich versucht, mein Bestes zu geben, den Code zu ändern und ihn so sauber wie möglich zu halten. Meistens werden Sie bei freiberuflicher Arbeit nicht eingestellt, um das CSS oder das HTML aufzuräumen, und es ist schwer zu rechtfertigen, meine Freizeit damit zu verbringen, den Code aufzuräumen, es sei denn, er ist wirklich schlecht und stört das, was ich zu tun versuche.
Bei Nr. 1 denke ich jedoch, dass es nicht immer nur darum geht, es so schnell wie möglich zu erledigen. Wenn ich den Kunden behalten möchte, muss ich sicherstellen, dass mein CSS für zukünftige Projekte skalierbar ist. Ich habe schlechten Code geschrieben, und im nächsten Jahr stellt mich der Kunde ein, um das Projekt zu aktualisieren, und ich denke: „Wer hat diesen Müll geschrieben!“ Bis ich merke, dass ich es war.
Hervorragende Einblicke in die Verwaltung von CSS, Chris. Ich stelle immer sicher, dass ich das Stylesheet komprimiere, bevor ich die Website in ihren Live-Zustand versetze.
„Einzeiliges CSS ist mit mehrzeiligem CSS vermischt, ohne Sinn und Verstand.“
Manchmal schreibe ich Code, der *so* aussieht, aber es ist nicht wirklich so. Wenn ich nur eine Eigenschaft habe, ist die Wahrscheinlichkeit groß, dass alles auf einer Zeile mit dem Selektor steht. Es ist nicht das Konsistenteste der Welt, aber es funktioniert und beeinträchtigt die Lesbarkeit nicht.
Das. Ich verwende oft einzelne Zeilen, wenn es nur wenige Eigenschaften gibt, wechsle dann aber zu mehrzeiligen, wenn es recht viele sind, da die einzelnen Zeilen unübersichtlich werden, wenn sie sich auf die nächste Zeile umbrechen.
Solange Sie zwischen diesen Stilen auf offensichtliche und konsistente Weise wechseln, ist das völlig in Ordnung. Das mache ich auch.
Ich benutze das auch
Wenn nur 1 Eigenschaft vorhanden ist, wird eine einzelne Zeile verwendet
Bei mehr macht es lesbar auf Zeilen
.lorem {color: red;} .ipsum { color: blue; height: 50px; line-height: 50px; }Danke für diesen Artikel, der sehr nützlich ist (und auch die Kommentare), für jemanden, der relativ neu im CSS-Coding ist wie ich!
Kann jemand einen guten Artikel empfehlen, wie ich mein CSS am besten organisieren kann (d.h. ob ich Klassen alle zusammen gruppieren soll oder nicht und ob ich es nach Farben/Typografie etc. aufteilen soll)? Meine CSS gut zu organisieren, ist etwas, womit ich kämpfe!
Danke
Nicolas Gallaghers Idiomatic CSS
github.com/necolas/idiomatic-css
Obwohl Sie Tipps zur Organisation finden können, würde ich vorschlagen, dass Sie versuchen, Ihre eigene zu entwickeln. Entweder oder die beiden würden gut funktionieren, oder in Kombination. Ich persönlich mag die Farb-/Typografie-Gruppierung nicht, aber das liegt daran, dass sie nicht so funktioniert, wie ich sie mental organisiere, und nicht daran, dass sie falsch ist.
Wie bei allem Code ist es wichtiger, ihn so zu organisieren, dass man ihn leicht finden kann, und hoffentlich auch für die nächste Person, die dasselbe tut, es sei denn, Sie arbeiten für jemanden, der groß genug ist zu sagen: „Scheiß auf Ineffizienz, das macht jeder, die ganze Zeit.“
Eingebettete Schriftarten und Bilder werden immer üblicher, um HTTP-Anfragen beim Laden der Seite zu reduzieren. Sie erhöhen die Dateigröße des Stylesheets erheblich und lassen es täuschend erscheinen, dass der Entwickler inkonsistent oder naiv ist. Beachten Sie dies also, wenn Sie nach der Größe einer CSS-Datei beurteilen. (Ja, ja, sie sollten vielleicht in eine andere Datei portiert werden; es hängt wirklich alles davon ab.)
Stimme Ihnen zu. Es sollte Konsistenz darüber geben, was der Designer für die Regeln befolgt.
Das Beurteilen von CSS beginnt normalerweise mit dem Blick auf die Produktionsdateien. Gibt es eindeutige Abschnitte, die anderen Entwicklern, die an Ihrem Projekt arbeiten, helfen, Ihren Code zu verstehen?
Zum Beispiel beginne ich normalerweise ein Stylesheet mit einem **Schlüssel** gefolgt von Überschriften, die die folgenden Abschnitte definieren
Die Schlüsselidee ist cool, wenn das für Sie funktioniert. Ich bin mir nicht sicher, ob ich dafür Punkte hinzufügen oder abziehen würde.
Ich würde widersprechen
Produktionsdateien = komprimierter Output, der nicht für Menschen zum Anschauen gedacht ist.
Ich mache ähnliche Dinge
wo in CSS steht, was es enthält oder nicht
damit ich es kopieren/einfügen/suchen kann, da ich jeden Abschnitt kommentiert habe
STYLE.CSS enthält
http://krsiak.cz/style.1.1.0.css
Ich verwende jetzt ein Inhaltsverzeichnis in meinen Stylesheets, aber ich nummeriere die Knoten nicht, um es einfacher zu machen, später etwas einzufügen, ohne neu zu nummerieren. Ich stelle sicher, dass das TOC identische Texte wie die Abschnittsüberschriften-Kommentare verwendet, um es einfach zu machen, mit der Suche zu diesen Texten zu springen (z.B. ⌘-I in Sublime oder ⌃-S in TM).
@ Chris – Obwohl Connor es in seiner Antwort nicht erwähnt hat, denke ich, dass er etwas auf dem richtigen Weg ist, indem er zuerst den Produktionscode überprüft. Nicht um herauszufinden, wie er strukturiert ist, sondern um **Ihren** Hauptproduktionspunkt zu beweisen: dass die Dateien minifiziert und unlesbar sein sollten. Wenn sie es nicht sind, sollte dies ein Warnsignal Nr. 1 sein.
Ich füge am Anfang einen Farb-Schlüssel hinzu.
Ich verwende auch Farben im Haupt-Stylesheet (MASTER.CSS)
#000; black (body, text, menu) #333; gray (dark - menu hover) #666; gray (text, border) #999; gray (table border) #CCC; gray (background) #EEE; gray (light - menu, background) #FFF; white (background, text, text shadow) #0645AD; blue (links) #98C22A; green (slider button) #AECA20; green (slider button:hover) #F9F9F9; gray (bg color in jQuery) #C4ED68; green (.highlight border) #E2FF9E; green (.highlight background)Ich bin sehr neugierig auf Klassen wie „left50“ oder „bigGray“. Was ist daran schlecht? Gibt es einen Artikel zum Lesen und Studieren? Weil ich ihn manchmal benutze und ich gerne wüsste, wo das Problem liegt.
Vielen Dank!
Es geht darum, semantisch zu sein – d.h. keinen Namen zu verwenden, der das Aussehen eines Elements beschreibt, sondern die Struktur.
Was ist zum Beispiel, wenn Ihr Kunde ein Farbschema ändert? Ihr .bigGray könnte jetzt grün sein. Oder Ihre .left50-Marge müsste auf nur 25 Pixel geändert werden, sodass der Name keinen Sinn mehr ergibt – besonders, wenn jemand anderes versucht, Ihren Code zu bearbeiten.
Vielleicht lesen Sie diesen Artikel, Chris erklärt es viel besser!
Hoffe, das hilft.
Das ist der einzige Punkt, zu dem ich Einwände habe. Eine Klasse wie `left50` ist in Ordnung, wenn diese Klasse nur „das“ tut und immer „das“ tun wird.
Wenn zum Beispiel `left50` nur links schwebt und eine Breite von 50% hat, warum sollte man sie anders nennen? Wenn Sie zu einem späteren Zeitpunkt möchten, dass das Element zum Beispiel 40% Breite hat, ändern Sie seine Klasse in `left40`.
960gs hat Klassennamen, die repräsentativ für ihre Stile sind.
Nur zur Klärung: Ich stimme zu, dass die meisten Klassennamen locker genug sein sollten, um Stiländerungen zu akzeptieren, aber Klarheit im Klassennamen schafft auch eine lesbarere Markup.
Ex: ul.list_normalize.left50
Wenn Sie das Stylesheet kennen würden, könnten Sie dieses Markup leicht lesen und wissen (zum Beispiel), dass diese ul keine Ränder oder Polster hat und links mit 50% Breite floatet.
Ich bevorzuge Lesbarkeit gegenüber Mehrdeutigkeit.
Nur meine Gedanken, obwohl ich offen für Kritik bin.
Semantik ist sehr persönlich, es gibt keine „richtige“ Antwort.
@Devin – Es ist nicht wirklich richtig, `left50` als Klasse zu verwenden, denn nicht nur müssten Sie die CSS-Datei ändern, wenn sich die Breite auf z.B. 25px verschiebt (dann `.left25`), sondern Sie müssten auch die HTML/PHP-Datei ändern – doppelte Arbeit, wie ich finde.
Ein weiterer schneller Test…
Scrollen Sie zum Ende der CSS-Datei und sehen Sie, wie viele Hacks angewendet wurden.
falls Sie bedingte Stylesheets als Hack zählen :)
in meinem Fall
IE 7 = 15x
IE 8 = 1x
http://krsiak.cz/style.1.1.0.css
Ehrlich gesagt, Sie brauchen eine große Haftungsausschlussklausel für diesen Artikel. Basierend auf dem, was geschrieben steht, haben Sie kein Recht, das CSS von jemand anderem zu beurteilen. Andere haben dieses Thema bereits angesprochen – Kontext ist alles. Sie berücksichtigen nicht
1. Der Entwickler, der mit Code integriert, über den er keine Kontrolle hat.
2. Arbeiten mit einem CMS oder einem anderen Framework, das Klassen und anderen Code automatisch generiert. Es ist vielleicht nicht logisch, aber die Ausgabe ist erforderlich.
3. Andere Entwickler, die den Code geändert haben, seit der Entwickler daran gearbeitet hat. Vielleicht sieht er gleich aus und hat dasselbe Endergebnis, aber kein Entwickler geht zurück zu alten Websites, um zu sehen, ob der Code seit seiner Arbeit daran geändert wurde.
4. JavaScript, das CSS modifiziert. Nicht alle von uns können wählen, wie JS integriert wird, und wenn es das CSS verfälscht.
Es gibt viele andere Szenarien, in denen ein guter CSS-Entwickler alle Ihre Tests nicht bestehen würde.
Es gibt einen Abschnitt namens „Warum?“ ganz oben in diesem Artikel, der erklärt, warum Sie dies möglicherweise tun müssen. Das sind alles gültige Punkte, aber ich stelle mir vor, dass Sie sie entweder bereits kennen würden oder sie in einer Diskussion zur Sprache kämen.
Chris, ja, das habe ich gelesen. Es scheint jedoch keine sichere Annahme zu sein, dass jeder weiß, dass er Ihre Tests nicht einfach für bare Münze nehmen kann. Selbst nach Diskussionen mit Leuten habe ich festgestellt, dass viele Interviewer selbst den Code nicht gut genug kennen, um solche Szenarien zu verstehen, selbst mit einer Diskussion.
Ich stelle mir vor, dass diese Seite für SEO sehr gut ranken wird. Daher werden viele Interviewer diese Seite lesen und mit den fehlgeleiteten Informationen bewaffnet sein und gute Entwickler falsch beurteilen.
Wenn deshalb ein guter Entwickler übergangen wird, ist das wahrscheinlich ein Gefallen für ihn, dass er den Job nicht bekommt.
Davon abgesehen würde es wahrscheinlich nur einen Satz ganz am Anfang dauern, um es zu klären, vielleicht dass es einfacher ist, Entwickler anhand von persönlichem Code zu beurteilen, da viele Faktoren den Standard von Agenturcode beeinflussen *seufz*
Trotzdem ein toller Artikel!
Die Aussage, dass Wiederholung von Kommentaren im Grunde falsch ist, wenn es um CSS geht. Genau deshalb gibt es Dinge wie LESS und SASS und sie sollten nach diesem Standard beurteilt werden. Aber es gibt nur so viele Tricks, die man verwenden kann, um die Wiederholung bei komplexen Regeln wie `box-shadow` und Verläufen zu reduzieren, wenn man bei CSS selbst bleibt (bis CSS-Variablen und einige andere Dinge allgemein unterstützt werden). Ich würde es verfeinern, indem ich sage, dass die Existenz VON VERMEIDBARER Wiederholung der Indikator für gutes/schlechtes CSS ist.
Auch unter „Der Selektortest“ fällt für mich, wie oft jeder Stil später überschrieben wird. Es ist gut, einige Basisstile zu haben, und sie dann mit einer spezifischeren Klasse später zu überschreiben, aber wenn derselbe Stil viele Male in einem einzigen Stylesheet zurückgesetzt wird, ist das meiner Meinung nach ziemlich schlecht.
Das ist nichts, was man leicht durch das Überfliegen einer CSS-Datei erkennen kann, man muss mit dem CSS und dem entsprechenden HTML gearbeitet haben, um zu wissen, welche Teile besser sein könnten.
Ich habe kürzlich ein sehr großes Projekt geerbt, bei dem alles Klassen sind und ich keine Kontrolle über die HTML-Ausgabe habe, aber einige Stile müssen seitenspezifisch sein, also mache ich Dinge wie dieses…
.article #comments ul > li > a.button {
/* Verrückte Stadt */
}
ist leider notwendig. Wenn ich Zeit hätte, das alles neu zu schreiben, glauben Sie mir, ich würde es tun. Absolut der falsche Weg, Klassen zu verwenden, meiner Meinung nach. Dies ist einer der größten Nachteile der Kompartimentierung der Entwicklung innerhalb von Agenturen.
Hier sind meine CSS-Tipps. Ich werde nicht auf die Details eingehen, aber wenn Sie diese Tipps befolgen, werden Sie besser für sie da sein.
– Verwenden Sie keine Klassennamen mit mehreren Wörtern, unabhängig vom Worttrenner
– Vermeiden Sie IDs, außer auf dem Body-Tag und/oder zur Identifizierung von Elementen für JS (nicht für Stile)
– Identifizieren Sie Inhalt, nicht Stil. D.h. Klassennamen sollten niemals explizit etwas über etwas aussagen, das in den Regeln definiert ist (keine Klassen wie „.one-third“).
– Schreiben Sie jeden Klassennamen auf, den Sie während des CSS-Entwicklungslebenszyklus eines Projekts verwenden
Auch Kudos an jeden oben, der den Kontext erwähnt hat. Gegen `!important` zu argumentieren, ist zum Beispiel lächerlich angesichts der Integration mit Systemen, über die Sie keine vollständige Kontrolle haben. Und zumindest für mich gilt: Je kleiner das Projekt, desto eher ist es in Ordnung, die Regeln zu brechen. CSS-Praktiken gelten vor allem für Langlebigkeit und Wartbarkeit. Super kleine Projekte, die Sie nur schnell abwerfen müssen, sind nicht immer anwendbar. Sie können immer später refaktorieren, wenn das Projekt so groß wird. Wenn Sie von Anfang an so gut im Schreiben von CSS sind, wird ein Refactoring nicht unbedingt so schwer sein.
Das gesagt, denke ich auch, dass es eine gewisse Gültigkeit hat, absichtlich nicht zu hart zu versuchen. Manchmal „entdeckt“ man die Gemeinsamkeit seiner Präsentationstrends, indem man ein wenig schlampiger ist, anstatt sofort zu versuchen, zu überentwickeln. Großartiges CSS zu schreiben ist wie großartiges Englisch zu schreiben, es erfordert viele Entwürfe und viele Iterationen, um prägnant, auf den Punkt gebracht, aber vor allem immer noch interessant zu sein.
Amen ;) CSS ist in der Tat in einem bestimmten „Stil“ geschrieben (kein Wortspiel hier), und auch wenn einige grundlegende Richtlinien gelten sollten (zum eigenen Seelenfrieden), gibt es einen Grund, warum bestimmte „Werkzeuge“ wie „!important“ verfügbar sind.
All das, gewürzt mit gesundem Menschenverstand und anschließendem Aufräumen, bringt einen weit!
Ich denke, eine große CSS-Datei ist nicht immer ein Zeichen für schlechtes CSS, es kann ein inkonsistenter Designer sein.
Tolle Vorschläge oben. Auch Naming ist mir wichtig. Nenne Dinge nach dem, was sie sind, und nicht nach dem, was sie tun
Was Kommentare im CSS betrifft, mache ich nie welche. Da ich der Einzige bin, der daran arbeitet, sehe ich keinen Bedarf an Kommentaren. Kommentare für mich hinzuzufügen wäre, als würde ich mein Zimmer mit Post-it-Zetteln bedecken, auf denen Tür, Wand, Schreibtisch, Bett usw. steht. Wenn es als Beispiel gepostet oder für jemand anderen geschrieben werden soll, machen Kommentare Sinn.
Was meine persönlichen CSS-Dateien betrifft, so gehe ich immer zurück und überprüfe meine Arbeit, wenn ich jemals über 7 KB für eigenständiges CSS hinausgehe. Ich halte auch CSS-Dateien für Styleswitcher-Zwecke auf 100 Bytes oder weniger.
Außerdem, etwa einmal im Monat, schrubbe ich mein CSS. Wenn ich eine Klasse in meinen HTML-Dateien verworfen habe, macht es keinen Sinn, sie in der CSS-Datei zu behalten. Ebenso überprüfe ich auch auf widersprüchliche Stile. Wenn ein Elternteil einen Rand angibt, das Kind keinen Rand angibt und ein anderes Kind einen anderen Rand angibt, ist es Zeit, zu untersuchen, warum und eine Möglichkeit zu finden, den Code zu optimieren.
Ich kommentiere mein CSS, auch wenn ich der Einzige bin, der daran arbeitet, denn wenn ich in sechs Monaten darauf zurückkommen muss, werde ich mich auf keinen Fall mehr daran erinnern, was alles ist oder wo ich alles platziert habe.
Sie müssen der Typ sein, der das CSS für dieses Projekt geschrieben hat, das ich aufräumen sollte. Glücklicherweise berechne ich die Zeit für die Ermittlung, was der billigere Typ, der die Website gebaut hat, zu erreichen versucht hat.
Das sind alles Dinge, über die ich mich auch beschwere. Allerdings ist es heutzutage im CMS-fokussierten Webdesign sehr schwer, Best Practices einzuhalten. Oft erbt man Klassen- und ID-Namen, zusammen mit einer Menge CSS von Drittanbietern. Manche sind ziemlich logisch, manche sind einfach verrückt.
Manchmal kann man einfach das Stylesheet auskommentieren und von vorne anfangen. Manchmal muss man sich durch Erweiterungen wühlen und Dinge anpassen, um den eigenen Bedürfnissen gerecht zu werden.
Ich wünschte, ich könnte einfach eine einfache Website mit einer CSS-Datei unter 100 KB erstellen.
Beste Rede, die ich je über „CSS-Best Practices“ gehört habe.
Genannt „CSS for Grown Ups: Maturing Best Practices“ von Andy Hume
http://schedule.sxsw.com/2012/events/event_IAP9410
Hören Sie es sich an, es wird Ihre (CSS) Welt auf den Kopf stellen!
Hier sind auch die Folien. :)
https://speakerdeck.com/u/andyhume/p/css-for-grown-ups-maturing-best-practises
Vielen Dank, sehr hilfreich :)
Die Hauptpunkte wurden hier behandelt. Es wäre interessant zu wissen, was jemand in diesem Thread von Folgendem hält
Aufteilung verschiedener Bereiche in separate Stylesheets und deren anschließendes Minifizieren zu einem, wenn die Website live geht – ich arbeite an einer Website, die auf Skeleton basiert, und die CSS-Dateien sind überall!
Organisation der Stylesheets in einer bestimmten Reihenfolge, d.h. alphabetisch
Werden diese als „Best Practices“ angesehen?
Danke!
Alphabetische Reihenfolge? Das ist lächerlich, man sollte sie nach Priorität organisieren.
Ich schreibe mein CSS seit kurzem als LESS. Für mich bedeutet das Schreiben von CSS auf diese Weise, dass meine Selektoren schlanker sind und insgesamt der Code leichter zu lesen und viel sauberer ist.
Ich vermisse ein weiteres !important-Indikator für _nicht so gutem_ CSS, das für mich sofort das Maß an CSS-Kenntnissen des Coders offenbart: das sind widersprüchliche Attribute. Ich stoße immer wieder auf so etwas wie `.left_img {float: left; clear: left;}` oder `div {display: block; display: inline;}` – das ist wirklich jemand, der nicht weiß, was er tut, und nur versucht.
Ein weiterer ähnlicher Indikator: Attribute, die sich selbst überschreiben, wie `.error{color: red; color: pink;}` – jedes Mal, wenn ich so etwas sehe, bekomme ich eine Art Schrecken, wenn ich mit diesem CSS weiterarbeiten muss. Es bedeutet, dass man nie genau weiß, wo Attribute gesetzt sind. Die Folge sind viel Debugging und Suche – Zeit, die besser hätte genutzt werden können.
Guter Gott, ich habe jeden einzelnen Kommentar gelesen und jedem Link gefolgt… mögliche Gehirnschmelze steht bevor…
Jedenfalls liebe ich all die Eingaben, aber für mich persönlich sage ich, dass die Verwendung von !important, wie sie ist, für mich zu 99,999999 % nur völlige Faulheit ist, und wie das Argument lautet, Kunden ist es normalerweise egal, sie wollen nur Ergebnisse und das so schnell wie möglich.
Ich nehme an, wenn ich es zum Überprüfen schreiben würde, würde ich sicherstellen, dass keine Instanzen vorhanden sind. Auf jeden Fall neige ich dazu, mich an eine solide Konstruktion zu halten, nicht für andere, sondern für mich selbst... Ich musste vor ein oder zwei Jahren Dinge ändern und habe früh gelernt, dass es mich wirklich in den Hintern beißen kann, wenn ich keine Art von System und sauberen Code habe.
Ausgezeichneter Artikel, ich liebe die Kontroverse ;-P
Der einzige Ort, an dem ich einen wirklich guten Nutzen für !important gefunden habe, ist im Druck.css
http://www.alistapart.com/articles/goingtoprint/
Ich bin mir beim Selektortest nicht sicher. Ich weiß, dass es bewährte Praxis ist, die Selektoren so kurz wie möglich zu halten, aber ich bevorzuge Korrektheit gegenüber Kürze.
Das Verkürzen des Selektors bedeutet entweder, das HTML mit zusätzlichen Klassen zu übersäen (Igitt) oder den Selektor weniger spezifisch zu machen. Dies wird zu einem Problem, wenn die HTML-Komponenten für neue und unvorhergesehene Elemente oder Partikel für neue Versionen oder Updates Ihrer Website erweitert werden. Plötzlich gilt der alte Selektor für mehr Elemente, als er beabsichtigt war, was ein klares und offensichtliches Rezept für eine Katastrophe ist. Dies wird zweifellos zu hässlichem und nicht wartbarem Code führen.
Daher prüfe ich lieber die Korrektheit des Selektors mit so vielen Überschreibungen wie möglich, anstatt kurze/knappe Selektoren.
Eine Sache, auf die man achten sollte, ist die Behandlung von IE – ignorieren sie es völlig?
Verwenden sie alte IE-Hacks? (wie den Unterstrich-Hack)
Verwenden sie Inline-Bedingungskommentare oder machen sie den niedlichen Trick, die IE-Klasse zum html-Tag hinzuzufügen?
Die Liste der IE-Hacks ist endlos. Das sind ein paar offensichtliche.
Hacks sind für mich schlimmer, da sie schwer zu finden und leicht zu übersehen sind
HTML-Klasse ist nett, da man sie an einer Stelle in sein Stylesheet einfügen kann
Dieser Artikel ist für mich unglaublich aktuell. Ich bin derzeit als Junior Frontend Dev angestellt. Dies ist meine erste reine Frontend-Rolle, was bedeutet, dass ich es schlucken musste, als Junior abgestempelt zu werden. Letzten Monat haben wir einen neuen Senior Frontend Dev eingestellt. Er wurde krank, also musste ich einspringen. Sein Code enthielt all diese Fehler und mehr. Ich kämpfe mich jetzt durch seinen Code und versuche, dieselbe Frist in der Hälfte der Zeit zu erfüllen, die er bereits hatte. Ich werde diesen Artikel an meinen PM weitergeben...
Wie andere bereits erwähnt haben, wenn man mit CMS-Plattformen mit Tonnen von Drittanbieter-Modulen umgeht, sind die Klassennamen und die HTML-Ausgabe oft tief in der PHP versteckt oder in ständig variierendem, vom Kunden bearbeitetem HTML, was es schwierig macht, die Struktur zu refaktorieren, um sie an das CSS anzupassen. Während dieser Ratschlag für viele andere Websites großartig ist – und einige der Ratschläge sicherlich für CMS-Stylesheets gelten –, sind einige der Redundanz und Spezifität ein notwendiges Übel, wenn es um das Theming mit ZEN-Stylesheets für Drupal geht, zum Beispiel.
Ich bin überrascht, dass http://www.slideshare.net/stubbornella/object-oriented-css noch nicht erwähnt wurde, obwohl er ziemlich oft zitiert wird.
Zusätzlich zu den oben genannten Punkten würde ich auch auf Folgendes achten:
1. Elemente in Regeln, die üblich sind und verschachtelt werden können, z.B. Stile wie
.mymodule div {}
besonders in Kombination mit `font-size`, was natürlich in relativen Einheiten sein sollte.
2. CSS, das zu Barrierefreiheitsproblemen führt
Wenn ein Element beispielsweise `position: absolute` hat, muss es im Browser überprüft werden, um sicherzustellen, dass es nicht über andere Elemente ragt, wenn der Text skaliert wird. Die Einstellung von Höhen in Pixeln und `overflow: hidden` muss ebenfalls im Browser überprüft werden, um Inhalte abzuschneiden, wenn der Text skaliert wird. Es gibt noch viele weitere rund um Konturen, Änderungen bei `:focus` sowie `:hover`, `display: none` vs. `position: absolute` und `left:-99999px` usw.
Und wenn Sie/andere nicht an den Aspekt der unternehmerischen Verantwortung glauben, dann denken Sie so: Der Code setzt Ihr Unternehmen und/oder Ihre Kunden der Klage aus.
3) Hintergründe, die sich nicht erweitern, wenn der Text länger wird
4) Die Nutzung der Kaskade nicht auszunutzen ist immer eine gute Sache.
5) Alternativ, die Wiederverwendung eines Stils, bei dem der Name des Stils Sie glauben lassen würde, dass er nur für einen bestimmten Bereich gilt. Haben Sie den `padding` in einem Stil geändert, der von Modul A verwendet wird, und dann feststellen, dass Modul B kaputtgegangen ist? Das war der Punkt.
@ Matthew J. Sahagian – Warum keine Klassennamen mit mehreren Wörtern? Sind Sie auf einer Camelcase-Kreuzzug oder haben Sie einen guten Leistungsgrund?
Ich verwende Camelcase für Skriptvariablen und Unterstrichelungen für CSS. Abgesehen davon, dass zwei verschiedene Programmierparadigmen vermischt werden, macht es meinen Code lesbarer.
bezüglich des „!important“-Problems… obwohl ich im Allgemeinen zustimme, gibt es Zeiten, in denen es eine gute Idee ist, z.B. bei Verwendung von @media-Abfragen für Bildschirmgrößen oder beim Drucken, um sicherzustellen, dass der Code überschrieben wird, unabhängig davon, was sonst noch vor sich geht oder was sich in Zukunft ändern mag.
Wie viele Leute haben ihr CSS minifiziert? Auf einer kleinen statischen 7-12 Seiten-Website wäre es das wert?
minifizieren, um eine schnellere Ladezeit zu erzielen, da die Dateigröße kleiner ist
Wenn Sie an großen Projekten arbeiten, minifizieren Sie!
Wenn es sich um ein Web handelt, bei dem Sie möchten, dass die Leute Ihren Code ansehen können, minifizieren Sie nicht, da Sie ihn lesbar machen möchten
Ich schlage vor, fehlerhaften CSS durch Tools wie CSSLint, CleanCSS, Chrome Inspector CSS Selector Profile oder Dust-Me Selectors laufen zu lassen, um Berichte zu erstellen, die zeigen, wie fehlerhaft die Stilregeln sind. Websitebesitzer werden die Ergebnisse eher nicht als Meinung abtun.
Toller Artikel. Es ist immer gut, dazuzulernen. Es braucht eine Weile, bis man sein eigenes System gefunden hat, das für einen funktioniert. Schlampiger Code ist nicht unbedingt auf einen faulen Designer/Entwickler zurückzuführen, sondern auf jemanden, der seine Nische noch nicht gefunden hat.
Ein toller Lesestoff, ich kämpfe mit der Verwendung von Vorlagen als Ausgangspunkt, es ist schwer, in die Gewohnheitszone eines anderen einzusteigen. Ich überlege, einige meiner eigenen Standardvorlagen zu erstellen, besonders mit all der Responsivität, die gerade stattfindet.
Guter Artikel, ich wünschte nur, mehr Entwickler würden „gute Programmierpraktiken“ befolgen.
WordPress-Themes sind ein Paradebeispiel, jedes Theme, an dem ich interessiert war, hat sehr „schmutzigen“ HTML- und CSS-Code.
Guter Artikel, ich denke, ein weiterer Test (und das könnte in den Kommentaren sein, ich habe nur die ersten Dutzend gelesen oder so) ist, wie das Ende der CSS-Datei aussieht.
Bei Websites, die schon länger online sind oder Websites, die Kundenfeedback-Runden durchlaufen haben, ist es interessant, unten nachzusehen und zu sehen, ob am Ende der Datei eine Reihe von Korrekturen angebracht wurden. Was bei einem großen Projekt oder einem langjährigen Kunden zu einer Reparatur nach der anderen werden kann.
Hier sind meine Ratschläge
Lebe dein Leben! Lass das Chaos regieren! Billiges, schmutziges CSS für immer!
Ein sicheres Zeichen für mich ist die Verwendung von **@import** in Produktions-CSS.
Auch wenn ich verstehe, dass bestimmte „Standards“ oder „Verhaltenskodizes“ angewendet werden müssen (erst einmal für die eigene geistige Gesundheit), muss ich hinzufügen, dass am Ende, solange alles gut aussieht, gut funktioniert, schnell funktioniert, alles gut ist. Wenn Sie tatsächlich in einem Team an einer Datei zusammenarbeiten müssen, sind einige Regeln wahrscheinlich sehr willkommen :D
Meine Gedanken dazu
http://cdn.memegenerator.net/instances/400x/17312350.jpg
Für diejenigen unter Ihnen, die sagen, sie sollen die !important-Deklaration niemals verwenden, haben Sie eindeutig nie versucht, mit der Modifizierung einiger Dojo-Themes zu arbeiten. Zumindest in < Dojo 1.5 ist ihr CSS mit unnötig langen Selektorketten und vielen !important’s durchsetzt. (Ernsthaft, die Dojo-Mitarbeiter haben keine Ahnung, wie man CSS schreibt.)
Und leider kann ich für die Dinge, an denen ich arbeite, die Basis-Dojo-Themes nicht entfernen, da dies zu viel Zeit in Anspruch nehmen würde, um die Stile, die wir verwenden, zu übertragen und sicherzustellen, dass die gesamte Anwendung immer noch funktioniert.
Natürlich ist das alles ziemlich subjektiv. Es gibt viele verschiedene Organisationsstile. Manche Leute alphabetisieren gerne alle Eigenschaften in einem Selektor. Persönlich gruppiere ich gerne zuerst Positionsdinge (Position, Display, Margins/Padding, Float usw.), gefolgt von Rändern, Farben und anderen Spezialeffekten, und schließe mit Textstilen ab.
Dies spiegelt wider, wie ich auf einer höheren Ebene ähnlich mit allgemeinen Regeln beginne, die das Gesamtlayout der Seite beeinflussen, und dann zu immer spezifischeren Elementen übergehe (was natürlich ist, angesichts der Funktionsweise der CSS-Kaskade).
Was das „schlechte“ Selektorbeispiel betrifft, das sah für mich nicht so schlecht aus. Ich kann mir leicht Anwendungsfälle vorstellen, wo das ein völlig gültiger Selektor wäre. Wenn man jedoch mehrere ID-Selektoren in einer Regel sieht (z.B. „#main #content #comments .foo“), beginne ich zu wundern. In einer CMS-gesteuerten Website kann dies manchmal notwendig sein, aber hoffentlich nicht. Ich sehe solche Dinge normalerweise nur in CSS, das von einem anderen Entwickler geerbt wurde, und/oder in Fällen, in denen eine Website mehrere Design-Überarbeitungen durchlaufen hat, ohne die Möglichkeit, alten Code zu verwerfen und von vorne zu beginnen. Was in realen Projekten leider üblich ist.
Ich respektiere IMMER einen Frontend-Entwickler, der zugibt, dass sein/ihr CSS perfekt ist. Machen wir uns nichts vor, wir haben wahrscheinlich alle unser altes CSS durchgesehen und festgestellt, dass Dinge anders hätten gemacht werden sollen. Ich weiß, ich habe das getan. Genauso wichtig ist ein CSS-Coder, der ständig versucht, seine Technik zu verbessern. Ein guter Maßstab dafür: wann haben sie zuletzt ihre Portfolio-Website neu aufgebaut? Ich arbeite seit ein paar Monaten an einer neuen Entwicklung/einem neuen Design für meine, basierend auf Dingen, die ich in den letzten 6 Monaten gelernt habe.
Für technischere Sachen, verwenden sie interessante Pseudo-Selektoren wie
usw. usw.
Verwenden sie globale Selektoren wie
Für mich zeigen diese Dinge ein besseres Verständnis dafür, wirklich über Struktur/Spezifität/zukünftige Modifikation/Entwicklung nachzudenken und viele der CSS-Regeln zu vereinfachen, die möglicherweise nicht benötigt werden.
Ein Entwickler, der zugibt, dass er kein perfektes CSS schreibt (besonders wenn er tatsächlich außergewöhnliches CSS schreibt), ist selten.
Ups… in der ersten Zeile meinte ich, dass ich einen Frontend-Entwickler respektiere, der zugeben kann, dass sein/ihr CSS NICHT perfekt ist.
hehe, ich habe etwas Ähnliches vermutet, als ich den Kommentar gelesen habe (sehen Sie, selbst Kommentare sind anfällig für einen winzigen Fehler, der die Bedeutung um 180 Grad ändern könnte :p) UND Sie haben einen Punkt, wenn es darum geht, „CSS zu begreifen“, während Sie fortgeschrittenere Selektoren verwenden. Leider sind diese nur für fortgeschrittenere Browser verfügbar, daher sollte dieses CSS nur verwendet werden, wenn Sie progressive Enhancement-Methoden anwenden. (oder eine jQuery-basierte imitierende CSS3 .js-Datei). So oder so, dieser Artikel hier berührt sicherlich einige sensible Saiten. (und ich bin auch der Erste, der zugibt, dass mein CSS nicht perfekt ist und es auch nie sein wird... Ich sehe CSS ein wenig als eine sich ständig weiterentwickelnde Art, Dinge zu tun, es ist ein lebendiges Wesen, das sich mit der Zeit entwickeln wird und viele verschiedene Ansätze für dieselben Probleme haben wird. Während ein Grundwissen davon einen Standard setzen mag, ist es letztendlich die „Hand“ oder „Signatur“ des Coders, die die wahre Beherrschung davon widerspiegelt. Und da es viele verschiedene Malstile gibt, wird es auch viele verschiedene Arten von Codierung geben. Das gesagt, wird dies wahrscheinlich nicht das letzte Wort zu dem betreffenden Thema sein.
@CiNiTriQs – Genau!
Sehr nützliche Liste zur Beurteilung von CSS. Es ist immer gut, etwas Neues zu lernen. Jeder Entwickler hat einen anderen Programmierstil und dieser Test kann hilfreich sein, um das CSS eines jeden Entwicklers zu beurteilen. Ich denke, Code sollte sauber und leicht lesbar sein.
Danke für diesen wunderbaren Beitrag :)
Für winzige Single-Developer-Projekte, bei denen die Person, die das CSS erstellt, es auch komprimiert und die Dateien auf den „Produktions“-Server hochlädt, könnten Sie es so beurteilen, aber dann ist der Mehraufwand, auf Best Practices abzuzielen, für solche Projekte wahrscheinlich verschwendet, und dann kann die Beurteilung beim offensichtlichen Test aufhören. CSS-Code enthält einfach nicht die trickreiche Geschäftslogik, die es wert macht, ihn so wartbar zu machen wie ein Kernsystem. Gute Entwickler haben genug Erfahrung, um zu wissen, wann sie Regeln brechen sollen, und ein Idiot, der einen Post auf css-tricks.com benutzt, um sie zu beurteilen, wird sich nur darüber beschweren, dass er keine guten Entwickler finden kann, weil diejenigen, die Code nach diesen Regeln schreiben, nicht diejenigen sind, die Probleme lösen können. Die Probleme, dass sie in Teams arbeiten müssen, mit einem anderen Programmierstil, als sie gewohnt sind, mit Legacy-Code, für eingebettete Browser, die schlechter als IE sind, mit unberührbarem HTML, CSS für SVG, mit einem knappen Budget und strengen Fristen usw. Code ist das Letzte, was ich bei der Einstellung von jemandem prüfe.
Aber das Fehlen eines Namespaces in Klassennamen ist ein Indikator…
Ich bin ein autodidaktischer Frontend-Entwickler und frage mich oft, ob mein CSS „gut“ ist. Das hilft mir definitiv einzuschätzen, wo ich stehe. Größtenteils bestehe ich! Ich denke, mein größter Fehler ist das Kommentieren, und ich benutze nicht oft Shorthands. Das war eine sehr schöne Lektüre, danke!
Ich habe erwartet, einen Abschnitt im Artikel über Browser-Hacks zu lesen?
Idiomatic CSS ist sehr gut; ich habe geholfen, es ins Französische zu übersetzen (also kenne ich es ziemlich gut) und glaube, dass es ein guter Ausgangspunkt ist.
Sie müssen nicht genau tun, was es sagt; es gibt Ihnen nur eine Vorstellung davon, wie Sie Dinge konsistent machen können, und bietet ein „bestes“ Beispiel.
Eine weitere Stimme für Idiomatic CSS. Es ist eine schöne kondensierte Referenz mit soliden Prinzipien.
Gibt es eine Möglichkeit, mit CSS alle !important Tags danach auszublenden, d.h. von den Bastarden, die Ihren Lebensunterhalt ruinieren wollen, indem sie Ihre Inkompetenz aufdecken?
Als Strafe für die Verwendung sollten die Leute tausendmal schreiben
.lazy-developer { use-!important-as-a-get-out-of-CSS-jail-free-card: none !important;}
Nicht wirklich, ich hasse es selbst, !important zu verwenden, aber die Struktur mehrerer CSSs und die unglückliche Art, wie sie in bestimmten (nicht zu nennenden) CMSs aufgerufen werden können, können bedeuten, dass es notwendig ist.
Ich verwende auch ein wenig important, um Responsive-Design zu überschreiben, verurteilen Sie mich nicht!
In praktisch allen Fällen wird important! nur von mir verwendet, wenn ich wirklich unter Zeitdruck stehe und keine andere Wahl habe =)