Кто определяет как называть теги?

Определение стандартов именования тегов: от W3C до сообщества

Прямой и краткий ответ: формальные правила именования HTML и XML тегов определяются организациями по стандартизации, прежде всего Консорциумом Всемирной паутины (W3C) и рабочей группой WHATWG. Однако на практике названия тегов часто становятся результатом консенсуса в developer-сообществе, исторических прецедентов и эволюции стандартов.

Давайте разберем этот процесс детально.

1. Роль W3C и WHATWG — формальные стандарты

Эти организации публикуют спецификации (HTML Living Standard, HTML5 Recommendation), которые являются первоисточником правил.

• Синтаксические правила:

    *   Имя тега должно начинаться с буквы (a-z, A-Z).
    *   Может содержать буквы, цифры, дефисы.
    *   Чувствительность к регистру: в **HTML** теги нечувствительны к регистру (`<div>`, `<DIV>`, `<Div>` — одно и то же). В **XML** и, как следствие, в **JSX** (React) и **Vue Single-File Components** — чувствительны к регистру, и по соглашению используют `camelCase` для пользовательских компонентов.

• Предопределенные теги: Спецификация определяет набор встроенных (built-in) тегов: html, div, span, section, header, main и т.д. Их имена зафиксированы. Создать собственный тег с новым именем (например, <myCard>) можно, но он будет обрабатываться браузером как инлайн-элемент (HTMLUnknownElement) без семантики и стилей по умолчанию. Для кастомных элементов теперь есть стандарт Web Components (customElements.define()).

2. Влияние сообщества и экосистемы

Формальные стандарты часто закрепляют уже устоявшиеся в сообществе практики.

• Фреймворки и библиотеки: Они создают свои "виртуальные" пространства имен для тегов-компонентов.

  // React (JSX) — здесь 'MyComponent' и 'button' (строчный тег) определяются разработчиком и React.
  function MyComponent() {
    return <button className="btn">Click</button>;
  }
  

    В этом примере `button` — это стандартный HTML-тег, обрабатываемый React, а `MyComponent` — пользовательский компонент. Правила именования таких компонентов определяются соглашениями фреймворка и стилем кода команды (обычно `PascalCase`).

• Исторический контеккт и семантика: Названия многих тегов пришли из прошлого или отражают их предназначение. Тег div — от division (раздел), span — от span of text (участок текста). С появлением HTML5 были добавлены семантические теги (article, nav, figure), чьи имена тщательно подбирались рабочей группой для максимально точного описания содержимого.

• Неофициальные, но общепринятые "стандарты": Например, префикс data- для кастомных атрибутов (data-user-id) был настолько популярен, что в итоге был стандартизирован в HTML5 (API dataset). Или соглашение об использовании is- / js- префиксов в классах для CSS и JavaScript соответственно (is-active, js-modal-trigger).

3. Практические соглашения для разработчиков

При именовании пользовательских компонентов (которые в итоге рендерятся в DOM-теги) действуют неписанные, но строгие правила:

1. Использование PascalCase (или kebab-case для Web Components):

    *   `PascalCase`: `UserProfile`, `SidebarMenu`, `DataGrid` (React, Vue 3 с `<script setup>`, Svelte).
    *   `kebab-case`: `user-profile`, `sidebar-menu` (нативные Web Components, Vue 2 без сборки).

1. Осмысленность и ясность: Имя должно сразу сообщать о назначении компонента (<ProductCard />, а не <Box3 />).

2. Префиксы для избежания конфликтов: В крупных проектах или библиотеках UI используют префиксы: BaseButton, AppHeader, ElInput (Element UI), ChakraBox (Chakra UI).

4. Соглашения об именовании для SEO и доступности (a11y)

Названия семантических тегов (main, nav, aside) были выбраны W3C не только для разработчиков, но и для парсеров поисковых систем и скринридеров. Правильное использование этих стандартных имен напрямую влияет на доступность и ранжирование сайта.

Итог

Имена стандартных HTML-тегов определяются и фиксируются W3C/WHATWG. Имена пользовательских компонентов определяются самими разработчиками, но строго в рамках соглашений, навязанных выбранным фреймворком, языком (JSX/XML) и сложившейся культурой сообщества. Процесс этот итеративный: сообщество вырабатывает удобную практику → она становится де-факто стандартом → часто формализуется в спецификациях. Поэтому современный фронтенд-разработчик должен одинаково хорошо знать как официальные стандарты браузерных тегов, так и конвенции своего стека технологий.