Размеры блоков, или Назад в будущее

Дэвид Стори 23 января 2013

Технологии разработки сайтов меняются в корне. XHTML (Strict — мы так гордились своей работой) уступил место более свободному HTML5. Нарезанные картинки и div-обёртки заменяются гораздо более разумными (и, если повезет, семантичными) средствами HTML и CSS3, такими как border-radius, box-shadow и градиенты. Резиновая раскладка превращается в отзывчивый дизайн на медиа-выражениях. JavaScript — уже не просто игрушка, и занимает положенное место в триумвирате с HTML и CSS. Может быть, мы уже близки к получению реального инструмента разметки с помощью Flexbox. Может быть, даже почтенные единицы em будут забыты, и их заменят более предсказуемые rem, а также гибкие единицы vw и vh.

Мы стоим на пороге третьей эры Открытого веба (век таблиц и однопиксельных гифов уже не более, чем история), и наши инструменты и процессы развиваются, начиная походить на инструменты обычных программистов — это скрипты сборки, препроцессоры, линтеры (при некотором приближении, напоминающие компиляторы), автоматическое тестирование и контроль версий.

Но есть кое-что гораздо менее заметное, о чём бы я хотел поговорить сегодня, тоже способное по-своему изменить разработку сайтов. Это CSS-свойство box-sizing.

Те из вас, кто помнит тяжелые старые времена, помнит и неправильную блочную модель, которую IE использовал вместо стандартной модели W3C. В этой модели рамка (border) и отступ (padding) считались частью ширины (width) и высоты (height) блока, в то время как в модели W3C отступ и рамка прибавлялись к ширине и высоте при расчёте конечных размеров блока. В модели IE свойство width отражало конечную ширину блока, в то время как в модели W3C оно отражало ширину контентной части блока (то есть части блока, в которой находится непосредственно его содержимое). Чтобы заставить IE играть по правилам, мы должны были использовать хак блочной модели Тантека Челика.

CSS-свойство box-sizing существует уже некоторое время и дает нам возможность переключаться между стандартной блочной моделью box-sizing:content-box и старой блочной моделью IE box-sizing:border-box. Недавний всплеск интереса к использованию этого забытого свойства связан с выходом статьи Пола Айриша * { box-sizing:border-box } FTW.

Пора переключиться на border-box?

Если вы хотите перейти сразу к делу, пожалуйста, поучаствуйте в опросе о box-sizing, а если нет — просто читайте дальше.

Использование border-box по умолчанию никогда не будет включено в стандарт, так как это скажется на отображении слишком большого количества сайтов, но не пришло ли время переключиться на использование его для всех элементов на всех проектах с помощью универсального селектора, как предлагает Пол? Об этом я думал в последнее время.

Если дело касается только моих собственных проектов или проектов с небольшими командами разработчиков, которых я знаю и с которыми могу общаться непосредственно, я думаю, сказал бы — да, это стоит сделать. Но когда речь идет о руководстве для многих разработчиков, проектах с открытым исходным кодом или демо-материалах, доступных для просмотра большому количеству пользователей, с которыми я никогда не общался, я всё ещё сомневаюсь.

За и против

Определенно, в лагере профессионалов есть несколько наиболее известных разработчиков. Пол Айриш, несомненно, фанат своего дела. Он подытоживает разочарование от текущей модели:

Уф. Если я говорю, что ширина блока должна быть 200 пикселей, то блок должен занимать 200 пикселей по ширине, даже если у него есть отступы по 20 пикселей.

Джоу Ламберт соглашается с Полом в комментарии:

Я большой фанат этой техники, я использовал ее в некоторых мобильных веб-приложениях и все больше использую в веб-проектах.

Джереми Кит просто называет её «очень крутой». В то же время, Стефани Рюис в удивляется в комментарии:

Мы должны лоббировать смену модели W3C. Я постоянно слышу, что разработчики разочарованы.

Терри Кобленц предупреждает:

К слову о «неправильной блочной модели», как мы привыкли её называть. Я думаю, проблема в том, что вы не можете управлять контентной областью блока, и любое изменение отступа или рамки окажет на нее влияние. Я понимаю, что людям может быть проще оформлять блоки таким способом, но это не волшебная палочка, и вам придется смириться с другими сложностями«.

Борис Збарский из Mozilla говорит:

Спецификация недостаточно подробно описывает, как это должно работать, чтобы реализовать это при помощи CSS3 Box, вот что я могу сказать.

В то время как Дэвид Барон (тоже представитель Mozilla, а также рабочей группы CSS) заявляет:

box-sizing — это слабо проработанное свойство, предназначенное только для обратной совместимости с Quirks Mode.

Насколько я вижу, «за» и «против» таковы:

За

  • Гораздо проще рассчитывать размер элемента. Это тот размер, который я задаю, вне зависимости от того, какую толщину рамки или какой отступ я указываю.
  • Мы можем указывать ширину блока в процентах для тянущихся макетов, продолжая использовать em или px для указания размеров полей. При использовании традиционной модели нам понадобится свойство calc для решения этой проблемы. Читайте отличный пост Криса Койера о box-sizing с описанием этого случая.
  • Если вы собаку съели, разрабатывая под IE, то вы уже знаете, как использовать такую модель.

Против

  • Если вам требуется поддерживать IE7 и ниже, то у вас нет другого варианта, кроме как использовать специальные библиотеки или переводить IE в Quirks Mode (не лучшая идея). Firefox потребует использования префиксов, и вам потребуется префикс -webkit, если вы заботитесь об относительно свежих версиях Webkit. Смотрите список браузеров, поддерживающих свойство box-sizing.
  • Всё ещё есть баги в поведении Firefox, особенно при работе с min- и max-width/height (к счастью, уже исправленные — прим. редактора).
  • Вы теряете контроль над размерами контентной области блока, что может привести к непредсказуемым последствиям. Например, что будет, если размер поля равен или больше ширины или высоты блока? (Самые дотошные могут открыть спецификацию и поискать правильный ответ).
  • Пожалуй, наибольшая проблема для меня — ожидания разработчиков. Если я использую * { box-sizing:border-box; } в коде, который должен использоваться и расширяться другими разработчиками, я уверен, что они с большей вероятностью будут ожидать блочной модели W3C, и их стили будут вести себя не так, как они ожидают. Более того, если речь идет о разработчиках-новичках, то они могут быть вообще незнакомы с моделью IE, что потребует от них изучения дополнительных материалов перед началом работы, даже если они поймут причину такого поведения.

Что вы думаете?

С учетом всего сказанного и других причин, которые, я уверен, найдутся, — что вы думаете по этому поводу? Если бы вы участвовали в проектах, где другие разработчики будут работать с вашим кодом, вы бы использовали box-sizing:border-box? Я создал опрос, так что вы можете дать мне об этом знать, и после получения результатов я сделаю отчет о том, что выбирают люди.

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

Результаты опроса

Прошла неделя с того дня, как я создал опрос об использовании box-sizing:border-box. За это время форму заполнили 256 человек. Результаты оказались такими:

Используете ли вы или будете использовать box-sizing:border-box? Да Нет
В текущем личном проекте 71% 29%
В будущем личном проекте 88% 12%
В будущем «командном» проекте 85% 15%
В будущем «публичном» проекте 60% 40%

В приведённой таблице под «командным проектом» понимается проект, в котором разработчики знакомы с человеком, принимающем решение об использовании модели border-box — например, группа разработчиков в одной компании или группа друзей, с которыми вы близко общаетесь в ходе работы. Под «публичным проектом» понимается проект, в котором разработчиком может быть кто угодно, с кем вы, вероятно, не можете лично согласовать выбор модели — проект с открытым исходным кодом или публичное API.

Хотя это не окончательные результаты голосования, есть признаки того, что разработчики комфортно чувствуют себя при использовании модели border-box (или планируют её использовать) и рады использовать ее в «командных проектах». Меня немного удивило количество разработчиков, уже использующих эту модель. Число разработчиков, предпочитающих применять модель border-box в «публичных проектах» ниже, но все равно на 20% выше, чем число тех, кто не планирует этого делать. Если результаты опроса что-то значат, не удивляйтесь, если встретите все больше проектов, использующих модель, формально считающуюся неправильной.

Хотя разработчики в большинстве своем предпочитают использовать box-sizing:border-box, многие заявили, что будут делать это только при необходимости, не применяя его ко всем элементам с помощью универсального селектора. Многие обратили внимание, что использование может нарушить работу некоторых jQuery-плагинов, и это способно ограничить применимость модели на сайтах, активно использующих jQuery. Другие сообщили, что применяли бы эту модель, если бы она была документирована, как это было с KSS-комментариями (это хороший подход при работе в команде или даже в личных проектах, если вам требуется затем поддерживать собственный код).

Я оставлю опрос открытым в надежде собрать больше ответов. Но поскольку соотношение результатов в box-sizing:border-box; составило 60 к 40 в течение недели, я не жду, что результат значительно изменится.

Вы все еще можете принять участие в опросе. К сожалению, результаты опроса сейчас скрыты. Но это только подогревает наше любопытство. Расскажите: а что вы думаете о возможности выбора блочной модели? Используете box-sizing:border-box; в текущих проектах? Планируете использовать?

Перевод оригинальных записей «Sizing Boxes (Back to the Future)» и «Box-sizing: border-box; the results are in» Дэвида Стори (David Storey), опубликованных на сайте Genetated Content. Переведено и опубликовано с разрешения автора.

Перевод выполнил Сергей Смольников.

Теги: , ,

Перейти к началу