it-swarm.com.de

Praktische Überlegungen zu HTML / CSS-Namenskonventionen (Syntax)

Frage: Was sind die praktischen Überlegungen für die Syntax in class und id Werten?

Beachten Sie, dass ich nicht nach der Semantik frage, d. H. Nach den tatsächlich verwendeten Wörtern, wie zum Beispiel beschrieben in diesem Blogpost . Auf dieser Seite der Namenskonventionen gibt es bereits viele Ressourcen, die meine Suche nach praktischen Informationen zu den verschiedenen syntaktischen Bits verdecken: Gehäuse, Verwendung der Interpunktion (speziell der - dash), bestimmte zu verwendende oder zu vermeidende Zeichen usw.

Um die Gründe zusammenzufassen, warum ich diese Frage stelle:

  • Die Benennung Einschränkungen auf id und Klasse führt natürlich nicht zu Konventionen
  • Die Fülle an Ressourcen auf der semantischen Seite von Namenskonventionen verdeckt die Suche nach syntaktischen Überlegungen
  • Ich konnte keine maßgebliche Quelle dafür finden
  • Es gab noch keine Frage zu SE-Programmierern zu diesem Thema :)

Einige der Konventionen, die ich in Betracht gezogen habe:

  1. UpperCamelCase, hauptsächlich als Cross-Over-Gewohnheit der serverseitigen Codierung
  2. lowerCamelCase, aus Gründen der Konsistenz mit JavaScript-Namenskonventionen
  3. css-style-classes, Was mit der Benennung der CSS-Eigenschaften übereinstimmt (kann jedoch ärgerlich sein, wenn Strg + Umschalt + Pfeiltaste Text auswählen).
  4. with_under_scores, Was ich persönlich nicht oft gesehen habe
  5. alllowercase, einfach zu merken, kann aber für längere Namen schwer zu lesen sein
  6. UPPERCASEFTW, um Ihre Programmierkollegen zu ärgern (möglicherweise in Kombination mit Option 4 zur besseren Lesbarkeit)

Und wahrscheinlich habe ich auch einige wichtige Optionen oder Kombinationen ausgelassen. Also: Welche Überlegungen gibt es für die Benennung von Konventionen und zu welcher Konvention führen sie?

28
Jeroen

Kopfgeld oder nicht, bis zu einem gewissen Grad wird die Wahl immer eine "Frage der Präferenz" sein - wie würden Sie sich schließlich fühlen, wenn das W3C eine bestimmte Konvention empfehlen (oder sogar auferlegen) würde, die Sie nicht für richtig hielten?

Trotzdem bevorzuge ich persönlich die lowerCamelCase Konvention, und ich werde die Gründe und praktischen Überlegungen angeben, die ich verwendet habe, um mich zu entscheiden - ich werde dies durch einen Prozess der Eliminierung tun, indem ich die Nummerierung aus Ihrer Frage:

(5.) Nur nicht leicht lesbar, weil Sie nicht wissen, wann Wörter beginnen und enden.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) history_incompatibility_plus_see: Mozilla Dev Documentation .

(3.) etwas schwieriger zu erklären ... wie Sie bereits erwähnt haben, ist die Auswahl in Texteditoren ein Problem (wie bei Unterstrichen, je nach Editor), aber für mich ist es auch die Tatsache, dass es mich daran erinnert Die Syntax ist reserviert für herstellerspezifische Schlüsselwörter , auch wenn diese mit einem Bindestrich beginnen und Wörter durch diese getrennt sind.

So bleiben Ihre (1.) und (2.), UpperCamelCase bzw. LowerCamelCase. Trotz der mentalen Verbindung zu Java Klassen (die nach einer klareren Konvention UpperCamelCase sind), CSS-Klasse Namen scheinen mir besser dran zu sein, wenn man mit einem Kleinbuchstaben beginnt. Vielleicht liegt das an XHTML-Element- und Attributnamen , aber ich denke, Sie könnten auch den Fall machen, dass CSS-Klassen verwendet werden UpperCamelCase würde helfen, sie auseinander zu setzen. Wenn Sie einen anderen Grund benötigen, verwendet das W3C lowerCamelCase in Beispiele für gute Klassennamen (obwohl die URL selbst ärgerlicherweise nicht mit mir übereinstimmt).

Ich würde aus den oben genannten Gründen von (4.), (5.) und (6.) abraten, aber annehmen, dass für einen der anderen drei Argumente vorgebracht werden könnten.

Ob Sie (oder sonst jemand) mir in dieser Angelegenheit zustimmen oder nicht, liegt jedoch bei Ihnen. Die Tatsache, dass Sie noch keine eindeutige Antwort erhalten haben, die maßgebliche Quellen zitiert, kann als Hinweis darauf verstanden werden, dass es gibt ) ist nicht so etwas wie ein definitiver Standard zu diesem Thema (sonst würden wir es alle verwenden). Ich bin mir nicht sicher, ob das unbedingt eine schlechte Sache ist.

18

Wörter in CSS-Klassennamen sollten durch Bindestriche (class-name) Getrennt werden, da Wörter in CSS-Eigenschaften und Pseudoklassen auf diese Weise getrennt werden und ihre Syntax durch CSS-Spezifikationen .

Wörter in ID-Namen sollten ebenfalls durch Bindestriche getrennt werden, um dem syntaktischen Stil von Klassennamen zu entsprechen, da ID-Namen häufig in URLs verwendet werden und der Bindestrich das ursprüngliche und häufigste Worttrennzeichen in URLs ist.

7
Emanuil Rusev

Es ist meistens eine Frage der Präferenz; Es gibt keinen etablierten Standard, geschweige denn eine maßgebliche Quelle in dieser Angelegenheit. Verwenden Sie alles, womit Sie sich am wohlsten fühlen. Sei einfach konsequent.

Persönlich verwende ich css-style-with-dashes, Aber ich versuche, Klassennamen mit mehreren Wörtern zu vermeiden und wo immer möglich mehrere Klassen zu verwenden (also button important default Statt button-important-default). Nach meiner Erfahrung scheint dies auch die beliebteste Wahl unter hochwertigen Websites und Frameworks zu sein.

Kleinbuchstaben mit Bindestrichen sind auch einfacher einzugeben als die anderen Optionen (mit Ausnahme der schwer lesbaren Konvention nowordseparatorswhatsoever), zumindest bei US-Tastaturen, da die Umschalttaste nicht erforderlich ist.

Für IDs gibt es die zusätzliche praktische Überlegung, dass Bindestriche nicht so gut funktionieren, wenn Sie Elemente anhand ihrer ID direkt in Javascript referenzieren möchten (z. B. document.forms[0].btn_ok). Wenn Sie jedoch jQuery verwenden, Sie werden sie wahrscheinlich sowieso über $() verwenden, also können Sie einfach $('#btn-ok') haben, was diesen Punkt meistens strittig macht.

Eine andere Konvention, auf die ich stoße, verwendet regelmäßig ungarische Warzen in IDs, um den Elementtyp anzugeben, insbesondere für Formularsteuerelemente. Sie hätten also #lblUsername, #tbUsername, #valUsername für die Bezeichnung, Eingabe und den Validator des Benutzernamens.

3
tdammers

Ich bin der festen Überzeugung, dass die Konsistenz am wichtigsten ist.

Es gibt zwei Möglichkeiten, dies zu betrachten:

  1. Ein gutes Argument kann für alllowercase oder css-style-clauses Vorgebracht werden (wahrscheinlich die bessere Wahl), da sie am besten mit dem Code übereinstimmen, in dem sie sich befinden. Dies verleiht einen natürlicheren Fluss Der Code insgesamt und nichts wird stören oder fehl am Platz sein.

  2. Ein ebenso gutes Argument kann für einen Stil angeführt werden, der sich von HTML-Tag-Namen oder CSS-Klauseln unterscheidet, wenn IDs und Klassen so unterschieden werden, dass die Lesbarkeit verbessert wird. Wenn Sie beispielsweise UpperCamelCase für IDs und Klassen verwendet haben und es nicht für ein anderes Konstrukt oder einen anderen Zweck verwendet haben, wissen Sie, dass Sie jedes Mal, wenn Sie ein Token in diesem Format gesehen haben, auf eines gestoßen sind. Eine Einschränkung, die dies mit sich bringen könnte, ist, dass es am effektivsten wäre, wenn jede ID oder Klasse ein Name mit 2+ Wörtern wäre, aber das ist in vielen Fällen vernünftig.

Beim Schreiben dieser Antwort stellte ich fest, dass ich viel mehr zur zweiten Wahl neige, aber ich werde beide verlassen, weil ich denke, dass beide Fälle ihre Berechtigung haben.

2
asfallows