Непонятно зачем в 5 методе приплетены странные рассчеты, после которых автор жалуется что минус в том что у нас теперь внезапно матан и рассчеты.
Вот например такой рабочий пример без чего бы то ни было, что можно было бы назвать гордым словом — рассчет, примерно такой же как выше в комментариях, но с еще большим количеством нового синтаксиса, чтобы скучно не было:
const averagePopularity = (arr) => {
const [sum, total] = arr.reduce(([sum, total], { found, popularity }) => {
if (!found) return [sum, total];
return [sum + popularity, total + 1];
}, [0, 0]);
return sum / total || 0;
};
Такие то вы дефицитные, что даже у яндеса найдется десяток людей на ту же вакансию с соразмеримым уровнем, но куда меньшим чсв, чем у вас, не говоря уже о гуглах и им подобных. Продолжайте кукарекать о своей незаменимости.
Давайте их пожалеем?
Эх, сейчас бы помечтать о том как мой будущий работодатель будет тратить уйму денег ради оплаты чсв кандидатов, которые приходят на интервью почесать оное чсв, а не на повышение зарплаты работникам, которым я, как настоящий кандидат, вроде как собираюсь стать.
Впрочем, если не собираюсь и не имею достаточно эмпатии чтобы поставить себя на место такого кандидата, то да, я могу вредных советов насоветовать, попризывать не жалеть бедненькие компании.
Соответственно, не понятно в чём тут экономия времени для кандидата, если его будут больше собеседовать.
Уровень понимания и осознания написанного на абсолютном дне. До ковида — телефонное интервью плюс переговоры с рекрутером + Полеты туда-сюда до Москвы/Питера/etс. отнимающие больше суток. После ковида — чуть больше онлайн интервью чем их было бы на месте. Экономия очевидно на сутках потраченных на полеты туда-обратно, плюс-минус пара часов здесь вообще ни что не влияет.
Ну, в том то и дело, что то было до ковида. Если компания оплатит перелёт и проживание, то можно и 8 часов лично собеседоваться, тут нормально всё.
При этом вы все равно потратили больше суток своего времени и не получили на выходе никаких денег в кармане, только оффер или нет.
Без полетов вы потратили условные 4 часа, и на выходе получили оффер или нет.
В первом случае вам типа норм, а во втором вам типа недоплатили. Задумайтесь, не унюхиваете маразм и отсутствие логики?
они ничего не тратят кроме денег на зарплату интервьюеру.
А это как бы мало? 4 условных интервьера плюс-минус, каждый тратит какое-то время на подготовку интервью с вами, само интервью, потом пишет отзыв, каждый тратит на вас в среднем допустим часа 3. Потом рекрутер сколько своего времени тратит, я не знаю, но пусть допустим еще 3.
А сколько еще затрачено на отвлечение программиста от непосредственной работы в плане уменьшения его производительности за счет отвлечения на интервью с вами? Можно еще по часу накинуть. А время изначальной подготовки каждого программиста к интервьюированию? Пару десятков часов, которое потом будет окупаться и размазываться по всем интервью. Думаю далеко не каждый программист за все время работы в яндексе проведет хотя бы 20 интервью чтобы подготовка размазалась хотя бы до часа. Но пусть будет 20 в среднем, еще час можно накинуть.
Итого получается 4 интервьюера * 5 часов зарплаты на каждого, плюс время рекрутера. На этом фоне оплата билетов и гостиницы даже не удвоит эти траты для компании. А вот вы при полетах в несколько раз увеличите затраты своего времени.
Вы заранее до интервью знаете что это займет несколько часов, хотя бы 2-3, оплачивать которые вам никто не собирается. Это абсолютная клоунада, когда вы ожидаете что по-хорошему каждому из сотни людей на вакансию надо оплачивать его время. Или из десятков, которые доходят до интервью. Компании и так тратят на каждого кандидата куда больше денег, чем требуется потратить от кандидата, в десятки раз больше даже с таким потоковым подходом к интервью.
Надо хоть немного совести иметь и понимать это, а не жаловаться что все про все заняло на 1-2 часа больше времени и бугуртить до уровня написания поста на хабр.
Еще надо понимать что собеседования по удаленке куда сложнее для интервьюера чем лично, поэтому очевидно что их надо больше чтобы лучше понять что за человек пришел. Очевидно это временно. Очевидно что винить компанию за это крайне несправедливо.
Если кто не в курсе, то до ковида яндекс и так при приглашении на личные интервью покупал вам и билеты на самолет и гостиницу оплачивал. Требовать чтобы еще больше они вам что-то компенсировали это вообще тотальная наглость. Что они вам еще должны, оплатить пару дней на уровне реальной зарплаты? Рожа, извините, не треснет? При ковиде теперь то конечно не лично получается, но и время вы экономите не собеседуясь лично.
На каждого программиста, который считает что ему все обязаны, найдется не менее десятка сравнимого уровня тех, кто понимает что ему эта конкретная вакансия нужна больше, чем он нужен компании. И кто готов «потратить» десятки, а то и сотни часов на весь процесс прохождения на желаемую вакансию в желаемую компанию. И я лично рад что такие как ОП, а также неготовые потратить несколько часов бесплатно, отсеиваются в описанном процессе найма. Классическая фича, а не баг.
Да, 4 часа это много когда вы и не собирались устраиваться на работу, а пришли поразвлекаться.
Реальная работа это, извините, сommitment и от вас и от компании на как минимум много месяцев или даже уже лет, плюс с большим количеством денег на кону.
Жаловаться что вас крутят 4 часа по алгоритмам это показать свое непонимание процессов найма, их практичности, неумение оценки реальности внедрения более «правильных» с вашей точки зрения процессов найма, неуважение к людям выстраивающим этот процесс за счет отметания с ходу вероятности того что возможно это именно вы что-то неправильно понимаете.
Даже если бы вы решили идеально все представленные задачи, изложенное вами отношение и мысли в этом посту с таким подходом вида «Все говно, а я Д`Артаньян» не помогают уже вам заслужить уважения в ответ. Лично я бы вас не принял никуда ни на какую роль после такой демонстрации, рад за вас что вам на текущем месте хорошо.
1. По-вашему фрактал (первый раз о нем слышу) имеет какое-то отношение?
Fractal is a tool to help you build and document web component libraries, and then integrate them into your projects.
Какая-то непонятная маргинальная тулза вообще непонятно что делает и зачем нужна пока не прочитаешь несколько страниц их документации. Как вы вообще наткнулись на это?
2. Тарс. По-вашему тарс это какая-то панацея?
Это просто набор тасок в gulp, который вдобавок еще и диктует свои правила к организации файлов, свои ограничения и тому подобное. У таких вещей как тарс вообще крайне ограниченная область применения и целевая аудитория, в них надо сначала еще и вложить время поверх вложенного в сам gulp, изучить, и только после нескольких применений это время окупится или не окупится никогда если по работе не нужно клепать статичные сайты каждые пару недель.
Провокации? Троллируете тут? Или это у вас классический случай «I was just pretending to be retarded»?
Мне достаточно очевидно (теперь уже), что вам абсолютно наплевать на чье-либо мнение, ошибок вы признавать или не умеете, или не хотите. Учиться мне у вас нечему, а что-либо уже вам доказывать, переубеждать, или иными словами приносить вам пользу у меня не осталось никакого желания, провоцируйте больше, флаг вам в руки.
Заодно спасибо вам или какому-нибудь вашему фанату за минус в карму.
Всего доброго, мистер провокатор.
Скролл это тоже не проблема. Вы уже реализовали какой-нибудь проект с применением этого чтобы говорить о том что с этим работать проще чем со скроллом?
Много media в и исходниках это не проблема, с использованием вашего миксина у вас их получается даже больше чем без него (sic!). Как только число свойств, изменяющихся хотя бы один раз при изменении размера экрана становится больше количества брейкпойнтов в проекте (3-5, сколько их у вас?), то миксинов становится больше чем было бы обычных media. А ведь число media всегда меньше чем количество брейкпойнтов в рамках одного класса. Конечно с учетом тех же самых ограничений в их структуре что вы вносите миксином.
Зачем вам `screen only`? Задумывались зачем? Было это обдуманное решение добавить его или вы не знаете для чего он нужен и нужен ли вообще?
Как комбинировать это все с `media print`?
Группировать media лучше внутри каждого класса, точно так вы делаете со своим миксином, вы ведь правильно почувствовали что удобнее группировать все media относящиеся к одному классу внутри этого самого класса. Если так не делать, то будет абсолютно неподдерживаемый код. Вот вообще без вариантов.
У вас еще есть проблема, с который вы вероятно сталкиваетесь и не осознаете, из-за чего пытаетесь решить в том числе и ее таким мягко говоря необычными способами. Разбивайте группы свойств внутри одного класса отступами, не бойтесь, от скролла еще никто не умирал. Порядок свойств у вас уже вроде как есть, что хорошо, теперь только еще группы свойств поразбивайте и пройдет желание улучшать читаемость ибо станет супер-читаемо.
И еще насчет результирующего сss, gzip абсолютно неважно сколько у вас будет в нем повторений media, одно или в пятьдесят раз больше, заботясь о размере получающегося сss вы не просто экономите на спичках, а экономите на байтах, даже до килобайта не дойдет экономия. Задумайтесь на минутку зачем и кому это надо, придете к выводу что никому не надо о такой экономии заботиться. blog.servergrove.com/2014/04/14/gzip-compression-works
Еще у вас порядок простановки media в первом примере кода нарушен, у вас сначала идет для самого маленького экрана, потом по брейкпойнту для самого большого, потом от него уже вниз по брейкпойнтам. Выберите один порядок и придерживайтесь его.
Еще ровные значения брейкпойнтов 640, 768, 1024 обычно означают начало диапазона размеров, а не конец, вот так например должно быть 320-639, 640-1023, 1024+
Именно так делают макеты дизайнеры, макет под ширину 640 будет показывать начальное состояние страницы и именно оно будет растягиваться до включительно 1023. А вот 1024 начнется уже условно десктопное отображение.
Может конечно попасться дизайнер наркоман и нарисовать как попало, но это уже другая история.
А еще не надо вкладывать классы друг в друга в общем случае, возьмите именование по БЭМ, SMACSS или еще чему такому и откажитесь от излишней вложенности уже сегодня бесплатно и без смс.
Скажете что нравится структура, которая получается при вложенности? Что она якобы повторяет html и помогает не глядя на html понять какой класс внутри другого окажется?
Ну так и используйте эту структуру, только без вложенности. Вот так:
$breakpoint--desktop: 1024px;
$breakpoint--tablet-wide: 880px;
$breakpoint--tablet: 640px;
$breakpoint--mobile: 320px;
.b-class {
width: 100%;
height: 100%;
color: black;
font-size: 12px;
@media (max-width: $breakpoint--tablet - 1) {
width: 20%;
height: 100px;
color: white;
font-size: 12px;
}
@media (max-width: $breakpoint--tablet-wide - 1) {
width: 25%;
height: 200px;
color: gray;
font-size: 14px;
}
@media (max-width: $breakpoint--desktop - 1) {
width: 50%;
height: 300px;
font-size: 10px;
}
}
.b-class__inner {
display: inline-block;
height: 500px;
background: red;
font-size: 14px;
`
@media (max-width: $breakpoint--tablet - 1) {
display: none;
}
@media (max-width: $breakpoint--tablet-wide - 1) {
height: 200px;
background: yelllow;
font-size: 20px;
}
@media (max-width: $breakpoint--desktop - 1) {
height: 300px;
background: black;
font-size: 18px;
}
}
.b-class__link {
text-decoration: none;
@media (max-width: $breakpoint--tablet-wide - 1) {
// Вот так вот в этой структуре сразу видно что здесь, например,
// это свойство избыточное. Это к вопросу о группировке всех
// media, относящихся к конкретному классу, внутри этого класса
text-decoration: none;
}
@media (max-width: $breakpoint--desktop - 1) {
text-decoration: underline;
}
}
Работа над такой кодовой базой будет абсолютно невозможна, вас будет проклинать любой человек, которому придется работать с этим после вас. И возможно вы сами через год.
Применяйте такое для собственных одноразовых сайтов, но не делайте такого на работе.
Вы сами создали себе проблему, и решили ее добавив в разы большую проблему, потенциально фатальную для поддержки вообще всей кодовой базы.
Вы вообще в курсе что в sass можно вот так писать?
Никаких повторений и все понятно с первого взгляда, можно даже никогда не зная sass предположить как будет выглядеть скомпилированный результат.
И вот здесь уже можно как-то отдельные правила скорректировать, вынести значение 1024px в переменную, или написать миксин с названием $desktop-and-down или еще какую-нибудь систему именования придумать, есть статьи на эту тему. Все будет в разы лучше чем то что у вас. У вас, повторюсь, применено потенциально фатальное для поддержки всей кодовой базы решение несуществующей проблемы.
1) читать Википедию на тех же 24"-1920x1080-мониторах — это тотально-маразматически неудобно. Где я теперь эту информацию буду искать, которую раньше в Вики находил — даже не представляю.
Сравнили автомобильный сайт с википедией? Одни и те же UI/UX приемы думаете применимы? Думаете есть большое пересечение в плане работы с контентом между энциклопедией и сайтами в категории из вашего примера?
Даже если так, то сравните как выглядит текст в википедии и у вас:
— у википедии 14px/22.4px, соотношение 1,6
— у вас (по крайней мере на одной из ширин) 20.6577px/24.7893px, соотношение всего 1,2. И это при том что у вас шрифт жирнее чем Ариал с википедии.
Межстрочный интервал это не хухры-мухры, правильный делает текст читаемым, неправильный делает текст нечитаемым и сам сайт объективно дешево выглядящим.
2) Страницу в ворде с полями по 1,5 см и предлагаемым по умолчанию 11 кеглем тоже читать жутко неудобно — очень-очень too long, почти 100 символов в ширину — это в 1,5-2 раза больше стандарта.
Это не веб. Говорит о вашем внимании.
________
Это нормально не иметь вкуса и чувства прекрасного для разработчика, но в таком случае лучше не плести отсебятину, а руководствоваться хотя бы очевидными и общепринятыми рекомендациями, не влезая в редкие исключения за вдохновлением и примером (как например в википедию или любую другую веб-энциклопедию за примером длины строк для сайта НЕ-энциклопедии).
У вас очевидно нет ни вкуса, ни чувства прекрасного, и еще есть немного (или много) резины головного мозга, так что почитайте об оптимальной длине строки, оптимальном межстрочном интервале, о типографике, и видимо занимайтесь ремеслом по имеющимся гайдлайнам не споря с ними и не осуждая. UI/UX это явно не ваша стезя.
Ширина текста по вашей первой ссылке это тотальный маразм, не уверен что я встречал такое вообще когда-либо в жизни. Разве что на самодельных сайтах 90-х годов с WordArt и гифками по всей странице было что-то подобное, помните такие сайты? Вот такой вот vibe идет от страницы по вашей первой ссылке.
Для вас настало время серьезной рефлексии, не упустите этот момент.
С префиксами то же самое: добавляя их ко всем без исключения блокам, мы обесцениваем такое выделение до нуля.
Вот здесь прямо точно видно что вы не так поняли цель «выделения». Выделяются классы не друг от друга, а от остальной базы кода. Хотя и друг от друга тоже, b- сигнализирует начало имени класса для любого окружения. Зачем это надо и почему без этого реально плохо вы можете прочитать в моем комментарии к вашему посту выше, но здесь я просто приведу цитату:
Если вы сидите в продуктовой разработке и годами работаете с одной и той же кодовой базой с вылизанной структурой, знаете коллег как облупленных и все они высокого уровня и следуют общим правилам, и правила собственно эти есть, то я вас поздравляю, but you're in a bubble.
Во всех остальных случаях (хотя даже и в вашем идеальном мире) я не будут доверять никому и выполню полнотекстовый поиск имени класса по всей кодовой базе, включая серверный код, прежде чем его удалить или изменить. И без префикса .b- мне придется разгребать сотни unrelated найденных результатов, и хорошо еще если не тысячи.
Если у вас это не так — у вас проблема в чем-то другом.
Миллион разных вещей может произойти и на мой взгляд разработчик ответственен за обеспечение как можно большей устойчивости к изменениям (вандализму) у кодовой базы. Без префиксов у имен классов единственный джуниор или сеньер с вашей attitude может все вашу красоту развалить в быстрые сроки и прибрать будет за ними в разы более тяжко.
Есть и другие аргументы за наличие префиксов, куда менее простые для описания и убеждения, поэтому если вас (или кого-то другого) это не убедило, то мне их будет бестолку приводить и распыляться, всего доброго.
Если вы сидите в продуктовой разработке и годами работаете с одной и той же кодовой базой с вылизанной структурой, знаете коллег как облупленных и все они высокого уровня и следуют общим правилам, и правила собственно эти есть, то я вас поздравляю, but you're in a bubble.
Во всех остальных случаях (хотя даже и в вашем идеальном мире) я не будут доверять никому и выполню полнотекстовый поиск имени класса по всей кодовой базе, включая серверный код, прежде чем его удалить или изменить. И без префикса .b- мне придется разгребать сотни unrelated найденных результатов, и хорошо еще если не тысячи.
Если у вас это не так — у вас проблема в чем-то другом.
Миллион разных вещей может произойти и на мой взгляд разработчик ответственен за обеспечение как можно большей устойчивости к изменениям (вандализму) у кодовой базы. Без префиксов у имен классов единственный джуниор или сеньер с вашей attitude может все вашу красоту развалить в быстрые сроки и прибрать будет за ними в разы более тяжко.
Есть и другие аргументы за наличие префиксов, куда менее простые для описания и убеждения, поэтому если вас (или кого-то другого) это не убедило, то мне их будет бестолку приводить и распыляться, всего доброго.
Никакого квеста: ищем имя блока, а дальше все видно… Или у вас описания блоков по три экрана?
У вас нет блоков больше трех экранов? В идеальном мире живете. Но даже в этом случае хватает и одного экрана собранных имен классов чтобы это было именно что развлечение себя головоломками вместо работы и облегчения работы людям после вас.
Я точно так же могу обозвать жесточайшим и неоправданным ваше требование чтобы структура css совпадала со структурой html.
Да, весьма жесткое требование, однако я привел на мой взгляд более чем весомые причины, и на чей угодно взгляд эти причины по крайней мере есть. В отличие от вас с куда более жестоким требованием/подходом к сбору имен классов.
Чем измеряли?
Сложностью поддержки — внесения изменений, исправления ошибок и рефакторинга. Как на собственном опыте, так и наблюдая за работой других человек над разными базами кода, включая и тот где имена классов собираются.
Любому человеку, ...
Почему вы так уверены?
Потому что считаю свои способности к экстраполяции выше среднего? И не встречал никогда и нигде аргументов за сбор имен классов? И не встречал и не слышал ни об одном человеке, который бы собирал имена классов долгое время и считал это хорошей практикой? Зато постоянно натыкаюсь на тех кто только начал их собирать и уже продвигает это везде не приводя никаких аргументов за это. Предполагаю что затем такие люди тихо сливаются и не отсвечивают о своих предыдущих заблуждениях.
Можете ли вы сказать что за плюсы есть от сбора имен классов? (не считая сбор модификаторов и псевдоселекторов, с этим все в порядке и по моему мнению)
А то пока что я не слышал ни одного, кроме абсурда о том что печатать меньше или что-то мышкой выделять там проще, хотя даже «аргумент» про выделение был не про сборку, а про синтаксис.
К сожалению, мы живем не в идеальном мире, и если над проектом работают уже два человека, то риск того что код не будет идеальным начинает приближаться к ста процентам. Но это лирика.
Есть несколько проблем с собиранием классов (не считая сборку модификаторов и псевдоселекторов):
1. Поиск любого класса превращается в квест вместо нажатия сочетания клавиш для поиска, особенно если имя элемента начинает состоять хотя бы из трех слов, не считая имени блока (А три слова это нормально, и пять нормально). Глазами найти тоже становится значительно тяжелее, и думаю это достаточно объективное суждение, не так ли? Начиная примерно от первого же уровня собирания, стили превращаются все в более и более запутанные лабиринты и головоломки, вместо инструмента веб-разработки. Кому-то может это интересно, не спорю. Куда круче редактировать кашу из спец-символов вместо простого кода, человек начинает выглядеть прямо как кулцхакер, самооценка повышает, уволить становится его сложнее и т.д.
2. Становится невыполнимым требование 7.2 структуры css/scss-кода повторять html-структуру, даже в приблизительной интерпретации. Просто напросто deal breaker лично для меня.
3. Даже без требования 7.2 структура scss-кода начинает диктоваться словами в имени классов, что либо не совпадает совсем со смысловой нагрузкой на конкретные классы и с html-структурой, либо накладывает жесточайшие и неоправданные ограничения на именование классов. А плохие имена классов это, очевидно, очень плохо по всем фронтам.
4. И из совсем реальной жизни: плохо (или даже просто не супер хорошо) написанный код с собиранием классов в ~десять раз хуже плохого css-кода без собирания классов.
5. Код со сборкой классов становится адом для поддержки, да даже не адом, он просто не поддерживается. Любому человеку, не пишущему такой код в течение хотя бы нескольких месяцев, проще взять скомпилированную версию scss/less-файла, заменить исходник именно на нее, и с ним уже работать.
Я могу представить собирание имен классов хоть сколько-нибудь оправданным (not really) только в случае если вообще весь стек проекта завязан на БЭМ по всем направлениям — верстка, стили, скрипты, системы сборки, инфраструктура, линтеры, etc… Иными словами если это внутренний проект Яндекса.
Работал и с древними проектами и простынями, и с настолько запутанными стилями, что их распутывание (без ломания всего в процессе) требовало многочисленных итераций рефакторинга/переделывания сразу по всему проекту, начиная с БД и заканчивая на фронте.
Поддерживать хороший css легко, нет, легчайшее занятие в вашей жизни. Однако одного css в вакууме для того чтобы сделать его легчайшим будет недостаточно. Необходимо будет и верстать определенным образом, и из js определенным образом взаимодействовать с DOM, и шаблонизацию применять определенным образом (серверную, клиентскую, любую). При этом все вот это будет влиять и на организацию самого css. Способ написания легчайшего для поддержки CSS в React-проекте будет отличаться от его же написания в jQuery одностраничнике или огромном легаси jQuery-монстре.
Я могу дать некоторые универсальные советы, за не следование которым я бы отрывал руки, но следовать им или нет уже дело каждого конкретного человека (равно как и читать их).
0. Прежде всего более-менее следовать тем ограничениям по связям стилей между блоками что есть в БЭМ.
0.1. Изолировать классы и стили разных блоков, у которых разный смысл, друг от друга.
0.2. Лучше повторить три четыре раза почти те же самые стили для разных по смыслу или способу работы блоков, чем лепить один блок-монстр. При этом монстром его сделает не размер, а слишком разное использование в разных местах.
0.3. Реально переиспользуемые маленькие блоки (такие как «кнопка») делать настолько понятным и прозрачными, насколько возможно. Вообще уделять особое внимание реально переиспользуемым вещам. Еще не пытаться делать переиспользуемыми не особо подходящие для этого блоки.
1. Всегда всем классам нужно добавлять префикс. Например b-, или несколько префиксов, например, l- (layout), u- (utility), g- (global), whatever else. Главное чтобы при полнотекстовом поиске по всему коду проекта, включая весь серверный код, не находилось бы ничего или почти ничего кроме непосредственно использования искомого класса. Нет никакого оправдания не использованию префиксов. Никакого. Такого человека просто сразу в утиль, либо если его жалко немного, то в говнолегаси без префиксов на год, пусть потом сообщит, нашел ли он там хоть один аргумент в пользу отсутствия префиксов.
2. Не использовать такой маразм как js- классы.
3. Не собирать имена классов в scss/less/etc. за исключением модификаторов и псевдоселекторов. Не собирать имена классов в JS и шаблонизаторах, за теми же исключениями.
4. Выбрать порядок свойств в правилах и следовать ему. Выбрать нормальный порядок, с группами свойств, отступами между ними. Следовать ему.
5. media-запросы писать прямо возле стилей элемента. НЕ выносить кучу стилей от разных элементов в 1 media-запрос. Лень повторять media-запрос 50 раз? Вынеси пиксельные значения в переменную или весь запрос в миксин.
6. Лень печатать 3-4 слова в одном имени класса? О**ел? Печатай столько, сколько требуется, чтобы понять что это за элемент и чтобы не гадать потом за тобой что ты там имел в виду. Если для этого требуется 10 слов, то что-то значит пошло где-то не так, и не в css, а в совокупности всего. Если требуется 7 слов, то ничего страшного, попечатаешь. Не сломаешься. А то ишь что, печатать ему лень, зато потом разбирайся несколько часов в тотально бессмысленном наборе классов из двух-трех слов, которые не характеризуют того что делает или чем является элемент. Сэкономишь пять минут в день на печатании, потеряешь уже в тот же день на воспоминаниях того что это за элементы, что они делают и какие у них между собой связи.
7. Не использовать 2 пробела, это нечитаемый рак мозга. Единственное оправдание, это если 2 пробела являются требованием работодателя по той или иной причине (есть несколько валидных причин, на мой взгляд крайне редких)
Еще было бы неплохо, но уже тяжело требовать такое конечно:
5. Соблюдать принцип единой ответственности насколько возможно, лучше добавить пару div'ов с понятными именами и единой ответственностью в стилях, чем мешать все стили в одну кучу на одном и том же элементе.
6. Тут же и вдобавок к предыдущему — не делать служебных div'ов, которые нужны только для верстки, и которые бы не имели четкого смыслового содержания. А если и требуются таковые, то выделять их настолько сильно, насколько возможно. Именованием, комментариями, отступами, чем угодно.
7. И еще пара вещей, на мой взгляд, необходимых, но и со своим минусом.
7.1. Ставить закрывающую скобку в том же столбце что и свойства.
7.2. Вот как-то вот так вот писать css/scss, с отступами, повторяющими структуру элементов в html:
Да, приходится следить за соответствием отступов в css при изменениях в структуре html, это один из минусов. Но сразу видно есть ли у блока адекватная структура или это бессмысленный каша с бессмысленно раскиданной версткой, классами и стилями, что на мой взгляд совершенно огромнейший плюс.
В итоге менять именно что структуру у блока не приходится почти никогда, а когда приходится, то это в основном из-за реально изменившихся требований к работе блока, а не по каким-то техническим причинам. Да и расширение функционала блока происходит куда легче из-за наличия смысла в его структуре.
Люди, у которых из аргументов тяжесть что-то в редакторе напечатать, отступы проставить или мышкой у которых что-то не выделяется, или идут в мануалы своего редактора или известно куда.
Пожалуйста, никогда не собирайте имена классов, за исключением присоединения модификаторов и псевдоселекторов. Вас будет проклинать последними словами каждый человек, которому придется работать с этим кодом после вас. Каждый. Последними.
Вот например такой рабочий пример без чего бы то ни было, что можно было бы назвать гордым словом — рассчет, примерно такой же как выше в комментариях, но с еще большим количеством нового синтаксиса, чтобы скучно не было:
Такие то вы дефицитные, что даже у яндеса найдется десяток людей на ту же вакансию с соразмеримым уровнем, но куда меньшим чсв, чем у вас, не говоря уже о гуглах и им подобных. Продолжайте кукарекать о своей незаменимости.
Эх, сейчас бы помечтать о том как мой будущий работодатель будет тратить уйму денег ради оплаты чсв кандидатов, которые приходят на интервью почесать оное чсв, а не на повышение зарплаты работникам, которым я, как настоящий кандидат, вроде как собираюсь стать.
Впрочем, если не собираюсь и не имею достаточно эмпатии чтобы поставить себя на место такого кандидата, то да, я могу вредных советов насоветовать, попризывать не жалеть бедненькие компании.
Уровень понимания и осознания написанного на абсолютном дне. До ковида — телефонное интервью плюс переговоры с рекрутером + Полеты туда-сюда до Москвы/Питера/etс. отнимающие больше суток. После ковида — чуть больше онлайн интервью чем их было бы на месте. Экономия очевидно на сутках потраченных на полеты туда-обратно, плюс-минус пара часов здесь вообще ни что не влияет.
При этом вы все равно потратили больше суток своего времени и не получили на выходе никаких денег в кармане, только оффер или нет.
Без полетов вы потратили условные 4 часа, и на выходе получили оффер или нет.
В первом случае вам типа норм, а во втором вам типа недоплатили. Задумайтесь, не унюхиваете маразм и отсутствие логики?
А это как бы мало? 4 условных интервьера плюс-минус, каждый тратит какое-то время на подготовку интервью с вами, само интервью, потом пишет отзыв, каждый тратит на вас в среднем допустим часа 3. Потом рекрутер сколько своего времени тратит, я не знаю, но пусть допустим еще 3.
А сколько еще затрачено на отвлечение программиста от непосредственной работы в плане уменьшения его производительности за счет отвлечения на интервью с вами? Можно еще по часу накинуть. А время изначальной подготовки каждого программиста к интервьюированию? Пару десятков часов, которое потом будет окупаться и размазываться по всем интервью. Думаю далеко не каждый программист за все время работы в яндексе проведет хотя бы 20 интервью чтобы подготовка размазалась хотя бы до часа. Но пусть будет 20 в среднем, еще час можно накинуть.
Итого получается 4 интервьюера * 5 часов зарплаты на каждого, плюс время рекрутера. На этом фоне оплата билетов и гостиницы даже не удвоит эти траты для компании. А вот вы при полетах в несколько раз увеличите затраты своего времени.
Надо хоть немного совести иметь и понимать это, а не жаловаться что все про все заняло на 1-2 часа больше времени и бугуртить до уровня написания поста на хабр.
Еще надо понимать что собеседования по удаленке куда сложнее для интервьюера чем лично, поэтому очевидно что их надо больше чтобы лучше понять что за человек пришел. Очевидно это временно. Очевидно что винить компанию за это крайне несправедливо.
Если кто не в курсе, то до ковида яндекс и так при приглашении на личные интервью покупал вам и билеты на самолет и гостиницу оплачивал. Требовать чтобы еще больше они вам что-то компенсировали это вообще тотальная наглость. Что они вам еще должны, оплатить пару дней на уровне реальной зарплаты? Рожа, извините, не треснет? При ковиде теперь то конечно не лично получается, но и время вы экономите не собеседуясь лично.
На каждого программиста, который считает что ему все обязаны, найдется не менее десятка сравнимого уровня тех, кто понимает что ему эта конкретная вакансия нужна больше, чем он нужен компании. И кто готов «потратить» десятки, а то и сотни часов на весь процесс прохождения на желаемую вакансию в желаемую компанию. И я лично рад что такие как ОП, а также неготовые потратить несколько часов бесплатно, отсеиваются в описанном процессе найма. Классическая фича, а не баг.
Реальная работа это, извините, сommitment и от вас и от компании на как минимум много месяцев или даже уже лет, плюс с большим количеством денег на кону.
Жаловаться что вас крутят 4 часа по алгоритмам это показать свое непонимание процессов найма, их практичности, неумение оценки реальности внедрения более «правильных» с вашей точки зрения процессов найма, неуважение к людям выстраивающим этот процесс за счет отметания с ходу вероятности того что возможно это именно вы что-то неправильно понимаете.
Даже если бы вы решили идеально все представленные задачи, изложенное вами отношение и мысли в этом посту с таким подходом вида «Все говно, а я Д`Артаньян» не помогают уже вам заслужить уважения в ответ. Лично я бы вас не принял никуда ни на какую роль после такой демонстрации, рад за вас что вам на текущем месте хорошо.
Наверное это потому что главному герою 11 лет? Удивительная наблюдательность
1. По-вашему фрактал (первый раз о нем слышу) имеет какое-то отношение?
Какая-то непонятная маргинальная тулза вообще непонятно что делает и зачем нужна пока не прочитаешь несколько страниц их документации. Как вы вообще наткнулись на это?
2. Тарс. По-вашему тарс это какая-то панацея?
Это просто набор тасок в gulp, который вдобавок еще и диктует свои правила к организации файлов, свои ограничения и тому подобное. У таких вещей как тарс вообще крайне ограниченная область применения и целевая аудитория, в них надо сначала еще и вложить время поверх вложенного в сам gulp, изучить, и только после нескольких применений это время окупится или не окупится никогда если по работе не нужно клепать статичные сайты каждые пару недель.
Собственно у меня к вам только один вопрос: Wat?
Мне достаточно очевидно (теперь уже), что вам абсолютно наплевать на чье-либо мнение, ошибок вы признавать или не умеете, или не хотите. Учиться мне у вас нечему, а что-либо уже вам доказывать, переубеждать, или иными словами приносить вам пользу у меня не осталось никакого желания, провоцируйте больше, флаг вам в руки.
Заодно спасибо вам или какому-нибудь вашему фанату за минус в карму.
Всего доброго, мистер провокатор.
Много media в и исходниках это не проблема, с использованием вашего миксина у вас их получается даже больше чем без него (sic!). Как только число свойств, изменяющихся хотя бы один раз при изменении размера экрана становится больше количества брейкпойнтов в проекте (3-5, сколько их у вас?), то миксинов становится больше чем было бы обычных media. А ведь число media всегда меньше чем количество брейкпойнтов в рамках одного класса. Конечно с учетом тех же самых ограничений в их структуре что вы вносите миксином.
Зачем вам `screen only`? Задумывались зачем? Было это обдуманное решение добавить его или вы не знаете для чего он нужен и нужен ли вообще?
Как комбинировать это все с `media print`?
Группировать media лучше внутри каждого класса, точно так вы делаете со своим миксином, вы ведь правильно почувствовали что удобнее группировать все media относящиеся к одному классу внутри этого самого класса. Если так не делать, то будет абсолютно неподдерживаемый код. Вот вообще без вариантов.
У вас еще есть проблема, с который вы вероятно сталкиваетесь и не осознаете, из-за чего пытаетесь решить в том числе и ее таким мягко говоря необычными способами. Разбивайте группы свойств внутри одного класса отступами, не бойтесь, от скролла еще никто не умирал. Порядок свойств у вас уже вроде как есть, что хорошо, теперь только еще группы свойств поразбивайте и пройдет желание улучшать читаемость ибо станет супер-читаемо.
И еще насчет результирующего сss, gzip абсолютно неважно сколько у вас будет в нем повторений media, одно или в пятьдесят раз больше, заботясь о размере получающегося сss вы не просто экономите на спичках, а экономите на байтах, даже до килобайта не дойдет экономия. Задумайтесь на минутку зачем и кому это надо, придете к выводу что никому не надо о такой экономии заботиться.
blog.servergrove.com/2014/04/14/gzip-compression-works
Еще у вас порядок простановки media в первом примере кода нарушен, у вас сначала идет для самого маленького экрана, потом по брейкпойнту для самого большого, потом от него уже вниз по брейкпойнтам. Выберите один порядок и придерживайтесь его.
Еще ровные значения брейкпойнтов 640, 768, 1024 обычно означают начало диапазона размеров, а не конец, вот так например должно быть 320-639, 640-1023, 1024+
Именно так делают макеты дизайнеры, макет под ширину 640 будет показывать начальное состояние страницы и именно оно будет растягиваться до включительно 1023. А вот 1024 начнется уже условно десктопное отображение.
Может конечно попасться дизайнер наркоман и нарисовать как попало, но это уже другая история.
А еще не надо вкладывать классы друг в друга в общем случае, возьмите именование по БЭМ, SMACSS или еще чему такому и откажитесь от излишней вложенности уже сегодня бесплатно и без смс.
Скажете что нравится структура, которая получается при вложенности? Что она якобы повторяет html и помогает не глядя на html понять какой класс внутри другого окажется?
Ну так и используйте эту структуру, только без вложенности. Вот так:
Применяйте такое для собственных одноразовых сайтов, но не делайте такого на работе.
Вы сами создали себе проблему, и решили ее добавив в разы большую проблему, потенциально фатальную для поддержки вообще всей кодовой базы.
Вы вообще в курсе что в sass можно вот так писать?
Никаких повторений и все понятно с первого взгляда, можно даже никогда не зная sass предположить как будет выглядеть скомпилированный результат.
И вот здесь уже можно как-то отдельные правила скорректировать, вынести значение 1024px в переменную, или написать миксин с названием $desktop-and-down или еще какую-нибудь систему именования придумать, есть статьи на эту тему. Все будет в разы лучше чем то что у вас. У вас, повторюсь, применено потенциально фатальное для поддержки всей кодовой базы решение несуществующей проблемы.
Сравнили автомобильный сайт с википедией? Одни и те же UI/UX приемы думаете применимы? Думаете есть большое пересечение в плане работы с контентом между энциклопедией и сайтами в категории из вашего примера?
Даже если так, то сравните как выглядит текст в википедии и у вас:
— у википедии 14px/22.4px, соотношение 1,6
— у вас (по крайней мере на одной из ширин) 20.6577px/24.7893px, соотношение всего 1,2. И это при том что у вас шрифт жирнее чем Ариал с википедии.
Межстрочный интервал это не хухры-мухры, правильный делает текст читаемым, неправильный делает текст нечитаемым и сам сайт объективно дешево выглядящим.
Это не веб. Говорит о вашем внимании.
________
Это нормально не иметь вкуса и чувства прекрасного для разработчика, но в таком случае лучше не плести отсебятину, а руководствоваться хотя бы очевидными и общепринятыми рекомендациями, не влезая в редкие исключения за вдохновлением и примером (как например в википедию или любую другую веб-энциклопедию за примером длины строк для сайта НЕ-энциклопедии).
У вас очевидно нет ни вкуса, ни чувства прекрасного, и еще есть немного (или много) резины головного мозга, так что почитайте об оптимальной длине строки, оптимальном межстрочном интервале, о типографике, и видимо занимайтесь ремеслом по имеющимся гайдлайнам не споря с ними и не осуждая. UI/UX это явно не ваша стезя.
www.smashingmagazine.com/2011/11/the-perfect-paragraph
baymard.com/blog/line-length-readability
ux.stackexchange.com/questions/3618/ideal-column-width-for-paragraphs-online
И еще несколько миллионов результатов в гугле и несколько тысяч статей и сотни исследований на одну и ту же тему, на тему оптимальной длины строки в вебе, особенно касаемо контентного текста.
Ширина текста по вашей первой ссылке это тотальный маразм, не уверен что я встречал такое вообще когда-либо в жизни. Разве что на самодельных сайтах 90-х годов с WordArt и гифками по всей странице было что-то подобное, помните такие сайты? Вот такой вот vibe идет от страницы по вашей первой ссылке.
Для вас настало время серьезной рефлексии, не упустите этот момент.
Вот здесь прямо точно видно что вы не так поняли цель «выделения». Выделяются классы не друг от друга, а от остальной базы кода. Хотя и друг от друга тоже,
b-сигнализирует начало имени класса для любого окружения. Зачем это надо и почему без этого реально плохо вы можете прочитать в моем комментарии к вашему посту выше, но здесь я просто приведу цитату:Во всех остальных случаях (хотя даже и в вашем идеальном мире) я не будут доверять никому и выполню полнотекстовый поиск имени класса по всей кодовой базе, включая серверный код, прежде чем его удалить или изменить. И без префикса .b- мне придется разгребать сотни unrelated найденных результатов, и хорошо еще если не тысячи.
Миллион разных вещей может произойти и на мой взгляд разработчик ответственен за обеспечение как можно большей устойчивости к изменениям (вандализму) у кодовой базы. Без префиксов у имен классов единственный джуниор или сеньер с вашей attitude может все вашу красоту развалить в быстрые сроки и прибрать будет за ними в разы более тяжко.
Есть и другие аргументы за наличие префиксов, куда менее простые для описания и убеждения, поэтому если вас (или кого-то другого) это не убедило, то мне их будет бестолку приводить и распыляться, всего доброго.
Но вот 7.2 как раз делает все это и больше. Минусов от 7.2 меньше чем от сборки и они другие. Ограничения приносят пользу, а не вред. Плюсы крупнее.
Ну вы поняли мое отношение.
У вас нет блоков больше трех экранов? В идеальном мире живете. Но даже в этом случае хватает и одного экрана собранных имен классов чтобы это было именно что развлечение себя головоломками вместо работы и облегчения работы людям после вас.
Да, весьма жесткое требование, однако я привел на мой взгляд более чем весомые причины, и на чей угодно взгляд эти причины по крайней мере есть. В отличие от вас с куда более жестоким требованием/подходом к сбору имен классов.
Сложностью поддержки — внесения изменений, исправления ошибок и рефакторинга. Как на собственном опыте, так и наблюдая за работой других человек над разными базами кода, включая и тот где имена классов собираются.
Потому что считаю свои способности к экстраполяции выше среднего? И не встречал никогда и нигде аргументов за сбор имен классов? И не встречал и не слышал ни об одном человеке, который бы собирал имена классов долгое время и считал это хорошей практикой? Зато постоянно натыкаюсь на тех кто только начал их собирать и уже продвигает это везде не приводя никаких аргументов за это. Предполагаю что затем такие люди тихо сливаются и не отсвечивают о своих предыдущих заблуждениях.
Можете ли вы сказать что за плюсы есть от сбора имен классов? (не считая сбор модификаторов и псевдоселекторов, с этим все в порядке и по моему мнению)
А то пока что я не слышал ни одного, кроме абсурда о том что печатать меньше или что-то мышкой выделять там проще, хотя даже «аргумент» про выделение был не про сборку, а про синтаксис.
Есть несколько проблем с собиранием классов (не считая сборку модификаторов и псевдоселекторов):
1. Поиск любого класса превращается в квест вместо нажатия сочетания клавиш для поиска, особенно если имя элемента начинает состоять хотя бы из трех слов, не считая имени блока (А три слова это нормально, и пять нормально). Глазами найти тоже становится значительно тяжелее, и думаю это достаточно объективное суждение, не так ли? Начиная примерно от первого же уровня собирания, стили превращаются все в более и более запутанные лабиринты и головоломки, вместо инструмента веб-разработки. Кому-то может это интересно, не спорю. Куда круче редактировать кашу из спец-символов вместо простого кода, человек начинает выглядеть прямо как кулцхакер, самооценка повышает, уволить становится его сложнее и т.д.
2. Становится невыполнимым требование 7.2 структуры css/scss-кода повторять html-структуру, даже в приблизительной интерпретации. Просто напросто deal breaker лично для меня.
3. Даже без требования 7.2 структура scss-кода начинает диктоваться словами в имени классов, что либо не совпадает совсем со смысловой нагрузкой на конкретные классы и с html-структурой, либо накладывает жесточайшие и неоправданные ограничения на именование классов. А плохие имена классов это, очевидно, очень плохо по всем фронтам.
4. И из совсем реальной жизни: плохо (или даже просто не супер хорошо) написанный код с собиранием классов в ~десять раз хуже плохого css-кода без собирания классов.
5. Код со сборкой классов становится адом для поддержки, да даже не адом, он просто не поддерживается. Любому человеку, не пишущему такой код в течение хотя бы нескольких месяцев, проще взять скомпилированную версию scss/less-файла, заменить исходник именно на нее, и с ним уже работать.
Я могу представить собирание имен классов хоть сколько-нибудь оправданным (not really) только в случае если вообще весь стек проекта завязан на БЭМ по всем направлениям — верстка, стили, скрипты, системы сборки, инфраструктура, линтеры, etc… Иными словами если это внутренний проект Яндекса.
Поддерживать хороший css легко, нет, легчайшее занятие в вашей жизни. Однако одного css в вакууме для того чтобы сделать его легчайшим будет недостаточно. Необходимо будет и верстать определенным образом, и из js определенным образом взаимодействовать с DOM, и шаблонизацию применять определенным образом (серверную, клиентскую, любую). При этом все вот это будет влиять и на организацию самого css. Способ написания легчайшего для поддержки CSS в React-проекте будет отличаться от его же написания в jQuery одностраничнике или огромном легаси jQuery-монстре.
Я могу дать некоторые универсальные советы, за не следование которым я бы отрывал руки, но следовать им или нет уже дело каждого конкретного человека (равно как и читать их).
0. Прежде всего более-менее следовать тем ограничениям по связям стилей между блоками что есть в БЭМ.
0.1. Изолировать классы и стили разных блоков, у которых разный смысл, друг от друга.
0.2. Лучше повторить три четыре раза почти те же самые стили для разных по смыслу или способу работы блоков, чем лепить один блок-монстр. При этом монстром его сделает не размер, а слишком разное использование в разных местах.
0.3. Реально переиспользуемые маленькие блоки (такие как «кнопка») делать настолько понятным и прозрачными, насколько возможно. Вообще уделять особое внимание реально переиспользуемым вещам. Еще не пытаться делать переиспользуемыми не особо подходящие для этого блоки.
1. Всегда всем классам нужно добавлять префикс. Например b-, или несколько префиксов, например, l- (layout), u- (utility), g- (global), whatever else. Главное чтобы при полнотекстовом поиске по всему коду проекта, включая весь серверный код, не находилось бы ничего или почти ничего кроме непосредственно использования искомого класса. Нет никакого оправдания не использованию префиксов. Никакого. Такого человека просто сразу в утиль, либо если его жалко немного, то в говнолегаси без префиксов на год, пусть потом сообщит, нашел ли он там хоть один аргумент в пользу отсутствия префиксов.
2. Не использовать такой маразм как js- классы.
3. Не собирать имена классов в scss/less/etc. за исключением модификаторов и псевдоселекторов. Не собирать имена классов в JS и шаблонизаторах, за теми же исключениями.
4. Выбрать порядок свойств в правилах и следовать ему. Выбрать нормальный порядок, с группами свойств, отступами между ними. Следовать ему.
5. media-запросы писать прямо возле стилей элемента. НЕ выносить кучу стилей от разных элементов в 1 media-запрос. Лень повторять media-запрос 50 раз? Вынеси пиксельные значения в переменную или весь запрос в миксин.
6. Лень печатать 3-4 слова в одном имени класса? О**ел? Печатай столько, сколько требуется, чтобы понять что это за элемент и чтобы не гадать потом за тобой что ты там имел в виду. Если для этого требуется 10 слов, то что-то значит пошло где-то не так, и не в css, а в совокупности всего. Если требуется 7 слов, то ничего страшного, попечатаешь. Не сломаешься. А то ишь что, печатать ему лень, зато потом разбирайся несколько часов в тотально бессмысленном наборе классов из двух-трех слов, которые не характеризуют того что делает или чем является элемент. Сэкономишь пять минут в день на печатании, потеряешь уже в тот же день на воспоминаниях того что это за элементы, что они делают и какие у них между собой связи.
7. Не использовать 2 пробела, это нечитаемый рак мозга. Единственное оправдание, это если 2 пробела являются требованием работодателя по той или иной причине (есть несколько валидных причин, на мой взгляд крайне редких)
Еще было бы неплохо, но уже тяжело требовать такое конечно:
5. Соблюдать принцип единой ответственности насколько возможно, лучше добавить пару div'ов с понятными именами и единой ответственностью в стилях, чем мешать все стили в одну кучу на одном и том же элементе.
6. Тут же и вдобавок к предыдущему — не делать служебных div'ов, которые нужны только для верстки, и которые бы не имели четкого смыслового содержания. А если и требуются таковые, то выделять их настолько сильно, насколько возможно. Именованием, комментариями, отступами, чем угодно.
7. И еще пара вещей, на мой взгляд, необходимых, но и со своим минусом.
7.1. Ставить закрывающую скобку в том же столбце что и свойства.
7.2. Вот как-то вот так вот писать css/scss, с отступами, повторяющими структуру элементов в html:
Да, приходится следить за соответствием отступов в css при изменениях в структуре html, это один из минусов. Но сразу видно есть ли у блока адекватная структура или это бессмысленный каша с бессмысленно раскиданной версткой, классами и стилями, что на мой взгляд совершенно огромнейший плюс.
В итоге менять именно что структуру у блока не приходится почти никогда, а когда приходится, то это в основном из-за реально изменившихся требований к работе блока, а не по каким-то техническим причинам. Да и расширение функционала блока происходит куда легче из-за наличия смысла в его структуре.
Люди, у которых из аргументов тяжесть что-то в редакторе напечатать, отступы проставить или мышкой у которых что-то не выделяется, или идут в мануалы своего редактора или известно куда.