Как стать автором
Обновить

Комментарии 9

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

Начиная от того, что стили могут инлайнится при сборке проекта

Контекст конечно же стоит понимать и тут не рассматривался вариант со сборкой проекта. Рассматриваются общие правила плохого тона и почему он считается плохим.

Билд, кстати, тоже делают умным и не добавляют все стили либо в разметку, либо в стили. Критически важный CSS отправляют в разметку, а всё остальное в стилевых файлах. Опять так можно сделать если в проекте есть сборка. Руками тоже можно, но куда сложнее.

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

Инлайнинг стилей не ограничиваются тегом <style>. В статье также показан вариант

`<div style="font-size: 20px; color: white; background-color: black;"></div>` и тут не понятно как справляться с псевдоэлементами и прочим.

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

Контекст конечно же стоит понимать

Контекст, прежде всего, должен автор задавать, при написании статьи. Не я все свалил в одну кучу под одним громким заголовком.

Инлайнинг стилей не ограничиваются тегом <style>

Как не ограничивается он и html-атрибутом style.

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

Зачем статьи, смотрите доки: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

чтоже будет когда автор дойдет до тайилвинда :)))

Google пошел все равно по своему.. в AMP стили как раз встроены в сам HTML :(

При подключении внешнего стилевого файла CSS отделён от разметки, поэтому его проще поддерживать.

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

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

Ускорить – возможно. Сделать легкочитаемым – вряд ли.

позволяет всем участникам быстрее ориентироваться в стилях.

То же самое, что я говорил выше, только наоборот. Когда я вижу разметку, по названию класса я, скорее всего, не угадаю, как элемент стилизован (если только класс не называется btn-red).

При использовании внешнего CSS вы видите структуру своего проекта

Ну да, разработчики смотрят на структуру проекта по CSS-файлам. CSS-файлы вынуждают держать компоненты не одним файлом, а папкой, что только усложняет восприятие структуры.

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

... и заодно сломать пол-проекта. По крайней мере, с inline-стилями я уверен, что изменение здесь больше ни на что не повлияет.

Если писать стили внутри атрибута style, то HTML становится трудночитаемым. Логическая структура исчезает и стили размываются по всему коду. Следить за стилизацией становится непросто, а поиск фрагмента, в котором нужно изменить CSS-правило, отнимает немало времени. И чем крупнее проект, тем сложнее управлять стилизацией.

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

Стили из внешнего CSS файла легко переопределять, так как у каждого селектора своё значение специфичности. Класс приоритетнее селектора тега, а идентификатор приоритетнее класса.

А если писать стили inline, то вообще ничего переопределять не придется)

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

А мы так хотим увидить страницу до того, как к ней применятся стили! (нет)

Почему всё же не стоит использовать inline-стили

Я не эксперт в вопросе безопасности, поэтому про CSP говорить не буду, уже сказано.

Но что касается самого кода, то inline-стили мы не используем, потому что классы позволяют нам переиспользовать CSS-код и абстрагироваться от низкоуровнего margin-top: 10px и т.д.

Однако, если есть возможность использовать компонентный подход, то лучше такие элементы, как button, выделять в отдельные компоненты и стили прописывать прямо в HTML. И лучше для этого использовать не встроенный атрибут style , так как получается многословно, а библиотеки для атомарного CSS, такие как Tailwind CSS.

Вывод

Аргументы, приведенные в статье, неверны, а выводы уже неактуальны.

Что у вас за проекты такие что наличие inline стилей не превращает работу с компонентами в кромешный ад? Вёрстка write once never read landing-ов в потоке?


По сути я вижу только 1 аргумент за inline-styles: стили ближе к вёрстке. Но, имхо, он почти не состятелен, в 2021г, т.к. времена div-обёрток над div-обёртками остались в нулевых, ибо современный CSS очень могущественнен. И поэтому вся вёрстка и лежит в стилях. А в HTML разметке остаётся разметка — множество аттрибутов, events, a11y. И какого-то смысла пихать туда ещё и стили не вижу.


К тому же вы говорите о компонентном подходе. В мало-мальски сложных SPA там мешанина разной UI-логики с кучей event-ов, хитрых аттрибутов, разной видимостью и прочим. И теперь туда десятки строк стилей в каждый тег пихать? о_О


Мне кажется для inline-стилей есть следующие применения:


  • Пишем write-only код на скорость. Какие-нибудь одноразовые лендинги. Качество кода имеет околонулевое значение, а сроки максимальное.
  • Нужна динамика. Например так можно задать css3-variables, которые уже используются в стилях
  • Нужна позиционная динамика. Всякие transform, translate и пр.
  • Нужна анимация. Правда тут часто бывает удобнее JS Animation API использовать

Зачем нужны изолированные от UI-логики и HTML (тут частично) стили:


  • DRY
  • pseudo- и прочие sub-селекторы
  • вся сцена оформления перед глазами без мусора (в данном случае те самые аттрибуты, события, логика отображения, всякие циклы и т.д.)
  • простота оптимизации и линтинга (но только в случае статичных стилей а не CSS-in-JS)
  • для сложных проектов принципиален вопрос архитектуры всего этого добра. И разумеется когда слой изолирован это намного проще
  • кеширование
  • производительность

Про CSP поржал. Из всех правил это наверное самое самое слабое. Но это не к вам, а к i360u.


Inline стили это мощный инструмент для исключительных целей.

Как печально, что на статью про правильное использование стилей в наше время 3,5 коммента "почему стили не надо использовать правильно"

Мне кажется или статья специально написана так, чтобы у всех бомбануло?)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий