Comments 75
UFO just landed and posted this here
UFO just landed and posted this here
Думаю, мобильная война не завершится никогда. Реалии таковы, что через несколько лет посетителей с мобильных девайсов будет больше, чем с класического десктопа. И спектр этих устройств будет огромен.
UFO just landed and posted this here
Вы не поняли. Уже можно выходить в интернет с электронной книжки, навигатора в машине, домашнего кинотеатра и беговой дорожки:
Не будет никаких конкретных устройств под которые будут затачиваться веб-приложения. Будет бесчисленное количество девайсов с доступом в интернет. Нужно будет думать и делать универсальные сайты. Это как раз то, о чем эта статья.
Не будет никаких конкретных устройств под которые будут затачиваться веб-приложения. Будет бесчисленное количество девайсов с доступом в интернет. Нужно будет думать и делать универсальные сайты. Это как раз то, о чем эта статья.
UFO just landed and posted this here
Вы не правы. Будут разные типы параметров рендера. А вот вы пишите статью, а сами на живом проекте хоть раз meida queries применяли? Я да. На живом проекте это не работает. опредление юзер агента на сервере да, работает.
По пововду типов рендера, я имею ввиду что это либо стандартизируют либо нет.
Медикуери, я использую например когда у меня есть iPhone и iPadб А вот они это или Десктом с Хромом определяется на сервер, то есть есть 2 типа рендера, это Десктопы и Мобилы(именно Эпл)
По пововду типов рендера, я имею ввиду что это либо стандартизируют либо нет.
Медикуери, я использую например когда у меня есть iPhone и iPadб А вот они это или Десктом с Хромом определяется на сервер, то есть есть 2 типа рендера, это Десктопы и Мобилы(именно Эпл)
> Вы не правы. Будут разные типы параметров рендера.
> По пововду типов рендера, я имею ввиду что это либо стандартизируют либо нет.
О чем вы?
> А вот вы пишите статью, а сами на живом проекте хоть раз meida queries применяли?
Уже несколько месяцев, сделано порядка 5 проектов. Это работает.
> На живом проекте это не работает. опредление юзер агента на сервере да, работает.
Почему у вас не работает?
> Медикуери, я использую например когда у меня есть iPhone и iPadб А вот они это или Десктом с Хромом определяется на сервер, то есть есть 2 типа рендера, это Десктопы и Мобилы(именно Эпл)
О чем вы вообще говорите.
> По пововду типов рендера, я имею ввиду что это либо стандартизируют либо нет.
О чем вы?
> А вот вы пишите статью, а сами на живом проекте хоть раз meida queries применяли?
Уже несколько месяцев, сделано порядка 5 проектов. Это работает.
> На живом проекте это не работает. опредление юзер агента на сервере да, работает.
Почему у вас не работает?
> Медикуери, я использую например когда у меня есть iPhone и iPadб А вот они это или Десктом с Хромом определяется на сервер, то есть есть 2 типа рендера, это Десктопы и Мобилы(именно Эпл)
О чем вы вообще говорите.
«посредством» пишется слитно — поправьте, а то смешно смотрится, особенно когда «средством» выделено курсивом.
— правки по тексту лучше слать в личку.
— ваше замечание лучше отправить автору «Веб-дизайн. Каждому устройству свое представление». У меня дословная цитата. Но сейчас, пожалуй, исправлю.
Спасибо!
— ваше замечание лучше отправить автору «Веб-дизайн. Каждому устройству свое представление». У меня дословная цитата. Но сейчас, пожалуй, исправлю.
Спасибо!
— «В резинку» верстается легко только очень простые макеты. Чуть больше сложностей и появляются блоки фиксированной ширины. Верстка меню, смешанных зависимых блоков упирается в требования фиксированной ширины или высоты. И на изображения max-width или max-height тоже плохо влияют, особенно если требуется сохранять scale. В общем не все так гладко.
— если есть иллюстрации то сразу появляются проблемы. Если лого и можно разрулить чере background-image, то иллюстрации к статье приходиться либо убирать либо масштабировать в шаблонизаторе. Это убивает идею на корню.
В общем радужный тон примерно такой-же как и в случае html5, css3 и прочих радостей — как только сталкиваешься с реальными требованиями заказчика, то появляются костыли. А они сразу убивают любую выгоду от кросс-… девайс верстки и получается что выгоднее держать несколько макетов в которых все прозрачно, чем один, но с кучей скрытых хаков и костылей.
— если есть иллюстрации то сразу появляются проблемы. Если лого и можно разрулить чере background-image, то иллюстрации к статье приходиться либо убирать либо масштабировать в шаблонизаторе. Это убивает идею на корню.
В общем радужный тон примерно такой-же как и в случае html5, css3 и прочих радостей — как только сталкиваешься с реальными требованиями заказчика, то появляются костыли. А они сразу убивают любую выгоду от кросс-… девайс верстки и получается что выгоднее держать несколько макетов в которых все прозрачно, чем один, но с кучей скрытых хаков и костылей.
Да еще забыл что все эти многочисленные условия делают нормальный css просто огромным, что очень печалит клиента, когда он наблюдает несколько секунд загрузки стилей.
С другой стороны цсс можно пожать гзипом. А то что все стили лежат в одном файле дает только преимущества — уменьшение обращений к серверу. это есть гуд, учитывая что на мобильных устройствах количество таких обращений ограничено
Огромным не получается. CSS на выходе по количеству строк примерно такой же. Дополнительных строк мало. Тут дело в очередности подачи стилей и media queries.
таким же по количеству строк он не может быть. все что меняется — привносить обьем css. И чем заковырестей верстка — тем больше приходиться менять. в 1.5-2 раза больше — это норма, но бывает что c 20-30к может подняться до 100к а то и больше.
20-30 тысяч строк css? %) На хабре будет меньше.
Таким же, конечно, не будет, но у меня на выходе css получается примерно таким же. Где-то плюс 200-300 строчек. На мой взгляд, это пренебрежимо мало.
Таким же, конечно, не будет, но у меня на выходе css получается примерно таким же. Где-то плюс 200-300 строчек. На мой взгляд, это пренебрежимо мало.
kbytes :) строк там — пара тысяч плюс минус
Вероятнее всего вы не умеете верстать. Покажите ваш css и вам это докажу.
Скажите, а такая запись не избыточна ли?
div.aside div.news p.date span.month-year {..}
div.aside div.news p.date span.month-year {..}
«Преждевременная оптимизация — корень всех бед» :)
Проект не планировался как highload, это разметка интернет-магазина средней величины. Мы очень плотно поддерживаем этот интернет магазин, часто нужно залезать в css.
Поэтому я предпочел наглядность кода. Все равно gzip-размер вполне приемлим.
Проект не планировался как highload, это разметка интернет-магазина средней величины. Мы очень плотно поддерживаем этот интернет магазин, часто нужно залезать в css.
Поэтому я предпочел наглядность кода. Все равно gzip-размер вполне приемлим.
собственно, спрашиваю.
я стараюсь избегать таких конструкций, потому что в процессе разработки теги могут заменяться на другие, например p на div, span на strong и тп — по разным соображениям и не всегда, но такое бывает. и тогда требуются лишние телодвижения, чтобы переделать стили.
или же дата будет появляется не только в блоке div.news, но и например в гипотетическом div.comment, тогда избыточное наследование вставит палки в колеса
я стараюсь избегать таких конструкций, потому что в процессе разработки теги могут заменяться на другие, например p на div, span на strong и тп — по разным соображениям и не всегда, но такое бывает. и тогда требуются лишние телодвижения, чтобы переделать стили.
или же дата будет появляется не только в блоке div.news, но и например в гипотетическом div.comment, тогда избыточное наследование вставит палки в колеса
Здесь я погорячился, думал ваш css состоит из 20 — 30 тысяч строк, а там во много раз меньше. Сорри
* reset.css, print.css и helper.css (с часто используемыми классами для image replacement, clearfix и так далее) в этом проекте подключались отдельно.
> «В резинку» верстается легко только очень простые макеты. Чуть больше сложностей и появляются блоки фиксированной ширины.
Практикую responsive не очень долго, но мне такие не встречались. Можете привести пример?
> И на изображения max-width или max-height тоже плохо влияют.
Что понимается под плохо?
> если есть иллюстрации то сразу появляются проблемы. Если лого и можно разрулить чере background-image, то иллюстрации к статье приходиться либо убирать либо масштабировать в шаблонизаторе. Это убивает идею на корню.
Иллюстрации в статье резинятся с помощью img { max-width: 100% }, об этом есть в статье.
> В общем радужный тон примерно такой-же как и в случае html5, css3 и прочих радостей — как только сталкиваешься с реальными требованиями заказчика, то появляются костыли.
Уже больше года использую html5/css3. Все можно решить. Я бы даже сказал не использовать html5/css3 не имеет смысла.
Практикую responsive не очень долго, но мне такие не встречались. Можете привести пример?
> И на изображения max-width или max-height тоже плохо влияют.
Что понимается под плохо?
> если есть иллюстрации то сразу появляются проблемы. Если лого и можно разрулить чере background-image, то иллюстрации к статье приходиться либо убирать либо масштабировать в шаблонизаторе. Это убивает идею на корню.
Иллюстрации в статье резинятся с помощью img { max-width: 100% }, об этом есть в статье.
> В общем радужный тон примерно такой-же как и в случае html5, css3 и прочих радостей — как только сталкиваешься с реальными требованиями заказчика, то появляются костыли.
Уже больше года использую html5/css3. Все можно решить. Я бы даже сказал не использовать html5/css3 не имеет смысла.
Я собственно приводил примеры когда с резинкой проблемы.
изображения с max-width или max-height когда упираются в это ограничение начинают корежить соотношение сторон.
иллюстрации разные бывают — мне пришлось на одном сайте 4 разных размера поддерживать, потому что клиенту было важно иметь качество отображения и отсутствие искажений.
я тоже больше года пихаю везде doctype html, но полноценную html5 верстку пришлось отменить. css3 тоже не получается использовать в полную, а где получается — там сразу хаки вылазят.
изображения с max-width или max-height когда упираются в это ограничение начинают корежить соотношение сторон.
иллюстрации разные бывают — мне пришлось на одном сайте 4 разных размера поддерживать, потому что клиенту было важно иметь качество отображения и отсутствие искажений.
я тоже больше года пихаю везде doctype html, но полноценную html5 верстку пришлось отменить. css3 тоже не получается использовать в полную, а где получается — там сразу хаки вылазят.
Добавлю, что для мобильных устройств max-width или max-height — так себе решение. Потому что скорость мобильных соединений пока что так себе, плюс у некоторых считается траффик. И открывая на своем телефончике сайт, следует учитывать, что провайдеру будет пофик на то, что у тебя стоит max-width:100px, в то время, когда картинка на самом деле шириной в 1000px и загрузится в свой полный вес
Существует решение этой проблемы github.com/scottjehl/Responsive-Images
спасибо за ссылку, попробую
хорошее решение, но следует учитывать, что не все мобильные браузеры поддерживают js, или поддерживают криво
хорошее решение, но следует учитывать, что не все мобильные браузеры поддерживают js, или поддерживают криво
Вот они костыли во всей красе!
Ну не костыли, а «progressive enhancement». Теперь ясно, почему у вас с css3 не складывается :)
Сейчас мы живем в период перехода с одних стандартов на другие, каждый браузер поддерживает ту или иную технологию по-своему, поэтому без таких штук все сложней и сложней обходится :)
Например, вот набор библиотек, которые позволяют эмулировать разные вкусные, но не кроссбраузерные штуки
github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
приходится пользоваться ими все чаще
Например, вот набор библиотек, которые позволяют эмулировать разные вкусные, но не кроссбраузерные штуки
github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
приходится пользоваться ими все чаще
Еще стоит упомянуть плавающие блоки (товары к примеру), которые могут иметь разную высоту (из-за переносов текста / заголовка):
А если хочется, чтобы высота блоков в одной линии была одинакова? То есть, чтобы высота автоматически растягивалась с учетом самого высокого блока, как у ячеек в таблице?
UFO just landed and posted this here
Я полностью прочитал статью и сделал тест. Все, как в статье описано, отлично работает. Даже в ИЕ6. Но как сделать одинаковой высоту блоков я не увидел. Возможно это где-то зарыто в комментариях?
UFO just landed and posted this here
такой подход можно использовать для простых сайтов — контентных, визиток, блогов и тп. Даже не можно, а нужно.
Но если есть более-менее сложный функционал и динамика, и требуется поддержка мобильных устройств, то резиновости и media queries не хватит
Но если есть более-менее сложный функционал и динамика, и требуется поддержка мобильных устройств, то резиновости и media queries не хватит
> Но если есть более-менее сложный функционал и динамика, и требуется поддержка мобильных устройств, то резиновости и media queries не хватит
Почему?
Почему?
Потому что существует ряд принципиальных вещей, которые отличаются на десктопе/тв и на мобильных устройствах — от дизайна и юзабилити до технических моментов.
Если, к примеру, на сайте, который состоит из трех колонок и наполнен в основном текстом и картинками, будет достаточно выстроить эти колонки в один столбик, пожав пропорционально шрифт и изображения, то на каком-нибудь портале или сайте с хитрой функциональностью c кучей js это будет уже потрудней. И начнут вылазить костыли — то флешку нужно срочно переделывать на альтернативу из js/css3, то оказывается, что на мобильных девайсах position:fixed почти нигде не работает и тривиальная задача прибить футер к низу экрана становится реальной проблемой, которую без прикрутки iscroll особо не сделаешь. Если есть карусель на сайте, то ей тоже придется уделить кучу внимания, параллельно добавив тач-ивенты
ну и так далее
Если, к примеру, на сайте, который состоит из трех колонок и наполнен в основном текстом и картинками, будет достаточно выстроить эти колонки в один столбик, пожав пропорционально шрифт и изображения, то на каком-нибудь портале или сайте с хитрой функциональностью c кучей js это будет уже потрудней. И начнут вылазить костыли — то флешку нужно срочно переделывать на альтернативу из js/css3, то оказывается, что на мобильных девайсах position:fixed почти нигде не работает и тривиальная задача прибить футер к низу экрана становится реальной проблемой, которую без прикрутки iscroll особо не сделаешь. Если есть карусель на сайте, то ей тоже придется уделить кучу внимания, параллельно добавив тач-ивенты
ну и так далее
А как на alistapart.com сделано, что блоки при определенной ширине браузера исчезают?
В свое время привык к cssgrid.net. И резиновый фреймворк (достаточно убрать
max-width), и мобильность, описанная в статье.
Статья излишне восторженная.
Во-первых проблемы будут со сложными макетами.
Во-вторых автор забывает о мобильных броузерах с ограниченной поддержкой CSS, которые отнюдь не на ура, воспримут подобную верстку.
В-третьих вышеуказанные сайты на мобильные броузерах с разрешением 320х240 и меньше, даже если отобразятся, то с огромной полосой прокрутки. Что никак не юзабельно.
Во-первых проблемы будут со сложными макетами.
Во-вторых автор забывает о мобильных броузерах с ограниченной поддержкой CSS, которые отнюдь не на ура, воспримут подобную верстку.
В-третьих вышеуказанные сайты на мобильные броузерах с разрешением 320х240 и меньше, даже если отобразятся, то с огромной полосой прокрутки. Что никак не юзабельно.
> Во-первых проблемы будут со сложными макетами.
Все можно решить.
> Во-вторых автор забывает о мобильных броузерах с ограниченной поддержкой CSS, которые отнюдь не на ура, воспримут подобную верстку.
Решение проблемы — Mobile first. Сначала отдается простейшая разметка. Потом с помощью свойств, которые простые браузеры не видет, отдается остальная верстка. Мобильные браузеры не видят то, чего не могут переварить. Об этом есть в статье.
> В-третьих вышеуказанные сайты на мобильные броузерах с разрешением 320х240 и меньше, даже если отобразятся, то с огромной полосой прокрутки.
Это проблема конкретно указанных сайтов. Я своими руками сделал несколько макетов в недавнем времени, где прокрутки на мобильных нет.
Все можно решить.
> Во-вторых автор забывает о мобильных броузерах с ограниченной поддержкой CSS, которые отнюдь не на ура, воспримут подобную верстку.
Решение проблемы — Mobile first. Сначала отдается простейшая разметка. Потом с помощью свойств, которые простые браузеры не видет, отдается остальная верстка. Мобильные браузеры не видят то, чего не могут переварить. Об этом есть в статье.
> В-третьих вышеуказанные сайты на мобильные броузерах с разрешением 320х240 и меньше, даже если отобразятся, то с огромной полосой прокрутки.
Это проблема конкретно указанных сайтов. Я своими руками сделал несколько макетов в недавнем времени, где прокрутки на мобильных нет.
Помните игру, уместившуюся внутри фавикона?
habrahabr.ru/blogs/subconsciousness/29316/
Так вот, хороший мультиплатформенный сайт должен оставаться юзабельным, даже если кто-то откроет его из «браузера», расположившегося, как эта игрушка, в значке 16х16. Не говоря уже о больших и тяжеловесных иконках для всяких там Android, iOS, Windows 8 и т. д. с разрешением в космические сотни пикселей:)
habrahabr.ru/blogs/subconsciousness/29316/
Так вот, хороший мультиплатформенный сайт должен оставаться юзабельным, даже если кто-то откроет его из «браузера», расположившегося, как эта игрушка, в значке 16х16. Не говоря уже о больших и тяжеловесных иконках для всяких там Android, iOS, Windows 8 и т. д. с разрешением в космические сотни пикселей:)
UFO just landed and posted this here
UFO just landed and posted this here
Кстати, если активно пользуетесь media queries, рекомендую такую технику
Во время перестройки блоков на разных экранах применяется css transitions, и объекты плавно летят на свои места или обретают новый размер :)
Выглядит эффектнее стандартных резких перестроек дизайна и добавляет пару плюсов в карму, когда клиент замечает фичу :)
Во время перестройки блоков на разных экранах применяется css transitions, и объекты плавно летят на свои места или обретают новый размер :)
Выглядит эффектнее стандартных резких перестроек дизайна и добавляет пару плюсов в карму, когда клиент замечает фичу :)
Интересные у парня часы на картинке. Никто не подскажет: что это за девайс?
К сожалению вы не очень внимательно прочли мою статью на которую вы ссылаетесь.
Проблема, которую я описывал, звучит не только как разные размеры в пикселях экранов. Она намного глубже. Это и различные физические размеры и разрешения дисплеев, сравните планшет 10'' 800х600 точек и коммуникатор 3'' 640х480. на втором устройстве даже 13px шрифт вы не прочтете, больно мелко будет. Также разные принципы управления на этих устройствах. Сравните точь- и мультиточ-скрины, а также управляемые пультом телевизоры, и добавьте электронные книги, тогда, возможно, вы поймете суть проблемы.
А резиновая и адаптивная верстка для браузеров это не проблема. Тут я с вами полностью согласен.
Проблема, которую я описывал, звучит не только как разные размеры в пикселях экранов. Она намного глубже. Это и различные физические размеры и разрешения дисплеев, сравните планшет 10'' 800х600 точек и коммуникатор 3'' 640х480. на втором устройстве даже 13px шрифт вы не прочтете, больно мелко будет. Также разные принципы управления на этих устройствах. Сравните точь- и мультиточ-скрины, а также управляемые пультом телевизоры, и добавьте электронные книги, тогда, возможно, вы поймете суть проблемы.
А резиновая и адаптивная верстка для браузеров это не проблема. Тут я с вами полностью согласен.
Проблема, которую я описывал, звучит не только как разные размеры в пикселях экранов.
Я все понимаю :) Смотрите — habrahabr.ru/blogs/webdev/125247/?reply_to=4123988#comment_4121005
Сравните планшет 10'' 800х600 точек и коммуникатор 3'' 640х480. на втором устройстве даже 13px шрифт вы не прочтете, больно мелко будет.
Все верно, поэтому шрифт нужно задавать либо сразу адекватного размера, либо в относительных (% или em), а не абсолютных единицах (px).
Сравните точь- и мультиточ-скрины, а также управляемые пультом телевизоры, и добавьте электронные книги, тогда, возможно, вы поймете суть проблемы.
Касательно touch-девайсов. Дизайн сайтов для небольших разрешений учитывает необходимость управления пальцем. То есть минимальный размер кликабельного элемента становится равен площади нажатия пальцем и так далее.
Электронные книги. У меня Kindle. Разработанный мною responsive-сайт работает на нем отлично. Единственная разница — сайт черно-белый.
Я все понимаю :) Смотрите — habrahabr.ru/blogs/webdev/125247/?reply_to=4123988#comment_4121005
Сравните планшет 10'' 800х600 точек и коммуникатор 3'' 640х480. на втором устройстве даже 13px шрифт вы не прочтете, больно мелко будет.
Все верно, поэтому шрифт нужно задавать либо сразу адекватного размера, либо в относительных (% или em), а не абсолютных единицах (px).
Сравните точь- и мультиточ-скрины, а также управляемые пультом телевизоры, и добавьте электронные книги, тогда, возможно, вы поймете суть проблемы.
Касательно touch-девайсов. Дизайн сайтов для небольших разрешений учитывает необходимость управления пальцем. То есть минимальный размер кликабельного элемента становится равен площади нажатия пальцем и так далее.
Электронные книги. У меня Kindle. Разработанный мною responsive-сайт работает на нем отлично. Единственная разница — сайт черно-белый.
Идеалисты. Вы выкидываете понятие таргетинг из проблемы. Представьте, чтоЮ, скажем, БМВ хочет создать автомобиль который охватовал бы все ниши: чтобы был спортивный и яркий, но представительный, чтобы с места разгонялся до 100 км/ч, но был экономный, чтобы вместительный, но маленький…
Добавление каждого сектора продаж увеличивает цену проекта (сайта) геометрически. Если заказ пришел, от конторы «Рога и копыта» которая продает веники, на сайт-визитку, то ей важен только браузерный рынок. Компания покрупней захочет еще поддержку мобильников. Совсем титаны заходят поддерживать все. Но крупные компании и понимают издержки подобной поддержки и готовы платить большие суммы. И вот тут уже вам просто выбор инструмента дают, как вы хотите это делать: держать три-четыре версии сайта, или делать одну, но для всех.
У меня такое впечатление что большинство комментирующих поделились на два лагеря:
1) «О боже, какая потрясающая техника, я смогу увеличить кол-во посетителей, и это ничего не будет мне стоить»
2) «О боже, если эта техника разойдется в массы и ее увидет мой придурок начальник, то я сдохну на работе.»
Все выше сказанное, на правах собственного опыта.
Добавление каждого сектора продаж увеличивает цену проекта (сайта) геометрически. Если заказ пришел, от конторы «Рога и копыта» которая продает веники, на сайт-визитку, то ей важен только браузерный рынок. Компания покрупней захочет еще поддержку мобильников. Совсем титаны заходят поддерживать все. Но крупные компании и понимают издержки подобной поддержки и готовы платить большие суммы. И вот тут уже вам просто выбор инструмента дают, как вы хотите это делать: держать три-четыре версии сайта, или делать одну, но для всех.
У меня такое впечатление что большинство комментирующих поделились на два лагеря:
1) «О боже, какая потрясающая техника, я смогу увеличить кол-во посетителей, и это ничего не будет мне стоить»
2) «О боже, если эта техника разойдется в массы и ее увидет мой придурок начальник, то я сдохну на работе.»
Все выше сказанное, на правах собственного опыта.
Вы не поняли. Делать сайт под «что-то» уже мертвая стратегия. Вы не можете предугадать с чего посетитель через полгода зайдет на сайт.
Может быть, это будет новый форм-фактор с разрешением, который не будет учитан в вашем дизайне «под мобильники» или «под десктоп».
С приходом планшетов границы еще более размыты. Пора делать сайты в принципе работающие на всем спектре разрешений.
Если это не интересует заказчика, это проблемы заказчика. Всегда найдутся более дальновидные руководители, чей бизнес и выживет в конкурентной борьбе.
Может быть, это будет новый форм-фактор с разрешением, который не будет учитан в вашем дизайне «под мобильники» или «под десктоп».
С приходом планшетов границы еще более размыты. Пора делать сайты в принципе работающие на всем спектре разрешений.
Если это не интересует заказчика, это проблемы заказчика. Всегда найдутся более дальновидные руководители, чей бизнес и выживет в конкурентной борьбе.
адаптивный дизайн — это замечательно, конечно. вот только не понял если я хочу поставить на background тега body какую-то картинку как мне это сделать-то так чтобы она так же хорошо выглядела при любом разрешении? надо использовать векторную графику я так понимаю? или есть какой-то еще выход?
Sign up to leave a comment.
Как сделать один сайт для всех устройств (Responsive Web Design)