17.05.2023 21:37
KrisWis 11 12000 Источник

В данном репозитории собраны 30 советов для новичков во FrontEnd сфере, которые возможно сделают ваш код чище и приятнее. Все советы постарался написать понятным языком, чтобы даже самый зелёный новичок всё понял :)

Правила введения кода для HTML

  1. В заголовке тега article должен использоваться тег h1. Его можно использовать сколько угодно раз, как и все "h" теги. h2 нужен для заголовков или подзаголовков. Теги h3 и h4 нужны для названия рубрик и тд в sidebar. А h5 и h6 нужны для мелких элементов страницы, которые нужно отделить от остального текста.

  2. Не указывать протокол "http:" в ссылках на внешние элементы.

  3. details и summary используются для разметки сворачиваемого раздела содержимого. Тег summary используется для выделения заголовка раздела, а тег details используется для выделения самого содержимого.

  4. Семантический тег mark используется для выделения текста, который был выделен по какой-либо причине.

  5. Теги div и span не являются семантическими тегами, поэтому нужно стараться их не использовать.

  6. Не указывать атрибут "type" при подключении стилей и скриптов.

Правила введения кода для CSS

  1. Надо избегать селекторов, которые являются или включают в себя html теги.

  2. По возможности писать сокращённые записи свойств (например, вместо padding-left, padding-top и тд, писать значения в padding).

  3. Не указывать единицы измерений для нулевых значений (например, вместо margin: 0px, нужно писать margin: 0).

  4. Не ставить 0 в целой части в значениях между -1 и 1 (т.е, вместо, например, 0.5em, писать .5em).

  5. Не использовать кавычки в ссылках.

  6. Сортировать объявления в CSS по алфавиту.

  7. Стараться использовать BEM для CSS.

Правила введения кода для HTML и CSS

  1. Всегда использовать 2 пробела для отступов.

  2. По возможности пояснять свой код комментариями.

Доступность:

  1. Сделать элементы видео доступными для людей с ограниченными возможностями.

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

  3. Для пользователей экранной лупы есть 3 правила для контента, который появляется при наведении:

    1. Контент можно отклонить без перемещения фокуса или курсора (например, с помощью Esc).

    2. Курсор можно перевести с кнопки на появляющийся контент и при этом он не исчезает.

    3. Появляющийся дополнительный контент остаётся видимым, пока фокус или курсор не убрали с кнопки или дополнительного контента либо пока пользователь не отклонит контент клавишей Esc.

  4. Атрибут Aria-label помогает присвоить элементу заголовок, который видим исключительно программам чтения с экрана. Атрибут Aria-labelledby позволяет сделать так, чтобы скринридер при фокусе на элемент читал другое видимое название или заголовок.

  5. Aria-describedby позволяет предоставить дополнительную информацию для скринридера к имеющемуся видимому заголовку.

  6. Aria-disabled позволяет включить неактивный элемент в порядок следования фокуса. Значит, для пользователя со скринридера этот элемент как бы не будет существовать.

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

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

  9. Чтобы посмотреть то, как элемент должен ввести себя при работе с клавиатуры, стоит посмотреть раздел ‘Design Patterns and Widgets’.

  10. Стоит указывать основной язык каждой страницы, используя, например, lang атрибут в html lang="en".Нужно использовать lang атрибут для определённых элементов, когда язык элемента отличается от остальной части страницы.

  11. Роли WAI-ARIA могут придать дополнительный смысл коду, например, используя role="search" для определения функциональности поиска.

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

  13. Стоит убедиться, что порядок элементов в коде соответствует логическому порядку представленной информации. Один из способов проверить это - удалить стиль CSS и убедиться, что порядок содержимого имеет смысл.

  14. Следует использовать отзывчиво-адаптивный дизайн сайта.

  15. Используйте WAI-ARIA для предоставления информации о функциях и состоянии пользовательских виджетов, таких как аккордеоны и кнопки, изготовленные на заказ. Например, role="navigation" и aria-expanded="true" (aria-expanded устанавливается для элемента, чтобы указать, развёрнут элемент управления или свёрнут, и отображаются ли контролируемые элементы или скрыты).

Комментарии (11)


  1. Filyushin
    18.05.2023 02:24
    #25558806

    В данном репозитории собраны 30 советов для новичков во FrontEnd сфере, которые возможно сделают ваш код чище и приятнее.

    Репозитории на гитхабе? Сделайте ссылку


  1. Wyse
    18.05.2023 02:24
    #25558870
    -1

    Должен быть 0 пункт:
    "Если у вас верстка исключительно на DIVaх - сменить род деятельности".
    Интереса ради смотрел код у разработчиков, которые достаточно долго фрилансят. И у них верстка чисто на дивах, Альты пустые. И так далее. А я сижу до сих пор капаюсь сам в себе))

    Ну и в целом то тут в общем то описан верстальщик больше чем какой то FrontEnd программист


  1. teilarerJs
    18.05.2023 02:24
    #25558872
    +2

    11.Сортировать объявления в CSS по алфавиту.

    Так делать не надо. Один из вариантов, как надо: https://learn.javascript.ru/css-format.


    1. ScorpAL
      18.05.2023 02:24
      #25561776

      Оставлю тут https://github.com/kutsan/stylelint-config-clean-order


  1. dopusteam
    18.05.2023 02:24
    #25558916
    +15

    Всегда использовать 2 пробела для отступов

    Почему?

    Сортировать объявления в CSS по алфавиту

    Зачем? Учитывая то, что порядок объявления напрямую влияет на порядок применения

    Стараться использовать BEM для CSS

    Зачем?

    И так далее

    Ужасная "статья", никакой аргументации, просто куча сомнительного качества "советов"


  1. YAZART
    18.05.2023 02:24
    #25559110
    +2

    Похоже на сбор комментариев с код-ревью и все только по верстке, а что насчет js?


  1. Metotron0
    18.05.2023 02:24
    #25559544
    +2

    Доступностью тегов video озаботились, а доступностью кода — нет. Если мне не комфортно видеть отступ в два пробела, что мне делать с кодом? Ширину таба хотя бы можно настраивать по вкусу, можно хоть в один пробел сделать.

    Я знаю хоткей на преобразование отступов, но потом перед коммитом обратно конвертировать?

    Я SCSS пишу в порядке появления элементов в коде. Зачем по алфавиту? Если для быстроты поиска, то быстрее нажать хоткей поиска текста.


  1. wertex15
    18.05.2023 02:24
    #25562334

    Следует использовать отзывчиво-адаптивный дизайн сайта.

    Это как?


  1. arokettu
    18.05.2023 02:24
    #25564294

    Не ставить 0 в целой части в значениях между -1 и 1 (т.е, вместо, например, 0.5em, писать .5em).

    Убивает читаемость. Зачем?


    1. Metotron0
      18.05.2023 02:24
      #25565812

      Видимо, это экономия 10 байтов на 10 кб. Но тогда логично писать весь CSS в одну строку, без пробелов около скобок. Странно, что человек не пользуется минификатором.


  1. alexnozer
    18.05.2023 02:24
    #25565760
    +1

    Много вредных советов, не соответствующих действительности.

    В заголовке тега article должен использоваться тег h1

    article - автономная единица контента. Карточка товара, новости, услуги. Как правило, такие элементы лежат внутри какого-то структурного раздела, а значит там уже не h1.

    Его можно использовать сколько угодно раз, как и все "h" теги.

    h1 должен быть один на странице. Множественные h1 были частью экспериментального алгоритма outline, который нигде не реализован и около года назад был удалён из спецификации.

    h2 нужен для заголовков или подзаголовков. Теги h3 и h4 нужны для названия рубрик и тд в sidebar. А h5 и h6 нужны для мелких элементов страницы, которые нужно отделить от остального текста.

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

    h2 нужен для заголовков или подзаголовков.

    Для подзаголовков рекомендуется использовать сочетание подходящего по иерархии h*, p и hgroup.

    А h5 и h6 нужны для мелких элементов страницы, которые нужно отделить от остального текста.

    Для мелкого поясняющего текста есть элемент small.

    Теги div и span не являются семантическими тегами, поэтому нужно стараться их не использовать.

    Все элементы HTML являются семантическими, так как их семантика (смысл и назначение) определена спецификацией. div это generic элемент для группировки потоковых элементов с целью стилизации, скриптинга или раскладки. span это generic элемент для выделения фрагментов фразового содержимого с целью стилизации, скриптинга или раскладки.

    Не указывать атрибут "type" при подключении стилей и скриптов.

    type="module" нужен для работы нативных ES-модулей, type="application/json" если необходимо хранить json в разметке, type="text/html" для хранения кусков разметки и тд.

    Надо избегать селекторов, которые являются или включают в себя html теги.

    Они полезны при описании reset-стилей.

    По возможности писать сокращённые записи свойств (например, вместо padding-left, padding-top и тд, писать значения в padding).

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

    Не указывать единицы измерений для нулевых значений; Не ставить 0 в целой части в значениях между -1 и 1;

    Не использовать кавычки в ссылках.

    Это работа инструментов - линтеров и минификаторов. Главное - чтобы на проекте был один консистентный подход.

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

    Для обеспечения доступности с клавиатуры нужно использовать кнопки и ссылки вместо дивов, не отключать outline, не менять физический и визуальный порядок, создавать focus-trap в модальных компонентах и делать кастомные интерактивные виджет в соответствии с рекомендациями WAI-ARIA AGP. Атрибут tabindex нужен только при создании кастомных виджетов.

    Aria-describedby позволяет предоставить дополнительную информацию для скринридера к имеющемуся видимому заголовку

    И к невидимому тоже. И даже если заголовок, под которым имеется ввиду accessible name, не задан вовсе.

    Aria-disabled позволяет включить неактивный элемент в порядок следования фокуса. Значит, для пользователя со скринридера этот элемент как бы не будет существовать.

    aria-disabled это состояние виджета, которое отражает активность/неактивность, как disabled у кнопки. Исходя из описания, речь идёт об aria-hidden="true"

    Роли WAI-ARIA могут придать дополнительный смысл коду, например, используя role="search" для определения функциональности поиска.

    Роль search не поддерживается ни в одном из скринридеров. А вообще первое правило aria - не использовать aria, для поиска лучше использовать новый элемент search, когода он получит поддержку.

    Например, role="navigation"

    Первое правило aria. Есть элемент nav.