Ich habe gerade skalierbare und modulare Architektur für CSS gelesen und es hat mich über ein paar Dinge nachdenken lassen. Snooks zwei Haupttentets sind:
Dies bedeutet also, dass semantische Klassennamen verwendet werden und nicht auf unsemantische Elementtypen für das Targeting angewiesen sind. Zum Beispiel, anstatt auf .someClass h5 zu zielen, wende ich stattdessen .someClass-title an, so dass die Dinge nicht kaputt gehen, wenn das h5 für etwas anderes ausgelagert wird.
Persönlich finde ich die Codierung der Hierarchie eines Elements in seinem Namen irgendwie unangenehm (auch wenn es semantisch korrekt ist). Ich würde es vorziehen, .someClass .title zu machen. Um jedoch eine Klasse als generischen Titel zu verwenden, müssen Sie akzeptieren, dass diese Klasse in vielen verschiedenen Kontexten verwendet wird.
Ist also etwas falsch daran, die gleiche Klasse in völlig anderen Kontexten zu verwenden, wenn ich weiß, dass sie durch ein vorheriges Element im Selektor Namespaced sein wird?
Zum Beispiel sagen wir, dass ich drei verschiedene Orte auf meiner Seite habe, wo eine Klasse von "Titel" sinnvoll ist:
HTML
%Vor%CSS
%Vor%Edit: als Alohci erwähnt in seiner Antwort unten, ein Header-Tag ist nicht unsemantisch, also vielleicht Das war nicht das beste Beispiel.
Offensichtlich tue ich in diesen Kontexten etwas ganz anderes als den Titel, aber der Titel macht mit seinem Namensraum absolut Sinn, und ich habe nie die Absicht, den Titel als allgemeinen Selektor zu verwenden.
Dies scheint alle Kästchen anzukreuzen. Es ist semantisch reich, vollständig von der Implementierung entkoppelt. Zum Beispiel, wenn das letzte Beispiel in ein ol oder einen Stapel von divs geändert wurde, würde nichts brechen, und wenn der Titel in ein Div gewrappt wäre, wäre es immer noch zielgerichtet.
Das macht für mich Sinn, aber ich habe diesen Ansatz nicht oft benutzt und ich frage mich warum. Ein offensichtlicher Nachteil ist, dass Sie Klassen im Selektor verketten, aber ich denke, dass dies dem Namespacing jedes Klassennamens vorzuziehen ist.
Ich bevorzuge eine Klasse wie .title statt nur das h5-Element auszuwählen, da ich glaube, dass es den HTML-Code vom CSS entkoppelt. Wenn Sie aus irgendeinem Grund entscheiden, ob h4 oder h6 besser für die Dokumentgliederung oder ein anderes Element / Grund geeignet ist, müssten Sie Ihr CSS umgestalten, wenn Sie das Element (h5) auswählen oder eine Klasse auswählen (. Titel).
Deshalb bevorzuge ich es, ALLE THINGS und Elementselektoren zu klassifizieren, da sich das Markup im Laufe der Zeit ändern kann. Wenn Sie auf einer kleineren Site arbeiten, die nicht viele Updates enthält, ist dies möglicherweise kein Problem, obwohl Sie sich dessen bewusst sind.
Soweit es etwas falsches an der Verwendung derselben Klasse in völlig anderen Kontexten gibt, wenn Sie wissen, dass es durch ein vorheriges Element im Selektor einen Namespace erhalten wird, habe ich Gedanken dazu gemischt.
Auf der einen Seite kommen einige Bedenken in den Sinn, zum Beispiel die Verwendung / Bedeutung / Rolle von .title könnte leer sein, ohne dass es Elternauswahl ist. (.pageHeader .title) Während ich denke, dass .title ein vollkommen guter Klassenname ist, kann es für andere Entwickler schwierig sein zu verstehen, dass die Bedeutung von einem Elternselektor wie .pageHeader .title
Ein weiteres Problem ist, wenn Sie die Klasse .title für mehrere Instanzen von "Titeln" in einem Modul verwenden, können Probleme auftreten. Die Grundidee ist, dass die lokalen Scoping-Nachkommen-Selektoren manchmal zu restriktiv sind, wenn man versucht, die Wiederverwendbarkeit von .title innerhalb des Moduls zu dehnen. Ich habe eine Code-Demo eingerichtet, um zu zeigen, wovon ich rede hier .
Auf der anderen Seite sind Nachkommenselektoren eine der am häufigsten verwendeten Selektoren, speziell für ihren Zweck.
Tim Murtaugh, der einer der Entwickler ist (nicht sicher, ob er der Lead-Entwickler ist oder nicht) für A List Apart verwendet Nachfahren-Selektoren für die Mehrheit seiner Stile auf seiner persönlichen Seite.
Ich habe kürzlich diese und BEM untersucht und stimme Ihrer Schlussfolgerung zu: "Dies ist vorzuziehen, um jeden Klassennamen zu benennen."
Ich bevorzuge .pageHeader .title {...} im Vergleich zu .pageHeader__title {...}, aber es gibt immer Fälle, in denen eine Vorgehensweise in einer Situation vorteilhafter ist als die andere.
Wie bei den meisten Dingen hängt es davon ab, aber ich denke, wenn Sie die Verschachtelung nicht zu tief gehen lassen und nachdenklich mit Ihrer Verwendung umgehen, sind die Nachkommenselektoren eine leistungsstarke und gute Lösung für lokal begrenzte Stile und bieten gleichzeitig eine Lösung für die globale Festlegung von Stilen.
Zum Beispiel:
%Vor%Ich denke, es gibt sehr wenig darüber zu sagen. Was Sie tun, ist in Ordnung, obwohl es nicht die einzige Möglichkeit ist, Ihr Markup für CSS zu organisieren. Die wichtige Sache zu verstehen ist, dass Klassennamen nicht Teil von CSS sind, sie sind Teil von HTML.
Also sind die Klassen, die auf ein Element angewendet werden, nicht in HTML-Begriffen "Namespaced" von ihren Vorfahren im DOM-Baum, sondern stehen in ihrem eigenen Recht. Daher ist es sinnvoll, dass Sie für die Klassennamen jedes Elements in Ihrem Beispiel "title" verwenden, da alle Titel gleich sind.
Ein gegenteiliges Beispiel wäre die Verwendung des Klassennamens von "note", wobei auf einem Element eine Art von Kommentar, aber auf einem anderen Element eine Musiknote signalisiert wird, und dann angenommen wird, dass ihre Bedeutungen durch Inspektion von unterschieden werden können ein Vorfahrelement. So sollten HTML-Klassen nicht funktionieren.
Es ist auch bemerkenswert, dass es nichts Unähnliches an <h5> gibt. Die Verwendung von Elementnamen in Ihren CSS-Selektoren ist nur eine weitere Möglichkeit, die Beziehung zwischen den Elementen zu beschreiben, die Sie formatieren möchten. .product h5 als Selektor bedeutet "style fünfte Überschriften im Kontext des Unterbaums der Klasse 'product' so ...". Das ist eine andere Aussage von .product .title , was "Stilelemente des Klassentitels" im Kontext des Unterbaums der Klasse "Produkt" wie folgt bedeutet ... ". Beide Aussagen sind nützlich.
Eine sehr wichtige Sache zu beachten ist, dass Browser CSS von rechts nach links und nicht von links nach rechts lesen. Wenn Sie Ihre Selektoren also nur wenige Ebenen tief strukturieren, dann ist es mehr Arbeit für Browser.
%Vor%Das ist also ein Titel, aber in einem anderen Kontext. Browser während des Renderings überprüft, ob das Kindelement innerhalb eines bestimmten Elternelements platziert ist und wendet dann entsprechende Regeln an.
%Vor%Hier haben wir 3 sehr unterschiedliche Titel (nicht einen!), so dass der Browser keine zusätzlichen Berechnungen anstellt oder überprüft, ob das Kind ein Kind eines bestimmten Elternteils ist. Was wir hier haben, ist auch eine flachere Struktur von Modulen, die immer schön ist.
Denken Sie immer daran, dass das Verschachteln Ihrer Selektoren und ihre Benennung auf dieselbe Weise, aber in unterschiedlichem Kontext, Auswirkungen auf die Leistung haben, was nichts bedeutet, wenn Sie eine kleine persönliche Website schreiben, aber wenn Sie eine Lösung planen und bereitstellen müssen Von Millionen betrachtet, ist es wichtig zu wissen, wie man sein Markup richtig strukturiert.
Es wird manchmal als "Eltern-Kind-Beziehung" ( Ссылка ) bezeichnet und oft empfohlen, mitzugehen %Code%.
In Ihrem Fall kann .page-header-title als Komponente und .page-header als Komponente behandelt werden. RCSS ( Ссылка ) unterstützt standardmäßig .title . Ich persönlich finde es keine wirklich gute Idee. Überlegen Sie Folgendes:
.page-header > .title erbt unbeabsichtigt von .tooltip > .title .
Also würde ich mit .page-header > .title gehen.
Wenn Sie beabsichtigen, dass die Überschrift von einer Basisklasse erbt, fügen Sie einfach eine Klasse zum HTML-Element hinzu
%Vor% Jetzt enthält .page-header-title komponentenspezifische Stile und page-header-title augments mit abstrakten Titelstilen. Ja, es ist ausführlich, aber sicher. Hier, wenn Interesse besteht, meine ausführliche Meinung darüber, wie man den Stil vernünftig kaskadieren und saubere und offensichtliche Abstraktion Ссылка