Как вы знаете, значения id и class могут использоваться для обеспечения ловушек реализации эффектов представления (CSS) и поведения (JavaScript) в коде переднего плана. Конечно, они также могут влиять на семантику; Микроформаты — это шаблон проектирования, который интенсивно использует атрибут class определенным образом. Но знаете ли вы, что еще можно использовать для этих двух основных атрибутов?
Я думаю, что когда мы тщательно продуманы, атрибуты id и class также могут улучшить организацию нашего кода, удобочитаемость и напрямую улучшить многие аспекты взаимодействия между разработчиками, что может быть особенно важно для больших команд . На самом деле, часть успеха микроформатов заключалась в создании продуманных соглашений о том, какие имена class использовать, когда и почему.
Замечания по идентификатору и имени класса
При составлении значений для атрибутов id и class я задаю себе следующие вопросы, чтобы помочь мне найти хорошее (и воспроизводимое) имя:
- Какую функцию выполняет элемент? (Почему это там? Какова его цель?)
- Есть ли другие элементы, которые выполняют аналогичные функции? (Насколько похожи? Какие различия между ними?)
- Существуют ли другие сайты, которые используют элементы для тех же целей? (Как они называются?)
Ответ на первый вопрос помогает мне создать самодокументируемый код , придумав имя, соответствующее функции и назначению кода. Например, один взгляд на подобный код сразу показывает, что это навигационный список, поэтому наличие ссылки на «навигацию» в его названии имеет очевидный смысл.
<ul> <li><a href="/">Home</a></li> <li><a href="/about/">About</a></li> ... </ul>
Ответ на второй вопрос помогает осветить возможности для повторного использования. Например, если только не существует всего одного элемента навигации во всей кодовой базе, вряд ли будет достаточно различаться идентификация вышеупомянутого кода только по функции («навигация»). Поэтому он может называться «основная навигация», «навигация по сайту», «панель навигации», «глобальная навигация» или какой-либо их комбинацией, в то время как другой элемент навигации получает одно из других имен. Давайте пойдем с именем «site» ради этого примера:
<ul id="sitenavigation"> <li><a href="/">Home</a></li> <li><a href="/about/">About</a></li> ... </ul>
Ответ на третий вопрос может помочь техническому взаимодействию кода (как в случае использования микроформатов), но также может помочь сделать схемы именования понятными и простыми. «Nav» — это обычное сокращение, и он даже является самостоятельным первоклассным элементом HTML5, который вы можете использовать сегодня . Получая вдохновение от существующей работы, вы уменьшаете когнитивные усилия, необходимые для принятия и поддержания ваших собственных условностей.
<ul id="sitenav"> <li><a href="/">Home</a></li> <li><a href="/about/">About</a></li> ... </ul>
Важность соглашений об именах
Соглашение об именах — это просто соглашение между разработчиками использовать одно и то же имя для обозначения тех же или похожих вещей и другой шаблон для обозначения чего-то другого. Такие соглашения невероятно просты, но невероятно мощны. Например, могу поспорить, что вы можете прочитать следующее предложение, потому что английские буквы соответствуют широко согласованным правилам: I re_lly l_ve sem__tic __rkup!
Соглашения позволяют любому, кто знаком с их общими принципами, заполнять детали, даже если эти детали отсутствуют. Врожденная способность человека экстраполировать информацию, основанную на соглашениях и предшествующих знаниях, не только полезна, когда дело доходит до заполнения пробелов. Та же самая техника может использоваться как способ сообщить о целях и намерениях.
Для элементов, которые являются общими для большинства веб-сайтов, таких как глобальные списки навигации и поля поиска, я использую названия TitleCase . Однако для элементов, характерных для одного сайта, я использую lower-case-dashed имена. Я использую соглашение об именах как своего рода микросинтаксис, чтобы подразумевать «общий» (он же «глобальный»), а не «конкретный» (он же «локальный») вид, касающийся назначения элемента, различие, которое может помочь ориентировать других разработчиков в большое представление изображения кодовой базы.
Следуя этому соглашению, sitenav становится SiteNav :
<ul id="SiteNav"> <li><a href="/">Home</a></li> <li><a href="/about/">About</a></li> ... </ul>
Обратите внимание, что использование TitleCase сравнении с lower-case-dashed именами в lower-case-dashed не зависит от того, присутствуют они в class CSS или в значении атрибута id . Вот как я могу разметить поле ввода текста в форме поиска:
<input type="text" class="SearchField" id="widgetco-search" title="Find a Widget" value="" />
Мы знаем, что «поле поиска» является общим понятием, поэтому, согласно моим соглашениям, оно получает TitleCase d. По тому же (очевидному) признаку, специальное поле поиска Widget, Co. не существует на других веб-сайтах, поэтому оно получает имя в lower-case-dashed . Среди моих 5 главных советов для красивой разметки — постоянно использовать шаблоны разметки ; Расширение этой концепции до значений id и class является естественной эволюцией.
От конвенции к общему кодексу
В конечном счете, соглашение об именовании, которое вы выбираете, не так важно, как его соблюдение. Однако очевидные соглашения легче подобрать быстро, поэтому один из способов проверить свое имя — это попытаться произнести ваш код вслух, как если бы он был английским. Имеет ли смысл выбранная вами грамматика, когда вы ее слышите, или она звучит неловко?
Рассмотрим поле формы. На английском языке это может выглядеть следующим образом : « Ввод текста виджета-поиска — это SearchField . Это позволяет вам найти виджет » . Это имеет грамматический смысл, и оба атрибута class « есть » , а также атрибуты id « обозначение »понятны.
Более того, вы уже знаете, что элемент с class Skyscraper , вероятно, будет использовать относительно широко распространенные и стандартные представления и поведения (и действительно, Skyscraper — это стандартный формат веб-рекламы IAB ), в то время как элемент с class wonderful-sale вероятно, нет. А поскольку вы знаете это мгновенно, вы можете более уверенно отделить свой пользовательский код от повторно используемых компонентов органичным способом.