Блог NunDesign

Иногда верстальщикам приходится отлавливать самые занимательные баги. К примеру на один из сервисов мы довольно старательно сделали весь базовый функционал, дизайн, вёрстку, вроде всё честно. Сделали языковые версии сервиса (я верстала под английскую и чуток стерелизовала после под прочие - французскую, немецкую, итальянскую и испанскую). Дальше канадские программеры сказали, что “остальные мелочи мы уж тут сами”. Сегодня звонят, мол глюк у нас тут, да такой, что уже крышу сносит. В одном из блоков (простенько отвёрстанный блок, чуток только декорированный, с перечнем причин, почему могла не пройти транзакция) на английской версии (той, которую я верстала) всё нормально, а остальные версии - там типа какие-то пробелы в середине блока добавляются. Причём смотрят ресурсные файлы - вёрстка одинаковая, равная правильной английской. Смотрят source code документа в браузере - там всё чисто, вёрстка без ошибок, нигде не могут найти баг. Т.е. глюк есть, а бага не видно.

Я тоже не сразу нашла. Честно говоря танцы с бубном пришлось исполнить. Знаете, что оказалось? Их мудрый верстальщик, или кто-то там, кто правил ресурсные файлы, открывал xml на редактирование в каком-то (пока не знаю в каком) редакторе, который после себя оставил некоторое количество непечатных символов, не в смысле матерных, а в смысле не отображаемых. Они не обнаруживались простыми методами, они не показывались в исходном коде документа браузера, они не ловились даже если с клавиатуры по символам идти построчно. Совершенно случайно в M$ Studio в режиме редактирования полей ресурсов увидела странные квадратики. Почистила код, запустила проект ура, всё работает! Заодно обнаружила ещё несколько кривостей, уже не наших. Отписываю это всё канадскому PM`у:

Alex: так-перетак-разтак!!! Как ты смогла это вычислить?
Tatyana: гы. танцы с бубном
Alex: шаман, однако
Alex: Ты можешь все это кинуть мне в мыло? Подробненько, чтобы и дятлу было понятно. Пли-и-из
Tatyana: Счас, секунду. только я по русски напишу письмо
Alex: Да хоть на суахили. Мне все-равно туда нужно будет маты вставлять
Alex: Ну открой секрет, как же ты все-таки находишь такие баги, Таня
Tatyana: Я ковыряла долго. Потом, с возрастом приходит убеждение, что чудес не бывает
Alex: А-а-а-а, так вот в чем разница. Я-то все еще верю в чудеса…
Tatyana: Чудеса может и бывают, но логически предсказуемые!

Не так давно к посту “Два вопроса про качественный в кавычках CSS” получила много полезных развёрнутых комментариев, спасибо всем. Напомню, что один из вопросов был о том, что если на странице есть кнопка-ссылка, к примеру, “Download”, то как правильно её реализовать: использовать конструкцию <a href=""><img src="" alt="Download" /></a>, где имидж в ссылке - красивая картинка для кнопки, или просто <a href=""></a>, где в описании класса фоном подгружать ту же красивую картинку? Правильно с точки зрения семантики, с точки зрения грамотной вёрстки и т.д. В комментариях были сторонники первого решения, были - второго, большей же частью писали о том, что без принципиальной разницы, по договорённости с главным менеджером. К примеру, заинтересовали такие критерии:

1. Если легко придумывается адекватный текст для alt, то нужно делать картинкой
2. картинки фоном в CSS — это крайняя мера, потому что “обнаруживать их в CSS - это не прозрачно”
3. когда стили отключены, кнопка должна отображаться как кнопка
4. представить, что все img на странице проиндексируются поисковиками и будут выдаваться в поиске по картинкам. Иногда помогает сориентироваться, где уместно использовать тег img /, а где - фончик в css.

На самом деле вопросов, связанных с логикой и семантикой вёрстки возникает много и не все они решаемы (или легко решаемы), где-то знаний не хватает, где-то хорошие тенденции рубятся “корпоративной политикой” или просто выбором технологий. Там же, в комментах к тому же посту несколько раз попросили дать ссылки на некоторые наши проекты, я уже как-то писала и ещё раз напишу: извиняйте, ребятки, не дам. Но задумалась о том, что вовсе не на всех наших проектах такое пристрастное требование верстать дивами, да ещё и обращать внимание на логику кода и семантические тонкости.

(more…)

Бывает так, что день, в том числе и рабочий, начинается вполне удачно, бывает же такое, что буквально первые шаги вхожнения в рабочий процесс ошарашивают. Вроде ничего такого не произошло, а картина мира как-то в дребезги разбивается просто. На этот раз какие-то неувязочки с нашим новым заотлантическим арт-директором. Получаю от ихнего руководства два письма. И сижу думаю, что бы эдакое в ответ написать, дабы и меня попустило, и ситуация прояснилась для обоих сторон. А с другой стороны - может, и правда это у меня пробелы в знаниях? Похоже, будет сегодня пара вопросов по “профессиональной” вёрстке. Пока в кавычках - но это потому, что я не совсем понимаю, что у нас просиходит.

Предыстория такая. Наши украинские дизайнеры (типа младшая группа) рисовала много эскизов “в туда”, часть из них проходила, и мы делали по этим эскизам небольшие сайты. При старом арт-директоре были, конечно, расстраивающие недопонимания, плохо была налажена обратная связь, переписка в основном состояла в том, что я ему писала “дайте же наконец хоть какие-то комментарии”, в мессенджере пинала, мол прочти письмо и ответь, получала ответ, что ASAP, и всё, дальше молчание. К вёрстке у нас каких-то конкретных требований не было, кроме как бы и так понятных - валидный HTML, валидный CSS, никаких табличных макетов (это, кстати, по поводу дискуссии про то, что лучше, это другие могут выбирать то или другое или даже дискутировать, а у нас, помимо идеологии и принципов, так было заявлено в ТЗ), по возможности текст делать текстом (ну, если уж совсем декоративные заголовки, то хидерами-подменками с длинными координатами).

Причём все эти месяцы я слышала (и получала известиями в мессенджере) информацию о том, что нам будут высланы какие-то технические требования к макетам, которые мы должны соблюдать. Я периодически напоминала, получала ответ о том, что “да-да, готовится”, а потом первого арт директора уволили и взяли второго, с которым мы общаемся уже скоро месяц как (третью неделю, вроде, или четвёртую). И всё по-новой: мы готовим вам документ с техническими требованиями к верстаемым сайтам, и этот документ будет выслан ASAP. Как в, разумные мои читатели, и сами понимаете, этот документ уважаемые наши заатлантические партнёры так и не прислали, и я даже сомневаюсь в том, что они его досочиняли, и вообще у них в голове есть какая-то типизированная схема, по которой эти требования можно составить.

Бр-р-р опять много букв на вступление, а теперь вопросы:
(more…)

И как я туда вообще выбралась? Иллюзии по поводу того, что на конференцию меня пошлют от компании, и компания же оплатит как конфу, так и проживание-прокормление, развеялись очень быстро. Может, оно и к лучшему. Напросилась в гости к девчушке, с которой когда-то вместе работали, и тут оказалось, что она тоже идёт на эту же конференцию, и, более того, её муж читает на конфе доклад (на второй день). Как тесен мир.

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

Мероприятие, как и было обещано, прошло в конференц залах (двух) Президент Отеля (публика периодически перетекала из одного зала в другой за интересными докладами), всё было так солидно и по взрослому. В холле бар и столы для кофебрейков. Вайфай работал стабильно, но с моего htc что-то куда-то писать было лениво. Зато появился повод лишний раз задуматься о том, что разработчики интерфейсов веб-сайтов, особенно всяких редакторских интерфейсов типа админки вёрдпресса, могли бы серьёзнее подойти к вопросу юзабельности и доступности блин этих самых интерфейсов для мобильных устройств.
Спешно перед поездкой, в самый день отъезда, купила мыльницу - выбор в пользу малых размеров, потому что возиться с любимым Canon`ом (который Canon EOS 400D Kit 18-55) тяжко, да и в условиях прогрессирующей лени бессмысленно. Но для мыльницы не взяла зарядное устройство для акка, и к вечеру первого дня она благополучно разрядилась, так что фотки будут, но позже и не очень много.

Долгожданные доклады о правильной вёрстке были отслушаны, всё понравилось, всё правильно, но чуда не произошло, ничего такого, чего бы я не знала или не использовала, никаких, гм., откровений, ессно, не прозвучало. С другой стороны, доклады по XSL оказались сложнее, чем мне понятно, будем догоняться реальной практикой на местечковых проектах.

UPD второй день: на следующий день то ли я адаптировалась, то ли список докладов (и докладчиков) сложился удачный, но второй день показался более плодотворным и ярким. Понравились доклады по интерфейсам новостийных сайтов, по методам тестирования юзабилити веб-интерфейсов, познакомилась и обменялась контактами с Геннадием Осипенко, Юлией Климентовской, Полом Гокиным (Paul Gokin), надеюсь, с пользой. Некоторые докладчики впечатлили - хорошим, уверенным знанием темы, которую читали, умением общаться с аудиторией, способностью увлечь даже такой темой, к которой я, к примеру, прямого отношения не имею (но имею опосредованное отношение). Один пример - доклад Марины Дидковской “Тестирование и оценка времени”. Я с нашими тестировщиками общаюсь напрямую, и, хоть они формально не являются моими подчинёнными, зачастую приходится тратить изрядно времени на введение людей в тему, на объяснение деталей процессов, особенно на тестовых версиях проектов, объяснения, кому какие баги надо постить и почему какой-нибудь “этот визуальный баг” таковым не является и прочие житейские радости.

Хотелось бы, конечно, подробнее пройтись по всем докладам, но так получилось, что я ничего не конспектировала, изданные тезисы восстанавливают в паммяти не все доклады, а записываемые ролики, к сожалению, будут доступны не раньше, чем через 2 недели, а может, и позже. Потому что, как сказали организаторы, ролики ещё надо оцифровать, порезать и разметить, а это время, и вообще… Может, после поездки наберусь сил, о чём-то напишу подробнее.
Ну и, конечно же, благодарности организаторам. Юра, ты умничка! Такое грандиозное мероприятие организовать… Олегу Бунину и Павлу Рогожину. Всем киевским и московским организаторам. И докладчикам - не поленились напрячься, подготовиться, выступить. И участникам - приехали, собрались, значит, не зря суета была. Спасибо Наташе и Лёше Колупаевым за приют
В общем, не жалею

UPD2: а что делать с этой красивой карточкой profyclub`а? Вот этот роскошный номер - его куда-нибудь нужно вбить?
Интересно, что на РИТ я регестрировалась ещё в прошлый раз, увы, не поехала, и не поеду на этот. Надо бы и поработать. С другой стороны, хотелось бы быть в теме, хотелось бы получить материалы конфы, да не спустя год, а как бы сразу. Если будет прямая трансляция - так же узнать где вовремя, а не на следующий день пялиться на “прямой эфир остановлен”, да.

Кого в вашей компании называют “дизайнером”? Понимаю, что вопрос не совсем корректный - тут зависит от того, чем компания, собственно, занимается, но всё равно интересно. К примеру, на прошлый пост о дедлайне и голимой вёрстке (трансляция в ЖЖ), где я использовала термин “дизайнер-верстальщик”, uznick ответил, что “А вот не надо совмещать дизайнеров и верстальщиков :)”. Отчасти ведь прав, не поспоришь. Но есть тема для обсуждения.

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

В нашей компании какое-то количество лет был один дизайнер - он именно так и назывался (не будем показывать пальцем, хотя, разумеется, это была я) , и это, с позволения сказать, дизайнер рисовал скетчи на сайты, отвёрстывал как простые сайты, так и макеты под шаблоны движков, и стандартных, и нашими же программерами писанных, с дальнейшей адаптацией вёрстки для новых страниц наших развивающихся проектов, рисовал, собирал и тюнил скины для виндовз-приложений, создавал пиктограммы и полноформатные иконки для программ, с программерами же оптимизировал интерфейсы этих же виндовз-программ; а так же периодически вёл переговоры с заказчиками и принимал участие в постановке более-менее внятной задачи для разработчиков. (more…)

Знаете, честно признаюсь, двоякое у меня лично отношение к дедлайнам. В первом моём отношении к ним я вижу следующее стечение обстоятельств: действительно, бывает такое, когда какому-то мудрому менеджеру приходит в голову уникальная идея, которую он не поленился высказать руководству. Которое, в свою очередь, перенаправило эту идею аналитикам и те, в свою очередь, оценили как перспективную и своевременную. А тут ещё руководство встретилось с потенциальными партнёрами, и те заинтересовались, и сказали, что, мол, вот то собрание, которое планируется в конце месяца - единственно удачное время для презентации базового макета будущего продукта, если они увидят, что воплотить идею - реально, если идея на деле окажется настолько же жизнеспособной, как и на словах, то будут вам инвестиции и всяческая наша поддержка. И вот идея спускается к разработчикам в виде ТЗ и с комментариями, мол, ребятки, вы уж постарайтесь. Сроки горят, за три недели нужно сделать базовую функциональность, базовый интерфейс (пусть не конечный вариант, но чтобы всё было причёсано и опрятно как минимум), если пройдёт - будет у нас бюджет на глобальный проект, минимум на год разработки для целой команды (сколько это человекочасов получается?).

В такой ситуации разработчики понимают, что если постараются, как просят, то в самом деле это и участие в чём-то глобальном/интересном, и полезный опыт, и повышения зарплаты, и на самом деле есть смысл поднапрячься (так было у нас с тем августовско-сентябрьским дедлайном, тяжёлым, но оправданным, как показала жизнь). Особенно, если сверхурочные оплачиваются и на предыдущих проектах разработчики убедились, что их не кинут, что это не гнусное использование рабской силы, а за хорошие проекты в самом деле надо бороться всей командой, сообща. Потому в прошлом у меня столько было заметок о командной работе, о взаимопонимании между группами разработчиков, между рисующими дизайнерами и верстающими, между верстальщиками и программерами, и между всеми ними и менеджерской надстройкой.

Но бывают и совсем другие дедлайны. Которые от безграмотного менеджмента и неуважения к разработчикам. Когда проект у людей висит уже не первый месяц, они что-то там возились, оптимизировали и даже разрабатывали функциональность, потом забрасывали на какое-то время, потом вдруг, скажем, под вечер в среду присылают письмо с архивом (!) проекта, частично даже без исходников (precompiledWeb), мол, ребята, вы там причешите в стиле (***) - в общем, нашего предыдущего большого проекта. Всё это без описания функциональности и без документации на сам проект, типа вы же такие умненькие, разберётесь. Типа, там же только таблицу стилей подредактировать. Запускаю проект (ага, без исходного кода, без связей, ещё повозиться надо, чтобы он вообще запустился, чтобы вообще хоть как-то увидеть интерфейс глазками, покликать по функциональным элементам), и тихо млею от того, насколько безграмотно организовано филе… больше сотни .aspx страниц, без шаблонов, с кошмарнейшим html кодом - доктайп не прописан ни в одной из, сплошные незакрытые или закрытые ошибочно теги (открыт параграф, закрыт спан), зато всё оформление прописано атрибутами в самих тегах. Да и значения атрибутов в одном теге то в двойных кавычках, то в одинарных, то совсем без оных. Встроенный в редактор валидатор кода зашкаливает, и это естественно - он подчёркивает всё, где видит неправильность, т.е. его использовать для правки смысла не имеет. А ещё часть функциональных элементов (сложных гридов, к примеру, с сортировками/фильтрами/настройками внутри, или календарик для фильтра по датам) вообще собираются js скриптом полностью - т.е. те же теги и атрибуты тегов - шрифты, цвета, фончики, извиняюсь. Какой css?? Ну и, повторюсь, весь этот хлам без сопроводительной документации. И даже тот факт, что запускающая для проекта страница называется Test.aspx, разработчики должны были понять сами ага. (more…)

Конференция для украинских веб-разработчиков, которую и здесь в том числе анонсировала ещё осенью, всё-таки состоится! Теперь она - UA Web 2008, пройдёт в Киеве, 27-28 марта, в Президент Отеле. Одна из целей организаторов - собрать в одном месте и перезнакомить профессионалов этой отрасли всего за 900 гривен с участника. Сейчас сформированы три секции - “Клиент”, “Серверное программирование и базы данных” и некие “другие темы” (там будут доклады про НЛП и аутотренинг, советы, как стать успешным фрилансером, или вот ещё — “Использование скрытых психофизических возможностей веб-разработчиков для успешного создания и внедрения современных Интернет-проектов” и не знаю даже как можно было бы меня убедить пойти на эту третью секцию), меня же очень-преочень интересует первая секция, каждый первый доклад. Настолько интересует, что я, скорее всего, буду. Регистрация у меня уже есть, осталось оплатить. Кстати, на сегодняшний (!) день подано 939 заявок на участие и получение материалов.

Подробнее о программе конференции вы можете узнать здесь; я у себя дублировать всю программу не буду, хотя бы потому, что опубликован не конечный вариант — ожидаются ещё доклады и докладчики, поэтому на сайте конференции вы, вероятно, всегда получите последнюю версию программы. Но не могу не поделиться программой на ту самую первую, клиентскую секцию: (more…)

Хотелось бы собрать статистику: по каким причинам — профессиональным и человеческим — увольняют дизайнеров и веб-дизайнеров? Не будем рассматривать ситуации, когда компания не подошла специалисту (денег мало, работа не интересная, надоело) и он уволился сам, не дожидаясь, так сказать. В теме возможны всё-таки две ситуации - когда дизайнер отработал испытательный срок и не был принят (не прошёл), и - чуть печальнее и тяжелее - когда необходимо уволить человека, проработавшего на компанию приличное время. И ещё маленькая оговорка: давайте учитывать, что под “дизайнер” будем понимать любого специалиста из дизайнерской группы — художника-дизайнера, или технического дизайнера (верстальщика), или ещё какие-то разновидности дизайнеров из IT-отрасли. Поделюсь своим опытом, может, добавлю из рассказов знакомых; интересные дополнения из комментариев включу в текст в режиме UPD (от “такого-то”).

1. Компания меняет профиль деятельности. Абсолютно реальная ситуация - дизайнер по-началу был востребован, приходили какие-то заказы на разработку сайтов, но редко и малобюджетные. И тут люди вклиниваются в бизнес, который к дизайну отношение имеет весьма далёкое, бизнес прибыльный - силы всей команды уходят в другую отрасль, заниматься поиском заказов и проработкой малобюджетных клиентов уже никто не будет, и специалист становится балластом. Сначала это не явно заметно - просто работы поубавилось, потом ему объявляют, что, мол, лишний ты здесь, до свидания, дорогой.

(more…)

Из прошлого поста о верстальщиках и программерах могло сложиться (и у некоторых, судя по переписке, сложилось) неправильное впечатление: да, я писала о кривом коде, порождаемом визуальными редакторами, да, я недоумевала - как же так, не ВасиПупкины, не начинающие веб-дизайнеры — вполне себе сложившиеся программисты, и вдруг - режим Design в VisualStudio для быстрого создания типовых форм. Но ведь и фраза “а что, у нас программеры уже напрочь ручками код перестали писать?” не имеет ничего общего с рекомендациями “писать” в блокноте, ни разу. И более того, когда касается не программирования, а вёрстки - своим ребятам я категорически запрещаю верстать в notpad`e, а программерам я вообще не указ. Просто - чем больше проект, тем меньше работы для дизайнера и верстальщика в проекте (когда уже написана общая таблица стилей, уделить пять минут тюнингу новой части сервиса — когда продумана и разработана концепция иконочек, маркеров и прочих фишечек, нарисовать новую козявочку — никакой сложности), но тем больше работы, связанной с тем, что ломается и “едет” дизайн после того, как программер поработал с проектом.

И здесь работа не для тестировщика, ему-то что, он таск отправил - что видит, о том и написал. А техническому дизайнеру - разгадывать шарады, почему что-то куда-то уехало. На днях звонит канадский программер, говорит — “я там ничего такого особого не делал… а блок с прелоадером (очередная крутящаяся козявочка с надписью “Loading…”), которая показывалась всегда в центре экрана, уехала в левый верхний угол“. Что делает дизайнер? Правильно, ломится проверять таблицу стилей - вдруг где-то правила сбились, вдруг где-то и в самом деле неграмотно написано… вроде всё честно. Ломится в код - бывало такое, когда программер добавлял контейнер (div) в код “не правильно”, а где ему показалось удобнее, но в коде тоже всё корректно. В чём глюк, разумеется, нашла - раньше прелоадер показывался на довольно простых условиях, когда генерилась таблица статистики, или подгружались ещё какие-то объёмы данных; но сейчас сценарии усложнились, и блок с картинкой (с тем же, как бы, идентификатором) программеру пришлось сделать серверным контролом. Т.е. с динамически создаваемым именем идентификатора. Т.е. правила, в соответствии с которыми прелоадер показывался в центре экрана, правила, которые назначались блоку по имени идентификатора, больше не применяются - имя-то меняется. (more…)

Сержусь. На дотнет, микрософт, билагейтса и ленивых программеров. Можно сколько угодно говорить о валидной вёрстке, с умным видом вещать о том, что таблицы в гипертексте используются для табличных данных, а макет, все контейнеры документа, весь этот дизайн - для этого есть другие теги, что избыточность в вёрстке - это дурной тон, код должен быть оптимальным и совершенным, как алмазная призма. А потом с таким старанием размеченный шаблон верстальщик отдаёт программеру, и на стерильность можно забить уже через пять минут (и, кстати, не первый раз на эту тему пишу).

Из простейшей (на первый взгляд) странице с редактированием профайла юзверя только что убила четыре (!) избыточные одноячеечные таблицы. Одна обрамляющая контент, одна - для блока с общими данными юзера, одна - для Change Password если юзер кликнул сменить пароль и одна - на Confirmation, если всё прошло успешно. На четвёртой не сдержалась, подзываю программера, мол, шо за дела? Мы же договаривались - ты вообще никакую вёрстку на странице не делаешь, кидаешь свои контролы в линейном порядке, я сама разрулю, как они должны ОТОБРАЖАТЬСЯ! А он мне отвечает… я, говорит, и не добавлял никакую разметку… оно, говорит, само. Он в студии, в режиме дизайн за один клик просто добавляет целый блок (размеченную форму) для, к примеру, смены пароля - со всеми необходимыми тегами, айдишниками и прочими атрибутами. Охренительная экономия времени! И вот при таких вот автоматизированных для ускорения работы программера действиях и добавляется, автоматически же, “контейнер” в виде одноячеечной таблицы, обрамляющей этот блок.

Спрашиваю - а что, у нас программеры уже напрочь ручками код перестали писать? Или вся работа верстальщика должна заключаться в том, чтобы каждую страницу при доработке сначала долго вычищать от избыточного кода, самодобавляющегося при пользовании программистами режимом “дизайн”, от самопрописавшихся атрибутов width и height, которые появляются, когда программер в том же блин режиме “дизайн” случайно где-то что-то дёрнет? Или - ещё хуже, когда программист, утомившись программировать, вместо того, чтобы пойти чайку попить садится, и начинает “оформлять” созданные им только что формы.

И вот я вышкаливаю пару талантливых юных верстальщиков. Ругаю за ошибки при анализе сетки. Если позволяет проект - заставляю перевёрстывать, объясняю, что вёрстка веб-страниц - это как раз та отрасль, где уместно применять свои способности к анализу. Потому что на самом деле это так, прежде чем вырезать из эскиза первую картинку, прежде чем написать первую строчку кода, первый контейнер, имеет смысл потратить время на то, чтобы понять макет, продумать для него его модульную структуру; и если на недовёрстанной ещё первой странице макета появляется необходимость какому-то классу переназначить правила с помощью ! important - значит, недопроанализировал, значит - всё заново (ага, и как раз пару дней назад такое было) перевёрстывать, благо есть возможность. В отличие, к примеру, от тех ситуаций, когда приходит сюда давно свёрстанный проект на доработку программерам, и спустя месяц вспоминают про дизайн (ой-ё, Таня, тут бы поправить бы), и ты прекрасно понимаешь, что поправить “честно” не выйдет. Или вместо 30 минут надо затребовать 3-4 дня на перемакетирование и перевёрстку всего этого разросшегося уже проекта, или - переназначение доменных правил, увы. Но если есть возможность - давайте продумывать макет изначально так, чтобы не было необходимости во всех этих important`ах.

И вот они, такие продвинутые верстальщики, откроют свой проект через какое-то время, когда уже динамика, посмотрят на код страниц… На все эти самодобавившиеся и саморасплодившиеся таблицы. На разъехавшиеся контейнеры из-за самопрописавшихся в их содержимом ширин и высот. И спросят меня - Таня, а к чему был весь этот предварительный цирк с логичной и валидной вёрсткой? И я не буду знать, что им ответить. Или - как мне сегодня программер посоветовал - посоветую им так же написать гневное письмо Биллу Гейтсу, или разработчикам Visual Studio, чтобы они укротили свой сервис с такими полезными автоматическими решениями. И режим “design” в Visual Studio прибили нафиг, навсегда. О. И Visual Studio тоже прибить, и тоже навсегда. Пусть на Java переучиваются, ибо нефиг.