#заметка дня
Мне не очень нравится вложенность в SASS/SCSS/LESS и иже с ними.
Не очень нравится и будущее предложение внести вложенность (nesting) в CSS.
И я поясню, почему.
В первой части заметки много кода, телега не справится. Пройдите сюда, пожалуйста: https://gist.github.com/bekharsky/dea79c6b51fb693fba81897a40a594a4
Не так давно я в чате пытался помочь человеку, который накидал & для формирования классов (пытался в БЭМ) и никак не мог понять, как же сделать &:hover.
Получалось что-то вроде:
Кто-то на этом месте фыркнет. И будет неправ, потому что SCSS мог бы вместо простой конкатенации строк делать что-то более умное с блоками. Но надо ли?
Более опытные вспомнят про кеширование селекторов. Тоже вариант. Закешируем с десяток, почему нет… попробуй разберись.
В общем, я с некоторых пор использую нестинг только для псевдо- классов и элементов. Ограничиваю область видимости, не пытаясь решить все проблемы на свете.
Нестинг затрудняет понимание кода и поиск. Стили потомка могут оказаться в любом месте стилей родителя. Зачем?
Все мои аргументы касаются только читаемости кода. Ты можешь быть юным гением, который знает любое место в своём проекте. Но зачем вообще тратить ресурсы мозга на это?
#css #scss #nesting
Мне не очень нравится вложенность в SASS/SCSS/LESS и иже с ними.
Не очень нравится и будущее предложение внести вложенность (nesting) в CSS.
И я поясню, почему.
В первой части заметки много кода, телега не справится. Пройдите сюда, пожалуйста: https://gist.github.com/bekharsky/dea79c6b51fb693fba81897a40a594a4
Не так давно я в чате пытался помочь человеку, который накидал & для формирования классов (пытался в БЭМ) и никак не мог понять, как же сделать &:hover.
Получалось что-то вроде:
.block {
&__element {
// styles
}
&:hover {
&__element {
// styles
}
}
}
Кто-то на этом месте фыркнет. И будет неправ, потому что SCSS мог бы вместо простой конкатенации строк делать что-то более умное с блоками. Но надо ли?
Более опытные вспомнят про кеширование селекторов. Тоже вариант. Закешируем с десяток, почему нет… попробуй разберись.
В общем, я с некоторых пор использую нестинг только для псевдо- классов и элементов. Ограничиваю область видимости, не пытаясь решить все проблемы на свете.
Нестинг затрудняет понимание кода и поиск. Стили потомка могут оказаться в любом месте стилей родителя. Зачем?
Все мои аргументы касаются только читаемости кода. Ты можешь быть юным гением, который знает любое место в своём проекте. Но зачем вообще тратить ресурсы мозга на это?
#css #scss #nesting
👍3
#статья дня
Схлопывание отступов… марджинов, маргинов, margin — да как пожелаете.
В мире flexbox и grid всю боль этой фразы понять непросто, хотя стоило бы. Возможно, перестали бы пихать флекс там, где достаточно блока… ну да ладно. Чего только стоит один мой недавний вопрос: https://t.me/htmlshit/531
Но Джош Камю просто взял и сделал прекрасную статью, на пальцах и картинках объясняющую схлопывания в разных ситуациях: https://www.joshwcomeau.com/css/rules-of-margin-collapse/
Как всегда, горячо рекомендую если не читать, то хотя бы по примерам потыкать. Лучше никто не делает пока :)
#css #margin #collapse #tutorial
Схлопывание отступов… марджинов, маргинов, margin — да как пожелаете.
В мире flexbox и grid всю боль этой фразы понять непросто, хотя стоило бы. Возможно, перестали бы пихать флекс там, где достаточно блока… ну да ладно. Чего только стоит один мой недавний вопрос: https://t.me/htmlshit/531
Но Джош Камю просто взял и сделал прекрасную статью, на пальцах и картинках объясняющую схлопывания в разных ситуациях: https://www.joshwcomeau.com/css/rules-of-margin-collapse/
Как всегда, горячо рекомендую если не читать, то хотя бы по примерам потыкать. Лучше никто не делает пока :)
#css #margin #collapse #tutorial
#фишка дня
…несуществующая
В эту последнюю пятницу лета (в Финляндии лето считают с мая по июль, чтобы хотя бы два месяца осени были без снега) хочется помечтать.
Вы только подумайте, насколько простым стало бы создание стилизованных радиокнопок и чекбоксов если бы у нас в руках был :has… суть – родительский селектор.
Но его нет. Он только лишь обсуждается: https://www.w3.org/TR/selectors-4/#relational
Правда, это сломает многие оптимизации в браузерах… но может, новые завезут.
Мечты, мечты…
#css #has
…несуществующая
В эту последнюю пятницу лета (в Финляндии лето считают с мая по июль, чтобы хотя бы два месяца осени были без снега) хочется помечтать.
Вы только подумайте, насколько простым стало бы создание стилизованных радиокнопок и чекбоксов если бы у нас в руках был :has… суть – родительский селектор.
Но его нет. Он только лишь обсуждается: https://www.w3.org/TR/selectors-4/#relational
Правда, это сломает многие оптимизации в браузерах… но может, новые завезут.
Мечты, мечты…
#css #has
#заметка дня
Не давече чем вчера ко мне прибежал начальник нашего энтерпрайза с мольбой о помощи. «Все пропало», — говорит, — «Значения текстовых полей в форме настроек дублировались, это починили, но теперь не все данные сохраняются. Выручай!».
А все потому что коллега перед тем, как в отпуск уйти, сделал рефакторинг ключей (key) в выводе массивов в React. И почти всё протестировал.
Казалось бы, ключи. Но даже вроде бы опытные разработчики ошибаются и делают key недостаточно уникальными, что может привести, и приводит, к последствиям, описанным выше.
Форму я, конечно, починил, косяк был буквально в паре строк. Но придётся коллеге по возвращению скинуть тред небезызвестного Дэна Абрамова: https://mobile.twitter.com/dan_abramov/status/1415279090446204929?s=20
Буквально на пальцах и кружках 🔴🔵🟡 описано, в чем же вообще проблема и зачем React’у так нужны ключи в выводе массивов.
#react #key
Не давече чем вчера ко мне прибежал начальник нашего энтерпрайза с мольбой о помощи. «Все пропало», — говорит, — «Значения текстовых полей в форме настроек дублировались, это починили, но теперь не все данные сохраняются. Выручай!».
А все потому что коллега перед тем, как в отпуск уйти, сделал рефакторинг ключей (key) в выводе массивов в React. И почти всё протестировал.
Казалось бы, ключи. Но даже вроде бы опытные разработчики ошибаются и делают key недостаточно уникальными, что может привести, и приводит, к последствиям, описанным выше.
Форму я, конечно, починил, косяк был буквально в паре строк. Но придётся коллеге по возвращению скинуть тред небезызвестного Дэна Абрамова: https://mobile.twitter.com/dan_abramov/status/1415279090446204929?s=20
Буквально на пальцах и кружках 🔴🔵🟡 описано, в чем же вообще проблема и зачем React’у так нужны ключи в выводе массивов.
#react #key
Twitter
Dan
Why React Needs Keys, a short visual explanation. Each render is like a frame in a movie. React doesn’t know *what* you did with your data. It only sees the JSX from the previous render and then from the next render. circles.map(c => <Circle color={c.color}…
#фишка дня
Мне тут сообщили, что в 92 Хром и в 90 Фаерфокс с пылу с жару завезли метод Array.prototype.at(). Передаёте в at индекс элемента массива и получаете его значение, собственно.
Я сижу и честно говоря не очень понимаю, зачем он так сильно всем нужен.
Если коротко, то при передаче положительного числа, он работает точно так же, как и . Т. е.
Веселье заключается в том, что at поддерживает отрицательные значения индекса. И вы правильно догадались, они отсчитывают значения элементов с хвоста.
Последний элемент имеет индекс -1.
Т. о. то, что раньше писалось как
Собеседник сказал, что от первого варианта пахнет языком Си 🧐. По-моему так от обоих.
А каково ваше мнение?
#js #array
Мне тут сообщили, что в 92 Хром и в 90 Фаерфокс с пылу с жару завезли метод Array.prototype.at(). Передаёте в at индекс элемента массива и получаете его значение, собственно.
Я сижу и честно говоря не очень понимаю, зачем он так сильно всем нужен.
Если коротко, то при передаче положительного числа, он работает точно так же, как и . Т. е.
arr[2] и arr.at(2) оба вернут третий элемент. Веселье заключается в том, что at поддерживает отрицательные значения индекса. И вы правильно догадались, они отсчитывают значения элементов с хвоста.
Последний элемент имеет индекс -1.
Т. о. то, что раньше писалось как
arr[arr.length - 1] теперь пишется как arr.at(-1). Ну и так далее. Собеседник сказал, что от первого варианта пахнет языком Си 🧐. По-моему так от обоих.
А каково ваше мнение?
#js #array
MDN Web Docs
Array.prototype.at() - JavaScript | MDN
The at() method of Array instances takes an integer value and returns the item at that index, allowing for positive and negative integers. Negative integers count back from the last item in the array.
Кажется, я нашёл способ гарантированно и бесплатно повторять баги вёрстки в Safari на Windows-машинах. Оставайтесь на связи, попробую упаковать эту информацию максимально доступно 🧐
#заметка дня
Давайте разбираться, что же не так с Safari и почему он отстаёт.
История Safari начинается с движка KHTML, первая версия которого вышла в 1998 году. KHTML разрабатывался как движок рендеринга HTML для среды рабочего стола KDE (как пропатчить KDE2 под FreeBSD?). Как и Trident в Internet Explorer для Windows, его планировалось использовать вообще везде в системе.
Разрабатывался медленно, но верно, и получился великолепным. В итоге именно его форкнули в Apple для создания движка своего браузера и взорвали общественность в 2003 году. Я сокращаю историю, советую почитать хотя бы Википедию, там интересно.
В общем, Safari просто был лучше всех существующих аналогов на тот момент и поэтому именно его движок решили использовать в Google для создания своего браузера. WebKit как раз был выпущен как открытый проект в 2005. В раскрутку Chrome была брошена вся медийная сила Google.
Но двум мощным корпорациям недолго работалось настолько плотно вместе и в 2013 году уже Google форкнули WebKit, создав Blink. Некоторое время рендеринг в движках не сильно отличался, но время шло.
В итоге мы пришли к тому, что Safari, побыв некоторое мультиплатформенным браузером (с 2007 по 2012), уступил место на Windows окончательно. Для Apple это был маркетинговый ход, ибо выглядел он на Windows точно так же, как на macOS, включая даже рендеринг шрифта. Они надеялись так переманить к себе людей.
Прошло 8 лет. Blink и WebKit очень сильно разошлись по своим возможностям. Google начала активно подминать под себя веб, давя всё на своём пути (почитайте хотя бы, почему сдохла Opera). Новые возможности начали появляться как на дрожжах, иногда просто ради реализации желаний того или иного вендора. Иногда этим вендором была сама Google (удивительное рядом).
Apple не имела таких длинных рук в вебе. Ошибка ли это или нет, но компания решила занять позицию "защиты" своих пользователей от посягательств (других вендоров, в основном). Правда где-то они переборщили и далеко не каждая фича современного веба реально имела какое-то отношение к безопасности. Например, различные поля ввода (даты, времени, цвета). Но давайте честно — они и в Chrome c Firefox совершенно неудобны и выглядят крайне странно.
Второй аргумент Apple — это энергоэффективность Safari. И тут им сложно что-то противопоставить, Chrome жрёт батарею просто на ура. Firefox чуть лучше, но в целом у него точно так же имеются проблемы с совместимостью то тут то там, особенно на мобильных устройствах.
Apple, перестав развивать версию Safari для Windows, забросила и адаптацию WebKit, оставив это сторонним разработчикам. Появились WebKitGTK и Qt WebKit. Если слова GTK и Qt вам не знакомы, это, очень грубо говоря, UI-киты для разработки десктопных приложений на разных платформах, но в основном, конечно, для основанных на Linux системах. На WebKit стали появляться независимые браузеры и он приобрёл большую любовь сообщества. Некоторые из них были даже доступны на Windows (Midori, Epiphany).
А потом в мир ворвалась вечно везде опаздывающая последние лет 15 Microsoft и представила WSL, Windows Subsystem for Linux. Стало возможным запускать даже графические приложения без особых проблем вообще и разработка версий вышеупомянутых браузеров для Windows окончательно застопорилась.
Apple никак не помогала адаптировать процессы разработки WebKit, и многие независимые Windows-разработчики повернулись в сторону Blink. Но под Linux разработка не прекращалась и последние версии движка WebKit всё так же доступны в составе современных браузеров.
Завтра я покажу наш первый вариант решения проблемы. Как минимум, из трёх. Многие уже точно догадались, к чему я веду :)
#apple #webkit #safari #wsl
Давайте разбираться, что же не так с Safari и почему он отстаёт.
История Safari начинается с движка KHTML, первая версия которого вышла в 1998 году. KHTML разрабатывался как движок рендеринга HTML для среды рабочего стола KDE (как пропатчить KDE2 под FreeBSD?). Как и Trident в Internet Explorer для Windows, его планировалось использовать вообще везде в системе.
Разрабатывался медленно, но верно, и получился великолепным. В итоге именно его форкнули в Apple для создания движка своего браузера и взорвали общественность в 2003 году. Я сокращаю историю, советую почитать хотя бы Википедию, там интересно.
В общем, Safari просто был лучше всех существующих аналогов на тот момент и поэтому именно его движок решили использовать в Google для создания своего браузера. WebKit как раз был выпущен как открытый проект в 2005. В раскрутку Chrome была брошена вся медийная сила Google.
Но двум мощным корпорациям недолго работалось настолько плотно вместе и в 2013 году уже Google форкнули WebKit, создав Blink. Некоторое время рендеринг в движках не сильно отличался, но время шло.
В итоге мы пришли к тому, что Safari, побыв некоторое мультиплатформенным браузером (с 2007 по 2012), уступил место на Windows окончательно. Для Apple это был маркетинговый ход, ибо выглядел он на Windows точно так же, как на macOS, включая даже рендеринг шрифта. Они надеялись так переманить к себе людей.
Прошло 8 лет. Blink и WebKit очень сильно разошлись по своим возможностям. Google начала активно подминать под себя веб, давя всё на своём пути (почитайте хотя бы, почему сдохла Opera). Новые возможности начали появляться как на дрожжах, иногда просто ради реализации желаний того или иного вендора. Иногда этим вендором была сама Google (удивительное рядом).
Apple не имела таких длинных рук в вебе. Ошибка ли это или нет, но компания решила занять позицию "защиты" своих пользователей от посягательств (других вендоров, в основном). Правда где-то они переборщили и далеко не каждая фича современного веба реально имела какое-то отношение к безопасности. Например, различные поля ввода (даты, времени, цвета). Но давайте честно — они и в Chrome c Firefox совершенно неудобны и выглядят крайне странно.
Второй аргумент Apple — это энергоэффективность Safari. И тут им сложно что-то противопоставить, Chrome жрёт батарею просто на ура. Firefox чуть лучше, но в целом у него точно так же имеются проблемы с совместимостью то тут то там, особенно на мобильных устройствах.
Apple, перестав развивать версию Safari для Windows, забросила и адаптацию WebKit, оставив это сторонним разработчикам. Появились WebKitGTK и Qt WebKit. Если слова GTK и Qt вам не знакомы, это, очень грубо говоря, UI-киты для разработки десктопных приложений на разных платформах, но в основном, конечно, для основанных на Linux системах. На WebKit стали появляться независимые браузеры и он приобрёл большую любовь сообщества. Некоторые из них были даже доступны на Windows (Midori, Epiphany).
А потом в мир ворвалась вечно везде опаздывающая последние лет 15 Microsoft и представила WSL, Windows Subsystem for Linux. Стало возможным запускать даже графические приложения без особых проблем вообще и разработка версий вышеупомянутых браузеров для Windows окончательно застопорилась.
Apple никак не помогала адаптировать процессы разработки WebKit, и многие независимые Windows-разработчики повернулись в сторону Blink. Но под Linux разработка не прекращалась и последние версии движка WebKit всё так же доступны в составе современных браузеров.
Завтра я покажу наш первый вариант решения проблемы. Как минимум, из трёх. Многие уже точно догадались, к чему я веду :)
#apple #webkit #safari #wsl
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Ну, как обещал. Смотрим на баги Safari в Windows. С опозданием на день, но вы мне простите, надеюсь :)
Подробное описание летит следом, терпение.
Подробное описание летит следом, терпение.
#заметка дня
Продолжаем наше сафари по Safari (офигеть каламбур).
Тенденция такова, что вообще никто не любит собирать браузеры на WebKit. Blink компилировать и интегрировать намного приятнее. Остались лишь самые упорные. Ну, с ними и поработаем.
Итак, давайте запустим браузер Epiphany в Windows. Он же GNOME Web.
Установка
Нам понадобится:
1. WSL2: https://docs.microsoft.com/en-us/windows/wsl/install-win10
Не надо бояться, там делов на десять минут.
Кстати, горячо рекомендую попутно поставить WIndows Terminal. И ещё более горячо рекомендую привыкнуть к мысли, что на WSL вообще всё делать удобнее, VSCode вас в этом поддержит.
Могу потом показать, что именно я имею в виду.
2. Я буду производить эксперименты на Ubuntu, так что устанавливаем её из магазина приложений. Более опытные могут брать что угодно.
3. Устанавливаем в Ubuntu epiphany-browser:
Это сервер X Window System. Я намеренно опускаю объяснения, что есть что, для этого есть Википедия, но именно эта штука позволит вам запускать графические приложения Linux в Windows.
Можно ещё XMing, но я в него не умею. Поделитесь.
Если же у вас Windows 10 20H2 или Windows 11, вам даже этот шаг не нужен. Всё заработает из коробки:
В общем, это всё.
Запуск
Можете посмотреть видео выше, а можете — почитать инструкцию:
1. Сначала нужно запустить X-сервер, для этого в составе VcXsrv имеется утилита XLaunch. Стартуем.
2. Она предложит режим работы на выбор, я предпочитаю многооконный полноэкранному.
3. На втором экране выбираем просто запуск сервера, без конкретного клиента (
4. Поскольку моё личное железо довольно бывалое (ThinkPad T450s), я решил не пытаться запускать графическое ускорение, оно всё равно для наших целей не нужно. А вот авторизацию стоит отключить (
5. Ubuntu надо указать, где же находится наш сервер окон. Для чего выполняем следующую команду:
Для этого и нужна вся магия grep и awk. В моём случае получается:
Можно потом и в конфигурацию вашей командной строки внести (.bashrc или .zshrc), чтобы работало сразу при запуске.
6. Ну теперь, пожалуй, надо запустить и сам браузер:
Версия WebKitGTK в моём случае 2.32.3. Это примерно соответствует Safari 14. Внизу баги, которые я проверял на видео:
1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746
2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html
3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/
И — о чудо — они совпадают с Safari 14.1.2. Уж можете мне поверить.
Засылайте ваши любимые баги в комментарии, посмотрим-с.
#safari #linux #webkit #epiphany
Продолжаем наше сафари по Safari (офигеть каламбур).
Тенденция такова, что вообще никто не любит собирать браузеры на WebKit. Blink компилировать и интегрировать намного приятнее. Остались лишь самые упорные. Ну, с ними и поработаем.
Итак, давайте запустим браузер Epiphany в Windows. Он же GNOME Web.
Установка
Нам понадобится:
1. WSL2: https://docs.microsoft.com/en-us/windows/wsl/install-win10
Не надо бояться, там делов на десять минут.
Кстати, горячо рекомендую попутно поставить WIndows Terminal. И ещё более горячо рекомендую привыкнуть к мысли, что на WSL вообще всё делать удобнее, VSCode вас в этом поддержит.
Могу потом показать, что именно я имею в виду.
2. Я буду производить эксперименты на Ubuntu, так что устанавливаем её из магазина приложений. Более опытные могут брать что угодно.
3. Устанавливаем в Ubuntu epiphany-browser:
sudo apt install epiphany-browser
Возможно, списки серверов, раздающих пакеты приложений (да и списки приложений вообще) нужно будет обновить:sudo apt update4. Если у вас версия Windows 10 ниже 20H2, вам потребуется VcXsrv.
Это сервер X Window System. Я намеренно опускаю объяснения, что есть что, для этого есть Википедия, но именно эта штука позволит вам запускать графические приложения Linux в Windows.
Можно ещё XMing, но я в него не умею. Поделитесь.
Если же у вас Windows 10 20H2 или Windows 11, вам даже этот шаг не нужен. Всё заработает из коробки:
В общем, это всё.
Запуск
Можете посмотреть видео выше, а можете — почитать инструкцию:
1. Сначала нужно запустить X-сервер, для этого в составе VcXsrv имеется утилита XLaunch. Стартуем.
2. Она предложит режим работы на выбор, я предпочитаю многооконный полноэкранному.
3. На втором экране выбираем просто запуск сервера, без конкретного клиента (
Start no client). Клиент это, собственно, приложение. Логика X-сервера немного перевёрнута с ног на голову, кому интересно — почитает Википедию, а мы двигаемся дальше.4. Поскольку моё личное железо довольно бывалое (ThinkPad T450s), я решил не пытаться запускать графическое ускорение, оно всё равно для наших целей не нужно. А вот авторизацию стоит отключить (
Disable access control), одна машина же.5. Ubuntu надо указать, где же находится наш сервер окон. Для чего выполняем следующую команду:
export DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'):0.0
Так получилось, что WSL2 требует IP-адрес даже локального компьютера, так что приходится ему его и указывать. Т. е. вот этот кусок внутри большой команды:grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'
Просто выводит ваш собственный локальный IP-адрес.Для этого и нужна вся магия grep и awk. В моём случае получается:
export DISPLAY=192.168.3.1:0.0
В вашем – ваш собственный адрес.Можно потом и в конфигурацию вашей командной строки внести (.bashrc или .zshrc), чтобы работало сразу при запуске.
6. Ну теперь, пожалуй, надо запустить и сам браузер:
epiphany
Если всё было проделано верно, откроется окно браузера, не совсем похожее на ваши привычные Windows-окошки (что за день, каламбур за каламбуром). Это всё потому, что Epiphany использует так называемые Client-side decorations. Это когда управление окном отрисовывается самим приложением. Мы отвлеклись.Версия WebKitGTK в моём случае 2.32.3. Это примерно соответствует Safari 14. Внизу баги, которые я проверял на видео:
1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746
2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html
3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/
И — о чудо — они совпадают с Safari 14.1.2. Уж можете мне поверить.
Засылайте ваши любимые баги в комментарии, посмотрим-с.
#safari #linux #webkit #epiphany
👍2
#такое дня
Разбавим увеличившийся накал серьёзности канала краткой демонстрацией умеренного подхода к тестированию UI/UX от Софии Валитовой.
Хороших выходных! Нам ещё многое с вами предстоит проверить.
Разбавим увеличившийся накал серьёзности канала краткой демонстрацией умеренного подхода к тестированию UI/UX от Софии Валитовой.
Хороших выходных! Нам ещё многое с вами предстоит проверить.
This media is not supported in your browser
VIEW IN TELEGRAM
#codepen дня
Прекрасная работа Стива Гарднера: https://codepen.io/ste-vg/pen/GRooLza
За прошедшие полтора года многие уже, наверное, забыли, что такое самолёты. Этот пример позволит вспомнить 👀
А вообще, если коротко, это очень хороший пример интеграции библиотеки анимации GSAP и 3D-модели в WebGL при помощи Three.js. Код простой, чистый, абсолютно понятный.
И не забывайте, их держит в воздухе магия.
#gsap #scroll #webgl
Прекрасная работа Стива Гарднера: https://codepen.io/ste-vg/pen/GRooLza
За прошедшие полтора года многие уже, наверное, забыли, что такое самолёты. Этот пример позволит вспомнить 👀
А вообще, если коротко, это очень хороший пример интеграции библиотеки анимации GSAP и 3D-модели в WebGL при помощи Three.js. Код простой, чистый, абсолютно понятный.
И не забывайте, их держит в воздухе магия.
#gsap #scroll #webgl
👍2
#видео дня
Если вдруг так получилось, что вам в этот воскресный день дождливо и грустно, советую посмотреть лекцию Жени Обрезкова с детальным разбором настроек конфигурации TypeScript и typescript-eslint. Естественно, совсем не обязательно смотреть все два с половиной часа, ведь есть оглавление. Каждый пример демонстрируется в песочнице. Подойдёт всем :)
https://youtu.be/4Vc-O20llVs
#typescript #tsconfig #eslint
Если вдруг так получилось, что вам в этот воскресный день дождливо и грустно, советую посмотреть лекцию Жени Обрезкова с детальным разбором настроек конфигурации TypeScript и typescript-eslint. Естественно, совсем не обязательно смотреть все два с половиной часа, ведь есть оглавление. Каждый пример демонстрируется в песочнице. Подойдёт всем :)
https://youtu.be/4Vc-O20llVs
#typescript #tsconfig #eslint
YouTube
Подробно tsconfig и typescript-eslint - разбор правил проверки кода и того, когда они полезны
В этом видео Женя Обрезков рассказывает о правилах проверок из tsconfig и typescript-eslint и приводит примеры ошибок, которых они позволяют избежать.
Ссылки из видео:
Небольшой блог пост, в котором Женя описывает вкратце всё то, о чем он говорил в этом…
Ссылки из видео:
Небольшой блог пост, в котором Женя описывает вкратце всё то, о чем он говорил в этом…
👍1
Media is too big
VIEW IN TELEGRAM
Глядите, чего я принёс. Запуск WebKit без виртуальных машин! Продолжение Safari-эпопеи.
Не без минусов, конечно, но коллективно мы можем их решить, думаю. Главный минус — сборка слишком новая.
Подробности через минуту.
Не без минусов, конечно, но коллективно мы можем их решить, думаю. Главный минус — сборка слишком новая.
Подробности через минуту.
#заметка дня
Знаете, идти сложным путём иногда не так плохо. Делиться его прохождением – тем более.
Мне в комментарии и ответы накидали ещё вариантов запуска WebKit на Windows без необходимости в виртуальной машине вообще.
И, кажется, я был не совсем прав.
Нет, я не меняю своего мнения о том, что интегрировать WebKit в свои приложения сложно. Но как оказалось, Windows-сборки, хоть и полуофициальные, существуют! И даже работают.
Как обычно, давайте по порядку.
У проекта WebKit существует некий сборочный цех. Портал, на котором скрипт-боты запускают сборки, пересборки и тесты всего проекта под различные операционные системы и платформы.
Конечно, большинство сборщиков работают для iOS, macOS и Linix различных конфигураций, но и под Windows тоже имеются!
Поехали.
1. Давайте пройдём в раздел сборок. Видим список с ответственными за них ботами.
Нас конечно же интересуют с префиксом Win в названии сборщика. Фильтруем.
2. Находится не так много, берём Apple-Win-10-Release-Build.
Можно и Debug, но размер его – мама не горюй.
3. Проваливаемся в параметры сборщика и видим огромное число готовых к употреблению сборок.
Как несложно догадаться, они все привязаны к конкретным ревизиям движка. Ну то есть, можно повыбирать…
Но не то чтобы. Оказалось, файлы хранятся не так долго, всего около пары недель. Ну давайте двухнедельной давности и возьмём. Ревизия r280313 не могла уйти далеко.
На момент, когда вы это читаете, архив может уже быть удалён. Поскольку эта версия максимально близка к обсуждаемой Safari 14.1.2, я приложу её отдельно.
Вообще, обещали, что минифицированные архивы будут храниться пару лет: https://webkit.org/blog/7978/introducing-webkit-build-archives/
Видимо, не для всех сборок… надо узнавать.
4. Прямая ссылка скрыта в шаге 12: transfer-to-s3. Находим её в логе, называется S3 URL. Скачиваем архив, распаковываем.
5. Находим в распаковке MiniBrowser.exe и… и запускаем?
Хрен там. Нужен Apple Application Support. Грубо говоря, набор библиотек для запуска.
Как его получить? Установить iTunes. Apple в своём репертуаре, конечно.
Раньше можно было распаковать установщик iTunes и установить библиотеки отдельно, но теперь – не выйдет :(
6. Ну что же, установили iTunes. И вот теперь можно и запустить!
Как и прежде, проверять я буду на:
1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746
2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html
В рассматриваемой ревизии этот баг уже исправлен.
3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/
Как и прежде, прошу вас делиться результатами и любимыми багами.
Оставайтесь на связи. Мы ещё не закончили.
#safari #bug #webkit #windows
Знаете, идти сложным путём иногда не так плохо. Делиться его прохождением – тем более.
Мне в комментарии и ответы накидали ещё вариантов запуска WebKit на Windows без необходимости в виртуальной машине вообще.
И, кажется, я был не совсем прав.
Нет, я не меняю своего мнения о том, что интегрировать WebKit в свои приложения сложно. Но как оказалось, Windows-сборки, хоть и полуофициальные, существуют! И даже работают.
Как обычно, давайте по порядку.
У проекта WebKit существует некий сборочный цех. Портал, на котором скрипт-боты запускают сборки, пересборки и тесты всего проекта под различные операционные системы и платформы.
Конечно, большинство сборщиков работают для iOS, macOS и Linix различных конфигураций, но и под Windows тоже имеются!
Поехали.
1. Давайте пройдём в раздел сборок. Видим список с ответственными за них ботами.
Нас конечно же интересуют с префиксом Win в названии сборщика. Фильтруем.
2. Находится не так много, берём Apple-Win-10-Release-Build.
Можно и Debug, но размер его – мама не горюй.
3. Проваливаемся в параметры сборщика и видим огромное число готовых к употреблению сборок.
Как несложно догадаться, они все привязаны к конкретным ревизиям движка. Ну то есть, можно повыбирать…
Но не то чтобы. Оказалось, файлы хранятся не так долго, всего около пары недель. Ну давайте двухнедельной давности и возьмём. Ревизия r280313 не могла уйти далеко.
На момент, когда вы это читаете, архив может уже быть удалён. Поскольку эта версия максимально близка к обсуждаемой Safari 14.1.2, я приложу её отдельно.
Вообще, обещали, что минифицированные архивы будут храниться пару лет: https://webkit.org/blog/7978/introducing-webkit-build-archives/
Видимо, не для всех сборок… надо узнавать.
4. Прямая ссылка скрыта в шаге 12: transfer-to-s3. Находим её в логе, называется S3 URL. Скачиваем архив, распаковываем.
5. Находим в распаковке MiniBrowser.exe и… и запускаем?
Хрен там. Нужен Apple Application Support. Грубо говоря, набор библиотек для запуска.
Как его получить? Установить iTunes. Apple в своём репертуаре, конечно.
Раньше можно было распаковать установщик iTunes и установить библиотеки отдельно, но теперь – не выйдет :(
6. Ну что же, установили iTunes. И вот теперь можно и запустить!
Как и прежде, проверять я буду на:
1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746
2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html
В рассматриваемой ревизии этот баг уже исправлен.
3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/
Как и прежде, прошу вас делиться результатами и любимыми багами.
Оставайтесь на связи. Мы ещё не закончили.
#safari #bug #webkit #windows
280313.zip
295.7 MB
Сборка WebKit Apple-Win-10-Release-Build от 27 июля 2021 года.
#заметка дня
У всей этой истории с Safari должен быть happy end.
TL;DR Browserstack.com
Но не все могут себе позволить даже 150 долларов в год за фриланс-план… или всё же есть выход?
Выход правда есть!
Browserstack активно поддерживает open-source проекты и даёт бесплатные лицензии на год!
Если у вас есть такой — смело топайте на https://www.browserstack.com/open-source и вбивайте там ссылку на репозиторий.
Главное — чтобы была подходящая лицензия. Полного списка я не нашёл, но уверен, что GPL, BSD и MIT точно включены. Я же указал Creative Commons Attribution 4.0 International.
Ах да, что же у меня за проект такой опенсорс? Да просто сайт этого канала: https://github.com/HTMLShit/htmlshit.site
Он немного в анабиозе сейчас, но работа над ним не прекращена.
После прохождения ручной модерации, мне пришло письмо. Я получил годовые планы тестирования браузера и мобильных с весьма вкусными условиями.
Короче, если вы ещё не начали свой проект – чего вы ждёте вообще?
#browserstack #safari #windows #test
У всей этой истории с Safari должен быть happy end.
TL;DR Browserstack.com
Но не все могут себе позволить даже 150 долларов в год за фриланс-план… или всё же есть выход?
Выход правда есть!
Browserstack активно поддерживает open-source проекты и даёт бесплатные лицензии на год!
Если у вас есть такой — смело топайте на https://www.browserstack.com/open-source и вбивайте там ссылку на репозиторий.
Главное — чтобы была подходящая лицензия. Полного списка я не нашёл, но уверен, что GPL, BSD и MIT точно включены. Я же указал Creative Commons Attribution 4.0 International.
Ах да, что же у меня за проект такой опенсорс? Да просто сайт этого канала: https://github.com/HTMLShit/htmlshit.site
Он немного в анабиозе сейчас, но работа над ним не прекращена.
После прохождения ручной модерации, мне пришло письмо. Я получил годовые планы тестирования браузера и мобильных с весьма вкусными условиями.
Короче, если вы ещё не начали свой проект – чего вы ждёте вообще?
#browserstack #safari #windows #test
This media is not supported in your browser
VIEW IN TELEGRAM
#тред дня
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.
2. Для начала - зачем это всё?
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.
3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
4. Способы чтобы иметь хорошо поддерживаемый код:
✅Покрытие тестами
✅Ведение документации
✅Код ревью
И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.
5. Что даёт код ревью:
➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои
6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью
Дальше советы из моей практики. На объективность не претендую.
7.
❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все
В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.
8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.
9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.
10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).
Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.
11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее
12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.
Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.
13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код
Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо
#работа #pr #github #twitter
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.
2. Для начала - зачем это всё?
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.
3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
4. Способы чтобы иметь хорошо поддерживаемый код:
✅Покрытие тестами
✅Ведение документации
✅Код ревью
И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.
5. Что даёт код ревью:
➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои
6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью
Дальше советы из моей практики. На объективность не претендую.
7.
❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все
В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.
8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.
9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.
10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).
Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.
11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее
12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.
Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.
13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код
Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо
#работа #pr #github #twitter
#статья дня
Вообще, это скорее даже тянет на хештег #фишка.
Есть такой способ навигации по странице, как якоря. Расставляете ссылки формата
И всё прекрасно и работает как задумано, вот только если у вас есть зафиксированная при скролле шапка, она закроет часть содержимого.
Как с этим боролись раньше? А довольно забавным образом.
Вместо всей секции ссылались на некий элемент:
К счастью, теперь это не нужно! Пруф: https://getpublii.com/blog/one-line-css-solution-to-prevent-anchor-links-from-scrolling-behind-a-sticky-header.html
TL;DR: scroll-padding-top на :root или scroll-margin-top на целевой элемент.
Прям прекрасно. Очевидно, работает не только для якорей, но и для scroll-snap интерфейсов.
И уже можно использовать.
#css #scroll #margin #anchor
Вообще, это скорее даже тянет на хештег #фишка.
Есть такой способ навигации по странице, как якоря. Расставляете ссылки формата
<a href=“#news”>News</a> и, собственно, раздел: <section id=“news”>bla</section>.И всё прекрасно и работает как задумано, вот только если у вас есть зафиксированная при скролле шапка, она закроет часть содержимого.
Как с этим боролись раньше? А довольно забавным образом.
Вместо всей секции ссылались на некий элемент:
<a name=“news”></a>, который сдвигали отрицательным margin или position: relative на величину высоты шапки. Грубовато, но работало!К счастью, теперь это не нужно! Пруф: https://getpublii.com/blog/one-line-css-solution-to-prevent-anchor-links-from-scrolling-behind-a-sticky-header.html
TL;DR: scroll-padding-top на :root или scroll-margin-top на целевой элемент.
Прям прекрасно. Очевидно, работает не только для якорей, но и для scroll-snap интерфейсов.
И уже можно использовать.
#css #scroll #margin #anchor
👍1