Während wir unsere jüngste Umfrage zur Reihenfolge von CSS-Eigenschaften abschließen, wirft dies die größere Frage nach CSS-Styleguides auf. Die Reihenfolge der Eigenschaften ist nur eine von vielen Entscheidungen, die Sie treffen müssen, um eine vollständige Styling-Strategie zu entwickeln. Namensgebung ist ein Teil davon. Gliederung ist ein Teil davon. Kommentare, Einrückung, allgemeine Dateistruktur… all das gehört zu einem vollständigen CSS-Styleguide.
Lassen Sie uns einige bestehende sammeln.
Aber zuerst… keine Pattern Libraries.
Ich **liebe** Pattern Libraries. Denken Sie an Twitter Bootstrap oder GEL. Ich denke, sie sind eine fantastische Arbeitsweise, insbesondere bei großen Websites und Webanwendungen. Dieser Beitrag handelt nicht davon. Wir werden eine Sammlung davon erstellen, denn das wäre meiner Meinung nach auch wertvoll. Es geht um Styleguides *für CSS selbst*.
Die Liste
Ich werde unten einige Auszüge aus jedem von ihnen auflisten, die mir gefallen.
GitHub
Als Faustregel gilt: Verschachteln Sie nicht mehr als 3 Ebenen tief. Wenn Sie feststellen, dass Sie weiter gehen, überlegen Sie, Ihre Regeln neu zu organisieren (entweder die benötigte Spezifität oder das Layout der Verschachtelung).
Einheitenlose Zeilenhöhen werden bevorzugt, da sie keinen prozentualen Wert ihres übergeordneten Elements erben, sondern stattdessen auf einem Vielfachen der Schriftgröße basieren.
Verwenden Sie ID- und Klassennamen, die so kurz wie möglich, aber so lang wie nötig sind.
Z.B. #nav statt #navigation, .author statt .atr
Verketten Sie Wörter und Abkürzungen in Selektoren nicht mit anderen Zeichen als Bindestrichen, um das Verständnis und die Lesbarkeit zu verbessern.
Z.B. .demo-image statt .demoimage oder .demo_image
Idiomatisches CSS
Idiomatisches CSS von Nicolas Gallagher →
Konfigurieren Sie Ihren Editor so, dass „Unsichtbare Zeichen anzeigen“ aktiviert ist. Dies ermöglicht es Ihnen, Leerzeichen am Ende der Zeile zu eliminieren, unbeabsichtigte Leerzeilen zu entfernen und Commits zu vermeiden, die unerwünschte Zeichen enthalten.
Lange, kommaseparierte Eigenschaftswerte – wie Sammlungen von Verläufen oder Schatten – können über mehrere Zeilen angeordnet werden, um die Lesbarkeit zu verbessern und nützlichere Diff-Dateien zu erstellen.
Verwenden Sie separate Dateien (die durch einen Build-Schritt verkettet werden), um Code für verschiedene Komponenten aufzuteilen.
CSS Wizardry
Ich habe ein pauschales Verbot für IDs in CSS. Sie haben buchstäblich keinen Zweck und verursachen nur Schaden.
Diese Abschnittsüberschrift wird auch mit einem $ vorangestellt. Das dient dazu, dass ich bei einer Suche nach einem Abschnitt tatsächlich nach
$MAINund nicht nachMAINsuche.
In Situationen, in denen es für einen Entwickler nützlich wäre, genau zu wissen, wie ein CSS-Code-Schnipsel auf ein HTML-Element angewendet wird, füge ich oft einen HTML-Schnipsel in einen CSS-Kommentar ein.
Smashing Magazine
Vitaly Friedmans „Improving Code Readability With CSS Styleguides“ →
Für große Projekte oder große Entwicklungsteams ist es auch nützlich, ein kurzes Update-Protokoll zu haben.
Für einen besseren Überblick über Ihren Code können Sie einzeilige Anweisungen für kurze Codefragmente verwenden.
ThinkUp
Wenn der Wert von Breite oder Höhe 0 ist, geben Sie keine Einheiten an.
Kommentare, die sich auf Selektorblöcke beziehen, sollten auf einer separaten Zeile unmittelbar vor dem Block stehen, auf den sie sich beziehen.
WordPress
WordPress CSS Coding Standards →
Fügen Sie zwei Leerzeilen zwischen den Abschnitten und eine Leerzeile zwischen den Blöcken in einem Abschnitt ein.
Breite Selektoren ermöglichen uns Effizienz, können aber negative Folgen haben, wenn sie nicht getestet werden. Ortspezifische Selektoren können uns Zeit sparen, führen aber schnell zu einer unübersichtlichen Stylesheet. Üben Sie Ihr bestes Urteilsvermögen.
Magische Zahlen sind unglücklich. Dies sind Zahlen, die als schnelle Lösungen für einmalige Zwecke verwendet werden. Beispiel:
.box { margin-top: 37px }.
SMACSS
Skalierbare und modulare Architektur für CSS von Jonathan Snook →
Diese Sache ist ein Biest und es wäre schwer, nur ein paar Zitate herauszugreifen. Aber…
Jeden neuen Stil, den Sie erstellen, am Ende einer einzigen Datei hinzuzufügen, würde das Finden von Dingen erschweren und wäre sehr verwirrend für alle anderen, die am Projekt arbeiten.
Wenn richtig gemacht, können Module leicht in verschiedene Teile des Layouts verschoben werden, ohne kaputt zu gehen.
Fügen Sie nur einen Selektor ein, der Semantik enthält. Ein Span oder Div enthält keine. Eine Überschrift schon. Eine Klasse, die auf einem Element definiert ist, hat reichlich.
Mehr?
Unterhält Ihre Organisation ein öffentliches Styleguide und nutzt es? Posten Sie es!
Früher habe ich meine CSS-Formatierung über mehrere Zeilen verteilt. Nachdem ich einen Ihrer alten Artikel über CSS-Formatierung gelesen hatte, bin ich jetzt ein Fan von einzeiliger CSS-Formatierung. Sie ist kürzer und schneller. Außerdem denke ich, dass die meisten Leute ihre eigenen Formatierungssysteme entwickeln.
Ich bin genau gleich. Jede Eigenschaft auf einer separaten Zeile zu haben, macht es meiner Meinung nach schwieriger zu lesen. Aber ich arbeite fast ausschließlich allein, wenn es um CSS geht.
Um eine Ihrer CSS-Eigenschaften zu ändern, sei es auf eine Klasse oder ID angewendet, müssten Sie nach links und rechts scrollen und sie visuell im Vergleich zu anderen in derselben Zeile finden.
In einer vertikalen Anordnung, und beispielsweise alphabetisch sortiert, können Sie Dinge leichter und schneller finden und ändern.
.class {color: #000000; background: #FFFFFF; font: 1em Arial, Helvetica, san-serif; font-style: italic; height: 150px; width: 500px;}
vs.
.class {
color: #000000;
background: #FFFFFF;
font: 1em Arial, Helvetica, san-serif;
font-style: italic;
height: 150px;
width: 500px;
}
„Ich habe ein pauschales Verbot für IDs in CSS. Sie haben buchstäblich keinen Zweck und verursachen nur Schaden.“
Keine wahreren Worte wurden jemals gesprochen.
Kann jemand das etwas besser erklären? Ich gehe davon aus, dass man stattdessen nur Klassen verwenden würde. Gibt es wirklich keine Vorteile von IDs?
Nach meinem Verständnis hat es eine quasi-!important-Wirkung auf Elemente. Wenn Sie #id verwenden, können Sie den Stil dieses Elements nicht überschreiben, es sei denn, Sie verweisen erneut darauf mit #id. Als Beispiel für einen Anwendungsfall…
Ich denke, das ist richtig :|
Ich denke, ein Argument für die Verwendung von IDs ist, dass sie Ihr CSS schneller rendern sollen. Chris schrieb einen Artikel darüber zu genau diesem Thema. https://css-tricks.de/efficiently-rendering-css/ Mir ist bewusst, dass der Artikel 2 Jahre alt ist, aber ich denke, er ist immer noch gültig.
Standardista erklärt es ziemlich gut mit dieser Grafik..
FWIW, ich stimme dieser Aussage überhaupt nicht zu. ID hat einen Zweck, und viele Male ist Spezifität kein Problem, sondern eine Lösung.
Ein pauschales Verbot von Tabellen hat die Leute bereits dazu gebracht, verrückte Ideen zu entwickeln… wie die Verwendung von Listen anstelle von Datentabellen. Stellen wir also sicher, dass wir nicht dasselbe mit IDs tun.
Ich sehe jetzt schon Leute, die Regeln wie diese verwenden
.someclass .someotherclass .yesanotherclass .canyoubelievethisisanotherclass .andyetonemore {…}
Autoren verwenden jetzt Klassen, um die Spezifität zu erhöhen, was die Leistung verringert, überladene Stylesheets erstellt usw.
Es gibt viel Gutes in IDs, und ich denke, es ist falsch, Leute vor ihrer Verwendung abzuschrecken.
Ok, verstanden – ich schätze, ich war mir dieses Konzepts etwas unbewusst, ohne mich wirklich damit auseinanderzusetzen. Ich habe mich immer daran gehalten, dass Container IDs sind und alles darin eine Klasse ist, und ich habe immer genutzt, wie IDs überschrieben wurden, um mir zu helfen, keine zusätzlichen Klassen erstellen zu müssen.
Also anstatt einer spezifischen h2-Klasse für den Header hätte ich definieren können, dass alle h2 im Header eine Farbe haben, die angezeigt wird. Vielleicht ist das schlechte Praxis und ich wusste es gar nicht, lol.
Ich muss @Thierry zustimmen. Ich denke, IDs sind unglaublich nützlich. Ich habe auch dieses „.class .class .class .class .class .class“-Ding bemerkt und mich gefragt, was es damit auf sich hat. Ich habe nicht wirklich verstanden, dass die Leute gegen IDs sind. Kann nicht sagen, dass ich das Argument nachvollziehen kann.
Ich bin ganz auf der Seite von „nie IDs verwenden“. Wenn Sie ein Spezifitätsproblem haben, ist die Verwendung eines Selektors, der *unendlich viel mächtiger* als eine Klasse ist, ein Vorschlaghammer, wenn Sie ein Skalpell brauchen (oder etwas Ähnliches, Sie wissen, was ich meine).
Chris,
Sie sagen
Bedeutet das, Sie gehen davon aus, dass die Verwendung von IDs ein Ergebnis eines Spezifitätsproblems ist? Denn ich denke, das ist weit von der Wahrheit entfernt. Viele Autoren verwenden IDs wegen ihrer Semantik – so wie es sein sollte ;-)
Wenn der Stil eines Elements **bestimmt** ist, eindeutig zu sein, wie ist dann **.logo** besser als **#logo**? Und ich sage nicht, dass man die ID verwenden soll, um eine Regel mit dem gesamten Stil für ein Element zu stopfen, ich sage nur, sie zu verwenden, um eindeutige Deklarationen einzuführen. Elemente mit IDs können durch eine Kombination von Regeln (über Typ, Klasse, ID, was auch immer) gestylt werden.
Beachten Sie auch, dass mein Beispiel das Wort „Logo“ verwendet, aber was passiert, wenn der Name allgemeiner ist (wie Klassennamen sein sollten) und das Projekt riesig ist? Dann können Autoren **nicht** sicher davon ausgehen, dass eine gegebene Regel für ein einzelnes Element spezifisch ist. Und von dort bricht das Ganze aus, weil sie Angst haben, etwas in dieser Regel zu ändern, und am Ende eine weitere Klasse einführen – nur um sicherzustellen, dass sie nicht mit einem anderen Element irgendwo auf einer anderen Seite der Website herumspielen.
Denken Sie auch nicht, dass Regeln wie die folgende ein ernsthaftes **Spezifitätsproblem** darstellen?
.class1 .class2 .class3 .class4 .class5 {…}
Ich sehe diese alle, und meiner Meinung nach ist das nicht besser als „fast alles mit ID zu machen“. Aber das Problem liegt in der Art und Weise, wie das Werkzeug verwendet wird, nicht am Werkzeug selbst.
Sie verwenden die Analogie mit dem „Vorschlaghammer“, also beende ich mit dieser:
Wenn alles, was Sie haben, ein Hammer ist, sieht alles wie ein Nagel aus!
Beste Grüße
Ich kann verstehen, was Sie meinen. Dennoch fallen mir immer noch Fälle ein, in denen die Referenzierung von Inhalten über eine ID eine schnelle und einfache Möglichkeit wäre, diese Inhalte anzusprechen und auch Teile der Seite zu „organisieren“. Sie sind großartig, weil sie *einzigartig* sind. Zumindest in meiner Erfahrung helfen sie mir, mich weniger überwältigt zu fühlen, ha!
Wenn Ihre automatisierten Testskripte, z. B. Watir-Webdriver, ID's sind brillant, um Elemente auf der Seite zu identifizieren.
Meine Meinung ist, dass IDs und Klassen beide ihren Platz haben und beide in Projekten verwendet werden sollten. Einige haben bereits erwähnt, semantisch ist #logo besser als .logo
Schließlich haben IDs einen bestimmten Zweck, nämlich einmal verwendet zu werden, um ein Element auf der Seite zu *identifizieren*. Klassen werden für Elemente verwendet, die mehr als einmal vorkommen, zum Beispiel könnten Sie einen #comment-thread haben und darin Elemente mit der Klasse .comment-body oder ähnliches.
Ich sehe keinen Vorteil darin, .comment-thread gegenüber #comment-thread zu verwenden, und wenn Leute Probleme mit dem Styling von Elementen darin haben, weil es eine ID ist, muss ich mich fragen, was Sie tun, da ich solche Probleme nie habe.
Nur meine Meinung ;-)
@Thierry,
Die meisten der von Ihnen vorgeschlagenen Beispiele sind schlechte Entwicklungsprobleme und keine Verwirrung darüber, wann eine ID angemessener oder weniger angemessen ist als eine Klasse.
Zum Beispiel hat ein Entwickler, der denkt, dass es ein pauschales Verbot für die Verwendung von Tabellen gibt, selbst für tabellarische Daten, ein tieferes Missverständnis der CSS-Spezifikationen als jede Codierungsmethodik beheben kann.
Auch, ich weiß, Sie haben es nur als Beispiel verwendet, aber etwas wie .class1 .class2 .class3 .class4 .class5 {…} ist nur die Verwendung von Klassen bis zum Äußersten, und ein Entwickler, der so etwas tut, wird wahrscheinlich genauso dazu neigen, ID-Namen für Spezifität zu missbrauchen und am Ende so etwas wie #header div #branding #logo img {…} zu haben.
@Sean,
Es scheint, Sie stimmen mir zu. IDs sind überhaupt kein Problem, es ist nur, wie die Leute sie verwenden.
@Thierry,
Ich stimme in dem Sinne zu, dass Klassen ihre eigenen Probleme mit sich bringen, aber ich verwende niemals IDs für meinen eigenen Code, und meiner Meinung nach erzwingen sie ein Spezifitätsniveau, das den Zweck des C in CSS zunichte macht. Die einzigen Male, dass ich IDs verwende, ist, wenn ich mich in einem Spezifitätskrieg mit einem 3. Plugin befinde, das seinen eigenen ID-gesteuerten maximalen CSS-Code versteckt hat, den ich neu gestalten muss.
@Sean,
„IDs erzwingen ein Spezifitätsniveau, das den Zweck des C in CSS zunichte macht.“
Ich könnte dieser Aussage mehr widersprechen. Wie wir alle wissen, steht C für Kaskade, die viele Dinge beinhaltet. Wenn wir das Gesamtbild betrachten, sind IDs kein Problem – sie sind Teil der Lösung.
Wenn „IDs schlecht sind, weil sie zu spezifisch sind“, warum vermeiden wir dann nicht, wann immer möglich, auch Klassen zu verwenden?
Vor Jahren dachte ich, der beste Weg sei, keine Hooks zu verwenden und stattdessen auf Nachfahrenselektoren zu setzen. Ich verwendete kaum Klassen, geschweige denn IDs. Zu dieser Zeit hätte ich mit jedem argumentieren können, dass die Verwendung von Klassen schlecht sei, weil „sie zu spezifisch sind“.
Genau dasselbe Argument höre ich heute über IDs…
Jedenfalls haben wir „Werkzeuge“, um eine Vielzahl von Herausforderungen zu bewältigen. Meiner Meinung nach ist es nicht klug, einige dieser Werkzeuge vollständig zu ignorieren.
Wir hatten die gleiche Diskussion in der Vergangenheit über „!important“. Ich lese viele, viele Male „verwende niemals !important!“
Ja, sicher :)
@Thierry,
Ich meinte ein Plugin eines Drittanbieters.
Ich sehe kein Problem mit der Verwendung von IDs in CSS. Haben Sie jemals an Dot Net-Anwendungen gearbeitet? Diese verwenden IDs für die Aufrufe in .vb oder c#, daher verwende ich manchmal diese vorhandenen IDs zum Stylen. Aber in Ihrem Fall würden Sie dann das Dokument aufblähen, indem Sie Klassen übergeben, um sie dann mit Ihrer CSS-Datei zu verbinden und die Ladezeit zu erhöhen? Was das Anordnen meines CSS angeht, füge ich normalerweise zuerst die Positionselemente dann die Box-Model-Sachen und dann die Text-Bits und dann die Präfixe ein.
.classHere{ float:left; position:relative; padding:8px; margin:16px 0 4px; background:#f8f8f8; color:#505050; -moz-box-shadow:1px 1px 1px rgba(0,0,0,0.8); -webkit-box-shadow:1px 1px 1px rgba(0,0,0,0.8); box-shadow:1px 1px 1px rgba(0,0,0,0.8); }Genau so. Ich denke, das hält alles in Ordnung und macht es leicht zu lesen.
@jamie,
Ich ordne mein CSS auch so an, normalerweise zuerst alle positionsbezogenen Deklarationen, dann Margin/Padding, dann den Rest. Es dauert mir zu lange, das Alphabet in meinem Kopf durchzugehen, um Dinge alphabetisch zu sortieren. Ich habe noch nie in .net gearbeitet, ich verstehe die Verwendung von IDs dort, sowie für Javascript, es ist nur für CSS, dass ich nicht von den IDs überzeugt bin, es sei denn, ich werde dazu gezwungen.
@Thierry, nun, jedem das Seine. Ich denke, das Wichtigste ist, konsistent zu sein und unseren Code zu dokumentieren, damit der nächste Entwickler leicht verstehen kann, was passiert, wenn er dem Projekt beitritt.
Ich habe meine Ansichten zu ID-Selektoren bereits anderswo geäußert.
Ich habe gerade einige Inhouse-CSS-Regeln für die Entwicklung unserer App hier bei Typecast geschrieben. Diese Regeln raten davon ab, dass IDs niemals für CSS verwendet werden sollten. Ich glaube fest daran, dass das Erstellen von CSS sich immer auf die **Wiederverwendbarkeit** konzentrieren sollte, es sollte darum gehen, Muster anstatt Einzellösungen zu schaffen. IDs sind von Natur aus einzigartig und widersprechen daher inhärent diesem Prinzip. Egal, wie oft Sie denken, dass Sie ein Muster nur einmal verwenden werden, irgendwann werden Sie es wieder brauchen.
Dieser Ansatz passt auch zu uns aufgrund der starken JavaScript-Interaktion in unserer App. IDs für die Backend-Entwickler zu lassen, hilft, Konflikte zwischen Design und Interaktion zu reduzieren, da unsere App wächst und sich verändert (was uns in der Vergangenheit Probleme bereitet hat).
Wie bereits einige Leute erwähnt haben, hängt diese Art von Entscheidung oft von der Situation und der Art des Projekts ab, an dem Sie arbeiten – was für uns funktioniert, muss nicht für jemand anderen funktionieren.
Natürlich ist der nächste spaßige Teil, diese Regel auf alle bereits geleisteten Arbeiten anzuwenden!
Es ist wirklich interessant, diese Konversation zu sehen, es ist eine dieser grundlegenden, Kernfragen, über die normalerweise nicht gesprochen wird, weil Leute an neuen Techniken oder Eigenschaften interessiert sind.
Aber ich würde mich auf die Seite der ID-Befürworter schlagen.
Ja, Klassen machen es wirklich einfach, denselben Code wiederzuverwenden, und das ist gut. Aber was, wenn es ein Element gibt, von dem Sie **wissen**, dass es auf jeder Seite einzigartig sein wird. Eines, das, wenn es zweimal auf der Seite vorkäme, ein Signal dafür wäre, dass etwas schief gelaufen ist (wie z. B. ein CMS, das seltsame Code-Schnipsel ausgibt).
Wenn Sie einen Container verwenden, um Ihre Webseite zu zentrieren, und wissen, dass Sie keine zwei
<div id="page-container">...</div>Elemente auf Ihrer Seite wollen, weil alles innerhalb dieses einzelnen Containers sein soll. Dann festigt die Verwendung einer ID dies im Code; wenn es zwei solcher Elemente gibt, gibt es möglicherweise eine Art visuellen Hinweis darauf, dass die Dinge nicht wie erwartet funktionieren.Dasselbe Beispiel kann auf den .logo/#logo-Punkt angewendet werden, den Thierry erwähnt hat. Bei den meisten Websites wissen Sie, dass Ihr Logo nur einmal auf der Seite verwendet wird, es sähe sonst seltsam aus. Wenn also zwei
#logo-Elemente auf der Seite sind, wissen Sie, dass bei der Generierung dieser Seite etwas schief gelaufen ist.Bei größeren Websites kann das anders sein, aber dann werden Sie, wie am Anfang des Artikels erwähnt, die Formatierung wahrscheinlich etwas anders angehen (Bibliothek, Präprozessor usw.).
Für kleine Websites sehe ich einfach kein Problem darin, etwas mit Überzeugung zu tun und zu sagen: „Ich weiß, dass es keine zwei Logos auf der Seite geben wird, lass uns das im Code festhalten.“
Nur meine Ansicht zu dieser Debatte…
Der ID-Selektor wird verwendet, um einen Stil für ein einzelnes, eindeutiges Element zu definieren.
Der Klassen-Selektor wird verwendet, um einen Stil für eine Gruppe von Elementen zu definieren. Im Gegensatz zum ID-Selektor wird der Klassen-Selektor am häufigsten auf mehreren Elementen verwendet.
Die ID kann in diesem Fall verwendet werden, um den Logo-Bereich oder -Abschnitt der Seite zu stylen.
Die Klasse hingegen kann mehrmals verwendet werden; zum Beispiel für jeden Text, der schwarz sein und einen weißen Hintergrund haben muss, wo er normalerweise rosa wäre.
Sehr nett. Ich habe immer Fragen und ich recherchiere immer, um mehr zu lernen und Dinge richtig zu machen. Chris ist es zu verdanken, dass ich jetzt gültiges XHTML und jetzt HTML5 schreibe (ich wüsste nicht, wie ich dieses verpassen soll).
Ich habe jedoch eine Frage, Sie sagten
Warum ist #fff nicht in Ordnung? Das habe ich nicht verstanden.
Eine Frage, die ich immer habe, ich mache das nie, weil ich denke, mehr Code ist nicht gut.
Aber ich hatte immer eine Frage dazu.
Ich mache stattdessen
Machen wir sie mit dem einfachen ‚ oder dem doppelten “ oder lassen wir sie einfach weg. Ich persönlich mache die doppelten.
Ich bin auch daran interessiert zu hören, warum #fff schlecht ist im Vergleich zu #FFF. Und ich mache dasselbe mit meinem Hintergrundcode (vernachlässige die Angabe von „-image“). Ich verwende jedoch ‚ ‘ statt „ “.
Ich denke, es geht mehr darum, den Code einheitlich zu halten, als dass er schlecht ist. Ähnlich wie in der Programmierung, wo sie sagen, entweder camelCase oder underscore_it verwenden.
Ich ärgere mich, wenn ich #FFF und #fff im selben Code sehe, oder sogar #FFFFF, was unnötige 3 zusätzliche Zeichen sind.
Fürs Protokoll: Es ist mir egal, ob FFF oder fff.
Nicht einmal wirklich wegen der Konsistenz.
Sie „lesen“ Hex-Codes nicht, also ist es einfach egal.
Für „#FFF“ vs. „#fff“ gibt es wirklich kein Problem, abgesehen vielleicht von der Konsistenz in Ihrem Code. Wir arbeiten hier mit Photoshop und Fireworks, sodass wir viele Variationen haben (PS nicht, FW aber kapitalisiert Hex).
Für einfache vs. doppelte Anführungszeichen in CSS behalte ich immer einfache Anführungszeichen aus einem Grund: Wenn ich später CSS in JavaScript/jQuery hinzufügen/bearbeiten muss, spart mir das Mühe beim Escaping meiner Anführungszeichen.
Das gilt natürlich nur, wenn Sie doppelte Anführungszeichen für Strings in JavaScript verwenden (was ich tue).
vs.
Farben werden durch die Kombination von ROTEN, GRÜNEN und BLAUEN Licht (RGB) dargestellt. Die Kombination von Rot-, Grün- und Blauwerten reicht von 0 bis 255 und ergibt mehr als 16 Millionen verschiedene Farben zur Auswahl (256 x 256 x 256).
Die meisten modernen Monitore können mindestens 16384 verschiedene Farben anzeigen, und bei der hier verwendeten RGB-Darstellung bezieht sich dies tatsächlich auf RRGGBB – ein Hex-Wert, der als 3 zweistellige Zahlen geschrieben wird, beginnend mit einem # Zeichen. Je mehr Ziffern/Buchstaben verwendet werden, desto genauer kann man seine Farbpalette definieren.
Farben in CSS können mit den folgenden Methoden angegeben werden: Hexadezimal, RGB, RGBA, HSL, HSLA oder vordefinierte/browserübergreifende Farbnamen (rot, pink etc.).
Was die Großschreibung angeht, verwenden W3C, Photoshop, Colorzilla, Kuler usw. normalerweise Großschreibung, ähnlich wie Unicode geschrieben wird. Es beeinflusst nicht, wie die Farbe interpretiert wird, und kommt lediglich auf Ästhetik und Kompression an.
__
Ihr Hintergrundproblem ist ein Problem mit langen im Vergleich zu Kurzschreib-Eigenschaftsdeklarationen. Wenn Sie beispielsweise ein Muster verwenden würden, das sich wiederholt, müsste eine andere CSS-Regel angewendet werden.
Hier ist ein Beispiel für die Schriftarteigenschaft.
Was auch so geschrieben werden kann.
__
Gemäß den Empfehlungen des W3C werden URI-Werte (Uniform Resource Identifiers, zu denen URLs, URNs usw. gehören) mit dem Wert url( gefolgt von optionalem Leerraum gefolgt von einem optionalen einfachen oder doppelten Anführungszeichen gefolgt von der URI selbst, gefolgt von einem optionalen einfachen oder doppelten Anführungszeichen gefolgt von optionalem Leerraum gefolgt von ) formatiert. Die Verwendung von einem oder keinem ist in Ordnung, jedoch müssen die beiden Anführungszeichen gleich sein.
@Karl und Jonathan Graft. Ein Grund, *nicht* zu verwenden
anstelle von
ist, dass „background“ *alle* verschiedenen Optionen für Hintergründe definiert, einschließlich background-image und background-color, auch wenn Sie sie nicht angeben. Ich weiß nicht mehr, ob das funktionieren wird
aber ich weiß mit Sicherheit, dass dies nicht funktionieren wird.
Im zweiten Fall überschreibt die „background“-Anweisung die „background-color“-Anweisung. Ich gebe sie fast immer separat an, wenn ich sowohl ein Bild als auch eine Farbe für den Hintergrund eines bestimmten Elements verwende. Oder auch wenn nicht, gebe ich sie normalerweise so an, falls ich in Zukunft eine oder die andere hinzufügen muss. Mag übervorsichtig erscheinen, aber das ist meine Meinung.
Ich habe zwei Punkte, die mir wichtig sind…
1) CSS-Regeln gehen in eine Zeile. Warum? Wir alle verwenden Breitbildmonitore und wir verwenden sie nicht im Hochformat, warum sollten wir nicht mehr von dem horizontal verfügbaren Platz nutzen, um mehr von unserem CSS auf einer Seite zu sehen?
Wenn ich wirklich lange Stylesheets sehe, die nur wenige Zoll horizontalen Platz nutzen und Sie nur wenige Regeln auf einmal auf dem Bildschirm sehen können, treibt mich das in den Wahnsinn.
2) Ich bevorzuge dies…. {width:80px; height:80px;} gegenüber diesem… {width : 80px; height : 80px;}
Ich weiß, dass es hier nicht wirklich sehr anders aussieht, aber in einer Monospace-IDE tut es das. Wenn man Leerzeichen vor und nach dem Doppelpunkt lässt, gibt es keine visuelle Gruppierung zwischen Eigenschaft und Wert. Die 80px „gehören“ zur Eigenschaft „width“ und sollten daher damit gruppiert und von der Eigenschaft „height“ getrennt werden. Das macht es einfach, Eigenschaften schnell zu lesen und zu finden.
Ich stimme auch der Nichtverwendung von IDs zu. Ich habe aufgehört, sie zu verwenden, und habe weniger Spezifitätsprobleme.
Wenn Sie in einer Versionskontrollumgebung arbeiten, scheiden einzeilige CSS-Dateien aus, da sie Diffs nutzlos machen. Dies, kombiniert mit CSS3-Herstellerpräfixen, bringt mich fest zurück ins „mehrzeilige“ CSS-Lager. Ich hatte früher genau die gleichen Empfindungen, also fühle ich mit Ihnen.
Ich habe festgestellt, dass mehrzeiliges CSS höflicher gegenüber den Leuten war, mit denen ich zusammengearbeitet habe.
Ich habe versucht, auf eine Zeile umzusteigen, und in einigen Fällen werde ich es auf eine Zeile beschränken (wenn ich nur 1 oder 2 Attribute definiere und es nie mehr als das sein wird).
Aber ich fand es frustrierend, dass jeder unterschiedliche Arbeitsweisen hatte und es anders umbrach. Die Arbeit in mehreren Zeilen sorgte dafür, dass jeder das Gleiche sah.
Ich mag die Idee, dass eine Zeile mehr passt, aber sie ist unpraktisch. Als Webentwickler/Designer machen wir uns oft Sorgen darüber, wie lang eine Textzeile in unserem fertigen Produkt sein wird, damit sie vom Benutzer leicht gelesen werden kann. Warum sollten Sie sich dann zwingen, Zeilen zu lesen, die die volle Breite eines 20″+ Monitors ausdehnen? Ganz zu schweigen davon, dass es nicht wie Text in einem Artikel ist, wo man seinen Platz anhand von Kontext und dem gerade Gelesenen aufrechterhalten kann.
.class1{height:10px; width:20px; border: 1px solid #ccc; display:block; float:left} .class2{height:20px; width:20px; border: 1px solid #eee; display:block; float:left} .class3{height:20px; width:20px; border: 1px solid #ccc; display:none; float:right} .class4{height:10px; width:10px; border: 1px solid #ccc; display:block; float:left}Dies ist schwer zu lesen (durch die Formatierung im Kommentarsystem hier erleichtert) und das sind nur etwa 60-70 Zeichen breit.
Ich liebe den GitHub Style Guide :) Ich glaube, es war der erste, in den ich mich gestürzt habe, als ich anfing, mich ernsthaft mit CSS zu beschäftigen.
Mir gefällt es, das einzige, was mich wirklich stört, ist die Verwendung von 2 Leerzeichen anstelle eines Einzugs. Wahrscheinlich nur persönliche Vorliebe.
Ich stimme vollkommen zu! Mein Codierungsstil ist Tab zum Einrücken, immer schon, immer bleiben.
Interessant, dass sie 2 Leerzeichen gewählt haben. Ich bin kürzlich vom harten Tab zum weichen Tab übergegangen, da ich festgestellt habe, dass er auf verschiedenen Plattformen und Editoren besser funktioniert (ein Leerzeichen ist ein Leerzeichen, während Tabs seltsam sein können). Aber ich verwende 4 Leerzeichen, die typischerweise einem Tab entsprechen.
Aber ich finde, dass 2 Leerzeichen etwas unordentlich sind, es sieht aus, als hätte jemand versehentlich die Leertaste mehr als beabsichtigt gedrückt :\.
Zwei Leerzeichen scheinen mir auch seltsam, ich habe gerade darüber gelesen, um zu sehen, was andere sagten. Ich weiß, dass der Thread zwei Jahre alt ist. Tab ist eine Taste, die zuverlässig den gleichen Abstand erzeugt, während die Verwendung von tatsächlichen Leerzeichen mehr Raum für Fehler/Unordnung lässt – die Präferenz für Leerzeichen ergibt für mich keinen Sinn. Außerdem kann man mit Notepad++/ Textwrangler/Dreamweaver auch große Blöcke einrücken, was es einfach macht, zurückzugehen und Dinge zu organisieren, die man vergessen hat, zu formatieren, während man an letzten Stilen gearbeitet hat.
Aber vielleicht kommt die Anforderung für Leerzeichen aus Situationen, in denen Tabs problematisch sind? Es scheint, dass das Beste wäre, „Tab“ so einzustellen, dass es Leerzeichen erzeugt (anstelle von Tabs) im gewählten Editor. Endlos die Leertaste zu drücken, treibt mich in den Wahnsinn, aber ich mag es auch nicht, wenn die Dinge nicht ordentlich ausgerichtet sind, also wäre es wirklich ärgerlich, keine Ein-Knopf-Leertaste zu haben.
Möglicherweise der erstaunlich hilfreichste Beitrag zur richtigen Zeit. Ich bin gerade dabei, einen Styleguide zu schreiben und benötigte einige Bezugspunkte.
Glücklicherweise stimme ich der Mehrheit der von jedem Autor erwähnten Punkte zu.
In den meisten Fällen ja, aber für Layout-Optionen ganz oben sind IDs meiner Meinung nach nicht schlecht. Denken Sie an
#headerund#footer, die wären hier in Ordnung, da sie einzigartige Komponenten der Seite sind. Aber ich verstehe, was Harry meint.Aber bisher habe ich beim Lesen wenig über die Verwendung von Kurzschreibweisen wie
backgroundoderpaddinganstelle vonbackground-coloroderpadding-leftpadding-rightin den Fällen erwähnt, in denen nur die Langform für Spezifität verwendet wird und die Kurzform für die meisten anderen Fälle verwendet wird. (Etwas, das ich meiner hinzufügen werde!).Ich würde gerne mehr über CSS/LESS/SASS-Dokumentationstools sehen; ist KSS die einzige wirkliche Option, die derzeit verfügbar ist, oder ist automatisierte Dokumentation nicht so beliebt? Persönlich sehe ich es als ein ziemlich großartiges Werkzeug, um bei jeder Version des Seitenstils ein geradliniges Dokument zu erstellen, um zu verstehen, welche Stile wo aufgerufen werden. (Ich weiß, dass man einfach die CSS-Dateien ansehen könnte, aber bei größeren Websites wäre dies am nützlichsten).
WordPress hat auch seinen eigenen kurzen CSS-Styleguide
http://codex.wordpress.org/CSS_Coding_Standards
Oh Mist, das habe ich vergessen. Ich habe jedoch die neueste Version (nicht die Codex-Version) gefunden und sie in den Artikel aufgenommen.
Danke für die Aufnahme des WordPress-Beitrags aus dem Handbuch – ich habe die Codex (Wiki)-Seite jetzt gelöscht, um stattdessen auf diese Seite zu verweisen. Es scheint nicht sinnvoll zu sein, sich entwickelnde Standards an zwei Stellen zu pflegen :)
Selbst wenn ich verstehe, warum IDs schädlich sein können, glaube ich nicht, dass sie verbannt werden müssen. Sie können sehr nützlich sein, nur nicht unter allen Umständen.
Tolle Zusammenfassung auf jeden Fall Chris, gut, so gute Ratschläge zu CSS zu sehen. Besonders gefällt mir der von Nicolas Gallagher.
„Verwenden Sie ID- und Klassennamen, die so kurz wie möglich, aber so lang wie nötig sind.“ Wenn Sie in einem Team arbeiten, ist das super wichtig. Zu kurz und es ist bedeutungslos, zu lang und es ist ärgerlich.
Kann ich Dave nur zustimmen. Menschen lesen auch Style Sheets! Hoffen wir und beten wir für einen Tag, an dem Benennungskonventionen ebenfalls geschätzt werden.
Enthalten diese Styleguides eine feste Reihenfolge für die Auflistung von Eigenschaften? Der nervigste Aspekt der Arbeit an den Style Sheets anderer Leute ist die erratische und inkonsistente Platzierung von Eigenschaften.
Der Google Styleguide empfiehlt alphabetisch geordnete Deklarationen, ich habe noch nicht alle anderen gelesen.
http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml#Declaration_order
Meine persönliche Präferenz ist Typ –> alphabetisch. Nach Typ meine ich, dass ich Eigenschaften irgendwie in Kategorien einteile:
Layout: innerhalb der Seite wie (display, float, etc.)
Form: Breite, Höhe, etc.
Stil: Rand, Abstand, Polsterung, etc.
Text: Schriftgröße, Schriftfamilie, etc.
Und alphabetisch innerhalb dieser Gruppen. Obwohl ich heutzutage mehr in OOCSS einsteige, habe ich diese in separate Klassen zur Wiederverwendbarkeit aufgeteilt.
Diese Arten von Beiträgen sind immer interessant. Es ist immer gut zu wissen, wie andere Leute coden, um zu überprüfen, ob man etwas besser machen kann.
Sie haben Starbucks Style Guide übrigens verpasst.
Das ist eine Pattern Library, keine CSS Style Guide =)
Hawidu CSS's Syntax Guide leitet das Projekt. Leute hassen vielleicht den Stil, den es verwendet, aber für mich ist er großartig.
Die Idee hinter dem Hawidu CSS-Framework ist, dass ein [funktionierendes] Projekt eine einzelne Datei sein würde, die so nah wie möglich an minifiziert ist und dennoch lesbar bleibt. Projekte in diesem Stil vermeiden die Kaskade, verwenden Attribute außer Klasse/ID zum Stylen, wenn es vernünftig ist, und fügen die Finesse nur hinzu, wenn sie benötigt wird.
Tolle Referenz. Da ich neu im Web bin und mich gerade selbst unterrichte, ist es großartig, verschiedene Ideen zum Stöbern zu haben, um nicht nur zu sehen, wie andere Leute etwas tun, sondern auch, was ich tun würde, und zu vergleichen. Danke. Es wäre großartig, dies aktualisiert und erweitert zu sehen.
Ich denke, diese ist etwas älter, aber wahrscheinlich immer noch gut.
http://na.isobar.com/standards/
Und sie deckt mehr als nur CSS ab. Und dann gibt es diese Liste auf Gimmebar.
https://gimmebar.com/collection/4ecd439c2f0aaad734000022/front-end-styleguides
Ich erinnere mich nicht mehr, wer das zusammengestellt hat… Irgendjemand eine Ahnung? Wieder wahrscheinlich mehr als nur CSS, aber sicherlich relevant für diesen Beitrag.
Was ist mit Anführungszeichen bei Bildreferenzen?
wp
.class { /* Korrekte Verwendung von Anführungszeichen */
background-image: url(“images/bg.png”);
font-family: “Helvetica Neue”, sans-serif;
}
Google
/* Empfohlen */
@import url(//www.google.com/css/maia.css);
html {
font-family: ‘open sans’, arial, sans-serif;
}
Nur Haussestyle?
Bildanführungszeichen sind optional. Schriftfamiliennamen mit Leerzeichen *erfordern* Anführungszeichen; einfach oder doppelt – es spielt keine Rolle.
Hilfreiche Informationen. Danke fürs Teilen.
Ich bin mir nicht sicher, ob nur Bindestriche verwendet werden sollten, um Wörter in Ihren Selektoren zu trennen. Zum Beispiel fühle ich bei der Verwendung eines OOCSS-Ansatzes, dass es notwendig ist, das Modul, seine Variationen, seine Komponenten usw. durch Namenskonventionen zu trennen. Zum Beispiel…
.link-list { }
.link-list_item { }
Hier verwende ich einen Unterstrich, um anzuzeigen, dass das Element „link-list_item“ eine Komponente oder ein Teil ist, aus dem eine „link-list“ besteht.
Grundsätzlich denke ich, dass dies das Verständnis von CSS verbessert, da alles nur Bindestriche sind. Es ist einfach zu erkennen, wie die Elementhierarchie basierend auf der Namenskonvention ist, und dies hat mehr Vorteile als Nachteile.
Schön. Das werde ich anfangen zu verwenden.
Ich verstehe, warum Sie IDs nicht verwenden möchten, aber die Schwierigkeit pauschaler Aussagen von Experten, dass sie niemals verwendet werden sollten, muss vielleicht qualifiziert werden. Es gibt derzeit eine ziemliche ID-Hexenjagd, und ich bin nicht überzeugt, dass sie in der realen Welt vollständig umsetzbar ist.
Zum Beispiel gibt es meiner Meinung nach Zeiten, in denen die Verwendung einer ID als Selektor am praktischsten ist (ich denke an die Arbeit mit einem CMS, bei dem die Änderung des Markups praktisch nicht möglich ist). Ich habe auch nichts dagegen, sie zu verwenden, um Dinge einzustellen, die sich nie ändern werden (z. B. Basisstile wie #sidebar in einem Design).
Zusammenfassend lässt sich sagen, dass die Verwendung von Klassen vorzuziehen ist und „Best Practice“ ist, und man sollte die Auswirkungen der Verwendung von IDs als Selektoren verstehen, aber keine Angst haben, dass die Welt untergeht, wenn das eine oder andere auf diese Weise gestylt wird. Es gibt oft weit größere Fische zu braten!
Ben, Sie sagten
Vielleicht liege ich falsch, aber meine erste Reaktion darauf ist, dass, wenn das CMS keine praktische Möglichkeit hat, das Markup zu ändern, und IDs zu diesen unberührbaren Elementen hinzufügt und keine Klassen, dann klingt das nach einem wirklich schlechten CMS. Im Allgemeinen fügen CMSs Klassen hinzu (wie WordPress es tut), keine IDs, oder zusätzlich zu IDs.
Kennen Sie ein CMS, das nur IDs hinzufügt und Ihnen die Änderung des Markups nicht erlaubt? Ich habe nicht genug Erfahrung mit verschiedenen CMSs, aber das scheint nicht oft, wenn überhaupt, vorzukommen.
Hallo Louis, im Prinzip stimme ich Ihnen vollkommen zu, aber manchmal ist es leicht, Dinge in einem schlechten Licht darzustellen, basierend auf Elfenbeinturm-Idealismus. Ich hatte schon viele Fälle, in denen ich mit Organisationen zusammengearbeitet habe, die ihr eigenes (begrenztes) CMS-System haben.
Die ganze Welt läuft nicht auf aktuellen CMS (oder sogar Open-Source)-Systemen, und es gibt viele Kunden und Institutionen, die Legacy-Systeme betreiben, die Ihnen keine Kontrolle über bestimmte Bereiche des Markups geben.
Selbst wenn Sie könnten (eine Klasse anstelle einer ID verwenden), denke ich immer noch nicht, dass die Wahl einer ID anstelle einer Klasse eine Todsünde des CSS-Schreibens darstellt. Wie bei allem anderen im Web werde ich zum Klischee „es kommt darauf an“ zurückgreifen.
Harry Roberts hat auch das
https://github.com/csswizardry/CSS-Guidelines/blob/master/CSS%20Guidelines.md
Aber ich habe keine Ahnung, wie ähnlich/unterschiedlich dieses zu dem ist, das Sie im Beitrag verlinken…?
Lead FrontEnd Dev @biemedia.com…
Verwendung eines Teils aus dem Beitrag +
Wenn JavaScript-Events mit CSS gestaged werden (:target – onclick, :hover, :focus (vorzugsweise mit Übergängen natürlich), deklarieren Sie diese Blöcke in neuen, gut dokumentierten Abschnitten mit einem offensichtlichen Referenzkommentar im Basisabschnitt/Block. Da ID-Blöcke meist unnötig sind, reservieren Sie sie für Feinabstimmungen, *wenn* überhaupt notwendig. Zusammen mit dieser Methode
Konstruieren Sie Ihr HTML/CSS so, dass Sie Ihre CSS-Abschnitte nachahmen können, wie JavaScript-Singletons und Ihre CSS-Blöcke als Unterklassen – das bedeutet: lassen Sie Ihr CSS so aussehen wie JSON (ein universell verstandenes Muster), wie möglich. Dies beinhaltet scheinbar unnötige Iterationen von Elterklassen, um Ihren Code semantischer/selbstdokumentierender zu halten.
Z.B.: .parent .child .babyClass{}. ODER: .parent .child, .parent .sibling{}. NICHT: .babyClass{} oder .sibling{}.
Machen Sie so viel GUI-Design wie möglich in CSS (nach eigenem Ermessen :-)), und versuchen Sie, JavaScript für reines DOUI (ausgesprochen: Dough-EE: Data-Oriented UI) zu reservieren. Dies trennt die Logikverarbeitung von der grafischen Darstellung, aber Sie können JavaScript immer verwenden, um Ihr CSS zu überschreiben.
Sehr wichtig: Die Verwendung von CSS :before/:after mit dem content-Attribut kann Ihnen ersparen, ein Event zwischen CSS und JavaScript zu verdoppeln, nur um eine grafische Änderung (CSS) und eine Textänderung (nicht HTML) (mit JavaScript innerHTML) hinzuzufügen.
Es ist auch „!important“, zu wissen, wann man falsch liegt.
„Wenn der Wert von Breite oder Höhe 0 ist, geben Sie keine Einheiten an.“
Dieser Satz, da stimme ich Ihnen zu.
Sie haben vergessen, den Link zum Google Style Guide einzufügen. http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
Meine persönlichen CSS-Styleguides: css.thenew.fr (http://css.thenew.fr)
Das ist großartiger Stoff. Ich schaue mir gerade GitHubs an, und es hat einige sehr gute Richtlinien. Besonders gefällt mir die Art und Weise, wie sie ihre Formulargestaltung erklären. Ich hatte schon immer Schwierigkeiten, richtige, strukturierte Stylesheets zu erstellen.
Ich stimme zu, wen kümmert FFF oder fff.
Bezugnehmend auf den ganzen Aufwand wegen Klassen statt IDs…. Ich wurde immer gelehrt, Klassen zu verwenden, wenn ein Element mehrmals verwendet werden muss, für alles andere wie #wrapper und #header verwende ich IDs. Es gibt Fälle, tatsächlich erst neulich, als ich ein bestimmtes Element überschreiben musste und es nicht konnte, weil ich eine ID über diesem Element verwendet habe. Sind dies die Anwendungsfälle, bei denen wir einfach in den sauren Apfel beißen und diese ID in eine Klasse ändern sollten? BTW großartiger Artikel, er hat definitiv einige Gespräche angeregt.
Danke für die Sammlung, ich kannte 1 oder 2 davon, aber wirklich danke dafür :)
Test.
Ich habe gerade getestet, was passiert, wenn Sie einen Kommentar mit Inline-Stilen einreichen, da diese in der Kommentarvorschau angezeigt werden. Sie werden beim Einreichen entfernt :)
Das ist die Php strip_tags()-Funktion, die so etwas entfernt, glaube ich. Sie hilft zu verhindern, dass Leute Skripte auf Ihrer Seite ausführen. Sie wären überrascht, was für kreative Dinge Leute mit JavaScript machen.
Das einzige, was mir fehlt, ist ein perfekt geformtes Beispiel.
Geben Sie uns einfach die beste Praxis für CSS-Codierung. Wie das hier
Außerdem… was ist besser?
oder
Und warum?
Ich stimme auf jeden Fall dem Update-Log zu, wie vorgeschlagen. Als Softwareberater bin ich auf zu viele Unternehmen gestoßen, bei denen es keine Update-Logs gab und keine Möglichkeit herauszufinden, wie sie Change Management handhaben. Übrigens – IDs sollen auch CSS schneller rendern.
Tatsächlich haben IDs und Klassen unterschiedliche Rollen, mein Konzept ist in der Online-CSS-Bearbeitung in Mozilla klar.
Ich stimme mindestens einer Aussage von allen zu. Einer, mit dem ich nicht einverstanden bin, ist die „Einzeilen-CSS-Aussage“. Sie ist überhaupt nicht lesbar und macht Ihre Datei nur breit. Das Schreiben jeder CSS-Aussage in theoretischen Abschnitten würde die Dinge für das Boxmodell, die reine Formatierung (Schrift, Farbe) und spezielle Effekte (border-radius, Gradient) klären. Das würde es Ihnen und jedem, der das Stylesheet nach Ihnen anfasst, erleichtern.
Ich glaube nicht, dass das behandelt wurde, aber #id’s sind sehr nützlich als Hooks für Ihre Javascript-Funktionen. Es ist viel besser als die Verwendung von .classes und dem Navigieren im DOM mit unhandlichen Selektoren. Ein pauschales Verbot ist nicht notwendig, aber es ist wichtig, sie an den richtigen Stellen einzusetzen.
Habe das Gleiche wie Harry für meine Coding-Richtlinien in HTML und CSS getan.
Ich liebe die Idee, einen guten Code-Styleguide zu haben und sich daran zu halten. Das passiert mit JavaScript und anderen Programmiersprachen seit Jahren und endlich kommt es zu HTML und CSS. Fantastisch.
Hier ist ein Link zu meinem Blogbeitrag übrigens.
(Ich konnte meinen Kommentar nicht bearbeiten, sorry.)
Und hier ist meine Follow-up-Richtlinie (inspiriert von Harry und Hans habe ich meinen Stil niedergeschrieben): Mein Coding Style und Richtlinien.
Der CSS Wizardry Artikel ist schrecklich, ich kann kaum erklären, warum man IDs in seiner Webseite verwenden sollte! Verweisen Sie einfach nicht auf sie in Ihrem CSS. Sie gar nicht erst hinzuzufügen, ist wirklich schlechte Praxis, da es Entwicklern nicht erlaubt, leicht mit Elementen zu interagieren.
Die allgemeine Faustregel ist, dass Sie IDs auf eindeutige Elemente und Klassen auf wiederverwendbare Elemente anwenden. Ein Schritt besser als das ist es, allen eindeutigen Elementen IDs zuzuweisen, sie aber mit einer Klasse zu stylen. (Grundsätzlich kein Styling auf ID-Elementen)
Also im Grunde Ihren HTML mit IDs aufblähen, die Sie nicht verwenden?
Es scheint, jeder hat unterschiedliche Meinungen (auf die wir alle Anspruch haben), aber ich kann immer noch nicht verstehen, warum Leute IDs hassen. Wenn Sie Probleme damit haben, dass sie etwas weiter unten überschreiben, nähern Sie sich wahrscheinlich nicht von der richtigen Richtung? Niemand kann das wirklich sagen, ohne einige Beispiele der Probleme zu sehen.
IDs helfen, CSS schneller zu rendern, wie bereits erwähnt, sie sind großartig für JavaScript (beim Auswählen von Elementen), da sie effizienter sind als Klassenauswahl. Sie sollten nur auf eindeutige Elemente angewendet werden (wie sie vor HTML5 waren, IDs von Header, Footer usw.).
Sie erwähnten auch „nach allgemeiner Faustregel“, dass IDs auf eindeutige Elemente und Klassen auf wiederverwendbare angewendet werden, schlagen Sie mich, wenn ich falsch liege, aber ich bin ziemlich sicher, dass es so gemeint ist (gültiges HTML und so …).
Das ist wieder meine Meinung ;-)
Einige der vorgestellten Regeln funktionieren für mich nicht.
Ich halte mich an die offiziellen Empfehlungen von WHTWG und W3C CSS WG.
Nun, das war lustig. Ich habe lange gebraucht, um eine gut argumentierte Antwort zu verfassen, habe versucht, sie abzuschicken, und wurde unhöflich darauf hingewiesen, dass die Felder Name und E-Mail ausgefüllt werden mussten. Wie wäre es mit einer Art Warnung, *bevor* ich auf „Absenden“ klicke? Und dann, wie wäre es mit einer Möglichkeit, meinen Fehler zu beheben, anstatt mich dazu zu zwingen, auf den „Zurück“-Button zu klicken und alles neu einzugeben?
Entschuldigung, aber ich werde meine Zeit nicht damit verschwenden, alles noch einmal zu tippen, also haben Sie meine weisen Worte verpasst. Ihr Verlust.
Tolle Tipps hier. Die Anwendung dieser Methoden macht die Neuerstellung eines Stylesheets deutlich effizienter.
Hier ist eine Seite mit Frontend-Entwicklungsrichtlinien, die ich für unser Unternehmen erstellt habe, da wir Entwickler an mehreren Standorten haben und Best Practices über alle unsere Projekte hinweg standardisieren wollten, sowie um Gespräche darüber zu führen, wie wir Frontend codieren sollten. http://www.sessiondigital.com/frontend/
Ein paar Tage zu spät zu dieser Konversation, aber ich habe ein Styleguide/Pattern-Library-Framework aufgebaut und pflege es.
https://github.com/Anotheruiguy/toadstool
Die Konzepte sind einfach: Nutze das Framework, um deine eigene Pattern-Library aufzubauen und nutze die vorgefertigten Ansichten für die schnelle Entwicklung des Styleguides.
Sei gewarnt, es befindet sich im Alpha-Stadium und ist selbst in schneller Entwicklung. Aber es gibt tolle Ideen, die man daraus mitnehmen kann, wenn man interessiert ist.
ID-Selektoren in CSS verwenden oder nicht verwenden.
Ich denke, ein wichtiger Punkt fehlt in der Konversation, die ich zum Thema ID-Selektor gesehen habe: Code-Wiederverwendung.
Per Definition wird eine ID nur auf einem einzigen Element auf einer Webseite verwendet; dies steht diametral im Gegensatz zur Code-Wiederverwendung.
Durch die Verwendung gut durchdachter Klassen und wiederverwendbarer Komponenten können Sie Websites mit einer kleineren CSS-Codebasis erstellen, mehr Konsistenz im Erscheinungsbild, einfacher zu warten und zu debuggen, und es wird schneller, neue Seiten zu erstellen.
In der Programmierwelt gibt es ein Konzept namens DRY (Don't Repeat Yourself - Wiederhole dich nicht). Ein einfaches Beispiel wäre die Berechnung eines Gesamtbetrags auf einer E-Commerce-Website; Sie haben möglicherweise viele Seiten oder Seitenleisten, auf denen er angezeigt wird. Er sollte in eine gemeinsame Funktion abstrahiert werden, die alle diese Stellen aufrufen, um einen Gesamtbetrag zu berechnen. Wenn also etwas auftritt, wie eine Änderung der Art und Weise, wie die Steuer berechnet wird, nehmen Sie die Änderung an einer Stelle vor und sie gilt für alle mit einem stark minimierten Risiko, eine zu übersehen oder einen Tippfehler in nur einer zu haben, der unbemerkt bleibt. Diese Art von Code-Wiederverwendung kann in CSS durch gut durchdachte Klassen erreicht werden; es macht das Leben einfacher.
Der Punkt ist, dass es kaum einen Grund gibt, IDs in CSS zu verwenden. Wenn die Selektorstärke Ihr Grund ist, dann haben Sie ein größeres Problem mit übermäßig aggressiven Selektoren irgendwo anders in Ihrem CSS; dies ist ein Band-Aid-Anwendungsfall.
IDs haben zwar einen nützlichen Zweck auf einer Webseite, aber ihre primäre Nützlichkeit liegt in JavaScript. Die Fähigkeit, ein eindeutiges Asset in einer Liste ähnlicher Assets zu identifizieren. Sie möchten zum Beispiel genau wissen, auf welches Miniaturbild ein Benutzer geklickt hat, bevor eine größere Version des Bildes in einem Lightbox angezeigt wird. Ihre Nützlichkeit schwindet mit dem Aufkommen von HTML5 data-something-Attributen, aber es war ein wertvolles Werkzeug zur Individualisierung von Elementen.
Mein zweisender Vorschlag ist also: Wenn Sie #logo in Ihrem CSS verwenden, sollten Sie stattdessen .logo verwenden können. Wenn Sie das nicht können, ist das ein Warnsignal dafür, dass Sie andere Teile Ihres CSS nicht gut genug durchdacht haben.
Sie sagen, es sei in dieser Konversation übersehen worden, und doch war eines der Hauptthemen die Spezifität (was bedeutet, ein Objekt zu spezifisch zu machen, so dass es nirgendwo anders verwendet werden kann, was dasselbe ist wie Code-Wiederverwendung).
Ich habe es schon einmal gesagt und sage es wieder: Warum .logo gegenüber #logo verwenden? Sie sparen kein Platz in CSS, weil Sie es immer noch genau so stylen müssen, wie Sie es mit einer ID tun würden. Es ist verständlich, wenn ein Logo mehr als einmal vorkommt, aber meistens tut es das nicht. Daher gilt die Code-Wiederverwendung in diesen Fällen nicht, da man keine Funktion für etwas schreibt, das man in der Programmierung nur einmal tut (wie z. B. das Ausloggen, es kann an mehreren Stellen auf einer Website vorkommen, aber es geht oft zum selben Ort, also keine Notwendigkeit für eine Funktion).
Durch die Verwendung einer Klasse über einer ID in Fällen, in denen keine Notwendigkeit besteht (Oder der vermeintliche Bedarf, dass IDs wegen Spezifität und Code-Wiederverwendung sinnlos sind, wenn das tatsächlich nicht zutrifft), wurde bereits festgestellt, dass Klassen in CSS nicht so effizient sind wie IDs, und dasselbe gilt für die Auswahl von Elementen mit JS.
Kurz gesagt: Für Einzelfälle (wie die meisten Logos, Holder usw.) verlieren Sie nichts, wenn Sie eine ID verwenden (Nein, nicht einmal Code-Wiederverwendung), aber Sie erhalten leichte Leistungsschübe (die sich summieren können!).
Ist das ein benutzerdefinierter Beitragstyp?
Außerdem wäre es nützlich, BEM zur Liste hinzuzufügen
http://bem.github.com/bem-method/pages/beginning/beginning.en.html
Ich stimme nicht zu
Ich schreibe immer das
Warum? Wegen Chrome Web Inspector, ich kann Pfeiltasten nach oben/unten verwenden, wenn ich px habe, aber es wird nicht automatisch 'px' hinzufügen, wenn ich nur 0 habe, also wird es das Element nicht bewegen. Gleiches gilt für Abstände und Polster.
Das ist eine großartige Sammlung von Gedanken und Methoden!
Vor langer Zeit habe ich lange und intensiv über die Deklarationsreihenfolge nachgedacht (wahrscheinlich mehr, als als „gesund“ gilt). Anstatt zu einer alphabetischen Reihenfolge zu gelangen, die ziemlich logisch ist, kam mir die Idee, Deklarationen in einer hierarchischen Reihenfolge zu schreiben.
Deklarationen, die Dinge wie Position, Stapelreihenfolge und die Auswirkungen von Objekten auf andere Objekte beschreiben, kamen zuerst, gefolgt von der Dimension des Objekts, dem Rahmen, dem Polster und der Hintergrundanzeige. Von dort aus würde ich alle Eigenschaften schreiben, die sich mit dem Inhalt innerhalb des Objekts befassen, wie z. B. Schriftfamilie oder Farbe. Dies erlaubte mir, das Verhalten des Objekts von einem globalen zu einem spezifischen Kontext aus zu betrachten.
Es funktioniert auf dem Papier... manchmal.
Laut Paul Irishs Beitrag auf HTML5Rocks über How Browser Works erwähnte er, dass das CSS-Rendering von rechts nach links erfolgt. Für jedes Element geht die CSS-Engine jedes Mal die gesamte Stylesheet durch, um nach dem angegebenen Element zu suchen, sobald sie das Element gefunden hat (über ID, Klasse, Tag oder universellen Selektor), bewegt sie sich zu ihrem linken Selektor und prüft das übergeordnete Element. Wenn das übergeordnete Element richtig ist, geht sie weiter und die Stile werden angewendet. Ich habe einen Blogbeitrag dazu geschrieben, der den gesamten Prozess erklärt.
Dies beweist also, dass die Leistung einer Seite verbessert wird, wenn keine Verschachtelungsebenen vorhanden sind, was in komplexen Apps hilfreich sein kann. Z.B. Wenn Sie sich den CSS von GMail ansehen, werden Sie keine Verschachtelungsebenen finden. Jede Klasse und ID ist in der gesamten App eindeutig. Auch wenn sie maschinell generiert sind (ich weiß nicht wie).
Dies führt uns zu den Richtlinien von GitHub und Google Code zur Spezifität und Namenskonvention. Google schlägt vor:
während GitHub Spezifität fördert. Dies wirft die Frage auf, wie Namenskonventionen durchgeführt werden sollten, um beide Richtlinien zu erreichen? Ist Smurf-Namen hier ideal, z.B.
.container-preview { ... }anstatt etwas wie
.container .left-container .preview { ... }Mit Smurf-Namen werden zwar aussagekräftige, aber wirklich lange Namen generiert, die schließlich störend werden. Gibt es eine andere Möglichkeit, dieses Problem zu lösen?
PS Kann mir jemand sagen, wie GMail diese CSS generiert?
Ich denke, die Lösung für das Problem wurde schon seit einiger Zeit von SASS vor langer Zeit gelöst.
Wenn einige Leute es vorziehen, ihre Arbeit in X-Format zu erledigen, aber am Ende des Tages das allgemeine Format Y haben möchten, können Sie Sass importieren lassen, was auch immer sie bevorzugen, und die eigentliche Produktions-Stylesheet in einer Vielzahl von Formaten haben, wie z. B. komprimiert, einzeilig, was auch immer.
Noch besser, es konvertiert einfach, was bereits existiert, in ein anderes Format, wenn diese Person in Millisekunden geht.
Auf diese Weise können Styleguides eingehalten werden, ohne dass ein Arbeiter oder jemand wirklich darüber nachdenken muss, die Art und Weise zu ändern, wie er die Stylesheets liest oder erstellt, was letztendlich Zeit verschwendet, die anderweitig für das verwendet werden könnte, was wirklich am wichtigsten ist: Die Website ist gestylt und leistet auf eine Weise, die ihren Zweck für Benutzer maximiert.
Ich kümmere mich nicht wirklich um IDs oder Klassen. Meiner Meinung nach sollte es nur einen Stiltyp geben und alles sollte seinen eigenen eindeutigen Namen haben. Aber so hat W3C die Dinge nicht eingerichtet. Jetzt haben sie noch mehr Elemente geschaffen (header, nav, footer usw.). Diese Elemente haben auf einer Seite das gleiche Gewicht wie html und body. Meiner Meinung nach ist das nicht gut oder richtig. Nicht jede Seite im Internet hat einen Header oder Footer oder sogar eine Navigation. Es kann eigenständige Landingpages geben. Jede Seite im Internet hat jedoch einen Body, der in HTML enthalten ist.
Daher sollte alles andere auf der Seite eine „Klasse“ sein (was nicht unbedingt die aktuelle CSS-Klassendefinition bedeutet), sondern nur ein Stil, der deklariert ist. Und alles auf der Seite sollte seinen eigenen eindeutigen Namen für einen Stil haben, obwohl er überall wiederverwendet werden kann. Im Moment kann man einen Stil wie #nav .nav haben. Das sollte man nicht tun können.
Ich glaube nicht, dass IDs oder Klassen die Dinge einfacher machen. Sie sind nur verwirrender und mit Dingen wie Header und Footer macht es das noch verwirrender.
W3C (und Menschen im Allgemeinen) machen die Dinge zu komplex. Alle versuchen seit Jahren, Seiten zu vereinfachen, aber dann werden immer wieder seltsame zufällige neue Elemente hinzugefügt, um die Dinge komplexer zu machen.