#заметка дня
Давайте разбираться, что же не так с 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
#заметка дня
Продолжаем наше сафари по 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
#заметка дня
Знаете, идти сложным путём иногда не так плохо. Делиться его прохождением – тем более.
Мне в комментарии и ответы накидали ещё вариантов запуска 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
#заметка дня
Я тут вспомнил, что эпопея с запуском WebKit в Windows — а это, суть, возможность тестировать настолько близко к Apple Safari, насколько возможно — была бы неполной без одного важного дополнения.
Давайте вначале вспомним, что было:
1. Краткая история Safari
2. Запуск WebKit-браузера Epiphany в Windows с WSL2
3. Запуск WebKit под Windows без виртуальных машин
4. Happy End в виде бесплатного Browserstack
У всего этого была одна небольшая проблема: WebKit во 2 и 3 вариантах был обычно слишком новый, что соответствовало последним сборкам Safari 14 и 15. Но что же делать, если нужно что-то чуть постарее? На официальном сервере сборки долго не живут.
Так вот, и такое есть: оказывается, старые сборки WebKit можно найти в старых же релизах Playwright: https://playwright.dev/docs/browsers/#managing-browser-binaries
Кто не знает, Playwright — средство для автоматизации тестирования.
Установили — забрали из каталога установки. Кажется, это вполне себе заявка.
#webkit #safari #windows
Я тут вспомнил, что эпопея с запуском WebKit в Windows — а это, суть, возможность тестировать настолько близко к Apple Safari, насколько возможно — была бы неполной без одного важного дополнения.
Давайте вначале вспомним, что было:
1. Краткая история Safari
2. Запуск WebKit-браузера Epiphany в Windows с WSL2
3. Запуск WebKit под Windows без виртуальных машин
4. Happy End в виде бесплатного Browserstack
У всего этого была одна небольшая проблема: WebKit во 2 и 3 вариантах был обычно слишком новый, что соответствовало последним сборкам Safari 14 и 15. Но что же делать, если нужно что-то чуть постарее? На официальном сервере сборки долго не живут.
Так вот, и такое есть: оказывается, старые сборки WebKit можно найти в старых же релизах Playwright: https://playwright.dev/docs/browsers/#managing-browser-binaries
Кто не знает, Playwright — средство для автоматизации тестирования.
Установили — забрали из каталога установки. Кажется, это вполне себе заявка.
#webkit #safari #windows
#баг дня
Не каждый день простое if-условие чинит угрозу приватности миллиарду людей.
https://github.com/WebKit/WebKit/commit/f73005ed826014988f8ee447de23927749fb56e5
Ошибка в WebKit-реализации IndexedDB позволяет отслеживать поведение пользователей между сайтами: https://fingerprintjs.com/blog/indexeddb-api-browser-vulnerability-safari-15/
#safari #webkit #privacy
Не каждый день простое if-условие чинит угрозу приватности миллиарду людей.
https://github.com/WebKit/WebKit/commit/f73005ed826014988f8ee447de23927749fb56e5
Ошибка в WebKit-реализации IndexedDB позволяет отслеживать поведение пользователей между сайтами: https://fingerprintjs.com/blog/indexeddb-api-browser-vulnerability-safari-15/
#safari #webkit #privacy
🔥3👍1
#статья дня
Думаете, браузеры только ругаться друг с другом умеют? Нет, они ещё и взаимодействуют.
Начиная с 2019 года множество компаний-разработчиков браузеров, ведомые инициативой Mozilla и Google, стали собираться на конференцию Interprop.
Этот год не стал исключением: https://web.dev/interop-2022/
Рассматриваются 15 тем взаимодействия и стандартизации (единого понимания документов):
- Каскадные слои
- Цветовые пространства
- Новые единицы измерения для viewport
- Скролл
- Subgrid
- CSS contain
- Элемент dialog
- Типографика
- Совместимость браузеров
- Правило aspect-ratio
- Flexbox
- Grid
- position: sticky
- Трансформации
В общем, будьте как разработчики браузеров :)
#webkit #firefox #blink #chrome #safari
Думаете, браузеры только ругаться друг с другом умеют? Нет, они ещё и взаимодействуют.
Начиная с 2019 года множество компаний-разработчиков браузеров, ведомые инициативой Mozilla и Google, стали собираться на конференцию Interprop.
Этот год не стал исключением: https://web.dev/interop-2022/
Рассматриваются 15 тем взаимодействия и стандартизации (единого понимания документов):
- Каскадные слои
- Цветовые пространства
- Новые единицы измерения для viewport
- Скролл
- Subgrid
- CSS contain
- Элемент dialog
- Типографика
- Совместимость браузеров
- Правило aspect-ratio
- Flexbox
- Grid
- position: sticky
- Трансформации
В общем, будьте как разработчики браузеров :)
#webkit #firefox #blink #chrome #safari
❤19
#статья дня
Вы не поверите, но, кажется, до Apple таки дошло, что Safari начинает всех бесить.
На самом деле, Safari надо любить, потому что Firefox стремительно загибается, но сложно любить то, что не очень-то и уважает потребности разработчиков.
Так вот!
Вышел Safari 15.4: https://webkit.org/blog/12445/new-webkit-features-in-safari-15-4/
В списке нововведений: lazy loading, dialog, :has(), каскадные слои, svh/lvh/dvh, focus-visible, accent-color, display: contents fix, scroll-behavior, Manifest-иконки, BroadcastChannel.
Выглядит охренительно, даже похоже на будущее.
Обновляемся, пользуемся.
Upd. держите перевод на русский https://habr.com/ru/news/t/655743/
#safari #webkit #macos
Вы не поверите, но, кажется, до Apple таки дошло, что Safari начинает всех бесить.
На самом деле, Safari надо любить, потому что Firefox стремительно загибается, но сложно любить то, что не очень-то и уважает потребности разработчиков.
Так вот!
Вышел Safari 15.4: https://webkit.org/blog/12445/new-webkit-features-in-safari-15-4/
В списке нововведений: lazy loading, dialog, :has(), каскадные слои, svh/lvh/dvh, focus-visible, accent-color, display: contents fix, scroll-behavior, Manifest-иконки, BroadcastChannel.
Выглядит охренительно, даже похоже на будущее.
Обновляемся, пользуемся.
Upd. держите перевод на русский https://habr.com/ru/news/t/655743/
#safari #webkit #macos
👍12🔥3
#фишка дня
Шоковый контент!
Вам, наверное, известно, что WebView — это когда в нативном приложении рендерится веб-приложение. И что такое точно есть в Android.
Я знал, что в Windows тоже применяется, знал, что в iOS вполне. Но не представлял, что даже официальные приложения Apple в macOS этим промышляют.
Если есть WebView-виджет, значит, есть и возможность его отладки?
Таки да! Следите за руками. Идём в терминал:
И вуаля — смотрим исходники того, что вам поставляет Apple и наслаждаемся.
Как по мне, весьма неожиданно. Поражает, насколько Apple поменяла свои правила интерфейсов, что даже встроенные web-части смотрятся настолько хорошо и нативно в контексте десктоп-приложения.
#macos #apple #webkit
Шоковый контент!
Вам, наверное, известно, что WebView — это когда в нативном приложении рендерится веб-приложение. И что такое точно есть в Android.
Я знал, что в Windows тоже применяется, знал, что в iOS вполне. Но не представлял, что даже официальные приложения Apple в macOS этим промышляют.
Если есть WebView-виджет, значит, есть и возможность его отладки?
Таки да! Следите за руками. Идём в терминал:
defaults write NSGlobalDomain WebKitDeveloperExtras -bool true
defaults write -g WebKitDeveloperExtras -bool YES
И вуаля — смотрим исходники того, что вам поставляет Apple и наслаждаемся.
Как по мне, весьма неожиданно. Поражает, насколько Apple поменяла свои правила интерфейсов, что даже встроенные web-части смотрятся настолько хорошо и нативно в контексте десктоп-приложения.
#macos #apple #webkit
🔥4👍3😁1
#видео дня
Вдогонку к посту про алгоритмы работы движка Flex-раскладки, позволю себе обнаглеть и приложить ещё и это видео: https://www.youtube.com/watch?v=RVnARGhhs9w
Называется буквально "How to render in WebKit".
Да, ему 10 лет, но 10 лет назад Flex уже был сформирован и даже прошли споры по первой версии Grid. Там определённо есть что почерпнуть.
На правах закладки, ага :)
#render #webkit
Вдогонку к посту про алгоритмы работы движка Flex-раскладки, позволю себе обнаглеть и приложить ещё и это видео: https://www.youtube.com/watch?v=RVnARGhhs9w
Называется буквально "How to render in WebKit".
Да, ему 10 лет, но 10 лет назад Flex уже был сформирован и даже прошли споры по первой версии Grid. Там определённо есть что почерпнуть.
На правах закладки, ага :)
#render #webkit
❤7
#видео дня
Все знают, что можно бесконечно наблюдать три вещи. И одна из них — как работает другой человек.
Все слышали: "В Blink добавили то-то, в WebKit добавили то-то, Firefox депрекейтнул то-то". О тяжёлой судьбе селектора :has слышали вообще чуть менее чем все.
Так как же происходит процесс этого самого добавления чего-либо? Кто и как пишет код в современных движках браузеров?
Какой тулинг используется, как выглядит код, как выглядят структуры данных, как проходят тесты? Вот было бы хорошо, если кто-нибудь провёл бы мастер-класс...
Ни слова больше! Кейт Сиркел как раз недавно этим занимался и выкатил видео про добавление селектора :has-slotted() в WebKit!
Вот: https://www.youtube.com/watch?v=vNuvEqs_TH4
А вдруг кто-то вдохновится и тоже станет контрибутором в какой-либо из движков? :)
#webkit #cpp #develop
Все знают, что можно бесконечно наблюдать три вещи. И одна из них — как работает другой человек.
Все слышали: "В Blink добавили то-то, в WebKit добавили то-то, Firefox депрекейтнул то-то". О тяжёлой судьбе селектора :has слышали вообще чуть менее чем все.
Так как же происходит процесс этого самого добавления чего-либо? Кто и как пишет код в современных движках браузеров?
Какой тулинг используется, как выглядит код, как выглядят структуры данных, как проходят тесты? Вот было бы хорошо, если кто-нибудь провёл бы мастер-класс...
Ни слова больше! Кейт Сиркел как раз недавно этим занимался и выкатил видео про добавление селектора :has-slotted() в WebKit!
Вот: https://www.youtube.com/watch?v=vNuvEqs_TH4
А вдруг кто-то вдохновится и тоже станет контрибутором в какой-либо из движков? :)
#webkit #cpp #develop
❤20👍7