Яка стандартна умова іменування для html / css ідентифікаторів та класів?

Це залежить від платформи, яку ви використовуєте, чи є загальна конвенція, яку пропонують / дотримуються більшість розробників?

Є кілька варіантів:

1. id="someIdentifier"' - виглядає досить узгоджено з кодом JavaScript.
2. id="some-identifier" - більше схожий на атрибути, схожі на html5 та інші речі в html.
3. id="some_identifier" - виглядає цілком відповідає рубіновому коду і все ще є дійсним ідентифікатором всередині Javascript

Я думав, що №1 і №3 вище мають найбільш сенс, тому що вони грають приємніше з Javascript.

Чи є правильна відповідь на це?

Немає жодної.

Я постійно використовую підкреслення, через дефіси псують виділення синтаксису мого текстового редактора (Gedit), але це особисті переваги.

Я бачив усі ці умовності, що використовуються всюди. Використовуйте той, який ви вважаєте найкращим - той, який виглядає найприємніше / найпростішим для читання, а також найпростіший набір, тому що ви будете користуватися ним багато. Наприклад, якщо у вас є нижня клавіша підкреслення на нижній стороні клавіатури (навряд чи, але цілком можливо), тоді дотримуйтесь дефісів. Просто займіться тим, що найкраще для себе. Крім того, всі 3 ці конвенції легко читаються. Якщо ви працюєте в команді, не забудьте дотримуватися визначеної командою конвенції (якщо така є).

Оновлення 2012 року

Я змінив те, як програмую з часом. Я зараз використовую справу верблюда ( thisIsASelector) замість дефісів; Я вважаю останнє досить потворним. Використовуйте все, що вам зручніше, що може з часом легко змінюватися.

Оновлення 2013 року

Схоже, мені подобається щорічно перемішувати речі ... Після переходу на піднесений текст та використання Bootstrap деякий час я повернувся до тире. Мені зараз вони виглядають набагато чистіше, ніж un_der_scores або camelCase. Моя оригінальна точка все ще стоїть: не існує стандарту.

Оновлення 2015 року

Цікавий кутовий випадок з умовами тут - Іржа . Мені дуже подобається мова, але компілятор попередить вас, якщо ви визначатимете речі, використовуючи щось інше, крім underscore_case. Можна вимкнути попередження, але цікаво, що компілятор настійно пропонує конвенцію за замовчуванням. Я думаю, що у великих проектах це призводить до більш чистого коду, що не є поганим.

Оновлення 2016 ( ви просили про це)

Я прийняв стандарт BEM для подальших моїх проектів. Назви класів в кінцевому підсумку є досить багатослівними, але я думаю, що це дає гарну структуру та повторне використання класам та CSS, що йде разом з ними. Я припускаю, що BEM насправді є стандартом (тому моє noстає, yesмабуть), але все ж залежить від того, що ви вирішите використовувати в проекті. Найголовніше: бути узгодженим з тим, що ви обираєте.

Оновлення 2019 ( ви просили про це)

Після того, як довгий час не писав CSS, я почав працювати в місці, де OOCSS використовує один із своїх продуктів. Особисто мені здається, що уроки сміття скрізь неприємні, але не потрібно весь час переходити між HTML та CSS, відчуваючи себе досить продуктивним.

Я все ще влаштувався на BEM. Це багатослівно, але простір імен робить роботу з ним у компонентах React дуже природним. Він також чудово підбирає конкретні елементи під час тестування браузера.

OOCSS та BEM - лише деякі стандарти CSS. Виберіть той, який працює для вас - вони всі сповнені компромісів, тому що CSS просто не так добре .

Оновлення 2020 року

Нудне оновлення цього року. Я все ще використовую BEM. Моя позиція насправді не змінилася з оновлення 2019 року з перелічених вище причин. Використовуйте те, що працює для вас, що масштабується з розміром вашої команди та приховує стільки ж, скільки мало поганого набору функцій CSS, скільки вам подобається.

У Google є посібник зі стилів css & html, який рекомендує завжди використовувати дефіс: https://google.github.io/styleguide/htmlcssguide.html#ID_and_Class_Name_Delimiters .

Я пропоную вам використовувати підкреслення замість дефісу (-), оскільки ...

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

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

ви можете отримати доступ до значення, легко id таким чином. Але якщо використовувати дефіс, це призведе до синтаксичної помилки.

Це старий зразок, але він може працювати без jquery - :)

завдяки @jean_ralphio, існує робота, яку можна уникати

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

Стиль Dash був би стилем коду google, але мені це не дуже подобається. Я віддаю перевагу TitleCase для id та camelCase для класу.

tl; dr;

Немає жодної правдивої відповіді. Ви можете вибрати один із безлічі там або створити свої власні стандарти на основі того, що має сенс, залежно від того, з ким ви працюєте. І це на 100% залежить від платформи.

Оригінальна публікація

Ще один альтернативний стандарт, який слід врахувати:

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

І у вашому сценарії:

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

Це просто використовує camelCase, under_score та дефіс відповідно для змінних, ідентифікаторів та класів. Я читав про цей стандарт на кількох різних веб-сайтах. Хоча дещо зайве у селекторах css / jquery, надмірність полегшує пошук помилок. наприклад: Якщо ви бачите .unknown_nameабо #unknownNameу своєму CSS-файлі, ви знаєте, що вам потрібно розібратися, на що насправді йдеться.

ОНОВЛЕННЯ 2019 року

(Дефіси називаються "шашликом", підкреслення - "snake_case", і тоді у вас є "TitleCase", "pascalCase")

Мені особисто не подобаються дефіси. Я спочатку розмістив це як одну з альтернатив (тому що правила прості). Однак дефіси роблять ярлики вибору дуже важкими (подвійне клацання, ctrl/ option+ left/ rightі ctrl/ cmd+ Dу vsCode. Також, назви класів та назви файлів - це єдине місце, де працюють дефіси, оскільки вони майже завжди в лапках чи в css тощо) . Але річ із ярликом все ще діє.

Окрім змінних, назв класів та ідентифікаторів, ви також хочете ознайомитись із умовами імен файлів. І Гіт Гілки.

Група кодування мого офісу насправді мала зустріч місяць-два тому, щоб обговорити, як ми збираємось називати речі. Для гілок git ми не могли вибрати між описом 321-the_issue_description або 321_the-issue-description. (Я хотів 321_theIssueDescription, але моїм співробітникам це не сподобалось.)

Приклад, щоб продемонструвати роботу зі стандартами інших народів ...

Vue.js має стандарт. Насправді у них є два альтернативні стандарти для декількох предметів. Мені не подобаються обидві їх версії за назви файлів. Вони рекомендують "/path/kebab-case.vue"або "/path/TitleCase.Vue". Перший важче перейменувати, якщо ви спеціально не намагаєтесь перейменувати його частину. Останнє не добре для сумісності між платформами. Я б віддав перевагу "/path/snake_case.vue". Однак, працюючи з іншими людьми або існуючими проектами, важливо дотримуватися того, що вже було викладено. Тому я їду з шашликом для назви файлів у Vue, хоча я буду повністю скаржитися на це. Тому що не дотримуватися цього означає змінити багато файлів, які встановлює vue-cli.

Про узгодження імен для HTML та CSS немає узгодженості. Але ви можете структурувати свою номенклатуру навколо дизайну об'єктів. Більш конкретно те, що я називаю власністю та відносинами.

Власність

Ключові слова, що описують об'єкт, можна розділити дефісами.

машина-нова-повернена праворуч

Ключові слова, що описують об'єкт, також можуть поділятися на чотири категорії (які слід упорядкувати зліва направо): Об'єкт, Дескриптор об'єкта, Дія та Дескриптор дій.

автомобіль - іменник, а об’єкт
новий - прикметник, а об’єкт-дескриптор, який більш детально описує об'єкт
- дієслово, а дія, що належить об'єкту
праворуч - прикметник та дескриптор дії, що описує дія більш детально

Примітка: дієслова (дії) повинні бути в минулому часі (повернув, зробив, пробіг тощо).

Відносини

Об'єкти також можуть мати стосунки, як батько та дитина. Дескриптор Action і Action належить до батьківського об'єкта, вони не належать дочірньому об'єкту. Для відносин між об'єктами ви можете використовувати підкреслення.

автомобіль-новий-повернутий право-колесо-ліворуч-повернутий ліворуч

• автомобіль-новий-повернутий праворуч (дотримується правила власності)
• колесо вліво-вліво-вліво (дотримується правила власності)
• автомобіль-новий-повернутий право-колесо-ліво-повернутий ліворуч (дотримується правила відносин)

Підсумкові зауваження:

• Оскільки CSS нечутливий до регістру, краще написати всі імена в малі регістри (або великі регістри); уникайте футляра з верблюдами чи паскальцями, оскільки вони можуть призвести до неоднозначних імен.
• Знайте, коли використовувати клас та коли використовувати ідентифікатор. Справа не лише в тому, що ідентифікатор, який використовується один раз на веб-сторінці. Більшу частину часу ви хочете використовувати клас, а не ідентифікатор. Веб-компоненти, такі як кнопки, форми, панелі, тощо, завжди повинні використовувати клас. Ідентифікатор може легко призвести до конфліктування імен, і його слід використовувати в порядок для простору імен для розмітки. Вищеописані поняття власності та відносин стосуються іменування класів, і ідентифікаторів, і допоможуть вам уникнути конфліктів імен.
• Якщо вам не подобається моя умовна умова іменування CSS, є ще декілька: Конструкція структурного іменування, Конвенція про презентаційне іменування, Конвенція про семантичне іменування, Конвенція іменування BEM, Конвенція іменування OCSS тощо.

Ще одна причина, чому багато хто вважає за краще дефіси в ідентифікаторах CSS та класах - це функціональність.

Використання комбінацій клавіш на зразок option+ left/ right(або ctrl+ left/ rightу Windows) для переходу кодового слова за словом зупиняє курсор на кожному тирі, що дозволяє точно пересувати ідентифікатор або ім'я класу за допомогою комбінацій клавіш. Підкреслення та camelCase не розпізнаються, і курсор переміститься прямо над ними, як ніби це все одне єдине слово.

Я нещодавно почав вивчати XML. Версія підкреслення допомагає мені відокремити все, що стосується XML (DOM, XSD тощо) від мов програмування, таких як Java, JavaScript (корпус верблюда). І я згоден з вами, що використання ідентифікаторів, дозволених у мовах програмування, виглядає краще.

Редагувати: Можливо, це не пов’язано між собою, але ось посилання на правила та рекомендації щодо іменування XML-елементів, яких я дотримуюся під час іменування ідентифікаторів (розділи "Правила іменування XML" та "Найкращі практики іменування").

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

Я думаю, що це залежить від платформи. При розробці в .Net MVC я використовую малі регістри стилів завантаження та дефіси для імен класів, а для ідентифікаторів використовую PascalCase.

Підставою для цього є те, що мої погляди підтримуються сильно набраними моделями перегляду. Властивості моделей C # - це регістр pascal. Задля зв’язування моделі з MVC має сенс, що назви елементів HTML, які прив'язуються до моделі, відповідають властивостям моделі перегляду, що є регістром. Для простоти мої ідентифікатори використовують ті ж умови іменування, що імена елементів, за винятком радіо кнопок і прапорців, які вимагають унікальних ідентифікаторів для кожного елемента в названій групі вводу.