Эта статья является продолжением моего «крестового похода» против ветряных мельниц убогих современных тенденций в разметке и оформлении веб-приложений (статья1, статья2). И, поверьте — солидная ее часть — это толерантная, такая, чтобы никоим образом не нарушить NDA, переработка реального доноса код-ревью кода важного боевого проекта для руководства одной из команд в которых мне приходилось участвовать. До этого момента я породил уже три достаточно злых, токсичных длиннопоста для сообщества, и, о чудо — ни один из них не умудрился скатился в минус (но последний был близок). И на этот раз — я готов! Ибо этот пост именно о тех технологиях и подходах к верстке, которые мне[, конечно же, на основе коммерческого опыта] кажутся весьма неудачными и неэффективными, неадекватными в очень многих ситуациях. Конечно, существуют команды, проекты, требования когда каждый из этих подходов может окажется вполне приемлемым и уместным. Но на деле, чаще всего, имхо, оказывается, что поборники данных методов — безальтернативно «подсаживаются на любимую иглу» и упорно не хотят знать и уметь, использовать ничего другого... Мне вообще кажется, что мир вокруг нас сейчас это — утопия, практически целиком, максимально упрощенная тотальным засильем пролоббированного рептилоидами, мировой закулисой корпорациями тоталитарного глобального мейнстрима, и это одинаково касается всех сфер жизни, вот тут можно почитать мою философскую статью на тему применительно как раз к интерфейсам Куда подевались социальные сети? Пропаганда и реклама вместо общения... И даже наш любимый журнал о технической культуре, по сути, превратился в рекламную помойку, по большей части, унылое отражение глобального общественного тренда... Но, как известно — «главное попытаться», поэтому — поехали!
Ошибки в работе с пространством
Неоправданное и, при этом, неявное использование flexbox
Очень многие проблемы в верстке бывают связаны с тем, что проектирующие сейчас разметку разработчики используют «модную» flexbox-раскладку вообще везде и для всего — и для чего надо, и для чего ну совсем негоже — практически для любого позиционирования элементов, в том числе и для крупных лейаутов. Когда я вижу такое, то сразу начинаю подозревать, что автор никогда не верстал писем, сетки под IE6-7-8-9, «ворвался» совсем недавно, но, при этом, поленился, например, пройти базовые курсы, как, впрочем, видимо, и поучить-потренировать такой же свежий, только для modern bro — grid-layout. Часто так делают именно для передачи статичного макета который будут принимать pixel-perfect. Вам кажется удобным делать «гибким и резиновым» то, что «должно быть четко и статично», идеально точно? Вероятно, вы никогда не делаете муторную подгонку сложных замороченных и нелогичных художеств-хотелок дизайнеров/клиентов? Я понимаю когда нужно «простым образом позиционировать что-то посередине».) Ну это значит, что, например, с вашими любимыми Styled Components, в арсенале «утилит-компонентов» переиспользуемых по всему проекту должен быть некий явный контейнер <FlexboxContainer mode=”center” /> — явно выражающий это! Нет, «тыжпрограммистна JSX/CSS-in-JS» и панически избегаешь всего, что связано с дизайном и его самостоятельными абстракциями, извините... Многие все делают флексом, но это даже никак не обозначено — никакой дизайн-абстракции не существует в принципе. Просто пара правил, в результате — повторяющихся в коде стопитцот раз — в классах CSS-модулей безо всякого маломощного composes, в «инкапсуляциях» стилевых компонент или как не читаемая «ишак вижу — ишак пою» «утилита в стиле Tailwind» на разметке... Требования изменились, или, обыденно — фиксим что-то всплывшее-неожиданное, кто-то добавил обертку-контейнер не в том месте, потерялось или появилось ненужное правило flex-direction или justify-content — где-нибудь еще «все развалилось» — фиксим снова! «Баги есть — есть работа!».
Совет 1. Особенно передавая статичный макет для pixel-perfect — опирайтесь на обычный статичный поток, используйте контейнеры, обертки которым можно выставлять высоту или абсолютное позиционирование относительно relative-родителя. Изучите, хотя бы бегло, старперские простые классические приемы, используйте Grid-раскладку для собственно сеток, а Flexbox-модуль — только там где это действительно необходимо и уместно. Чаще всего: для «мелкого», локального позиционирования внутри небольших конечных блоков, виджетов.
«Бесхребетная» разметка
Что бывает когда все написано на flexbox и не формирует в статичном потоке четкие контейнеры и обертки с фиксированной высотой? Все разваливается и едет — в самых неожиданных или вполне ожидаемых местах. Элементы ведут себя менее предсказуемо, очевидно, по определению — более гибко, резиново, и это часто создает проблемы с тем, чтобы передать макет точно, например когда мы пытаемся переиспользовать и модифицировать «уже готовые» шаблоны-паттерны на похожих видах — постоянный сплошь и рядом встречающийся кейс в веб-дизайне. Очень часто эта «резиновая верстка» статичных макетов еще и «висит на контенте». Немного изменились данные, текстовый контент приходящий с бека, строк стало больше — вообще вся страница поплыла... В хорошей надежной продуманной верстке баг если и появляется, то только один раз и дальше он уже надежно фиксится. Но мне приходилось видеть, как одни и те же проблемы «возвращались по кругу», возникали много раз... Потому что изначально все было сделано настолько безобразно-дурно, что геройски переписать надежно — уже очевидно слишком дорого, а править с помощью кряков и хуков, на самом деле — также дорого, но еще и крайне неприятно, отвратительно, мерзко... Но приходилось править, конечно, что не переписал геройски по всему репо, так как «бизнес есть бизнес, детка»...
Я заметил что пишущие на React c CSS-modules молодые фронтенд-программисты часто как будто «экономят divы». И понятно почему: «якобы излишнее обертывание элементов в блоки в стиле БЭМ» это уже не модно и они просто так уже не мыслят. У нас сейчас наконец-то все просто и ясно, никакого творчества-отсебятины: блок это компонент, внутри — элементы строго как в дизайне, ничего лишнего, плюс надежный модуль стилей для каждого! Даже если эта надежность совершенно излишняя и запутанная, а нам, наоборот, нужна легкая и быстрая модификация, переиспользование. О том как бывает тяжело изменять такую надежность и как на самом деле эта святая простота выглядит в коде — я расскажу немного ниже...
Совет 2. Не «экономте <div>-ы»! Формируйте контейнеры-обертки, блоки, ну, или — вводите общие компоненты.
Магические кряки и хуки вместо просто хорошей верстки
Какой-нибудь очередной «манипулирующий с DOM» хук, например, опирающийся на «магические айдишники» (а ref-ы уже не получится использовать, так как у нас все в разных несвязанных компонентах) — всегда придет на помощь, даже если вместо этого нужно было вовремя осознать и написать один «лишний» <div> и простые стилевые правила к нему. Нет, мы не ищем простых путей, предпочитаем писать хуки на единственной технологии которую хорошо знаем и потом подбирать возвращающиеся баги когда эти кряки отваливаются. Не очевидное но важное заблуждение пишущих исключительно в описываемом стиле разработчиков в том, что сложный современный дизайн вообще возможно качественно и быстро «разметить» полностью избегая выделять отдельный слой глобальной стилевой абстракции и пользуясь одной только компетентностью, только ей ограничивая переиспользуемость. Может быть с помощью CSS-in-JS действительно удобно верстать некий строгий интерфейс с виджетами большой командой, в котором «рюшечки не важны». Но не, например, набор «бохатых-шикардосных» лендингов быстро с красивым размашистым дизайном и повторяющимися, но разнообразно модифицируемыми паттернами на них. Дальше я расскажу о том почему использование CSS-in-JS на подобных проектах это большая ошибка и мешает делать быструю качественную верстку.
Совет 3. Очень банальный, хорошо известен: делайте с помощью верстки все что можно сделать версткой. Делать плохую верстку для того чтобы потом фиксить ее хуками — это ненадежно, срывает сроки и общепризнанно плохой стиль.
Неадекватные сложности дизайнов, целям и задачам, срокам и бюджету проектов технологии
В дизайне очень часто встречаются модификации, отклонения, исключения — дизайнеры все очень творческие, в клиенты иногда — еще более творческие, и, главное — требовательные. Давайте поглядим что нам нужно было сделать раньше для того чтобы модифицировать набор стилей на некотором элементе, скажем так: на HTML с глобальными стилями на любом препроцессоре, псевдокод:
// Исходный стиль
.style {}
// Разметка
<div class="style" />
// Добавляем модификатор
.style {
&--mod {}
}
// Отправляем на разметку
<div class="style style--mod" />А теперь возьмем некий модный проект на, конечно же — передовых технологиях от bigTech-гигантов занимающих 80-85% рынка вакансий, например React [c GraphQL] + Flow (TypeScript это для умников, энтерпрайза и игры в долгую, понятно) + да и такое бывает, честное слово: SCSS + «стандартной технологии для защиты стилей» CSS Modules + Styled Component тоже прикручены.)))
Забегая вперед: то, что раньше действительно, без преувеличений — делалось за две минуты, сейчас иногда занимает полчаса и чревато сложноуловимыми неочевидными ошибками. Вот этот наш простой самый распространенный будничный прием при переиспользовании разметки — нужно из «конечной вьюхи» прокинуть класс-модификацию для специфической стилизации элемента на данном специфическом виде. Теперь нам нужно проходить через всю цепочку компонентов чтобы передать класс, при этом, слов нет, везде проверяя что это string с Flow и нигде не ошибиться. Давайте посмотрим как выглядит наш код, переиспользуемый компонент-шаблон в библиотеке @src/components/Template/Template.js, очень упрощенно, в реальности все намного сложнее:
// @flow
// Libraries
import * as React from 'react';
import classNames from 'classnames';
// ...
// Components
import TemplateChild from './components/TemplateChild';
// ...
// Styles
import styles from './Template.scss';
type PropTypes = {
children: React.Node,
classes?: {
root?: string,
child?: {
root?: string,
class1?: string
// ...
}
},
prop1: type,
prop2: type,
...
};
const Template = ({
children,
classes = {},
prop1,
prop2,
// ...
}: PropTypes): React.Element<'div'> => {
// Hooks
// ...
return (
<div
className={classNames(classes.root, styles.Root, {
[styles.RootMod]: prop1,
// ...
})}
>
<TemplateChild
className={{
root: classes?.child?.root,
class1: classes?.child?.class1
}}
// ...
/>
{ children }
</div>
);
};
export default Template;
Стили для него:
.Root {
// ...
&Mod {
// ...
}
}Индекс:
// @flow
export { default } from './Template';Дальше: общий компонент-вида в @views/View/components/Template/Template.js - да, да, именно так — с тем же названием, но во вьюхе:
// @flow
// Libraries
import * as React from 'react';
import classNames from 'classnames';
// ...
// Components
import Template from '@components/Template';
import ViewCommonChild1 from './components/ViewCommonChild1';
import ViewCommonChild2 from './components/ViewCommonChild2';
// ...
// Styles
import styles from './Template.scss';
type PropTypes = {
classes?: {
root?: string,
child1?: {
root?: string,
class1?: string,
// ...
},
child2?: {
root?: string,
class1?: string,
// ...
},
},
prop1: type,
// ..
};
const ViewCommon = ({
classes = {},
prop1,
// ...
}: PropTypes) => {
// Hooks
// ...
return (
<Template
classes={{ root: classNames(classes?.root, styles.Root, {
[styles.RootMod]: prop1,
}) }}
>
<ViewCommonChild1
classes={{
root: classes?.child1?.root,
class1: classes?.child1?.class1,
// ...
}}
/>
<ViewCommonChild2
classes={{
root: classes?.child2?.root,
class1: classes?.child2?.class1,
// ...
}}
/>
</Template>
);
};
export default ViewCommon;Плюс индекс, стили и еще целая папка-матрешка с глубокой вложенностью вот этого всего, в дочерних компонентах и так далее... Причем вот тут — на «общем верхнем виде» — все будет действительно очень плохо, безобразно адово — количество объявлений типов в PropTypes компонента будет стремиться к стопитцот — и чем больше модифицируется ваша вьюха на конечных видах — тем стремительнее...
Ну и теперь мы наконец можем слепить конечный вид для роутера — который будет все это использовать в @views/View/Reals/RealView.js:
// @flow
// Libraries
import * as React from 'react';
// Components
import Template from '../components/Template/Template';
// Styles
import styles from './RealView.scss';
const RealView = (props): React.Element<typeof Template> => (
<Template
classes={{
root: styles.Root,
child1: {
class1: styles.class1,
// ...
},
child2: {
class1: styles.class1,
// ...
},
// ...
}}
/>
);
export default RealView;Ну, и, конечно — специфические стили для этого конечного вида.
Что, правда? Мы же просто хотим передать один несчастный модификатор? Но видим запутанную сложную структуру, множество файлов, и нигде в этом лабиринте нам надо не забыть передать стиль, еще и проверяя что это строка? Это не только жутко выглядит, отнимает лишнее время, крайне утомляет и раздражает, так еще и просто совершенно бессмысленно по сути. Как будто мы сами «вставляем себе палки в колеса». Справедливости ради, в CSS Modules присутствуют минимальные возможности переиспользования кода, некой низовой абстракции, или можно, например, выделять глобальные стили. Но первое, по моим наблюдениям, обычно не используется фэнами данного подхода, как и, например, препроцессор, если он прикручен, но, в результате, по сути «задавлен Модулями». У нас есть «исходные классы переиспользуемых компонентов-прототипов» и при необходимости они с трудом перекрываются «переданными по цепочке» классами от конечных вьюх. Код копируется и раздувается, содержит одно и тоже. В глазах рябит от одинаковых селекторов на разных уровнях. Поиск затруднен. Для того чтобы создать и передать простой класс-модификатор мы вынуждены вносить изменения не в два (конечная разметка и стили), а, чаще всего, в целые цепочки файлов — это очевидно увеличивает риск конфликтов при мерджах. А я то ожидал что «все наконец будет в одном месте»? Как бы не так! Ты мечешься по огромной сложной запутанной системе компонент и стилей для них, пытаясь сделать то, что бы мог надежно и понятно для последователей сделать за пару минут с нормальным глобальным препроцессором или даже просто на CSS. Я не заметил никакой «защиты» [которая часто вообще просто не нужна] — те же самые конфликты специфичности по-прежнему возможны. Ну, то есть, мы просто теперь очень дико, странно и трудно делаем то, что раньше делалось очень просто. Какие такие «глобальные конфликты» возможны если писать на БЭМ обычную надежную верстку без прокидывания классов и проверки их типа и прочих танцев с бубнами? Зачем мне такая «полезная» технология, что она дает в случае вот нескольких похожих друг-на-друга, но, при этом, всегда немного разных «бохато-шикардосных» лендосов? Мне показалось, только очень сильно и очевидно мешает? Мне кажется это «заговором» против абстракции в стилях и «обычной верстки» — которая способна формировать дополнительный к компонентной структуре фреймворка, легко стилизуемый классами CSS слой. Клиент ждет от нас хороший дизайн, а мы сосредотачиваемся на сомнительном оверинжиниринге, который, вероятно, этому только мешает, пишем функционально-декларативный Реакт [с GraphQL] и самыми модными технологиями для стилизации, типизацией — прямо как на каком-нибудь курсе «синьор за 3 месяца» или хакатоне. Только когда все это сталкивается с реальностью и дизайном боевого проекта — становится даже жарче чем на хакатоне.)
Совет 4. Никогда не использовать React c CSS-Modules на проектах где нужна быстрая, но четкая верстка и переиспользование. Эта технология не дает ничего действительно нужного и полезного, но очень сильно затрудняет и ограничивает самые простые привычные вещи: блокирует препроцессор и эффективную модификацию оформления.
Ах, да! У нас же еще есть Styled Component, и теперь у нас уже «почти полный набор известных технологий для стилизации» — как «на выставке». Также как и Модули, SC ограничивают возможности стилизации и переиспользования верстки [исключительно компонентностью]. Да мы можем удобно, понятно перекрывать исходные стили модификациями по пропсу в самом компоненте. Но также неминуемо возникает проблема с доставкой этих модифицирующих пропсов и опять выглядит некруто. А если компоненты не связаны? Маппить со стора, через контекст? Совсем чудовищно, когда можно «просто нормально верстать». Кроме того, при использовании обоих технологий одновременно: хеши SC встают слева от хешей Модулей, перекрывая их, что еще увеличивает сложность, беспорядок, вероятность ошибок.
Совет 5. Никогда не используйте «все технологии сразу», даже если ваш коллега Вася привык и очень хочет, не знает препроцессор и так далее. Используйте только что-то одно, и именно то, что будет выгодно в контексте требований и сроков конкретного проекта.
Говоря о методологиях для разметки сразу вызывающих оторопь в контексте проектов со сложными нетривиальными дизайнами или же крайне сжатыми сроками, нельзя не вспомнить действительно древний подход не ассоциирующийся с мировым злом рептилоидами экосистемой самого популярного (почему-то здесь ассоциация с «продукцией» пивца Моргенштерна) ныне фронтенд-фреймворка Реакт. Это «утилитарный метод» получивший ныне свою вторую жизнь в качестве мейнстримно CSS-in-JS-ной реализации Tailwind с ее оголтелым слоганом-оксюмороном: «“Best practices” don’t actually work». Если вы видите на шаблонах нечто подобное:
<div class="ml-2 class1 pb-10 flex y_center class2" />
<div class="ml-2 mr-3 flex_wr class3" />Значит это оно! Я встречал проекты в которых авторы еще и «ловко», «умно» генерили утилиты с помощью хэшей/мапов и миксинов препроцессора. В этом случае — у вас даже нет шанса просто найти класс по поиску среди обычного списка в стопитцот утилит (зато вхождений на разметке — абсолютно точно будет стопитцот)... Но даже продвинутый Tailwind «который используют bigTech-акулы-гиганты», с его обещанными плюшками в виде небольшого размера бандла или даже передачей «атомарного тренда» в дизайне — весьма сомнительно что способен предоставить настоящую гибкость и эффективность в условиях нереальных сроков или меняющихся/недорисованных макетов — а оно очень часто именно так и бывает в жизни. В любом случае, если вам нравиться устраивать такой нечитаемый кромешный ад на разметке вместо идеального БЭМа — пожалуйста. Только не зовите меня когда макеты изменятся, «наконец приедут гаджеты» и надо будет «все переверстать».)
Совет 6. Не используйте утилитарный подход или Tailwind в случае горящих сроков и меняющихся или не до конца известных требований.
Дурная компонентность
Чаще всего, я вижу, что в уже распиленных проектах структура на верхнем уровне в @src/components — структура компонент крайне куцая и скудная (некоторые адепты Риакт еще, кажется, любили выделять «контейнеры» — но, имхо, им самим часто не до конца понятно — по какому именно признаку)) ). А на видах, наоборот — глубокая и чрезмерная, еще и с огромным количеством стилей. Изменения иногда создают проблемы, приводят к потере кода при мерджах, а наименование при этом как-будто специально стремиться еще больше запутать и сбить с толку. Я то вообще радикал, и считаю что виды вообще не должны содержать стилей, а компоненты в библиотеке — не должны обвязываться со стором. И, на самом деле, для того чтобы осознать почему это так, чем крайне выгодно — нужно просто вдумчиво-аккуратно написать несколько больших проектов.
Мне всегда казалось что самый надежный и удобный для быстрого поиска подход с React — когда мы стремимся дать компоненту уникальное для проекта имя, файл называется также, и кроме того — экспортиться и используется он точно по этому самому маркеру (конечно, в реальности бывают исключения из правила). Очень удобно искать и все сильно упрощает. Или, может быть, кто-то мыслит и читает репо только в маштабах одной актуальной таски, но не всего проекта? Работая со Vue/Nuxt, например, удобно ввести соглашение, что мы называем и используем в разметке кастомные компоненты только в PascalCase-стиле. А сторонние — в kebab-case.
На самом деле, в реальности — иногда ваши коллеги даже не пишут собственно компонент работая с компонентным фреймворком, и кажется, даже не совсем понимают что это такое, для чего именно нужно. Они просто копируют куски кода или целые файлы по видам, с проекта на проект. Недавно у меня был опыт на невозможно-переборно-авральном, но крайне важном, значимом проекте с коллегой-фуллстеком на 10 лет старше меня (а мне уже 40). Он начал с верстки двух похожих страниц-форм, содержавших множество полей ввода. Сверстал одну страницу «обычной версткой» — без использования компонент, и, при этом — игнорируя требования макетов/дизайн-системы относительно внешнего вида и поведения плейсхолдеров или сообщений валидации. Потом скопировал все это на другой роут, переименовал классы и немного видоизменил под макеты. Готово — «пока так сойдет». Когда я вежливо поинтересовался «а как называется этот потрясающий стиль программирования на фронтенде?» коллега принялся авторитетно поучать про «инкапсуляцию», и то, что «компонент это модуль»))... Через месяца полтора команда справилась с основным объемом и руководство с дизайнерами подняли вопрос что «формы выглядят не по макету»! Если бы изначально было потрачено на пару часов больше и аккуратно использовались компоненты — достаточно бы было внести изменения действительно — в одном месте — чтобы все легко поправить... Вот тебе и инкапсуляция!
Помню, один из моих бывших боссов рассказывал про знакомого, который прошел жесточайший отбор в Google на должность некоего важного директора в Долине. Через какое-то время он посетил родину, и кореша за пивком поинтересовались закономерным: «А что ты, твой отдел делает?». Персонаж открыл какой-то из множества сервисов и ответил: «Вот эту кнопку!». Вероятно, это была очень важная и сложная суперкнопка, безусловно. Но многим из нас не так повезло в жизни, и на текущих проектах приходится делать очень много разных кнопок-контролов и всего прочего, с самыми разными людьми, и в разных обстоятельствах, ситуациях...
Совет 7. Полезно стараться организовать как можно более плоскую и понятную, подробную структуру компонент на проекте. При этом удобно формировать некую вообще практически линейную максимально детализированную «библиотеку» переиспользуемых компонент, а на видах их использовать. В идеале виды вообще не должны содержать стилей, а компоненты в библиотеке — не должны обвязываться со стором.
Сегодня мы многое поняли
На самом деле, не рептилоиды Цукерберг мировая закулиса «написала четыре миллиона проектов» с отвратительной архитектурой, на сомнительных подходах-технологиях, с отвратительными кодом и версткой. Если в описанных выше подходах ты узнал свойственные тебе привычки и манеры, но при этом ты хочешь чувствовать себя разносторонним профессионалом на фронтенде, возможно — пора меняться, пробовать что-то новое/другое.
Комментарии (87)
PaulZi
08.11.2021 09:01+2С каких пор flex layout запрещен к применению в "крупных лейаутах"? При этом упоминая в одном предложении IE6-7-8-9 и grid-layout. Мне кажется автор просто не умеет готовить flexы, и теперь всех уговаривает ими не пользоваться, потому что у него все едет.
Особенно учитывая то, что относительно недавно гридов толком не было, и приходилось делать сайдбары либо на flex, либо на float)
ushliypakostnik Автор
08.11.2021 10:56-4Ну ок, наверное не умею... )) Курсов не кончал никаких, чисто гуглил только бегло по верхам)). Ехало не у меня, а в чужом проекте на который был написан ревью когда-то, послуживший основой... А насчет сайдбаров вот помню какое-то время назад переписывал за коллегой с гридов - на старый-добрый паддинг с relative/absolute - так удобнее всего мне кажется.
ChiDa
10.11.2021 00:46+1Вы бы, тогда, хотя бы поясняли свою позицию. Чем удобнее, в сравнении с гридами?
ushliypakostnik Автор
10.11.2021 00:57-1На самом деле - надоело уже метать биссер перед ... хабровчанами... Вот эти минусы все - я ванговал, конечно, но все равно растраивает - "тупая толпа" и тд... Но раз уж вы берете на слабо - потратил 10 минут и написал показательные примеры - не для того чтобы вас убедить - просто ради развлечения. Итак - пишем на HTML/CSS/pureJS - простейшие пример сайдбара:
1) Для начала - на гридах - думаю без объянений все ясно? Клиенты и дизайнеры очень часто хотят "чтобы была какая-нибудь анимация", правильно? Нажмите на кнопочку: https://jsfiddle.net/1jmfeb6d/44/ - дошло, нет?
2) Дальше - пишем 2 примера - по классике - железно-надежным дедовским способом который до сих пор лучше всех:
relative/absolute: https://jsfiddle.net/90xwfc8z/24/
и flexbox: https://jsfiddle.net/26dtur4j/17/
И тут и там все хорошо и анимация - пашет и даже на флексе - кода CSS - чуть меньше. Но это только кажется. Давайте попробуем чуть приблизить примеры к реальности и добавить контент и в меню и в "тело":
c relative/absolute - нам просто надо сделать relative/fixed - это будет удобно и часто так бывать как раз и "в адаптации" - на гаджетах: https://jsfiddle.net/9omr76tb/51/ - все хорошо!
и flexbox: https://jsfiddle.net/qykdnw31/25/ - дошло?
Достали, реально!!! Лучше бы азы учили и практиковались чем камменты строчить - теша свое ЧСВ.... (((((((((PaulZi
10.11.2021 01:47Ну как и предполагалось, вы имеете весьма скупые познания о flexbox. Чтобы анимация сработала достаточно добавить transition по min-width. Лучше бы не позорились, выставляя из себя д'артаньяна..
ushliypakostnik Автор
10.11.2021 03:02Хахаха, да ну кэп?.. Речь не о анимациии - проблема с анимацией была продемострирована как проблема с гридом, очевидно же. Добавить min-width в transition - я просто забыл - спать пора, а вы как "суперзнаток сеток и флекса"))) (умора) уже немного прокололись, так как должны были сказать что это грубо, "непофлексовски" и следует использовать flex-shrink: 0; для .page__sidebar вместо min-width в 2ух селекторах!!! Я же сказал - 2) - делаем "понастоящему" и добавляем контент! Пофиксите разную высоту у сайдбара и контента при скроле? Если не ответите - буду заслуженно считать вас ... сами знаете кем?
PaulZi
10.11.2021 09:26https://jsfiddle.net/fp96rq3L/
Код ещё больше сократился.
Надеюсь публичные признания, что вы были не правы будут? Хотя вряд ли.ushliypakostnik Автор
10.11.2021 10:51Нет, кэп, вы пока что достойны только унижения, имхо - извините, но это ради вашего же блага! Вы еше не дозрели, видимо, не много до необходимого инсайта, да и некоторые непроходимо на него бывают вообще не способны. И я вас еще только подвожу к нему - ибо то как пафосно вы юлите при этом - ну просто очень забавно... Вы серьезно считаете что align-items: stretch; невозможно нагуглить сразу за один запрос "сделать блоки одинаковой высоты на flex"? Тайное знание какое-то, доступное избранным?
Cиндром Даннинга-Крюгера?Давайте просто проанализируем UI/UX? Контент, требования немного изменились - в левом меню, например внезапно появились оверглубокие вложенные списки - контента может становится ну очень много. Дизайнеры хотят чтобы пользователь мог контролировать и "всю страницу" и "меню" - отдельно - когда овердлинные списки раскрываются - они не должны влиять на контент. Вот у вас же осталось правило:
.page__sidebar { ... overflow-y: scroll; }
Зачем? Оно же не работает и не будет работать с решением на align-items: stretch; и flex-basis??? В моем органичном примере с фиксед - все с самого начала так и есть - "хороший юзабилити" - может слышали о такой вещи - мы вообще - реальные специалисты - именно этим и занимаемся - "работаем для удобства пользователя", прежде всего, а не абстрактные примеры пишем на модных технологиях...Так вот - тот кто уже окончательно сел в лужу - пару раз оскорбив при этом человека с более глубоким и разносторонним опытом опытом который только пытался помочь зашореннуюму сознанию с завышенным ЧСВ - вопрос? Как можно в вашем последнем идеальном флексе "вернуть скроол в меню" и тем самым улучшить пользовательский опыт - сейчас в нем очевидно есть проблемы - например - пункт меню в конце списка - контента мало - либо то либо другое блокируется - нужно скроллить?
https://jsfiddle.net/8ocysztu/23/
Жду.PaulZi
10.11.2021 11:01Вы сами запутались и других путаете. С чего вы решили вдруг сделать sidebar фиксированным отдельно живущим от контента?
overflow-y: scroll; - забыл убрать
Если уж вы хотите делать фиксированный сайдбар, то тут естественно flexы не подходят, да и гриды особо тоже, тут напрашивается position: fixed.
PaulZi
10.11.2021 11:04В целом с вами всё понятно, продолжать дискуссию с д'артаньяном, не вижу смысла.
PaulZi
10.11.2021 11:09Ну и на всякий случай вот вам решение на флексах:
ushliypakostnik Автор
10.11.2021 12:08Вы в третий раз оскорбляете меня и тем самым показываете с кем и что именно понятно. Вы даже не читаете толков коментариев в дисскуссии и тут уже просто отмазываетесь - "специалисты" "с низкой ответсвенностью" - так себя и ведут: 1) речь изначально шла о лучшей технологии для разметки лейаута с сайдбаром 2) на гаджетах он и так чаще всего - фиксед - то что вы это не понимаете - значит нет реального опыта, 100%...
Обычно на странице бывает еще и футер. Добавляем в мое решение - просто добавляем контейнер и стили для него - и пусть он будет даже с "модным" position: sticky; (тоже выучили "такое сложное"? - но у меня вот в Эдж - "моргает") https://jsfiddle.net/48jesqLn/18/
А вы что будете делать? Еще обертки добавлять и модные правила?https://jsfiddle.net/u8jdhv90/50/
Может уже просто признать что вы ... ? С низкой ответственностью?JustDont
10.11.2021 13:02Эк бомбануло, так, что уже можно и взаимоисключающими параграфами начать крыть.
А вы что будете делать? Еще обертки добавлять и модные правила?https://jsfiddle.net/u8jdhv90/50/
Статья выше:
Совет 2. Не «экономте <div>-ы»! Формируйте контейнеры-обертки, блоки, ну, или — вводите общие компоненты.
Когда аргументам не хватает убедительности — можно возмутиться, что флекс у нас не умеет одновременно в строку и в столбик укладывать, да?
ushliypakostnik Автор
10.11.2021 13:17Передергивание чистой воды - в статье речь о стиле когда "вообще скелета и БЭМа-разумного нет"... А тут как раз пример из самого первого пассажа - "для разметки крупного лейаута - выбрали флекс - всплыли требования - крутим дополнительные контейнеры, все усложняем - где-то чтото начинает плыть и тд" - все как раз вот четко "по тексту"... Так ведь еще и потом в адаптации - автор начнет это все "отменять" - оставляя "чудокорячный флекс" только на десктопе, а для гаджетов отписывая "как у меня везде" - не излишне, эффективно? Для того чтобы делать сразу правильно и просто - нужно "знать где подстелить" или набивать шишки, да... Но в комментариях они не набиваются смотрю - бесполезно, тролли лучше знают и тд...
ushliypakostnik Автор
10.11.2021 14:09Да да да - о том и речь - в контексте фреймворка оно еще и точно будет в разных файлах, компонентах, свойства начнуть терятся и тд - вот эта вся мрачная история о которой в статье и рассказывал... По сути - мы вместо простейшей надежной и легко модифицируемой в самом критическом случае конструкции: fixed у одного элемента - и паддинга у другого - и обычного статичного потока с которым легко дальше работать - устраиваем цирк: - везде флекс изза которого мы начинаем "крутить обертки, добавлять свойства" и тд... Гореверстальщики.
ushliypakostnik Автор
10.11.2021 14:35@JustDontпоэтому продолжим развлекаться, а то видимо непонятно - обычно у нас еще и бывает фиксированный хедер у "всего сайта", правильно? Давайте добавим - в моем случае мы опять - "просто добавляем элемент - фиксед и паддинг основному контейнеру-странице":
https://jsfiddle.net/1rp65Lgo/
А у вас с флексом "с самого верха", вангую - еще оберткИ и сложность? )) hhttps://jsfiddle.net/on7qtsze/2/
Жду.
Заметьте, у меня структура сейчас - линейна - и модификации - практически не добавляют никакой сложности в структуру/стили, почти не затрагивают остальные элементы - все очень просто и понятно:<main class="page"> <header class="page__header" /> <aside class="page__sidebar" /> <section class="page__content" /> <footer class="page__footer" /> </main>
"Противоречие" - у вас в головах. У меня - опыт... Жду примера?
ushliypakostnik Автор
10.11.2021 15:21@JustDont и у вас, кстати в последнем примере - бяка-косяк "с обшим скролом страницы - в правом нижнем углу - с точки зрения UI - фиговенко - дизайнеры придерутся:
Плюс, конечно - еще расскажите насколько просто будет "мигом" перепилить все вот так: https://jsfiddle.net/oh3q7bue/35/
Ушли плакать, чтоле, @PaulZi???
PaulZi
10.11.2021 15:47Зачем кормить тролля? :)
Если нравится можете и на таблицах верстать, кто вам мешает.
ushliypakostnik Автор
10.11.2021 16:00Имхо, не только "Верстальщик", любой фронт должен уметь верстать на всем вообще - в том числе и на таблицах - в любой момент может понадобыться письмо - иначе он не фронт, а как вы - "флексер"-мракодел...)))... А опытный фронт - еще и обязан понимать - что именно и на чем уместно верстать - чтобы "потом не возращалось", не было проблем с внезапными хотелками и тд и тп...
В некоторых простых случаях для сайдбара для modern bro - допустимо применить флекс, конечно. Но простая статика - до сих пор - проще, надежнее и гибче. "Хакатон в песочнице" - вы с коллегой-флексером не вывезли. Если забавляться с этим дальше - совсем захлебнетесь - это уже очевидно - у меня 4 элемента в блоке, а у вас - понеслась по кочкам... А вспомните - начиналось то вообще "с грида", который оказывается "просто не анимируется"... ))) Поэтому тролли - это вы.
ushliypakostnik Автор
10.11.2021 12:26Смысл моих "поучений" выше в том, что опытные специалисты - которые каждый день имеют реальную боль - прежде вот от вот сомнительных экспериментов таких вот безответсвенных заносчивых комментаторов - делают просто и надежно с одной стороны, а с другой - так, что это можно легко модифицировать - без танцев с кряками, добавлением сложности и тд. А такие как вы - нахватавшись "модного" по верхам - лепят всякое - "лишь бы лепить". Как я заметил часто "ради своего экспириенса" - в ущерб проекту, результату, нервав и времени коллег... Ведь потом работодатели - зовут меня чтобы я вот это все вычищал и тд... Профессионал - не стремиться "выпендриться", а делает 1) надежно 2) гибко.
Это не про вас.
ushliypakostnik Автор
10.11.2021 12:54То что 2 блока внутри одного можно разместить по горизонтали с помощью:
1) классически - флоатами
2) с падингом "изъяв один из потока" - relative/absolute или fixed - как вам все равно придется сделать потом чаще всего для гаджетов
3) через inline-block - нюанс - без пробела между блоками в разметке - так наверное не умеете вообще - а я так много лет сетки писал "не только для modern", например https://github.com/ushliypakostnik/svelte-scss-router-i18n/blob/60f94e589f3f8b07771c693a58d67d691bbf11d4/src/styles/core/_grid.scss#L1-L66
4) флексом для modern
5) гридом для modern
Известно "почти всем" - сегодня - особенно 4 и 5, к сожалению. Проблемы начинаются потом, когда контент/требования начинают менятся, вы пишете гаджеты где ваш флекс уже не уместен и тд и тп... Человек с опытом - сделает сразу тупо просто и гибко при этом... А "безответсвенный" - будет дальше танцевать с бубнами для того чтобы выгородить свою несостоятельность...
dom1n1k
10.11.2021 03:05Можно-то можно, но это выглядит как костыль. Вообще говоря, с анимируемостью флексбокса действительно есть нюансы и устроено там всё неочевидно. Там неявным образом участвует flex-basis, который зависит сразу от многих факторов (от собственно flex-basis; от width, min-width и max-width; от контента и даже единиц измерения).
Так что именно для анимаций флексбокс — объективно не самый лучший выбор.
Другое дело, что пример всё-таки специфический, а в статье утверждения звучат намного более глобальные…ushliypakostnik Автор
10.11.2021 03:25Речь не только об анимируемости гридов и флексбокса... И чем это пример "специфический" то? Это самый как раз простой "старт", "рамочный прототип" сайдбара и даже "немного, чуть в развитии" - накидали блок и 2 элемента - решаем какой способ позиционирования использовать, что надежно и легко анимировать, как будет вести себя при разном контенте... Я же вот просто уже много лет - каждый день подобное пишу ручками и переписываю за вот такими "комментаторами" - от зуммеров-реактеров до престарелых фуллов так и не научившихся верстать - ((((... Ну и спор был, забомбило у массовки по поводу как раз гридов - которые вот действительно "просто не анимируются" тупо в данном случае как надо... Потом - сообразив что поплыли - "знатоки флекса" "уцепились за флексбокс" - но и тут в реальности проблем дофига - а мы только начали пилить минимальный пример... Такой сайдбар надежный (что есть собственно - "крупный лейаут") - делается "как деды делали" - вот так как я показал. Тем более что панель-меню еще - вообще и так должна быть [чаще всего] именно фиксед на гаджетах - "ездить" и "над контентом"... Но больше я писать сюда не буду походу долго - надоело пачкаться - оно того не стоит, мне за это не платят и противно вообще - как будто "во флекс наступил"...((((
Но вообще "история с сайдбаром" - да - очень показательная - в контексте общего смысла статьи - азов не знают - зато - флекс везде вообще, хуки на реакте, мрак на таилвинде и прочая ересь. А как "панель сбоку надежно привесить" - не понимают. Начинаешь объяснять - понты... Тьфу вообще...
jt3k
16.11.2021 08:47У меня к вам развивающие рассуждения, не по теме.
Вы пишете довольно грамотные вещи, но очень многословно и с огромным количеством не всегда понятных идиом. Сложно читать.
Ещё.
примеры на jsfiddle ещё сильнее отпугивают зрителя, потому что там разработчики забили на поддержку смартфонов, и поэтому там сейчас нечитабельно даже в ландшафтной ориентации.
Я уверен что до моего комментария дочитали процента 3 людей. По выше обозначенным причинам.
ChiDa
13.11.2021 00:33Ну раз не для того, чтобы меня убедить, то я даже читать не буду эти простыни ????
ushliypakostnik Автор
10.11.2021 01:14Бла-бла-бла https://habr.com/ru/post/587674/comments/#comment_23687996! Пишите больше камментов! ))))))
sfi0zy
08.11.2021 09:08+2Несмотря на провокационный характер текста – смысл в нем есть. Но я бы сказал, что все подобные советы можно в конечном счете свести к трем посылам: верстайте тупо, верстайте логично, и сознательно выбирайте инструменты под задачи. Если код тупой, последовательный, происходящее в нем понятно с одного взгляда при быстром пролистывании, логика использования компонентов продумана изначально, а возможности инструментов аргументированно используются для решения конкретных задач, а не “потому, что можем и вообще все так делают” — вероятность того, что с кодом будет просто работать, сильно возрастает. И что-то мне подсказывает, что эти посылы применимы не только к CSS. Да и не только к коду.
JustDont
08.11.2021 10:31Беда в том, что оно так не работает.
"Тупой логичный" CSS никогда не DRY. Просто потому что инструментов для этого нет. Итого вы написали тупо и логично, а дальше сидите меняете исключительно через полнотекстовый поиск по особым комментариям-меткам, которые вы расставили (расставили же? нет? упс) в тексте, чтоб в 100500 местах поменять один и тот же логически связанный параметр.На этом месте кто-то уже должен потирать ручки, готовясь написать "но у нас же теперь есть css variables!". И да, есть. И с ними и вправду становится немного легче, но не сильно: во-первых, для них нет нормальных средств отладки, понаворотили стилей с переменными и несколькими уровнями их перекрытия? Ну вот и разбирайтесь сами же, если что-то пошло не так. Во-вторых, нет средств раннего выявления ошибок — опечатались в имени переменных (а их будет оооочень много) — ну, сами виноваты, что сказать. В-третьих, за помещением переменных в правильный скоуп — следить нужно самостоятельно (соседние блоки в некоторых случаях могут нуждаться в инфе из переменной блока, а в этом случае её придётся вынести в некоторого общего для всех родителя).
Итого оно есть, но нормально не масштабируется, и попытка применить css variables для написания css без повторов — на проекте нормальных размеров тоже превращается в ад, просто другого сорта.Итого в пределе вынос css в код через css-in-js таки как-то работает (если взять нормальные инструменты и применять по назначению), потому что тогда стили подклеиваются к вашим "тупым логичным" компонентам, и всё плюс-минус нормально. А не существуют в виде чего-то отдельного, со своей модульностью (не обязательно совпадающей с модульностью компонентов) и своими проблемами.
ushliypakostnik Автор
08.11.2021 11:12-1Я смоютрю вы все еще хотите конструктива))... Кратко: нет, вы ошибаетесь - второй абзац целиком ошибочный-ложный, вероятно нет опыта, но пытаетесь как-то аргументировать чтобы оправдать такой-же ложный-ошибочный и недостаточно компетентный но насегодня вполне "мейнстримный" вывод в третьем. Как и все остальное - препроцессоры и компонентность - тоже "нужно уметь правильно готовить". Прочитайте если хотите разобраться мою предыдущую статью https://habr.com/ru/post/582638/?
JustDont
08.11.2021 13:04Пытаться одновременно быть "за" препроцессоры и "против" CSS-in-JS — это удивительнейшее двоемыслие.
С учетом того, что делают они плюс-минус одно и то же. Если вы возьмете нормальный CSS-in-JS, а не решение, в которое помимо этого еще полмира запихнули, как в SC.ushliypakostnik Автор
08.11.2021 13:44Я скорее - практик, коллега. И мне в моем адовом аутсорсе часто приходится писать и на том и на этом, на самых разных проектах... Дьявол - в нюансах, большая часть которых всплывает когда вы на этом пашите и горит и тд... "Делают одно и тоже", но по-разному же - об этом и статья...
JustDont
08.11.2021 14:40Я думаю, что не сильно ошибусь, если скажу, что тут в комментариях все практики. Едва ли кто-то из присутствующих сидит и пишет свой очень нужный тулинг для CSS, или пребывает на подобных архитектурных орбитах по каким-то другим причинам.
И вот моя практика — она как раз в том, что препроцессоры на практике могли бы работать (возможности все есть), но никогда не работают. Потому что человеческий фактор и очень уж легко все эти правильно выстроенные через препроцессоры (и/или БЭМ, или любое другое далекое от инструментального контроля решение) структуры просто сломать или постепенно испортить мелкими изменениями. Нанимать отдельного человека, который бы охранял стили от ухудшения и поломки структуры — это никогда не выход.
ushliypakostnik Автор
08.11.2021 17:16Ну это вот очень избитая точка зрения, говорю - еще под первой статьей пару лет назад можно найти такие выкованные опытной болью убеждения фуллстеков-тимлидов и тд... Вывод сомнительный крайне - и это очень часто как раз и есть, имхо, главная проблема команд, целых фирм в плане фронта - ниумеем, нипалучается, но и "знать не хотим" - дизайнеры в своей писочнице, мы мракоделим вообще как хотим, джуны - наверстают в компонентах... И все это "работает" только в определенных условиях - спокойный продукт-долгострой, простая вьюха... Чтобы реально хороший дизайн сделать - нужно "отдельного человека" нанять или можно просто - "на Бутсрапах" вывезти? Устал спорить, честное слово...
sfi0zy
08.11.2021 12:31Итого вы написали тупо и логично, а дальше сидите меняете исключительно через полнотекстовый поиск по особым комментариям-меткам, которые вы расставили (расставили же? нет? упс) в тексте, чтоб в 100500 местах поменять один и тот же логически связанный параметр.
Если у меня будет задача иметь именно в коде CSS единые константы для всего интерфейса (грубо говоря набор констант из дизайн-системы) — я подумаю взять препроцессор и воспользоваться константами. Они решат эту конкретную задачу. У них будут человеко-понятные имена (на опечатки линтер проверит), будет сразу понятно, что это, откуда и зачем. Возможно от этого код даже станет еще более понятным, чем был, т.к. некоторые логические связи между компонентами станут явными. Так что пример как-то не в тему моего комментария.
CSS custom properties дают другой функционал, работающий в реальном времени, очевидно отличный от констант препроцессора. Иногда он нужен, иногда — нет. В моей практике почти никогда не нужен, т.к. состояния компонентов задаются классами для состояний компонента, которые формируются на этапе разработки, а именно рассчитывать какие-то значения в CSS на лету уже не нужно. Хотя могу представить интерфейс, где это может пригодиться. Опять же — вопрос в задачах.работает (если взять нормальные инструменты и применять по назначению)
По вашему комментарию кажется, что вы отвечаете на вопрос, которого я не ставил. Вы и сами говорите, что инструменты работают, если их применять с умом и по назначению. И я про это говорю. А если не по назначению — то не работают, или по крайней мере не так хорошо, как хотелось бы. И я тоже про это говорю. Так что ваш комментарий вроде как спорит с моим, а вроде как и про то же самое.ushliypakostnik Автор
08.11.2021 12:38Мммм.... я вроде отвечал другому аккаунту... ну Ладно - половина первого, еще кофе не выпил - ничего не понятно... Да - технологии надо по назначению и задачам, все верно, конечно.
JustDont
08.11.2021 13:11я подумаю взять препроцессор и воспользоваться константами
Собственно доведенный до логически завершенного решения препроцессор — и будет CSS-in-JS по типу emotion. Принципиальная разница только в том, что CSS-in-JS может (но не обязан, смотря что и как в стили подставляете) иметь какой-то код в рантайме, а препроцессор не может.
Ну а непринципиальной разницы — куда больше, и вся не в пользу препроцессоров (свой нескучный синтаксис, свои нескучные инструменты разработки разной степени кривости и бажности, своя нескучная возня с тулингом… с какой же "любовью" я вспоминаю старый sass, который требовал второй питон и node-gyp просто для того, чтоб поставиться).Так что ваш комментарий вроде как спорит с моим, а вроде как и про то же самое.
Да нет, я с вами не спорил. Я всего лишь обратил внимание на то, что подход в лоб с CSS не работает, это таки свой отдельный язык со своей отдельной историей и своими отдельными заморочками (и ваш следующий комментарий про препроцессоры это только подчеркивает), который из-за всей своей отдельности может (но беда в том, что не обязан) неплохо стыковаться с компонентами, а может и не стыковаться.
dom1n1k
08.11.2021 13:24CSS custom properties дают другой функционал, работающий в реальном времени, очевидно отличный от констант препроцессора. Иногда он нужен, иногда — нет. В моей практике почти никогда не нужен
В моей картине мира css-переменные чаще всего используются для проброса какого-то свойства от блока к элементам. Часто бывает так, что у блока есть модификатор, который меняет некие свойства сразу у нескольких элементов. В традиционном подходе для каждого элемента нужно прописать каскадный селектор от модификатора блока. Это не то чтобы сложно, но может быть громоздко. А если возможны комбинации модификаторов, то последует комбинаторный взрыв. А можно завязаться на кастом-проперти, значение которой и будет меняться модификатором родительского блока.
ushliypakostnik Автор
08.11.2021 17:08Не сочтите за лесть, но заглянул на ваши публикации - крайне интересно, круто, великолепно просто! Вы первый человек на которого я подписался
в этой помо...на Хабре... У меня профили на профсайтах, кстати, тоже были раньше подписаны "Creative frontend developer", сейчас убрал про "творческий"... ))))
dom1n1k
08.11.2021 13:15Мне тоже показалось, что если очень захотеть и постараться понять автора, то там можно вычленить отдельные крупицы здравого смысла. Возможно, процентов 5. Но остальные 95 — словоблудие и сомнительные, мягко говоря, утверждения. Это при том, что я и сам не люблю CSS-in-JS.
ushliypakostnik Автор
08.11.2021 13:35Спасибо, кэп! И останусь при своем мнении что "сухих технических текстов" - нам каждый день хватает в насущных доках с головой... Поэтому, стараюсь вносить свою посильную лепту в этот скучный предсказуемый мир и журнал - писать для вас странные, личные и эмоциональные статьи которые 1) не реклама и 2) не убогая выжимка из очередного геттингстартед "как я тоже развернул проект на этом"... Щас я отхвачу еще минусов, но, походу все "чукчи" делятся на две группы которым друг-друга не понять: писатели и комментаторы, извините!))
hardtop
08.11.2021 09:36+2Какой-то очень водянистый способ изложения. Почему бы котов и прочие плакаты не заменить на сравнения "Плохо-хорошо" или "Было-стало"?
И чем так плохи flex-ы? Неужто float: left с clearfix-ами лучше? Да и pixel-perfect в эпоху адаптивной вёрстки и экранов разной плотности пикселей немного странное стремление. Тут надо с заказчиками и дизайнерами разговаривать. Обычно в 95% это работает.
Попытка написать супер-универсальную систему приводит к сильному смещению баланса "гибкость-шаблонность" в сторону шаблонности. Типа, бутстрапа. Да, накидать быстро что-то можно, но шаг влево - и ты роешься в документации и стековерфлоу. И это популярная вещь с доками, примерами и сообществом. Не просто так появился ненавистный Тейлвинд (хотя он мне тоже не нравится).
ushliypakostnik Автор
08.11.2021 11:05+1Спасибо за каммент, но картинки, имхо огненные, хотя минус за оформление я уже опять отхватил - ((((...
Флекс не плох к месту и умело приготовленный... Статья написана о проекте в котором как-то удивительно переборно было с этим...
А вот с этим не согласен совсем: "Да и pixel-perfect в эпоху адаптивной вёрстки и экранов разной плотности пикселей немного странное стремление." - во-первых стремление не мое, а некоторых клиентов. Во-вторых - вообще непонятно а чем вам адаптивность и плотность пикселей мешает сделать точно по макету? Просто поставьте плагин и потренеруйтесь - на соответсвующем проекте - где это нужно-важно - это не сложно на самом деле как раз сейчас - делать так чтобы было везде одинаково-идеально.
По поводу "всяких бутрапов" - мой предыдущий текст, взгляните: https://habr.com/ru/post/582638/.hardtop
08.11.2021 11:50+1Да, предыдущую статью читал. Смотрите, постараюсь объяснить. Вы сделали своё логическое деление вещей, которое понятно Вам. Но чтобы другому человеку проникнуться этим - нужна внятная документация.
Сравнивая примеры того же бутстрапа, где есть variables.scss, миксины и стили, разбитые по компонентам и Ваши примеры, где есть тоже разбиение, но с другой логикой и под другим соусом - я не понял сильной разницы. Получилось сложно и запутанно.
ushliypakostnik Автор
08.11.2021 11:55Мне кажется что вы не до конца поняли основной посыл - это, конечно - прежде всего ко мне вопросы, к моим текстам, согласен... Бутсрап - это набор готовых шаблонов с крайне ограниченной стилизацией. А мой подход сейчас напротив: "никаких бутсрапов - только кастом!") - я считаю что код нужно писать максимально самому и писать аккуратно... Ну ладно, проехали...
Jack_Rabbit
08.11.2021 10:36+1Я не вижу большой проблемы в использовании flexbox. Проблема на самом деле в том, что не все в полной мере понимают как это работает и как нужно этим пользоваться.
Без flexbox тоже можно жить и выравнивать элементы по-старинке через inline-block, table-cell и прочие float, но зачем?
Что касается Tailwind и прочих схожих фреймворков, то их основная проблема заключается в том, что задача стилизации переносится с уровня стилей на уровень представления, где ее зачастую сложнее решать. Естественно, что это вносит дополнительные ограничения и более тесно связывает модуль с его стилями, что далеко не всегда хорошо.
ushliypakostnik Автор
08.11.2021 12:10Спасибо за каммент! Я с вами согласен и, кажется, совсем не призываю жить без флексбокс!)
Ilusha
09.11.2021 01:16tailwind можно не использовать напрямую: можно мержить стили из tailwind-классов в свои.
Да и его назначение больше не в шорткатах для стилей, а в предоставлении документированной css-системы базового поведения. Которую можно переопределять.
Но у tailwind-классов в представлении есть бонус: читая верстку сразу видим ее структуру не обращаясь к файлам стилей и т.п.
А если говорит про ограничения, то это вопрос паттернов использования.
ushliypakostnik Автор
09.11.2021 01:58Ну и "в Гугле, Фейсбуке и тд используют - чем мы хуже, да"? На мой скромный взгляд вы говорите какие-то чудовищные вещи "можно мержить стили из tailwind-классов в свои" ??? Что, зачем? Можно пример, пожалйста чтобы я понял о чем речь - я тупой дизайнер вообще с деменцией?...
Дальше еще непонятнее, какая-то посторонняя сомнительная фича чтобы "ее переопределять"? А не проще "все свое" - но лучше не будем - я за день и так отгреб минусов и тд...
Дальше - еще одно таинственное заклинание - о какой структуре то речь? На мой вкус и цвет "хорошая верстка" - должна выглядеть как-то так: https://github.com/ushliypakostnik/ui-library-starter/blob/master/src/components/Input/Input.vue - ну тоесть - не должно быть "никакой структуры о которой нам нужно знать" какбэ - еще и используя некий неудобный левый хромой костыль...
Мне тут один ПМ рассказал что у него любители Таилвинда - постоянно срывали сроки на проектах в ПЯТЬ раз... Впринципе все что мне надо об этом знать...Ilusha
09.11.2021 11:46Вы не знаете tailwind. Не понимаете его. Но почему-то критикуете. Я не буду тут распинаться и что-то доказывать. Точно так же вы не умеете во flex. Этот называется лудитство.
Срыв сроков в пять раз из-за.. CSS? Со слов ПМ? Этот аргумент забивает последний гвоздь в крышку гроба хоть какого-то серьёзного к вам отношения.
ushliypakostnik Автор
09.11.2021 12:31А вы не понимаете верстку и фронтенд, судя по всему - играете в навязанные корпоративные игрушки и не имеете ни собственного разностроннего опыта, ни своего мнения по вопросам - ну так воображайте дальше, срывайте сроки, пишите камменты - но лучше все-таки не под моими постами - а то утомили. Очень показательно у кого под этой статьей бомбит - можно просто по акам посмотреть, а кто пишет что "провакационно, но смысл есть", например... Мне совсем не нужно "серьезное отношения" к себе от якобы "специалиста" "любителя Таилвинд". Таких как вы я просто выгоняю сразу с проектов - чтобы не мешали и вычищаю весь код сколько бы его не было - начисто.
Flex он "познал", а... Где вас таких берут-делают то...Ilusha
09.11.2021 12:52На любую критику у вас нытье, словоблудство и фантазии.
Дед, прими уже свои таблетки.ushliypakostnik Автор
09.11.2021 13:02Очень хорошо показываете себя. Ваш сбивчивый путанный рассказ о единственной убогой пластмассовой игрушке которая вам заменяет реальные знания и опыт - это критика? ))) Слезу - так выбить можете, надавив на жалость, но не серьезное внимание. Утомили - честно...
jt3k
09.11.2021 09:22+1Идите троллить в другое место.
tailwind можно не использовать напрямую: можно мержить стили из tailwind-классов в свои.
Это выглядит стрёмно. Вместо нормального цсс там предлагают писать `@apply class2 brder-r-4x sx-dotted some other-21 shit`
Но у tailwind-классов в представлении есть бонус: читая верстку сразу видим ее структуру не обращаясь к файлам стилей и т.п.
Это не бонус. Чем это отличается от обычного подхода? Кроме повышения когнитивной нагрузки такой способ ничего не даёт.
Ilusha
09.11.2021 12:05Это выглядит компактно, но дико на первый взгляд.
1. Размеры и отступы. Когда у тебя верстка по сетке и все размеры относительны базовому числу, то уже сам генеришь себе шорткаты xs/sm и т.д. А когда сюда подключается зависимость от брекпоинтов для лучшего адаптива, то без этого уже просто сложно.
А если у тебя сетки нет, то и tailwind не нужен.
2. Цвета, радиусы и другие визуальные части, которые дизайнеры меняют сразу везде: это опять глобальные классы, которые удобно подмерживать.
3. Шорткаты поведения (flex и т.д.). Здесь уже проще: их использование в верстке дает только наглядность во время разработки: сразу понятно что за элемент и как будет себя вести. Это вкусовщина.
ushliypakostnik Автор
09.11.2021 12:40Вы разговариваете сами с собой. Чем человек невежественнее некомпетентнее, имеет меньше опыта, тем агрессивнее он старается убеждить всех вокруг "в своей единственной истине" и "самом правильном подходе" - это просто рефлексия и вытеснение компенсирующее ваше нежелание учиться и менятся, экспериментировать, творить самому... Все о чем вы говорите, например - было в вебдизайне задолго до Таилвинд и будет всегда когда этот печальный обморок-недоразумение уже все забудут... Все это - реализуется намного проще и более гибко, эффективно и эстетически удачнее - другими подходами.
Jack_Rabbit
10.11.2021 16:56+1Если объединять стили из Tailwind в свои, то получится тот же CSS с теми же проблемами, но с ещё одной ненужной зависимостью.
Но основной недостаток Tailwind заключается в отсутствии компонентного подхода на уровне CSS. Фактически он переносит эту проблему на уровень разметки и логики шаблонов.
Приведу простой пример. Есть простая секция с картинкой слева, а также заголовком, текстом и кнопкой справа. В случае с обычным CSS можно создать множество классов модификаторов, которые будут менять вид всей секции (порядок расположения, размер и выравнивание текста, стиль кнопки). Это поведение можно расширить с CSS переменными и добавить поддержку тем на уровне секции. Для темного фона текст будет светлым, для светлого фона - темным.
Иными словами, на уровне разметки нам нужно просто добавить один или несколько классов к секции, чтобы полностью изменить ее поведение. Основная логика преобразований будет в одном месте в CSS.
В случае с Tailwind эта проблема переносится на уровень шаблонов. Грубо говоря, условный JS или PHP должен содержать всю логику для добавления утилитарных классов, чтобы изменить порядок следования элементов, компенсации отступов, корректировки полей, а также обработки граничных ситуаций, когда, например, нет картинки, вместо одной кнопки - две, или вместо картинки у нас iframe с видео. Отдельная история - это темизация.
Поскольку ни JS, ни PHP изначально не создавались для таких манипуляций, у нас будет огромное количество кода с условиями. Это сложно читать и практически невозможно поддерживать.
ushliypakostnik Автор
10.11.2021 17:05Спасибо за каммент! Все так, все так... Тут у меня "вьетнамские флешбеки" на то как много-много лет назад, когда я начинал, конечно же - "с Бутрап" - писал скрипты с джиквери чтобы в ресайзе сетку на кастомный брекпоинт перестроить - вот всякое такое...
Ilusha
11.11.2021 22:17tailwind - это про статику. Не нужно условий в js/php: это инструмент для генерации статики.
Это просто добавление слоя абстракции: конфигурируемые утилитарные классы, которые содержат распространенные наборы стилей.
Можно писать точно такой же CSS/SCSS: каскады и т.п.
Но сравнивать лучше с SCSS: мы то же самое можем делать переменными. Только в случае tailwind у нас есть "пресеты" заполненных свойств, которые мы можем применить как элементу, так и классу.
Т.е. мы можем пользоваться сочетанием трех инструментов: css, scss и tailwind-классы. Причем из сборки выкидываются неиспользованные.
Т.е. без tailwind мы пишем, условно:<button class="myClass">
.myClass { border-radius: $border-radius-sm; }
А с tailwind<button class="myClass">
.myClass { @apply rounded-sm }
Или<button class="rounded-sm">
Если обсуждать контекст цветовых схем (тем), то он из коробки решается следующим образом: к элементу добавляются два класса: обычный и второй с префиксомdark:. Переключение может достигается добавлением одного класса в корень.
tailwind никак нас не ограничивает в возможностях, но предоставляет инструменты укладывать стену не по одному кирпичу, а по N сразу.dom1n1k
11.11.2021 23:08Я как-то писал, что TW — это дополнительный кодовый слой, но уровень его абстракции не выше, чем у любого CSS-препроцессора (наоборот, ниже, потому что там есть миксины и прочее). То
пятое колесолишняя зависимость.
habr.com/ru/post/508844/#comment_21803906Ilusha
12.11.2021 13:52Этот слой выше CSS, но ниже препроцессоров.
И я нормально отнесся бы к TW, если бы его преподносили именно как библиотеку вспомогательных утилит
Здесь я с вами согласен. Только я изначально так его воспринимаю :)
deni5n
08.11.2021 11:13imho, "фрейвмворки" с их декларативностью задумывались как раз для того, чтобы один раз "привыкнуть" к кажущейся на первый взгляд ментальной сложности, а потом собирать из их инструментария проекты быстрее и эффективнее. причем именно эффективнее, т.к. один к примеру супер верстальщик ушедший с проекта "без фрейвмворка" , ставит его на паузу пока не найдется такойже высококлассный (без преувеличения специалист) , в то время как проект использующий какой либо стандартный инструмент продолжается, т.к. на условном рынке всегда есть "мидл" с соответствующей подготовкой. возможно вы просто как раз тот самый высококлассный специалист, познавший обе стороны, но не осознающий потребностей бизнеса (это весьма субъективное предположение, позвольте ему вас не расстраивать, если оно к вам не относится)
ushliypakostnik Автор
08.11.2021 11:18Если честно, то не совсем понял ваш комментарий? Причем тут "фреймворки"? Любая из перечисленных в статье технологий "для оформления" - осваивается целиком за полдня? Я скорее про то что на рынке как раз стало "слишком много" уже "почти синьеоров", ну ладно реально - если фулл, но "чисто фронтов" - которые знают один главный раскрученный фреймворк, имхо далеко не самый лучший, самую дурную технологию для офомления и больше ничего и знать особо не стремяться... Чтобы быть полноценным специалистом - нужно знать и базу-азы, уметь сделать нативно и современные фичи пробовать разные... Это все банально же...
amvasiljev
08.11.2021 11:18Стек команды всегда будет форматировать стек члена команды и данная статья не будет воспринята командой.
Использующим bootstrap эта статья не зайдет.
Начинающим - возможно поможет, хотя "табличную верстку" они вряд ли будут изучать, как и пытаться понять отличие блочных элементов от строчных.
Стек "солиста", независимо от личной успешности, всегда будет его стеком. При этом неплохо было бы верстальщику-индивидуалу понимать, что в будущем написанное им будет обслуживаемым и масштабируемым, как им самим, так и другими людьми.
Делать индивидуальные работы так, чтобы в процессе обслуживания/масштабирования у других людей не возникало устойчивого желания написать все с нуля, вместо попыток погасить авторские css-цепочки через !important - к этому я призываю коллег, независимо от используемых ими технологий )))
ushliypakostnik Автор
08.11.2021 11:23Ну "используюшие бутсрап" - впринципе не занимаются "хорошей версткой" - предыдущую мою статью посмотрите на эту тему - эта о том "что плохо", та - "что хорошо", как надо.) Статья действительно, по моей задумке может быть полезна начинающим, чтобы выбрали "правильную сторону в этом", но совершенно не соглашусь со следуюшими утверждениями: "хотя "табличную верстку" они вряд ли будут изучать, как и пытаться понять отличие блочных элементов от строчных.". Без второго, имхо - вообще невозможно верстать. А письма - пока что еще никуда не делить по сути со своей табличной версткой. В любой момент на любом моменте вас могут попросить сверстать письмо для рассылки - и если вы профессионал - придется предметно и дотошно разобраться, это не сложно и информации полно.
mrG0bliN
08.11.2021 11:24+1flow? =) статья троллинг, автор байтит на батхерт ньюфагов ????
ushliypakostnik Автор
08.11.2021 11:28Ну есть, наверное, немного, в этом вы правы, конечно - доля "здорового троллинга", имхо - вполне может и даже должна присутствовать в огненно-бомбической статье)... А вот по поводу flow вы не правы - в самом начале статьи поясняется что переработано из реального код ревью написанного несколько лет назад... Да и вот оно меня самого поразило это все - о том и речь...
Mike-M
08.11.2021 14:39+1Просьба к автору разбивать текст на абзацы. Сплошная «простыня» тяжеловата для восприятия.
ushliypakostnik Автор
08.11.2021 14:43Да, спасибо за каммент! Походу вообще у многих на Хабре - когнитивный диссонанс от витиевато-размашистого гонзо! ))
engine9
09.11.2021 10:27Потому что нужно учитывать то, что на ваш текст читатель выделяет какое-то ограниченное количество ресурсов мозга и внимания. И если он не в виде удобного для потребления блюда, а в виде полуфабриката, то его проще дропнуть и переключиться.
Но не примите мою реплику как наезд. У меня нет знаний и компетенции, чтобы оценить техническую сторону, я просто не разбираюсь в теме.ushliypakostnik Автор
09.11.2021 10:40Да, ок, ну а скажите - в скелетную аннимацию вы умеете?
engine9
10.11.2021 21:06Отчасти да, могу роботов анимировать и всё такое. Забавно, я ваш комментарий прочёл в почте, как раз делая перерыв между занятиями по скелетной анимации.
ushliypakostnik Автор
10.11.2021 22:53Ого, офигенно, просто - давайте общаться? Да, можно было бы и в личку задать вопрос, но пусть здесь будет... Да, я по поводу https://habr.com/ru/post/556238/ - ну и там совсем простые минимальные фичи нужны, но которые могут быть интересны соответствующему спецу "для творчества-тренировки"... И я, при этом, даже готов платить чтото адекватное - как договоримся... Технологически в контексте "фронта" тот проект уже не особо актуален - я тут стал на Vue3 + TypeScript - стратегию писать - вот задумал ремейк на Dune 2/2000 "из детства"... Но просто даже - найти выход на человека который может простые модельки красивые делать и анимации для них прописать - это очень ценно - я сам уже давно "не дизайнер" уже похоже совсем! Давайте на днях в телеграм свяжемся - мой ник @ushliypakostnik - напишите мне? Ни по знакомым, ни под статьей о первом эксперименте - под которой было много аплодисментов от коллег - но ни одного "аниматора" - не нашлось...
Fyll97
08.11.2021 14:47+1Со многим согласен в статьи. Но есть огромная проблема в автора - вода:)
Знаете чем отличается полезный материал от хренового, его можно понять и использовать на практике:)
Сдесь огромная проблема с осуствием примеров (вроде только один пример на 5 утверждений) це еслиб я сказал для здоровья нужно кушать орехи, танцевать ночью под луной на кладбище, голосовать за партию Серых и смотреть Игру престолов ну главное зарядки по утрам ведь доказано что это продливает жизнь на примере жителей Японии. Думаю понятен пример? Только у вас ещё хуже выглядит через форму подачи я Дарьтаньян а все остальные долбоебы (довольно честно бывает правда, но вы пишите статью для них и смысл тогда их обзивать !? Це как Моргенштерн только в вашем случае вы тоже не очень разумны )
ushliypakostnik Автор
08.11.2021 14:53Спасибо, особенно за сравнение с
уё..идолищем и с Днем Рождения Гражданской Обороны!) Вот тут и тут можно мое никому не нужное музло заценить - я им всю сознательную жизнь и в 2 раза дольше чем разметкой балуюсь! )) Ну я "всегда буду против" и вообще не стараюсь никому угодить какбэ - "я так вижу и чувствую", и, мне кажется - тем и ценно, забавно... Конкретно эта статья, имхо не нуждается в занудных-скучных примерах - "помочь зуммерам осознать что есть еще варики-альтернативы кроме солей" ну и вообще - "первый раз влететь в минус" - ждем вечера )))
Klvld894
08.11.2021 21:28О Боже и сюда моргенштерна приплели
ushliypakostnik Автор
08.11.2021 21:28Ну в статье о том "как верстают зуммеры" - не могло не быть упоминания...
Aleksandr-JS-Developer
09.11.2021 09:17Вывод: удаляем React и верстаем на float
ushliypakostnik Автор
09.11.2021 10:38Вот вы шутите, а на самом деле иногда плакать хочется и пичаль. Да, имхо для некоторых самых обычных коммерческих кейсов совершенно необходимо уметь на сверстать "нативно" на HTML/CSS/pureJS(ну или jQuery), ну или например испольуя какию-нибудь сборочку https://github.com/ushliypakostnik/webpack-start - престареллый фулл-лаварельщик - еще справиться, а вот зуммеры-реактеры - нет...
JustDont
Хорошая шутка.
Без флекса ничего не едет, точно. Вот как прописали всему фиксированную высоту — так с тех пор и не едет. Зум в браузере поменяется? Шрифты клиент заменит? Не. Не едет.
Ну а что у человека текст из блоков выпадет или пропадет — это неважно. Главное ведь что не едет ничего.
Над этим можно было бы даже посмеяться, но когда в реальности тебе говорят, что CSS с сотнями calc() (а то и без них, просто ни одно число нельзя в отдельности поменять, ибо разметка летит) это прекрасно, а флекс это фу-фу — тут на самом деле оплакивать надо, способности некоторых отдельных верстальщиков.
Это даже не говоря про то, что зафиксировать размеры флекс-блока — нисколько не сложнее, чем сделать то же в отношении простого статичного блока. Но куда уж до таких тонкостей, когда главное "простые классические приемы" ввернуть.
ЗЫ: Я бы и по остальному тексту приложил, но когда тебе предлагают в 2021 году в пример Flow — это сильно смахивает на толстый троллинг. Да и SC, надо сказать, сильно небесспорная инкарнация CSS-in-JS, чтоб выискивать минусы именно в нем. Но общая мысль текста "ну прост вы тупые и не можете делать сразу всё правильно через простые буковки (БЭМ), ишь чё удумали со своим переносом стилей в код" — она тоже… великолепна. Как говорится, пацаны-то и не знают — нет чтоб просто делать всё правильно, а неправильно не делать. Сидят усложняют чё-то.
Ilusha
А Вы обратили внимание на выпад:
ЧСВ зашкаливает. Д’Артаньянщина. Давненько я такого не видел.
ushliypakostnik Автор
Не Д’Артаньянщина, а Гамбарянщина)... Да мне не жалко и "какой есть", от себя не убежишь.))) И за "Давненько я такого не видел." - искренне - спасибки! Ради такого каммента стоило убить выходной. Согласен - скучно все и не цепляет. Я вот на Хабре - ни разу каммента не написал, только четыре уже статьи. ))
ushliypakostnik Автор
Ого, ожидаемо - понеслась выставка тщеславия "знатоков CSS"! ))) Если честно, ваш коммент сложно воспринять в 3 часа ночи - ибо поток сознания некоторый... Но, во-первых - у меня никогда и ничего не "едет", хоть с SC, хоть с Модулями, хоть с чем - потому и пишу... Во-вторых, кажется вы передергиваете - про "2021" - точно - в самом начале же написано что статья переработка реального старого - несколько лет прошло - код-ревью... А можно вашу статью прочитать какую-нибудь чтобы у меня тоже забомбило, или проектик какой самостоятельный поглядеть необычный?
dopusteam
Вам для этого комментария вроде хватило)
Вообще, было бы хорошо конструктивной ответить
ushliypakostnik Автор
Простите за мою неконструктивность, но перечитывая ваш каммент - никак не могу сконцентрироваться, вдохновиться и решить что именно и насколько подробно отвечать - и если отвечать, то надо писать длиннющую простыню на пару часов - еще одну статью по сути - со мной всегда так... Да и минусуют меня за неконструктивность и ЧСВ... Вот, смотрите, я когда черновик статьи стал собирать - там "похожие" показывает - вот с этой угорел вообще https://habr.com/ru/company/vk/blog/319956/ - правда старенькая, но пишут что SC - это вообще венец эволюции CSS!!!???? Что дальше?... Вот даже в технологиях - мнения, опыт - разные, а верстка так вообще достаточно гуманитарна, за что ее и люблю всю дорогу, например...