Если вы тратите большую часть своего времени на программирование, работая непосредственно с браузером, вы, вероятно, уже знаете, насколько проще обслуживание, тестирование и согласованность рендеринга, когда ваша разметка хорошо структурирована и семантическая. Важность разделения контента и презентации не теряется на вас. Более того, вы знаете, как хорошо выполнить это разделение.
Если бы только вы могли написать каждую строчку кода в вашем следующем проекте, вы уверены, что это был бы самый чистый, самый поддерживаемый веб-сайт в Интернете! Но веб-сайты редко являются единственным продуктом фронт-эндовых разработчиков, и в любом проекте, который требует значительных программных усилий, может быть трудно добиться признания преимуществ качественной интерфейсной базы кода даже для самого высокого качества. -сознательные программисты на стороне сервера. Слишком часто то, что на первый взгляд кажется незначительным экземпляром семантики HTML, на самом деле включает в себя целый ряд последствий, выходящих за рамки того, что очевидно для большинства людей (включая отделы управления и эксплуатации) в большинстве проектов.
Недавно мой коллега (очень талантливый разработчик PHP) задал фантастический вопрос о такой ситуации. В нашем проекте мы хотели создать разрыв строки перед тем, как в примечаниях появится текст ссылки, который будет отображаться по-разному на сайте. Моим решением был HTML, который выглядел примерно так:
<div class="help-note"><p> <span>Can you add a picture to the page about</span> <a href="..." title="Help us improve the article about 'Altocumulus clouds'">Altocumulus clouds</a>? </p></div> и CSS, как это:
.help-note span { display: block; }
Мой коллега хотел знать, почему я решил использовать span с дополнительным правилом CSS, чтобы выполнить разрыв строки в дизайне нашего художника. Разве это не было бы более естественно, рассуждал он, если бы мы просто использовали div ? Таким образом, мы можем вообще отказаться от добавления CSS. Кроме того, не являются ли элементы div такими же, как элементы span , кроме span , когда display: block применяется по умолчанию?
Это отличный вопрос, с помощью которого можно проиллюстрировать взаимосвязь, которую разметка имеет во многих частях кодовой базы веб-сайта. Давайте посмотрим на некоторые из этих последствий.
Хотя практически говоря, элементы div и span предназначены для того, чтобы быть бессмысленными, есть небольшая разница. Это связано не только с тем, что стилизация этих элементов по умолчанию в браузере отличается, но также и, что, возможно, более важно, последствия логической группировки на контекстной основе.
Элементы
divиspanв сочетании с атрибутамиidиclassпредлагают общий механизм добавления структуры в документы. Эти элементы определяют контент как встроенный (span) или блочный (div), но не налагают на контент другие идиомы представления. Таким образом, авторы могут использовать эти элементы в сочетании с таблицами стилей, атрибутомlangи т. Д., Чтобы адаптировать HTML к своим собственным потребностям и вкусам.
На первый взгляд они могут показаться одинаковыми, но более внимательно рассмотрим формулировку: эти элементы определяют содержимое как встроенное (
. span ) или блочное ( div )
Другими словами, сам контент предлагает соответствующий элемент. Поскольку вся справочная записка логически представляет собой одно предложение и предназначена только для разделения на несколько строк при применении стиля (и, вероятно, не в, скажем, текстовом представлении содержимого, поскольку это было бы странно для структуры предложения) , тогда элемент span является единственным из этих двух, который подходит. загрузка фильмов
Использование span также имеет технические преимущества. Например, предположим, что нашим пользователям настолько нравятся HelpNotes, что мы решили использовать их в других местах. Мы создаем класс HelpNote , который имеет только один метод вывода с такой сигнатурой:
/** * Produces appropriate output of a note for help regardless of display context. */ public static function renderHelpNote( Object $title )
Эта функция — то, что HelpNote -разработчики могут использовать для вывода HelpNote независимо от того, откуда они ее вызывают. Поэтому, независимо от того, используем ли мы HelpNote в электронной почте или на веб-странице, состоящей из нескольких частей (например), в PHP мы можем просто сказать renderHelpNote( $title ) и покончить с вызовом. Это было бы полезно, скажем, в цикле или системе шаблонов.
Теперь возникает вопрос, должно ли предложение с примечанием к справке использовать span или div ? Если мы используем div , то мы знаем, что для создания версии справочной заметки в виде элемента списка, мы должны добавить логику в функцию renderHelpNote , чтобы пропустить div , или перекомпилировать div как элемент встроенного уровня. Однако если мы используем span , то мы не только придерживаемся структуры предложений, но и остаемся гибкими, придерживаясь понятия постепенного улучшения, стилизуя только самые конкретные случаи и позволяя более общим, низким -точные конструкции остаются незапятнанными.
По общему признанию, это — тип точности и навязчивой правильности, которая может быть раздражающей или даже бессмысленной человеку, не знающему тонкостей. Тем не менее, я думаю, что это еще одна причина для правильного разделения интересов.
Как разработчик внешнего вида, мне неважно, как упорядочен список заметок о помощи; Я просто верю, что будет список, и что мой коллега отсортирует его в том порядке, в котором он намеревался. Точно так же я не хочу заставлять моих коллег заботиться о том, будет ли разрыв строки выглядеть правильно; Я просто хочу, чтобы они вывели код и позволили мне управлять дисплеем. Результат с span — это больше, чем просто более чистый код переднего плана, это также более простая, более многократно используемая логика вывода на стороне сервера.
Мне часто кажется, что существует огромное культурное столкновение между back-end разработчиками и front-end разработчиками. Выбор, который делает одна группа, может показаться сумасшедшим для другой. Однако чаще всего небольшое межфункциональное обучение может иметь большое значение для написания кода, который лучше для всех нас. Так что задавайте вопросы, потому что техники, которые помогают вашим коллегам, вероятно, тоже помогут вам.
Обновление : мне нравится, как тщательно все, кто комментирует этот пост! 🙂 Было сделано несколько хороших замечаний, и потребовались некоторые разъяснения, поэтому я постарался ответить на них в комментариях. В частности, вот почему этот пример исключает использование простого стиля элемента <a> .