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

Frage: Wie lauten die praktischen Überlegungen zu Syntax classund idWerten?

Beachten Sie, dass ich nicht nach der Semantik frage , dh nach den tatsächlich verwendeten Wörtern, wie sie beispielsweise in diesem Blogpost beschrieben sind . Auf dieser Seite der Namenskonventionen gibt es bereits viele Ressourcen, die meine Suche nach praktischen Informationen zu den verschiedenen syntaktischen Elementen verdecken : Groß- und Kleinschreibung, Verwendung von Interpunktionen (insbesondere der -Bindestrich), bestimmte zu verwendende oder zu vermeidende Zeichen usw.

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

• Die Namensbeschränkungen auf id und Klasse natürlich nicht zu irgendwelchen Konventionen führen
• Die Fülle an Ressourcen auf der semantischen Seite von Namenskonventionen verdeckt die Suche nach syntaktischen Überlegungen
• Ich konnte keine autorisierende Quelle dazu finden
• Es gab noch keine Fragen zu SE Programmers zu diesem Thema :)

Einige der Konventionen, über die ich nachgedacht habe:

1. UpperCamelCase, hauptsächlich als Cross-Over-Gewohnheit von serverseitiger Codierung
2. lowerCamelCase, um die Übereinstimmung mit den JavaScript-Namenskonventionen zu gewährleisten
3. css-style-classesDies entspricht der Benennung von CSS-Eigenschaften (kann jedoch ärgerlich sein, wenn Sie die Tastenkombination Strg + Umschalt + Pfeil drücken).
4. with_under_scores, die ich persönlich nicht viel gebraucht gesehen habe
5. alllowercase, einfach zu merken, aber für längere Namen schwer zu lesen
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 zur Benennung von Konventionen und zu welchen Konventionen führen sie?

Kopfgeld oder nicht, bis zu einem gewissen Grad wird die Wahl immer eine "Präferenzsache" sein - wie würden Sie sich fühlen, wenn das W3C eine bestimmte Konvention empfiehlt (oder sogar auferlegt), die Sie nicht für richtig hielten?

Allerdings bevorzuge ich persönlich die lowerCamelCaseKonvention und gebe die Gründe und praktischen Überlegungen an, die ich verwendet habe, um mich zu entscheiden - ich werde dies durch einen Ausschlussprozess tun, wobei ich die Nummerierung aus Ihrer Frage verwende:

(5.) nur nicht leicht lesbar, da nicht bekannt ist, wo die Wörter beginnen und enden.

(6.) ASABOVEPLUSITSANNOYINGLIKEONESHOUTING.

(4.) history_incompatibility_plus_see: Mozilla Dev Documentation .

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

So bleiben Ihre (1.) und (2.), UpperCamelCase und LowerCamelCase. Trotz der mentalen Verbindung zu Java- Klassen (nach einer klareren Definition UpperCamelCase) sind CSS-Klassennamen meiner Meinung nach besser geeignet, mit einem Kleinbuchstaben zu beginnen. Möglicherweise liegt das an den Namen der XHTML-Elemente und -Attribute , aber ich denke, Sie könnten auch den Fall herbeiführen, dass die Verwendung von UpperCamelCase durch CSS-Klassen dazu beiträgt, diese voneinander zu unterscheiden. Wenn Sie einen anderen Grund benötigen, verwendet das W3C lowerCamelCase in Beispielen 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, nehme jedoch an, dass für die anderen drei Argumente vorgebracht werden könnten.

Ob Sie (oder sonst jemand) in dieser Angelegenheit mit mir einverstanden sind, liegt jedoch bei Ihnen. Die Tatsache , dass Sie keine bekamen definitive Antwort zitiert zuverlässige Quellen jetzt kann als Hinweis genommen werden , dass es nicht ist so etwas wie eine bestimmte Norm zu diesem Thema (sonst würden wir es alle verwenden). Ich bin mir nicht sicher, ob das unbedingt eine schlechte Sache ist.

Wörter in CSS-Klassennamen sollten mit Bindestrichen ( class-name) getrennt werden, da Wörter in CSS-Eigenschaften und Pseudoklassen auf diese Weise getrennt werden und ihre Syntax durch die CSS-Spezifikationen definiert wird .

Wörter in ID-Namen sollten auch mit Bindestrichen 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.

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

Ich persönlich benutze css-style-with-dashes, aber ich versuche, Mehrwortklassennamen zu vermeiden und, wo immer möglich, mehrere Klassen zu verwenden (also button important defaultnicht button-important-default). Aus meiner Erfahrung scheint dies auch die beliebteste Wahl unter qualitativ hochwertigen Websites und Frameworks zu sein.

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

Für IDs gibt es die zusätzliche praktische Überlegung, dass, wenn Sie Elemente anhand ihrer ID direkt in Javascript referenzieren möchten (z. B. document.forms[0].btn_ok), Bindestriche nicht so gut funktionieren - aber wenn Sie jQuery verwenden, werden Sie wahrscheinlich dies tun benutze sie $()trotzdem durch , dann kannst du sie einfach haben $('#btn-ok'), was diesen Punkt meistens umstritten macht.

Für das Protokoll, eine andere Konvention ich über kommen regelmäßig verwendet ungarischen Warzen in IDs den Elementtyp , um anzuzeigen, insbesondere für Formular - Steuerelemente - so müssten Sie #lblUsername, #tbUsername, #valUsernamefür den Benutzernamen Etikett, Eingang und Validator.

Ich bin der festen Überzeugung, dass die Konsistenz das Wichtigste ist.

Es gibt zwei Möglichkeiten, dies zu betrachten:

1. Ein gutes Argument kann für alllowercaseoder css-style-clauses(wahrscheinlich die bessere Wahl) sein, weil sie mit dem Code, in dem sie sich befinden, am konsistentesten sind. Es verleiht dem Code insgesamt einen natürlicheren Fluss, und nichts wird verwirrend oder fehl am Platz sein .

2. Ein ebenso gutes Argument für einen Stil, der sich von HTML-Tag-Namen oder CSS-Klauseln unterscheidet, ist die Unterscheidung von IDs und Klassen, um die Lesbarkeit zu verbessern. Wenn Sie beispielsweise UpperCamelCasefür IDs und Klassen verwendet haben und es nicht für ein anderes Konstrukt oder einen anderen Zweck verwendet haben, würden Sie wissen, dass Sie jedes Mal, wenn Sie ein Token in diesem Format sahen, auf eines gestoßen sind. Eine Einschränkung, die dies auferlegen könnte, ist, dass es am effektivsten wäre, wenn jede ID oder Klasse ein Name mit mehr als 2 Wörtern wäre, aber das ist in vielen Fällen vernünftig.

Als ich diese Antwort aufschrieb, stellte ich fest, dass ich eher zur zweiten Wahl neige, aber ich werde beide verlassen, weil ich denke, dass beide Fälle von Nutzen sind.

Es ist wirklich alles eine Frage der Präferenz oder der Faulheit. CamelCase ist einfacher zu tippen, aber ich bevorzuge die Verwendung der Unterstreichungsnotation, da ich persönlich das Lesen und Debuggen einfacher finde als CamelCase. Es gibt keine festgelegte Kodierungskonvention, die eingehalten werden muss. Ich habe noch nie an einem Ort gearbeitet, der die gleichen Kodierungsrichtlinien wie der Ort zuvor hatte.

Die meisten Unternehmen haben Richtlinien, an die Sie sich im Allgemeinen halten müssen, um den Code sauber zu halten und die Arbeit für alle zu erleichtern. Wenn Sie ein Freiberufler sind, können Sie alles daran setzen, da Sie die einzige Person sind, die an dem Code arbeitet. Meiner Meinung nach gibt es nur zwei Kodierungskonventionen: CamelCase- oder Unterstreichungsnotation. Mein Rat ist, einen auszuwählen und dann dabei zu bleiben.

Sie scheinen sich einer einfachen Tatsache nicht bewusst zu sein: Die meisten CSS-Funktionen werden nicht von Programmierern ausgeführt .

Es wird von Grafikdesignern gemacht.

Sie kümmern sich nicht um unsere Bearbeitungskriege und sie kümmern sich nicht weniger darum, was wir mit der Umschalttaste machen.
Sie wissen wahrscheinlich nicht einmal, wo dieser schicke _Schlüssel ist . (oder wie es heißt)

Sie interessieren sich nicht für Code-Ästhetik , sie interessieren sich für ästhetische Ästhetik .

(Und sie können dort einen Punkt haben)

Sie lesen die Spezifikation nicht , sie erhalten das Tutorial.
Und dann überprüfen Sie die Referenzen auf w3schools.

Einige von ihnen glauben wahrscheinlich, dass sie aus Gründen keine großen Klassennamen verwenden können.
Sie stecken voller seltsamer, meist irrelevanter Missverständnisse.