Комментарии 60
Как же я люблю смотреть на людей, которые все усложняют на серьезных щщах и выдают это за откровение.
А как в данном случае использовать кастомные файлы стилей сторонних наборов компонентов (PrimeNG, Ant Design, Telerik, DevExpress и тд)?
Нарвусь на минуса, но мне больно смотреть как люди пляшут вокруг сраных каскадников. Что с БЭМ, превратившимся в какой-то больной транспайлер, что с остальными подходами. Ребят, это же просто текстовик со стилями отображения в браузере
Проблема появляется с ростом кодовой базы, когда приходится выдумывать какие то дикие названия, чтоб добиться уникальности
Либо неожиданно оказываются перекрыты стили из другой части системы
Это если нет каких то механизмов изоляции стилей, как в angular например
Микроскопом по гвоздям, когда проблема в самом интрументе, пытаться решить ее поиском способа именования, чтобы он не «сдувался»
Расскажите как правильно делать
— отдельный файл с css переменными
— дефолтные стили элементов (table, card итд), причем сделаны они должны быть так чтобы дочерние элементы не требовали позиционирования в родительском через margin.
— стили компонентов должны лежать прямо в каталоге компонента и по возможности вносить минимальные изменения для обеспечения своих функций. При правильной организации они нужны редко.
— все css правила сортированы по алфавиту
Легко, просто, не жрем себе мозг.
— дефолтные стили элементов (table, card итд), причем сделаны они должны быть так чтобы дочерние элементы не требовали позиционирования в родительском через margin.
— стили компонентов должны лежать прямо в каталоге компонента и по возможности вносить минимальные изменения для обеспечения своих функций. При правильной организации они нужны редко.
— все css правила сортированы по алфавиту
Легко, просто, не жрем себе мозг.
вы не ответили на вопрос. (upd: оказывается я и не вам его задавал :D)
как вы стили компонентов инкапсулируете?
В идеальном мире, где нет никакой кастомизации компонентов
Начиналось с «Ребят, это ж всего лишь текстовик со стилями, вы чего носитесь с ним?»
Тут уж «Вот у меня есть несколько правил» никак не соответствует вышесказанному
Мой изначальный посыл был, что это не просто «текстовик со стилями» если нет никакой инкапсуляции то рано или поздно начнутся проблемы
как вы стили компонентов инкапсулируете?
При правильной организации они нужны редко
В идеальном мире, где нет никакой кастомизации компонентов
Начиналось с «Ребят, это ж всего лишь текстовик со стилями, вы чего носитесь с ним?»
Тут уж «Вот у меня есть несколько правил» никак не соответствует вышесказанному
Мой изначальный посыл был, что это не просто «текстовик со стилями» если нет никакой инкапсуляции то рано или поздно начнутся проблемы
как вы стили компонентов инкапсулируете?
Вообще у vue.js Был какой то механизм, но я лично — никак. Я стараюсь делать стили такими, чтобы у компонентов общего назначения не было необходимости в стилях. А компоненты применяемые один раз (например компонент конкретной страницы) — через Id.
рано или поздно начнутся проблемы
В современном вебе проблемы начинаются очень быстро и связаны они с тем что люди думать перестали. Ну простой пример
.mds_precious_card
.mds_precious_card > *
.mds_precious_card > h2
Первый задаст общий стиль, во втором суну отстутп между элементами, третий на случай если заголовочек у меня крайне хитер. Ну еще может понадобится last-child.
Что же делает народ обычно? О там будут стили для каждого типа каждого элемента, да в зависимости от его типа и прочий шлак.
Конечно, пример утрированный, но я это вижу постоянно.
Итого у нас остаются строго функциональные стили которые являются уделом создателей компонентов. Именуем их по имени компонента и радуемся жизни.
Дополню предыдущие рекомендации, говоря о современных фреймворках — никто не мешает использовать библиотеку компонентов, которые выверены под принятые гайдлайны с минимальными свойствами кастомизации под случай, уровня margin, color или fill. Но это в идеальном мире. Так как был вопрос изначально видимо мне — в том же Vue есть scoped стили. Не лучшее по производительности решение через дата-аттрибуты, но в качестве ограничения области использования — хороший метод
А потом h2 заменили на h3 и стили слетели
А если отступ нужен для одного элемента другой — уже нужен класс. Для последнего сделали через :last-child, а потом добавился ещё один блок и нужно переделывать
Так может тогда суть беды в архитектуре, а не в именовании классов?
А потом h2 заменили на h3 и стили слетели
во первых h3 нечего там делать, во вторых вы можете предусмотреть несколько уровней, в третьих вы можете вообще не делать хитрый стиль для заголовка.
а потом добавился ещё один блок и нужно переделывать
у последнего исключительно чтобы убрать межблочный отступ снизу.
А если отступ нужен для одного элемента другой — уже нужен класс.
Нет не нужен.
У вас есть карточка, нет разницы что вы в нее воткнете, ничего не должно особо меняться. Если элемент несет какую либо семантику, как например type=«submit», section, итд итп их тоже можно проработать для компонента и прописать стили в родительском компоненте.
Если вам нужны стили строго по месту то либо через #id родительского компонента либо по id дочернего. Какое тут место классу тоже не понимаю.
Если вам нужно каждый раз для каждого дочернего элемента прописывать стили — вы делаете чтото ну совсем не так.
По вашим ответам мне кажется, что вы никогда не верстали ничего сложнее карточки с заголовком, картинкой и кнопкой, у вас нет дизайнера? я не буду дальше спорить, не все живут в идеальном мире, удачи.
По вашим возражениям вы никогда не делали библиотеку, которая живет под разными темами.
Я создал и внедрил у целой пачки клиентов библиотеку компонентов на ваниле, в которой кроме всего прочего есть сложнейшая кастомизируемая таблица созданная под чудовищную плотность данных и сложные формы. И вот уже много лет они все работает исправно и получает обновление при том что там разные темы.
Прямо сейчас я с коллегой дорабатываю подобную библиотеку на vue.js в которой компоненты еще сложнее и к интерфейсам предъявляются очень жесткие требования по удобству и в то же время делается все, чтобы тратить на создание новых интерфейсов как можно меньше времени. И да, поддержка разных тем никуда не делась.
Даже не знаю что этим хотелось сказать…
но некоторые могут его создавать
Я создал и внедрил у целой пачки клиентов библиотеку компонентов на ваниле, в которой кроме всего прочего есть сложнейшая кастомизируемая таблица созданная под чудовищную плотность данных и сложные формы. И вот уже много лет они все работает исправно и получает обновление при том что там разные темы.
Прямо сейчас я с коллегой дорабатываю подобную библиотеку на vue.js в которой компоненты еще сложнее и к интерфейсам предъявляются очень жесткие требования по удобству и в то же время делается все, чтобы тратить на создание новых интерфейсов как можно меньше времени. И да, поддержка разных тем никуда не делась.
у вас нет дизайнера
Даже не знаю что этим хотелось сказать…
не все живут в идеальном мире
но некоторые могут его создавать
и вы для этого используете описанный подход?
Это довольно забавно, если учесть, что в vue, как и у многих других фреймворках, есть возможность использовать css modules, которые инкапсулируют стили в рамках компонента.
«Хитрый стиль для заголовка» это вообще как?
Не проще ли всем назначать классы и стилизовать от них, а не от родителя?
То, что вы пишите, очень смахивает на ретроградный подход к верстке, но вы пишите на vue и не используете базовых возможностей?
А тилизовать от id, это попахивает извращением.
Это довольно забавно, если учесть, что в vue, как и у многих других фреймворках, есть возможность использовать css modules, которые инкапсулируют стили в рамках компонента.
«Хитрый стиль для заголовка» это вообще как?
Не проще ли всем назначать классы и стилизовать от них, а не от родителя?
То, что вы пишите, очень смахивает на ретроградный подход к верстке, но вы пишите на vue и не используете базовых возможностей?
А тилизовать от id, это попахивает извращением.
Попробуйте нахреначить стилей прямо по компонентам а потом поддерживать две темы. В остальном мне в принципе все равно как вы делаете, убеждать мне лениво.
Это кто это такой модный будет менять уровни заголовков?) Это очень серьезная модификация, чтобы ее случайно сделать.
Если можно обойтись без стилей, лучше без них. Например, меню
nav ul li a span
не знаю примеров, когда надо обвешиваться стилями в простой известной семантической структуре, а задать стили через обращения к тегам ну очень логично.
Если можно обойтись без стилей, лучше без них. Например, меню
nav ul li a span
не знаю примеров, когда надо обвешиваться стилями в простой известной семантической структуре, а задать стили через обращения к тегам ну очень логично.
Дополню предыдущего оратора: этот подход вам позволит сменить или написать новую тему легко и просто.
Если у вас в проекте есть кастомные компоненты, то они должны содержать только тот css который их делает таковыми.
Например мы очень хотим табличку со стики хедером:
.mds_datagrid thead > tr > th {position:sticky; top:0;}
и все, остальные стили наследуем с table
Если у вас в проекте есть кастомные компоненты, то они должны содержать только тот css который их делает таковыми.
Например мы очень хотим табличку со стики хедером:
.mds_datagrid thead > tr > th {position:sticky; top:0;}
и все, остальные стили наследуем с table
Это такой же культ, как с текстами. Напишите сочинение на 4 страницы, добавьте туда аллегорий и описательности, иначе не поставим высокую оценку.
… потом вываливают CSS на 4мб, в котором намешаны фреймворки, лайфхаки, нейроинтерфейсы и малиновое варенье.
НЛО прилетело и опубликовало эту надпись здесь
Насмотрелся я на эти структуры в темах вордпресса. Думал, вертел и не понял прикола.
Я не верю, что автор способен придерживаться этой структуры без ущерба. Любая структура это рамки. Я порой, чтобы не думать, куда пхать индивидульные стили, кладу их в main.scss, inner, contacts проще искать. Если ты описываешь уникальные сущности, привязанные скорее к урлам, их проще потом искать и отрефакторить если вдруг изменение будет в html.
Я не верю, что автор способен придерживаться этой структуры без ущерба. Любая структура это рамки. Я порой, чтобы не думать, куда пхать индивидульные стили, кладу их в main.scss, inner, contacts проще искать. Если ты описываешь уникальные сущности, привязанные скорее к урлам, их проще потом искать и отрефакторить если вдруг изменение будет в html.
НЛО прилетело и опубликовало эту надпись здесь
Если речь идет десятках тысяч, это либо легаси, либо бойлерплейт индусский. Там уже структура историческая, осмыслять поздно)
НЛО прилетело и опубликовало эту надпись здесь
css не код. Его особо структурировать не надо. От переструктуризации начинаются грязные хаки. Но границу эту я не смогу назвать. А платят так, как себя продашь.
НЛО прилетело и опубликовало эту надпись здесь
Мы все равно говорим без предмета критики. Я критикую подход из статьи. Он переструктурирован. Крупный магазин просто обслуживается не одним человеком, поэтому договоренности тут не потому что не дадут переписать, а потому что решение должно быть удобным не для одного.
Яж не говорю все лепить в 1 файл. Я видел темы вордпресса которые так структурированы и кроме самодурства ничего в голову не пришло. С ними работать нифига не проще, особенно бесят папки, поиск по которым достает.
Топик какой-то скучный. Раньше минусили, спорили. Сейчас всем все равно.
Яж не говорю все лепить в 1 файл. Я видел темы вордпресса которые так структурированы и кроме самодурства ничего в голову не пришло. С ними работать нифига не проще, особенно бесят папки, поиск по которым достает.
Топик какой-то скучный. Раньше минусили, спорили. Сейчас всем все равно.
Он у вас что 5 лет растет? Через два года уже все переписывать и менять надо, а большинство проектов — это просто странички.
НЛО прилетело и опубликовало эту надпись здесь
Только не с помощью оператора extend, а с помощью миксинов, которые просто дублируют код. Кроме того, миксины проще изменять и дополнять, прокидывая аргументы.
Использование экстенд достаточно давно считается антипаттерном (есть исключения, конечно, но в целом это антипаттерн), потому что экстенды плохо работают с вложенными селекторами, media query и ухудшают читаемость кода (если экстенд используется не 2-3 раза, а 50-100).
В той же документации sass на странице про экстенды выделено 3 блока с важными уточнениями и отдельная секция по limitations
Использование экстенд достаточно давно считается антипаттерном (есть исключения, конечно, но в целом это антипаттерн), потому что экстенды плохо работают с вложенными селекторами, media query и ухудшают читаемость кода (если экстенд используется не 2-3 раза, а 50-100).
Extends or Mixins?
Extends and mixins are both ways of encapsulating and re-using styles in Sass, which naturally raises the question of when to use which one. Mixins are obviously necessary when you need to configure the styles using arguments, but what if they’re just a chunk of styles?
As a rule of thumb, extends are the best option when you’re expressing a relationship between semantic classes (or other semantic selectors). Because an element with class .error--serious is an error, it makes sense for it to extend .error. But for non-semantic collections of styles, writing a mixin can avoid cascade headaches and make it easier to configure down the line.
В той же документации sass на странице про экстенды выделено 3 блока с важными уточнениями и отдельная секция по limitations
Я себе написал авто оптимизатор-сборщик. Изменил CSS или JS — система сразу проверила MD5 и заменила собранные сжатые файлы шаблона и ресурсов JS\CSS. Оригиналы лежат отдельно, а сборщик кладет и подключает их из директории public cache. CSS и скрипты при этом оптимизируются и сжимаются автоматически c добавлением integrity. Для Kernel на PHP подобный сборщик у меня занял 3 часа работы двумя регулярками.
Бандлеры, сборщики и транспайлеры для CSS становятся не нужны с появлением CSS 4 variables.
И первым по списку должен идти reset(посмотрите Boiler Plate — там не плохой сброс реализован).
Попутный вопрос: @_import() ваш SASS заменяет на что-то(они оптимизируются в один source)? Это же плохая рекомендация по версиям того же Google Page Insights или GT Metrix.
Бандлеры, сборщики и транспайлеры для CSS становятся не нужны с появлением CSS 4 variables.
И первым по списку должен идти reset(посмотрите Boiler Plate — там не плохой сброс реализован).
Попутный вопрос: @_import() ваш SASS заменяет на что-то(они оптимизируются в один source)? Это же плохая рекомендация по версиям того же Google Page Insights или GT Metrix.
Вы написали свой webpack, а зачем? Мне правда интересно
Нет. Вы так рассуждаете, что кроме JavaScript больше ни чего не осталось. У меня, например, PHP на backend. А вы со своей Node.js даже инсталляторы делать не научились до сих пор 98% разработчиков.
Есть конфиг файл описывающий какие скрипты и файлы подключаются. Их можно редактировать, а с шаблоном они собираются автоматически. В том и прелесть, что ни какой webpack не нужен вообще. Это просто часть системы, которая работает автоматически и прозрачно.
Есть конфиг файл описывающий какие скрипты и файлы подключаются. Их можно редактировать, а с шаблоном они собираются автоматически. В том и прелесть, что ни какой webpack не нужен вообще. Это просто часть системы, которая работает автоматически и прозрачно.
Я со своей Node.js не научился писать инсталляторы? Да, так и есть, но я в общем-то и не собирался, не пытался и не планирую. Также JS не считаю своим дефолтным языком программирования.
Я вас и не осуждаю. Но мне надо как и моим клиентам и прочим потребителям чтобы оно устанавливалось. Они берут у меня продукт на котором работают, а не пачку деплоев для которых еще надо разрабов купить целый отдел. Если вы работаете над одним проектом — это понятно. А если их 50?
какой-то непонятный кейс. Почему они должны устанавливать это у себя через самописный установщик? Какая у них инфраструктура и на чем запускается? Почему бы не настроить CI/CD с использованием Docker'а?
Человек строит гипотезу о квалификации оппонента ничего не зная о ней, продолжает ее развивать исходя из своего личного взгляда на решение тех или иных задач, опуская при этом вопрос качества и имеющихся альтернатив. Я согласен с вашим взгядом, но боюсь здравого обсуждения у вас не получится. Изобретать велосипеды полезно, для своего опыта в качестве хобби, но практики ставшие общими придумали не идиоты. Если знания о сборщиках, и упомянутом webpack ограничиваются этим:
Есть конфиг файл описывающий какие скрипты и файлы подключаются.Продолжать беседу довольно сложно и бессмысленно.
НЛО прилетело и опубликовало эту надпись здесь
Был такой подход. Он не очень, потому-что мало отличается от прописывания инлайн стилями, просто короче.
Этот подход размывает сущность между шаблоном и css. Например, вам нужно после 800px уменьшить margin-top на половину. Эта сущность описана в двух файлах: шаблоне и css.
Либо вы будете городить новый стиль less-800px-ml-half либо перекрывать его в css. В любом случае это вызывает путаницу, когда понадобится что-то изменять адаптивно. Это допустимо, если вы не будете выходить за рамки выбранного css фреймворка. Это известно по бутсрап войне. Сначала натягивают бутстрап, а потом с ним воюют отдельным файлом !important.
Поэтому снижение когнитивной нагрузки — это следствие всего лишь договоренности, что мы не делаем сложный адаптив. А нюансов там куча, например, убирать полностью padding у сетки при ширине менее 420px, чтобы в телефоне в два ряда шли товары, и задать max-height какой нибудь.
Этот подход размывает сущность между шаблоном и css. Например, вам нужно после 800px уменьшить margin-top на половину. Эта сущность описана в двух файлах: шаблоне и css.
Либо вы будете городить новый стиль less-800px-ml-half либо перекрывать его в css. В любом случае это вызывает путаницу, когда понадобится что-то изменять адаптивно. Это допустимо, если вы не будете выходить за рамки выбранного css фреймворка. Это известно по бутсрап войне. Сначала натягивают бутстрап, а потом с ним воюют отдельным файлом !important.
Поэтому снижение когнитивной нагрузки — это следствие всего лишь договоренности, что мы не делаем сложный адаптив. А нюансов там куча, например, убирать полностью padding у сетки при ширине менее 420px, чтобы в телефоне в два ряда шли товары, и задать max-height какой нибудь.
НЛО прилетело и опубликовало эту надпись здесь
Если отталкиваться от компонентной архитектуры, то зачем вообще нужны эти пляски с каскадами?
Селекторы придумай, за их специфичностью проследи, статический анализ достигается только подключением 100500 плагинов на все случаи жизни, базирующиеся на данных из JS стили создаются черезкрасивые хитрые решения
Конечно, все еще зависит от инструментов. Конечно, без них никуда.
Допустим, возьмем React.js. Тогда смело можно использовать какой-то CSS-in-JS, например styled components, и по возможности вообще избегать вложенных селекторов и декларации className где-либо, что сразу избавляет от пропасти в статическом анализе и каких либомега инструментов для удаления мертвого CSS, и многое другое реализуется средствами JS, что избавляет нас от каких-либо препроцессоров, которые пытаются повторить то же самое, что уже умеет JS, и то на момент сборки.
Конечно, можно аргументировать около олдскульные подходы и трюки в CSS тем, что они менее требовательны к ресурсам, но давайте еще помнить о вреде низкоуровневых оптимизаций, так как в <ваш процент>% случаев они не играют никакой роли. Как минимум, lazy loading и разбитие бандла на части даст больше профита, чем попытки сжать итоговый CSS
И в конце концов, CSS создавали не люди, которые прилетели из будущего и уже знают, какое недостатки будет иметь в будущем такая реализация
Селекторы придумай, за их специфичностью проследи, статический анализ достигается только подключением 100500 плагинов на все случаи жизни, базирующиеся на данных из JS стили создаются через
Конечно, все еще зависит от инструментов. Конечно, без них никуда.
Допустим, возьмем React.js. Тогда смело можно использовать какой-то CSS-in-JS, например styled components, и по возможности вообще избегать вложенных селекторов и декларации className где-либо, что сразу избавляет от пропасти в статическом анализе и каких либо
Конечно, можно аргументировать около олдскульные подходы и трюки в CSS тем, что они менее требовательны к ресурсам, но давайте еще помнить о вреде низкоуровневых оптимизаций, так как в <ваш процент>% случаев они не играют никакой роли. Как минимум, lazy loading и разбитие бандла на части даст больше профита, чем попытки сжать итоговый CSS
И в конце концов, CSS создавали не люди, которые прилетели из будущего и уже знают, какое недостатки будет иметь в будущем такая реализация
НЛО прилетело и опубликовало эту надпись здесь
можно использовать какой-то CSS-in-JS, например styled components, <...>, что сразу избавляет от пропасти в статическом анализе и каких либо мега инструментов для удаления мертвого CSSМожно поподробнее?
Почему переход от Тьюринг-неполного CSS к Тьюринг-полному JS избавляет от пропасти в статическом анализе?
в чистом JS можно добиться относительно бедного статического анализа через тот же ESLint. Если пойти дальше, можем использовать TS. С ним тоже будет некоторая пропасть, но это хотя бы решает такую дилемму как:
1. установить 100500 модулей для проверки CSS и 100500 модулей для проверки JS/TS
или
2. установить 100500 модулей для проверки JS/TS
1. установить 100500 модулей для проверки CSS и 100500 модулей для проверки JS/TS
или
2. установить 100500 модулей для проверки JS/TS
Чем tools отличается от utilites?
Прочитал все комментарии в надежде увидеть хоть один про CSS-модулей, но почему-то нет (упомянули только styled-components). Но ведь в самом деле, зачем усложнять все и поддерживать сложную структуру руками, если все проблемы могут автоматически решить существующие инструменты?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я структурирую CSS