frontend/EmberJS developer
0,0
рейтинг
29 октября 2013 в 05:08

Разработка → Слово в защиту пиксельных значений media queries

Я покажу тебе, глубока ли кроличья нора.Читая публикации о верстке для вэба, вы не раз натыкались на рекомендацию не использовать пикселы в media queries. Например, вот цитата из совсем недавней статьи на Хабре:

Вместо использования фиксированных размеров, лучше использовать относительные единицы для определения breakpoints. На хабре уже многократно была раскрыта тема использования относительных размеров в верстке. Вот неполный список статей: здесь, здесь, здесь. Приведу лишь самый главный довод — это позволит браузерам изменять дизайн в зависимости от уровня установленного размера зума пользователем, в результате чего пользователь увидит более приятный, более доступный для просмотра сайт.

Что, если я скажу вам, что использование пикселов в media queries не только не причиняет никакого вреда верстке, но и имеет преимущества над использованием em'ов?



В статье используется термин «breakpoint». Программистам он режет слух, так как в мире программирования означает совсем другое. Уверяю вас, что в англоязычном мире фронтенд-разработки это устоявшийся и однозначный термин. Он означает ширину окна браузера, при превышении которой компоновка страницы меняется. Коверкать его на русский язык я не стал, как и термин «media query».

 

Media queries с пиксельными значениями не мешают зуму


Начнем с «самого главного довода» против пикселов: якобы, при увеличении страницы в старом браузере пиксельные значения media queries не срабатывают. Это просто-напросто ложь. Пиксельные media queries нормально срабатывают при зуме во всех сколько-нибудь популярных браузерах. Даже в Internet Explorer 8!

Да, IE 8 не поддерживает media queries. Но если вы воспользуетесь в вашем проекте замечательным полифиллом Respond.js, то IE 8 будет отображать его с полной поддержкой media queries. И знаете, что? Они корректно срабатывают при зуме даже в нем. Крутите колесико мыши с зажатым Ctrl — компоновка страницы перстраивается. К примеру, на сайте, анимация зума которого в IE показана справа, я использовал media queries следующего вида:

@media (min-width: 401px) {
  #header-first {
    float: left;
    width: 47.82609%;
    margin-right: 4.34783%; }}

Более древнего IE под рукой не оказалось, но это и не важно — доля IE7 составляет в России всего 0.7%, IE6 — 0.1%, и то, по большей части, за счет госучреждений.

Итак, проблема, называемая в качестве главной причины отказа от пикселов в media queries, просто не существует. По всей видимости, это просто легенда, которая слепо передается из уст в уста, регулярно попадает даже в публикации влиятельных изданий и блоги гуру фронтенда, и никто не удосуживается просто взять и проверить, а так ли это.

UPD 2013-10-31: я обнаружил, что в Safari media queries при зуме не срабатыват. Но они не срабатывают независимо от того, какая единица измерения в них используется. KrylCW помог подтвердить, что это справедливо и для Safari 7. Кроме того, по его данным, media queries не срабатывают при зуме в Яндекс.Браузрере под MacOS (актуальная версия 1.7.1364.22074 (0b6c012)), но срабатывают, если после зума сделать обновление страницы.

Я попробовал Яндекс.Браузер под виндой (актуальная версия 13.10.1500.8765 (e504cce)). Там всё наоборот: пиксельные media queries зумятся корректно, а относительные — нет! Вы зумите страницу, media query срабатывает правильно. Скажем, это происходит на шаге 175%→200%. Потом вы зумите в обратную сторону, и media query на шаге 200%→175% не срабатывает, но срабатывает на шаге 100%→90%. Причем если зумить туда-сюда, то разрыв с каждым циклом увеличивается!

Для желающих попробовать самим наклепал тест: пикселы, em'ы.
 

Изменение базового размера шрифта приводит к «съезжанию» всех breakpiont'ов, если они заданы в em'ах


Представьте такую ситуацию. Звонит вам шеф или клиент и говорит: «А чего у нас на сайте шрифт такой мелкий? Моя жена ничего не может прочитать, сделайте покрупнее». Спорить бесполезно. Вы грустно вдыхаете, бросаете виноватый взгляд на дверь отдела дизайна, открываете CSS-код и увеличиваете базовый размер шрифта с 13px до 16px (да, базовый размер шрифта все равно задается в пикселах, как ни крути).

Что при этом происходит? Все breakpoint'ы, заданные в em'ах, смещаются. Теперь на планшетах сайт отображается в одну колонку: так, как раньше выглядел только на телефоне. Выглядит это примерно так (сделайте ширину окна менее 900px и ужаснитесь). Вы этому рады? Готов спорить, что окажись вы в такой ситуации, вы будете, матерясь вполголоса, спешно переписывать все media queries… или в полный голос, если в проекте не используется препроцессор.

Да, я в курсе про идеологию Content First, в соответствии с которой breakpoint'ы и должны смещаться, подчиняясь комфортному для потребления масштабу контента. Это позволяет уйти от необходимости учитывать в CSS-коде дуриллион разнокалиберных устройств, имеющих браузер. Вместо этого вы ставите breakpoint'ы в единицах, относительных размеру шрифта, и заставляете сайт перестраиваться тогда, когда контенту становится слишком тесно или слишком просторно.

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

Да, для контент-ориентированных сайтов ширина колонки текста не должна выходить за комфортные пределы. Но, во-первых, эта ширина имеет достаточно широкий диапазон. Мне известна рекомендация в 45—75 знаков, то есть ширина колонки может безболезненно меняться на величину вплоть до 66 процентных пунктов. Во-вторых, почему именно такая ширина считается стандартом? Откройте любой глянцевый журнал, там сплошь и рядом попадаются колонки текста шириной по 15 знаков, и никому не приходит в голову, что это плохо. Мне, например, очень удобно свернуть журнал трубочкой, когда я пытаюсь читать его в битком набитом вагоне метро. А на Хабре ширина колонки текста — от 75 до примерно 115 знаков, причем подавляющее большинство посетителей Хабра видят текст шириной именно 115 знаков.

Кстати, вы не заметили тут подмену понятий? Сделать оптимальную ширину текста можно и с использованием пиксельных media queries.

И наконец, часто ли вам приходится менять размер всех шрифтов на уже выполненном проекте, причем без переоформления всего остального? А если у вас все шрифты в em'ах, а клиент потребовал увеличить шрифт только основного текста? Простите, последний вопрос к теме статьи не относится.

 

Смежные media queries, заданные в em'ах, отображаются внахлест


Я называю пару media queries «смежными», когда максимальная ширина одного совпадает с минимальной шириной другого. Приведу взятый с потолка пример:

.container {
  color: black;
  background-color: white; }}

@media (max-width: 40em) {
  .container { color: red; }}

@media (min-width: 40em) {
  .container { background-color: red; }}

Отгадаете, что увидит посетитель, которому «повезет» открыть этот сайт в браузере шириной точно 40em?

Величина перекрытия составляет всего один пиксел, но она есть. Если у посетителя сайта вдруг окажется именно такая ширина экрана, то и компоновка страницы, и оформление могут оказаться покорежены, вплоть до полной нечитаемости.

При использовании пикселов проблема решается элементарным и совершенно надежным способом:

@media (max-width: 600px) { /* ... */ }
@media (min-width: 601px) { /* ... */ }

Когда я, слепо подчиняясь мнению большинства, писал media queries на em'ах и обнаружил перекрытие, я попробвал решить проблему аналогичным способом: (min-width: 20,1em). Нахлест сменился зазором: на определенной ширине окна не применяется ни тот, ни другой media query. Я попробовал 20,01, потом 20,001… Методом артиллерийской вилки мне удалось найти нужное значение остатка после запятой.

Я быстро понял, что один раз подобрать этот остаток недостаточно. Для каждого базового размера шрифта остаток будет другим, иначе обязательно будет иметь место либо зазор, либо нахлест. Но я не растерялся, ведь я хорошо владею SASS и могу написать mixin, побирающий правильный остаток для любого значения в em'ах. Берем на входе сколько-то em'ов, умножаем на базовый размер шрифта, прибавляем единичку, делим обратно на базовый размер шрифта — и вуаля, получаем на выходе безопасное значение.

У вас на этом месте должно возникнуть смутное ощущение, что этот путь какой-то… неправильный. По крайней мере, у меня оно возникло. Я попытался посмотреть на ситуацию со стороны и задался вопросом: чем я, собственно, занимаюсь?

И это подводит нас к следующему аргументу:

 

Em'ы в media queries — это посредник между двумя пиксельными величинами: базовым размером шрифта и шириной окна браузера


Как уже упоминалось выше, базовый размер шрифта всегда задается в пикселах. В противном случае браузер просто не знает, какой размер шрифта считать равным одному em'у. Если базовый размер шрифта не указан, любой нормальный браузер примет его за 16 пикселов. Если он указан в em'ах, то браузер помножит его на те же 16 пикселов. То же касается и других относительных единиц: 1 pt принимается 4/3 px, а количество пикселов в сантиметре прописано в ОС.

Min-width и max-width в media queries сопоставляются с шириной окна, которая у любого браузера задана целым числом виртуальных пикселов. К примеру, для iPhone по четвертый включительно, она составляет 320×480, а для iPhone 5 — 320x568.

Задавая media queries в em'ах, вы сначала производите в уме преобразование из пикселов в em, а потом из em обратно в пикселы, чтобы понять, а в какую ширину экрана вы этим breakpoint'ом, собственно, попадаете.

Незачем так себя мучить. Просто используйте пикселы.

 

Использование пиксельных media queries не означает отказ от подхода «content first»


То, что вы используете пикселы в media queries, не лишает вас возможности исходить из контента при проектирвоании media queries.

Статей о том, как грамотно делать media queries, в интернетах великое множество, и эта тема выходит за рамки данной статьи. Поэтому я ограничусь несколькими рекомендациями, которыми постараюсь подкрепить тезис в подзаголовке.

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

Во-первых, не используйте по отдельному CSS-файлу для каждой ширины экрана (поддержку IE можно обеспечить полифиллом). Структурируйте код по используемым на страницах сайта модулям и расставляйте media queries индивидуально для каждого модуля. Это облегчит контроль над каждым модулем и упростит поддержку кода.

Во-вторых, при проектировании responsive layout отталкивайтесь от контента. Способ очень простой (и придуман не мной). Сначала сверстайте модуль, ориентируясь на минимальную ширину экрана. Разумеется, модуль должен быть «резиновым». Затем растягивайте окно браузера до тех пор, пока модуль не станет выглядеть паршиво. В этом месте ставьте breakpoint и переверстывайте под эту ширину. Повторяйте до тех пор, пока не упретесь max-width вашего сайта.

Кстати, не ограничивайте максимальную ширину сайта узкой колонкой в 980 пикселов. Если у вас большой монитор, посмотрите, как роскошно может выглядеть сайт на ширине 1920 пикселов. Если у вас монитор меньше, то, ради бога, наскребите пять тысяч рублей и купите себе большой. Это же ваш профессиональный инструмент!

В-третьих, используйте препроцессор. Внедрить препроцессор в проект — непросто, особенно для новичка, но он сэкономит вам колоссальное количество возни.

Подойдет любой препроцессор, но я горячо рекомендую Sass. Не потому, что сам язык Sass чем-то лучше — они все более или менее равны по возможностям, а потому, что он имеет цельную экосистему библиотек. Библиотеки, которые принято называть «расширениями Compass», очень богаты функционально и эффективно взаимодействуют друг с другом.

В четвертых, чтобы не оказаться погребенным под кучей разнокалиберных media queries…

 

Нарезайте шкалу размеров экрана на дольки


Для того, чтобы облегчить задачу работы с media queries, я смастерил расширение Breakpoint Slicer (которое, в свою очередь, использует Breakpoint — очень мощное и универсальное расширение для работы с media queries).

Идея Breakpoint Slicer очень проста. Вы расставляете breakpoint'ы через небольшие промежутки, например: 400px, 600px, 800px, 1050px. Модуль пронумеровывает эти промежутки по порядку:

  1. 0—400
  2. 401—600
  3. 601—800
  4. 801—1050
  5. 1051—∞

А затем в Sass-коде вы просто говорите, с какого по какой промежуток надо поставить media query:

  • at(2) — эквиваленто (min-width: 401px) and (max-width: 600px)
  • from(2) — эквиваленто (min-width: 401px)
  • to(2) — эквиваленто (max-width: 600px)
  • between(2, 4) — эквиваленто (min-width: 401px) and (max-width: 1050px)

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

Если у вас появится вопрос по использованию Breakpoint Slicer, не стесняйтесь задать его в багтрекере (если знаете английский, то лучше на английском).
Андрей Михайлов @lolmaus
карма
29,7
рейтинг 0,0
frontend/EmberJS developer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (64)

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Капелька сарказма с утра:)
    • +2
      Вы можете задать размер шрифта в пунктах и сантиметрах, но как тогда браузер поймет, какой высоты делать базовый шрифт? Он тупо умножает ваши пункты и em'ы на дефолтное значение. Для em'а это 16, для pt — 4/3, а коэффициент для сантиметра и дюйма берется из настроек ОС. В результате всегда получаются пикселы.

      В статье это сказано в параграфе «Em'ы в media queries — это посредник между двумя пиксельными величинами: базовым размером шрифта и шириной окна браузера».
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Именно это я и хотел сказать. :)
        • 0
          Браузер же может узнать плотность пикселей от операционной системы.

          Может, но не всегда это делает, считая дефолтные 96. Или ОС может сообщить дефолтные 96, не смотря на то, что знает точные. В Ubunte как минимум (а то и во всех иксах по умолчанию) есть два разных наборов параметров, которые по идее должны быть одинаковые, но на деле из одного всегда вытекает dpi 96, а из другого на основе EDID дисплея.
          • +2
            Не может, так как должен считать, что 1 дюйм равен 96 css-пикселям. 1 пункт соответственно равен 1/72 дюйма, или другими словами 12 пунктов = 16 css-пикселям.
            www.w3.org/TR/css3-values/#absolute-lengths

            CSS-пиксель — основная единица, с которой оперирует браузер. Он не обязан быть равен физическому размеру точки. Так, на ретине один css-пиксель по длине равен двум физическим при нормальном масштабе.
  • +37
    Все вышеизложенные аргументы в пользу употребления пиксельных значений в адаптивной вёрстке признаю справедливыми.
    • +42
      … всё, расходимся.
    • +8
      Та да, даже нечего добавить :)
  • +2
    Прямо толковая статья! Пока читал и скроллил вниз, все боялся увидеть, что это перевод, но нет! Спасибо!
  • +2
    Все толково. Единственная просьба, тем кто делает сайты. Если используете картинки для оформления (не как контент) проверяйте как выглядит сайт с этим плагином https://addons.mozilla.org/en-US/firefox/addon/nosquint/. Выставьте увеличение текста 120%, а картинки 100%.
    • 0
      «Menu / View / Zoom / Zoom text only» — и не нужно никаких расширений. Вот только это нестандартное по сути масштабирование и имеет ли смысл так проверять — большой вопрос.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Спасибо. Как-то привык уже пользоваться плагином, надо будет отучиться.
        нестандартное по сути масштабирование и имеет ли смысл так проверять — большой вопрос.

        Для меня и моих знакомых, определенно в этом есть смысл. Имея монитор 23 дюйма и «фулХД» разрешение, так же имею рабочий стол шириной 110см. и двигать по столу монитор нет совсем никакого желания. Так-что без такого нестандартного разрешения не обойтись.
  • +6
    Из всего этого можно сделать лишь один простой, но неутешительный вывод: люди, проектировавшие media queries, забыли о том, что числа с плавающей точкой нельзя сравнивать с помощью знака равенства.

    Сначала приведу гипотетический формат, в котором описываемая в статье проблема была бы решена:
    @media (max-width: 20em) { /* ... */ }
    @media (min-width: ">20em") { /* ... */ }
    


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

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

    Обращу ваше внимание на то, что есть другая — более фундаментальная область вёрстки — вёрстка классическая, книжная, к которой сейчас всё сильнее и сильнее приближается по качеству web-дизайн и которая никогда не знала слова «пиксель».

    Но это всё — лирика. А конкретно, пока у вас плотность точек порядка сотни, вы можете мерять хоть в пикселях, хоть в экранах. Но когда она — 300, вы уже обязаны вспомнить, что человеческий глаз воспринимает информацию не в пикселях, а в сантиметрах. И именно страница «меньше пяти сантиметров» должна быть перевёрстана, чтобы не мельчить и легко читаться. Так рассуждал бы верстальщик газетной колонки. Как вы, уперевшись в пиксель, добьетесь одинаково хорошего вида страницы на старом мониторе 72dpi и одновременно на экране новомодного iPad?

    Общая мысль такова: если в результате анализа какой-то возможности выясняется, что она завязана на пиксели (как в данном случае), значит эта возможность спроектирована плохо. Потому что «плохость» пикселя — фундаментальный факт. А «хорошесть» существующей media queries — под вопросом.

    Истинное проклятие, стоящее на пути современной вёрстки интерфейсов — растровые изображения. К счастью, мы уже научились их эффективно векторизовать и тянуть, хотя процессоры должны подрости, чтобы это стало мейнстримом. Но это — совсем другая история…
    • +6
      Согласен с вашим предложением @media (min-width: ">20em"). Если бы такой подход существовал, эта статья не появилась бы, а я бы верил, что пикселы ломают зум.

      Но вот с остальным поспорю.

      Во-первых, я бы предпочел взять на войну надежный топор, нежели бракованное ружье.

      Во-вторых, хоть пиксел и является для описания размеров «неестественной» сущностью, он не так плох, как вы его подаете.

      Дело в том, что в верстке используются не реальные, а «виртуальные» пикселы. Вы почему-то проигнорировали соответствующий параграф статьи (не поняли, о чем идет речь?). В англоязычных публикациях можно встретить наименование «CSS pixels», противопоставляемое «DPI pixels». Виртуальные пикселы совпадают с реальными на экранах с малым разрешением. На «ретине» же плотность экрана может быть сколько угодно высокой, но виртуальное разрешение привязано не к разрешению, а к размеру экрана.

      Как я сказал в статье, на первых четырех поклениях iPhone размер экрана с точки зрения CSS составляет 320×480 пикселов, несмотря на то, что количество реальных пикселов у разных поколений устройства отличается в четыре раза.

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

      Следует понимать, что использование крупных виртуальных пикселов в CSS не мешает использовать изображения в высоком разрешении. То есть вы можете сделать <img src='hd_img_1280x720px.jpg' style='width:200px' alt='Retina image'>, и на iPhone 4/5 оно отобразится в высоком разрешении, несмотря на то, что в CSS задан размер 200px. То же самое касается и шрифтов. Шрифт, размер которого задан равным 16 пикселам, будет отображаться в высоком разрешении и иметь сколько угодно реальных пикселов.

      Таким образом, ваше утверждение «Как вы, уперевшись в пиксель, добьетесь одинаково хорошего вида страницы на старом мониторе 72dpi и одновременно на экране новомодного iPad?» говорит о том, что вы ни разу не пробовали этого делать, потому что такой проблемы даже не стоит.

      И наконец, использование виртуальных пикселов вместо единиц измерения реального мира решает еще одну проблему.

      Например, если сайт на «умных часах» будет отображаться в том же масштабе, что и на традиционном экране настольного ПК, то масштаб будет настолько крупным для мелкого экранчика, что пользоваться сайтом будет невозможно. Ширина колонки текста составит 10 знаков. Я предпочту, чтобы масштаб на часах был меньше, чем на ПК, ведь я могу поднести их близко к глазам. И наоборот: текст, отображающийся на настенном табло в том же масштабе, что и на ПК, окажется слишком мелким для чтения, даже несмотря на гигантские размеры и высокое разрешение табло.

      Поэтому размер виртуального пиксела на каждом устройстве индивидуален и определяется значением DPI, прописанным в ОС. На мобильных устройствах это значение зашито жестко, а на десктопных его можно регулировать по желанию пользователя, причем эта настройка одинаково распространяется на все приложения, а не только на браузер. И если владелец retina-дисплея выставил мелкий масштаб (да еще вывалил за это миллион денег), то значит, ему так удобно. Значит, у него хорошее зрение и ему хочется, чтобы на экране помещалось побольше материала. Пытаться вклиниться в это собственными настройками масштаба вашего сайта — значит идти поперек потребностей пользователя.
      • +1
        Вы меня подловили, каюсь. Версткой интерфейсов занимаюсь больше на Android, чем в web (CSS знаю очень поверхностно). Тут я, действительно, полез немного не в свою степь. Однако же, именно из-за того, что я чуть-чуть в стороне от CSS, имею наглость критиковать из-за угла, видя всю картину целиком. Позвольте мне высказать теоретическую точку зрения (ни в коем случае не призываю отказываться от топора, если ружья не стреляют).

        Продолжу высказанную мысль: не стоит мерить реальность в мерах, предлагаемых технологией. Технология несовершенна и содержит кучу несуразностей и противоречий.

        Давайте просто вспомним, что такое описанный вами «виртуальный пиксель», откуда он возник и зачем нужен. Десять лет назад вольшая часть экранов имела разрешение 90-120dpi и разработка страниц в пикселях настоящих была обычным делом. Очень многие сайты были гвоздями прибиты к пикселям.

        А потом внезапно появилась ретина. Сколько там? 250dpi? Нормальный человек, просто открыв любой сайт на таком экране, читал бы текст только под лупой. И поэтому умные люди (Apple?) решили притвориться, что четыре пикселя их устройства — это на самом деле один. Экран вернулся к привычным ~90 «виртуальным» dpi, а имеющиеся сайты не потребовалось срочно переделывать.

        С инженерной точки зрения решение было верное. Нельзя же заставить целую индустрию разом взять и забыть про основоположную меру длины!

        Но с точки зрения стратегической именно тогда надо было понять, что от px пора отказываться. Все ваши аргументы справедливы, просто вы смотрите на проблему с точки зрения сложившейся (нехорошей) ситуации. Вот, например, вы пишете:

        Например, если сайт на «умных часах» будет отображаться в том же масштабе, что и на традиционном экране настольного ПК, то масштаб будет настолько крупным для мелкого экранчика, что пользоваться сайтом будет невозможно. Ширина колонки текста составит 10 знаков. Я предпочту, чтобы масштаб на часах был меньше, чем на ПК, ведь я могу поднести их близко к глазам.


        Проблема сформулирована замечательно. Позвольте я предложу решение?

        Есть две шкалы расстояния в типографике — шкала, основанная на реальных размерах (сантиметры, дюймы) и шкала, основанная на размере шрифта (пресловутые em). Такая двойственность неслучайна. Человеческий глаз (с точки зрения чтения) имеет два параметра — угол обзора и разрешающую способность. Возможно, вы слышали о типографском правиле не размещать на строке больше определенного (кажется, 66) количества знаков? Вот это — из угла обзора. И отсюда же, кстати, задание максимального размера страницы в 30em. А правило «не печатать кеглем меньше 8» — это про разрешающую способность.

        В браузере помимо кнопок Zoom In / Zoom Out должны быть кнопки увеличения/уменьшения шрифта. И если все размеры задаются именно в тех единицах, которые для этих размеров предназначены, то сайт будет прекрасно выглядеть и на часах. Просто на часах стандартный кегль браузера должен быть указан не 12, а 9. Или 8 (если разработчику часов не страшно, что пользователь будет зрение ломать).

        Я укажу размер так: текстовая страница шириной не больше экрана и одновременно не больше 35em. Размер шрифта определяется конкретным устройством и может быть подкорректирован пользователем с помощью кнопок «A+», «A-». Вот, собственно, и всё. Никаких пикселей. Поправьте меня, если я ошибаюсь.

        А вот это:
        размер виртуального пиксела на каждом устройстве индивидуален и определяется значением DPI, прописанным в ОС.
        есть костыль, право на жизнь которого диктуется только насущной проблемой поддержки старых сайтов. Но лучше ведь не добавлять проблему в новые, разве не так?

        PS. Вдогонку: вот это
        Шрифт, размер которого задан равным 16 пикселам

        противоестественно вообще. Для шрифтов существует понятие кегль, привязанное к реальным размерам и метрикам шрифта. Так что шрифты — только в pt
        • +1
          Шило на мыло.

          Как есть: в ОС записан DPI устройства, а также некий коэффициент А, индивидуальный для каждого устройства. Умножение DPI на А дает размер универсальной единицы «виртуальный пиксел», которую можно непосредственно использовать для задания размеров блочной модели. Размеры шрифтов должны быть пропорциональны А. Увеличение А в настройках браузера должно приводить к перерасчету всех размеров на странице.

          Как предлагаете вы: в ОС записан DPI устройства, а также некий коэффициент Б, индивидуальный для каждого устройства. Умножение DPI на Б дает размер универсальной единицы «стандартный кегль», которую можно непосредственно использовать для задания размеров шрифтов. Размеры блочной модели должны быть пропорциональны Б. Увеличение Б в настройках браузера должно приводить к перерасчету всех размеров на странице.

          Очевидно, что два подхода не имеют преимуществ друг перед другом. Просто первый подход привычнее вэб-дизайнерам, второй — полиграфистам.

          Разница только одна: первый подход работает уже сейчас, и работает хорошо. Второй подход — гипотетический и вряд ли будет реализован.

          Но прикол в том, что два подхода — практически одно и то же. Просто смиритесь с тем, что font-size для <html> вам придется задать через А, и используйте Б для всего остального.

          … кроме media queries. :)
          • +1
            Технически разницы нет. Но
            Умножение DPI на Б дает размер универсальной единицы «стандартный кегль»

            Я предлагаю не получать давно известные величины (пункт) методом перемножения попугаев на (пункты * попугаев^(-1) ). Я лишь хочу, чтобы люди понимали, что попугаи — технический костыль.

            И еще я хочу, чтобы они (вы, в частности) поняли, что пункт нельзя прибивать к сантиметру. Он должен быть настраиваемым и любая вёрстка должна при его изменении подстраивать размеры текста и подгонять текстовые блоки, не затрагивая остальные элементы дизайна. И именно в этом разница между нашими подходами. Вы считаете, что мера одна — и поэтому упираетесь в «проблему часов». А я утверждаю, что меры две.
            • 0
              Я не понимаю. Я правильно описал ваш подход или неправильно?

              Если неправильно, то в чем разница? Чтобы стандартный кегль не был жестко связан с сантиметром, его и нужно умножать на коэффициент, задаваемый в ОС и регулируемый в настройках браузера. Назовете ли вы его «Б», «попугай-1» или стыдливо умолчите о его существовании, сути это не поменяет. И «проблему часов» переименование коэффициента не решит.

              К слову, что за «проблема часов»? Сейчас никакой проблемы как раз таки нет, потому что у каждого устройства свой коэффициент А, который, кстати говоря, называется «device pixel ratio».
        • +1
          Кстати говоря размеры «идеальных» CSS пикселей были выбраны анологично приведенным вами типографским правилам, про угол обзора и разрешающуюся способность глаза, только не для книги, как в случае с книжной версткой, а именно для мобильных устройств, которые держат на вытянутой руки. А вопрос, почему CSS пиксели плывут на разных устройствах — это вопрос не к самим пикселям, а к производителям дисплеев и разработчикам ОС/браузеров.
        • 0
          Не понятно, зачем переходить с px на em, если решение со стороны вендоров, производящих устройства с высоким dpi уже принято? Ну давайте, как уже было лет 10, снова метаться — одни будут продолжать использовать пиксели, другие (ну не живется спокойно людям), будут снова пропагандировать em. Что получим? Еще 10 лет метаний между выбором?
      • 0
        То есть вы можете сделать <img src='hd_img_1280x720px.jpg' style='width:200px' alt='Retina image'>, и на iPhone 4/5 оно отобразится в высоком разрешении, несмотря на то, что в CSS задан размер 200px.

        выходит, если сделать картинку физически 200px то на экране получится «мыло». как в таком случае рассчитать оптимальный размер картинки? %)
        • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Хотели же ввести image-set, или как их там, суть в том, что бы дать несколько разных картинок с разными размерами, а обозреватель сам выбрал, что ему использовать. Что бы не грузить лишнее.
    • –1
      Забудьте про классическую книжную вёрстку, она устарела как какашки мамонта и к вебу неприменима.
      Вы готовы верстать вручную все страницы сайта, вместе со всем контентом и каждым новым комментарием? Что, прям под весь зоопарк экранов, принтеров и скрин-ридеров? Нет? Ну так о чём вообще разговор?

      Что значит «плохость пикселя — фундаментальный факт»? Реальность такова, что сам пискель — это фундаментальный факт, потому что всё, на чём выводятся сегодня страницы, состоит из этих самых пикселей. Ваше же к этому отношение вообще никого не интересует.

      Вообще, заявления в духе «плохость фундаментального факта» — явный признак гуманитария. У гуманитариев да, у них закидоны типа «я против E=mc2!» проходят на ура. Вот только в инженерном деле, коим является вёрстка, с гуманитарным подходом делать нечего. Потому что тут результат вашей работы оценивается элементарно — оно или работает, или не работает, независимо от вашего отношения к плохости или хорошести фундаментальных фактов.
      • +3
        Давайте я просто приведу вам в пример работающую систему вёрстки, не основанную на пикселях.
        en.wikipedia.org/wiki/TeX
        Небезызвестный автор этой системы (надеюсь, его вы не будете презрительно называть «гуманитарием») потратил больше года на изучение типографского дела. Прочтите The TeXbook
        Если бы ни высокий порог вхождения, требуемый, чтобы как следует научиться ей пользоваться (знаю не понаслышке, многое умею сам), она бы прекрасно подошла в качестве альтарнативы связке HTML + CSS, которая в силу стечения обстоятельств оказалась победителем.

        Что значит фраза «плохость пикселя — фундаментальный факт» я развёрнуто объяснил. И еще добавил вот здесь. И вы, наверное, просто не прочли внимательно всё целиком — вам просто смелая фраза не понравилась. Потому что дальше вы пишете:
        сам пискель — это фундаментальный факт, потому что всё, на чём выводятся сегодня страницы, состоит из этих самых пикселей

        а я всё своё доказательство того, что пикселю в верстке не место построил, по сути, именно на этом вашем утверждении.

        Еще раз, кратко: человек смотрит на экран одними и теми же глазами, независимо от dpi экрана. Он может поднести его поближе (что нежелательно) или отойти подальше. Но вёрстка содержимого на экране должна определяться свойствами зрения, а не свойствами экрана.

        Вы готовы верстать вручную все страницы сайта, вместе со всем контентом и каждым новым комментарием?

        А вот это вообще не понял, к чему. Я же не предлагаю отказываться от автоматической вёрстки — напротив, предлагаю нормальную систему, при которой она станет действительно адаптивной. Это вы предлагаете подгонять под сто устройств с разным размером пикселя.

        А словосочетания типа «какашки мамонта» приберегите для дебатов в детском саду.
        • 0
          Извините, но TeX не годится для веба вообще. Он до поздних нулевых годов на практике ничерта не умел юникод, не говоря уже о нормальной многоязычности (которую он не умеет и сейчас, кстати: чтобы сверстать книгу с японским и русским одновременно в LaTeX, нужно немало воевать с его костылями времён 80х годов), одного этого уже достаточно, чтобы не рассматривать его всерьёз. Таблицы в нём реализованы хуже: не надо забывать, что скорость соединения с интернетом ещё не так давно была ограниченной. С картинками отдельная головная боль. Про DOM вообще можно не вспоминать. И напомните мне, в каком году компьютеры научились рендерить TeX с приемлемой скоростью и в каком появился html.

          LaTeX — неплохая система для вёрстки бумажных технических вещей. Под них она и заточена. HTML может быть неидеален, но даже он лучше, чем TeX в вебе. Дело не в высоком пороге вхождения, а в принципиально разных областях применения.
          • 0
            Во-первых, вы ошибаетесь насчет мультиязычности — используйте XeTeX (и XeLaTeX, соответственно) — там исходные файлы кодируются в UTF-8, как и выходной PDF. Кроме того, в итоговом файле есть гиперссылки, а если вы очень захотите, то встроите туда даже Flash Video (если PDF позволит). Для локализации используйте polyglossia

            А во-вторых, если бы то количество денег, которое было вложено в развитие HTML+CSS было вложено в TeX, он бы сейчас только что кофе не варил. Сопоставьте сообщества и вы поймете, что тот факт, что вёрстка в TeX-е до сих пор не превзойдена никем означает, что это — очень хорошая система.

            Приведу лишь один живой пример недоделанности большинства HTML-верстальных программ: они не умеют расставлять переносы. Текст с выключкой влево и без переносов смотрится отвратительно для человека, который видел текст с хорошо расставленными переносами (а TeX умеет делать это так, что Word и InDesign рядом не валялись). И, несмотря на то, что расстановка переносов в реальном времени — не задача для современных машин, ее по-прежнему нет.

            Причина, на мой взгляд, проста. К сожалению, никто не пытается сделать web красивее. Большинство людей просто устраивает сложившееся положение вещей. А некоторые, вероятно, так давно держали в руках хорошо свёрстанную книгу, что забыли, как она выглядит.
            • 0
              «Кодируются в UTF-8» — это ещё далеко не мультиязычность. Он даже RTL без дополнительных движений (костыли, меняющие направление текста по коду символа; ломаются в некоторых случаях) не умеет. О лигатурах, вертикальном письме (которое нужно в японском) и комбинирующих символах можно даже не говорить, а ведь это — только базовый уровень поддержки юникода. В этом и проблема опенсорса: UTF-8, как и юникод вообще — не тривиальная задача. Большинство софта не ломается, если им скармливать латинницу или кириллицу в utf-8, но сломаются даже на нескольких европейских языках, не говоря уже об азиатских. Такое умение utf-8 — не многоязычность.

              polyglossia до сих пор очень сырая.

              >если PDF позволит

              Попробуйте чуть уменьшить размер окна браузера. Представьте, что в это время браузер рендерит PDF заново. Какое железо нужно для такого веба? Сейчас планшетники/телефоны спокойно относятся к повороту экрана именно потому, что им не надо рендерить этот PDF на каждый чих. Адаптивный веб в PDF невозможен.

              Вёрстка в TeX, как я и говорил, хороша для технической одноязычной БУМАЖНОЙ литературы. Для остального есть лучшие системы вёрстки. Да, в том числе и для бумаги.

              >Приведу лишь один живой пример недоделанности большинства HTML-верстальных программ: они не умеют расставлять переносы

              Переносы в HTML? Серьёзно? Когда HTML создавался для того, чтобы его можно было прочитать на последнем тостере? В том числе и без физического экрана (сейчас в нём немало поддержки screen reader'ов)? Извините, Вы не в теме. HTML — не для бумажных документов с фиксированной шириной колонки текста. И да, на word (который не программа для вёрстки вообще) и indesign софт не заканчивается.
          • 0
            в LaTeX есть несколько замечательных штук — «блочная» модель для всего, «резиновые» распорки, вертикальное выравнивание и стили на языке программирования. это позволяет делать практически любые трюки с отображением для высокоуровневой разметки, в то время как в CSS приходится ждать очередного стандарта или расширения.
      • +2
        Охотно разделяю ваши выпады в адрес гуманитариев, но с мнением bigfatbrowncat о плохости пиксела я согласен.

        Мое рабочее место включает четыре разнокалиберных монитороа. Все четыре — низкой плотности пикселов, то есть имеют привязку реальных пикселов к виртуальным как один к одному. Но размер реальных пикселов у них отличается! Хуже того, самая популярная в мире ОС не позволяет задать DPI индивидуально для каждого монитора. Да и даже глобальная настройка DPI работает через одно место, как верно подметил achekalin.

        Но через несколько лет у всех профессионалов на рабочих местах будут «ретины». И тогда понятие «пиксела» перестанет для пользователя иметь всякий смысл, потому что пикселы больше не видны невооруженным глазом, а физическое разрешение изображений, отобразаемых на экране, никогда не будет совпадать с фактическим размером изображения в файле: старые изображения будут для этого слишком малы, а HD-изображения — слишком велики.

        Далее. Ваша нападка про книжную верстку несправедлива. bigfatbrowncat вовсе не предлагал верстать каждую страницу индивидуально. Он предлагал к рассмотрению гипотетический сценарий смены универсальной единицы «виртуальный пиксел» на «стандартный кегль». Вот, как вы выразились, «о чем вообще разговор».
        • +2
          Спасибо за поддержку. А предыдущему оратору я уже ответил. Добавлю только, что неплохо бы, перед тем, как рассуждать на какую-то тему, поступить не как «гуманитарий», а как «технарь» — то есть ознакомиться с фундаментальной «матчастью», то есть с теми самыми «какашками мамонта», которые он так презирает, ибо традиции типографского дела несколько столетий и наука эта непростая. Я, например, знаю только основы.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вот вы сами вчитайтесь во всю эту, простите, дребедень. Сначала они объявили, что 1 пиксель — 1/96 дюйма (как будто других мониторов не бывает). Кстати, у Лебедева в Ководстве написано, что стандарта было два. Один — от MS, другой от Apple. Потом эти злодеи коэффициент еще придумали для ретины…

        Коронная фраза:
        стандарт теперь разрешает искажать физические размеры

        Это еще похлеще, чем отрицать E = mc^2.
        И вот этими, с позволения сказать, стандартами мы все вынуждены пользоваться!

        Я вам так скажу: пиксел — это пиксел. Пвадратик такой трёхцветный. И если стандарт начинает вместо него подсовывать невесть что — это уже само по себе есть повод задуматься о том, чтобы не пользоваться этой неведомой хренью, простите. Мерять в сантиметрах, дюймах, пунктах… В чём-то, что не объявят вдруг внезапно другого размера. Не находите?
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            пиксели-оборотни покусали другие абсолютные единицы — те самые сантиметры, дюймы и пункты — и они тоже получили способность внезапно оказываться другого размера

            А-а-а!!! Мир сошёл с ума! Дайте мне звездолёт и другой глобус.
    • 0
      Я пробовал писать медиа-запросы в сантиметрах — получается просто и удобно. Лучше, чем в пикселах с емами.
  • +1
    Гляжу на первую в посте картинку, и вспоминаю, что Морфеус скушал другую таблетку, после того, как Нео выбрал одну из двух. Что как бы намекает :)

    Ну а что до темы статьи, автор как-то… сплеча, что ли, рубит. Производители, к сожалению, уже сами не знают, что будет завтра. Пиксель, как PICture ELement, был всю жизнь точкой картинки в понимании того, что, скажем, в картинке 200 точек х 100 точек их было 200 по ширине и 100 по высоте.

    «Внезапно» (на самом деле — жизнь заставила) придумали преобразование, что точка на экране = логическая точка картинки, умноженная на некий коэффициент, который позволяет подтянуть увеличение всего на экране до уровня, комфортного для глаз конкретного юзера. Я пишу слово «внезапно» в кавычках, потому что идея красивая и простая для понимания, но, ОПА!, самая популярная в в мире ОС оказалась не в состоянии принять ее настолько, что даже на сегодня не может каждую процедуру вывода провести через такое преобразование. Что же, получаем логические и физические точки (и эти разные точки иные браузеры уже не всегда адекватно применяют при расчете всяких em) — что уже мешает применять медиа-запросы.

    Хорошо, смотрим на retina-экраны. Там точек вообще сильно больше, чем нужно для вывода. «Лишние точки» позволяют сглаживать тексты, но при выводе графики особым образом «не замечаются». Тут em вообще рассчитать непонятно как, ведь у нас уже не два, а три, или даже четыре типа точек на экране и в «уме» ОС.

    Завтра MS перепишет винду так, что она сможет масштабироваться на сверхкачественных экранах. Уверен на 100%, что логика работы Windows будет в корне отличаться от таковой у OSX на Retina — и дизайнеры отгребут себе еще один головняк. И завтра мы с вами будем ломать голову, что лучше, купить новый бук с экраном 4196 х 2534 (любые высосанные из пальца не кратные ни одному встреченному ранее разрешению числа подставьте), на котором Windows 9.2 будет нет-нет, да «плыть», или поискать и взять старый с экраном 1280х1024 :)

    А теперь вернемся к теме статьи. Привяжемся к пикселам — отгребем завтра. Привяжемся к относительным величинам — отгребем сегодня. Забьем на все новомодности, и вернемся к верстке таблицами — потеряем «красоту неописуемую», но получим old-fashioned стабильность дезигна. В общем, тот еще выбор!
    • +1
      Привязывать размеры шрифтов и элементов страницы напрямую к реальным сантиметрам — нельзя. Не всмысле, технологии не позволяют, а всмысле, делать так — ошибка. Я изложил, почему, в комменте выше. Пожалуйста, по этой теме отвечайте на тот коммент, чтобы не дробить нить дискуссии.
      • +1
        Привязывать размеры шрифтов и элементов страницы напрямую к реальным сантиметрам — нельзя.

        Разумеется, нельзя. Размер шрифтов должен быть привязан к кеглю, который определяется параметром устройства. Например, книга формата А4 обычно печатается шрифтом 12pt, а маленькая книжка — 9pt. Так почему же подобным образом не обращаться с устройствами?

        Плюс к этому, у пользователя должна быть кнопка «сделать крупнее/мельче», которая влияет только на размер em-а (и вместе с ним на размер шрифта), а не на сантиметр.

        А размер элементов страницы — на усмотрение дизайнера и определяться он должен соотношением геометрических размеров экрана (10 дюймов) и размером шрифта (10 пунктов)
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Потому что размер шрифта не должен быть прибит к конкретному значению. Должна быть возможность менять размеры букв, не меняя при этом дюймы и сантиметры. Иными словами, не меняя формат страницы, изменить размер букв и значение em. Тогда вёрстка действительно будет гибкой.
            • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              Так вам никто и не предлагает менять дюймы и сантиметры, просто речь идет об одном и том же с разных технологических «уровней» — что вообще такое пункт? Это доля физического дюйма (кстати можно также заметить, что дюйм — также относительная и к тому же абстрактная величина), а именно 1/72. И когда вы меняете размер шрифта в типографии — вы используете просто другое количество этих же долей этого же дюйма. А что такое CSS Pixel? Аналогичная доля дюйма (кстати несовсем уж и дюйма, если говорить уж совсем точно, то доля радиана — вот наткнулся на интересную ссылку inamidst.com/stuff/notes/csspx), а уж вопрос о том, как проецируются CSS пиксели на физические пиксели, это вопрос совершенно к другим людям. Ну а почему в верстке не используются именно пункты, как в типографике, то это также вопрос «не в кассу» — в разное время использовалось разное количество систем измерения, и сегодня в разных странах используются разные системы измерения.
              • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      По поводу Морфеуса. Пересмотрел эту, Морфеус в ней таблетку не ест, а в следующей сцене у него в ладони таблетки уже нет.

      Но это и не важно. Таблетка — это просто символический способ сказать «да» или «нет», и ничего более. Когда Нео съедает красную, с ним ничего не происходит. Морфеус просто приглашает его в другую комнату.
      • +1
        Насколько я помню, красная таблетка это трекер, с помощью которого команда Морфеуса находит тело Нео в реальном мире.
  • +1
    Я уже довольно давно пришел к аналогичным выводам.
    Практика повсеместного использования em-ов уходит корнями в старые времена, когда браузеры не умели корректно масштабировать страницы. Сегодня даже для размеров шрифта использовать их совершенно не обязательно и даже неудобно (кроме некоторых специфичных случаев).

    На текущий момент я в основном использую:
    — пиксели
    — пиксели с умножением на коэффициент в препроцессоре (LESS, SASS, etc)
    — проценты
    — rem-ы (пока еще осторожно и с fallback-ами, но вообще штука удобная).

    А em-ы удобны в отдельных ситуациях, но как мейнстримная единица — устарели.
  • 0
    А почему это размер шрифта задаётся в точках, а не в типографских пунктах? (То есть 10pt вместо 12px?)
    • 0
      Вы вольны задавать размер шрифта в любой из доступных единиц. Нравятся пункты — используйте пункты. Просто вы должны понимать, что вы не избавляетесь при этом от пикселов, потому что ваши пункты происходят из пикселов путем умножения на коэффициент, а для сравнения с виртуальным размером экрана они обратно пересчитываются в пикселы.

      А почему пункты использовать среди верстальщиков не принято… ну просто это для нас не естественный способ описать шрифт, а очередная синтетическая величина, не имеющая никаких преимуществ перед остальными. И перепривыкать к ней нет никакого смысла.
      • 0
        Естественно я это понимаю. Просто пересчет пикселей в нормальные единицы не должен быть задачей верстальщика. Это — проблема браузера. Согласны? (виноват, не заметил, что вы это не мне :) )
  • 0
    Из гитхабовского стайлгайда: «Use px for font-size, because it offers absolute control over text».
    При сложном дизайне с большим количеством типографики только пиксели могут обеспечить соответствие макету. Вряд ли это добавляет трудоемкости в адаптивном дизайне — обычно на версиях для планшетов и телефонов меняются только размеры заголовков. Проблемы это может доставить только в создании версии для слабовидящих на основе текущей верстки, но на моей практике мне приходилось сталкиваться с этим лишь однажды, потому что такую функциональность требуют обычно лишь госзаказчики.
    • 0
      Не очень понимаю, почему вы принимаете за образец GitHub, свёрстанный совершенно деревянно — никакой адаптивности к разрешению. Всё прибито гвоздями к пикселям. Про соответствие макету — не скажу. Очень многое зависит от того, кто составляет макет и как он это делает.

      Но насчет дизайна для слабовидящих — я себя к таковым не причисляю. Однако периодически очень хочется на экране смартфона увеличить шрифт, не приближая страницу, то есть так, чтобы буквы стали крупнее, а ширина страницы и размер элементов оставался прежним. У вас такого желания не возникало? А ваши собственные сайты могут так?
      • +1
        А как вы собираетесь в мобильном браузере увеличивать шрифт, не увеличивая всего остального?

        Если в браузере есть для этого специальная настройка, то браузер нормально увеличит и пиксельные шрифты, ничего сложного тут нет. По крайней мере, старушка Opera Mini прекрасно с этим справлялась на любых сайтах.

        А если в браузере специальной настройки нет, то о чем вообще речь?
        • 0
          Честно говоря, я хочу, чтобы обычный pinch zoom на сайте увеличивал шрифт, а не создавал чёртовы полосы прокрутки. Можно такой сайт сделать?

          Потому что мне, на самом деле, не нужен zoom, при котором расползается вся страница. Я просто хочу покрупнее почитать текст.

          В идеале, pinch zoom на тексте должен увеличивать шрифт, а на картинке — увеличивать картинку. Но это, видимо, должно быть поддержано браузером…
          • 0
            Извините конечно, но такой вопрос — а если у вас в принципе плохое зрение и вы вынуждены носить очки, или как поступают многие люди используете для чтения обычную лупу, то читая книгу с мелким шрифтом и картинками, то у вас увеличивается только текст или вместе с картинками?
      • +2
        Мне очень нравится «деревянный» GitHub, нигде ничего не ползет и все очень предсказуемо. Мне не приходит в голову пользоваться им на телефоне.
        К вопросу о пикселах. Я хочу контролировать то, как моя работа выглядит на всех устройствах. Если у проекта есть достаточный бюджет, то хорошо сверстанный адаптивный сайт будет выглядеть на всех мобильных устройствах одинаково, хорошо, читабельно, в соответствии с дизайном и предсказуемо. Кстати, мне очень не нравится, когда сайты неограниченно тянутся на весь мой шикарный 21:9 дисплей. И когда жирные заголовки, которые рассчитаны на одну строку вдруг перескакивают на вторую. Или пункты инлайнового меню вдруг отображаются в две строки. Да, мне не хочется увеличивать шрифт на моем смартфоне — если сайт абсолютно не рассчитан под мобильные устройства, то его никакие относительные величины не спасут. Зато они помогут ему выглядеть как говно.
        P.S. Пример — На всех разрешениях кегль контента один и тот же, проблем с чтением нет. Использованы пикселы, соответсвие макетам до пиксела. Еще раз — зачем нужны относительные величины? Чтобы сверстанный на коленке сайт можно было читать на телефоне с дисплеем 320x240?
        • 0
          Размер экрана моего телефона — 5.3 дюйма. Это — первый мой личный смартфон. Купил, чтобы иметь 2 в 1 — и телефон, и планшет. И устройство бы прекрасно справилось с задачей, но пользуясь им, я невольно почти все сайты в интернете разделил на две категории:
          1. Сайты типа GitHub, интерфейс которых, чтобы просто прочитать текст, нужно увеличивать настолько, что без панорамирования в процессе чтения — никуда. Очень неудобно. Потому что они «деревянные».
          2. Сайты, которые считают себя мобильными — очень мало функционала, очень крупные шрифты, всё рассчитано на 3 дюйма в диагонали.

          Я привел вам в пример этот мобильник не чтобы попонтоваться (а он действительно дорогой). Просто он нестандартный. Больше телефона, но меньше планшета. Поэтому он — идеален для проверки качества вёрстки.

          Сделать сайт, который запросит разрешение экрана 1280 пикселей в ширину и нарисует себя в них правильно — не фокус. Интересно сделать сайт, который будет удобен и красив на любом экране.

          Пример вы привели неплохой. Но пример frameless, приведенный автором статьи, мне нравится больше.
  • +1
    Как можно вообще обсуждать «em» когда уже сто лет в обед как существуют «rem», то же самое, только не нужно всё время ходить с калькулятором.
    • +2
      Речь в статье не об этом. А о том, что px — целое, а em — с плавающей точкой. А CSS сделан так, что при сравнении получается зазор.
  • 0
    Мне, когда я знакомился с адаптивной версткой, пришла идея, что после введения дисплеев высокой четкости пикселом в верстке должна называться виртуальная точка, минимально различимая человеческим глазом. А устройство (в зависимости от размеров экрана, предполагаемого расстояния до глаз) и пользователь, настраивая его, пусть сами решают, какое у него разрешение в таких виртуальных пикселах.
    • НЛО прилетело и опубликовало эту надпись здесь

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.