Перфекционисты не месте?
раскрыть ветку (20)
раскрыть ветку (19)
раскрыть ветку (18)
раскрыть ветку (17)
Хорошо, молодцом)
А вот смотри, у тебя есть 10 дивов. Надо их в ряд выстроить. Сколько способов сможешь назвать?
раскрыть ветку (16)
Смотря как, по x или y))
По горизонтали тут еще смотря какой контейнер, если ли оверфлоу, в теории это флекс, грид, мб ещё флоатами, но тут сомнения, на ум приходит inline поведение, но тоже сомнительно))
раскрыть ветку (15)
В ряд это по горизонтали. Родитель можно какой угодно сделать.
Ты назвал:
1. Флекс
2. Грид
3. Флоаты (а почему сомнения?)
4. Инлайны (почему сомнительно?)
Всё или ещё будут?
раскрыть ветку (14)
Редко встречаются не типовые задачи, флексов и гридов обычно вполне хватает. Ну вот 4 варианта, больше нет идей))
раскрыть ветку (13)
4. инлайны будут игнорить размеры блока, поэтому inline-block лучше, а вообще подойдет почти что угодно из семейства inline-*;
5. псевдотаблицы (родителю дать display: table-row, детям display: table-cell;
6. тот же columns;
7. наговнокодить абсолютами;
8. наговнокодить трансформами или родителя на 90 градусов повернуть);
А почему ты верстаешь не mobile-first и юзаешь ли ты rem'ы?
P.S.: я верстаю с 2008)
раскрыть ветку (12)
Вот это списочек конечно xd
Да как то изначально пошло так что сперва под ПК, а потом уже под маленькие девайсы. Вообще я сейчас плотно на таилвинд подсел))
раскрыть ветку (11)
Tailwind, bootstrap и tilda - это три волшебных слова в резюме верстальщиков, которых я никогда не возьму к себе на работу. Это три волшебных слова в вакансиях компаний, куда я никогда не пойду работать сам. Если вы признаете CSS ООП в пользу БЭМа и не можете прийти к mobile first в те времена, когда 95% сидят с телефона, то неважно сколько лет вы в теме, в верстке вы не более, чем middle. Про rem'ы мы не говорим.
раскрыть ветку (10)
Один вопрос, а зачем в верстке быть больше чем мидл, чтобы что?)) Я скажу. Чтобы потешить свое самолюбие и записать шорцы в Ютуб про новое свойство которое не поддерживает 80% браузеров xd.
Бутстрап вообще ни кто в реальных проектах не использует уже давно, только если сетку его.
Тильда? Так это конструктор вообще, и к слову сказать сайты многих блогеров и прочих контентмейкеров не редко на ней и сделаны.
Таилвинд хороший инструмент, а если ещё уметь его конфигурировать, то это швейцарский нож в вёрстке.
раскрыть ветку (9)
Понятное дело, что коммерчески куда разумнее не становиться сеньором или богом в верстке, а идти во фронт, бэк, фуллстэк или в айти-менеджмент. Шортсы в ютуб ты можешь посмотреть у Анны Блок. А я тот, к кому она обратилась за версткой сайта для её дела. Новые свойства - очень осторожное место. Я :has юзаю только там, где оно функционально может быть опущено. К тильде аргумент тот, что чел сидит дрочит её и называет это версткой, а себя верстаком. Нет, такое не катит. Тэйлвинд для тех, кто не знает о кэшировании страницы и об отрисовке элементов. К примеру: почему нельзя юзать в CSS селекторы по тегам (кроме html и body) и особенно звездочку? Дебилы поголовно пишут: "* {box-sizing: border-box;}", вообще не включая голову и не думая о чистоте кода и о рендеринге браузером. SVG как есть на страницу пихают ради иконок, не зная о существовании масок. По W3C никто финальные прогоны не делает тоже. Тэйлвинд засоряет кэш, а также сковывает использование псевдоэлементов, на которых нужно выстраивать полностью оформление.
раскрыть ветку (8)
А можно, пожалуйста, раскрыть пару аргументов:
1) На счет атомарного css, какой именно кеш забивает Tailwind (Windi\Unocss)?
2) На счет сковывания использования псевдоэлементов в том же самом Tailwind, можно ли пару примеров?
раскрыть ветку (6)
Да, конечно.
1. Браузер кэширует подключаемые файлы: CSS, JS, картинки. Все, что в зоне HTML-разметки не кэшируется и грузится по новой. Когда вместо того, чтобы вписать один класс БЭМ и описать в кэшируемой зоне, мы кидаем кучу классов на тег, все это по новой кэшируется.
2. Tailwind работает с элементами в целом и накидывает свойства на них. На практике очень много стилей вешается на псевдоэлементы :before/:after - огромное количество оформительских фич. Тут у блока уголочек дизайнер выделил, тут у активной вкладки скругления внешнего угла, тут у спиcка кастомные маркеры, тут уголочек у тултипа и многое другое.
Есть прекрасная методология БЭМ. Есть ваша безграничная фантазия и несколько способов решения каждой проблемы. Такие вещи как bootstrap и tailwind ограничивают вас как творца. Вместо безграничного набора каких угодно кубиков лего у вас есть уже готовые компоненты. Если говорить о bootstrap, то верстка макета по нему это вообще сплошные переопределения с !important.
Must have:
1. БЭМ (можно с оторванными модификаторами);
2. Mobile first (можно использовать max-width в @media очень редко, чтобы избежать переопределений, только для тех вещей, которые есть на мобилке, но отсутствуют на десктопе);
3. Rem'ы на 10px или формулой от 100vw для резины;
4. Никаких тегов в css (scss, само собой) кроме html и body;
5. Никаких селекторов «*»;
6. Normalize.scss вместо reset.scss;
7. Swiper вместо slick и тем более прочих других;
8. Никаких !important, только в крайнем случае;
9. Полная валидация W3C кроме warning'а по поводу viewport'а;
10. Одноцветные иконки всегда через маски;
11. Всегда учитывать переполнение контента, например модалки центрировать гридами на случай большого текста;
12. Анимация внутри SVG-файла -- хорошо. Хоть SMIL, хоть CSS;
13. Все тексты типографировать, всю графику гнать в webp.
раскрыть ветку (5)
Спасибо.
Но, все же, не до конца понял по п.1.
Для примера рассмотрим два варианта с некоторыми абстрактынми блоками и их стилями:
1) .mx-a .min-w-100
Где tailwind скомпилирует файл css
2) .some-block__item { margin: 0 auto; min-width: 400px }
Где прекомпилятор scss скомпилирует файл css
В одном и другом случае, файл по канону подключается в секуции head html-документа, то какие тут могут возникнуть противоречия, касаемо кеширования css-файлов?
Или речь тут не про сам tailwind как таковой, а на поведение некоторых бандлеров\фреймворков, которые имеют дополнительный функционал для инлайнинга стилей?
А что касается п.2, то ведь tailwind имеет поддержку работы с псевдоэлементами посредством модификаторов before::\after::
Как пример: class="after:content-['*'] after:ml-0.5"
Несомненно, в сложных стилвеых конструкциях выглядеть это будет монструозно.
раскрыть ветку (4)
С двумя свойствами да, а если больше?)
И плюс это нечитабельное говно.
А как насчет стилевых компонентов и UI-kit'а? Везде копипастить вместо использования универсальных классов?
На скрине 1 можно увидеть написанную мной документацию по использованию кастомных чекбоксов и радиобаттонов на одном из моих проектов. На дальнейших скринах вырезки из стилевого описания этого компонента. Там сочетания :hover, :checked и псевдоэлементов. И всё это описано читабельно и ёмко.
раскрыть ветку (3)
По факту, хоть с сотней классов, тут не может идти речь о кешировании в таком контексте, ибо использование методолгии BEM или tailwind, да даже без них никак не отражаются на факте кеширования файлов стилей. Единственное, что тут может затрагивать данный вопрос, так это использование функционала фреймворка\бандлера со встраиванием стилей, когда частично или полностью стили встраиваются в страницу посредством обычных тегов <style></style>, такой подход разумен например при весьма ограниченном использовании тех или иных стилей на страницу, особенно еще обрезанных critters и страницах генерируемых при SSG.
Что касается примеров, приведенных выше, то взглянем глазами человека, кому придется это поддерживать:
1) Ему необходимо изучать новый стандарт классов, следуя документации, при этом, скорее всего, документация разнится от проекта к проекту, и едного стандарта нет, разве что глобального - именование по БЭМ. И тут уже возникает небольшой вопрос, изучить один раз обширную документацию по tailwind (с "говорящими" классами) и стандартизироваться или каждый раз лезть в документацию кастомную.
2) Список классов ограничивает свободу, если потребуется, например, обводку сделать не серой, а зеленой, то придется лезть в css и добавлять свой стиль.
3) Данная html-структура в любом случае требует копипасты, разница тут лишь в том, что используется полный набор необходимых классов для стилизации (tailwind) или кастомных. Например unocss позволяет спокойно делать так называемые shortcuts или rules, проще говоря собственные классы в том числе и динамические.
раскрыть ветку (2)
Все дело в концепции. За внешний вид отвечают стили. Они должны быть в зоне стилей. В зоне разметки должна быть структура. И так далее. У вас на скринах нечитаемая каша. Вероятно вам нравится Python. Пишите так, если вам угодно. Я и мои ребята будет в более выгодном конкурентном свете на рынке благодаря таким, как вы.
раскрыть ветку (1)