Помощь с code review вёрстки?

Question

[Happy-Child]

Здравствуйте!
Прошу помочь с code review.
Вот сама вёрстка - https://serge.sivenkov.by/
Вот исходники - https://github.com/Happy-Child/Happy-Child.github.io
Прошу больше внимания уделить исходникам. Спасибо.

Comments

[ⓒⓢⓢ]

для чего вы используете em\rem величины?

[Happy-Child]

Для того, чтобы каждый раз не писать на определённых размерах экрана px.

[ⓒⓢⓢ]

Happy-Child, понятно, ваше удобство превыше всего? :)
Можно ведь перевести в проценты и оставить пользователю возможность выбирать удобный ему размер шрифта
* в проценты для блока html

[Happy-Child]

Тут вас чутка не понял.

Если я задам размер шрифта в %, они буду считаться не от html, а относительно размера шрифта родителя. Rem в свою очередь, берёт значение от html.

Возможно я не понял что вы хотели до меня донести.

[ⓒⓢⓢ]

Happy-Child, если изменить у блока html фиксированный размер шрифта на проценты, то пользователь сможет использовать свои настройки браузера.
Например на больших экранах удобно в настройках браузера увеличивать шрифт, чтобы он не был мелким. Если сайт адаптивный, то он без дополнительных движений от пользователя сам подстроиться под нужный размер.
Что-нибудь из этого можно почитать:
https://webformyself.com/texniki-adaptivnoj-tipogr...

[Happy-Child]

ⓒⓢⓢ, теперь понял что вы имели ввиду)

Answer 1

[Ivan Bogachev]

Думаю в этом мини-проекте вам уже не нужно все переделывать, но в перспективе обращайте внимание на:

Файлы:
- Если вы собираете зависимости в бандл - не храните их исходники в репозитоии. Они там не нужны. В репозитории храните только package-lock.json, чтобы можно было скачать нужные версии всего.
- Все конфиги, связанные со сборкой, должны быть в репозитории.
- Было бы круто разнести исходники и результат сборки. Условно в папки src и dist или build или еще как-нибудь назовите. Будет удобнее.

Скрипты (логику проверять лениво, так что только по внешнему виду):
- Много всего в одном файле. Делите на небольшие модули, будет удобнее.
- Все очень разное. Кавычки, табы и пробелы, даже if-else вы пишете все время по-разному. Используйте какой-нибудь один стиль написания кода. Для начала можно взять от airbnb - он довольно популярный.

Стили (все не смотрел, говорю по паре файлов):
- Вижу мешанину из CSS-методологий. Вроде БЭМ, но местами какая-то дичь начинается. Вроде этого: "main-banner__title text-accent text-cormorant-bold d-block wow fadeInUp".
- Постоянное использование px-to-rem с разными параметрами вперемешку с просто пикселями требует слишком много внимания к себе. Оно там правда нужно?
- Для префиксов есть автопрефиксер. Не тратьте время на них.
- Для импорта анимаций из animate.css есть postcss-animation. Снова, не тратьте время.
- Если используете переменные для цветов, не мешайте их с захардкоденными значениями rgba и hex.
- Магические числа вроде calc(100% - 427px) лучше не использовать, либо комментировать.
- Вставляйте critical CSS в страницы.

Comments

[Happy-Child]

Огромное спасибо! Хорошие подзатыльники прилетели) Учтём

[Happy-Child]

Уточните пожалуйста по стилям по первому пункту - Вижу мешанину из CSS-методологий.
Возьмём тот же самый заголовок баннера

Почему я так сделал:
Стили которые прописаны в подчёркнутых классах встречаются во многих элементах на странице (wow и fadeInDown - классы для анимации). Я создал для них отдельный класс чтобы не писать в стилях каждый раз. Также есть кнопки для вызова модального окна, для быстрого доступа к ним через скрипт я дал им класс.

Если такой вариант не подходит, то опишите пожалуйста почему.

[Ivan Bogachev]

Happy-Child,

Стили которые прописаны в подчёркнутых классах встречаются во многих элементах на странице

Да, это понятно. Но сейчас названия классов разношерстные - где-то традиционное для бэма сочетание дефисов и подчеркиваний, где-то camelCase, где-то еще что-то. Это бы все привести к единому стилю - воспринималось бы легче.

Я создал для них отдельный класс чтобы не писать в стилях каждый раз.

Главная проблема классов-утилит, которые меняют отдельные свойства в CSS, в сочетании с бэмом - это то, что со временем их становится слишком много. И это приводит к головной боли - получается, что мы пишем стили в разметке. Иногда это удобно, когда нужно по-быстрому что-то наклепать, но любой редизайн замедляется в разы. А чтобы в стилях не писать несколько раз одно и то же для разных блоков и их модификаторов, можно испольовать миксины или расширения классов - у препроцессоров много возможностей. Потом gzip это все сожмет, так что за размер файлов можно не переживать.

[Happy-Child]

Понял, спасибо за грамотный ответ

[Happy-Child]

Ещё будет последний вопрос.
Ваше замечание - "Постоянное использование px-to-rem с разными параметрами вперемешку с просто пикселями требует слишком много внимания к себе. Оно там правда нужно?".

Просьба расписать чуть подробнее.
Я сделал этот миксин, чтобы не считать на калькуляторе сколько мне нужно rem (на макете всё в px). Какие есть другие альтернативы для решения этой проблемы.

Спасибо!

[Ivan Bogachev]

Happy-Child, Альтернативное решение на самом деле очень простое. Правда работает оно только с толковыми дизайнерами. Идея в том, что количество действительно разных размеров на макете всегда ограничено. Хороший макет - это не "намалевал на коленке как попало", это скорее "строгая система, в которой размеры всего заранее определены". Соответственно нет нужды постоянно что-то считать. Можно сделать переменные со всеми размерами (их будет штук 10 может быть) и везде использовать только их. Назвать можно на свой вкус и цвет. Таким образом в коде не будет большого количества совершенно непохожих чисел, которые быстро смешиваются в кашу в голове.

Со временем глаз привыкает к такому ограниченному набору размеров и их можно различать на глазок и не тыкать в каждый элемент в макете, проверяя его размер. Само мышление перестраивается с "количества пикселей" на "один из размеров из набора". Если сотрудничать с одним дизайнером, то можно прийти к тому, что он будет примерно набрасывать макет, не подгоняя все с точностью до пикселя, а мы будем верстать исключительно по этой системе размеров. Такой подход экономит кучу времени всем.

В идеале, если дизайнер знаком с тем, как верстают печатные издания, то он может все размеры изначально приблизить к "красивым" значениям в rem. Тогда и переменные под это не нужны. Пару лет назад я пытался эту мысль описать, получилось немного сумбурно и не убедительно, но с тех пор идея обкаталась и могу сказать, что она работает. Простые сайты можно клепать совсем без дизайнера и будет получаться вполне неплохо. Собственно мой сайт - маленький пример, как это работает.

[Happy-Child]

Ivan Bogachev, Снова спасибо.