Обсуждение вообще вышло довольно примечательным; я, кажется, с чрезмерными претензиями к личным качествам и профессиональным навыкам специалиста, из которого получается хороший верстальщик, а ребята в комментариях только подчёркивали это; Женя Бондарев писал:

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

В какой-то степени Женя прав, даже с меркантильной точки зрения в нашей компании (где программеров в любом случае раз в 5 больше, чем дизайнеров) хороший (а значит, как минимум ведущий) программист будет получать больше хорошего верстальщика, но здесь вот ещё в чём сложность расчётов: на больших проектах задачи распределяются на подзадачи и направления, и кроме PM`а на проекте есть несколько подкоманд программистов, каждой из которых управляет ведущий программист, лучший. Т.е. он не только лучше всех программирует, он ещё занимается менеджерской работой, распределяет задачи внутри своей команды и отвечает за качество кода своих подзадач. Это всё-таки другая ответственность. К сожалению, всегда бывает так (это я по себе знаю), что большую часть задач, которые ставятся перед командой, ведущий специалист может выполнить сам, и, более того, быстрее, лучше, качественнее (и дальновиднее, потому что умеет видеть проект в целом и перспективу), но задач в какой-то момент становится несколько… больше, чем может выполнять один человек за один рабочий день, а клонировать этого самого ведущего программиста пока технологии не позволяют.

Что же касается сравнения зарплат у обычных программеров и у верстальщиков, то здесь всё очень даже сопоставимо, а с ростом команды, когда и в нашей, дизайнерской команде понадобится выделять тимлидеров и некоторым ребятам добавится административной работы, то зарплаты будут становится сопоставимыми с зарплатами ведущих программистов, я в это верю. Но есть здесь и другой момент, о котором стоит говорить. У меня много примеров, когда человечек приходит в веб разработку, как верстальщик (веб-дизайнер), начинает изучать js, потом – серверное программирование и… в чисто вёрстку уже не возвращается. И не знаю случаев, когда программист начинает серьёзно интересоваться html+css, бросает своё программерство и становится верстальщиком. И дело не только в деньгах, во многих причинах, в том числе и в том, что “есть устойчивое мнение”, что статус программиста в любой IT компании, в любом IT сообществе выше, чем у верстальщика.

Нашла недавно старую уже шутку по теме, “Памятка верстальщику, мнение программера” – мило для тех, кто умеет посмеяться над собой и несовершенством мира, но если говорить серьёзно, то есть проблема с подобным отношением к верстальщикам. Мы тут на прошлой неделе заспорили с одним из программеров по поводу одного визуального глюка и методов его решения, вот он мне что-то типа такого и выдал, что “я здесь программер, и я решаю, какая будет логика на этом участке!” – пол часа бессмысленных препирательств закончились тем, что тимлид по этому проекту нашёл время подойти к нам и выяснить в чём проблема, выслушать обе стороны и подтвердить, что МОЁ решение — верное, а программер просто в собственном коде чего-то недосмотрел. И таких ситуаций в нашей компании было довольно много, видимо, поэтому ребята, которые не новички и работают со мной больше двух лет, спорят редко и уж тем более не смотрят свысока, а зачастую даже спрашивают совета по более концептуальным вопросам, чем “как отформатировать этот блок”. Но для того, чтобы на сегодняшний день было ТАК, нужно, чтобы во многих предыдущих спорных или сомнительных ситуациях верстальщик ОКАЗЫВАЛСЯ ПРАВ, и его статус рос с каждым верным решением.

А для этого нужны знания и опыт, потому и желательно “и творческое, и аналитическое мышление”, и — умение в сложной ситуации взять на себя ответственность, и умение мотивировать свои решения, объяснять как команде в целом, так и каждому отдельно взятому программисту, как бы свысока он поначалу не смотрел. Когда к тебе кидается программист с обвинениями в твоей кривой вёрстке и говорит, что вот он “взял тобой отвёрстанный блок, вставил его в новый документ, прописал в документе ссылку на твою же таблицу стилей, и эта таблица стилей работает не полностью, криво, где-то что-то не центрируется, где-то ещё какие-то глюки выползают”, и достаточно одной минуты на анализ проблемы: ага, программер создал документ, умничка, и код правильно скопировал, и ссылку правильно поставил. Только при генерации этого нового документа забыл указать Doctype, вообще. Подумаешь, одна непонятная такому гениальному программисту строчка.

Уметь отстаивать качество своего кода, в котором уверен, а то недавно наш канадский гений, который принимает нашу вёрстку веб-сайтов и занимается интеграцией в общую систему, громко (мы-то не слышали, но канадское руководство аж письмо спешно написала о том, что вот, мол, Алан кричит, что вы опять плохую вёрстку выложили) обвинял в некоторых, гм, некроссбраузерных записях в таблице стилей и требовал, чтобы поля и отступы описывались четырьмя значениями (верх-право-низ-лево) даже для симметричных свойств, типа margin: 2px auto; – это недопустимо и глючит в разных браузерах, надо писать margin: 2px auto 2px auto;, когда же я задала ему вопрос о том, что это проверялось точно ли с указанным Doctype? И если да, можно ли мне дать пример, где и для какого браузера сокращённая запись НЕ РАБОТАЕТ? он написал, что вот прямо так сразу под рукой этого примера нет, но “будет время, он продемонстрирует”, и вот вторую неделю ищет примеры, и канадское руководство, так же, как и мы, ждёт подтверждения, справедливы ли были обвинения этого интегратора в том, что украинская вёрстка – безграмотная.

Кстати и Женя Бондарев, который своим комментарием заставил задуматься о специальностях, пограничных с вёрсткой – программер, и проблему поиска хорошего верстальщика, а так же отношения к вёрстке и программированию видит со своей программерской точки зрения.

А вот Zigzag видит специалиста с другой стороны:

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

Я Паше ответила, что это, видимо, потому, что верстальщик понимает не только то, как форма или окно должны выглядеть с точки зрения “удобства пользования”, но и с точки зрения логики самой формы, сценариев отображения форм, да и с точки зрения реализации тоже.
Программеры смотрят на интерфейс изнутри. Менеджмент, юзеры – снаружи. А верстальщики…
Вообще, это другое видение экранного интерфейса, когда у тебя долгое время практика смотреть на него (интерфейс) изнутри и снаружи одновременно. Верстать, проверять, тестировать, да ещё и когда у тебя 14 из 16 контейнеров с формами скрыты и показываются в зависимости от разных условий, и эти сценарии тоже нужно в голове держать, и не только код делать оптимальным, но и пытаться оценивать оптимальность самих сценариев, и, конечно же, на совещаниях (митингах) не молчать, высказывать мнение о том, как оптимизировать экраны, упростить формы, сократить шаги сценариев. А как же ж без этого? Т.е. специальность проектировщика интерфейсов — она на самом деле так же близка к верстальщику, как и программирование.

В заключение я бы хотела попиарить один случайно обнаруженный конкурс (проводится при поддержке Ru-Center) для веб-разработчиков… который, вообще-то, объявлен уже давным давно, ещё в апреле этого года, видимо, в своё время я проигнорировала информацию. Обратила внимание на знакомое имя среди организаторов: автор идеи и председатель оргкомитета конкурса WebHiTech — Артемий Ломов. Когда-то я регулярно читала его колонку о веб-дизайне “Веб-анатомия по воскресеньям“, была подписана на его рассылку. После, пару лет назад, приятно удивлена тем, что Артемий, решив завязать с рассылкой на Subscribe.ru, передал подписчиков моей, на то время регулярно выходившей рассылке “Библиотека Сайтостроительства…“, мда.. ностальгия. Да, так вот. Помимо интересной самой по себе идее конкурса обратила внимание на миссию конкурса:

Миссия конкурса WebHiTech — посильное содействие повышению культуры веб-разработки в Рунете посредством популяризации уважительного отношения веб-разработчиков к духу (первостепенно) и букве (не первостепенно, но тоже важно) актуальных рекомендаций Консорциума W3C. Имеются в виду, главным образом, спецификации расширяемого языка разметки гипертекста XHTML 1.0 Strict и XHTML 1.1, каскадных листов стилей CSS2 и руководящие указания по обеспечению доступности веб-контента WCAG 1.0.

Помимо прочего, в правилах конкурса обнаружено:

Портрет идеального, с точки зрения оргкомитета, информационного сайта, имеющего все шансы победить на конкурсе WebHiTech в любой из номинаций, таков:

• Страницы сайта оформлены в духе разумного, функционального минимализма, производят безусловно позитивное эстетическое впечатление и воспринимаются как завершенные и целостные композиции.
• Все страницы сайта оформлены в едином стиле. Сайт создает целостное впечатление.
• Страницы сайта рационально используют площадь окна браузера. Оргкомитет конкурса отстаивает убеждение, что «резиновая» верстка при прочих равных условиях предпочтительнее фиксированной по ширине.
• Область основного содержания использует максимально возможную (без ущерба для других функциональных областей) площадь на пространстве страниц. Безусловное предпочтение отдается сайтам, на которых нет бесполезных для посетителей элементов, таких, как нетематическая реклама и т. д.
• Система навигации сайта интуитивно понятна, информативна и всячески способствует экономии времени и сил посетителей. Ссылка, ведущая на текущую страницу, считается грубейшим недочетом. Наличие полнотекстового поиска по всему контенту сайта приветствуется.
• Посетитель может легко изменить размер шрифта на странице штатными средствами привычного ему браузера (даже если речь идет об IE).
• Текстовое содержание сайта, а также альтернативные текстовые комментарии к графическим изображениям и другим объектам, являющимся частью контента, полностью доступны пользователям консольных и речевых браузеров, устаревших версий графических браузеров, пользователям, привыкшим отключать графику.
• Важная для пользователей функциональность всех сервисов сайта сохраняется при отключенных JavaScript, Flash, ActiveX и т. д. в браузере.
• HTML-разметка отвечает исключительно за логическое структурирование контента, тогда как управление его представлением (внешним видом, особенностями воспроизведения программами синтеза речи и т. п.) полностью возложено на CSS. Предпочтительно использование внешних листов стилей, загрузка которых не требуется с каждой вновь открываемой страницей.
• HTML-код страниц соответствует идеалам семантической верстки. (Заголовки размечены тегами <h1>…</h6> в соответствии с естественной иерархией, но никак не <font>; абзацы — тегом <p>, но не <br>, таблицы используются только по прямому назначению и т. п.)
• Контент сайта легко индексируется поисковыми машинами, переход поискового робота между страницами сайта не затруднен никакими технологическими ограничениями (например, навигацией, реализованной на основе JavaScript).
• На сайте предусмотрены автоматически генерируемые, прозрачные для пользователя (т. е. не требующие от него никаких действий) версии представления контента для вывода страниц на печать и для просмотра их на экранах карманных компьютеров.
• Страницы сайта отображаются без существенных различий во всех сколько-либо распространенных на текущий момент графических браузерах: IE 6—7, Opera 8—9, Firefox 1—3, Safari 3.
• Код разметки обнаруживает полное соответствие спецификации XHTML 1.0 Strict (менее желательно — HTML 4.01 Strict) или XHTML 1.1. Код листов стилей полностью соответствует спецификации CSS2.
• Текст на страницах сайта вселяет уверенность, что его автор (редактор) в совершенстве владеет русским языком и правилами набора.
• Иллюстративная графика и фотоматериалы, размещенные на сайте, не вызывают сомнений в художественных талантах и технических навыках их авторов.
• Любая страница сайта загружается не более 10 секунд даже в том случае, если для доступа в Интернет посетителем используется модемное соединение со скоростью 28 800 бит/с.

Оргкомитет отдает себе отчет, что идеальных информационных сайтов, как это ни печально, не существует в природе, однако полагает, что вышеприведенная «контрольная карта» сможет стать неплохим подспорьем для потенциальных участников конкурса на этапе принятия решения о целесообразности выдвижения того или иного проекта.

Я, с одной стороны, пиарю конкурс и рекомендую веб-мастерам подавать заявки, а с другой — обратить внимание на эту “контрольную карту”, которая (почему нет?) вполне может стать прототипом списка для самопроверки веб-разработчика и для тестирования специалиста на очередном собеседовании. Раз уж мы в поиске такой… творческой личности с аналитическим складом ума, ха-ха.

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

У нас команда большая, проекты (те, которые с web интерфейсами) есть не очень большие, а есть крупные сервисы, а есть и просто ветка рекламных сайтов (коих на каждый разрабатываемый продукт несколько делается, то на разную целевую аудиторию разные, то под разные задачи), где разделение на “дизайнер рисующий”+”дизайнер верстающий” просто уместно с любой точки зрения, хотя бы даже с целью оптимизации процесса. Канадское руководство, кстати говоря, дотошно пытало меня,  довольно долго, зачем же нужно подобное разделение? Я долго пыталась объяснить и с одной точки зрения, и с другой, и в конце концов сформулировалось что-то типа такого “всё-таки дизайнер рисующий — личность особо творческая, с развитым образным восприятием мира, способный создавать визуальные формы с нуля, типа креатив, а дизайнер верстающий должен обладать логическим мышлением, изрядным аналитическим складом ума, мыслить не образами, а логическими конструкциями”.

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

Кстати к теме, уж не знаю, как мировое сообщество переводит на английский язык слово “верстальщик” (причём для web, а не для полиграфии), но у наших канадских партнёров в ходу слово “интергратор” – это как раз тот чувак, который берёт нарисованный для него эскиз и создаёт из него рабочий сайт. Интергирует, так сказать, визуальный прототип в реальный проект. И они там, и мы здесь (я и моя маленькая команда верстальщиков) — страшно сказать, интерграторы. Однако как только речь заходит о крупных .NET`овских проектах, они тушуются… вот был период, когда на одном крупном сервисе был период небольшого перепроектирования и редизайна, который совпал с перетрясками административными, и тогда канадская команда было сказала, что редизайн (и связанную с ним ре-вёрстку) они будут делать сами. И ладно, мы не обиделись, баба с возу… Прошло время. Срочное совещание по громкой связи с нами и срочно – два дизайнера-верстальщика на этот проект. Потому что… их “интерграторы” налажались и не справились. Потому что их верстальщик открыл .aspx и сказал, что он здесь ничего не понимает. Потому что даже в шаблонах он напортачил так, что я потом ещё долго чистила за ним безобразные, недопустимые на больших проектах конструкции.

Вспоминаю, как я, несколько лет назад, пришла в нашу контору и наш Технический Директор тоже меня… собеседовал. Собственно, смешно вспоминать начало диалога, я всё равно на тот момент знала о вёрстке на порядки больше, чем он, однако главное, что его интересовало — смогу ли я работать с движками, написанными на .NET, понимаю ли я код, который (он мне показывает) вот в этом, .aspx файле? Что я могла ответить. У меня вообще не было практики сотрудничества с .NET программерами, ни единого проекта. Однако было изрядно .php и (меньше) .java, и я самоуверенно заявила на собеседовании: нет большой разницы делать вёрстку под любую платформу, если есть понимание закономерностей, которые таки прослеживаются во внутренней логике любой из них. И я была права! Даже при том, что мне всё-же пришлось обучаться “на лету”, не было ни одной задачи, ни одного контрола, студийного или стороннего, который бы я не смогла приструнить под заданный стиль проекта.

И вот второй год поиска верстальщика, готового справляться на должном уровне с нашими задачами меня не то, чтобы расстраивает, но как-то, признаюсь, настораживает. Практика показывает, что очень не всегда расчёт на то, что “обучим здесь, по ходу дела” срабатывает, что есть изрядная инертность и зловредные “ложные истины”, которые тормозят специалиста в саморазвитии с одной стороны, и мешают командной работе над *успешным* проектом с другой. Потому что то, что допустимо (или, во всяком случае, не критично) в сегменте разработки 5-10 страничных сайтов-презентаций, не позволительно на серьёзных проектах. А привычка допускать кривости – она остаётся, она живёт в верстальщике и отражается в каждом первом проекте, и не надо строить иллюзий, что “в этом” проекте он, пусть с ним, юзает вложенные таблицы и атрибуты для визуальных стилей, а вот “в этом”, строгом, сделает стерильно. Не сделает.

Может, я себя не так веду на собеседованиях? Ставлю не те задачи, спрашиваю не о том? Сегодня вот ещё будут два человечка, девочка и мальчик. Оба позиционируют себя именно как технические дизайнеры, для вёрстки и, немножечко, для js, что нормально. Ссылки на сайты в их портфолио не впечатлили, код в лучших традициях конца прошлого века (прочем, и в то время были ребята, которые писали здравый код), и что я? Опять спрашивать о том, что такое Doctype и для чего он нужен? Как имитировать кнопку ссылкой свойствами css или позиционировать вот такую вот модель? А как же узнать, способен ли человек думать и анализировать проект, с которым ему придётся работать? Угадывая наперёд, где какое наследование будет уместно, где понадобится динамика или шаблонизация при росте проекта, чтобы на каком-то этапе не споткнуться о собственные костыли, когда без концептуальной перевёрстки проект становится ущербным и дико избыточной вёрсткой и страшной таблицей стилей? Не замыкаясь на ограниченной задаче “отверстать вот эту, присланную утром картинку” лишь бы отображалось похоже и гордиться этим, громко споря и заявляя – не важно, что там внутри и как оно написано, главное, что отображается похоже и кроссбраузерно, и валидацию даже сайты Артемия Лебедева не проходят, и лучший валидатор — браузер! Эх, икается, наверное, господину Лебедеву, кумиру юных, нуждающихся в авторитете, подражающих даже в ошибках…

У наших программеров (.NET) такого требования не было и на собеседованиях никто ничего по теме вёрстке у них не спрашивал – основная среда разработки – M$VS, и знания тестировались только возвышенно-программерские. Вёрстку, как следствие, в большинстве своём публика знает только в первом приближении, и в том случае, когда начинается работа с интерфейсом и публике всё же приходится свои рабочие контролы как-то размещать на странице, они городят совершенно безумный код, разумеется, не ручками, а в режиме “design” – этого лучше не видеть, скажу только, что, когда я получаю в работу очередную страницу, основное время уходит на удаление всего того кода, который там предусмотрительно набодяжен.

Клиенты ныне настолько разбалованные аяксом, что требования к интерфейсам (во всяком случае служебным интерфейсам на сервисы) у них довольно масштабные, посему в конторе очень много используют как готовых решений типа telerik, RadControl и иже. Деревья, закладки (имитация виндовых “табов”), хитрые “комбобоксы” с расширенной функциональностью и прочее, и прочее. Иногда прокатывает – просто взять готовое и – напильником (в том числе и визуал), иногда так складывается, что напильником приходится из подводной лодки допиливать реактивный самолёт, и, оценив масштаб /когда готовый контрол доработать теоретически реально, но, для узкой задачи он, с одной стороны, является избыточным и тяжеловесным, с другой стороны – ковыряться детальнейше в больших объёмах чужого кода – то ещё удовольствие/, принимаем решение делать свой контрол (но на это понадобится, к примеру, один рабочий день. Как правило это самое трудное – выбить этот самый один рабочий день).

Недавно, почти довёв до совершенства RadControls Tabstrip`овские закладки под поставленную задачу наткнулись, что как раз незатейливую заказанную клиентом фичечку реализовать просто не получается, контрол же сам по себе – ничего военного, со всем напором юношеского энтузиазма убедили руководство выделить для работы нам время, и сели с программером его сочинять. Я ему прикинула модель тегов, расписала, где нужны будут идентификаторы и где куда мне генерить какие именованные классы (разумеется, использовали в разметке двухуровневые ненумерованные списки) , и какими спанами куда и что обрамить (первоуровневые элементы по событиям визуально становятся похожи на закладки же ж со сглаженными краями, но при этом ПРОИЗВОЛЬНОЙ ШИРИНЫ). Дальше была разделённая работа – я писала таблицу стилей, программер – логику выгребания из xml имён первого уровня, второго уровня, да в зависимости от определённого при авторизации статуса юзера, да… короче, написали. Супер получилось. Вот кстати тогда он и поделился информацией (с ужасом, как мне показалось), что в некоторых фирмах подобные контролы пишутся программерами при НЕЗНАЧИТЕЛЬНОЙ дизайнерской поддержке (ну, там, придумать-нарисовать эти самые картинки на закладки и, возможно, порезать их же).

А мне подумалось, что как раз легче работать “в паре” с теми программистами, которые не заморачиваясь вообще на “размещение” их рабочих контролов на странице кидают их… в столбик на голую страницу. Так кст. говоря, легче, проще и быстрее. Хотя – признаю, всё не так плохо, и программеры часто подходят с вопросами по вёрстке и стилям, и (не часто, но всё же) иногда что-нибудь не сложное пишут сами (предупреждая вежливо, что вот создали класс и описание его закинули в .css файл, ничего? Имя нормальное? описание не безграмотное? Ничего, говорю, нормально-красиво-до-стерильности-сама-доведу).

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

И я не против, когда разработчик хочет себе высокую оплату своего труда, и сама убеждаю руководство, что платить надо больше, и меня, разумеется, радует, что учиться они всё-таки хотят, только реально учатся пока медленно почему-то, но повторять стопятый раз фразы типа “у таблицы нет атрибута valign!” “что опять делает padding в стиле картинки? Создаёт поле от картинки до неё же?” “опять незакрытые теги! Опять не закрыты картинки, br`ы, но ладно, здесь просто обучиться. Но абзацы-то, абзацы мы научимся закрывать?” Я уж не говорю про лекции о семантике и логике, обычной логике. Ладно один из верстальщиков (оправдываясь, обиделся) говорит “я же говорил, что ещё не освоил дивную вёрстку и буду верстать пока таблицами, вы же разрешили!” – Б-блин. Да. Подтверждаю. Разрешила. Сделать колоночный макет таблицей. Но.Напрудить мне десяток (а в целом – 24) вложенных таблиц для того, чтобы РАЗМЕТИТЬ В ОДНОЙ СТРОКЕ ПЯТЬ ЗАГОЛОВКОВ И ПЯТЬ СТРОЧЕК ТЕКСТА вложенными таблицами – это уже не имеет отношение к дивной вёрстке, это, извиняюсь, имеет отношение к ОСНОВАМ HTML и ОСНОВАМ ЗДРАВОГО СМЫСЛА, будут они обижаться или нет. Ок, разобрали с ним вёрстку на примере того, что делал он и того, что переделывала я (не изменив своего обещания разрешить таблицу для колоночного макета, свести весь макет из 24 таблиц к одной), отметили те атрибуты, которые просто являются ошибкой (т.к. не существуют и не работают), те атрибуты и теги, которые являются логической ошибкой (т.е. нарушают логику документа и, как следствие, усложняют вёрстку, прежде всего из-за непредсказуемости ошибок, хрен найдёшь потом почему у него что-то куда-то уползло), и те, которые в целом написаны верно *(с т. зр. логики вёрстки), но избыточно, т.е. код, который в оптимизированном виде использовать проще, да оно и нагляднее получается с т.зр. читабельности всего созданного филе другим разработчиком или даже этим, скажем, через недельку.

Со вторым там всё ещё более запущено. Меня, конечно, безмерно радует энтузиазм, желание быстрее научиться и делать правильно, но ошибки, которые генерит второй, пугают больше. Сами понимаете, если верстальщик не закрыл, к примеру, абзац, большого горя он никому не принёс. А вот если какой-то рульный контейнер (div), описание которого задаёт поведение всех дочерних объектов, а потом пол дня ищет, почему у него всё разъезжается, или ещё хуже, делает плавающую модель и удивляется, почему соскакивает блок (не понимаю, говорит, почему, я же размеры линейкой из макета в фотошопе снимаю!), а обнаруживается, что родительскому объекту задан фиксированный width (ой, а откуда это? я этого не писал! это DW сам прописывает!) потому что в режиме “Design” в DW он где-то как-то за что-то потянул, а потом в коде не проверил… и.. ой, ну там короче много всего, больше похожего на анекдот (я почти уверена, что он не издевается, что он не специально).

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

Заодно пришлось подгонять откровенным шантажом. Объяснять одну простую тупую вещь. Если я из одного проекта в другой буду каждый вечер сидеть до десяти вечера в офисе и ПЕРЕДЕЛЫВАТЬ работу, набодяженную нашими капризными и такими требовательными к уровню зарплаты труженниками веб-девелопмента, то нафиг надо тратить фирме зарплатный фонд на поддержку их капризов? Я согласна на премиальные, сделаю сама, как и раньше – когда я одна работала, в целом работы, может быть, было и поменьше, но не в шесть раз, точно не в шесть, и – успевала, тяжело было, но хотя бы контролируемо (хочешь сделать хорошо, сделай это сам!)

Тут я, разумеется, лукавила. Потому что даже послеотпускной трёхнедельный дедлайн в августе-начале сентября, когда надо было, и сделали, и круто, и зарплату подняли, и сверхурочные заплатили, и премию, и казалось бы – с чего бы мне быть недовольной? А вот с чего. Нафиг такие напряги. Здоровье подорвало, бессонницы начались, приступы странные с вызовом скорой в офис, с мужем проблемы слёзные, хозяйки мол дома нет – не в деньгах ведь счастие, так?