Comments 16
CSS-код в иллюстрации поста — это «как получить плохую вёрстку».
nav li — путь к проблемному каскаду, а от каскада надо стараться уходить.
nav li — путь к проблемному каскаду, а от каскада надо стараться уходить.
Мда, начиная с «W3C Validator», каждый следующий совет всё хуже и хуже. Учтите, что эту статью скорее всего будут читать люди не разбирающиеся в вёрстке — вы ведь именно для них писали советы?
W3C Validator
Если вы не знаете, что это такое — не трогайте. Проверяйте вёрстку в браузерах. Всё выглядит хорошо — значит всё хорошо.
Любой более-менее средний сайт содержит в стилях кучу префиксов + тянет за собой стили для сторонних компонентов. Как минимум, много предупреждений в валидаторе вам обеспечено. И зачем предъявлять это верстальщику?
JavaScript
В целом верно, но опять же смущает совет требовать обоснования применения JS. Если вы сами не способны понять обосновано или нет применение JS в конкретном случае, то какой смысл спрашивать об этом исполнителя? Разве что для самообразования :)
Пиксель в пиксель
Ошибаются все. И больше всего ошибаются те, кто считает, что вёрстка «пиксель в пиксель» возможна.
С учётом того, что большинство макетов рисуются «обычными» дизайнерами, хорошая вёрстка — это не тогда когда результат выглядит «точно как в макете», а когда результат выглядит максимально хорошо:
— вне зависимости от браузера
— при разном количестве контента
W3C Validator
Если вы не знаете, что это такое — не трогайте. Проверяйте вёрстку в браузерах. Всё выглядит хорошо — значит всё хорошо.
Любой более-менее средний сайт содержит в стилях кучу префиксов + тянет за собой стили для сторонних компонентов. Как минимум, много предупреждений в валидаторе вам обеспечено. И зачем предъявлять это верстальщику?
JavaScript
В целом верно, но опять же смущает совет требовать обоснования применения JS. Если вы сами не способны понять обосновано или нет применение JS в конкретном случае, то какой смысл спрашивать об этом исполнителя? Разве что для самообразования :)
Пиксель в пиксель
Ошибаются все. И больше всего ошибаются те, кто считает, что вёрстка «пиксель в пиксель» возможна.
С учётом того, что большинство макетов рисуются «обычными» дизайнерами, хорошая вёрстка — это не тогда когда результат выглядит «точно как в макете», а когда результат выглядит максимально хорошо:
— вне зависимости от браузера
— при разном количестве контента
Согласен с вами полностью. В статье описаны скорее вредные советы, чем полезные.
Вот в довесок мои советы:
стоит познакомить дизайнера с понятием «сетка» (PDF на тему — www.subtraction.com/pics/0703/grids_are_good.pdf)
стоит познакомить дизайнера с понятием «вертикальный ритм» (туториал на тему — webdesign.tutsplus.com/articles/improving-layout-with-vertical-rhythm--webdesign-14070)
стоит рассказать дизайнеру какие элементы на странице трудно (невозможно) стилизовать (формы, скроллы, алерты)
как показывает практика далеко не все дизайнеры знакомы с понятием «адаптивная верстка» и особенностями дизайна адаптивных макетов
Вот в довесок мои советы:
стоит познакомить дизайнера с понятием «сетка» (PDF на тему — www.subtraction.com/pics/0703/grids_are_good.pdf)
стоит познакомить дизайнера с понятием «вертикальный ритм» (туториал на тему — webdesign.tutsplus.com/articles/improving-layout-with-vertical-rhythm--webdesign-14070)
стоит рассказать дизайнеру какие элементы на странице трудно (невозможно) стилизовать (формы, скроллы, алерты)
как показывает практика далеко не все дизайнеры знакомы с понятием «адаптивная верстка» и особенностями дизайна адаптивных макетов
Согласен, что советы неахти. А точнее некоторые из них даже вредны.
W3C Validator
Лично мое мнение и опыт показывают, что даже верстальщику среднего уровня по силам сделать верстку которая 100% валидна. И этого нужно добиваться. А вот когда верстку натянут на код — там уже могут появиться невалидные места и вот тут уже нужно начинать прикрывать глаза (например & в ссылках).
«Обоснованный» JavaScript & Пиксель в пиксель
Часто по своей работе вижу такие требования. И пишут их в основном после прочтения таких топиков.
Но задайте себе вопрос: как вы сможете отличить обоснованный JS от необоснованного? Вы будете разговаривать с верстальщиком о вещах в которых он компетентен, а Вы — нет. Он вам докажет что угодно, даже не сомневайтесь.
PixelPerfect — утопия. Можно убить половину времени проекта на это, но зачем? Вам шашечки или ехать? Прагматики выбирают Progressive Enhancement, а с идеалистами и фанатиками я никому не пожелаю работать.
W3C Validator
Лично мое мнение и опыт показывают, что даже верстальщику среднего уровня по силам сделать верстку которая 100% валидна. И этого нужно добиваться. А вот когда верстку натянут на код — там уже могут появиться невалидные места и вот тут уже нужно начинать прикрывать глаза (например & в ссылках).
«Обоснованный» JavaScript & Пиксель в пиксель
Часто по своей работе вижу такие требования. И пишут их в основном после прочтения таких топиков.
Но задайте себе вопрос: как вы сможете отличить обоснованный JS от необоснованного? Вы будете разговаривать с верстальщиком о вещах в которых он компетентен, а Вы — нет. Он вам докажет что угодно, даже не сомневайтесь.
PixelPerfect — утопия. Можно убить половину времени проекта на это, но зачем? Вам шашечки или ехать? Прагматики выбирают Progressive Enhancement, а с идеалистами и фанатиками я никому не пожелаю работать.
Эх, ну сколько можно говорить о валидаторе, только тратите время и заказчика и верстальщика.
JavaScript, ну вот скажите, как заказчик отличит анимацию сделанную на js от анимации сделанной на css? Он даже не будет знать куда смотреть.
Пиксель в пиксель, тоже требование сомнительное. Как показывает практика дизайнеры сами все время забывают свои же гайдлайны и у них в макетах скачут отступы, размеры шрифта и т.п. Хороший верстальщик подправит такие огрехи незаметно, но при проверке пиксель в пиксель на него еще и наедут! Или скажем сравнить макет сделанный под виндой с сайтом на маке? Там разная толщина шрифтов, пиксель в пиксель вообще невозможен.
JavaScript, ну вот скажите, как заказчик отличит анимацию сделанную на js от анимации сделанной на css? Он даже не будет знать куда смотреть.
Пиксель в пиксель, тоже требование сомнительное. Как показывает практика дизайнеры сами все время забывают свои же гайдлайны и у них в макетах скачут отступы, размеры шрифта и т.п. Хороший верстальщик подправит такие огрехи незаметно, но при проверке пиксель в пиксель на него еще и наедут! Или скажем сравнить макет сделанный под виндой с сайтом на маке? Там разная толщина шрифтов, пиксель в пиксель вообще невозможен.
К сожалению, не моуг поставить плюс, но выразить свое согласие очень хочется. Pixel-perfect действительно невозможен из-за различных типов сглаживаний шрифтов, из-за того что дизайнер часто по своей же сетке направляющих не рисует пиксель-в-пиксель и т.п. Из-за советов «проверяйте через картинку с прозрачностью» и появляется всякое «подвиньте мне логотип на 1 пиксель влево, а менюшку на 2 пикселя вниз», будто это сильно что-то меняет. Я при верстке зачастую немного отхожу от макета именно по причине исправления неточностей за дизайнерами, пиксель перфект в таких ситуациях означает лажу.
JavaScript, ну вот скажите, как заказчик отличит анимацию сделанную на js от анимации сделанной на css? Он даже не будет знать куда смотреть.
Тут не согласен. У меня уже очень давно установлен NoScript и за много лет сформирован белый список сайтов. И так раздражает, когда даже в самые простые вещи, пытаются запихнуть JS.
Клиент который хочет pixel perfect априори никогда не получит хорошую вёрстку.
Если вы без понятия для чего это нужно, то попросите поддерживать Chrome, Firefox, Opera, Explorer от 8 версии.
Я бы отметил, что поддерживать необходимо современные версии браузеров, опираясь на данные вашей аналитики (GA и Я.Метрика в помощь). Так, например, на портале для геймеров поддержка IE8 будет не обоснована. А вот для корпоративных сайтов банковского сектора и вообще финансового сектора — здесь без IE8 и даже частичный поддержки IE7 не обойтись. Более того, нужно избегать флэша и очень аккуратно использовать JS. Это я вам говорю как человек, который работал в разных финансовых организациях. Сейчас я по своим проектам вижу долю IE8 в 50-55% и еще 1,5-2% IE7.
Использовать наложение превью на макет для проверки пиксель в пиксель — это перебор, тут спору нет. Но делать это нужно в любом случае для проверки правильности расположения блоков, кнопок и прочих элементов. Текст может (и всегда будет) отличаться, а вот остальные элементы не должны. Исключение — если дизайнер сам их явно криво расположил (но за такие макеты вообще браться не рекомендую).
Sign up to leave a comment.
Как получить хорошую верстку от верстальщика