Während meines Studiums habe ich in einer Bar gearbeitet. Die Bar hatte eine kleine Küche und servierte typisches amerikanisches Bar-Essen: Burger, Flügel und Suppe. Wir hatten zwei Suppen, eine wechselte, eine war immer Chili. Wir haben das Chili jede Woche selbst gemacht. Manchmal waren wir ausverkauft, manchmal hatten wir am Ende der Woche Chili übrig. Wenn etwas übrig war, haben wir es entweder weggeworfen oder mit nach Hause genommen. Es war immer noch perfekt zum Essen, aber es war keine gute Politik, wochenaltes Chili in einem Restaurant zu verkaufen.
Ich habe mit einem Freund in dieser Bar gearbeitet. Er war Vegetarier. Er war kein Vegetarier aus Geschmacks- oder persönlichen Gesundheitsgründen, sondern aus Gründen der globalen Nachhaltigkeit. Das Chili enthielt Fleisch. Also normalerweise nichts für meinen Freund.
Eines bestimmten Wochenendes, als das Ende der Woche nahte, hatten wir Chili übrig. Mein Freund arbeitete. Er konnte diesen Topf Chili in den Abfluss schütten oder er konnte ihn mit nach Hause nehmen. Nun, wenn man Vegetarier ist und dies nur aus Gründen der globalen Nachhaltigkeit tut, dann ist die richtige Wahl sicherlich, das Chili mit nach Hause zu nehmen und zu essen. Lebensmittel wegzuwerfen und etwas anderes zu konsumieren ist verschwenderisch.
Ja, er konnte es für mich mit nach Hause nehmen oder zu seiner Großmutter bringen. Wir könnten uns 100 alternative Wege für dieses Chili ausdenken, aber bleiben wir bei der Analogie – es kommt vor, dass persönliche Ideale durch praktische Erwägungen herausgefordert werden. Manchmal hat es mit Chili zu tun.
Als dieses Dilemma mit meinem Freund besprochen wurde, fand ich seine Argumentation für sein Nicht-Essen des Chilis gut. Er sagte: „Es geht darum, eine Linie im Sand zu ziehen.“ Höchstwahrscheinlich bezog er sich auf The Big Lebowski, aber er machte einen guten Punkt.
Hier geht es nicht um einen Topf Chili und einen Typen in einer Bar. Es geht darum, langfristig und für das größere Wohl keine Kompromisse einzugehen. Vielleicht macht die Bar beim nächsten Mal Chili, macht etwas weniger oder kleinere Portionen aufgrund des bekannten Abfalls. Vielleicht wird bei der nächsten Überarbeitung der Speisekarte weniger fleischhaltiges angeboten, weil wir wissen, dass es kompromisslose Vegetarier wie meinen Freund gibt, die auch viel Zeit in Bars verbringen. Wenn diese Haltung zum Standard wird, geht es um Millionen von Töpfen Chili und eine veränderte Welt.
Richtig, also, HTML-Klassen.
Sie wissen, dass es generell am besten ist, mit Klassen zu stylen, richtig? Das ist, was OOCSS und SMACSS und moderne Schriften über CSS lehren. Nicht nur „Klassen clever nutzen“, sondern auch „IDs nicht nutzen“. CSS Lint wirft Ihnen sogar eine Warnung entgegen, wenn Sie IDs in Selektoren verwenden. Was? Wirklich? Eine _Fehlermeldung_ für das Schreiben eines völlig gültigen Selektors?
Ja, wirklich. IDs sind unendlich spezifischer als Klassen. Naja, fast. Das ist so stark, dass es in CSS schnell außer Kontrolle geraten kann. Ja, es kann eine schnelle, einfache, mächtige Überschreibung sein, aber wie überschreiben Sie das dann? (Wer überwacht die Wächter?) Wenn Sie mit sich selbst (und Ihrem Team) vereinbaren, sie niemals zu verwenden, geraten Sie nicht in diese Wettrüsten. Diese Überschreibungsprobleme können immer anders gelöst werden – durch Code-Refactoring, Verschachtelung einer Klasse oder etwas Ruhigeres und Intelligenteres.
Viele kluge Leute sind anderer Meinung (siehe Kommentar-Thread in einem anderen Beitrag). Aber für mich läuft das wieder darauf hinaus, eine _Linie im Sand zu ziehen_. Ich werde keine IDs zum Stylen von Dingen verwenden. Kein Kompromiss. Selbst wenn eine ID wie eine kurzfristige Ersparnis erscheinen mag, sind die langfristigen Vorteile, sie niemals zu verwenden, größer.
Eines Tages habe ich einfach beschlossen, meine eigene Linie im Sand zu ziehen, und seitdem style ich nicht mehr mit einer ID. Ab und zu mag es sich widersinnig anfühlen, aber insgesamt habe ich das Gefühl, dass es meine Arbeit verbessert hat.
Super, jetzt kann ich nur noch ans Chiliessen denken… Oh, und an ein kleines „Suche ‚#‘ -> Ersetze ‚.‘“
Ich habe das gerade gemacht und war erschrocken, weil alles kaputt war. Dann wurde mir klar, dass ich alle meine Farben nullifiziert hatte. :(
Sind Tags wie header, footer, aside, und nav nicht auch so etwas wie Pseudo-IDs? Das ist sicherlich eine der Arten, wie ich sie betrachte. Ich nehme an, wenn Sie nur einen in Ihrem Code verwenden, dann brauchen Sie keine Klasse oder ID dafür hinzuzufügen, um ihn zu stylen.
Ich bin immer noch nicht davon überzeugt, dass IDs nicht mehr nützlich oder verwendbar sind.
Al
Tags sind Selektoren. Eine ID ist eine einmalige Verwendung eines Tags anstelle einer Klasse.
class=”foo” (beliebig oft verwenden)
id=”foo” (einmal verwenden)
IDs haben in JavaScript / jQuery immer noch ihren Platz!
Es ist tatsächlich völlig gültig, mehrere Header, Navs oder Asides zu haben (ich glaube, man ist auf einen Footer beschränkt). Man kann einen Haupt-Header haben und dann einen Header in jedem Section-Tag haben, zum Beispiel.
Ich glaube nicht, dass Chris sagte, dass IDs nicht nützlich sind. Man kann sie in CSS verwenden und sie sind großartig für JS. Aber es kann helfen, Dinge übersichtlich zu halten, wenn man sich an Klassen hält.
Mein Team hatte eine ID für einen Absenden-Button verwendet. Sie dachten, es gäbe nur einen einzigen Absenden-Button. Sie lagen falsch und ich musste die ID in eine Klasse umwandeln. Kein großes Problem, aber die Verwendung von Klassen kann die Dinge erleichtern.
Ich stimme zu, ArleyM, die Verwendung von IDs ist immer noch der effizienteste Weg, Elemente mit Skriptsprachen zu manipulieren. getElementById ist unermesslich schneller als alle anderen Alternativen, da der Browser ein Verzeichnis von Elementen mit IDs führt und nur ein Element zurückgibt. Sicher, wir haben getElementsByClassName, aber zuerst muss der Browser jedes Element durchlaufen, nach dieser Klasse suchen, und dann müssen Sie die Ergebnisse erneut durchlaufen, um das gesuchte Element zu finden.
Man könnte argumentieren, dass jQuery die Komplexitätsprobleme löst, aber es macht immer noch die exakt gleiche Logik im Hintergrund.
Wenn Ihnen die Geschwindigkeit des Skripts wichtig ist, verwenden Sie IDs.
Ich halte ein pauschales Verbot eines so grundlegenden Teils von HTML für falsch. Es sind Werkzeuge, die mit Weisheit und Mäßigung eingesetzt werden sollten. Lassen Sie uns hier nicht überreagieren. Viele Leute haben Tabellen missbraucht, und wir haben alle erschreckt, damit aufzuhören. Manche Leute missbrauchen IDs, aber machen wir nicht denselben Fehler noch einmal.
Lies, was Chris sagt
„IDs zum Stylen von Dingen verwenden“, d.h. CSS schreiben, um die Elemente mit einer bestimmten ID zu stylen. Das hat also nichts mit JavaScript zu tun. Ich nehme an, er wird immer noch IDs verwenden, um das Element mit JavaScript anzusprechen.
In gewisser Weise ist dieser Link völlig irrelevant, aber in einer anderen bringt er die Sand-/Chili-Analogie zum Abschluss. Ich habe das heute Morgen zufällig gelesen
Es gibt _tatsächlich_ Sand in Fast-Food-Chili: http://www.businessinsider.com/11-disgusting-ingredients-that-arent-advertised-in-food-2012-3?op=1#ixzz1qYZOG1QU
Dein Freund könnte sich jetzt mit metaphorischer Nachhaltigkeit beschäftigen und eine Linie im Chili ziehen!
Was ist mit der Verwendung einer ID als Fragment-Identifikator innerhalb eines Dokuments? http://www.w3.org/DesignIssues/Fragment.html
Fragment-Identifikatoren sind nicht für CSS. Diese Diskussion dreht sich rein um die Verwendung von IDs als Styling-Anker. Natürlich sollten IDs weiterhin für andere Zwecke verwendet werden.
Guter Punkt.
Ich könnte nicht mehr zustimmen, obwohl ich mich im Voraus für meine Tollpatschigkeit entschuldigen muss...
Eine schnelle Ansicht des Quellcodes dieser Seite zeigt 47 Verwendungen von IDs. Okay, fair genug, Sie verwenden diese nicht zum Stylen. Aber warten Sie, es gibt auch eine Reihe von Deklarationen für IDs im Stylesheet der Seite.
Also, ist das Ihre „Linie im Sand“ für die Zukunft? Oder gibt es einen legitimen Grund, warum IDs in bestimmten Umständen _benötigt_ werden?
Das ist eine Sache, die ich an WordPress hasse. Ich gebe mir Mühe, in all meinen Projekten sauberen, best-practice-konformen Code zu schreiben, aber dann ist mein persönlicher Blog (der angeblich meine beste Arbeit repräsentieren soll) ein Durcheinander. Weil WordPress beim Code furchtbar ist, besonders wenn man viele Widgets und Plugins hat. In vielen Fällen sind diese Plugins die einzigen, die das tun, was man will, und die einzigen Styling-Haken, die sie einem bieten, sind IDs.
Aus meinem schnellen Blick auf Chris' Code scheint es, dass er genau das getan hat. Kurz gesagt: WordPress zählt nicht! :)
(Das ist auch der Grund, warum auf Paul Irishs WordPress-Blog die Nachricht steht: „Der eigene Code dieser Seite ist ziemlich schwach…“)
Ah, das erklärt es dann! Ich benutze kein WordPress, und das ist ein weiterer einfacher Grund dafür. Ich würde mich ziemlich unwohl fühlen, ein CMS zu verwenden, das Ihren Code auf diese Weise verschandelt.
@Louis – Ich glaube nicht, dass das überhaupt Schuld von WordPress ist. Man kann Plugins beschuldigen, klar, aber als Entwickler habe ich immer das Gefühl, dass das Theme selbst vollständig in meiner Hand liegt, um es zu kontrollieren.
@gary
Ich stimme zu, aber zugegeben, auf einem persönlichen Blog übertrumpft Faulheit Best Practices! :) Es ist einfach einfacher, WP schlecht sein zu lassen, das ist alles.
Auch in Bezug auf Plugins ist das Problem folgendes: Das Plugin fügt oft selbst das HTML ein. Ja, ich könnte die Plugin-Datei bearbeiten, damit sie Klassen anstelle von IDs enthält. Aber was passiert dann, wenn ich das Plugin aktualisiere? Diese Klassen verschwinden und es kommt zu Fehlern. Und ich werde auf keinen Fall spezielle Notizen zu jedem Plugin machen, das ich manuell geändert habe. Daher ist es auf einem persönlichen Blog einfacher (weniger faul), WordPress schlechten Code machen zu lassen. Ich weiß also, dass es möglich ist, es besser zu machen, es macht nur oft keinen Spaß oder ist nicht praktikabel.
Ups… „gary“ sollte „gray“ heißen. Mein Fehler. :)
Ich widerspreche dem Kommentar zu WordPress – Der Entwickler hat 100 % Kontrolle über das Markup, WordPress verschandelt nichts. Wenn Sie schlechte Plugins wählen, ist das Ihre eigene Schuld. Wählen Sie Ihre Plugins mit Bedacht, Grashüpfer.
Je besser ich im CSS-Aufbau werde, desto weniger verwende ich IDs zum Stylen.
Aber andererseits verwende ich sie immer noch, denn es gibt Elemente, die _tatsächlich_ einzigartig sind und es _brauchen_, einzigartig zu sein. ID-Regeln sind perfekt für sie.
Was ich weiß, ist, dass ich Zeit spare, in dem Moment, in dem ich die Regel schreibe. Würde ich Zeit sparen, indem ich stattdessen eine Klasse verwende? Nun, wer weiß? Wie kann ich das berechnen?
Ich kann es kaum. Und selbst wenn ich es könnte, bin ich mir nicht sicher, ob es die Mühe wert wäre.
Wenn ich jemals meine ideologische Integrität schützen möchte, würde ich sagen, dass ich in der Lage sein möchte, eine Linie im Sand zu ziehen, wann immer ich Lust dazu habe. Diese Linie könnte mich auf den richtigen Weg führen.
Nur weil ein Element einzigartig ist, heißt das nicht, dass sein Styling einzigartig ist. Warum nicht eine allgemeinere Klasse verwenden, die auf etwas anderes angewendet werden könnte?
Und nur weil etwas jetzt einzigartig ist, heißt das nicht, dass es immer einzigartig sein wird. Glauben Sie, Sie werden immer nur einen Header, einen Footer und einen Inhaltsbereich haben?
@Scott
Wenn ich sage, ein Element sei einzigartig, meine ich, sein Styling sei einzigartig. Also, da haben wir's.
Sie wissen nicht, was ich unter „einzigartig“ verstehe und warum ich sicher bin, dass sie einzigartig sind. Denken Sie wirklich, dass ich nur über Header spreche?
Es gibt auch Fälle, in denen ich IDs und Klassen mische. Das kann ich tun, also tue ich es, wenn ich es brauche.
Am Ende denke ich, dass die Verwendung von ID-Regeln _semantisch_ korrekter ist als die ausschließliche Verwendung von Klassen.
MaxArt, ich bin mir nicht sicher, ob Sie das Konzept erfassen. Sobald Sie sich für das Styling einer ID entscheiden, sagen Sie: „Ich werde niemals die Stile, die auf diese ID angewendet werden, auf etwas anderes wiederverwenden, niemals.“ Wenn das, was Sie erstellen, konsistent/benutzerfreundlich gestaltet ist, würde ich argumentieren, dass es Fälle für wiederverwendbare Stile in jedem „Modul“ gibt.
Merne, der Punkt einer ID ist es, ein Element _auf dieser Seite_ eindeutig zu machen. Ich kann dieselbe ID auf vielen Seiten verwenden.
Wenn ich zum Beispiel die gesamte Seite mit einem Warte-Spinner bedecken möchte, wenn eine AJAX-Anfrage gestellt wird, um weitere Benutzerinteraktionen zu verhindern, kann ich eine eindeutige Struktur dafür verwenden. Und ich kann sie auf allen Seiten verwenden, die ich möchte, auf konsistente Weise.
Sicher, ich kann Klassen verwenden. Aber warum? Gibt es eine Chance, mehr als eine Vollbildabdeckung auf derselben Seite zu haben? Nein, das wäre ein Interface-Fehler.
Nur eine ID zu verwenden, ist die semantisch korrekte Art, den Trick zu machen.
Sie bringen ein gutes Argument für einen sehr spezifischen Anwendungsfall. In diesem Fall stimme ich Ihnen zu. Natürlich hat dieser Loader keine semantische Bedeutung, daher würde er über JavaScript hinzugefügt werden (wenn ich es tun würde), und nicht beim Laden des DOM vorhanden sein. Ich benutze IDs in meinem JavaScript, also würde ich in diesem Fall auch eine ID verwenden (aber eine Klasse zum Stylen haben).
Der Punkt ist, dass wenn Sie sich entscheiden, IDs und Klassen (in Ihrem Stylesheet) zu mischen, Sie einen Spezifitätskampf beginnen. Ich stimme zu, dass bestimmte Entwickler damit davonkommen (und es wunderschön tun), aber wenn der Fall eintritt, dass Sie nicht der einzige Entwickler sind, kann es schnell chaotisch werden.
Alles gesagt, ich glaube nicht, dass IDs etwas mit Semantik zu tun haben.
Genau!! Das sage ich meinen Teamkollegen… hoffe, Ihr Beitrag macht sie jetzt auf die Dinge aufmerksam… gerade auf Facebook geteilt! :)
Ich bin immer noch nicht überzeugt. Ich benutze ab und zu IDs, wenn es sich um einen sehr spezifischen Fall handelt.
Warum sollte ich sie überschreiben müssen? Es ist ein spezifischer Selektor für ein spezifisches Element, also kann ich einfach den Inhalt dieses Selektors ändern. Ich weiß, dass es nichts anderes beeinflussen wird, weil es eindeutig ist.
Sicher, wenn Sie IDs überall verteilen und sie als Selektoren verwenden, werden Sie früher oder später auf Probleme stoßen, aber wenn Sie sie hier und da in sehr spezifischen Szenarien verwenden, sehe ich kein Problem.
Im Artikel von CSS Wizardry, auf den Sie in Ihrem Crazy Town Selectors Blog verwiesen haben, kam das Konzept des „Selektor _Intent_“ auf. Fragen Sie sich, was Sie auswählen, und wenn Ihre Antwort lautet: „dieses Element und nur dieses Element“, warum nicht die ID verwenden? Wenn sich die Antwort ändert, dann ja, Sie müssen sie durch eine Klasse oder einen gemeinsamen Selektor ersetzen, aber das liegt daran, dass sich die Absicht geändert hat und die ID nicht mehr angemessen ist.
Anstatt einer restriktiven Linie im Sand, die sagt: „Tun Sie das unter keinen Umständen“, denke ich, dass es angemessener ist, eine _Richtlinie_ im Sand zu haben (sehen Sie, was ich getan habe?), um Missbrauch zu verhindern oder abzuschrecken.
Ich weise immer noch Leute auf ihre Verwendung von IDs hin, wenn es unangemessen ist, wenn sie Duplikate haben oder wenn ihr Selektor sinnlose ID-Referenzen enthält (d.h. 2 gestapelte ID-Selektoren). Aber das ist ganz anders, als ihnen zu sagen, sie sollen es nie tun.
Ja, ich habe inzwischen die Theorie der No-More-IDs übernommen. Ich schaue mir ältere Websites an, die ich gebaut habe, und denke: „Igitt… was für ein Durcheinander“, wenn ich die IDs auf all diese seltsamen Arten überschrieben habe. Klassen machen alles SO viel sauberer.
Estelle Weyls „CSS SpeciFISHity“-Grafik ist großartig, um zu visualisieren, wie sich verschiedene CSS-IDs und Klassen in Bezug auf die Spezifität unterscheiden.
Ich denke, diejenigen, die sich der „No ID in CSS“-Ideologie widersetzen, verpassen das Gesamtbild.
Um wartbare, skalierbare CSS zu schreiben, das mit einer Website wächst und reift, müssen Sie jeden Abschnitt Ihrer Seite wie ein Modul betrachten, und nicht nur ein einzelnes Modul, sondern einen Aufbau aus Teilen, von sehr generischen Modulen bis hin zu spezifischeren Untermodulen. Dabei erkennen Sie den Wert der Verwendung von Klassen gegenüber IDs. Wenn ich mich entscheide, eine ID auf einem Untermodul zu verwenden, kann ich diese Stile niemals aufbauen, um sie woanders wiederzuverwenden, da dieser Selektor jetzt zu spezifisch ist.
Schauen Sie sich einfach an, wie Twitter Bootstrap aufgebaut ist, wo Sie Klassen wie
.navund dann „Unter“-Klassen wie.nav-tabshaben. Sie haben eine Basisklasse wie.nav, die dann mit.nav-tabsaufgebaut wird. So sollten Sie über den Aufbau jedes Teils Ihrer Seite nachdenken. Kann es zu einer generischen Basisklasse verallgemeinert werden, die ich dann immer wieder auf meiner Website verwenden kann? Selbst „einzigartige“ Elemente wie eine Hauptnavigation profitieren von Basisklassen. Sie könnten Ihr CSS so aufbauen, dass Ihre tatsächlichen Regeln für Ihre Hauptnavigation nur wenige Zeilen lang sind, da sie auf anderen Basisklassen basieren, um den Großteil der Arbeit zu erledigen.Sie bringen ein sehr triviales Beispiel.
Sie können dieselbe ID auch in mehr als einer Seite verwenden, wissen Sie.
Das ist eine gute Beschreibung, warum wir diese Linie im Sand ziehen sollten. Ich habe nach einer tieferen Erklärung gesucht, warum „die langfristigen Vorteile, [IDs] niemals zu verwenden, größer sind.“ Ich würde gerne mehr darüber lesen.
Ausgezeichnetes Beispiel.
Ich stimme Ihnen Chris absolut zu. Es sei denn, Sie arbeiten mit PHP. Aber selbst dann empfehle ich nicht, eine ID zu stylen.
Tags wie header, footer, aside, nav, section, article sind nicht wie IDs, sie sind Tags. Sie werden beim Stylen als Tags verwendet. Das bedeutet, dass Sie so weniger Klassen benötigen, aber die Möglichkeit offen lassen.
Zum Beispiel, wenn Sie eine primäre und eine sekundäre Navigation haben möchten. Eine kann horizontal und die andere vertikal sein. In einem solchen Fall können Sie den Nav-Tag für beide verwenden und jedem eine Klasse geben. So können Links gleich aussehen, aber unterschiedliche Schriftgrößen oder was auch immer Sie möchten haben.
Yo, nur zur Info, aber ich habe unseren Bug „Klassen können spezifischer sein als IDs“ in WebKit behoben. Jetzt wird die Klassenspezifität bei 255 abgeklemmt und läuft nicht in den ID-Bereich über.
Aber Sie werden nicht Vegetarier? : (
Wo ist mein Happy End?
Ich bin in letzter Zeit auf diese Diskussionen gestoßen, aber habe noch keinen guten Grund gehört, warum man IDs nicht verwenden sollte.
In meinem Fall verwende ich sie rituell, um bestimmte Teile (Module, Abschnitte, was auch immer) der Website oder Anwendung zu identifizieren (ID). So kann ich ein paar generische Styling-Deklarationen für das gesamte System über Tags und Klassen schreiben; und dann die Container-IDs verwenden, um spezifische Instanzen eines generischeren Musters anzusprechen, die möglicherweise ein zusätzliches (oder anderes) Styling benötigen.
Diese Praxis hat mir gut gedient, um die Größe meiner Stylesheets zu reduzieren und es einfacher zu machen, Stile in Zukunft zu warten und zu modifizieren.
Ich bin zu Klassen für fast alles übergegangen. Ich verwende immer noch IDs für Fälle, in denen JavaScript sie benötigt oder aus semantischen Gründen, also zum Beispiel;
Also verwende ich Grid One-Third (zum Beispiel) für Breite, Höhe, Styling usw. und dann ist main-content da, um es speziell mit JS anzusprechen oder einfach nur aus semantischen Gründen. Ich benutze sie nur noch sehr selten zum Stylen.
Hmm, pre/code-Tags funktionierten nicht. Jedenfalls meinte ich:
div id=”main-content” class=”grid one-third”
Zum Beispiel.
Aber was ist, wenn Sie 3 gleiche Grids auf einer Seite haben und #main-content leicht anders sein soll?
Wenn der Stil, den ich brauchte, nur für dieses DIV einzigartig war, dann würde ich absolut wahrscheinlich die ID stylen. Wenn es sich jedoch um einen wiederholten Stil handelte, Farbe, Hintergrund, Box-Shadow, was auch immer, würde ich einen Weg finden, eine Klasse zu erstellen, um das div effektiv „opt-in“ zu machen und einfach eine zusätzliche Klasse hinzuzufügen.
Es ist leicht, der Gesetz des Instruments zu verfallen, und wenn man merkt, dass man ein Werkzeug töricht missbraucht hat, ist die übliche panische Reaktion, das Werkzeug ganz aufzugeben.
Das ist ein dummes Verhalten.
Lernen Sie stattdessen, wann es angebracht ist, ein Werkzeug zu verwenden, wie z. B. wenn ID-Selektoren eine vernünftige Lösung sind.
Wenn das Werkzeug nicht angemessen ist, verwenden Sie es nicht.
Chris, ich folge dir schon lange und viele deiner Tiraden bleiben bei mir hängen und machen mich zu einem besseren Menschen/Entwickler… egal wie sehr ich dir im Moment widerspreche. Aber ich habe dich noch nie so absolutistisch reden hören, und ich komme zu diesem Beitrag zurück, indem ich sage, dass das Sprechen in Absoluten niemals gut ist. Würden Sie argumentieren, dass IDs im Web-Development keinen Zweck haben, oder nur nicht zum Stylen?
Chris sagt in seinem Artikel selbst, dass „[er] keine IDs zum Stylen von Dingen verwenden wird. Kein Kompromiss.“ Ich kann nur annehmen, dass er meinte, dass die Verwendung von IDs für andere Zwecke in Ordnung ist – wie jQuery.
Können wir ein Beispiel dafür sehen, wie IDs auf schmutzige Weise zum Auswählen verwendet werden?
Wenn ich einen Login-CTA mit der ID „login“ habe, werde ich diese ID verwenden, um einen winzigen, schönen Selektor für dieses sehr einzigartige UI-Element zu erstellen. Kurz darauf werde ich mich mit Chili belohnen, als Belohnung für meine eloquente Konvergenz von HTML, CSS und JavaScript.
Und jetzt will der Kunde denselben Login auch im Footer hinzufügen…
Ich verwende nur Klassen, außer wenn ich einen Anker auf einer Seite anspreche, was an sich selten ist. IDs scheinen nützlicher für Funktionen als für das Styling zu sein.
Es ist eine Kleinigkeit, aber Punkte (.class) sind auch visuell weniger störend/aufdringlich als #s in CSS. Lächerlich, aber es stimmt!
Jahrelang – wahrscheinlich länger, als ich überhaupt wusste, dass es einen Grund dagegen gab – habe ich keine IDs zum Stylen verwendet, AUSSER in einem Fall. Für mich war die Begründung immer nur: „Habe ich das #mani-nav oder .main-nav genannt?“ Eine kleine Ärgernis, die sich bei Hunderten von Selektoren summieren kann.
Die eine Ausnahme – und wahrscheinlich eine, die ich immer noch verwenden werde – ist, dass ich jede ID nur EINMAL in einem PROJEKT verwende und dann nur auf dem <body>-Tag. Außerdem verwende ich niemals IDs in CSS zum Stylen, außer in einem Fall
oder so ähnlich. Es scheint mir einfach, dass WENN das ID-Tag einen legitimen Verwendungszweck hatte, dann war es, eine Seite zur „IDentifikation“ zu kennzeichnen – und vielleicht die Tatsache, dass es gegen die „Ether“ verstößt, doppelte .home.home zu verwenden.
Mein persönlicher Weg von IDs zu Klassen: Ich habe IDs in der (jüngsten) Vergangenheit mehr verwendet… Ich hatte typischerweise diese Denkweise
1) ein „einzigartiger Abschnitt“ innerhalb einer Seite wurde durch eine ID identifiziert
2) alles darin wurde gestylt, um _„divitis“ und „classitis“ zu vermeiden_, d.h. geeignete Tags für Inhalte zu verwenden und zu vermeiden, unnötige Klassen zu meinem HTML hinzuzufügen
‘#’news {}<br/>
‘#’news h2 {}<br/>
‘#’news ul {}<br/>
‘#’news a{}<br/>
(Vielleicht hätte dies mit Klassen gemacht werden können… aber hey, das war die Vergangenheit!)
Jetzt, da ich zu HTML5 (mehr semantische Tags, wow!!) und LESS gewechselt bin, habe ich mich dabei ertappt, wie ich versucht habe, diese Linie zu ziehen.
Ich denke definitiv, dass _Mixins und Verschachtelung das möglich gemacht haben_. Ich experimentiere noch, aber es scheint gut zu funktionieren…
Eine weitere Sache, die mir sehr geholfen hat, besseres CSS zu schreiben, ist, _die Website-Styles über Seiten und Abschnitte hinweg „konsistenter“ zu gestalten_ (d.h. unnötige und bedeutungslose Variationen zu vermeiden)
Hey, mir wurde gesagt, ich bekomme eine kostenlose Schüssel Chili, wenn ich hierher komme…
.totally-agree
Bevor Sie eine bestimmte Methode verbreiten, sollten Sie sich fragen, was das Ziel ist.
Welches Ziel möchten Sie beim Schreiben von CSS erreichen?
Angenommen, Sie möchten den effizientesten Code schreiben, wie können Sie das tun?
Und wieder müssen Sie sich fragen, was „beste Effizienz“ in diesem Fall bedeutet.
Kleinste Dateigröße, minimale Überschreibungsregeln, beste Wartbarkeit, Upgradefähigkeit oder was sonst?
Also zumindest einige der oben genannten Punkte können nur erreicht werden, wenn das HTML-Markup Ihrer gesamten Website fertig ist und Sie es als völlig statisch betrachten. Mit anderen Worten, das bedeutet, dass Sie zuerst Ihren gesamten HTML schreiben müssen und dann mit dem Schreiben Ihres CSS beginnen, aber wer macht das wirklich so?
Um zu vermeiden, dass eine kleine Änderung in Ihrem Markup zu Änderungen oder Umformulierungen riesiger Teile Ihres CSS führt, sind Klassen zweifellos eine geeignete (die beste?) Methode. Einer ihrer größten Vorteile ist, dass sie Ihr CSS unabhängiger von der Struktur Ihres Markups machen und somit eine größere Flexibilität bei Code-Änderungen bieten. Und Klassen könnten auch leicht von Javascript manipuliert werden.
Ich könnte mir vorstellen, dass die meisten Leute CSS-Klassen selten verwenden, weil sie denken, dass sie ihren HTML-Code so ordentlich wie möglich halten wollen, aber stattdessen versuchen, es auf der CSS-Seite zu tun, indem sie solch fragile Konstrukte wie „header > h1 + p {…}“ verwenden.
Und warum sind IDs so beliebt?
Nun, ich glaube, weil sie die Möglichkeit bieten, die Regeln auf einen überschaubaren Teil der Seite/des Standorts zu beschränken. Und aufgrund ihrer Spezifität stellen sie sicher, dass die Stile geliefert werden, unabhängig davon, welche anderen Selektoren übereinstimmen.
Aber selbst bei der ausgiebigen Verwendung von Klassen stecken Sie immer noch im Kaskaden- und Spezifitätskonzept von CSS fest. Denken Sie zum Beispiel nur an "Responsive Design" und die Verwendung von Media Queries. In der realen Welt müssen Sie also (oft) mehrere Klassen auf ein Element anwenden und diese auch in Ihrem CSS verketten (ein typischer Anwendungsfall ist die Verwendung von Modernizr).
Und wenn Sie später eine neue Seite zu Ihrer Website hinzufügen, sind Sie sich dann noch aller Ihrer Klassen bewusst, die Sie zuvor in Ihrem CSS definiert haben?
Und Sie werden eine bestehende Klasse später nicht mehr ändern, weil die Auswirkungen unkalkulierbar sind.
Die Frage ist: "Warum sollte ich?"
Sie können Ihre Selektoren leicht gruppieren, indem Sie eine neue ID hinzufügen oder eine frühere ID in eine Klasse ändern und so weiter. Und da CSS vollständig vom Markup abhängt, ist es unvermeidlich, dass bestimmte Änderungen an Ihrem Markup auch Änderungen an Ihrem CSS mit sich bringen.
Meiner Meinung nach ist es eine Tatsache, dass CSS von Natur aus zumindest ein wenig ineffizient ist. Aber müssen wir uns wirklich darum kümmern?
Vergessen Sie nicht die Barrierefreiheits-Skip-Menüs! Dafür brauchen wir IDs und für eine bessere JS-Performance.
Ich muss Ihnen einfach für Ihr http://shoptalkshow.com/episodes/034-with-jeremy-keith/ danken – wo er die Wiederverwendung von HTML5-Elementen (wie Header) mit ARIA-Rollen zur Erzielung von Spezifität beschreibt. Dieser Ratschlag hat mein Markup für immer bereinigt und verändert. Das ist meine Linie im Sand!
Die Verwendung von IDs ist in Ordnung, wirklich.
Sie müssen vielleicht "schlauer" sein, um zu wissen, wie und warum Sie sie verwenden. "Schlauer" als der Typ, der FFOI nur Klassen benutzt.
Außerdem ist der WAHRE Name "chile" und nicht "chili" – Chile Mexicano
Im Allgemeinen benutze ich selbst nur Klassen (wenn möglich – WordPress, du Witzbold, ich schaue dich an).
Ich bin mir nicht wirklich sicher, warum ich in diese Denkweise geraten bin. Ich erinnere mich vage daran, vor Jahren gelesen zu haben, dass die Verwendung von Klassen einen Leistungsvorteil hatte. Ich schätze, das ist insgesamt gering, aber ich bin seitdem bei diesem Ansatz geblieben.
Entgegen dem, was Sie gelesen haben, habe ich gelesen, dass IDs tatsächlich eine bessere Leistung haben.
Sie haben definitiv eine bessere Leistung, das gesamte Dokument muss durchsucht werden, um alle Klassen auszuwählen, aber das ID-Element muss nur gefunden werden, wenn ein ID-Selektor verwendet wird. Die Leistung von CSS war für mich nie ein großes Problem, außer bei der Verwendung einiger neuer CSS3-Techniken.
Ich zögere irgendwie, meine Verwendung von IDs ganz einzustellen. Da ich sehr technisch bin, ist es sehr wichtig zu zeigen, was ich mir beim Schreiben des Codes gedacht habe, d.h. es soll immer nur EIN Hauptmenü geben und die Seite ist ungültig, wenn es zwei gibt.
Dennoch verliert man mit guter Benennung nicht viel und es sollte hoffentlich zu allgemeinerem Code führen, wie Chris sagt.
Chili sollte niemals verschwendet werden! Jedenfalls benutze ich IDs und Klassen, um Top-Hierarchie-Stile von anderen zu unterscheiden. Ich stimme nicht zu, sie ganz fallen zu lassen.
Was ist mit Formularen, sind sie eine Sonderausnahme oder sollten wir immer noch das "for"-Attribut zusammen mit einer ID am Label verwenden?
Wenn das Formularelement innerhalb des Labels liegt, dann ist das `for`-Attribut nicht notwendig.
Wenn Sie eine ID für das Label verwenden möchten, liegt das bei Ihnen. Wenn Sie es doch tun, seien Sie versichert, es ist absolut in Ordnung.
Wenn Sie also nur Klassen verwenden, könnten Sie nicht auch nur IDs verwenden? Denn abgesehen von der Spezifität und der allgemeinen Regel, dass IDs eindeutig sein sollten, glaube ich nicht, dass es einen Unterschied gibt? Oder gibt es tatsächlich einen Unterschied in der Art und Weise, wie Browser IDs und Klassen rendern/cachen/performen?
Guter Punkt. Die ausschließliche Verwendung von IDs wäre jedoch nahezu unmöglich, um Komponenten wiederzuverwenden.
Was OOCSS betrifft, so wäre die ausschließliche Verwendung von IDs das Gegenteil, und wir wissen alle, dass OOCSS eine gute Praxis ist.
Ich glaube, ich habe mal gehört (oder gelesen), dass Aaron Gustafson auf einer Webdesign-Konferenz sagte, dass IDs tatsächlich eine bessere Leistung als Klassen haben. Ich muss ihn noch einmal fragen, es scheint nichts zu diesem Thema zu geben.
Ich kann Chris nur zustimmen. Als ich zum ersten Mal davon hörte, gingen meine Augen weit auf, aber es macht mein Leben viel einfacher.
Warum benutzt du keine IDs?! Oft gibt es Elemente, die nur einmal auf der Seite vorkommen. Du bist ein kluger Junge, sicher würdest du einfach wissen, wann und wo man eine ID anstelle einer Klasse verwendet?
Warum kann man keine IDs und OOCSS haben? Könnte man so etwas haben und die Vorteile von IDs und OOCSS nutzen?
Hüstel,
So etwas wie* <element id=”specific_stuff” class=”generci_stuff />
Ich finde in diesem Artikel einige Weisheiten. Wichtiger als der Kampf um IDs/Klassen (ich persönlich benutze keine IDs) ist die Tatsache, dass man nachdenkt und recherchiert, eine Entscheidung trifft, von der man glaubt, dass sie die Art und Weise, wie Dinge weltweit gemacht werden, verbessern wird, und seinen Teil beiträgt.
Ich benutze immer noch IDs, aber ich weiß, dass ich es nicht sollte und werde eine Linie im Sand ziehen.
The Dude Abides
Sobald ich CSS wirklich zu verstehen begann, hörte ich auf, IDs zu verwenden, weil ich während der Entwicklung zwangsläufig Code wiederverwenden wollte und dann eine ID in eine Klasse ändern musste. Alles begann damit, dass ich etwas tun wollte, das nur mit einer Klasse funktionierte, und da fielen für mich die IDs weg.
Obwohl ich gewohnheitsmäßig Klassen verwende, gibt es Orte, an denen ich IDs verwenden könnte. Ein Beispiel ist, wenn ich dieselbe Klasse mehr als einmal auf einer Seite verwende, sie aber leicht unterschiedlich haben möchte, d. h. andere Hintergrundfarbe oder Hintergrundbild oder eine andere Schriftart oder Zeilenhöhe. In diesem Fall könnten Sie eine ID verwenden, um sie zu ändern. Ich verwende jedoch aus Gewohnheit Klassen und tendiere in solchen Fällen immer noch dazu, Klassen zu verwenden. Seltsamerweise ist der einzige Ort, an dem ich immer noch eine ID verwende, bei Formularen. Wer hätte das gedacht.
Ich stimme D zu, sobald man CSS wirklich versteht, hört man auf, IDs zu verwenden. Außer in dem Fall, dass man den Code nicht wiederverwenden möchte. Sobald ich es verstanden hatte, änderte das meine Denkweise über CSS und die Entwicklung, da die Wiederverwendung von Code viel Zeit sparen kann.
Was wir wirklich brauchen, ist eine Möglichkeit, OOCSS rein in CSS zu erreichen. Die Änderung von Klassenattributen im HTML unserer Vorlagen bei Bedarf an einem Design-Tweak anstelle von nur dem Anpassen von CSS-Dateien fühlt sich wie ein Schritt zurück an.
Ich benutze nie IDs für Styling und versuche auch, sie nicht anderweitig zu verwenden. Es fühlt sich einfach nicht richtig an.
ArleyM und Andy Griffin haben beide darauf hingewiesen, dass die Verwendung von jQuery die Verwendung von IDs rechtfertigen würde, da dies einer der häufigsten Optimierungstipps für jQuery-Skripte ist.
Sie selbst (Chris) haben sehr oft gesagt und bewiesen, wie wichtig jQuery in Ihrer Arbeit ist.
Meine Frage ist also: Würden Sie sagen, dass bei der Verwendung von jQuery
A- die Verwendung von IDs in Ordnung ist, als eine dieser Situationen, in denen man "muss", wie Ben Frain sagte (http://benfrain.com/never-use-ids-as-selectors-unless-you-have-to/)
B- der Geschwindigkeitsvorteil der Verwendung von IDs im Vergleich zum Verzicht auf IDs in meiner Arbeit so gering ist, dass ich sie nicht verwenden werde
C- es keinen wirklichen Geschwindigkeitsvorteil bei der Verwendung von IDs gibt, es ist eine urbane Legende
Vielen Dank