Факторы, влияющие на html вёрстку (Часть 1: Работа HTML кодера)

    Для кого эта статья?


    Html кодерам – начинающим кодерам поможет повысить
    свой профессиональный уровень; оценить текущую ситуацию
    в проектах, предупредить негативное течение проекта.Тем, кто
    ещё только определяется «быть или не быть» больше вкурить
    о профессии html кодер. Те же, кто в кодинге давно врятле
    найдут в статье что-то новое для себя, а некоторые вещи
    даже могут показаться не достойными внимания. Однако стоит
    помнить, что очевидные вещи для одного — это неизвестный
    мир для другого, а ваш опыт хорошей практики может быть
    выходом из сложной сложившейся ситуации для кого-то.
    Руководству – узнать, какие мероприятия стоит провести
    в компании для улучшения рабочего процесса, повышения
    опыта работников, уменьшения издержек (за счёт уменьшения
    перерасхода проектного времени и учёта не просчитанных
    ранее активностей) и повышения качества.
    Руководителям проектов (Project managers) – поможет
    учесть некоторые специфические риски проекта: узнать о
    неизвестных ранее поглотителях проектного времени и не
    запланированных активностях; узнать о реальных трудозатратах
    по некоторым активностям; оценить и улучшить текущий уровень
    ведения проектов.
    Другим участникам web разработок – поможет больше
    узнать о трудовых буднях своих коллег.

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

    Работа HTML кодера


    1. Исходные данные и материал для вёрстки.


    1.1 Вёрстка дизайна


    Худший вариант:
    Клиент присылает некачественный материал для вёрстки.
    Материал в форматах pdf, ppt, jpg либо psd со склеенными
    слоями, растеризованными шрифтами, шрифтами со сглаживаниями;
    шрифтами, не входящими в поставку Windows. Требования
    описаны словесно («сделайте красным», «сделайте, как здесь»).
    Хорошая практика:
    Материал для вёрстки должен быть в формате PSD (не исключён
    другой популярный формат, поддерживающий слои). В PSD
    используемые слои названы соответственно своему содержимому.
    Шрифты, не входящие в стандартную поставку Windows, используются
    только для картинок.
    Влияние:
    Склеенные слои, растеризованный текст и другие не соблюдённые требования к исходному материалу приводят к увеличению времени вёрстки.

    Пример: в дизайне используется кнопка в виде картинки. Необходимо сделать похожую по аналогии. При дизайне, каким он должен быть, это займёт около 10 минут. При плохом качестве может занять и 2 часа.

    Действия:
    1. PM: На этапе выяснения требований дать клиенту
    ознакомиться с документом по требованиям к графическому
    материалу. (Содержащему примеры требований. Желательно
    со скриншотами и пояснениями к каждому пункту).
    2. PM: Вовлечь клиента в процесс контроля за соблюдением
    требований при приёмке у сторонних дизайнеров. Объяснить,
    что качество графического материала, прежде всего, влияет
    на чувство доверия и отношения его будущих клиентов (пользователей)
    сайта, а также на качество работы html кодера. (Важно
    различать качественный дизайн и красивый дизайн: это не
    тождественные вещи).

    1.2 Редизайн


    Худший вариант:
    Клиент присылает или сообщает ссылки (что ещё хуже) на
    страницы со свёрстанным дизайном плохого качества (без
    типовых элементов, содержащим проблемы кроссбраузерности,
    невалидный код).
    Хорошая практика:
    Клиент присылает свёрстанный код. HTML кодер, PM и другие
    участники проверяют его качество и наличие необходимых
    элементов.
    Влияние:
    Если факт плохого качества страниц не озвучен перед клиентом
    или PM’ом, то за все вытекающие баги ответственность перекладывается
    на HTML кодера. Тем самым увеличивается время незапланированного
    фиксинга багов.
    В случае со страницами, расположенными в Интернете, прежде
    чем приступить к вёрстке, кодеру необходим этап переподготовки
    для создания сайта локально. Это время следует учесть
    при оценке.
    Пример: Чтобы воссоздать локально сайт, где все
    картинки прописаны в CSS, верстальщику надо отследить
    путь каждой, прописать его в адресной строке, чтобы скопировать
    каждую картинку на локальный диск. Количество прописанных
    в CSS картинок не ограничено.
    Действия:
    1. PM: На этапе выяснения требования подчеркнуть
    важность качества входящего материала и последствия плохого:
    технические (баги, перерасход проектного времени, плохая
    расширяемость) и негативное влияние на чувство доверия
    и отношение будущих клиентов (пользователей).
    2. PM: Просить клиента прислать свёрстанный код
    вместо публикации на сайте (если нет FTP доступа). Это
    позволяет HTML кодеру сразу же работать с кодом «как есть»,
    не занимаясь переподготовкой. Важно отметить, что это
    ещё и позволяет предотвратить тихое добавление клиентом
    новых элементов под видом того же плана работ.
    3. HTML кодер: Известить PM’а о возможных проблемах,
    ошибках и качестве материала. Написать, каких элементов
    не достаёт в новом дизайне. Попросить провести сравнительный
    анализ нового и старого дизайна (выяснить, что меняется,
    что добавляется, что убирается и т. д.).

    2. Требования к вёрстке (DIV, table, смешанная).


    2.1 Вёрстка на дивах


    Худший вариант:
    Проекты с требованием блочной вёрстки (семантическая вёрстка
    с использованием DIV) выполняются кодерами, не имеющими
    необходимого опыта, или используется блочная вёрстка там,
    где она не обоснована.
    Хорошая практика:
    Блочную вёрстку стоит применять в тех местах, где это
    применение обосновано (субъективное мнение), если:
    — необходимо соблюдение стандартов;
    — это единственно-возможный способ реализации;
    — это требования клиента или платформы;
    — это способ уменьшить количество багов у web-developer’oв
    при работе с HTML кодом;
    — необходимо упростить места соприкосновения клиента с
    кодом
    Умение «верстать на дивах» (и править достаточное количество
    нетривиальных багов) требует наличия подобного опыта у
    HTML кодера.
    Менее изящная, но стабильная табличная вёрстка покрывает
    основные запросы к вёрстке в 80% типовых задач.
    Смешанная вёрстка — компромисс и способ вобрать лучшее
    из двух вариантов.
    Влияние:
    Блочная вёрстка привносит вероятность несуществующих при
    табличной вёрстке багов, таких как:
    — неправильный рендер браузером;
    — неправильное или непредсказуемое поведение вёрстки при
    изменении размера окна, шрифта, размера текста и т.д.;
    — сложные баги кроссбраузерности.
    Подобные баги исправляются достаточно сложно, часто с использованием
    хаков и незадокументированных возможностей. Решения не
    всегда кроссбраузерны, расширяемы и надёжны.
    Действия:
    1. PM и HTML кодер: В начале проекта обсудить вопросы,
    касающиеся типа вёрстки.
    2 PM и HTML кодер: Воспользоваться консультантом,
    попросить консультации у коллег.

    2.2 Требуется табличная вёрстка, а исходный материал на
    блочной


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

    Тот же результат (создание практически с нуля, а не переделка),
    если заказчик прислал вёрстку не подходящую для используемой
    платформы.
    Действия:
    1. HTML кодер: Использовать смешанную вёрстку (процесса
    адаптации и багов на стыках двух типов не избежать, однако
    это минимизирует расход времени в сравнении с созданием
    с нуля).
    2. PM: Понимать и учитывать при оценке, что в подобной
    ситуации дизайн не берётся как есть. Конечный результат
    представляет собой симбиоз прошлого решения и клиентского
    варианта. Любое нововведение чревато багами, множащимися
    в геометрической прогрессии.

    3. Знание проекта (структуры папок, элементов, генерирующих
    дизайн).


    Худший вариант:
    HTML кодер не знает проект.
    Хорошая практика:
    HTML кодер знает проект.
    Влияние:
    Незнание проекта приводит к тому, что на разбирательство
    с особенностями реализации системы тратится время, выделенное
    на выполнение самого задания. Следующая статья значительной
    траты времени – баги и недоделки, произошедшие из-за незнания
    системы (неучтённые страницы, разное отображение при разных
    условиях и т.д.).
    Действия:
    1. Рабочий процесс: Изучение используемых платформ
    в свободное от проектов время. Таск на ознакомление с
    системой перед началом проекта. Проведение обязательной
    аттестации на знание системы.
    2. Рабочий процесс: Использовать в проекте консультанта
    с таском «Консультирование» (кроме этого таска он в проекте
    может не участвовать).
    3. PM и HTML кодер: Воспользоваться консультантом,
    попросить консультации у коллег.

    4. Степень зависимости от программно- аппаратной части.


    Худший вариант:
    Высокая зависимость от программно- аппаратной части.
    Хорошая практика:
    Автономная, параллельная работа.
    Влияние:
    Примеры зависимостей, которые отражаются на времени:
    — зависимость от аппаратной части ПК (Photoshop (несколько
    одновременно открытых PSD), Dreamweaver (2-3 окна), TopStyle
    (2-3 открытых файла), проводник (или коммандер), 2-3 открытых
    браузера (FireFox, IE, Opera) и иногда программа для работы
    c PHP – вот вполне типовой пример рабочий области).
    — зависимость от аппаратной части и интернетHTML кодеру
    в работе требуется видеть моментальный результат своих
    действий, т.к. иногда вёрстка строится на предположении
    и результатах того, как ведёт себя дизайн в определенных
    изменяющихся условиях. Время ожидания результата иногда
    превышает время на его создание. Когда, даже чтобы увидеть
    результат самых небольших изменений, необходимо дождаться
    долгой перегрузки всей страницы (а перезагружает страницу
    кодер за проект достаточно много раз).
    — зависимость от действий программиста и программ, связанных
    с рабочим процессом. Несмотря на то, что SVN (и другие
    системы контроля версий) призвана не только сохранить
    код, но и распараллелить разработку, временами приходится
    вместо разработки возиться с обновлением SVN и восстановлением
    работоспособности своего хоста после обновления. Это связано
    с тем, что параллельный разработчик меняет что-то радикальное,
    скрывает или добавляет часть функциональности влияющей
    и на работу HTML кодера.
    Действия:
    1. Рабочий процесс (проектная команда): Обсудить
    влияние друг на друга и исходя из этого предложить порядок
    тасков.
    2. Рабочий процесс: Приемлемые мощности ПК и скорость
    интернет.

    5. Стадия вступления в проект.


    Худший вариант:
    Кодер вступает в проект, когда ещё не готова часть ключевой
    функциональности или часть, влияющая на визуальное отображение.
    Возможны вмешательство или доработки в уже проработанных
    страницах. Остались не выясненными до конца части сайта.
    Хорошая практика:
    Проект проходит таким образом, что кодер и девелопер работают
    либо параллельно, либо кодер после девелопера.
    Влияние:
    Регрессии необоснованно забирают время, которое не может
    быть просчитано в начале.
    Действия:
    1. Рабочий процесс (проектная команда): Обсудить
    влияние друг на друга и исходя из этого предложить порядок
    тасков.
    2. Рабочий процесс: Эффективные коммуникации по
    ходу проекта позволяют избежать регрессий или снизить
    их количество, избежать багов.
    3. PM: Контролирует проект на промежуточных стадиях.
    Отсутствие контроля со стороны PM в ходе проекта выльется
    в регрессии, переделку и аврал в конце. Если в начале
    идёт девелопмент, потом кодинг и натяжка, то перед натяжкой
    следует проверить результаты девелопмента на соответствие
    требованиям спецификации и своим представлениям. Как показала
    практика, отсутствие этого приводит к следующим ситуациям:
    — время на девелопмент израсходовано, и нет возможности
    привлечь ресурс для доработки. Приходится отвлекать занятых
    на другом проекте людей.
    — нормальный процесс HTML кодинга нарушается. Из-за недоработок
    приходиться переделывать и доделывать куски проекта, по
    которым, как казалось, работа завершена.
    — авральная работа, перерасход рабочего времени, баги.

    6. Коммуникации и выяснение возникающих вопросов по ходу
    проекта с участниками проекта.


    Худший вариант:
    Коммуникации затруднены (между клиентом и PM или участниками
    команды).
    Хорошая практика:
    С коммуникациями никаких проблем.
    Влияние:
    Затруднение обсуждения оперативных вопросов ведёт к неоднозначному
    пониманию требований. Если у вас был вопрос, который вы
    решили самостоятельно, и его решение не совпало с видением
    клиента, то это приведёт к переделке => потери проектного
    времени.
    Внутрикомандные коммуникации тоже влияют на процесс. Например,
    использование IM при обсуждении оперативных вопросов часто
    замедляет общение, т. к. некоторые вещи достаточно тяжело
    и долго объяснять, и также приходиться делать это сразу
    с несколькими людьми в нескольких окнах.
    Действия:
    1. Рабочий процесс: Один из неявных примеров улучшения
    коммуникаций — словарь рабочего сленга в Wiki. Новый сотрудник
    без труда может прочитать и понять используемые слова
    из лексикона коллег. Участники проектной команды должны
    проявлять инициативу в улучшении коммуникаций (использовать
    как логические инструменты, так и технические средства).
    2. Рабочий процесс: Для проектной группы лучше использовать
    общий чат, где все участники проекта будут в курсе обсуждения
    проекта.

    7. Условия и ограничения используемой платформы или проекта.


    Худший вариант:
    Проектная команда не знает требований системы или работы
    компонентов, отвечающих за дизайн. Приходится переделывать
    под вновь узнанные требования.
    Хорошая практика:
    Вёрстка учитывает требования системы при натяжке.
    Влияние:
    Появляющиеся новые требования в виде ограничений и условий
    системы приводят к переделкам и адаптации, что влечёт
    трату незапланированного времени.
    Пример 1: Не всегда есть возможность скачать текущую
    версию сайта клиента, поэтому для работы локально приходиться
    вырывать какие-то части и ставить их на локал. Ещё чаще
    приходится делать сначала локально, потом после проверки
    проделывать те же действия на клиенте. Незапланированное
    время — это повтор тех же действий на клиенте и время,
    потраченное на устранение разницы (закачка/скачка на/с
    клиента).
    Пример 2: Open Source сильно подвержен ограничениям
    и условиям. Так в системе OsCommerce содержание категории
    товаров генерируется жёстко в коде, что может повлечь
    не только переделку HTML, но даже переделку PHP.
    Действия:
    1. Рабочий процесс (проектная команда): Обсудить
    узкие места, изучить систему до старта проекта.
    2. PM и HTML кодер: Воспользоваться консультантом,
    попросить консультации у коллег.
    3. Рабочий процесс: Конспектировать решение проблем
    или сами проблемы в Wiki, создавая базу знаний.

    8. Квалификация и опыт. Способность идентифицировать проблему,
    решить и «законспектировать».


    Худший вариант:
    HTML кодер использует нестабильные решения, не заинтересован
    в улучшении качества работы, безразличен ктенденциям и
    техникам.
    Хорошая практика:
    HTML кодер совершенствует технику, интересуется тенденциями.
    Знакомится с чужим опытом и создаёт собственные наработки.
    Влияние:
    Опытный специалист — ключ к решению любой задачи.
    Действия:
    1. Рабочий процесс: Популяризировать пользу базы
    знаний. Культивировать и централизировать материал. Освещать
    и доводить до сведения, вовлекать.
    2. HTML кодер: Использовать прочтённое на практике,
    не боятся экспериментировать, наблюдать результат. Знакомиться
    и изучать смежные области знаний, накапливать и синтезировать
    знания. Предлагать внедрение обкатанных и обдуманных вариантов.
    3. HTML кодер: 70% проблем с которыми сталкиваешься
    в процессе работы уже решал кто-то. Задокументированное
    решение позволит не только не вспоминать судорожно, как
    это решалось в прошлый раз, но и избавить от таких мыслей
    коллег.
    Продолжение следует…
    Источник: Блог о web-разработке
    и способах её улучшения
    Метки:
    Поделиться публикацией
    Комментарии 45
    • 0
      Супер. Только п.1.1 - «Хорошая практика» и «Влияние» посмотрите, что-то они одинаковые
    • +1
      Отличная статья, передам PM для ознакомления
      • 0
        Спасибо.Во второй части описание факторов категорий "Работа PM" и "Рабочий процесс"
      • +1
        Респект, отлично проделанная работа по анализу предмета с простым и понятным структурированием.
        • 0
          имхо табличка маловата
          • 0
            Считаете чего-то не хватает? Тут лежит анкета http://www.amazedev.com/files/anketa.doc пожалуйста заполдните её. Это внесёт вклад в расширение статьи новыми факторами и примерами из Вашего опыта Спасибо.
        • +4
          Спасибо за проделанную работу. С вашего позволения буду ссылатся на некоторые пункты при работе с клиентом.

          Согласен практически со всем. Единтсвенное - выражу свое субъективное мнение по поводу п.2. Правда это уже из разряда холивар - по этому прошу сильно не пинать.

          "необходимо соблюдение стандартов;" - необходимо всегда. Стандарты делались не для того что бы просто быть. Они есть и их необходимо придерживаться. Почему большинство думает что html-coding это нечто, где позволено писать что угодно и как угодно. Почему никто не пишет так например на C++ ?

          "Блочную вёрстку стоит применять в тех местах, где это применение обосновано" - стоит применять всегда. Таблицы для табличных данных.

          "это способ уменьшить количество багов у web-developer’oв при работе с HTML кодом;" - по моему опыту, блочная верстка значительно упрощает жизнь программистам.

          "Менее изящная, но стабильная табличная вёрстка покрывает основные запросы к вёрстке в 80% типовых задач" - по моему личному опыту, большинство типовых задач решается с использованием блочной верстки, и есть лиш несколько моментов где использование таблиц при верстке действительно может быть оправдано.

          "Подобные баги исправляются достаточно сложно, часто с использованием хаков и незадокументированных возможностей. Решения не всегда кроссбраузерны, расширяемы и надёжны." - все приходит с опытом )

          Еще раз спасибо.
          • 0
            Согласен с вами полностью. Почему тогда написал именно так?
            Потому, что не всегда получается выбирать, к сожелению.

            "блочная верстка значительно упрощает жизнь программистам" - золотые слова, только добавлю что фикс багов в ней(блочной вёрстке) для них опять эту жизнь усложняют, если кодера рядом нет :)

            А холивар мне кажется уже закончен в пользу стандартов и блочной вёрстки. Просто кто-то пока не инвестировал своё личное время в изучение.
            • +1
              "...для них опять эту жизнь усложняют, если кодера рядом нет " - согласен, но со своими программерами я всегда рядом. в этом плане им наверное повезло :) мне вот например, значительно усложняет жизнь когда дают править табличную верстку. чесн слово - я бы лучше переверстал все с нуля дивами :(

              "А холивар мне кажется уже закончен в пользу стандартов и блочной вёрстки" - к сожалению это не так. Если бы было так - "жить бы стало проще, жить бы стало веселее". Имею в виду не только кодеров, но и разработчиков ПО (ИЕ 6-7). Соглан, в последнее время ситуация стала немного лучше, об этой проблеме стали больше говорить, но всеже еще далеко до идеала :(
              • –2
                Однако выскажу и своё субъективное мнение, что я согласен с автором статьи. Стандарты нужны тогда, когда они действительно востребованы, но если вы делаете сайт, целевая аудитория которого домохозяйки, слесари, в общем люди не далекие до интернета, сидящие за старенькими компами с windows 98 и IE 5.5, да еще прочитавшие где-нибудь в "умном" издании, что javascript это плохо; css это вообще ужас... там уж не до соблюдения стандартов. Ей богу можно голову сломать, пока добъешься корректного отображения...

                А во-вторых, говоря о стандартах, пока 80% пользователей используют продукцию компании Microsoft и пока для 50% из этих пользователей, Интернет - это нажать левой кнопочкой на "Пуске" и там пунктик "Интернет", нам придется писать верстку для браузеров понимающих стандарты и для ИЕ. Кто-то считает, что этим 50% вообще в интернете делать нечего, однако, ИМХО, наверное они приносят большую часть прибыли в интернет... даже порой своей глупостью..
                • 0
                  Каждый имеет право на свое мнение - но пока таких мнений как ваше будет большинство, ситуация еще долго не изменится в лучшую сторону :(
                  А компания Microsoft со своим детищем ... ну что тут скажеш, с этим нужно боротся всем сообществом.
                  • 0
                    Объясни мне, что ты предлагаешь? Это примерно то же самое, что сейчас всем сказать: "А выбросите как вы нафиг все свои мобильные gsm телефоны и купите 3G"... я не против блочной верстки и стандартов, но при когда я следую только им и не подключаю заднюю мысль о простых пользователях - я сознательно отбрасываю их из разряда своей целевой категории. Хабрахабр было возможно сделать по стандартам, с применением передовых технологий; сайт "Жалюзи для всех" нельзя!
                    • 0
                      "и не подключаю заднюю мысль о простых пользователях" - интересно, у меня это совсем не задняя мысль, а первостепенная. Ведь если сайт сверстан в соотвествии со стандартами, то по идее это должно! значить то что он одинаково будет отображатся в любой программе поддреживающей эти стандраты. Чем не забота о пользователе?
                      "я сознательно отбрасываю их из разряда своей целевой категории" - каким образом соответствующий стандартам сайт может отбросить какую-либо часть целевой аудитории?
                      ""Жалюзи для всех" нельзя!" - "неверю!" (с) даже скажу с больше - можно. Любой сайт можно сверстать валидно, кроссбраузерно. Было бы желание! Другое дело - программная реализация, сдесь сложнее соблюдать стандарты, но тоже не невозможно. И тем неменее, я всегда отдаю программить валидную верстку - и моя совесть чиста :) А IE 5.5 о котором вы вспоминали - не аргумент в вашу пользу.
                      • +1
                        Ну да, хотя бы различное трактование свойства padding, font-size в валидных браузерах и в IE уже не говорят в пользу последнего. Во-вторых, когда это IE поддерживал стандарты? НЕ говорите мне о том, чтобы было бы желание, а все остальное получится, если верстаешь для себя, имеешь неограниченный запас времени и терпения, то возможно вы и правы (не хочу с ходу примеры приводить это опровергающие, сами их найдете). Когда еще плюсом ко всему стоит ограничение по времени и желание поспать - тогда уже не до валидности кода... или вы в момент сдачи кода будете хвастать 30% готовностью проекта, но валидным кодом?

                        В общем, не хочу вас переубеждать, и не пытайся меня переубедить. Я не против стандартов, просто есть компания Microsoft!
                        • 0
                          Присоединяюсь к Вашим словам, когда есть очень ограниченное время, а исходный материал желает лучшего, то стандарты вместе с совестью приходится переступать.

                          Такой вот реальный мир.
                          • 0
                            Прошу прощения за то, что смешиваю "вы" с "ты"... у меня просто как раз один из таких проектов висит, поэтому не слежу за тем что пишу!
                            • +1
                              "Во-вторых, когда это IE поддерживал стандарты?" - думаю что всегда. Не все, часть из них по своему, часть "придумал сам" - но давайте не будем называть IE абсолютно "нестандартным" браузером. Опера и Огнелис тоже по разному смотрят не некоторые вещи! Не в таких масштабах конечно - но тем не менее.
                              "...имеешь неограниченный запас времени и терпения" - вот в чем, загвоздка. В данном случае важно не то, насколько браузер поддерживает стандарты, а то, насколько быстро вы способны решать проблемы возникающие в связи с этим, не отходя от них (стандартов). Свой первый сайт я верстал что-то около месяца, но я только учился (огромное спасибо сайту ZendGarden и Дейву Ши за книгу "Философия CSS-дизайна). Мне безумно понравилась идея изменения дизайна без изменения html кода. И я искал! Гнал от себя желание поспать и делал. И в конце-концов у меня получилось - резиново, кроссбраузерно, валидно! С тех пор прошло 2 года и я продолжаю искать - хотя на верстку у меня теперь уходит гораздо меньше времени.
                              "хвастать 30% готовностью проекта, но валидным кодом" - все приходит с опытом. Прийдет и умение оценивать сроки.
                              "и не пытайся меня переубедить" - я никого не пытаюсь переубедить. У каждого свой путь. И я искренне желаю вам успехов в вашем!

                              P.S. "есть компания Microsoft" - есть, и с этим нужно считаться.
                              • 0
                                ""Во-вторых, когда это IE поддерживал стандарты?" - думаю что всегда. Не все, часть из них по своему, часть "придумал сам" - но давайте не будем называть IE абсолютно "нестандартным" браузером. Опера и Огнелис тоже по разному смотрят не некоторые вещи! Не в таких масштабах конечно - но тем не менее." — стандарт, это ведь как правило — одно для всех, а здесь получается как в России с ПДД, правила писаны для всех, но каждый соблюдает их по своему!

                                "Свой первый сайт я верстал что-то около месяца, но я только учился (огромное спасибо сайту ZendGarden и Дейву Ши за книгу "Философия CSS-дизайна). Мне безумно понравилась идея изменения дизайна без изменения html кода. И я искал! Гнал от себя желание поспать и делал. И в конце-концов у меня получилось - резиново, кроссбраузерно, валидно! С тех пор прошло 2 года и я продолжаю искать - хотя на верстку у меня теперь уходит гораздо меньше времени."
                                Опыта у меня, конечно поменьше... но с одним соглашусь, что начинать надо именно с Дейва Ши... я правда пока не дошел до этой книги (*каюсь*), но она есть в планах.

                                ""хвастать 30% готовностью проекта, но валидным кодом" - все приходит с опытом. Прийдет и умение оценивать сроки." — здесь двояко, все таки есть такая пирамидка: "Дешево" - "Качественно" - "Быстро"... зачастую заказчики выбирают первое и последнее... сидят там твердолобые дядьки, которым объяснять о качестве не имеет смысла, им важно только чтобы было дешево и как можно быстрее...
                                • 0
                                  Олег спасибо за аргументированные коменты мне как новичку очень интересно.
                  • 0
                    Поддерживаю. Пункт 2.1 был бы совершенно правильным года эдак 3 назад, но сейчас это вызывающе неверная информация.
                    • +1
                      Смысл пункта не в том что я поддерживаю кого-то из холивар. Смысл в том,что вёрстка на div'ах следует отдавать опытным людям.

                      Актуальность стандартов и то,что это единственно правильная ветка развития я под сомнения не ставил, как мне кажется.
                      • 0
                        Тогда стоило бы об этом отдельно указать. :) А вообще спасибо.
                  • 0
                    Вы бы хоть в Ворде орфографию проверили. Ей богу, читать тяжело. :(
                    • 0
                      Простите. Проверял и не только в ворде. Буду признателен, если о самых тяжёлых местах сообщите в личку. Спасибо.
                    • 0
                      Факторы *,* влияющие на HTML-верстку.
                    • 0
                      сорь что не в тему.. но).

                      Как можно защитить дизайн от рипа? тобиш чтобы малолетки не содрали диз и не поставили его на свой "мегасайт". Пробовал кодировать путь до Css через яваскрипт, помогло на время, но все равно раскодировали..
                      • +1
                        писать "малолеткам" на email, что если они не сменят дизайн на свой, то придет злой дядя милиционер и накажет их ) другие способы не действенны )))
                        • 0
                          ну вот к примеру сделал я шаблон и продаю по 40уе за копию.

                          а тут найдется малец который сделает рип и выложит нахаляву, и все, бб мои денежки.

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

                          если кто сможет такое реализовать - жду в асе, 111577.
                      • +1
                        Не выкладывать в интернет.
                        • 0
                          между прочим очень верно, инет — среда открытая по сути своей
                      • 0
                        > 2.2 Требуется табличная вёрстка, а исходный материал на блочной
                        Интересные, оказывается, бывают случаи. Как велик и непредсказуем этот мир!
                        • 0
                          семантическая вёрстка с использованием div....используется блочная вёрстка там, где она не обоснована.

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

                          Спорный во многих моментах бриф.
                          • 0
                            Спасибо.
                            Однозначно в избранное.
                            • 0
                              Примеры 1 и 2 в седьмом и восьмом пунктах совпадают. Так задумано?
                              Отличная статья, спасибо.
                              • 0
                                В восьмом лишние, спасибо. После n-ой перечитки уже замылил глаз
                              • 0
                                >Продолжение следует...

                                ждём с нетерпением
                                хорошо бы ещё в оконцовке - Часть последняя: Отдых HTML кодера)
                              • +1
                                как же хочется ткнуть носом дизайнера и других руководителей проекта в некоторые пункты (1 и 5). причем, когда на словах говоришь: мне было бы удобнее так и так, то это просто пропускается мимо ушей... обидно за необоснованную трату времени.
                                • 0
                                  Спасибо за отзыв. Реальность и породила эту статью. Вот тут http://habrahabr.ru/blog/webdev/29893.ht… находится вторая часть "Факторы, влияющие на html вёрстку (Часть 2: Работа PM и Рабочий процесс)"

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.