Когда мы верстаем новые фичи, либо фиксим баги в небольшом проекте, нет проблем проверить, не поломали ли мы что-то работающее. Для этого достаточно просто его прокликать. Но так бывает не всегда: наш текущий проект насчитывает около 200 уникальных страниц и мы столкнулись с проблемой автоматизации регрессионного тестирования вёрстки. И если у программистов всё всем давно известно, методы тривиальны, да и ПО соответствующее написано, то нам, front end разработчикам, приходится ломать голову. Но мысли некоторые есть.

В контексте этого документа, я буду условно разделять все ошибки вёрстки на ошибки раскладки (связаные с позицией блока в документе) и оформления (как то цвет текста, фона и др.) Далее мы будем рассматривать ошибки раскладки.

Из-за чего весь сыр-бор

При вёрстке мы используем подход вроде Object Oriented CSS. Таким образом, наша страница состоит из блоков, блоки могут быть как простые, не содержащие других блоков, так и составные, имеющие внутри себя простые блоки. Мы сделали свой код максимально некаскадным (за исключением некоторых наследуемых значений, вроде цвета ссылки, текста и шрифта), и, казалось бы, если мы аккуратно делаем девтест того самого блока, который подвергается изменениям, сломаться ничего не должно. Как бы ни так! Потому что:

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


Фрагмент результата валидации example.com

Вчера пол дня потратил на подробное изучение LESS и его отличие от используемых нами SASS/SCSS.

Синтаксис SASS мне импонирует больше чем SCSS за его краткость. Но большая вложенность стилей в SASS может быстро ликвидировать все преимущества его краткости. В любом случае разницу между SASS и SCSS не принципиальна. LESS оказался ближе к SCSS чем к SASS. И, в общем, это тоже самое. Отличий не много, но парочка из них принципиально меняют расстановку сил.

	Иметь представление о верстке и проблемах кроссбраузерного отображения его макета?
	Нарезать графику для верстки и подготавливать ее для веба?
	Уметь сверстать свой макет сам?

Проголосовал 631 человек. Воздержалось 142 человека.

Hej, habr — приветствуем вас на шведском! В кризисный 2009 год появилось немного свободного времени, чем мы решили воспользоваться, чтобы «сделать красиво» для самих себя. Результатом стал интересный, на наш взгляд, пример подхода по созданию городского путеводителя, которым хотели бы поделиться — stockholmania.ru. Возможно, наши идеи пригодятся кому-нибудь в других проектах.

Почему Стокгольм? Это маниакально любимый город нашего дизайнера (который с регулярной периодичностью его посещает), а мне, как путешественнику, было интересно «пробудить аппетит». Наш веб-журнал — попытка уйти от привычного туристического подхода и показать Стокгольм под немного другим углом. И по форме, и по содержанию.

Crosspixel — небольшая программка на Javascript (около 15 Кб), которая показывает макет поверх вёрстки; как PixelPerfect для Firefox, только работает в любом браузере :)
Работает так:

1. скачайте crosspixel.js и подключите в ваш html-файл;
2. укажите путь до вашего файла-макета и его размеры;
3. в браузере появится панелька, которая позволяет показывать/скрывать макет (при показе меняет размер окна браузера под макет, при сокрытии восстанавливает прежний размер), менять его прозрачность.

Проект на GitHub

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