- In einem Q&A-Artikel auf Smashing Magazine habe ich eine Frage beantwortet, wie man CSS betrachtet und feststellt, ob es gut oder schlecht ist.
-
Harry Roberts erläuterte meine Antwort mit vielen spezifischeren Beispielen für schlechte Dinge, die man in CSS finden kann (z. B. magische Zahlen, qualifizierte Klassen, zu vage Selektoren). Harry sagt in diesem Artikel:
Verwenden Sie IDs in HTML für Fragment-Identifikatoren und JS-Hooks, aber niemals in CSS.
- Jeffrey Zeldman reagiert darauf und verteidigt die Verwendung von IDs. Jeffrey vergleicht die Aufgabe von IDs mit OOCSS und der Vermeidung von Nachfahrenselektoren.
- Wir haben Jeffrey im ShopTalk zu Gast, um das zu diskutieren. Wir verbringen nicht zu viel Zeit mit Uneinigkeit – sondern konzentrieren uns auf eine viel größere Übereinstimmung: zu dogmatisch bei diesen Dingen zu sein, ist die schlimmste Haltung überhaupt.
- Völlig zufällig haben wir nächste Woche Harry Roberts im ShopTalk zu Gast.
Jetzt bin ich wieder dran. Ich liebe es zu bloggen.
Ich habe das Gefühl, wenn sich jemand über Harrys oder andere Artikel aufregt, dann weil er manchmal dogmatisch wirkt. Wenn Ihnen dieser Begriff nichts sagt, denken Sie einfach daran als unflexibles Denken. So ist das eben, verdammt, und basta. Starke Meinungen zu haben ist großartig, unflexible sind es nicht. Darüber zu schreiben, was für Sie funktioniert, ist großartig, über unveränderliche Manifeste zu schreiben, nicht.
Ich habe Harry getroffen. Er ist ein netter Kerl. Ich bin mir nicht sicher, wie dogmatisch er in seinem Denken ist (ich bezweifle es stark). Das werden wir im ShopTalk besprechen.
Jeffrey bezeichnete die Anweisung, dass IDs niemals verwendet werden sollten, als „Unsinn“.
Sagen Sie es mit mir: Es ist nichts falsch daran, eine ID zu verwenden, wenn sie angemessen verwendet wird (semantisch, strukturell, sparsam). Es gibt viel Falsches an der Vorstellung, dass Klassen immer Klassen vor Nachfahrenselektoren und semantischen, strukturellen IDs vorzuziehen sind.
Das kommt mir genauso nahe an Dogmatismus heran wie Harrys Aussage. Und ich bin da auch schuldig. Ich habe darüber in meinem Artikel „Eine Linie im Sand, eine Geschichte über deftiges Chili und die Verwendung von Klassen“ geschrieben.
Ich werde keine IDs zum Stylen von Dingen verwenden. Kein Kompromiss. Selbst wenn eine ID kurzfristig rettend erscheinen mag, sind die langfristigen Vorteile, sie niemals zu verwenden, größer.
Die vollständige Vermeidung von IDs hat mir zu einer besseren Erfahrung beim CSS-Authoring verholfen. Wahrscheinlich hätte ich es mehr so formulieren sollen, aber naja.
Ich habe das Gefühl, Jeffrey denkt, dass die Vermeidung von IDs bedeutet, alles andere zu überklassen, auf die Kaskade zu verzichten und keine intelligenten Selektoren zu verwenden, die sauberen Markup fördern. Ich glaube nicht, dass IDs etwas mit diesen Dingen zu tun haben. Überklassen ist dumm, das sollte man nicht tun, und man sollte nicht denken, dass das OOCSS bedeutet (ich denke daran wie: finde ein Muster, gib diesem Muster eine Klasse). Die Kaskade ist immer noch nützlich, aber in begrenztem Umfang. Man könnte argumentieren, dass sie genauso viel schadet wie nützt. Und schließlich bin ich ganz auf Nachfahrenselektoren eingestellt. Sie funktionieren gleichermaßen gut mit Klassen wie mit IDs. Besser, würde ich argumentieren, da die Klasse wiederverwendbar ist.
Ich habe auch das Gefühl, dass Jeffrey eine tiefere Perspektive darauf hat als Harry oder ich. Wie wir im ShopTalk-Podcast besprochen haben, hat Jeffrey einige Ären durchlaufen, in denen Markup extrem hässlich war, und hat dazu beigetragen, ein Zeitalter des sauberen Markups einzuläuten, das wir heute gewohnt sind. Ich kann verstehen, dass er nervös wird, wenn er das Gefühl hat, dass die Dinge sich in die andere Richtung bewegen.
Ich bin ständig in Situationen, in denen ich eine Single-Page-Website erstelle, die eine kurze Lebensdauer hat. OOCSS ist für einige Dinge großartig, aber für kleine Projekte mit schneller Abwicklung ist es manchmal einfach zu viel.
Ich weiß, dass es gut ist, Best Practices zu verwenden, aber manchmal muss man sich auf das verlassen, was im Notfall funktioniert.
Auch wenn ich es zweimal in meinem Kommentar geschrieben habe, schreibe ich es noch einmal. Ich meine manchmal. IDs müssen nicht die ganze Zeit tabu sein.
Aber warum überhaupt eine ID verwenden? Eine Klasse, die man nur einmal verwendet, erfüllt denselben Zweck, außer dass man später keine Kopfschmerzen hat, wenn das Projekt erweitert wird. Selbst wenn das Projekt nie erweitert wird, haben Sie nicht mehr Zeit oder Mühe aufgewendet, als eine Klasse zu verwenden, oder?
@Scott, ich benutze IDs schon lange nicht mehr, aber ich stimme Zeldman zu, wenn es darum geht, eine Praxis, die noch funktioniert, dogmatisch abzulehnen. Alle Websites, die ich erstelle, sind seit zwei Jahren responsiv, aber es stört mich nicht, wenn andere etwas Fixed-Width erstellen.
Tabellenlayouts funktionieren immer noch…
Es könnte eine gute Idee sein, ein Styleguide für sich selbst zu erstellen, auf dessen Grundlage man Websites erstellt; ähnlich wie Bootstrap, aber nicht so voll ausgereift, da man nicht seine ganze Zeit damit verbringen möchte, Unmengen von Stilen neu zu schreiben.
http://larrybotha.github.com/styleguide/
Löschen Sie, was Sie nicht benötigen, wenn Sie mit einem Projekt beginnen, testen Sie, wie alles aussieht, bevor Sie es implementieren, und setzen Sie dann Ihre Website einfach wie ein Puzzle zusammen. Es ist beängstigend, wie schnell eine Website Gestalt annimmt, sobald die Mehrheit der Elemente bereits angeordnet ist.
Wesley,
Ich bin mir nicht sicher, ob ich Ihnen zustimme. OOCSS ist genauso schnell, wenn nicht sogar schneller für mich. Im Allgemeinen ist es eine gute Gewohnheit, Ihr CSS auf diese Weise zu machen. Vererbung ist Ihr FREUND! Selbst bei kleinen Projekten wird das Begrenzen von Dingen mit IDs unübersichtlich, besonders wenn Sie dazu neigen, Ihren Code wiederzuverwenden. Die ID-Begrenzung ist für mich tatsächlich wichtiger bei Enterprise-Websites, wo es unbekannte CSS-Klassen unter Ihrem Code gibt und Sie nicht möchten, dass sie kollidieren. (Dies kann immer noch mit OOCSS vermieden werden, aber dann muss man manchmal geschickter mit seinen Namenskonventionen umgehen.) Meiner Meinung nach haben beide ihren Platz.
Für mich ist es schlichte Überoptimierung. Es ist falsch, keine ID zu verwenden, nur aus der Möglichkeit heraus, dass man sie „vielleicht“ wiederverwendet.
Während eine ID einzigartig ist und in Ordnung ist, muss man, sobald man dupliziert, optimieren und eine KLASSE verwenden, aber nur für relevante Aspekte.
Wenn Sie also alles im Sinne von OOCSS schreiben, mit der Idee, es überall wiederverwenden zu können, dann sind Klassen sicherlich der richtige Weg.
Fall Sie nur nicht in die Gewohnheit der vorzeitigen Optimierung verfallen.
„Vorzeitige Optimierung.“ Klingt für mich nach fauler Entwicklung.
„Schreiben Sie Ihren Code immer so, als ob derjenige, der Ihren Code später wartet, ein gewalttätiger Psychopath wäre, der weiß, wo Sie wohnen.“ – John Woods
Es geht nicht nur darum, dass wir den Stil „vielleicht wiederverwenden“, sondern darum, dass wir Muster in den Designs gefunden haben und uns entschieden haben, Klassen zu verwenden, die für einzelne Instanzen angewendet und erweitert werden können, anstatt die gleichen 4 Deklarationen für 10 verschiedene Selektoren zu wiederholen.
Ich habe das alles mitverfolgt, seit Harry seinen Artikel neulich gepostet hat. Ich habe großen Respekt vor Jeffrey, doch er scheint die Ansicht zu vertreten, dass die Verwendung von IDs anstelle von Klassen semantischer ist. Das stimmt jedoch nicht, da der Browser aus dem Inhalt der ID keine Informationen gewinnt.
Harry mag manchmal dogmatisch wirken, aber immer aus unglaublich begründeten Gründen. Die CSS-Architektur hat sich in den letzten Jahren stark verändert, daher brauchen wir Leute, die sagen: „So muss es gemacht werden, und hier sind die Beweise dafür.“ Ich habe das Gefühl, CSS wird weniger zur Verantwortung des Designers und fällt mehr in die Hände von Leuten, die Konzepte wie OOCSS vollständig verstehen.
Ich bin sehr daran interessiert, Harrys ShopTalk-Episode zu hören.
Ich springe kurz mal rein und sage:
Danke Mann, das bedeutet mir viel :)
Ich denke, ich bin ziemlich *zuversichtlich* in meinem Denken; ich verbringe meine gesamte Arbeitszeit damit, CSS zu skalieren, CSS für große Teams zu schreiben, die an Websites arbeiten, deren Entwicklung Monate (wenn nicht Jahre) dauert. Ich habe viel Überzeugung in meinem Denken und bedauere sehr, dass es als Dogmatismus rüberkommt.
Ich habe auf die harte Tour gelernt, wie mich IDs in sogar den unwahrscheinlichsten Umständen gestolpert haben, wo lose und verschlungene Selektoren zu Refactoring-Aufgaben von einem halben Tag geführt haben, wo es wenige Sekunden dauern hätte sollen.
Dies aus erster Hand zu erleben und zu umgehen, ist etwas, das ich (zu sehr?) gerne teile, denn erst wenn man merkt, wo man sich selbst Arbeit macht, erkennt man, wie viel einfacher die Dinge sein können.
Ich arbeite wohl in einem Umfeld, in dem es sehr wichtig ist, dass Regeln durchgesetzt werden, weil ich gesehen habe, wie Dinge ausarten, wenn es keine gibt. Wenn ich in meinem Tagesgeschäft nicht so offen und zuversichtlich in meiner Meinung wäre, hätte ich *wirklich* Schwierigkeiten damit.
Ich freue mich sehr darauf, morgen im Shop Talk zu plaudern.
Viele Grüße,
H
Ein großartiges Werkzeug, um den richtigen Gebrauch eines Werkzeugs/einer Technik zu lernen, ist, es ständig zu verwenden. Benutzen Sie es, bis es wehtut. Dies ist eine Technik, die mein Vater anwandte, als er mir beibrachte, Stockcar zu fahren. Er ließ mich immer schneller in die Kurve fahren, bis ich mich drehte. Das identifizierte, wie schnell ich fahren sollte, und lehrte mich auch die Konsequenzen.
Ich denke, Zeldman trifft es auf den Punkt mit „Jedem Absatz-Element in der Seitenleiste eine Klassenbezeichnung zu geben, ist nicht nur eine unnötige Verschwendung von Bandbreite, sondern auch schlechter Stil.“ Aber was ist, wenn man niemals auf seinen ausgegebenen HTML schaut? Macht es dann wirklich einen Unterschied?
Das Bandbreitenproblem ist hinfällig. Ich meine, jeder benutzt doch GZIP (oder?), also macht das Hinzufügen von 10 identischen Zeichenketten praktisch keinen Unterschied. (Wenn Bandbreite ein so großes Problem ist, warum ermutigt Zeldman dann „semantische“ ID-Namen? Sie sollten alle nur 2 Zeichen lang sein.)
Das eigentliche potenzielle Problem ist einfach, dass Sie durch das Hinzufügen von mehr Code Ihren Code hässlicher und möglicherweise schwerer zu lesen und zu debuggen machen. Dennoch ein eher geringfügiges Problem meiner Meinung nach.
Zusammenhängender Twitter-Thread
Das ist genau die Verwirrung, die existiert. Es ist letztendlich keine Debatte darüber, ob man IDs verwendet oder nicht. Sie koexistieren im selben Ökosystem und dienen unterschiedlichen Zwecken. Für kleine bis große Projekte neige ich dazu, OOCSS zu verwenden, da es gut für die Gewohnheitsbildung und die Wiederverwendung von Code ist. Auf der anderen Seite gibt es auf großen Websites, an denen man nicht gearbeitet hat oder deren zugrunde liegender Code unbekannt ist, wahrscheinlich eine gute Chance, dass Ihre geliebte „.text“-Klasse bereits für etwas anderes verwendet wird. Daher können IDs nützlich sein, wenn Sie Ihr CSS *spezifisch* mit der Absicht, es nicht zu teilen und eigenständig zu halten, eingrenzen möchten.
Ich denke, solange Sie Ihren Code aus einem bestimmten Grund auf eine bestimmte Weise schreiben und nicht nur, weil Sie blind jemandem folgen oder ihn irgendwo kopieren und einfügen, ohne ihn zu verstehen, ist es in Ordnung.
Der OOCSS- und der SMACSS-Ansatz sind großartige Richtlinien, aber manchmal muss man die Regeln brechen, um ein bestimmtes Problem in einem Projekt zu lösen.
Ich verstehe die ID-Phobie auch nicht. Ja, in Bezug auf JS – es ist nicht sicher, dieselbe ID für mehrere Elemente zu verwenden, aber das bedeutet nicht, dass man sie nicht benutzen darf. Es ist wirklich dumm, „überzuklassen“.
Ich verstehe auch die „Tabellen“-Phobie nicht :) Ebenfalls extrem dumm.
Off-Topic – wie bekommt ihr eure Avatare? Muss ich mich in der Lodge anmelden?
Gehen Sie zu Gravatar.com.
Das Zusammenstellen einer großen Website mit IDs ist die schlechteste Erfahrung, die man sich antun kann. Ich war dort, und das ist der Schwerpunkt der Arbeit von Harry Roberts.
Die Nichtverwendung von IDs rührt von den Albträumen her, die IDs in CSS verursachen.
Ich bin mir nicht sicher, worauf sich Ihre Aussage bezieht, aber auch hier wird der Versuch, flexible Stile zu schreiben, die skalieren, ohne modulare Methoden beim Schreiben Ihres CSS zu verwenden, zu einem Albtraum.
Wie definieren Sie „Überklasse“? 3 Klassen? 5 Klassen? 10 Klassen? Gibt es eine magische Zahl für die Anzahl der Klassen, die Sie einem Element zuweisen können, oder ist Ihre Begründung tiefer, dass die Anzahl der Klassen vielleicht vom Kontext, der Häufigkeit des Vorkommens dieses Elementtyps und der Modularität des Standardzustands des Blocks abhängt?
Dies ist wieder ein Problem, das aus der Erfahrung im Erstellen großer Websites resultiert.
John Lueders – danke :) hat funktioniert
Larry Botha – große Websites – ja. Und trotzdem passiert es manchmal, dass man eine ID für JS setzen muss. Warum eine neue Klasse deklarieren, wenn man einfach ihre ID verwenden kann. Der Punkt ist, dass man sich nicht einschränken sollte. Es heißt nicht – man sollte IDs überall verwenden :)
Hallo Chris, ich stimme Ihrer allgemeinen Meinung über Dogmatismus in der Webdesign-Branche voll und ganz zu. Ich denke nicht, dass es sich nur darauf beschränkt, wie man CSS macht – wir sehen es an vielen Stellen, insbesondere im Hinblick auf mobile und responsive Webdesign. Ich frage mich, ob Sie diesen Artikel gelesen haben: CSS Architecture von Philip Walton? Soweit ich weiß, schlägt er vor, die Kaskade weniger zu nutzen und spezifischer mit Klassen zu sein und komplizierte und generische Selektoren zu vermeiden. Dieser CSS-Schnipsel aus seinem Artikel veranschaulicht, was er meint.
Viele Grüße, Mark
Ich würde argumentieren, dass diese Art von Praktiken *nicht* darin besteht, die Kaskade weniger zu nutzen, sondern besser zu verstehen, wie sie funktioniert.
Ich stimme diesem Teil des Artikels vollkommen zu. Manche Leute interpretieren ihn so, dass sie jeder einzelnen Elementklasse hinzufügen müssen (wie eine Klasse zu allen
<p>-Tags hinzufügen), aber meiner Meinung nach geht es nicht darum. Es geht darum, Styling von Markup zu entkoppeln. Idealerweise möchten wir ein Stylesheet erstellen, das nicht geändert werden muss, wenn wir eine Markup-Änderung vornehmen, zum Beispiel die Entscheidung, eine Reihe von divs für eine Navigation anstelle von Listenelementen zu verwenden. Das würde wahrscheinlich nicht passieren, aber ein Problem, das ich kürzlich hatte, war die Erstellung einer flexiblen Styling-Lösung für Akkordeons, die überall im Code eingefügt werden können und trotzdem korrekt funktionieren. Zuerst hatte ich Markup, das aussah wieOffensichtlich wäre dies mit Selektoren wie
.accordion h1,.accordion h1 + pleicht zu stylen, aber es ist nicht sehr flexibel… was ist, wenn wir uns entscheiden, h1-h6 im gesamten Markup anstelle von h1 überall zu verwenden? Verschiedene Akkordeons könnten unterschiedliche Titel-Tags haben, und was ist, wenn<p>nicht immer für den Inhalt geeignet ist, den wir innerhalb jedes Abschnitts anzeigen möchten… das einfache Hinzufügen eines Klassennamens zu<h1>und<p>löst diese Probleme mit minimalem Aufwand.Dies ist jedoch nur ein winziger Teil dessen, was potenziell eine riesige Website sein könnte. Ich habe genauso viele Probleme damit, mit Magentos Standard-Stylesheet und übermäßig spezifischen Regeln zu kämpfen (vorherige Entwickler haben Magentos-Stylesheet beim Theming einfach überschrieben, anstatt ein neues zu erstellen). Das Überschreiben von Regeln wie
ul#main-navigation li.item a.navigation-link.current-item.overist genauso ärgerlich wie das Auftreffen auf eine hartnäckige ID, weshalb ich eher zu Harrys Ansatz mit einzelnen Klassennamen neige, zumindest weiß ich, dass ich und die anderen Leute in unserem Team nicht die gleichen Frustrationen erleben werden, die ich hatte!Nur so am Rande, ich habe das Gefühl, dass viele dieser Diskussionen über „Code-Smell“ überverallgemeinert sind. Wenn man vor 5 Jahren über dasselbe reden würde (oder Harry vor 2 Jahren fragt), wären die Antworten sehr unterschiedlich. Selbst wenn man Harrys Punkte heute liest, haben fast alle signifikante Ausnahmen oder sind eine Widerspiegelung eines spezifischen Architekturansatzes, den er zu diesem Zeitpunkt verfolgt. Das soll nicht heißen, dass diese Diskussionen keinen Wert hätten.
Ich würde argumentieren, dass dies wirklich die Bedeutung einer kohärenten Architektur, eines Satzes von Prinzipien und der Bemühungen, diese gesamte Struktur konsistent zu halten, wiederholt. Sie können „Code-Smell“ in einem Kontext haben, aber das macht sie nicht notwendigerweise zu Universalia, die immer gelten. In anderen Kontexten können andere Entscheidungen getroffen werden, und man kann schätzen, warum kluge Leute sie getroffen haben. Andernfalls besteht die Tendenz, von einer dogmatischen Position zur nächsten zu wechseln – etwas, das (anekdotisch) in diesem Bereich nicht selten vorkommt.
Sobald eine harte Position eingenommen wurde, ist es nicht immer einfach, sich davon zu lösen, besonders wenn man viel Zeit und Mühe investiert hat. Zeldman war zu seinem Verdienst bereit, seine bekannte Position aufgrund einiger gut begründeter Argumente in den Kommentaren zu seinem Artikel anzupassen.
Aber viele Entwickler haben festgestellt, dass die Anstrengung, „Belange zu trennen“, auch zu einer anderen Art von enger Kopplung zwischen ihnen geführt hat, die am deutlichsten in Kontexten zutage tritt, wo sie zu Wartungsproblemen führt. Die Bemühungen, die Menschen unternehmen, um diese Kopplung zu lockern, bedrohen Zeldmans frühere Bemühungen nicht, sie bauen darauf auf und bewegen sich von einem übermäßig strengen (im heutigen Kontext) Verständnis von HTML-basierten Semantiken weg, die CSS-Hooks (wie Klassennamen) an Dokumenten- und Inhaltsebene-Semantiken banden. Ebenso kann man erwarten, dass wir in den kommenden Jahren verschiedene Taktiken anwenden und möglicherweise viele der Ansätze vermeiden werden, die heute als „gut“ gelten, insbesondere da der Webstack weiterentwickelt wird.
Nicolas, ich stimme Ihnen vollkommen zu, dass die meisten dieser Diskussionen hauptsächlich kontextbezogen und relativ zu den Bedenken hinsichtlich des heutigen Web-Stacks sind.
Die meisten Vorschläge, die ich in dem Artikel gemacht habe, auf den Mark Dixon verwiesen hat, ergeben sich aus der Tatsache, dass es im heutigen Web sehr schwierig (wenn nicht unmöglich) ist, CSS-Komponenten vollständig zu kapseln.
Aber in der (vermutlich) nahen Zukunft werden viele dieser Probleme durch Web Components gelöst werden, die eine vollständige Kapselung von CSS und HTML ermöglichen.
Ganz ehrlich, das ist eine seltsame Diskussion. Wenn man IDs nicht handhaben kann, kann man auch keine Klassen handhaben. So einfach ist das.
Ja, ID hat eine höhere Spezifität und ist nur einmal auf der Seite erlaubt. Das macht nicht so viel Unterschied, wie manche vielleicht denken.
Kurz gesagt: „nicht“ verwenden. IDs ist dummer Rat. Ich bin sicher, Befürworter dieses Ansatzes wurden auch schon oft von Klassen verletzt, haben aber beschlossen, das zu ignorieren.
Ich neige dazu, zuzustimmen. Die ganze Debatte und Diskussion ist albern. Ich schalte sofort ab, wenn jemand anfängt, dogmatische Scheiße darüber zu spucken, ob man IDs verwenden soll und was das Leben einfacher macht. Es ist alles nur subjektives Geschwätz.
Ich denke, beide Methoden sind in Ordnung, solange Anstrengungen unternommen werden, das CSS zu organisieren und zu strukturieren. Niemand verbringt gerne die ersten Stunden damit, die Stylesheets von jemand anderem (oder sich selbst) zu lesen und zu verstehen.
Wenn ich an einem Stylesheet arbeite, versuche ich, es im Rhythmus zu halten wie folgt:
Verwenden Sie Klassen / IDs mit einer konsistenten Namenskonvention.
Stellen Sie sicher, dass diese Namen für Menschen lesbar sind.
Fügen Sie Kommentare in das Stylesheet ein, die erklären, worauf es sich bezieht, ein Hack usw.
Ein Inhaltsverzeichnis oben ist auch eine nette Geste.
Ich glaube, wir sollten das verwenden, was zu unserem Design passt. Leute, wir sind Designer, wir sind Problemlöser, Code sollte uns auf diese Weise dienen. Wenn eine ID benötigt wird, machen Sie es unbedingt, wenn Sie nur Klassen verwenden können, ist das in Ordnung.
Solange wir es sauber, funktionsfähig halten können und wenn es unsere Bedürfnisse oder Probleme löst, dann juhu! Wenn nicht, lösen Sie es auf andere Weise.
Ich denke, das ist eine Diskussion wie die über Preprozessoren, wir sollten das verwenden, was uns am besten passt und für uns funktioniert!
Ich schätze die Einstellung „einfach Probleme lösen“ und „was auch immer für dich funktioniert“, aber sei dabei extrem selbstbewusst. Diese Konversation besagt, dass Sie eine „IDs sind absolut in Ordnung“-Einstellung haben könnten, obwohl sie Sie (vielleicht) ins eigene Fleisch schießt.
Rodrigo, um das, was Sie gesagt haben, in den Kontext zu setzen… sagen wir, die Stützbalken unter Ihrem Haus geben nach und Sie haben 24 Stunden Zeit, eine Lösung zu implementieren. Sie entscheiden sich, 10 Rollen Klebeband zu verwenden und sie um alle Balken zu wickeln. Hat die Lösung funktioniert? Ja. Ist es der beste Weg, dies zu tun? Die meisten würden wahrscheinlich nein sagen. Nur weil eine Lösung funktioniert, heißt das nicht immer, dass es die beste Praxis oder das Richtige ist.
Ich habe das Gefühl, dass Dogmatismus oft in Bereichen großer Veränderungen und Übergänge entsteht, in denen wir alle das Gefühl haben wollen, dass wir die Dinge „richtig machen“. Wenn wir uns auf ein System einlassen, ist OOCSS nur ein Beispiel, neigen wir dazu, unsere Position zu verteidigen. Wenn wir offen für die Idee sind, dass es einen besseren Weg gibt, als wir es tun, kann diese Unsicherheit das, was wir tun, herausfordernd machen. Dies wird in großen Teams/Systemen dramatisch verstärkt, wo ein kalkulierter Ansatz entscheidend ist.
Lassen Sie 10 Rockstar-Entwickler dieselbe Website entwerfen, und Sie erhalten 10 verschiedene CSS-Lösungen – die alle funktionieren. Es gibt einen Unterschied zwischen Grundlagen und übergeordneten Richtlinien.
Ich liebe Harrys Artikel und ich liebe auch, was Zeldman gesagt hat. Beide haben Recht. Es geht mehr um den Kontext als um die Strategie.
Diese Diskussionen sind für uns alle hilfreich, um besser zu werden. Das Problem liegt darin, wo sich Leute „elitär“ verhalten, als ob ihr Weg der EINZIGE Weg wäre.
Macht weiter so. Baut coole Sachen!
Ihre Theorie von „10 Rockstar-Entwicklern“ fasziniert mich… Anfangs mögen sie alle gleich aussehen und funktionieren. Ich denke, das Problem, das OOCSS angeht, ist die Nachhaltigkeit des Codes. Wenn diese 10 Rockstar-Entwickler weiterhin an derselben Website arbeiten würden, würden wir sehen, dass einige, die weniger als ideale Code-Strukturen verwenden, mit der Wartung und Instandhaltung zu kämpfen haben? Was ist, wenn Sie den Code an einen anderen Entwickler übergeben? Wie leicht kann er die Lücke füllen und weitermachen?
Ich denke, die größte Frage bei der Diskussion von Code-Theorie ist: Fügt es der Webentwicklungs-Community als Ganzes einen Mehrwert, wenn so viele Menschen wie möglich auf die gleiche Weise arbeiten?
Andrew, ich stimme allem zu, was Sie gesagt haben, besonders wenn man ein System hat, das Kontinuität schafft. Trotzdem denke ich, dass der Versuch, ein einziges System für alle Projekte, Unternehmen und Kontexte festzulegen, wie auf ein sich bewegendes Ziel zu schießen ist. Darüber hinaus denke ich, dass die CSS-ID-Debatte nur ein Beispiel dafür ist, wo „Dogma“ ins Spiel kommt. Wir könnten über responsive Webdesign vs. Fixed-Width vs. separate mobile Websites sprechen oder eine andere solche Debatte. Ich bin super pro-responsiv, erkenne aber an, dass dies nicht unbedingt die richtige Lösung für alle Projekte ist, und ich werde niemanden verurteilen, der einen anderen Weg wählt.
Mit anderen Worten, Harrys Artikel ergibt absolut Sinn und wir sollten alle Notiz davon nehmen und uns in diese Richtung bewegen, aber wir müssen auch erkennen, dass es Ausnahmen gibt und dass CSS eine Evolution ist.
Nur weil ein Entwickler Harrys Richtlinien nicht perfekt befolgt, heißt das nicht, dass er/sie kein Rockstar-Entwickler ist, genauso wenig wie jemand, der das tut, ihn zu einem Rockstar macht.
Wo Dogma ein Problem ist, ist, wenn Leute in der Community die Arbeit anderer unfair kritisieren, weil sie nicht auf eine bestimmte Weise nach dem Prinzip des Dogmas selbst und nicht nach der tatsächlichen Arbeit oder dem Ergebnis gemacht ist.
Ich liebe diese Threads. Wir arbeiten in einer unglaublichen Branche.
Bei den spezifischen Problemen von IDs als Klassen-Selektoren bin ich fest (jetzt, nicht immer) im „Niemals“-Lager. Ich habe an zu vielen großen Projekten mit zu vielen großen Teams gearbeitet, wo die Verwendung von IDs als Selektoren Spezifitäts-Alpträume verursacht hat, die eine fast vollständige CSS-Refaktorierung erforderten, um etwas zu beheben, das eigentlich recht klein war. In meiner Praxis greifen CSS-Hooks jetzt nur noch Klassen (und semantisch strukturierte HTML-Elemente) auf, und IDs existieren ausschließlich als jQuery-Hooks. Tatsächlich gebe ich einem Element manchmal eine identische Klasse und ID für das CSS und jQuery. Ist das die effizienteste Vorgehensweise? Vielleicht nicht. Ist es auf einem großen Projekt in einer Teamumgebung am besten zu handhaben? Meine Erfahrung sagt ja. (Ihre Ergebnisse können variieren.)
Beim größeren Thema Dogmatismus & CSS habe ich das Gefühl, dass man in Teamumgebungen und bei großen Projekten eine gewisse Menge an Dogmatismus (ich glaube, das nannte man früher Coding Style Guides?) *braucht*, damit alle auf dem gleichen Stand sind. Wenn man nicht mit der Arbeit anderer kollidieren, Spezifität und andere Probleme angehen und insgesamt mehr mit Kopfschmerzen zu tun haben wollte, als das Projekt abzuschließen, mussten bestimmte Regeln aufgestellt und von allen befolgt werden.
Nur so am Rande, ich stimme 99,999 % von Harrys Beitrag zu. Seine Tipps repräsentieren gute CSS-Praktiken, die ich seit einiger Zeit in meiner Arbeit zu befolgen versuche. Ich möchte nicht sagen, dass ich *dogmatisch* bin, aber… :-)
Nichts in Harrys (ausgezeichnetem) Artikel wirkt auf mich dogmatisch. Ich glaube, Sie verwechseln *dogmatisch* mit *bestimmt*.
Harrys Rat ist bestimmt, weil erqualifizierende oder „abschwächende“ Bedingungen fehlen lässt. Das macht ihn zuversichtlich und klar, anstatt schüchtern und vage.
Dogmatismus hat nichts mit bestimmten oder starken Überzeugungen zu tun. Dogma ist resistent gegen Veränderung oder Überzeugung. Ein dogmatischer Mensch wird seine Überzeugungen nicht ändern, auch wenn ihm überzeugende Beweise oder Argumente vorgelegt werden.
(*Dogma* bezieht sich hauptsächlich auf tief verwurzelte religiöse Überzeugungen, die als unmöglich – oder ketzerisch – zu revidieren gelten.)
Man kann fast jede Frage mit „Es kommt darauf an“ beantworten; aber das ist eine nutzlose Antwort. Es ist gut, bestimmt zu sein, wenn man es kann.
Diese extreme Schwarz-Weiß-Sichtweise ist tatsächlich eines der Dinge, die mich von einigen der jüngsten Best Practices abschrecken (insbesondere von der Verwendung von IDs).
Um dies vorwegzunehmen: Ich sehe vollkommen, woher sie kommen, und ich stimme sogar zu – man sollte sich bemühen, sicherzustellen, dass sein CSS wiederverwendbar ist, aber ich tue das auf verschiedene Weise: Ich verwende einen Präprozessor und Mixins/ähnliche Dinge (ich glaube nicht, dass ich mehr Details darüber geben muss, wie ich das mache!)
Hier ist mein Problem: Ich habe ein Element auf meiner Website, nehmen wir einen gezielten Affiliate-Bereich (ich verwende Header/Footer nicht als Beispiel, da ich zunehmend [role=blah] dafür verwende). Aus Gründen, die nichts mit CSS zu tun haben, hat dieses Element eine ID, und *für mich* macht es viel mehr Sinn, diese ID zu verwenden, da sie bereits vorhanden ist, anstatt dem Element eine oder mehrere Klassen hinzuzufügen. Ich glaube, es fühlt sich wie eine Verschwendung eines perfekt brauchbaren Identifikators an =)
Das gesagt, wenn ich das in reinem CSS ohne Sass/Less/Stylus schreiben müsste... würde ich wahrscheinlich grummeln, aber diese "rounded-corners"-Klasse hinzufügen, denn es ist ärgerlich, einen Satz von Stilen immer und immer wieder wiederholen zu müssen!
Diese Denkweise ist Teil des Problems, wenn man versucht, wartbareres, skalierbareres CSS zu erstellen.
Das „effiziente“ Wiederverwenden dieser ID führt dazu, dass Ihr CSS an Ihren JavaScript-Code oder andere Aspekte Ihres Codes gekoppelt wird (je nachdem, wofür Sie die ID verwenden). Es macht diese CSS-Stile auch viel spezifischer als andere CSS-Stile, was ein Problem sein kann, wenn Sie versuchen, Ihre Stile zu erweitern/zu überschreiben. Und natürlich bedeutet es, dass die Stile nicht wiederverwendbar sind.
Wartbaren Code zu schreiben bedeutet nicht unbedingt, die geringstmögliche Code-Menge zu verwenden. Es ist oft besser, *methodisch* zu sein.
CSS-Präprozessoren können beim Schreiben von wartbarerem Code helfen, aber sie sind nur ein Teil einer guten Lösung. Ein Prämulator ist kein Ersatz für eine gute CSS-Struktur.
Aber das ist genau mein Punkt, wenn es um Präprozessoren geht – es *ist* wiederverwendbar.
Die restlichen Punkte finde ich interessant und werde darüber nachdenken müssen, da das gute Gründe sind. Sie werden mich vielleicht „überzeugen“, vielleicht auch nicht, aber es ist zumindest viel näher dran als die Argumente bezüglich Spezifität/Wiederverwendbarkeit. Danke =)
Oh ja, Sie haben absolut Recht, dass Präprozessoren die Wiederverwendung von Stilen ermöglichen, auch wenn sie an eine ID gebunden sind.
Es gibt einen kleinen Unterschied: Der ausgegebene CSS-Code wiederholt Ihre Stile. Das ist kein Problem für die Wartung, beeinträchtigt aber die Leistung, indem es Ihre Stylesheet größer macht. Allerdings sollte Gzip das meiste davon komprimieren, sodass das vielleicht keine große Sache ist.
Tatsächlich wird es sich nicht wiederholen, nicht, wenn man Erweiterungen verwendet. Zugegebenermaßen kann man immer noch auf Probleme mit der Spezifität stoßen und am Ende etwas haben, das weit oben in der Datei steht, obwohl man es weiter unten überschreiben möchte.
(Meine Argumente beziehen sich jetzt weniger darauf, warum man IDs verwenden sollte, sondern mehr auf die Vorverarbeitung, aber ich genieße die Diskussion)
Was denken Sie jedoch über die Verwendung von z. B. [role=main] auf diese Weise – würden Sie immer noch der Meinung sein, dass es ein Problem wäre, dies zu verwenden, sodass man stattdessen eine Klasse verwenden sollte?
„Vorzeitige Optimierung“ Klingt hässlich… Was war noch mal die Heilung? gesunder… gesunder… oh ja, gesunder Menschenverstand! Ich scherze natürlich, aber es scheint mir, dass wir uns in einer Zeit des Wandels befinden, in der wir neue Technologien erfinden, die sehr wenig Nutzen haben (OOCSS trotz seiner angeblichen Geschwindigkeitsvorteile ist im Grunde CSS, genauso wie LESS (in kompilierter Form)).
Für einen guten Artikel über OOCSS (im Grunde besagt, dass man IDs verwenden kann und OOCSS nichts für kleine Projekte ist) siehe den Artikel im Smashing Magazine.
„Eine Einführung in Object Oriented CSS (OOCSS)“
http://goo.gl/Phq53
@EdPoole. Semantik beschränkt sich nicht auf Browser, sie hat auch Bedeutung für Suchmaschinen und Entwickler. Ich würde sagen, der semantische Gewinn einer richtig verwendeten ID ist winzig, aber Semantik ist nicht auf den Browser beschränkt.
„Das ist der Weg, wie es gemacht werden sollte, und hier sind die Beweise dafür.“ Egal, wie sehr jemand denkt, dass er Recht hat, genau das ist das Problem. Das ist Dogmatismus. Niemand in der Gemeinschaft hat das Recht zu sagen, wie die Dinge gemacht werden sollen. Niemand hat das Recht, Meinungen als Fakten darzustellen.
Wir sprechen hier über Best Practices. Per Definition sind das Meinungen. OOCSS ist faktisch nicht die einzig gültige Methode, um CSS in jeder möglichen Situation zu strukturieren. Das macht es zu einer Meinung, zu einer Debatte, mit mehreren Ansichten. Kein Fakt.
Ich habe das Gefühl, dass die ganze „vermeide IDs“-Bewegung die Zugänglichkeit ein wenig beeinträchtigt hat, da ich keine Sprungmenüs mehr sehe. Wir verwenden zwar ARIA, aber es funktioniert nicht gut bei älteren Screenreadern. Viele Leute übersehen, dass JAWS (der beliebteste Screenreader) am besten mit IE funktioniert und sehr teuer im Upgrade ist, was viele Leute mit älteren Versionen zurücklässt, die nicht mit den neuen HTML-Funktionen funktionieren.
Persönlich verwende ich IDs für Hauptlayoutkomponenten (Header, Nav, Content, Footer usw.), JavaScript (DOM-Zugriff), Sprungmenüs und Formularelemente (offensichtlich). Aber ich würde sie auch in anderen Situationen nicht scheuen.
Außerdem sieht der neue Footer so aus, als würdest du das Merch-Mädchen gruselig anstarren… Ich bin dafür.
Das ist ein gutes Beispiel dafür, wo Dogmatismus beängstigend ist. Wenn Sie kein Sprungmenü *wegen einer Styling-Entscheidung* einfügen, machen Sie es falsch. Obwohl ich ein Befürworter der „keine IDs zum Stylen verwenden“-Seite dieser Debatte bin, darf das **zum Stylen** nicht vergessen werden. Verwenden Sie bitte weiterhin IDs für alles andere, wofür IDs nützlich sind.
Gibt es irgendwo eine gute Ressource, die jemand für CSS-Styling und -Struktur empfehlen könnte, die auch die ID-freie Methode implementiert? Mir gefällt die Idee und ich bin immer auf der Suche nach Verbesserung meiner Praktiken und Gewohnheiten, suche nur nach etwas Orientierung und guten Lektüren zu diesem Thema.
Ich glaube, die Diskussion kommt daher, dass manche Leute denken, manche Leute plädieren dafür, „*IDs zu verwenden ist schlecht, immer!*“, und nicht „*IDs nicht zum Stylen verwenden*“. Die erste Aussage klingt furchtbar dogmatisch, aber mit mehr Nuancen (in der zweiten Aussage) klingt sie gar nicht so dogmatisch.
Aber während Chris' Artikel eher den Charakter von „*meh, so schreibe ich eben meinen Kram*“ hatte, könnte Harrys Artikel etwas „aggressiver“ rübergekommen sein? Ein wenig so, als ob „*wenn Sie IDs verwenden, machen Sie es falsch*“ und ich fühlte mich fast angegriffen. Infolgedessen fühlte sich Zeldmans Artikel, in dem er die Verwendung von IDs verteidigte, umgekehrt fast wie eine Verteidigung *von mir* an.
Das mag etwas übertrieben klingen, aber mein Punkt ist, dass der *Tonfall* der drei besprochenen Artikel viel dazu beiträgt, wie die eigentliche Botschaft vom Publikum wahrgenommen wird.
Fyi, ich habe das schon früher kommentiert, in Ihrem Artikel CSS Style Guides.
Mein Standpunkt dazu ist, dass bei sehr großen Projekten jedes Werkzeug in der Kiste wertvoll ist. Denn früher oder später kann jedes Werkzeug in dieser Kiste das richtige Werkzeug für die Aufgabe sein.
Vielleicht bin ich das, aber ich verstehe wirklich nicht, wie das Stylen von IDs auf lange Sicht so viele Kopfschmerzen verursachen kann. Sicher, Klassen sind wiederverwendbarer und es ist wahrscheinlich besser, sie anstelle von IDs zu verwenden, aber wenn es in einem bestehenden Projekt so schwierig zu ändern ist, dann wurde der Code wahrscheinlich nicht gut genug geschrieben. Mit dem gesagt, nachdem ich einige der Kommentare hier gelesen habe, werde ich IDs wahrscheinlich noch weniger verwenden als bisher, aber ich würde gerne einige reale Beispiele hören, wie die Verwendung von IDs die Produktionszeit von irgendjemandem (oder einem Team) bei einem großen Projekt ruiniert hat.
Ich denke, die Vorstellung, dass es ein sehr großes Projekt sein muss, um das Ergebnis zu beeinflussen, ist falsch. Für mich ist das so, als würde man sagen
„Ich werde keine Hotkeys in Photoshop verwenden, weil das nur ein schnelles Projekt ist.“
Zeit ist Geld. Werden Sie effizienter. Immer.
Wir hatten ein Problem (mittelgroße Website), bei dem ein QA einem Element eine ID hinzufügte, um einen Selenium-Test schreiben zu können. Zufälligerweise wurde das von ihm verwendete Wort als ID an einem anderen Teil der Website verwendet – zu dieser Zeit stylten wir IDs. Einer der Hauptgründe für uns, nur Klassen zu stylen, ist, dass Klassen nur für CSS verwendet werden, während unsere IDs für mehrere Dinge verwendet werden, daher fühlt es sich sicherer an, nur Klassen zu stylen.
Ich denke, das Wichtigste ist, dass Sie eine Entscheidung treffen, wie Sie IDs und Klassen verwenden, und sicherstellen, dass jeder, der an Ihrem Code arbeitet, sich der Regel bewusst ist.
Das ist ein gutes Beispiel, danke, ich glaube, ich bin gründlich überzeugt, abgesehen von den Fällen „es ist schon da!“ und bei diesem bin ich immer noch nicht entschieden.
Aber denken Sie daran
Das. So viel davon. Stellen Sie sich vor, die ID wäre nicht nur zum Stylen verwendet worden, sondern als JavaScript-Hook für etwas anderes? Himmel.
An die Frauen, die in diesem männerdominierten Beruf kommentiert haben: Willkommen.
Ich bin seit etwa 18 Monaten professionelle Webdesignerin; ich scheue mich ein wenig, überhaupt zu kommentieren (besonders da ich nicht alle Auswirkungen von „objektorientiertem“ Code verstehe).
Das gesagt, ich bin überrascht, dass niemand das angesprochen hat
Abgesehen von der Überlegung großer vs. kleiner Websites sehe ich in den Kommentaren eine Kluft zwischen dynamischen und statischen Designern…
Ich habe Skripte noch nicht ganz gemeistert. Custom Modernizr ist das Dynamischste, was ich bin. Daher sind IDs für mich kein Problem.
Code-Stil, Erweiterbarkeit und Kommentare verstehe ich, aber da ich nie in einem Team gearbeitet habe, lerne ich oft durch „View Source“, was sowieso minimiert (z. B. Kommentare entfernt) sein sollte.
Auf meiner persönlichen Website enthält jede Seite ein Logo/Markenzeichen (mit der ID „brand“ im Menü [obere linke Ecke]), da dies ein Element ist, das konsistent sein muss und nur einmal pro Seite verwendet wird, scheint es passend (und prägnant/semantisch), ihm eine ID zu geben.
Weiterhin – und vielleicht hat sich das kürzlich geändert – im MDN-Artikel über effizientes CSS-Schreiben und anderen Artikeln (besonders relevant im mobilen Kontext) wird detailliert beschrieben, wie „teuer“ der Nachfahrenselektor ist und sogar einige der CSS3-Stile.
Vieles davon basiert auf dem, was ich von Paul Irish und Steve Souders gelesen habe, und ich nehme sie einfach beim Wort…
Sicher, ich könnte :last-of-type Pseudoklassen verwenden, aber da ich weiß, wie teuer das ist, neige ich dazu, manuell eine Klasse 'last' zum letzten Element hinzuzufügen (usw.). Aber, wie bereits erwähnt, neige ich dazu, an kleineren, statischen Websites zu arbeiten.
Meine aktuelle Website basiert auf Twitter Bootstrap, aber ich fand, dass es viele Elemente „überklasse“ hat, also habe ich, um sie mobiltauglicher zu machen, einige CSS3-Eigenschaften durch ungefähre CSS 2.1-Eigenschaften ersetzt, Klassen vereinfacht, IDs hinzugefügt, ungenutzte CSS-Regeln gelöscht und sie geändert, um neue semantische HTML5-Elemente (z. B. „nav“) einzufügen.
Um auf Tim's Kommentar einzugehen, ich habe auch IDs für Sprunglinks usw. hinzugefügt (und dann Styling-Eigenschaften zu ihnen hinzugefügt, da sie bereits vorhanden waren). Ich bin kein Wunderkind, aber ich glaube, es ist unsere Pflicht – wenn wir dazu in der Lage sind – unsere Inhalte so vielen Menschen wie möglich zugänglich zu machen…
[g@!-%&?n IE-Benutzer ausgeschlossen – das kriegen sie dafür, dass sie einen Browser benutzen, der Standards ignoriert!]
Ehrlich gesagt, ich würde gerne mehr über Skripting, Zugänglichkeit, Best Practices usw. lernen… erklären Sie es mir, verweisen Sie mich auf Ressourcen oder klicken Sie auf den Link und besuchen Sie meine Domain, um mir eine E-Mail zu schicken oder mir einen Job anzubieten :-D und mir einen besseren Weg zu zeigen.
Als jemand, der seit 15 Jahren programmiert (wenn auch zugegeben nur seit einem Jahr professionell), sollte ich Sie vielleicht stattdessen begrüßen! =)
Darf ich fragen, wie Sie eine Kluft zwischen dynamischen/statischen Seiten sehen? Ich glaube nicht, dass etwas von dem, was gesagt wurde, auf einer dynamischen im Gegensatz zu einer statischen Seite anders wäre, mit der potenziellen Ausnahme der Verwendung eines CMS, das den Code ziemlich freizügig mit Hooks überhäuft (Ja, WordPress, ich liebe es, mit dir zu arbeiten, aber ich schaue dich an!).
Man sollte niemandem alles glauben, ist mein Gefühl. Das bedeutet nicht, dass man jedes Wort von ihnen hinterfragen sollte, sondern sehen sollte, wie sie ihre Aussagen untermauern, damit man eine Art Verifizierung dafür hat, warum sie Dinge sagen.
Sie sollten auch keine Angst haben, nach dem Warum zu fragen, solange es zum Thema passt. Ich denke, eine der Stärken des Webs ist, dass die meisten Dinge hinterfragt werden können und sollten, obwohl man natürlich keine objektiv falschen Dinge argumentieren sollte (nein, #000 ist nicht die Farbe Weiß!).
Hallo Marie, alle zusammen,
Aus dem, was ich im MDN-Artikel, bei den Google PageSpeed-Infos (auch Irish und Souders) usw. über das Parsen von CSS gelesen habe, wird es von rechts nach links gelesen, und weil Nachfahrenselektoren versuchen müssen, durch jeden Knoten zu matchen (?… ich glaube, das ist der Begriff), ist es zeitaufwendig… „grauenhaft teuer“ ist der Satz, an den ich mich erinnere.
Dann gibt es noch den gefürchteten „Repaint“.
Wenn ich nur Klassen verwende, um Spezifitätsprobleme in der Zukunft zu vermeiden, hätte ich dann nicht CSS, das (großartig… und ein produktives Beispiel) mit reinen Klassen-Nachfahrenselektoren überhäuft ist und dann potenzielle Repaint-Probleme, wann immer ich diese Klassen dynamisch ändere (Position im DOM und die geänderten Eigenschaften wären Faktoren)?
Mein Bauchgefühl (ich habe auf Stack Exchange gefragt, ohne Antwort) ist, dass eine statische Seite ohne hinzugefügte Klassen, erstellte und eingefügte Elemente usw. (Analysen werden bei diesem einen Punkt ausgenommen), von Natur aus schneller wäre als eine, die nicht nur für DOM und CSS, sondern auch für Skripte geparst werden muss. Liege ich falsch?… Innerhalb vernünftiger Grenzen* ist es ein ausreichender Unterschied, um signifikant zu sein?
*für mich zählt auch das Mobile.
Wenn man etwas nur einmal braucht, verwendet man eine ID. Wenn es in Zukunft wegen Ihrer Nachlässigkeit anderswo aufgerufen werden muss, ersetzen Sie es durch eine Klasse. Wenn Sie eine Klasse haben, um z. B. einen Button darzustellen, aber bei einem bestimmten Button mehr Spezifität benötigen, der eine andere Border-Radius-Ecke links benötigt, geben Sie ihm dieselbe Klasse und zusätzlich eine ID und überschreiben Sie diesen Border-Radius.
Ist daran etwas falsch?
Absoluter Dogmatismus? Wahrheit
Verwenden Sie keine Klassen, um dasselbe auf denselben Eigenschaften zu stylen, die bereits mit einer ID-Regel gestylt wurden… denn: es wird nicht funktionieren… Oder verwenden Sie 256 oder 257 davon…
…
IDs sind stark und individualistisch; Klassen sind klassisch und funktionieren besser mit allen anderen.
Meiner bescheidenen Meinung nach ist diese Diskussion: nicht zu !wichtig…
Mein Malkurslehrer sagte uns einmal: „Es ist unsere Aufgabe als Kunstlehrer, Ihnen die Regeln beizubringen, es ist Ihre Aufgabe als Kunststudenten, uns zu sagen, dass wir falsch liegen. Aber um die Regeln zu brechen, müssen Sie sie zuerst kennen.“
Ich sehe Regeln wie Chris' „Linie im Sand“ oder Harrys „Dogma“ nicht als mehr als das, Regeln. Sie sollten Regeln nicht brechen, es sei denn, Sie kennen sie zuerst. Sobald Sie sie kennen und wissen, warum sie das sind, was sie sind, sollten Sie sie brechen. Denn nur dann tun Sie es mit wahrer Absicht.
Eine Sache, die ich am Erlernen von Web-Dingen liebe und hasse, ist, dass es immer etwas Neues zu lernen gibt. In meinen früheren Kommentaren hatte ich das Gefühl, CSS ziemlich gut im Griff zu haben, und kommentierte, ohne die oben verlinkten Artikel zu lesen oder auch nur den kleinen Schnipsel über die Verwendung von IDs in HTML, aber nicht in CSS, zu bemerken.
Ich fand den Artikel von Zeldman und noch mehr die folgenden Kommentare sehr aufschlussreich, so dass ich jetzt auf dem ID-freien CSS-Zug bin (mit der Einschränkung, dass ich für etwas, von dem ich wirklich erwarte, dass es immer eindeutig ist und eine ID im HTML benötigt, es *vielleicht* stylen werde, anstatt eine zusätzliche Klasse hinzuzufügen). Großartige, aufschlussreiche Diskussionen und ich habe viel von Ihnen allen gelernt, danke.
Ich habe irgendwo gelesen und glaube fest daran, dass CSS keine Programmiersprache ist. IDs sind Artefakte aus der Programmierung. Listen, Divs, Spans müssen alle von der Sprache manipuliert werden. Ich finde mehr Organisation meiner IDs für Menüs, Akkordeons und Ähnliches. Klassen sind für mich eine großartige Möglichkeit, die Formatierung und die visuellen Hinweise beizubehalten. Es ist sehr einfach, diese zu kombinieren und zu mischen. Zu sagen, dass IDs nicht verwendet werden sollten oder dass zu viele Klassen nicht optimal sind, ist wirklich eine Betrachtung dessen, wer den Code schreibt. Ich werde CSS als visuelle Formatierung und nicht als Programmierung einer Seite verteidigen. Verwenden Sie JQuery oder JavaScript, um Funktionalität hinzuzufügen, und lassen Sie CSS schön aussehen.
Ich war in Situationen, in denen die Debatte ID vs. Klasse mich in schlimme Kreise geführt hat, bis ich lernte, mein CSS zu organisieren und zu schablonieren, die JQuery-Klassen zu nutzen und mein Skripting in Skripten zu belassen.
IDs wurden für die funktionale Programmierung einer Webseite erstellt und verwendet, nicht für die CSS-Formatierung. Überlassen Sie CSS seiner grundlegenden klassenbasierten Formatierung.