«Неаккуратно как-то», — говорили они…

Подписываясь на крупные промо-проекты, будьте крайне осторожны, котаны :)

#threejs #promo

#ссылка дня

GreenSock, создатели широко известной библиотеки для анимации GSAP, решили закрыть разом все вопросы по работе со скроллом. Эффекты? Нате. Анимация? Нате. Параллакс? Их есть у меня. Анимировать SVG? Без проблем. Даже WebGL завезли.

В общем, они просто взяли и выложили подборку различных эффектов анимации по скроллу, добавили к каждому видео-предпросмотр и ссылку на CodePen.

Меньше слов, больше ссылок:

https://greensock.com/st-demos/

P. S. Библиотека GSAP имеет весьма развесистое лицензирование, но условия бесплатного использования покрывают даже некоторые коммерческие применения. В любом случае, идеи — бесценны.

#gsap #css #js #scroll #animation

#ссылка дня

Вот так вот ноябре 2011 года мы занимались адаптивной вёрсткой.

Три устройства, три разных платформы. Android, webOS и iOS.

И на всех трёх — браузеры, основанные на WebKit. И на Android явно проблемы.

Было забавно наблюдать в последующие года, как Chrome завоёвывал рынок, кастомные WebKit-браузеры на устройствах исчезали (впрочем, китайские телефоны до сих пор ставят что-то своё), а Safari стремительно отставал.

Впрочем, в последние пару лет Safari умудрился догнать и перегнать Chrome по скорости ввода новых фич. Например, вот новости с прошедшей WWDC 2022: https://webkit.org/blog/12824/news-from-wwdc-webkit-features-in-safari-16-beta/

Container Queries, Subgrids, Flexbox Inspector, WebPush на iOS (ого!), Animation offset path…

Неплохо стреляют.

#safari #ios #macos #wwdc

#статья дня

Тот случай, когда статья шестилетней давности не потеряла ни капли актуальности. Превращаем GIF в SVG и анимируем с помощью CSS: https://cssanimation.rocks/buffer/

1. Как векторизовать изображение (трейсинг).
2. Как разбить анимацию на составляющие (метод таймлайна).
3. И как, собственно, реализовать на ключевых кадрах.

Обратите внимание: временная шкала рисуется руками. Это очень удобно и наглядно, практически как графическое решение уравнения. Сразу понятны все проблемы. Если интересно — давайте обсудим, как конкретно это реализовывать.

Классика вечна :)

#css #svg #gif #animation

#такое дня

Мир изменился. Сегодня хороним Internet Explorer: https://www.theguardian.com/technology/2022/jun/15/microsoft-to-retire-internet-explorer-browser-and-redirect-users-to-edge

Не могу я сказать, что в мире IE трава была зеленее. Вообще нет.

Да, кто-то и дальше будет поддерживать IE11 или даже ниже. Сил вам, котаны.

А мы побежали дальше.

#ie #microsoft

#статья дня

Давай сегодня тему пошире. Если ты работаешь с проектами крупнее одного лендинга за раз, или более того — с продуктами, резко встаёт вопрос целесообразности внедрения той или иной фишки.

Просто «потому что хочется» работает на самых первых этапах, ведь проекты создаются для того, чтоб решить какую-то конкретную боль клиента. Иногда клиент — основатель стартапа.

А вот потом начинается производственный ад. Виной которому менеджеры продукта.

Ну конечно же не они, но именно они будут отвечать за ведение проекта и внедрение результатов. И за аналитику на первом этапе, конечно же. Так как же с ними договариваться и как они будут принимать это решение? Ну или, как минимум, приоритизировать задачи?

в один пост не вместилось, далее… ⏭

А формула проста, и имя ей RICE-фреймворк.

Берём коэффициенты:

Reach: сколько людей будет затронуто, число
Impact: насколько сильно,0.25, 0.5, 1, 2, 3
Confidence: степень уверенности в этом, в процентах
Effort: сколько сил потребуется, любое положительное число, сторипоинты, человеко-месяцы, часы; что угодно используемое в конторе

И считаем: (R*I*C)/E. Больше число — больше уверенности в успехе. Или как минимум в целесообразности начала разработки.

А вот что такое готовность и успех можно поговорить позже.

Правда это всё не включает Developer’s Enjoyment 🥲

Подробнее тут: https://hello.ducalis.io/knowledge-base/rice-scoring-prioritization-framework

#статья, а заодно и #инструмент, дня

Я очень люблю заказывать себе и другим футболки с разными глупыми и не очень рисунками. Очень часто найти оригинал изображения не представляется возможным по разным причинам. В наличии только хреновенький растр.

Естественно, это никуда не годится и приходится переводить изображение в векторный формат, SVG. Трассировать его, выражаясь профессиональным языком.

Обынчо залетаешь в поиск с запросом "image to vector online" и там уже выбираешь между хорошим и бесплатным. Когда не лень, можно побаловаться консольными утилитами вроде https://potrace.sourceforge.net/ или условными Inkscape, люстрой, дровами.

И вот Томас Штайнер взял Potrace, собрал его под WebAssembly и выдал SVGcode. По пути не преминув запилить целую статью: https://web.dev/svgcode/

Она сильно поможет тем, кто тоже хочет научиться писать универсальные утилиты используя доступные инструменты, с чего начать и какие API использовать.

Да и сам SVGCode весьма хорош :)

#svg #pwa #trace

#такое дня

Не про разработку, сорян. Просто не могу не поделиться путешествием из Вильнюса в Хельсинки.

В Вильнюсе у нашей компании есть офис, и тимлидов отправили туда на, простите, тимбилдинг.

И если дорога туда была прекрасной, хоть я и впервые в жизни летал на турбовинтовом самолёте, то обратно…

Вылет ожидался в 17:40. Нас посадили в автобус, мариновали 20 минут, выгнали обратно в терминал. Рейс перенесли на 20:00.

А после — отменили. Пришло письмо, что переносят на 05:45 утра, с пересадкой и тремя часами простоя в Риге. Ну ок, поужинали, пошли получать отель и ваучеры.

Ага, хуяучеры.

Сотрудники не знали вообще ничего. Даже пытались нас убедить, что вылет по UTC. Прекрасное.

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

В три часа ночи выдвинулись обратно в аэропорт. На сей раз платили кэшем (нас семь человек), но поскольку все такси были вызваны заранее, цены просто удивили — 8 и 6 евро. Да, аэропорт в городе и ехать десять минут, но в Хельсинки ты за эти деньги разве что в это самое такси только сядешь.

Вылет в Ригу прошёл вовремя, уже на турбовентиляторном самолёте, так что было гладко. Но из Риги в Хельсинки вылет задержали еще на полтора часа почти.

В общем, поездка-то шикарная, но готовым надо быть ко всему. Конечно, авиакомпания возместит убытки, но неприятный осадок всё-таки остался.

UTC, блин. Всю жизнь буду помнить.

Берегите себя, котаны :)

#статья дня

В честь официального прекращения поддержки IE вспомним неожиданно прекрасную статья о том, как делали сайты тогда: https://habr.com/ru/company/ruvds/blog/564300/

«Когда?», — спросите вы. «Тогда», — отвечу вам я. Потому что уж слишком долго IE6 задержался на олимпе браузеров и доживал своё ещё век.

В общем, автор решил повторить интерфейс Facebook теми средствами, что были доступны тогда. Под IE6, соответственно.

Получилось прекрасно, всплакнул.

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

Рекомендую. 11 из 10.

#ie6 #facebook #css #layout

#статья дня

Не так давно я узнал два новых слова: суперэллипс (ну ок, это я и раньше знал) и квадруг.

Ага, квадруг. Squircle. Т. е. фигура между квадратом и кругом, но не просто квадрат со скруглёнными углами. Кроме шуток: https://en.wikipedia.org/wiki/Squircle

Так вот, иконки приложений на iOS — квадруги. Сквирклы, если хотите. Хотя очень многие путают их с обычным сопряжением прямой с окружностью (ага, с border-radius).

В общем, от слов к статье: https://medium.com/@nikolskayaolia/an-easy-way-to-implement-smooth-shapes-such-as-superellipse-and-squircle-into-a-user-interface-a5ba4e1139ed

Вообще, тема оптических иллюзий в иконках и логотипах крайне интересна. И очень часто и квадраты не квадраты, и круги не круги…

Найду статью на эту тему — скину. Ну или пишите, если хотите примеров.

#ios #illusion

#codepen дня

В чём секрет производительных анимированных градиентов?

В том, что их не надо анимировать!

Анимировать градиент через установку background-position, кейфреймы на цвета или пользовательские свойства, конечно, можно. Но это будет вызывать излишние перерисовки (repaint), читаем.

Работать-то будет: https://codepen.io/P1N2O/pen/pyBNzX

А что лучше? Так старый добрый transform. Не на фон, конечно же, а на псевдоэлемент, его содержащий. Его и двигайте. Давайте что-нибудь запилим прям щас.

Например, очередной лоадер на этой неделе: https://codepen.io/alinaki/pen/zYGvWYN

Одним градиентом рисуем полоски, второй — запихиваем в псевдоэлемент и двигаем его.

Ну вроде ок, не? Кто сделает на шейдерах?

P. S. впрочем, иногда можно и пользовательскими свойствами долбануть по всем фронтам: https://dev.to/afif/we-can-finally-animate-css-gradient-kdk

#css #gradient #performance

#заметка дня

Один из самых проблемных вопросов верстальщиков — не обязательно начинающих — это так называемый “пиксель пёрфект” (pixel perfect). Проще говоря, свёрстанный макет должен полностью соответствовать дизайну вплоть до последнего пикселя.

Сейчас справедливо поднимется вой со всех сторон, что в 2022 году верстать с точностью до пикселя не надо, что у нас десятки разных разрешений экранов, множество возможных комбинаций ориентации и устройств ввода. Да и квалификация дизайнеров зачастую вызывает вопросы.

Но всё немного интереснее.

Давайте сразу определимся: правильно свёрстанный макет точен до пикселя по умолчанию. Точка.

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

У блока стоят поля и отступы по 16 пикселей? Нет ни одной причины ставить 15, чтобы «было легче считать» (и такое бывает), а потом проходить по всему макету заново. Ставьте сразу 16, а чтобы помочь себе — пользуйтесь расширениями для браузера, например https://www.welldonecode.com/perfectpixel/

Конечно, так можно дойти до крайности. Я много раз видел как люди бездумно копируют размеры из Sketch, Avocode или Figma, наивно полагая, что уж кому как не им знать о размерах и положении. Это самая большая ошибка, и я уж молчу о том, что редакторы зачастую ставят абсолютное позиционирование всему подряд.

Будьте заранее готовы к тому, что макет – живой. Выделенный блок делится на секции? Используйте проценты во флексах или fr в гридах, делите его относительными единицами. Дизайнер поставил 63 px? Это явно дрогнула рука, не используйте нечётные значения никогда, округляйте до ближайших x4 (в данном случае — 64). Во всех размерах должна просматриваться логика, не могут три кнопки в ряду иметь один размер, а четвёртая – другой.

Почему кратно четырём? Потому что округление в пределах четырёх пикселей вполне укладывается в общепринятое понятие точной вёрстки, но на крайний случай у вас останется ещё как минимум два уровня деления. А при использовании нечётных значений transform или устройства с полуторной плотностью экрана дадут вам размытую картинку (к счастью, последние версии браузеров эту проблему часто решают за нас).

В скором времени я попробую затронуть тему вёрстки изначально неудобных макетов: что делать если вам выдали макет в 1920 пикселей, а большинство ноутбуков до сих пор имеют 1366 и как вести диалог с дизайнером и заказчиком в такой ситуации.

#css #html #pp #pixelperfect

#видео дня

Когда я выкатил пост со шпаргалками по TypeScript в React, поднялся некоторый вой.

Мол, не нужно, навязали, неудобно и так далее.

O RLY? Ну ок. Типы в JS всё равно могут появиться. Например, вот предложение в рабочую группу ECMAScript TC39 от Гила Тайяра:

https://www.youtube.com/watch?v=SdV9Xy0E4CM

В сухом остатке, типы становятся лишь комментариями для их проверки и более ни на что не влияют. Такое себе расширение JSDoc.

Кто-то в восторге, кто-то считает, что уж проще тогда TypeScript использовать.

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

#js #ts #types

#фишка дня

Нормальные «математические» или «операторные» медиазапросы скоро будут доступны не только в Firefox, как я писал в одном из постов, но и в Chrome 104: https://developer.chrome.com/blog/media-query-range-syntax/

Короче говоря, вместо такой вот ерунды:

@media (min-width: 400px) and (max-width: 600px) {
// Styles for viewports between 400px and 600px.
}

Будем писать такую:

@media (400px <= width <= 600px) {
// Styles for viewports between 400px and 600px.
}

Мне нравится больше. Кому ещё — глядите на плагин для PostCSS: https://github.com/postcss/postcss-media-minmax

#css #math #mediaqueries

#книга дня

Для тех, чей взор на типографику распространяется дальше, чем написать margin: 1em 0.

Александра Королькова уже достаточно давно выложила в бесплатный доступ свою книгу “Живая типографика”.

А я свою на Авито покупал когда-то, потому что тираж был полностью распродан…🙂

https://leksandra.livejournal.com/120488.html

Приобщаемся к основам типографики и благодарим автора.

Ссылка из поста: https://yadi.sk/i/oy19NzNjydZjR

#типографика

#codepen дня

Я вообще хотел очередной дедовской разгон на тему вёрстки и общения с заказчиком, но мне чота в лом. Может открытую дискуссию устроим под этим постом…

А сам пост будет посвящен прекрасному примеру использования SVG-фильтров на реальном контенте.

Помните, я когда-то показывал газету на CSS-grid? Ну вот же: https://t.iss.one/htmlshit/508

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

И вот тут на помощь придёт реализация шума Перлина aka Perlin Noise для SVG: https://codepen.io/simoncoudeville/pen/zYRygaV

Можно побаловаться настройками внизу, можно изменять контент как душе угодно. Абсолютно прекрасный по своей сути пример.

#svg #effect #filter

#ссылка дня

Сегодня я подобрал максимально красивый ресурс: набор демок на WebGL: https://ykob.github.io/sketch-threejs/

Эффекты глитча, игры с частицами, огонь, солнце, вода! Огонь, кстати, выглядит пугающе натурально. А я когда-то убедил заказчика обойтись вариантом попроще… не знал :)

Все примеры с исходными кодами, есть и весьма практичные, вроде галереи.

#js #webgl

#заметка дня

Пожалуйста, прекратите засорять глобальное пространство имён утилитами из npm/yarn.

Это я о чём:


$ npm i -g gulp
…bla-bla-bla
$ gulp


Не надо! Даже если документация говорит вам это сделать. Или, ещё хуже, рандомный ютубер или блогер.

Используйте для ваших локальных задач npm-скрипты:


$ npm i gulp
…create your scripts
$ npm run gulp


А для глобальных, скорее всего, есть инструменты получше.

Итак, как же работают npm-скрипты?

Если вы зайдёте в каталог node_modules, со всеми пакетами, там будет вложенный каталог .bin. Но вот исполняемых файлов, бинарников, там нет. А есть т. н. символические ссылки, симлинки. А вот уже они указывают на нужный файл в каком-либо конкретном пакете.

Как они узнают, куда указывать? Всё просто: в package.json нужного пакета будет, опять же, секция bin.

Итого, если node run xxx не нашёл скрипта с нужным именем, он полезет за ним в локальное пространство имён. Не найдя приложения в локальном пространстве имён, он полезет в глобальное и запустит приложение.

Почему это полезно?

Да потому что можно держать миллион разных версий gulp/webpack/vite/далее везде и не страдать по этому поводу. Работать будет всегда и везде. А если сюда приплюсовать nvm… Но об этом потом.

Кому интересны подробности, вот вам баззворд для лучшего понимания проблемы: PATH.

Задавайте ваши ответы, котаны.

P. S. inb4 npx

#js #node #run

#статья дня

Я недавно разработал своё расширение для Chrome DevTools. Пока достаточно примитивное, но уже очень помогающее мне в работе. В паблик вряд ли выйдет, но большинство всё равно о моей рабочей среде не знает… Нужен хороший definition of done и отмашка руководства для этого.

Так вот, пока искал информацию там-сям, наткнулся на интервью одного из разработчиков DevTools: https://habr.com/ru/company/jugru/blog/452990/

Двухлетней давности, но крайне занимательное. Редко у кого есть настолько глубокое погружение в задачу. Один тот факт, что Netflix использует свой собственный веб-движок уже достоин интереса.

#chrome #devtools

#предложение дня

Реклама-рекламой, но многие из вас, кто пришёл по моим собственным рекламным постам, могли заметить, что я упоминал, что наша компания ищет фронтов.

Вы думаете, я кликбейтил? Почему не написал никто? Вроде, контакты все есть…

Это вам не канал с мемами, камон.

Короче, поехали. Если вы читаете давно, то уже знаете, а если нет — то узнаете сейчас.

Я работаю Engineering Manager (тимлид, короче) в компании Supermetrics. Стартовал с позиции Senior JS.

Компания занимается добыванием и перекладыванием пользовательских данных из разных мест в разные другие места. С обработкой и без. Это если прям на пальцах.

Короче, открытые позиции:
- Senior Frontend Developer: DWH team
- Senior Full-Stack Developer: Data Studio Team
- Lead Web Engineer - Marketing team

Вот по последнему пункту: очень сложно найти хорошего вордпрессника… Давайте попробуем.

Пишите в контакты на странице или мне. Сделаю реф, если всё понравится.

Дерзайте, котаны.