Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
Капелька сарказма с утра:)
Вы можете задать размер шрифта в пунктах и сантиметрах, но как тогда браузер поймет, какой высоты делать базовый шрифт? Он тупо умножает ваши пункты и em'ы на дефолтное значение. Для em'а это 16, для pt — 4/3, а коэффициент для сантиметра и дюйма берется из настроек ОС. В результате всегда получаются пикселы.
В статье это сказано в параграфе «Em'ы в media queries — это посредник между двумя пиксельными величинами: базовым размером шрифта и шириной окна браузера».
В статье это сказано в параграфе «Em'ы в media queries — это посредник между двумя пиксельными величинами: базовым размером шрифта и шириной окна браузера».
Именно это я и хотел сказать. :)
Браузер же может узнать плотность пикселей от операционной системы.
Может, но не всегда это делает, считая дефолтные 96. Или ОС может сообщить дефолтные 96, не смотря на то, что знает точные. В Ubunte как минимум (а то и во всех иксах по умолчанию) есть два разных наборов параметров, которые по идее должны быть одинаковые, но на деле из одного всегда вытекает dpi 96, а из другого на основе EDID дисплея.
Все вышеизложенные аргументы в пользу употребления пиксельных значений в адаптивной вёрстке признаю справедливыми.
Прямо толковая статья! Пока читал и скроллил вниз, все боялся увидеть, что это перевод, но нет! Спасибо!
Все толково. Единственная просьба, тем кто делает сайты. Если используете картинки для оформления (не как контент) проверяйте как выглядит сайт с этим плагином https://addons.mozilla.org/en-US/firefox/addon/nosquint/. Выставьте увеличение текста 120%, а картинки 100%.
«Menu / View / Zoom / Zoom text only» — и не нужно никаких расширений. Вот только это нестандартное по сути масштабирование и имеет ли смысл так проверять — большой вопрос.
Спасибо. Как-то привык уже пользоваться плагином, надо будет отучиться.
Для меня и моих знакомых, определенно в этом есть смысл. Имея монитор 23 дюйма и «фулХД» разрешение, так же имею рабочий стол шириной 110см. и двигать по столу монитор нет совсем никакого желания. Так-что без такого нестандартного разрешения не обойтись.
нестандартное по сути масштабирование и имеет ли смысл так проверять — большой вопрос.
Для меня и моих знакомых, определенно в этом есть смысл. Имея монитор 23 дюйма и «фулХД» разрешение, так же имею рабочий стол шириной 110см. и двигать по столу монитор нет совсем никакого желания. Так-что без такого нестандартного разрешения не обойтись.
Из всего этого можно сделать лишь один простой, но неутешительный вывод: люди, проектировавшие media queries, забыли о том, что числа с плавающей точкой нельзя сравнивать с помощью знака равенства.
Сначала приведу гипотетический формат, в котором описываемая в статье проблема была бы решена:
Введение подобного определения в CSS решило бы эту проблему раз и навсегда. К сожалению, автор статьи прав в том, что единственный по-настоящему радикальный способ пользоваться тем, что есть сейчас — это использовать px. Но вот в постановке вопроса я не согласен.
Защищать пиксельные размеры на основании этой недоработки — всё равно что защищать топор в сравнении с ружьем на основании того, что последнее дает осечки. Пиксели противоестественны. Человек придумал их как техническое средство для отображения цифровой (читай — дискретной) информации. Привязывание дизайна к размеру пикселя — костыль, на который приходилось идти дизайнерам UI из-за того, что экраны в силу своего несовершенства торчали этими пикселями в глаз пользователю.
Обращу ваше внимание на то, что есть другая — более фундаментальная область вёрстки — вёрстка классическая, книжная, к которой сейчас всё сильнее и сильнее приближается по качеству web-дизайн и которая никогда не знала слова «пиксель».
Но это всё — лирика. А конкретно, пока у вас плотность точек порядка сотни, вы можете мерять хоть в пикселях, хоть в экранах. Но когда она — 300, вы уже обязаны вспомнить, что человеческий глаз воспринимает информацию не в пикселях, а в сантиметрах. И именно страница «меньше пяти сантиметров» должна быть перевёрстана, чтобы не мельчить и легко читаться. Так рассуждал бы верстальщик газетной колонки. Как вы, уперевшись в пиксель, добьетесь одинаково хорошего вида страницы на старом мониторе 72dpi и одновременно на экране новомодного iPad?
Общая мысль такова: если в результате анализа какой-то возможности выясняется, что она завязана на пиксели (как в данном случае), значит эта возможность спроектирована плохо. Потому что «плохость» пикселя — фундаментальный факт. А «хорошесть» существующей media queries — под вопросом.
Истинное проклятие, стоящее на пути современной вёрстки интерфейсов — растровые изображения. К счастью, мы уже научились их эффективно векторизовать и тянуть, хотя процессоры должны подрости, чтобы это стало мейнстримом. Но это — совсем другая история…
Сначала приведу гипотетический формат, в котором описываемая в статье проблема была бы решена:
@media (max-width: 20em) { /* ... */ }
@media (min-width: ">20em") { /* ... */ }
Введение подобного определения в CSS решило бы эту проблему раз и навсегда. К сожалению, автор статьи прав в том, что единственный по-настоящему радикальный способ пользоваться тем, что есть сейчас — это использовать px. Но вот в постановке вопроса я не согласен.
Защищать пиксельные размеры на основании этой недоработки — всё равно что защищать топор в сравнении с ружьем на основании того, что последнее дает осечки. Пиксели противоестественны. Человек придумал их как техническое средство для отображения цифровой (читай — дискретной) информации. Привязывание дизайна к размеру пикселя — костыль, на который приходилось идти дизайнерам UI из-за того, что экраны в силу своего несовершенства торчали этими пикселями в глаз пользователю.
Обращу ваше внимание на то, что есть другая — более фундаментальная область вёрстки — вёрстка классическая, книжная, к которой сейчас всё сильнее и сильнее приближается по качеству web-дизайн и которая никогда не знала слова «пиксель».
Но это всё — лирика. А конкретно, пока у вас плотность точек порядка сотни, вы можете мерять хоть в пикселях, хоть в экранах. Но когда она — 300, вы уже обязаны вспомнить, что человеческий глаз воспринимает информацию не в пикселях, а в сантиметрах. И именно страница «меньше пяти сантиметров» должна быть перевёрстана, чтобы не мельчить и легко читаться. Так рассуждал бы верстальщик газетной колонки. Как вы, уперевшись в пиксель, добьетесь одинаково хорошего вида страницы на старом мониторе 72dpi и одновременно на экране новомодного iPad?
Общая мысль такова: если в результате анализа какой-то возможности выясняется, что она завязана на пиксели (как в данном случае), значит эта возможность спроектирована плохо. Потому что «плохость» пикселя — фундаментальный факт. А «хорошесть» существующей media queries — под вопросом.
Истинное проклятие, стоящее на пути современной вёрстки интерфейсов — растровые изображения. К счастью, мы уже научились их эффективно векторизовать и тянуть, хотя процессоры должны подрости, чтобы это стало мейнстримом. Но это — совсем другая история…
Согласен с вашим предложением
Но вот с остальным поспорю.
Во-первых, я бы предпочел взять на войну надежный топор, нежели бракованное ружье.
Во-вторых, хоть пиксел и является для описания размеров «неестественной» сущностью, он не так плох, как вы его подаете.
Дело в том, что в верстке используются не реальные, а «виртуальные» пикселы. Вы почему-то проигнорировали соответствующий параграф статьи (не поняли, о чем идет речь?). В англоязычных публикациях можно встретить наименование «CSS pixels», противопоставляемое «DPI pixels». Виртуальные пикселы совпадают с реальными на экранах с малым разрешением. На «ретине» же плотность экрана может быть сколько угодно высокой, но виртуальное разрешение привязано не к разрешению, а к размеру экрана.
Как я сказал в статье, на первых четырех поклениях iPhone размер экрана с точки зрения CSS составляет 320×480 пикселов, несмотря на то, что количество реальных пикселов у разных поколений устройства отличается в четыре раза.
Виртуальные пикселы служат для фронтендщика универсальной единицей измерения. Они позволили абстрагироваться от физических разрешений, причем без мучительного переходного периода, характерного для всех остальных положительных изменений, происходящих в мире фронтенда.
Следует понимать, что использование крупных виртуальных пикселов в CSS не мешает использовать изображения в высоком разрешении. То есть вы можете сделать
Таким образом, ваше утверждение «Как вы, уперевшись в пиксель, добьетесь одинаково хорошего вида страницы на старом мониторе 72dpi и одновременно на экране новомодного iPad?» говорит о том, что вы ни разу не пробовали этого делать, потому что такой проблемы даже не стоит.
И наконец, использование виртуальных пикселов вместо единиц измерения реального мира решает еще одну проблему.
Например, если сайт на «умных часах» будет отображаться в том же масштабе, что и на традиционном экране настольного ПК, то масштаб будет настолько крупным для мелкого экранчика, что пользоваться сайтом будет невозможно. Ширина колонки текста составит 10 знаков. Я предпочту, чтобы масштаб на часах был меньше, чем на ПК, ведь я могу поднести их близко к глазам. И наоборот: текст, отображающийся на настенном табло в том же масштабе, что и на ПК, окажется слишком мелким для чтения, даже несмотря на гигантские размеры и высокое разрешение табло.
Поэтому размер виртуального пиксела на каждом устройстве индивидуален и определяется значением DPI, прописанным в ОС. На мобильных устройствах это значение зашито жестко, а на десктопных его можно регулировать по желанию пользователя, причем эта настройка одинаково распространяется на все приложения, а не только на браузер. И если владелец retina-дисплея выставил мелкий масштаб (да еще вывалил за это миллион денег), то значит, ему так удобно. Значит, у него хорошее зрение и ему хочется, чтобы на экране помещалось побольше материала. Пытаться вклиниться в это собственными настройками масштаба вашего сайта — значит идти поперек потребностей пользователя.
@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-дисплея выставил мелкий масштаб (да еще вывалил за это миллион денег), то значит, ему так удобно. Значит, у него хорошее зрение и ему хочется, чтобы на экране помещалось побольше материала. Пытаться вклиниться в это собственными настройками масштаба вашего сайта — значит идти поперек потребностей пользователя.
Вы меня подловили, каюсь. Версткой интерфейсов занимаюсь больше на Android, чем в web (CSS знаю очень поверхностно). Тут я, действительно, полез немного не в свою степь. Однако же, именно из-за того, что я чуть-чуть в стороне от CSS, имею наглость критиковать из-за угла, видя всю картину целиком. Позвольте мне высказать теоретическую точку зрения (ни в коем случае не призываю отказываться от топора, если ружья не стреляют).
Продолжу высказанную мысль: не стоит мерить реальность в мерах, предлагаемых технологией. Технология несовершенна и содержит кучу несуразностей и противоречий.
Давайте просто вспомним, что такое описанный вами «виртуальный пиксель», откуда он возник и зачем нужен. Десять лет назад вольшая часть экранов имела разрешение 90-120dpi и разработка страниц в пикселях настоящих была обычным делом. Очень многие сайты были гвоздями прибиты к пикселям.
А потом внезапно появилась ретина. Сколько там? 250dpi? Нормальный человек, просто открыв любой сайт на таком экране, читал бы текст только под лупой. И поэтому умные люди (Apple?) решили притвориться, что четыре пикселя их устройства — это на самом деле один. Экран вернулся к привычным ~90 «виртуальным» dpi, а имеющиеся сайты не потребовалось срочно переделывать.
С инженерной точки зрения решение было верное. Нельзя же заставить целую индустрию разом взять и забыть про основоположную меру длины!
Но с точки зрения стратегической именно тогда надо было понять, что от px пора отказываться. Все ваши аргументы справедливы, просто вы смотрите на проблему с точки зрения сложившейся (нехорошей) ситуации. Вот, например, вы пишете:
Проблема сформулирована замечательно. Позвольте я предложу решение?
Есть две шкалы расстояния в типографике — шкала, основанная на реальных размерах (сантиметры, дюймы) и шкала, основанная на размере шрифта (пресловутые em). Такая двойственность неслучайна. Человеческий глаз (с точки зрения чтения) имеет два параметра — угол обзора и разрешающую способность. Возможно, вы слышали о типографском правиле не размещать на строке больше определенного (кажется, 66) количества знаков? Вот это — из угла обзора. И отсюда же, кстати, задание максимального размера страницы в 30em. А правило «не печатать кеглем меньше 8» — это про разрешающую способность.
В браузере помимо кнопок Zoom In / Zoom Out должны быть кнопки увеличения/уменьшения шрифта. И если все размеры задаются именно в тех единицах, которые для этих размеров предназначены, то сайт будет прекрасно выглядеть и на часах. Просто на часах стандартный кегль браузера должен быть указан не 12, а 9. Или 8 (если разработчику часов не страшно, что пользователь будет зрение ломать).
Я укажу размер так: текстовая страница шириной не больше экрана и одновременно не больше 35em. Размер шрифта определяется конкретным устройством и может быть подкорректирован пользователем с помощью кнопок «A+», «A-». Вот, собственно, и всё. Никаких пикселей. Поправьте меня, если я ошибаюсь.
А вот это:
PS. Вдогонку: вот это
противоестественно вообще. Для шрифтов существует понятие кегль, привязанное к реальным размерам и метрикам шрифта. Так что шрифты — только в pt
Продолжу высказанную мысль: не стоит мерить реальность в мерах, предлагаемых технологией. Технология несовершенна и содержит кучу несуразностей и противоречий.
Давайте просто вспомним, что такое описанный вами «виртуальный пиксель», откуда он возник и зачем нужен. Десять лет назад вольшая часть экранов имела разрешение 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
Шило на мыло.
Как есть: в ОС записан DPI устройства, а также некий коэффициент А, индивидуальный для каждого устройства. Умножение DPI на А дает размер универсальной единицы «виртуальный пиксел», которую можно непосредственно использовать для задания размеров блочной модели. Размеры шрифтов должны быть пропорциональны А. Увеличение А в настройках браузера должно приводить к перерасчету всех размеров на странице.
Как предлагаете вы: в ОС записан DPI устройства, а также некий коэффициент Б, индивидуальный для каждого устройства. Умножение DPI на Б дает размер универсальной единицы «стандартный кегль», которую можно непосредственно использовать для задания размеров шрифтов. Размеры блочной модели должны быть пропорциональны Б. Увеличение Б в настройках браузера должно приводить к перерасчету всех размеров на странице.
Очевидно, что два подхода не имеют преимуществ друг перед другом. Просто первый подход привычнее вэб-дизайнерам, второй — полиграфистам.
Разница только одна: первый подход работает уже сейчас, и работает хорошо. Второй подход — гипотетический и вряд ли будет реализован.
Но прикол в том, что два подхода — практически одно и то же. Просто смиритесь с тем, что
… кроме media queries. :)
Как есть: в ОС записан DPI устройства, а также некий коэффициент А, индивидуальный для каждого устройства. Умножение DPI на А дает размер универсальной единицы «виртуальный пиксел», которую можно непосредственно использовать для задания размеров блочной модели. Размеры шрифтов должны быть пропорциональны А. Увеличение А в настройках браузера должно приводить к перерасчету всех размеров на странице.
Как предлагаете вы: в ОС записан DPI устройства, а также некий коэффициент Б, индивидуальный для каждого устройства. Умножение DPI на Б дает размер универсальной единицы «стандартный кегль», которую можно непосредственно использовать для задания размеров шрифтов. Размеры блочной модели должны быть пропорциональны Б. Увеличение Б в настройках браузера должно приводить к перерасчету всех размеров на странице.
Очевидно, что два подхода не имеют преимуществ друг перед другом. Просто первый подход привычнее вэб-дизайнерам, второй — полиграфистам.
Разница только одна: первый подход работает уже сейчас, и работает хорошо. Второй подход — гипотетический и вряд ли будет реализован.
Но прикол в том, что два подхода — практически одно и то же. Просто смиритесь с тем, что
font-size для <html> вам придется задать через А, и используйте Б для всего остального.… кроме media queries. :)
Технически разницы нет. Но
Я предлагаю не получать давно известные величины (пункт) методом перемножения попугаев на (пункты * попугаев^(-1) ). Я лишь хочу, чтобы люди понимали, что попугаи — технический костыль.
И еще я хочу, чтобы они (вы, в частности) поняли, что пункт нельзя прибивать к сантиметру. Он должен быть настраиваемым и любая вёрстка должна при его изменении подстраивать размеры текста и подгонять текстовые блоки, не затрагивая остальные элементы дизайна. И именно в этом разница между нашими подходами. Вы считаете, что мера одна — и поэтому упираетесь в «проблему часов». А я утверждаю, что меры две.
Умножение DPI на Б дает размер универсальной единицы «стандартный кегль»
Я предлагаю не получать давно известные величины (пункт) методом перемножения попугаев на (пункты * попугаев^(-1) ). Я лишь хочу, чтобы люди понимали, что попугаи — технический костыль.
И еще я хочу, чтобы они (вы, в частности) поняли, что пункт нельзя прибивать к сантиметру. Он должен быть настраиваемым и любая вёрстка должна при его изменении подстраивать размеры текста и подгонять текстовые блоки, не затрагивая остальные элементы дизайна. И именно в этом разница между нашими подходами. Вы считаете, что мера одна — и поэтому упираетесь в «проблему часов». А я утверждаю, что меры две.
Я не понимаю. Я правильно описал ваш подход или неправильно?
Если неправильно, то в чем разница? Чтобы стандартный кегль не был жестко связан с сантиметром, его и нужно умножать на коэффициент, задаваемый в ОС и регулируемый в настройках браузера. Назовете ли вы его «Б», «попугай-1» или стыдливо умолчите о его существовании, сути это не поменяет. И «проблему часов» переименование коэффициента не решит.
К слову, что за «проблема часов»? Сейчас никакой проблемы как раз таки нет, потому что у каждого устройства свой коэффициент А, который, кстати говоря, называется «device pixel ratio».
Если неправильно, то в чем разница? Чтобы стандартный кегль не был жестко связан с сантиметром, его и нужно умножать на коэффициент, задаваемый в ОС и регулируемый в настройках браузера. Назовете ли вы его «Б», «попугай-1» или стыдливо умолчите о его существовании, сути это не поменяет. И «проблему часов» переименование коэффициента не решит.
К слову, что за «проблема часов»? Сейчас никакой проблемы как раз таки нет, потому что у каждого устройства свой коэффициент А, который, кстати говоря, называется «device pixel ratio».
Кстати говоря размеры «идеальных» CSS пикселей были выбраны анологично приведенным вами типографским правилам, про угол обзора и разрешающуюся способность глаза, только не для книги, как в случае с книжной версткой, а именно для мобильных устройств, которые держат на вытянутой руки. А вопрос, почему CSS пиксели плывут на разных устройствах — это вопрос не к самим пикселям, а к производителям дисплеев и разработчикам ОС/браузеров.
Не понятно, зачем переходить с px на em, если решение со стороны вендоров, производящих устройства с высоким dpi уже принято? Ну давайте, как уже было лет 10, снова метаться — одни будут продолжать использовать пиксели, другие (ну не живется спокойно людям), будут снова пропагандировать em. Что получим? Еще 10 лет метаний между выбором?
То есть вы можете сделать <img src='hd_img_1280x720px.jpg' style='width:200px' alt='Retina image'>, и на iPhone 4/5 оно отобразится в высоком разрешении, несмотря на то, что в CSS задан размер 200px.
выходит, если сделать картинку физически 200px то на экране получится «мыло». как в таком случае рассчитать оптимальный размер картинки? %)
Забудьте про классическую книжную вёрстку, она устарела как какашки мамонта и к вебу неприменима.
Вы готовы верстать вручную все страницы сайта, вместе со всем контентом и каждым новым комментарием? Что, прям под весь зоопарк экранов, принтеров и скрин-ридеров? Нет? Ну так о чём вообще разговор?
Что значит «плохость пикселя — фундаментальный факт»? Реальность такова, что сам пискель — это фундаментальный факт, потому что всё, на чём выводятся сегодня страницы, состоит из этих самых пикселей. Ваше же к этому отношение вообще никого не интересует.
Вообще, заявления в духе «плохость фундаментального факта» — явный признак гуманитария. У гуманитариев да, у них закидоны типа «я против E=mc2!» проходят на ура. Вот только в инженерном деле, коим является вёрстка, с гуманитарным подходом делать нечего. Потому что тут результат вашей работы оценивается элементарно — оно или работает, или не работает, независимо от вашего отношения к плохости или хорошести фундаментальных фактов.
Вы готовы верстать вручную все страницы сайта, вместе со всем контентом и каждым новым комментарием? Что, прям под весь зоопарк экранов, принтеров и скрин-ридеров? Нет? Ну так о чём вообще разговор?
Что значит «плохость пикселя — фундаментальный факт»? Реальность такова, что сам пискель — это фундаментальный факт, потому что всё, на чём выводятся сегодня страницы, состоит из этих самых пикселей. Ваше же к этому отношение вообще никого не интересует.
Вообще, заявления в духе «плохость фундаментального факта» — явный признак гуманитария. У гуманитариев да, у них закидоны типа «я против E=mc2!» проходят на ура. Вот только в инженерном деле, коим является вёрстка, с гуманитарным подходом делать нечего. Потому что тут результат вашей работы оценивается элементарно — оно или работает, или не работает, независимо от вашего отношения к плохости или хорошести фундаментальных фактов.
Давайте я просто приведу вам в пример работающую систему вёрстки, не основанную на пикселях.
en.wikipedia.org/wiki/TeX
Небезызвестный автор этой системы (надеюсь, его вы не будете презрительно называть «гуманитарием») потратил больше года на изучение типографского дела. Прочтите The TeXbook
Если бы ни высокий порог вхождения, требуемый, чтобы как следует научиться ей пользоваться (знаю не понаслышке, многое умею сам), она бы прекрасно подошла в качестве альтарнативы связке HTML + CSS, которая в силу стечения обстоятельств оказалась победителем.
Что значит фраза «плохость пикселя — фундаментальный факт» я развёрнуто объяснил. И еще добавил вот здесь. И вы, наверное, просто не прочли внимательно всё целиком — вам просто смелая фраза не понравилась. Потому что дальше вы пишете:
а я всё своё доказательство того, что пикселю в верстке не место построил, по сути, именно на этом вашем утверждении.
Еще раз, кратко: человек смотрит на экран одними и теми же глазами, независимо от dpi экрана. Он может поднести его поближе (что нежелательно) или отойти подальше. Но вёрстка содержимого на экране должна определяться свойствами зрения, а не свойствами экрана.
А вот это вообще не понял, к чему. Я же не предлагаю отказываться от автоматической вёрстки — напротив, предлагаю нормальную систему, при которой она станет действительно адаптивной. Это вы предлагаете подгонять под сто устройств с разным размером пикселя.
А словосочетания типа «какашки мамонта» приберегите для дебатов в детском саду.
en.wikipedia.org/wiki/TeX
Небезызвестный автор этой системы (надеюсь, его вы не будете презрительно называть «гуманитарием») потратил больше года на изучение типографского дела. Прочтите The TeXbook
Если бы ни высокий порог вхождения, требуемый, чтобы как следует научиться ей пользоваться (знаю не понаслышке, многое умею сам), она бы прекрасно подошла в качестве альтарнативы связке HTML + CSS, которая в силу стечения обстоятельств оказалась победителем.
Что значит фраза «плохость пикселя — фундаментальный факт» я развёрнуто объяснил. И еще добавил вот здесь. И вы, наверное, просто не прочли внимательно всё целиком — вам просто смелая фраза не понравилась. Потому что дальше вы пишете:
сам пискель — это фундаментальный факт, потому что всё, на чём выводятся сегодня страницы, состоит из этих самых пикселей
а я всё своё доказательство того, что пикселю в верстке не место построил, по сути, именно на этом вашем утверждении.
Еще раз, кратко: человек смотрит на экран одними и теми же глазами, независимо от dpi экрана. Он может поднести его поближе (что нежелательно) или отойти подальше. Но вёрстка содержимого на экране должна определяться свойствами зрения, а не свойствами экрана.
Вы готовы верстать вручную все страницы сайта, вместе со всем контентом и каждым новым комментарием?
А вот это вообще не понял, к чему. Я же не предлагаю отказываться от автоматической вёрстки — напротив, предлагаю нормальную систему, при которой она станет действительно адаптивной. Это вы предлагаете подгонять под сто устройств с разным размером пикселя.
А словосочетания типа «какашки мамонта» приберегите для дебатов в детском саду.
Извините, но TeX не годится для веба вообще. Он до поздних нулевых годов на практике ничерта не умел юникод, не говоря уже о нормальной многоязычности (которую он не умеет и сейчас, кстати: чтобы сверстать книгу с японским и русским одновременно в LaTeX, нужно немало воевать с его костылями времён 80х годов), одного этого уже достаточно, чтобы не рассматривать его всерьёз. Таблицы в нём реализованы хуже: не надо забывать, что скорость соединения с интернетом ещё не так давно была ограниченной. С картинками отдельная головная боль. Про DOM вообще можно не вспоминать. И напомните мне, в каком году компьютеры научились рендерить TeX с приемлемой скоростью и в каком появился html.
LaTeX — неплохая система для вёрстки бумажных технических вещей. Под них она и заточена. HTML может быть неидеален, но даже он лучше, чем TeX в вебе. Дело не в высоком пороге вхождения, а в принципиально разных областях применения.
LaTeX — неплохая система для вёрстки бумажных технических вещей. Под них она и заточена. HTML может быть неидеален, но даже он лучше, чем TeX в вебе. Дело не в высоком пороге вхождения, а в принципиально разных областях применения.
Во-первых, вы ошибаетесь насчет мультиязычности — используйте XeTeX (и XeLaTeX, соответственно) — там исходные файлы кодируются в UTF-8, как и выходной PDF. Кроме того, в итоговом файле есть гиперссылки, а если вы очень захотите, то встроите туда даже Flash Video (если PDF позволит). Для локализации используйте polyglossia
А во-вторых, если бы то количество денег, которое было вложено в развитие HTML+CSS было вложено в TeX, он бы сейчас только что кофе не варил. Сопоставьте сообщества и вы поймете, что тот факт, что вёрстка в TeX-е до сих пор не превзойдена никем означает, что это — очень хорошая система.
Приведу лишь один живой пример недоделанности большинства HTML-верстальных программ: они не умеют расставлять переносы. Текст с выключкой влево и без переносов смотрится отвратительно для человека, который видел текст с хорошо расставленными переносами (а TeX умеет делать это так, что Word и InDesign рядом не валялись). И, несмотря на то, что расстановка переносов в реальном времени — не задача для современных машин, ее по-прежнему нет.
Причина, на мой взгляд, проста. К сожалению, никто не пытается сделать web красивее. Большинство людей просто устраивает сложившееся положение вещей. А некоторые, вероятно, так давно держали в руках хорошо свёрстанную книгу, что забыли, как она выглядит.
А во-вторых, если бы то количество денег, которое было вложено в развитие HTML+CSS было вложено в TeX, он бы сейчас только что кофе не варил. Сопоставьте сообщества и вы поймете, что тот факт, что вёрстка в TeX-е до сих пор не превзойдена никем означает, что это — очень хорошая система.
Приведу лишь один живой пример недоделанности большинства HTML-верстальных программ: они не умеют расставлять переносы. Текст с выключкой влево и без переносов смотрится отвратительно для человека, который видел текст с хорошо расставленными переносами (а TeX умеет делать это так, что Word и InDesign рядом не валялись). И, несмотря на то, что расстановка переносов в реальном времени — не задача для современных машин, ее по-прежнему нет.
Причина, на мой взгляд, проста. К сожалению, никто не пытается сделать web красивее. Большинство людей просто устраивает сложившееся положение вещей. А некоторые, вероятно, так давно держали в руках хорошо свёрстанную книгу, что забыли, как она выглядит.
«Кодируются в UTF-8» — это ещё далеко не мультиязычность. Он даже RTL без дополнительных движений (костыли, меняющие направление текста по коду символа; ломаются в некоторых случаях) не умеет. О лигатурах, вертикальном письме (которое нужно в японском) и комбинирующих символах можно даже не говорить, а ведь это — только базовый уровень поддержки юникода. В этом и проблема опенсорса: UTF-8, как и юникод вообще — не тривиальная задача. Большинство софта не ломается, если им скармливать латинницу или кириллицу в utf-8, но сломаются даже на нескольких европейских языках, не говоря уже об азиатских. Такое умение utf-8 — не многоязычность.
polyglossia до сих пор очень сырая.
>если PDF позволит
Попробуйте чуть уменьшить размер окна браузера. Представьте, что в это время браузер рендерит PDF заново. Какое железо нужно для такого веба? Сейчас планшетники/телефоны спокойно относятся к повороту экрана именно потому, что им не надо рендерить этот PDF на каждый чих. Адаптивный веб в PDF невозможен.
Вёрстка в TeX, как я и говорил, хороша для технической одноязычной БУМАЖНОЙ литературы. Для остального есть лучшие системы вёрстки. Да, в том числе и для бумаги.
>Приведу лишь один живой пример недоделанности большинства HTML-верстальных программ: они не умеют расставлять переносы
Переносы в HTML? Серьёзно? Когда HTML создавался для того, чтобы его можно было прочитать на последнем тостере? В том числе и без физического экрана (сейчас в нём немало поддержки screen reader'ов)? Извините, Вы не в теме. HTML — не для бумажных документов с фиксированной шириной колонки текста. И да, на word (который не программа для вёрстки вообще) и indesign софт не заканчивается.
polyglossia до сих пор очень сырая.
>если PDF позволит
Попробуйте чуть уменьшить размер окна браузера. Представьте, что в это время браузер рендерит PDF заново. Какое железо нужно для такого веба? Сейчас планшетники/телефоны спокойно относятся к повороту экрана именно потому, что им не надо рендерить этот PDF на каждый чих. Адаптивный веб в PDF невозможен.
Вёрстка в TeX, как я и говорил, хороша для технической одноязычной БУМАЖНОЙ литературы. Для остального есть лучшие системы вёрстки. Да, в том числе и для бумаги.
>Приведу лишь один живой пример недоделанности большинства HTML-верстальных программ: они не умеют расставлять переносы
Переносы в HTML? Серьёзно? Когда HTML создавался для того, чтобы его можно было прочитать на последнем тостере? В том числе и без физического экрана (сейчас в нём немало поддержки screen reader'ов)? Извините, Вы не в теме. HTML — не для бумажных документов с фиксированной шириной колонки текста. И да, на word (который не программа для вёрстки вообще) и indesign софт не заканчивается.
в LaTeX есть несколько замечательных штук — «блочная» модель для всего, «резиновые» распорки, вертикальное выравнивание и стили на языке программирования. это позволяет делать практически любые трюки с отображением для высокоуровневой разметки, в то время как в CSS приходится ждать очередного стандарта или расширения.
Охотно разделяю ваши выпады в адрес гуманитариев, но с мнением bigfatbrowncat о плохости пиксела я согласен.
Мое рабочее место включает четыре разнокалиберных монитороа. Все четыре — низкой плотности пикселов, то есть имеют привязку реальных пикселов к виртуальным как один к одному. Но размер реальных пикселов у них отличается! Хуже того, самая популярная в мире ОС не позволяет задать DPI индивидуально для каждого монитора. Да и даже глобальная настройка DPI работает через одно место, как верно подметил achekalin.
Но через несколько лет у всех профессионалов на рабочих местах будут «ретины». И тогда понятие «пиксела» перестанет для пользователя иметь всякий смысл, потому что пикселы больше не видны невооруженным глазом, а физическое разрешение изображений, отобразаемых на экране, никогда не будет совпадать с фактическим размером изображения в файле: старые изображения будут для этого слишком малы, а HD-изображения — слишком велики.
Далее. Ваша нападка про книжную верстку несправедлива. bigfatbrowncat вовсе не предлагал верстать каждую страницу индивидуально. Он предлагал к рассмотрению гипотетический сценарий смены универсальной единицы «виртуальный пиксел» на «стандартный кегль». Вот, как вы выразились, «о чем вообще разговор».
Мое рабочее место включает четыре разнокалиберных монитороа. Все четыре — низкой плотности пикселов, то есть имеют привязку реальных пикселов к виртуальным как один к одному. Но размер реальных пикселов у них отличается! Хуже того, самая популярная в мире ОС не позволяет задать DPI индивидуально для каждого монитора. Да и даже глобальная настройка DPI работает через одно место, как верно подметил achekalin.
Но через несколько лет у всех профессионалов на рабочих местах будут «ретины». И тогда понятие «пиксела» перестанет для пользователя иметь всякий смысл, потому что пикселы больше не видны невооруженным глазом, а физическое разрешение изображений, отобразаемых на экране, никогда не будет совпадать с фактическим размером изображения в файле: старые изображения будут для этого слишком малы, а HD-изображения — слишком велики.
Далее. Ваша нападка про книжную верстку несправедлива. bigfatbrowncat вовсе не предлагал верстать каждую страницу индивидуально. Он предлагал к рассмотрению гипотетический сценарий смены универсальной единицы «виртуальный пиксел» на «стандартный кегль». Вот, как вы выразились, «о чем вообще разговор».
Спасибо за поддержку. А предыдущему оратору я уже ответил. Добавлю только, что неплохо бы, перед тем, как рассуждать на какую-то тему, поступить не как «гуманитарий», а как «технарь» — то есть ознакомиться с фундаментальной «матчастью», то есть с теми самыми «какашками мамонта», которые он так презирает, ибо традиции типографского дела несколько столетий и наука эта непростая. Я, например, знаю только основы.
Вот вы сами вчитайтесь во всю эту, простите, дребедень. Сначала они объявили, что 1 пиксель — 1/96 дюйма (как будто других мониторов не бывает). Кстати, у Лебедева в Ководстве написано, что стандарта было два. Один — от MS, другой от Apple. Потом эти злодеи коэффициент еще придумали для ретины…
Коронная фраза:
Это еще похлеще, чем отрицать E = mc^2.
И вот этими, с позволения сказать, стандартами мы все вынуждены пользоваться!
Я вам так скажу: пиксел — это пиксел. Пвадратик такой трёхцветный. И если стандарт начинает вместо него подсовывать невесть что — это уже само по себе есть повод задуматься о том, чтобы не пользоваться этой неведомой хренью, простите. Мерять в сантиметрах, дюймах, пунктах… В чём-то, что не объявят вдруг внезапно другого размера. Не находите?
Коронная фраза:
стандарт теперь разрешает искажать физические размеры
Это еще похлеще, чем отрицать E = mc^2.
И вот этими, с позволения сказать, стандартами мы все вынуждены пользоваться!
Я вам так скажу: пиксел — это пиксел. Пвадратик такой трёхцветный. И если стандарт начинает вместо него подсовывать невесть что — это уже само по себе есть повод задуматься о том, чтобы не пользоваться этой неведомой хренью, простите. Мерять в сантиметрах, дюймах, пунктах… В чём-то, что не объявят вдруг внезапно другого размера. Не находите?
Я пробовал писать медиа-запросы в сантиметрах — получается просто и удобно. Лучше, чем в пикселах с емами.
Гляжу на первую в посте картинку, и вспоминаю, что Морфеус скушал другую таблетку, после того, как Нео выбрал одну из двух. Что как бы намекает :)
Ну а что до темы статьи, автор как-то… сплеча, что ли, рубит. Производители, к сожалению, уже сами не знают, что будет завтра. Пиксель, как PICture ELement, был всю жизнь точкой картинки в понимании того, что, скажем, в картинке 200 точек х 100 точек их было 200 по ширине и 100 по высоте.
«Внезапно» (на самом деле — жизнь заставила) придумали преобразование, что точка на экране = логическая точка картинки, умноженная на некий коэффициент, который позволяет подтянуть увеличение всего на экране до уровня, комфортного для глаз конкретного юзера. Я пишу слово «внезапно» в кавычках, потому что идея красивая и простая для понимания, но, ОПА!, самая популярная в в мире ОС оказалась не в состоянии принять ее настолько, что даже на сегодня не может каждую процедуру вывода провести через такое преобразование. Что же, получаем логические и физические точки (и эти разные точки иные браузеры уже не всегда адекватно применяют при расчете всяких em) — что уже мешает применять медиа-запросы.
Хорошо, смотрим на retina-экраны. Там точек вообще сильно больше, чем нужно для вывода. «Лишние точки» позволяют сглаживать тексты, но при выводе графики особым образом «не замечаются». Тут em вообще рассчитать непонятно как, ведь у нас уже не два, а три, или даже четыре типа точек на экране и в «уме» ОС.
Завтра MS перепишет винду так, что она сможет масштабироваться на сверхкачественных экранах. Уверен на 100%, что логика работы Windows будет в корне отличаться от таковой у OSX на Retina — и дизайнеры отгребут себе еще один головняк. И завтра мы с вами будем ломать голову, что лучше, купить новый бук с экраном 4196 х 2534 (любые высосанные из пальца не кратные ни одному встреченному ранее разрешению числа подставьте), на котором Windows 9.2 будет нет-нет, да «плыть», или поискать и взять старый с экраном 1280х1024 :)
А теперь вернемся к теме статьи. Привяжемся к пикселам — отгребем завтра. Привяжемся к относительным величинам — отгребем сегодня. Забьем на все новомодности, и вернемся к верстке таблицами — потеряем «красоту неописуемую», но получим old-fashioned стабильность дезигна. В общем, тот еще выбор!
Ну а что до темы статьи, автор как-то… сплеча, что ли, рубит. Производители, к сожалению, уже сами не знают, что будет завтра. Пиксель, как PICture ELement, был всю жизнь точкой картинки в понимании того, что, скажем, в картинке 200 точек х 100 точек их было 200 по ширине и 100 по высоте.
«Внезапно» (на самом деле — жизнь заставила) придумали преобразование, что точка на экране = логическая точка картинки, умноженная на некий коэффициент, который позволяет подтянуть увеличение всего на экране до уровня, комфортного для глаз конкретного юзера. Я пишу слово «внезапно» в кавычках, потому что идея красивая и простая для понимания, но, ОПА!, самая популярная в в мире ОС оказалась не в состоянии принять ее настолько, что даже на сегодня не может каждую процедуру вывода провести через такое преобразование. Что же, получаем логические и физические точки (и эти разные точки иные браузеры уже не всегда адекватно применяют при расчете всяких em) — что уже мешает применять медиа-запросы.
Хорошо, смотрим на retina-экраны. Там точек вообще сильно больше, чем нужно для вывода. «Лишние точки» позволяют сглаживать тексты, но при выводе графики особым образом «не замечаются». Тут em вообще рассчитать непонятно как, ведь у нас уже не два, а три, или даже четыре типа точек на экране и в «уме» ОС.
Завтра MS перепишет винду так, что она сможет масштабироваться на сверхкачественных экранах. Уверен на 100%, что логика работы Windows будет в корне отличаться от таковой у OSX на Retina — и дизайнеры отгребут себе еще один головняк. И завтра мы с вами будем ломать голову, что лучше, купить новый бук с экраном 4196 х 2534 (любые высосанные из пальца не кратные ни одному встреченному ранее разрешению числа подставьте), на котором Windows 9.2 будет нет-нет, да «плыть», или поискать и взять старый с экраном 1280х1024 :)
А теперь вернемся к теме статьи. Привяжемся к пикселам — отгребем завтра. Привяжемся к относительным величинам — отгребем сегодня. Забьем на все новомодности, и вернемся к верстке таблицами — потеряем «красоту неописуемую», но получим old-fashioned стабильность дезигна. В общем, тот еще выбор!
Привязывать размеры шрифтов и элементов страницы напрямую к реальным сантиметрам — нельзя. Не всмысле, технологии не позволяют, а всмысле, делать так — ошибка. Я изложил, почему, в комменте выше. Пожалуйста, по этой теме отвечайте на тот коммент, чтобы не дробить нить дискуссии.
Привязывать размеры шрифтов и элементов страницы напрямую к реальным сантиметрам — нельзя.
Разумеется, нельзя. Размер шрифтов должен быть привязан к кеглю, который определяется параметром устройства. Например, книга формата А4 обычно печатается шрифтом 12pt, а маленькая книжка — 9pt. Так почему же подобным образом не обращаться с устройствами?
Плюс к этому, у пользователя должна быть кнопка «сделать крупнее/мельче», которая влияет только на размер em-а (и вместе с ним на размер шрифта), а не на сантиметр.
А размер элементов страницы — на усмотрение дизайнера и определяться он должен соотношением геометрических размеров экрана (10 дюймов) и размером шрифта (10 пунктов)
Потому что размер шрифта не должен быть прибит к конкретному значению. Должна быть возможность менять размеры букв, не меняя при этом дюймы и сантиметры. Иными словами, не меняя формат страницы, изменить размер букв и значение em. Тогда вёрстка действительно будет гибкой.
Так вам никто и не предлагает менять дюймы и сантиметры, просто речь идет об одном и том же с разных технологических «уровней» — что вообще такое пункт? Это доля физического дюйма (кстати можно также заметить, что дюйм — также относительная и к тому же абстрактная величина), а именно 1/72. И когда вы меняете размер шрифта в типографии — вы используете просто другое количество этих же долей этого же дюйма. А что такое CSS Pixel? Аналогичная доля дюйма (кстати несовсем уж и дюйма, если говорить уж совсем точно, то доля радиана — вот наткнулся на интересную ссылку inamidst.com/stuff/notes/csspx), а уж вопрос о том, как проецируются CSS пиксели на физические пиксели, это вопрос совершенно к другим людям. Ну а почему в верстке не используются именно пункты, как в типографике, то это также вопрос «не в кассу» — в разное время использовалось разное количество систем измерения, и сегодня в разных странах используются разные системы измерения.
По поводу Морфеуса. Пересмотрел эту, Морфеус в ней таблетку не ест, а в следующей сцене у него в ладони таблетки уже нет.
Но это и не важно. Таблетка — это просто символический способ сказать «да» или «нет», и ничего более. Когда Нео съедает красную, с ним ничего не происходит. Морфеус просто приглашает его в другую комнату.
Но это и не важно. Таблетка — это просто символический способ сказать «да» или «нет», и ничего более. Когда Нео съедает красную, с ним ничего не происходит. Морфеус просто приглашает его в другую комнату.
Я уже довольно давно пришел к аналогичным выводам.
Практика повсеместного использования em-ов уходит корнями в старые времена, когда браузеры не умели корректно масштабировать страницы. Сегодня даже для размеров шрифта использовать их совершенно не обязательно и даже неудобно (кроме некоторых специфичных случаев).
На текущий момент я в основном использую:
— пиксели
— пиксели с умножением на коэффициент в препроцессоре (LESS, SASS, etc)
— проценты
— rem-ы (пока еще осторожно и с fallback-ами, но вообще штука удобная).
А em-ы удобны в отдельных ситуациях, но как мейнстримная единица — устарели.
Практика повсеместного использования em-ов уходит корнями в старые времена, когда браузеры не умели корректно масштабировать страницы. Сегодня даже для размеров шрифта использовать их совершенно не обязательно и даже неудобно (кроме некоторых специфичных случаев).
На текущий момент я в основном использую:
— пиксели
— пиксели с умножением на коэффициент в препроцессоре (LESS, SASS, etc)
— проценты
— rem-ы (пока еще осторожно и с fallback-ами, но вообще штука удобная).
А em-ы удобны в отдельных ситуациях, но как мейнстримная единица — устарели.
А почему это размер шрифта задаётся в точках, а не в типографских пунктах? (То есть 10pt вместо 12px?)
Вы вольны задавать размер шрифта в любой из доступных единиц. Нравятся пункты — используйте пункты. Просто вы должны понимать, что вы не избавляетесь при этом от пикселов, потому что ваши пункты происходят из пикселов путем умножения на коэффициент, а для сравнения с виртуальным размером экрана они обратно пересчитываются в пикселы.
А почему пункты использовать среди верстальщиков не принято… ну просто это для нас не естественный способ описать шрифт, а очередная синтетическая величина, не имеющая никаких преимуществ перед остальными. И перепривыкать к ней нет никакого смысла.
А почему пункты использовать среди верстальщиков не принято… ну просто это для нас не естественный способ описать шрифт, а очередная синтетическая величина, не имеющая никаких преимуществ перед остальными. И перепривыкать к ней нет никакого смысла.
Из гитхабовского стайлгайда: «Use px for font-size, because it offers absolute control over text».
При сложном дизайне с большим количеством типографики только пиксели могут обеспечить соответствие макету. Вряд ли это добавляет трудоемкости в адаптивном дизайне — обычно на версиях для планшетов и телефонов меняются только размеры заголовков. Проблемы это может доставить только в создании версии для слабовидящих на основе текущей верстки, но на моей практике мне приходилось сталкиваться с этим лишь однажды, потому что такую функциональность требуют обычно лишь госзаказчики.
При сложном дизайне с большим количеством типографики только пиксели могут обеспечить соответствие макету. Вряд ли это добавляет трудоемкости в адаптивном дизайне — обычно на версиях для планшетов и телефонов меняются только размеры заголовков. Проблемы это может доставить только в создании версии для слабовидящих на основе текущей верстки, но на моей практике мне приходилось сталкиваться с этим лишь однажды, потому что такую функциональность требуют обычно лишь госзаказчики.
Не очень понимаю, почему вы принимаете за образец GitHub, свёрстанный совершенно деревянно — никакой адаптивности к разрешению. Всё прибито гвоздями к пикселям. Про соответствие макету — не скажу. Очень многое зависит от того, кто составляет макет и как он это делает.
Но насчет дизайна для слабовидящих — я себя к таковым не причисляю. Однако периодически очень хочется на экране смартфона увеличить шрифт, не приближая страницу, то есть так, чтобы буквы стали крупнее, а ширина страницы и размер элементов оставался прежним. У вас такого желания не возникало? А ваши собственные сайты могут так?
Но насчет дизайна для слабовидящих — я себя к таковым не причисляю. Однако периодически очень хочется на экране смартфона увеличить шрифт, не приближая страницу, то есть так, чтобы буквы стали крупнее, а ширина страницы и размер элементов оставался прежним. У вас такого желания не возникало? А ваши собственные сайты могут так?
А как вы собираетесь в мобильном браузере увеличивать шрифт, не увеличивая всего остального?
Если в браузере есть для этого специальная настройка, то браузер нормально увеличит и пиксельные шрифты, ничего сложного тут нет. По крайней мере, старушка Opera Mini прекрасно с этим справлялась на любых сайтах.
А если в браузере специальной настройки нет, то о чем вообще речь?
Если в браузере есть для этого специальная настройка, то браузер нормально увеличит и пиксельные шрифты, ничего сложного тут нет. По крайней мере, старушка Opera Mini прекрасно с этим справлялась на любых сайтах.
А если в браузере специальной настройки нет, то о чем вообще речь?
Честно говоря, я хочу, чтобы обычный pinch zoom на сайте увеличивал шрифт, а не создавал чёртовы полосы прокрутки. Можно такой сайт сделать?
Потому что мне, на самом деле, не нужен zoom, при котором расползается вся страница. Я просто хочу покрупнее почитать текст.
В идеале, pinch zoom на тексте должен увеличивать шрифт, а на картинке — увеличивать картинку. Но это, видимо, должно быть поддержано браузером…
Потому что мне, на самом деле, не нужен zoom, при котором расползается вся страница. Я просто хочу покрупнее почитать текст.
В идеале, pinch zoom на тексте должен увеличивать шрифт, а на картинке — увеличивать картинку. Но это, видимо, должно быть поддержано браузером…
Мне очень нравится «деревянный» GitHub, нигде ничего не ползет и все очень предсказуемо. Мне не приходит в голову пользоваться им на телефоне.
К вопросу о пикселах. Я хочу контролировать то, как моя работа выглядит на всех устройствах. Если у проекта есть достаточный бюджет, то хорошо сверстанный адаптивный сайт будет выглядеть на всех мобильных устройствах одинаково, хорошо, читабельно, в соответствии с дизайном и предсказуемо. Кстати, мне очень не нравится, когда сайты неограниченно тянутся на весь мой шикарный 21:9 дисплей. И когда жирные заголовки, которые рассчитаны на одну строку вдруг перескакивают на вторую. Или пункты инлайнового меню вдруг отображаются в две строки. Да, мне не хочется увеличивать шрифт на моем смартфоне — если сайт абсолютно не рассчитан под мобильные устройства, то его никакие относительные величины не спасут. Зато они помогут ему выглядеть как говно.
P.S. Пример — На всех разрешениях кегль контента один и тот же, проблем с чтением нет. Использованы пикселы, соответсвие макетам до пиксела. Еще раз — зачем нужны относительные величины? Чтобы сверстанный на коленке сайт можно было читать на телефоне с дисплеем 320x240?
К вопросу о пикселах. Я хочу контролировать то, как моя работа выглядит на всех устройствах. Если у проекта есть достаточный бюджет, то хорошо сверстанный адаптивный сайт будет выглядеть на всех мобильных устройствах одинаково, хорошо, читабельно, в соответствии с дизайном и предсказуемо. Кстати, мне очень не нравится, когда сайты неограниченно тянутся на весь мой шикарный 21:9 дисплей. И когда жирные заголовки, которые рассчитаны на одну строку вдруг перескакивают на вторую. Или пункты инлайнового меню вдруг отображаются в две строки. Да, мне не хочется увеличивать шрифт на моем смартфоне — если сайт абсолютно не рассчитан под мобильные устройства, то его никакие относительные величины не спасут. Зато они помогут ему выглядеть как говно.
P.S. Пример — На всех разрешениях кегль контента один и тот же, проблем с чтением нет. Использованы пикселы, соответсвие макетам до пиксела. Еще раз — зачем нужны относительные величины? Чтобы сверстанный на коленке сайт можно было читать на телефоне с дисплеем 320x240?
Размер экрана моего телефона — 5.3 дюйма. Это — первый мой личный смартфон. Купил, чтобы иметь 2 в 1 — и телефон, и планшет. И устройство бы прекрасно справилось с задачей, но пользуясь им, я невольно почти все сайты в интернете разделил на две категории:
1. Сайты типа GitHub, интерфейс которых, чтобы просто прочитать текст, нужно увеличивать настолько, что без панорамирования в процессе чтения — никуда. Очень неудобно. Потому что они «деревянные».
2. Сайты, которые считают себя мобильными — очень мало функционала, очень крупные шрифты, всё рассчитано на 3 дюйма в диагонали.
Я привел вам в пример этот мобильник не чтобы попонтоваться (а он действительно дорогой). Просто он нестандартный. Больше телефона, но меньше планшета. Поэтому он — идеален для проверки качества вёрстки.
Сделать сайт, который запросит разрешение экрана 1280 пикселей в ширину и нарисует себя в них правильно — не фокус. Интересно сделать сайт, который будет удобен и красив на любом экране.
Пример вы привели неплохой. Но пример frameless, приведенный автором статьи, мне нравится больше.
1. Сайты типа GitHub, интерфейс которых, чтобы просто прочитать текст, нужно увеличивать настолько, что без панорамирования в процессе чтения — никуда. Очень неудобно. Потому что они «деревянные».
2. Сайты, которые считают себя мобильными — очень мало функционала, очень крупные шрифты, всё рассчитано на 3 дюйма в диагонали.
Я привел вам в пример этот мобильник не чтобы попонтоваться (а он действительно дорогой). Просто он нестандартный. Больше телефона, но меньше планшета. Поэтому он — идеален для проверки качества вёрстки.
Сделать сайт, который запросит разрешение экрана 1280 пикселей в ширину и нарисует себя в них правильно — не фокус. Интересно сделать сайт, который будет удобен и красив на любом экране.
Пример вы привели неплохой. Но пример frameless, приведенный автором статьи, мне нравится больше.
Как можно вообще обсуждать «em» когда уже сто лет в обед как существуют «rem», то же самое, только не нужно всё время ходить с калькулятором.
Мне, когда я знакомился с адаптивной версткой, пришла идея, что после введения дисплеев высокой четкости пикселом в верстке должна называться виртуальная точка, минимально различимая человеческим глазом. А устройство (в зависимости от размеров экрана, предполагаемого расстояния до глаз) и пользователь, настраивая его, пусть сами решают, какое у него разрешение в таких виртуальных пикселах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Слово в защиту пиксельных значений media queries