25 советов для начинающего верстальщика

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

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

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

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

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

Почему?

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

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

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

Зачем?

И так далее

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

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

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

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

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

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

Это как?

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

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

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

В заголовке тега 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.

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

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

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

Мне, честно говоря, очень не нравится формулировка. Что значит "по возможности"?) Здесь я могу пояснить, что я написал, а это скопировал с StackOverflow, поэтому пояснить не могу?)

Думаю, правильнее было бы "при необходимости пояснять свой код". И то эта необходимость должна быть явно выраженной. Если обратиться к книге Р. Мартина "Чистый код", в разделе "Комментарии" приводится совет комментировать действительно проблемные места, такие, которые могут вызвать вопросы у других разработчиков. БОльшую часть кода другой разработчик должен разобрать без ваших пояснений. Если же это не так -- с вашим кодом что-то не так, меняйте стиль)

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

А почему не 4?) А почему пробелы а не табы?) Я к тому, что такие вещи могут варьироваться от команды к команде. Хотя 2 пробела -- это самое широко распростаненное соглашение формата кодовой базы, не забудьте спросить про иные соглашения, если работаете с кем-то. Возможно, вам повезло, и вы попали к любителям табуляции. Ну и editorconfig вам в помощь. Ну или что покруче, например, prettier.

Про BEM, я бы тоже не был столь категоричен. Я видел как люди организовывали небольшой проект верстки по методу Atomic. В определенных случаях это применимо и проблем с читаемостью особо нет. Но если не знаете, как организоваться -- то да, BEM ваш друг)

В целом, советы очень сомнительные. Я не хочу обижать автора, но без аргументации это
а) не понятно
б) не авторитетно
в) местами вредно
Хотите чтобы дошло до даже "самого зеленого" -- добавьте "потому что". Имхо, как раз для начинающего это будет очень полезно.

Сам новичок во фронте, но уже сам могу сказать, что статья посредственная, еще и местами вредная. Больше даже для верстальщиков.

Такое ощущение, что это chatGPT постарался.

Как начинающий хотел бы статью с ссылками на статьи и курсы полезные. А то что тут написано я не понял.

Вот html, где учить? Курс? Автор Ютуба,? Сайты со статьями? Книги? И та же история про css, javascript, да и по сути любое другое направление а айти