Комментарии 26
какая же все таки свистопляска…
А ведь казалось — только заставили МС отказаться от своих свистоперделок в шестом осле, стандартны собрались повсюду. Браузеров — море. Практически все они одинаково отображают сайты (Кроме Оперы, она как всегда — сама себе дива). Вот оно — золотое время программирования в вэбе…
Но на горизонте собираются грозные W3Cтучи. Кажется со всеми этими примочками и свистоперделками…
Но на горизонте собираются грозные W3Cтучи. Кажется со всеми этими примочками и свистоперделками…
Порой мне кажется, что люди, которые говорят, что в опере что-то не так отображается, настолько профаны своего дела, что дальше уж не куда. А если вы далёки от этой темы, тогда зачем цитировать мысли другого профана? Извините.
А может это просто не их дело, хотя и не далеки? Мне вот приходится иногда верстать и чисто субъективно заметил, что чаще всего проблемы возникают с Оперой. То есть я пишу код, в Фоксе и Хроме он обычно выглядит ожидаемо, а в Опере (последняя версия из официальных репов), которую я запускаю для очистки совести — нет.
Ключевые слова «иногда верстать». За 4 года работы в коллективе, видал какие прогеры «творят структуры» не совместимые с жизнью, потом просят что-то подправить, открываешь фаербаг и диву даёшься — «как, какого ёжика оно вообще хоть как-то отображается». С опытом вырабатывается набор структур, которые максимально оптимальны и кроссбраузерны безо всяких хаков. Ради совести проверять остаётся в IE7, там бывают приключения с двойными маржинами. Так что тут дело в поведении браузера к неправильным структурам, и сложно сказать, какой из них прав, и в случае с фоксом\хромов — кто на кого дро... у кого копирует поведение.
Ради фана. У фаерфокса, порой line-height центрирует текст со смещением на 1 пиксель вниз.
Ради фана. У фаерфокса, порой line-height центрирует текст со смещением на 1 пиксель вниз.
НЛО прилетело и опубликовало эту надпись здесь
Ура! Скоро не нужно будет писать костыли для Хрома, и он будет работать так же радужно, как и IE.
Для тех, кто уже потянулся к минусу — это шутка ;-)
Но на самом деле, это отлично. Когда пишешь интерфейсы, завязанные на размер окна: слайдовые панели мониторинга, мобильные веб-сайты, — очень важно быть уверенным, что элемент, рассчитанный костылем на JS будет выглядеть одинаково везде, и не придется плодить несколько view-ов под каждое устройство.
Для тех, кто уже потянулся к минусу — это шутка ;-)
Но на самом деле, это отлично. Когда пишешь интерфейсы, завязанные на размер окна: слайдовые панели мониторинга, мобильные веб-сайты, — очень важно быть уверенным, что элемент, рассчитанный костылем на JS будет выглядеть одинаково везде, и не придется плодить несколько view-ов под каждое устройство.
абсолютно не понимаю ценности этих нововведений для мобильной разработки :( на мобильниках часто меняется размер окна браузера? если нет, то чем это лучше процентов, можно какой-нибудь юзкейс?
Окей:
У Вас в руках три телефона с 480х640, 240х320 и какой-нибудь Моторола с 1200х1600 разрешением.
Я хочу вывести три графика на экран так, чтобы каждый занимал ровно 1 экран. Или, например, график на экран, а ниже рассчеты и математические выкладки.
В этом случае я графику дам 100vh, например, и не буду ставить костылей, которые будут пытаться высчитать высоту экрана, множить на zoom и делать прочие гадости.
У Вас в руках три телефона с 480х640, 240х320 и какой-нибудь Моторола с 1200х1600 разрешением.
Я хочу вывести три графика на экран так, чтобы каждый занимал ровно 1 экран. Или, например, график на экран, а ниже рассчеты и математические выкладки.
В этом случае я графику дам 100vh, например, и не буду ставить костылей, которые будут пытаться высчитать высоту экрана, множить на zoom и делать прочие гадости.
При изменении размеров окна браузера размеры блочных элементов, указанные в vh, vw или vmin, меняются в реальном времени, а размеры шрифта — только после перерисовки
Что это значит на практике?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В Chrome Canary заработали новые единицы измерения CSS — vh, vw и vmin