Комментарии 18
Заковыристые вопросы, однако. ? Но оно того стоит! Познавательная статья, почерпнул для себя новые свойства. Автору благодарность. ?
Спасибо за вопросы. Но для себя подумал - css изначально создавался как стильный инструмент над html и включал в себя, что этим будут заниматься дизайнеры, а не программисты. В этом была своего суть разделения задач. Но сейчас css такой мощный, но при этом и сложный, что 'просто' креативным челам он неподступен. Только спецам, которые могут и хотят погружаться по полной.
Более 10 лет нечем кроме как разработкой веб сайтов не занимаюсь, причем проекты крупные, дорогие с разными клиентами а-ля Apple. От визуальных редакторов лендосов до систем bowtie на нефтяных вышках. Разумеется своих бутстрапов в сторибуках понаписано.
И по правде говоря, я наверное ни на один вопрос, твердо не отвечу. Да кому я вру, я ваще не шарю все это, тем более :is и :where мне кажется впервые вижу.
Возможно я тупой, но проекты делаются, задачи решаются и без ответов на эти вопросы, тем более на собесе или что бы я у кого-то это спросил лол
Согласен. Бизнесу все равно как это сделано, если оно удовлетворяет требованиям. Поэтому зачастую проще использовать устаревшие технологии, которые с большей вероятностью будут работать у большинства пользователей. И как показывает практика этих устаревших технологий хватает с головой :)
Заголовок статьи надо переименовать в "Мои любимые вопросы о CSS для верстальщиков-экспертов с ответами." Тут реально надо просто иметь спеку в голове.
Для общего развития - шикарная статья, спасибо.
Ну это так было и будет. Кому-то кроме стамески и молотка ничего не надо, кому-то бумаги и ножниц - чтобы чудеса творить. А кому-то и 3D принтера уже мало.
То же самое.
Да потому что Caniuse покажет, что году в 21 только стали эти свойства поддерживаться.
Все пользователи по команде браузеры обновили что ли? :)
А нам нужно чтоб работало без "сюрпризов".
P. S. Статья интересная, спасибо!
Код работает не в вакууме. На практике многое в этой статье не работает так, как написано, хотя на первый взгляд может показаться, что все ок. Например:
Чему равняется вычисленное значение для свойства width и height у элементов .child?
Очевидно оно зависит не только от самой grid-сетки, но и от содержимого этих самых child. Сделайте им размер шрифта побольше и удивитесь несоответствию результата вашему ответу как по высоте, так и по ширине.
Каким свойством можно сократить количество определённых свойств для псевдоэлемента ::before до трёх?
Замена установленных height и width на четверку top, right, bottom, left, и потом на inset - это, конечно здорово и спортивно, только это меняет логику работы кода. Добавьте, например, margin для ::before, и окажется, что код в вопросе и ответе работает по-разному.
Перепишите следующий код так, чтобы определение значений для свойств margin и padding было без использования 0
Свойства margin, margin-block и margin-inline (и их составляющие в виде top, right, left и bottom) имеют разную логику работы. Версии block и inline зависят от свойств writing-mode, direction и text-orientation. Так что замена обычного margin на них может сломать верстку. Код в вопросе и ответе не эквивалентен. То же имеет отношение и к padding.
Так что вопросы, конечно, хороши, но в теории. А работа есть работа. Я бы не стал такое рекомендовать для вопросов на интервью. Для себя, почитать и восхититься возможностями языка - да, но не для интервью. Штуки вроде :focus-visible гуглятся за минуту при необходимости. За смешивание гридов, флексов и инлайнов на одном элементе нужно на ревью по голове стучать, чтобы коллег не путали неявными приведениями свойств друг к другу. Код долен быть очевидным, однозначно трактуемым с первого взгляда. А вычисленные значения будут зависеть от контекста и мы в подозрительных случаях будем смотреть в DevTools, чтобы видеть весь контекст, а не играть в угадайку.
"Код работает не в вакууме. На практике многое в этой статье не работает так, как написано, хотя на первый взгляд может показаться, что все ок."
Да, код работает не в вакууме. Вопросы создаются в вакууме, потому что проверятся/показывается какой-либо аспект-знание. Умение соединять разные аспекты, в частности " Сделайте им размер шрифта побольше", это отдельный навык, который не проверяется вопросами. Я постарался дать примеры кода, который максимально приближенны к практике. Например, свойством inset или margin-inline.
По поводу логических свойств. Посмотрите видео Kevin Powell или статьи Ahmad Shadeed. Они используют их так, как я написал в вопросах. То, что они могут сломать верстку при определении другого направления текста? Так люди либо это знают, либо узнают и примут решение, что с этим делать. Также существуют разработчики, которые делают проекты для микрокомпаний, у которых мультиязычность не востребована. У них ничего не сломается.
Нет единого правильного направления работы. Есть разные кейсы, к которым нужно использовать разные подходы. Статья про расширение кругозора, а не чтобы заваливать вопросами на собеседовании.
По поводу логических свойств. Посмотрите видео Kevin Powell или статьи Ahmad Shadeed. Они используют их так, как я написал в вопросах.
Я видел и статьи, и видео от этих ребят, и они везде рассматривали логические свойства в контексте направления текста. Не похоже, чтобы они говорили "а давайте просто так заменим одни свойства на другие, с другой логикой работы, ничего ведь не изменится". Так что отсылка к авторитетам не самая удачная.
То, что они могут сломать верстку при определении другого направления текста? Так люди либо это знают, либо узнают... Статья про расширение кругозора
Тогда уж надо в статье для расширения кругозора сразу и расширять его читателю, и говорить, что на самом деле мы тут имеем кучу скрытого поведения, про которое может быть интересно узнать. Может быть в следующей версии этой статьи стоит ее расширить именно такой информацией. Показать, что там есть еще один слой знаний, и разные свойства в языке появляются не просто так, они не заменяют друг друга на 100%, хотя иногда кажется, что это так.
Я бы сказал что половина этих задач - это пример плохого и неоднозначного кода, требуещего сакральных знаний. Нормальный верстальщик знает что явное лучше неявного и если ваша верстка настолько зависит от родительских элементов, что аж паддинги перестают работать, то сами понимаете...
Я бы сказал, что это проблемы дизайна языка CSS. Вот зачем считать специфичность, если порядок применения стилей определялся бы по порядку определения в файле стилей? - это убрало бы треть каверзных вопросов из статьи.
это может замечательно сработает для одного файла стилей, но если файлов много и подключаются они не в строго определенном порядке, да еще где-то они инлайново в html вставляются в теге style
...тогда что? Надеюсь, что не открою для вас секрет, но в CSS и сейчас учитывается порядок объявления правил.
И если у вас стили подключаются в случайном порядке и ничего не ломается, то дело уж точно не в том, что в одном файле у вас все стили по тегам, во втором по классам, а в третьем по уникальным идентификаторам. Так стили никто на моей памяти никогда не организовывал.
Скорее всего вас спасает то, что стили в разных файлах отвечают за свои компоненты, не связанные друг с другом.
Чаще всего стили организуются по методологии BEM, целью которой является изоляция стилей по префиксу с названием компонента, а так же полное изничтожение концепции специфичности CSS. Популярность BEM - явный признак того, что специфичность селекторов CSS вредна.
(прошу прощения у автора поста)
Так как вопрос разработчикам Хабра. Дело в том, что времени читать посты, остается в ночное время с телефона, закладок много (черезчур) отложенных на прочтение, но из-за отсутствия ночной (темной) темы, я не могу сдвинуться с места.
Давно где-то читал некую причину отсутствия темной темы на хабре:
мол и так есть много плагинов для браузеров которые все темнят по дефолту, ответ - в мобиле хром не поддерживает плагины.
Я не могу понять и принять, как на таком конкретно читальном сайте, нет выбора темной темы. Это сверх непонятная для меня ситуация. Просто обратить цвета, какие-то две функции - мешают множеству людей - читать ваш сайт.
Это не "мои любимые вопросы по css", а "я прочитал про css-grid и сейчас задолбаю вас заковыристыми вопросами, которые в жизни не встречаются... никогда".
А если серьезно, то вопросы, задаваемые на собеседованиях или сотрудникам на срезах знаний, должны подталкивать их к размышлениям и развитию. Вопросы не должны сводится к знанию очень тонких нюансов или к решению ребусов на внимательность, а иначе все это не имеет смысла.
Мои любимые вопросы о CSS с ответами. Версия 2023 года