Jaka jest standardowa konwencja nazewnictwa dla identyfikatorów i klas html / css?

Czy zależy to od używanej platformy, czy też istnieje wspólna konwencja, którą sugeruje większość deweloperów?

Istnieje kilka opcji:

1. id="someIdentifier"' - wygląda całkiem spójnie z kodem javascript.
2. id="some-identifier" - wygląda bardziej jak atrybuty HTML5 i inne rzeczy w HTML.
3. id="some_identifier" - wygląda dość spójnie z kodem ruby ​​i nadal jest prawidłowym identyfikatorem wewnątrz Javascript

Myślałem, że powyższe punkty 1 i 3 mają największy sens, ponieważ grają ładniej z Javascriptem.

Czy jest na to odpowiednia odpowiedź?

Nie ma jednego

Cały czas używam podkreślników, ponieważ łączniki zaburzają podświetlanie składni mojego edytora tekstów (Gedit), ale taka jest osobista preferencja.

Widziałem wszystkie te konwencje stosowane wszędzie. Użyj tego, co uważasz za najlepsze - tego, które wygląda najlepiej dla Ciebie / najłatwiejsze do przeczytania, a także najłatwiejsze do pisania, ponieważ będziesz go często używać. Na przykład, jeśli masz klawisz podkreślenia na spodzie klawiatury (mało prawdopodobne, ale całkowicie możliwe), trzymaj się łączników. Po prostu idź z tym, co najlepsze dla siebie. Ponadto wszystkie 3 z tych konwencji są łatwo czytelne. Jeśli pracujesz w zespole, pamiętaj o przestrzeganiu konwencji określonej przez zespół (jeśli istnieje).

Aktualizacja 2012

Z czasem zmieniłem sposób programowania. Teraz używam teraz wielbłąda ( thisIsASelector) zamiast łączników; Uważam to drugie za raczej brzydkie. Używaj tego , co wolisz, co z czasem może się łatwo zmienić.

Aktualizacja 2013

Wygląda na to, że lubię mieszać co roku ... Po przejściu na Sublime Text i użyciu Bootstrap przez jakiś czas wróciłem do myślników. Dla mnie teraz wyglądają o wiele czystiej niż un_der_scores lub camelCase. Moja pierwotna uwaga jest nadal aktualna: nie ma standardu.

Aktualizacja 2015

Ciekawym narożnikiem z konwencjami jest tutaj Rust . Naprawdę podoba mi się ten język, ale kompilator ostrzeże Cię, jeśli zdefiniujesz coś przy użyciu czegoś innego niż underscore_case. Możesz wyłączyć ostrzeżenie, ale interesujące jest to, że kompilator zdecydowanie sugeruje konwencję domyślnie. Wyobrażam sobie, że w większych projektach prowadzi to do czystszego kodu, co nie jest niczym złym.

Aktualizować 2016 ( pan poprosił o nim)

Przyjęłam standard BEM dla moich projektów na przyszłość. Nazwy klas są dość szczegółowe, ale myślę, że zapewnia dobrą strukturę i możliwość ponownego wykorzystania klas i CSS, które się z nimi wiążą. Podejrzewam, że BEM jest w rzeczywistości standardem (więc mój nostaje się yesbyć może), ale nadal zależy od ciebie, co zdecydujesz się wykorzystać w projekcie. Co najważniejsze: bądź zgodny z tym, co wybierzesz.

Aktualizować 2019 ( pan poprosił o nim)

Po dłuższej pracy bez pisania CSS zacząłem pracować w miejscu, które używa OOCSS w jednym z ich produktów. Osobiście uważam, że dość nieprzyjemne jest zaśmiecanie klas wszędzie, ale nie muszę przeskakiwać między HTML a CSS przez cały czas, co wydaje się dość produktywne.

Nadal jednak jestem nastawiony na BEM. Jest to szczegółowe, ale dzięki przestrzeni nazw praca z komponentami React jest bardzo naturalna. Doskonale nadaje się również do wybierania określonych elementów podczas testowania w przeglądarce.

OOCSS i BEM to tylko niektóre ze standardów CSS. Wybierz taki, który Ci odpowiada - wszystkie są pełne kompromisów, ponieważ CSS po prostu nie jest tak dobry .

Aktualizacja 2020

Nudna aktualizacja w tym roku. Nadal używam BEM. Moje stanowisko nie zmieniło się tak naprawdę od aktualizacji 2019 z powodów wymienionych powyżej. Używaj tego, co działa dla Ciebie, które skaluje się wraz z rozmiarem zespołu i ukrywa tyle, albo tyle słabego zestawu funkcji CSS, ile chcesz.

W Google znajduje się przewodnik po stylach css & html, który zaleca używanie zawsze łącznika: https://google.github.io/styleguide/htmlcssguide.html#ID_and_Class_Name_Delimiters .

Sugeruję użycie podkreślnika zamiast myślnika (-), ponieważ ...

<form name="myForm">
  <input name="myInput" id="my-Id" value="myValue"/>
</form>

<script>
  var x = document.myForm.my-Id.value;
  alert(x);
</script>

możesz łatwo uzyskać dostęp do wartości przez id w ten sposób. Ale jeśli użyjesz łącznika, spowoduje to błąd składniowy.

To stara próbka, ale może działać bez jquery - :)

dzięki @jean_ralphio istnieje sposób na obejście tego

var x = document.myForm['my-Id'].value;

Styl Dash byłby stylem kodu Google, ale tak naprawdę nie lubię tego. Wolę TitleCase dla id i camelCase dla klasy.

tl; dr;

Nie ma jednej prawdziwej odpowiedzi. Możesz wybrać jeden z wielu dostępnych lub stworzyć własne standardy w oparciu o to, co ma sens, w zależności od tego, z kim pracujesz. I jest w 100% zależny od platformy.

Oryginalny post

Jeszcze jeden alternatywny standard do rozważenia:

<div id="id_name" class="class-name"></div>

I w twoim skrypcie:

var variableName = $("#id_name .class-name");

To po prostu używa camelCase, under_score i dzielenia wyrazów odpowiednio dla zmiennych, identyfikatorów i klas. Przeczytałem o tym standardzie na kilku różnych stronach internetowych. Nadmiarowość jest nieco redundantna w selektorach css / jquery, ale ułatwia wykrywanie błędów. np .: Jeśli widzisz .unknown_namelub #unknownNamew swoim pliku CSS, wiesz, że musisz dowiedzieć się, o co tak naprawdę chodzi.

AKTUALIZACJA 2019

(Łączniki nazywane są „kebab-case”, podkreślenia nazywane są „snake_case”, a następnie masz „TitleCase”, „pascalCase”)

Osobiście nie lubię łączników. Pierwotnie opublikowałem to jako jedną z alternatyw (ponieważ zasady są proste). Jednak łączniki sprawiają, że skróty wyboru są bardzo trudne (podwójne kliknięcie, ctrl/ option+ left/ righti ctrl/ cmd+ Dw vsCode. Ponadto nazwy klas i nazwy plików są jedynym miejscem, w którym działają łączniki, ponieważ prawie zawsze są w cudzysłowach lub w css itp. Ale skrót nadal obowiązuje.

Oprócz zmiennych, nazw klas i identyfikatorów chcesz także przyjrzeć się konwencjom nazw plików. I Git Oddziały.

Grupa kodująca z mojego biura faktycznie odbyła spotkanie miesiąc lub dwa temu, aby omówić, jak zamierzamy nazwać różne rzeczy. W przypadku gałęzi git nie mogliśmy zdecydować między 321-the_issue_description lub 321_the-issue-description. (Chciałem napisać 321_ opis problemu, ale moim współpracownikom się to nie podobało).

Przykład demonstrujący pracę ze standardami innych ludzi ...

Vue.js ma standard. W rzeczywistości mają dwa alternatywne standardy dla kilku swoich przedmiotów. Nie lubię obu ich wersji nazw plików. Zalecają oni albo "/path/kebab-case.vue"albo "/path/TitleCase.Vue". Pierwsza z nich jest trudniejsza do zmiany nazwy, chyba że specjalnie próbujesz zmienić nazwę części. To ostatnie nie jest dobre dla kompatybilności między platformami. Wolałbym "/path/snake_case.vue". Jednak podczas pracy z innymi ludźmi lub istniejącymi projektami ważne jest, aby postępować zgodnie z ustalonymi już standardami. Dlatego używam kebab-case dla nazw plików w Vue, mimo że całkowicie na to narzekam. Ponieważ nieprzestrzeganie tego oznacza zmianę wielu plików konfigurowanych przez vue-cli.

Nie ma uzgodnionej konwencji nazewnictwa dla HTML i CSS. Ale możesz zbudować swoją nomenklaturę wokół projektu obiektu. Mówiąc dokładniej, co nazywam własnością i relacjami.

Własność

Słowa kluczowe opisujące obiekt mogą być oddzielone łącznikami.

nowy samochód skręcił w prawo

Słowa kluczowe opisujące obiekt można również podzielić na cztery kategorie (które należy uporządkować od lewej do prawej): Obiekt, Deskryptor obiektu, Akcja i Deskryptor akcji.

samochód - rzeczownik i
nowy obiekt - przymiotnik i deskryptor obiektu, który bardziej szczegółowo opisuje obiekt
zwrócony - czasownik i czynność należąca do
prawa obiektu - przymiotnik i opis deskryptora akcji akcja bardziej szczegółowo

Uwaga: czasowniki (akcje) powinny być w czasie przeszłym (odwrócone, wykonane, uruchomione itp.).

Związek

Obiekty mogą również mieć relacje takie jak rodzic i dziecko. Akcja i deskryptor akcji należą do obiektu nadrzędnego, nie należą do obiektu podrzędnego. W przypadku relacji między obiektami można użyć podkreślenia.

samochód-nowy-skręcony-w prawo_koło-lewy-skręcony w lewo

• samochód-nowy-skręcony w prawo (zgodnie z zasadą własności)
• koło-lewo-skręcił w lewo (zgodnie z zasadą własności)
• car-new-Turn-Right_wheel-Left-Turn-Left (zgodnie z zasadą relacji)

Uwagi końcowe:

• Ponieważ w CSS nie jest rozróżniana wielkość liter, lepiej jest pisać wszystkie nazwy małymi literami (lub dużymi literami); unikaj wielbłąda lub pascala, ponieważ mogą prowadzić do niejednoznacznych nazw.
• Dowiedz się, kiedy użyć klasy, a kiedy identyfikator. Nie chodzi tylko o to, że identyfikator zostanie użyty raz na stronie internetowej. Przez większość czasu chcesz używać klasy, a nie identyfikatora. Komponenty sieciowe, takie jak (przyciski, formularze, panele, itp.) Powinny zawsze używać klasy. Identyfikatory mogą łatwo prowadzić do konfliktów nazw i powinny być używane oszczędnie do oznaczania przestrzeni nazw. Powyższe pojęcia własności i relacji dotyczą nazewnictwa zarówno klas, jak i identyfikatorów i pomogą uniknąć konfliktów nazw.
• Jeśli nie podoba ci się moja konwencja nazewnictwa CSS, istnieje jeszcze kilka innych: Konwencja nazewnictwa strukturalnego, Konwencja nazewnictwa prezentacyjnego, Konwencja nazewnictwa semantycznego, Konwencja nazewnictwa BEM, Konwencja nazewnictwa OCSS itp.

Innym powodem, dla którego wielu preferuje łączniki w identyfikatorze CSS i nazwach klas, jest funkcjonalność.

Używanie skrótów klawiaturowych, takich jak option+ left/ right(lub ctrl+ left/ rightw systemie Windows), do przechodzenia kodu słowo po słowie zatrzymuje kursor przy każdym myślniku, umożliwiając precyzyjne przechodzenie przez identyfikator lub nazwę klasy za pomocą skrótów klawiaturowych. Podkreślenia i camelCase nie są wykrywane, a kursor przesuwa się nad nimi, jakby to było jedno słowo.

Niedawno zacząłem uczyć się XML. Wersja podkreślona pomaga mi oddzielić wszystko, co dotyczy XML (DOM, XSD itp.) Od języków programowania, takich jak Java, JavaScript (wielbłąd). Zgadzam się z Tobą, że użycie identyfikatorów dozwolonych w językach programowania wygląda lepiej.

Edycja: Być może nie ma to związku, ale tutaj znajduje się link do reguł i zaleceń dotyczących nazewnictwa elementów XML, które stosuję podczas nazywania identyfikatorów (sekcje „Zasady nazewnictwa XML” i „Najlepsze praktyki nazewnictwa”).

http://www.w3schools.com/xml/xml_elements.asp

Myślę, że to zależy od platformy. Podczas programowania w .Net MVC używam małych liter i myślników w stylu bootstrap dla nazw klas, ale dla identyfikatorów używam PascalCase.

Powodem tego jest to, że moje widoki są poparte silnie typowanymi modelami widoków. Właściwości modeli C # są wielkością pascal. Ze względu na powiązanie modelu z MVC sensowne jest, aby nazwy elementów HTML, które łączą się z modelem, były zgodne z właściwościami modelu widoku, które są wielkością pascal. Dla uproszczenia moje identyfikatory używają tej samej konwencji nazewnictwa co nazwy elementów, z wyjątkiem przycisków opcji i pól wyboru, które wymagają unikalnych identyfikatorów dla każdego elementu w nazwanej grupie wejściowej.