#codepen дня

Ну что, кажется, настало то время, когда для стилизации радиокнопок и чекбоксов не нужно больше изгаляться с input:checked+i. Это освобождает мозг и руки для более приятных вещей.

Итак, смотрим на пример от Джона Кантнера: https://codepen.io/alinaki/pen/ExMXbqz

1. Для начала, обнуляем все браузерные стили и предположения браузера об внешнем виде радиокнопок вообще через appearance: none.

2. Я вам этого не говорил, но, технически, уже давно можно на поля ввода накладывать псевдоэлементы. Но не на select. Я всё хочу написать большой пост про реализацию select, пока вот так.

Благодаря этой возможности, собственно, можно стилизовать чекбокс как душе угодно: ::before, ::after, :checked::before, :checked::after... В целом, лично я бы обошёлся радиальным градиентом и одним псевдоэлементом.

3. Освободившиеся ресурсы мозга и тот факт, что теперь все элементы красиво вложены в label (как минимум, не нужны for и id), можно отправить на реализацию разных эффектов.

Например, проверить, есть ли лейбл с выделенным чекбоксом и подвинуть к нему рамку:

label:nth-of-type(2):has(input[type="radio"]:checked) ~ .selection {
 transform: translateY(100%);
}

Обратите внимание, рамка — отдельный элемент, к ней обращаемся через селектор низлежащих соседей ~.

Не знаю, что меня больше впечатляет. Псевдоэлементы на полях ввода или :has.

И да, поддерживается везде.

#css #has #appearance #бородач

#статья дня

Висящие промисы как простой способ оборвать async-функцию

await new Promise(() => {})

Зачем так делать?

Отмена через throw ненадёжна — её легко случайно поймать в try/catch, и код поедет дальше.

try {
  await handler()
} catch (e) {}

С висящим же промисом выполнение гарантированно останавливается.

Где это используется?

В пошаговых workflow, где функция должна завершиться на середине и продолжиться позже.

async function signup(user) {
  await step("create-user", user)

  if (!user.emailVerified) {
    await new Promise(() => {}) // закончили здесь
  }

  await step("send-email", user)
}

Оркестратор сохраняет прогресс и потом запускает её заново, пропуская выполненные шаги.

Минусы:
— такой код легко сломать случайно: забытый await или лишний Promise — и функция зависнет навсегда
— трудно дебажить: нет ошибки, нет стека, просто «ничего не происходит»
— не подходит для обычного приложения без оркестратора (сам по себе это тупик)
— может путать других разработчиков: выглядит как баг, а не как намеренное поведение

В общем, это способ явно остановить выполнение без исключений, но он требует дисциплины и инфраструктуры вокруг.

А, ну да. Сама статья: https://www.inngest.com/blog/hanging-promises-for-control-flow

#js #promise #halt

#фишка дня

А вы знали, что в GitHub Markdown не надо списки нумеровать самому?

1. Раз
1. Два
1. Три

будет буквально преобразовано в

1. Раз
2. Два
3. Три

И не надо париться, когда редактируешь.

P. S. оказывается, есть такая штука, как mdlint, и она на самостоятельную нумерацию очень даже ругается.

#статья дня

Scroll-driven animations уже давно есть в Chrome, и за последний год вокруг них накопилось много примеров — у того же Bramus Van Damme были подробные демки с view-timeline и разными вариантами ranges. Теперь появился ещё один большой разбор от самого Джоша Комо: https://www.joshwcomeau.com/animation/scroll-driven-animations/

Как всегда, это интерактивная документация по animation-timeline.

Посмею себе напомнить ключевую идею процесса: прогресс анимации берётся не из времени (`animation-duration`), а из положения элемента относительно viewport или scroll-контейнера. В статье это сразу показывается на примере с progress bar, где значение анимации напрямую связано со скроллом страницы.

Дальше он последовательно вводит scroll-timeline и view-timeline. Первый вариант привязывается к прокрутке контейнера, второй — к тому, как конкретный элемент входит и выходит из viewport. Есть наглядные демо, где один и тот же @keyframes ведёт себя по-разному в зависимости от выбранного таймлайна.

Отдельно разбирается animation-range. На интерактивных примерах видно, как entry, exit, cover, contain влияют на диапазон, в котором проигрывается анимация.

Есть демонстрации с несколькими timeline’ами и синхронизацией анимаций, где один scroll-прогресс управляет сразу несколькими свойствами.

Практически в каждом блоке есть интерактив: можно скроллить вложенные контейнеры и сразу видеть, как меняется поведение.

Документация: https://developer.mozilla.org/en-US/docs/Web/CSS/animation-timeline
Примеры от Google: https://developer.chrome.com/docs/css-ui/scroll-driven-animations/

Из нюансов — Safari всё ещё отстаёт: часть API отсутствует или работает неполно, так что без фоллбеков пока не обойтись.

#css #scroll

Замечал странную штуку: дел не так уж много, но любое – как будто через сопротивление?

Не то чтобы лень. Просто не делается и все тут! Зато видосики на Ютубе залетают на ура...

Попался годный разбор, советую посмотреть, если тоже чувствуешь, что превращаешься в апатичного зомби 👉🏼 https://t.me/Manifestans

Мысль, которая зашла: когда перестаешь понимать "чего хочу Я", даже нормальная жизнь ощущается, как каторга.

Кликай сюда, чтобы разобраться, что с тобой происходит и как снова начать испытывать ощущение, что ты живешь, а не существуешь.

#заметка дня

Ли Робинсон — разработчик и тренер в Cursor — поделился практическими советами о том, как выделиться среди сотен кандидатов при подаче на инженерную позицию.

Как сделать своё инженерное резюме заметным (глазами человека, который смотрит сотни резюме):

1. Резюме должно быть на одну страницу. Если нужно больше — добавьте ссылку на сайт. Не нужно по 10+ пунктов на каждую работу.

2. Вы сразу будете выделяться среди >90% кандидатов, если у вас есть персональный сайт с продуманным содержанием.

3. Если вы указываете свой X (Twitter), возможно, стоит почистить посты? Звучит очевидно, но люди публикуют всякое.

4. Обязательно добавьте GitHub. И, пожалуйста, без профиля в стиле MySpace с кучей бейджей и картинок — я хочу видеть код и ваши реальные навыки.

5. Адаптируйте отклик под компанию. Для стартапа курсы из университета менее важны. Для FAANG — могут помочь пройти ATS.

6. Удивительно, но многие резюме вообще не упоминают AI или агентов. Разработка меняется, и от вас ожидается понимание работы с AI. Это должно быть отражено в проектах и резюме.

7. Относитесь к LinkedIn серьёзно. Да, разработчики чаще сидят в X, но внутри компаний всё ещё пересылают именно LinkedIn.

8. Покажите свою индивидуальность: интересы, вкус, мышление. Книги, тексты, фильмы — всё, что раскрывает вас как человека. В конце концов, люди хотят работать с теми, кто им интересен и приятен.

9. Не используйте AI для написания резюме или сопроводительного письма. Это очень заметно, особенно в AI-компаниях. Можно использовать для идей, но писать — самому.

10. Не добавляйте фото в резюме. Лучше разместите его на внешних ссылках.

11. Качество важнее количества. Лучше 3 сильных проекта, чем 27 поверхностных AI-поделок.

Помните: рекрутеры просматривают сотни и тысячи откликов. Они не будут тратить 20 минут на каждый. Уберите лишнее и переходите к сути.

#resume #cv

В CodeRun встроили AI-тренера на SourceCraft

CodeRun — это онлайн-тренажер Яндекса для разработчиков: решаешь задачи, качаешь скиллы и готовишься к техсобесам. Теперь в нем появился AI-помощник: он не напишет код за тебя, но проведёт от намека к инсайту, не лишая права на ошибку. Вместо готового решения ты получаешь:

— прогрессивные подсказки;
— тест-кейсы для проверки решения, включая краевые случаи;
— разбор примеров из условия.

Чтобы попробовать, заходи в задачи на CodeRun и открывай вкладку «Кодерун AI». Пока фича в бета-режиме, нужна авторизация, а лимит — 20 запросов в сутки.

#инструмент дня

Надоело каждый раз выходить из уютной консоли и открывать caniuse.com, чтобы посмотреть, с каких браузеров поддерживаются сабгриды?

Ой, только не говорите, что я один тут верстаю вслепую.

Вашему вниманию Bramus Van Damme и его caniuse-cli: https://www.npmjs.com/package/@bramus/caniuse-cli

$ caniuse viewport-units
$ caniuse "viewport units"
$ caniuse @property

Имеется автокомплит для zsh.

Ну, консольные маньяки, перепись!

P. S. Скилл для Клода есть же уже?)

#cli #caniuse #бородач

#такое дня

Когда в следующий раз будете ворчать на коллегу за PR в 200 строк — вспомните это: https://github.com/oven-sh/bun/pull/30412

Ментейнеры Bun, конечно, могут сколько угодно рассказывать нам о бессонных ночах в попытке отдебажить утечку памяти в Zig (будучи крупнейшим проектом на этом языке), но без этих ночей ничего бы не вышло.

Штош.

P. S. кстати, почитайте, что ответили авторы Zig о недавнем «ИИ-форке», который представили Bun. Там прям интересно.

#rust #zig

#фишка дня

Итак, все мы знаем, что при добавлении скроллбара (если этот скроллбар, конечно, виден) у нас происходит сдвиг по фазе полей справа.

Ну или слева, если вы араб.

Но это же можно исправить! Используя правило scrollbar-gutter: stable можно зарезервировать место под скроллбар, не прибегая к иным методам вроде overflow: scroll (который буквально этот самый скроллбар заранее покажет, даже если он не нужен).

Демо от Ахмада Шадида в его Defensive CSS: https://defensivecss.dev/tip/scrollbar-gutter/

Can I Use: https://caniuse.com/?search=scrollbar-gutter

Поддержка в Chrome и Firefox. В Safari пока только в TP, но на Apple-устройствах скроллбары, как правило, скрыты и отображаются поверх контента, не занимая места.

Выглядит это, правда, как дополнительный паддинг, но!

Есть интересное но в виде scrollbar-gutter: stable both-edges, которое зарезервирует место под скроллбар, и такое же — на другой стороне. Что, в целом, избавит нас от разных паддингов.

Раньше за похожее решение отвечало правило overflow: overlay, но его отменили в пользу gutter.

Лучше всего это работает, впрочем, для попапов. Мало кого волнует скроллбар на тексте, а вот прыгающий body при появлении модалки — это уже перебор.

#css #scrollbar #gutter #бородач