Что такое хорошо: как мы разрабатывали критерии для оценки качества вёрстки веб-проектов



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

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

    Важность критериев в процессе обучения


    Изначально оценку работ учеников, участвующих в базовых интенсивах HTML Academy, проводил помогающий им наставник (о важности наличия «живого» учителя мы писали в прошлый раз). Для повышения качества этого процесса и снижения вероятности необъективной оценки было решено выработать чёткие критерии, которым должны соответствовать работы.

    Поскольку проверку на соответствие критериям в любом случае осуществляет наставник, то необходимо было сделать так, чтобы этот профессионал был согласен с предлагаемым инструментарием оценки.

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

    В результате мы переработали критерии таким образом, чтобы исключить всякую двусмысленность — все наставники должны одинаково понимать, как именно проверять работы учеников.

    Сбор обратной связи


    Поскольку целью наших интенсивов является подготовка специалистов, которые смогут получить работу в компаниях и будут заняты в реальных проектах, мы решили узнать экспертное мнение представителей веб-студий. В Санкт-Петербурге такие компании объединяет ассоциация СПЕЦИА — к экспертам этих организаций мы и обратились.

    Процессы в разных студиях построены по-разному, что сказывается в том числе на требованиях к вёрстке проектов (пример — кто-то не приемлет стилизацию элементов по id, а где-то — это вполне нормальная практика и т.д.).

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

    Что в итоге получилось


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

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

    Базовые критерии


    1. Выполнена HTML-разметка всех страниц и всех элементов на страницах.
    Ученики должны понимать, что страницы должны быть свёрстаны полностью.

    2. Один стилевой файл на все страницы (с учётом normalize.css можно два).
    Так как мы не рассматриваем автоматизацию, то мы смягчили критерий и разрешили подключать нормалайз отдельным файлом.

    3. Вёрстка идентично отображается в последних версиях браузеров Chrome, Opera, Firefox, Safari, а также в Internet Explorer 10+.
    Да, наш выбор — IE10+. Ученикам мы рассказываем, как отбиваться от вёрстки под более старые версии.

    4. Сайт должен нормально смотреться на минимальном для данного макета разрешении:

    • При большем размере экрана макет должен оставаться по центру и не иметь горизонтального скролла.
    • На экранах, которые меньше ширины макета, вёрстка не должна менять свою структуру.
    Хорошо Плохо
    5. В корне документа должны быть папки css, img, js или аналогичные. Главная страница имеет название index.html. В названиях и расширениях файлов нет заглавных букв и пробелов.
    Хорошо Плохо
    6. Единообразное написание и форматирование кода в HTML, CSS и JavaScript.
    Мы не настаиваем на выборе какого-то определённого стиля кодирования. Главное — единообразие.
    Хорошо Плохо
    <header class="page-header">
      <nav class="main-menu">
        <ul>
          <li class="active">
            <a href="index.html">Главная</a>
          </li>
          <li>
            <a href="contacts.html">Контакты</a>
          </li>
        </ul>
      </nav>
      <div class="login">
        <a href="/login" class="login-button">Вход</a>
      </div>
    </header>
    <header class="page-header">
      <nav class='mainMenu'>
        <ul><li class="active">
            <a href="index.html">Главная</a>
          </li>
          <li>
            <a href="contacts.html">Контакты</a>
          </li>
        </ul>
    </nav>
    
        <div class='logIn'>
          <a class="login_button" href="/login">Вход</a>
      </div>
    </header>
    7. Грубые ошибки в разметке отсутствуют. Например:

    • Ссылки сделаны не тегом <a>, а другими тегами.
    • Использование строчных элементов для создания крупных (сеточных) блоков.
    • Абзацы должны быть абзацами, а не <br><br>.
    Этот критерий самый субъективный, так как есть много спорных, но приемлемых вариантов разметки элементов. Но есть и «абсолютное зло», которое в код допускать не хочется. Будем рады вашим примерам таких типовых ошибок.

    8. Нельзя строить сетку с помощью таблиц и позиционирования.
    Не с помощью display: table, а именно с помощью таблиц.

    9. Нельзя использовать !important в CSS.

    10. При наполнении контентом как на макете элементы каждой страницы должны соответствовать макету:

    • Допускаются различия в 5 пикселей по высоте и 2 пикселя по ширине.
    • Допускаются отсутствия стилизации кастомных элементов форм.
    • Допускаются различия в отображении шрифтов, связанные со сглаживанием на различных платформах.
    • Должны быть подключены правильные шрифты, а их размеры и толщина должны соответствовать размерам в макетах и ТЗ.
    Критерии соответствия макету сделали мягче, чем полный «пиксельпёрфект». А как вы считаете правильным?

    11. Выбран правильный формат изображений:

    • JPEG для фотографий.
    • Всё остальное в PNG.

    12. Документ должен проходить проверку на валидность.

    Дополнительные критерии


    1. Нельзя использовать транслит в названиях классов, атрибутах и так далее.
    Хорошо Плохо
    .login-button { ... }
    .container { ... }
    .footer { ... }
    .knopka-vhoda { ... }
    .kontainer { ... }
    .podval { ... }
    2. Нельзя использовать #id для стилизации.

    3. Нельзя использовать вложенность селекторов больше двух.

    4. Использован normalize.css.

    5. Необходимо явно указать подходящее vertical-align для всех блоков с display: inline-block.

    6. Необходимо указать альтернативные варианты шрифта и тип семейства в конце перечисления.

    7. Необходимо расположить CSS-префиксы в правильном порядке.

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


    Но если аккуратно прописать цвет фона блокам, то отсутствие изображений не страшно.


    9. Необходимо, чтобы все состояния элементов из styleguide.psd были использованы.
    Конечно, не все дизайнеры делают такие стайлгайды, но для учебных макетов мы их подготовили, чтобы ученики привыкали задумываться о стилизации разных состояний. Ниже фрагмент стайлгайда одного из макетов.


    10. Необходимо, чтобы при взаимодействии с элементами (наведение, нажатие) ни сам элемент, ни окружающие его блоки не меняли своего положения.
    Ничего не должно «прыгать» просто так.

    11. Необходимо использовать:

    • Спрайты для изображений или иконочный шрифт.
    • Минимизировать CSS-код.
    • Минимизировать JavaScript-код.
    Мы рассказываем про простейшие приёмы оптимизации вёрстки и хотим, чтобы ученики их начали использовать.

    12. Необходимо у всех изображений в теге <img> прописать размер.

    13. Вёрстка проходит тест на переполнение контентом. Вёрстка не ломается:

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


    В этом случае при добавлении пунктов должен увеличиваться по высоте блок меню. Может быть это и некрасиво, зато пункты меню видны всегда.


    14. Необходимо подключить все скрипты непосредственно перед </body>.

    15. Необходимо использовать минимально возможное количество элементов HTML.
    Это тоже субъективный пункт, поэтому и вынесен в дополнительные критерии. С его помощью мы заставляем учеников, например, использовать псевдоэлементы для создания декоративных деталей.

    16. Необходимо использовать подход Progressive Enhancement, например:

    • Кнопки, вызывающие появление попапов, по умолчанию являются ссылками, которые ведут на отдельные страницы.
    • Интерактивная карта без JavaScript показывает статичную картинку с картой.

    Что можно улучшить: мнения профессионалов


    Поскольку цель наших интенсивов — подготовка специалистов, которые могли бы работать над реальными веб-проектами, мы решили собрать мнения экспертов о каждом пункте критериев, вошедших в окончательный список для оценки качества вёрстки.

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

    В их числе партнёр digital-агентства Little Big Agency Максим Юрин:
    Хороший и полный список, советую всем специалистам пробегаться по всем его пунктам перед сдачей проекта. Это позволит добиться того, чтобы проект выглядел аккуратно внешне, а также, что немаловажно, сделает сам код удобным для прочтения и разбора.

    Кто-то, как например, технический директор digital-агентства Molinos Евгений Сергеев, считает представленные выше критерии в целом адекватными, но некоторые корректировки не помешают:
    Думаю, для начинающих список вполне адекватен, в нём много важных моментов. Конечно, его можно дополнять.

    Новые критерии с ходу не предложу, но, например, я бы перенёс два критерия из дополнительных в базовые.

    Необходимо указать альтернативные варианты шрифта и тип семейства в конце перечисления.
    Вёрстка проходит тест на переполнение контентом. Вёрстка не ломается:

    • При добавлении в элементы большего количества текста.
    • При использовании картинок с неподходящими размерами.
    • Текст не должен выпадать из объектов.
    • Переполнение контентными блоками не приводит к нарушению сетки.

    Особенно второй. Часто совсем об этом не задумываются.

    Мнение разработчика Redmadrobot Дмитрия Шашлова:
    Список адекватен, по нему можно проверить скорее качество усвоения материала, а чтобы оценить общие знания, их качество безотносительно к курсу Академии, критерии лучше сформулировать следующим образом:

    • Вёрстка должна быть максимально понятной как для верстальщика, так и для разработчика, не в ущерб стандартам и общепринятым правилам форматирования страниц;
    • То же относится и к файловой структуре для макетов, чтобы можно было судить о содержании папки по её названию;
    • Задавая параметры адаптивной вёрстки нужно иметь ввиду все возможные размеры экранов, описанные в требованиях;
    • Стоит относиться с отдельным вниманием ко всем ресурсам, поставляемым в релизную вёрстку (cкрипты, стили, изображения — всё должно быть подготовлено для веба).

    Есть и эксперты, считающие, что некоторые моменты можно улучшить или изменить. Ниже представлены комментарии и рекомендации Вадима Макеева, веб-евангелиста Opera Software и основателя сообщества Веб-стандарты:
    > Допускаются различия в 5 пикселей по высоте и 2 пикселя по ширине
    Указывать такие вещи в пикселях, значит провоцировать нездоровую дотошность, которая в реальном мире не нужна. Достаточно сказать «максимально близко к макету».

    > Документ должен проходить проверку на валидность validator.w3.org
    Я бы лучше рекомендовал validator.w3.org/nu — он меньше фокусируется на формальной валидности.

    > Выбран правильный формат изображений: JPEG для фотографий, всё остальное в PNG
    Нет «правильного» формата, есть только «подходящий» и здесь вполне можно упомянуть SVG.

    > Необходимо подключить normalize.css к вёрстке отдельным файлом
    normalize.css или reset.css, оба подхода имеют право на жизнь.

    > Необходимо указать альтернативные варианты шрифта и тип семейства в конце перечисления
    Это больше, чем дополнительный критерий, я бы перенёс в основные.

    > Необходимо расположить CSS-префиксы в правильном порядке
    Такое требование запутывает, нет «правильного» порядка для префиксов, есть один принцип: свойство без префикса а) должно быть, б) должно идти последним.

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

    > Необходимо использовать подход Progressive Enhancement, например
    Форма с кнопкой, интерактивная карта — какие-то не очень внятные и ненужные частности. Лучше сформулировать: важные функции сайта должны работать без JS, точка. Ну и «прогрессивное улучшение».

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

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

    Подписывайтесь на наш блог и становитесь нашим наставником!
    HTML Academy 142,36
    Интерактивные онлайн-курсы
    Поделиться публикацией

    Вакансии компании HTML Academy

    Комментарии 47
    • 0
      С таким набором поддерживаемых браузеров можно еще и использование Flexbox добавить. В качестве прогрессивного улучшения, например.
      • 0
        Мы на продвинутом интенсиве это сделаем. Эти критерии для базового — там флексбоксы не разбираем, поэтому не добавили в критерии.
        • 0
          Давно хотел узнать почему такое странное отношение к флексбоксам — все постоянно говорят, что это не для новичков? И выходит что прогрессивный простой интуитивно понятный механизм отодвигается как нечто сложное, а новичкам захломляют мозг этим адом инлайнблоков и флоатов место которым где-нибудь на свалке истории.
          • 0
            Любой новичёк может попасть в «группу поддержки» старого проекта, где о IE6 ещё не забыли, и без понимания того как работают float, inline-block он ничего не сделает.
            Flexbox — это магия, он просто работает, и вы не получите используя его (на начальном уровне) представления о том, что представляет из себя веб страница на самом деле, например если говорить о таких вещах как «поток», да и CSS в полной мере вы не поймёте и не начнёте его использовать на 100% без знания основ.
      • 0
        Спасибо! Полезно при работе с фрилансом, как список требований и проверочный список.

        Насчет «основное должно работать без JS», признаюсь каждый раз задумываюсь. Сложно представить устройство пользователя, на котором выключен JS. Соцсети некоторые синие без него просто не открываются. Я согласен, что если что-то не сработает на сайте компании из-за выключенного JS — это потеря клиента. Но маниакально все все делать/проверять в двух варианта с- без- JS — тоже вопрос.

        Наверно, тут нет общего правила.
        • 0
          Общего правила определенно нет. Но опять же, делать «основное должно работать без JS» применимо далеко не к каждому проекту.
          • +2
            Тут явно решает вышестоящая шизофрения. Поскольку это все субъективно, якобы нет js потеря клиента. Да уж фактор так фактор) Вот почему клиенты то уходят) По мне это одна из сотен мелочей, которые можно бесконечно дорабатывать и предполагать заместо статистики, которую собрать почти невозможно. Каким образом может быть отключен JS? ну ну как? Плагин стоит? Вирус? Старая или сломанная аппаратура? Ну клиент значит нищеброд, а это не клиент тогда. Наоборот — в плюс.

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

            Почему нельзя начинать рассуждения о факторе потери клиентов с вероятности ошибок в усложении техническим систем. Чем проще система, тем проще с ней работать тем меньше ошибок она вероятно породит. Чем сложнее система (не значит удобнее клиенту), тем больше времени на нее нужно и как следствие инертность реализации нового сервиса(услуги) увеличивается, а значит клиент ждет. К дизайну практически нет возражений — субъективно нравится начальству — в проект. Тайна привлечения клиентов нарисована, осталось разработчикам не поломать ее.

            Ответом тут будет только возможность сотрудника уделять свое время на мелочи все свое рабочее время. И потом он может троллить коллег, дескать ленятся.)) Мне кажется это таится в личном ощущении «хорошо сделанной работы» вот есть миллион факторов которые вы видите, и выполняя 3 года часть в 600 тысяч, сегодня ощущаете их уже как 10 и вам нужна новая рутина для ощущения «хорошо выполненной работы». А если вы делаете множество вещей, особенно разговор с клиентом который может просто вырубить на сутки голову, вам эти 600 000 как весь миллион…

          • 0
            Общее правило есть. Если базовый функционал может работать без JS, он должен работать без JS. Если контент может быть доступен без JS, то он должен быть доступен без JS. В 90% случаев такая реализация совсем не трудоёмка. Но есть две тонкости:

            1. Если JS являются неотъемлемой частью базового функционала (те же Яндекс.Карты), то, конечно, без JS ничего работать не будет. И тут париться не надо.

            2. Насколько стоит усложнять базовый функционал, чтобы он был похож на версию c JS. Здесь все тонкости. Пример: магазин пиццы. В нём есть конструктор пиццы на JS (размер, тесто, добавки, пересчет цены и т.д.). Без JS на месте конструктора обычное текстовое поле, куда пользователь впишет «мне маргариту с двойным сыром». Сложно такой базовый функционал сначала реализовать, а затем его расширить на JS?
            • 0
              Да какая потеря клиента, маловероятно.
              Кто может отключить JS, тот может и включить его.
              У всех остальных он есть.
            • 0
              Очень крутая статья! Спасибо!
              > Спрайты для изображений или иконочный шрифт
              Слишком сложное и сомнительное требование, особенно насчёт иконочных шрифтов — очень сомнительная технология
              Уже год используем иконочный шрифт и не разу не пожалели.
              А все началось с того, что дизайнеру не нравилось как выглядят иконки на ретина дисплеях.
              • 0
                А вы специально подготовленный для ретины шрифт используете или свой? Говорят, бывают небольшие проблемы с отображением на ретине.
                • 0
                  По началу думали свой шрифт создать, а потом решили использовать готовый сервис для генерации набора иконок (fontastic) на выходе получаем шрифт в разных форматах + файл css для подключения. Провели много тестов. Все современные браузеры отлично все отображают в том числе и мобильные.
                  • 0
                    Смотрел видео с конференции где Вадим Макеев упоминал об иконочных шрифтах, с его слов проблем несколько: отображение в браузерах (в т.ч. на разных ОС) может отличаться, в opera mini такие пиктограммы не отображаются вовсе.
                    • 0
                      Но какой процент пользователей используют оперу мини? Посмотрев на разных сайтах я пришел к цифре что это меньше 1 процента пользователей. А дальше уж вам решать стоит ли поддерживать их или нет.
              • +1
                Спасибо.
                Очень хорошая статья :)
                • 0
                  Отличная статья — буду стараться придерживаться этих критериев.
                  Один вопрос — в разработке своего сайта вы их придерживались сами?
                  • –1
                    Конечно же, нет. Ведь это прототип. Когда будет полноценная версия сайта, то все наши критерии будут учтены.
                  • 0
                    Да, наш выбор — IE10+. Ученикам мы рассказываем, как отбиваться от вёрстки под более старые версии.

                    Если можно, вкратце. Как отбиваться?
                    • 0
                      Циферками, договором
                      • 0
                        Циферками, договором

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

                        Я думал, может есть какие-то другие адекватные методы отбиться от старых версий IE.
                        • 0
                          Не сделает. Потому что когда этот Вася родился, у IE6 появились первые конкуренты. И он даже не знает, где его взять.
                          Договор подходит для любых товарно-денежных отношений, что между физическими, что между юридическими лицами.
                          Ну и да, повальное увлечение IE6 корпоративными клиентами — миф. Пять лет назад открылись под своей вывеской, ни одного случая оптимизации под IE6. Даже не спрашивали. Номинально, почти без хаков, только с html5.js ничего никуда не уезжает в IE8+ — я и не тестирую в нем, что бы не делал — ничего не уезжает. Единственное, что уголки не закругляются и тени не видно. Как их делать в IE9- я, разумеется, знаю, но это никому не нужно
                          • 0
                            Про IE6, это я так просто сказал, для примера. На самом деле да, никому это уже не надо.
                            Но меня интересовал вопрос по фразе из статьи. Чтобы именно IE10+ и не старее. Чтобы Флексбокс можно было использовать. Вот тут какие доводы для клиента могут быть? Я, например, ничего не могу придумать, кроме как: «Мне так удобнее, новая технология позиционирования и пр.». Но заказчику плевать на эти наши флексбоксы и наше удобство.

                            А договор, это только при личной встрече, что для фрилансера может быть проблемой.
                            • 0
                              В-общем и целом, скажу, что пока не готов перейти на flexbox. Все костыли, которые есть — не отличаются ни удобством, ни 100% поддержкой. Подождите пару годиков — Windows 10 будет бесплатная, и постепенно переползут на нее все, но пока рано. Я думаю, к 2022 году.

                              При общении с клиентом лучше речь от первого лица забыть, можно играть только на сравнении с конкурентами, но не на своем мнении, они-то думают, раз они деньги платят — они не вас послушать пришли за свои деньги. Заказчику действтельно плевать, на то удобно вам или нет. А пока я не юзаю флексы, бонусом получая ie8+ без вообще каких-либо трудозатрат — заказчик придет не к вам, хотя я очень давно не студент, помню html 2.01 и раньше наизусть мог написать behavior для png в ie :) Желание написать все свое, использовать передовые библиотеки и функции и т.д. показывает верстальщика/программиста/кого угодно — джуниора. Не человека, который понимает, сколько геморроев огребет в процессе использования в бизнес-процессе какой-то неоткатанной технологии. А для экспериментов можно завести блог(никто не читает), гитхаб(4 закачки) и все такое :)

                              По поводу договора — лучше бы, чтобы он был. Вы не поверите, но даже если вы выступаете как физические лица с обоих сторон — достаточно лишь обоим распечатать договор, поставить свою подпись и отправить друг другу по бумажной почте. Проще не бывает. Как показывает практика, опять же, пункт про поддерживаемые браузеры не читает никто. Кстати, в судах переписку в почте тоже принимают.
                              • 0
                                Мне тоже приходится на реальных проектах, в большинстве случаев, отказываться от Флексбокса. Именно из-за желаемой поддержки IE8 или 9. Но, что касается необкатанности и костылей, то не согласен. Вполне все адекватно работает. Префиксы не забывать просто и все. Разумеется, это пока не для больших проектов. Но для среднестатистического лендинга вполне подходит.

                                По поводу почты. Побойтесь Бога, какая почта? Грубо говоря, на FL или Фрилансим заказ на верстку лендинга за 3–4 тысячи, дедлайн вчера. Ну и какие тут договора и почта. Электронная еще может быть.
                                Все таки вы, вероятно, имеете в виду более серьезные проекты «под ключ», со сроком сдачи не меньше месяца.
                          • 0
                            Можно подумать, что это заказчики такие прям дураки.
                            Да заказчики просто смотрят статистику и видят, что ие 8 и 9 все еще дорого игнорировать.
                            • 0
                              Я это все понимаю. Вот поэтому у меня и возник вопрос, как это они учат «отбиваться от вёрстки под более старые версии»?
                              Мало ли, может гипноз какой используют… (шутка).
                      • +1
                        Нет адаптивности, БЭМ, SVG, Flexbox, оптимизации скорости загрузки. Зато при таких-то требованиях к браузерам ещё есть префиксы. От рекомендаций несёт ветхостью, они были актуальны лет пять назад. После таких рекомендаций встречаешь самые натуральные таблицы, свёрстанные через display: table, и PNG-картинки в мегабайт размером. Хорошо, что разбираются основы, но этого явно недосточно
                        • 0
                          Это критерии для базового интенсива, мы в них не включаем то, что на базовом не разбираем. А вот на продвинутом расширим критерии, добавив адаптивность, БЭМ, SVG, Flexbox, оптимизацию.

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

                          Будем признательны, если вы напишете, какие критерии уже не актуальны, мы их переработаем.
                        • 0
                          Смущает несколько моментов.

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

                          Почему нигде не упоминается о гифах, которые тоже имеют право на жизнь.

                          Давайте посмотрим правде в глаза — Стайлгайд — это миф =)) Он практически всегда бывает, если разработка ведётся над одним проектом, но если же это поток сайтов, которые требуется верстать, то его можно увидеть в одном из десятка сайтов.

                          Так же не встретил ничего касаемо — доктайпа, мета, медиакверис.
                          • 0
                            Если у вас ресет такой
                            *{margin:0; border:none; padding:0....}
                            


                            То разумеется, от такого боль будет не только в голове
                            • 0
                              Какой то странный комментарий… Лучше бы ничего не писали. Речь шла о нормалайзе, о нём я и написал.
                              • 0
                                К чему такая принципиальность и требование к использованию нормалайза, либо резета?
                                • 0
                                  Кажется вам просто скучно и нечего делать, и вы спамите абсолютно всем комментариями, при чём по делу и без.
                                  • 0
                                    Отвечу развернуто — reset и ему подобные техники, неважно, самописные они или нет, просто добавляют немного адекватности там, где она должна быть. Самая простая проверка верски на пригодность — это найти форму на сайте и попробовать в нее написать что-нибудь, а там в одностроковых полях вода шрифт один, в больших полях другой, на кнопке — третий, и не совпадающий с основным шрифтом страницы — это частный случай, но reset с помощью одного правила убирает даже необходимость проверять на такие мелкие ошибки, он и содержит кучку частных случаев, только и всего
                                    • 0
                                      Нет уж извиняйте, разница довольно таки большая между «самописными или нет». Одно дело — когда вы не знаете как привести стили сайта к кроссбраузерному виду и слепо лепите целый reset.css файл. Другое дело, когда вы знаете тонкости поведения того или иного тэга, можно основу взять даже ваш пример, где можно обойтись простым input, textarea, button { font-family: Arial;}, а не подключать целый css ради этого…

                                      И я думаю, что любой продвинутый верстальщик (фронтэндер) с опытом составляет свой шаблон для старта вёрстки, в котором прописаны корректировочные стили.
                                      • 0
                                        И я думаю, что любой продвинутый верстальщик (фронтэндер) с опытом составляет свой шаблон для старта вёрстки, в котором прописаны корректировочные стили.


                                        То есть свой собственный фреймворк, в который входит самописный reset. Я не вижу предмета спора.
                                        Кстати, ваше решение примера — не универсальное. Целый отдельный CSS и получается из-за того, что подобных решений там не одно. А разделение на файлы просто удобнее — их же, в-конце концов, можно склеивать и сжимать. Использование Normalize с github также вполне оправданно, если, например, над проектом или несколькими работает не один человек с большой частью унифицированного кода, некой внутренней библиотеки элементов.
                                        • 0
                                          Разделение на файлы — отдельная холиварная тема, за сим откланиваюсь.
                          • 0
                            1/4 от текста — набор мифов.
                            Сильно не вычитываю, на вскидку, попробуем оценить некоторые перлы:

                            >Один стилевой файл на все страницы
                            Жесть. Вы при обучении не рассказывает о препроцессорах, сбрщиках CSS и всех заставляете все топтать в 1 пузатый CSS файл?

                            >… как отбиваться от вёрстки под более старые версии.
                            Корпоративные клиенты всем расскажут как отбиться от вас…

                            >Ссылки сделаны не тегом , а другими тегами.
                            Простите, а каким ещё тегом можно сделать ссылки?

                            >Нельзя использовать !important в CSS.
                            В ООН и W3 консорциуме стоит его вообще запретить, навсегда

                            >Необходимо подключить все скрипты непосредственно перед .
                            Жесткач… А все ли и обязательно до body?

                            • 0
                              Нельзя использовать !important в CSS.

                              meiert.com/en/blog/20150310/important/
                              • 0
                                Если бы было нельзя или не нужно — его бы не было. В-прочем, используется оно настолько редко, что подобные комментарии унылы до безобразия. Кто-то берется подсчитывать точное количество вхождений этого правила в популярных фреймворках, писать всякие статьи о том, что они вот дескать придумали некий другой взгляд на CSS и т.д. Я думаю, у людей, которые могут вести обсуждения этого пункта (или любого другого, но не менее ультимативно) — очень много свободного времени
                              • 0
                                «Абзацы должны быть абзацами, а не <br><br>.» Я тоже так считаю, но почему все посты на хабре отбырбырены?
                                • 0
                                  FYI Критерии качества, связанные с Section 508 [1], могут оказаться весьма полезными даже, если к Веб-сайту и не предъявляются повышенные требования для обеспечения возможности взаимодействия с людьми с ограниченными возможностями. Например, отдельные критерии из этого списка [2] могут весьма положительно повлиять на качество большинства Веб-сайтов.

                                  [1] en.wikipedia.org/wiki/Section_508_Amendment_to_the_Rehabilitation_Act_of_1973
                                  [2] webaim.org/standards/508/checklist
                                  • 0
                                    > Допускаются различия в 5 пикселей по высоте и 2 пикселя по ширине.
                                    в реальной жизни дело приходится иметь как правило скорее с набросками, без особо дотошного выравниванивания по сетке, странной высоты строки и прочих прелестей. Когда начинаешь такое верстать ты либо пытаешься причесать все косяки дизайнера и внести какую-то логику в код, либо запиливаешь все сомнительные места в пикселях.

                                    Второй подход это то, от чего нужно сразу избавляться.
                                    • +1
                                      Нельзя использовать вложенность селекторов больше двух.

                                      Как по мне, это странное ограничение. Лучше пусть будет множество вложений, но часто используемые слова не должны быть классами первого уровня. Как то .right, .left или .hidden весьма чётко ограничены и не должны быть трактованы иначе, кроме
                                      float:left, float:right, display:none
                                      
                                      А, например, селекторы типа ul, ol, li не должны изменяться, кроме как классами, либо селекторами большой вложенности
                                      ul.mymenu>li>ul>li { }
                                      
                                      для под-меню второго уровня.
                                      • 0
                                        Правила, в-целом, понятные и адекватные. Ну плюс-минус километр личных предпочтений…
                                        Вот что глаз резануло — это дизайн полей форм, чекбоксов и радио в приведенном макете. На этом месте хотелось бы поподробнее — какие инструменты для этого юзаются
                                        • 0
                                          1. Мы разрешаем их не стилизовать. И запрещаем стилизовать селекты (хотя их в макетах нет)

                                          2. Для радио и чекбоксов — приём с :checked ~ label
                                        • 0
                                          Всё остальное в PNG.

                                          SVG умышленно или случайно не указан?

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

                                          Самое читаемое