Вы легко и небезосновательно сочтёте моё мнение о lossless WebP (к изложению которого я сейчас перехожу) гораздо болѣе благопріятнымъ, чѣмъ изложенное выше моё мнение о lossy WebP.

Большой удачею я считаю, что это мнение к тому же может оказаться и куда менѣе спорным: так как рѣчь пойдёт о формате, предназначенном для сжатия изображений, совершаемого без каких-либо потерь, то тут не потребуются никакие исследования, сравнивающие внѣшній видъ результатов съ тѣмъ видомъ, который обеспечивается конкурирующими форматами, тут ни к чему мýки выбора между различными вариантами подсчёта SSIM, дающими подчас противоположные оцѣнки результата (не свободные от вопросов о том, насколько та или иная метрика вида изображения соѿвѣтствуетъ или не соѿвѣтствуетъ человѣческому впечатленію), и тут нас не смутят указания на одномѣрность самогó показателя SSIM (который зачастую выдаёт сходные величины для таких искажений исходного изображения, которые человѣческое восприятие сочло бы качественно различающимися, примѣръ чего мнѣ приведён был на Nowere въ концѣ 2019 г.). Наоборот, наоборот! Рассматривая lossless WebP, мы можем навсегда сдѣлаться совершенно спокойными насчёт качества сохранения изображений в этом формате: качество-то всегда стопроцентное — и обращать наше внимание единственно на выигрыш в объёме файла, который выражается бесспорным количественным показателем (числом его байтов).

Дык что ж увидим? — оказывается, вышеупомянутый Jyrki Alakuijala превосходно сдѣлалъ свою работу, так что в качестве конкурента для PNG (то есть для единственного формата сжатия полноцвѣтныхъ изображений без потерь, сейчас поддерживаемого всѣми браузерами) формат lossless WebP годится очень хорошо: существует исследование Google, демонстрирующее способность формата lossless WebP обеспечивать сжатие содержимого большинства PNG-файлов (сжатие, оцѣниваемое ужé после переужатия этого содержимого лучшими из существующих средств для переужатия PNG, совершаемого без потерь) ещё на 20% или даже на 40% (а в среднем — где-то на четверть), а это значит, что в крупных файлах экономятся цѣлые мегабайты (то есть, для мобильных зрителей — полновѣсныя секунды их времени).

Я выделил слово «сейчас» жирностью, поскольку надеюсь, что (несмотря на всѣ коронавирусныя преграды) в нынешнем (2020) году мы всѣ дождёмся от Joint Photographic Experts Group нового формата JPEG XL, в котором также есть собственный режим для сжатия изображений, совершаемого без потерь, так что не один только PNG, но также и lossless JPEG XL составит для lossless WebP конкуренцию въ нѣкоторыхъ случаях. Въ нѣкоторыхъ, но не во всѣхъ: мнѣ удалось обнаружить такой частный случай, в котором lossless JPEG XL сжимает изображение менѣе сильно, чѣмъ даже PNG (а всё потому, что проектировщики JPEG XL решили нѣсколько пожертвовать экономиею объёма в пользу большего распараллеливания декодирования и в пользу большей простоты извлечения ѿдѣльныхъ фрагментов изображения, о чём и Jyrki Alakuijala повѣдываетъ) — а вот lossless WebP даже в этом же частном случае сжимает изображение болѣе чѣмъ на четверть сильнѣе, чѣмъ PNG.

Эта находка свидетельствует, и даже вполне неопровержимо, что и в том близком будущем, в котором JPEG XL объявится и начнёт поддерживаться интернетовскими браузерами, какие-то изображения будут лучше сжиматься без потерь посредством lossless JPEG XL, а какие-то другие — lossless WebP. (Справедливости ради надо сказать, что вышеупомянутое гугловское исследование упоминает об обнаружении и таких изображений, хотя и очень немногих, которые в PNG сжимаются без потерь лучше, нежели в lossless WebP; мнѣ-то самомý такие примѣры ещё не встречались, но я-то и интересоваться lossless WebP начал очень недавно, так что почему бы и не положиться на мнение Google по этому вопросу.)

Видя такие достоинства lossless WebP, хочется использовать его для сжатия всѣхъ такихъ полноцвѣтныхъ изображеній, которыя укладываются в границы его примѣнимости (16383×16383 пиксела и TrueColor), во всѣхъ тѣхъ случаях, когда этот формат и поддерживается, и реально обеспечивает превосходство над PNG (а в будущем — и над JPEG XL).

Выгода от употребления lossless WebP вмѣсто PNG иногда бывает больше, чѣмъ та (упомянутая предшествующим сообщением) разница объёмов, которая в исследовании Google найдена сравнением объёма lossless WebP с объёмом такого PNG, который до этого был сжат наилучшими средствами сжатия PNG без потерь. Ведь если файл PNG больше мегабайта, то его сáмой сжатой версии хочется предпочесть ту, которая сдѣлана чересстрочною по алгоритму Adam7: пусть объём файла возрастёт, но зрители со слабыми каналами связи (по которым мегабайт приходит дольше секунды) увидят полноразмѣрную (хотя размытую) версию изображения поскорѣе (для чего тогда достаточно ≈1½% файла). Примѣръ: скриншот страницы вон того фото (1440×2232 пиксела на экране QHD) занимает 1252595 байтов PNG (см. файл original.png в прилагаемом архиве), но его чересстрочная форма (файл interlaced.png) занимает ужé 1828148 байтов. А в lossless WebP изображение займёт 863158 байтов (файл lossless.webp) — это меньше мегабайта, позволяя мириться с отсутствием чересстрочности.

Формат animated WebP используется для хранения анимаций, каждый кадр которых хранится в одном из вышеописанных форматов, то есть либо в формате lossy WebP, либо в формате lossless WebP, причём форматы разных кадров могут быть разными.

Анимированный lossless WebP является конкурентом для прежних форматов сжатия анимированных изображений, совершаемого без потерь: конкурентом и для анимированных GIF, и для анимированных PNG — и анимированный lossless WebP одерживает побѣду над ними благодаря болѣе высокой степени сжатия.

Так, напримѣръ, около шести лѣтъ тому назад, когда анимированные изображения снова начали входить в моду (но на новом техническом уровне начала десятых лѣтъ: не как небольшие и простенькие GIFки девяностых годов, а как отрывки видео многосотпиксельной ширины и болѣе чѣмъ мегабайтового объёма), во блоге Cloudinary появилась рекомендация выкладывать такие анимации в формате animated WebP (в качестве альтернативы для браузеров, понимающих WebP), причём не только для сокращения объёма файлов (то есть во избежание чрезмѣрныхъ расходов траффика), но и для преодоления ограничений 256-цвѣтной палитры, почти неизбѣжныхъ для GIF. (Я пишу «почти», так как gifski позволяет создавать болѣе цвѣтные кадры GIFов наложением нѣсколькихъ менѣе цвѣтныхъ кадров, хотя это и приводит к дальнейшему росту объёма.) То и другое достоинство остаётся злободневным до сих пор, обуславливая пользу от перехода на анимированные lossless WebP с прежних гифок или с APNG.

Тут надо сразу же сказать, однако же, что Cloudinary предпочитает (для ещё большей экономии объёма файлов) рекомендовать использование анимированных lossy WebP. Но сейчас, через ≈шесть лѣтъ после этой рекомендации, я могу отнестись к этому мнению Cloudinary скептически и указать вот на какое обстоятельство: так как формат анимированных изображений lossy WebP основан на формате ключевых кадров видеопотока VP8, то этот формат (в качестве средства для хранения анимаций со сжатием, сопровождающимся внесением потерь) с неизбѣжностью уступает (по соотношению объёма и качества) даже видеозаписям VP8, потому что во всякой видеозаписи, кроме ключевых кадров, также используются промежуточные, сжатые ещё сильнѣе ключевых. Слѣдовательно, если на мѣстѣ анимированного lossy WebP поставить видеофайл WebM (с видеопотоком VP8 или, тѣмъ болѣе, VP9) или видеофайл MP4 (с видеопотоком HEVC или, тѣмъ болѣе, AV1), то можно при том же объёме получить большѣе качество, а также важную дополнительную возможность использования звуковой дорожки. Придётся побеспокоиться разве что о том, что изо всѣхъ этих четырёх видеопотоков в системе iOS (то есть на айфонах и на айпэдах) браузером Safari поддерживается только HEVC, зато HEVC не поддерживается в большинстве других браузеров (и на то есть причина — угрожающая неясностью ситуация в сфере патентных отчислений за использование HEVC). Но об этом-то приходится побеспокоиться и насчёт формата WebP, тоже не поддерживаемого в Safari.

Появление видеозаписей, однако, не вполнѣ покончило с причинами использовать анимированные lossy WebP. В гугловском FAQ достоинством анимированных WebP зовут продолжение их недостатка: анимация, не содержащая промежуточных кадров, тѣмъ самым требует меньше оперативной памяти и меньше усилий процессора, так что появление нѣсколькихъ таких анимаций на одной интернетовской странице не создаст больших проблем даже для такого маломощного пользовательского устройства, которое стало бы бѣшено греться и подлагивать, если б столкнулось съ нѣсколькими полноцѣнными видеозаписями на одной странице. Но так как возможности устройств растут, то значимость этого достоинства отходит в прошлое. Ещё можно замѣтить, что пока анимация остаётся иллюстрацией (а не видеозаписью), её проще подмѣнить (для браузеров, не поддерживающих WebP) на иллюстрацию другого формата (на APNG, на анимированный GIF, а для Safari — и на видео MP4 в теге img) — подмѣнить на стороне сервера (как это дѣлаетъ Cloudinary), или на странице тегом picture (если есть, скажем, готовый APNG-аналог WebP-файла), или подпереть джаваскриптовым костылём (наподобие WebPJS или libwebpjs).

Итак, lossy WebP — это конкурент JPEG, достигший лишь спорного успѣха, так что в нынешнем году его ждут пышные похороны после появления AVIF (и затѣмъ ещё после появления JPEG XL, если оно состоится), причём до этого осталось недолго: поддержка AVIF ужé ждёт своего часа в недрах Chromium с 8 апреля, так что вскоре должна объявиться и в Google Chrome, и в Microsoft Edge, и в Opera, и во всѣхъ других браузерах, на основе Chromium созданных.

Чуть лучше чувствует себя animated WebP: это превосходная замѣна для прежних анимированных GIFов и для APNG, но сам обычай употребления файлов, хранящих зацикленные и беззвучные анимации, постепенно уступает мѣсто как видеозаписям (въ томъ числѣ — видеозаписям со звуком), так и CSS-анимациям (плавным измѣненіямъ свойств элементов страниц).

И, наконец, lossless WebP представляет собою величайший нынешний идеал сжатия полноцвѣтныхъ изображений, превосходящий PNG во всём, кроме поддержки чересстрочности и выхода за предѣлы TrueColor, а также готовый поспорить с грядущими lossless JPEG XL, по крайней мѣрѣ, в частных случаях.

Вышеупомянутая психологическая уловка Google (объединение этих трёх форматов под одним названием WebP), казалось бы, за счёт непререкаемой привлекательности lossless WebP могла бы побуждать к поддержке всего WebP (то есть и двух остальных вариантов WebP, не так хорошо выдержавших испытание временем), но действительность ужаснее этого.

Ужасно положение пользователей iOS, подтверждающее тезис «Safari is the new IE» (и даже в превосходной степени: Корпорация Microsoft хотя бы допускала на Windows конкурентов IE, тогда как Apple отстаивает единственность движка Safari в системе iOS) многолетним отсутствием поддержки WebP. Это отсутствие тѣмъ болѣе удивительно, что в 2016 году компания Apple тестировала возможность поддержки WebP в бета-версиях своего браузера (в том числе и на iOS 10), но затѣмъ отказалась от поддержки WebP, никак свой отказ не объяснив.

Ужасно положение пользователей Файерфокса, которые изначально привлечены были изобилием расширений, предшествующих появлению Firefox Quantum, и поэтому во множестве остаются вѣрными доQuantumной версии браузера, не способной показывать WebP.

Для браузеров, не поддерживающих WebP, можно прилагать копию изображения в альтернативном формате в теге picture (это, напримѣръ, рекомендует Joshua Comeau), но этот обходной путь, понятное дѣло, не годится для тѣхъ сайтов, которые стремятся к экономии не одного только траффика, но также и объёма хранимых файлов — так бывает, напримѣръ, на имиджбордах, гдѣ обычно хранится превеликое множество файлов, но жёстко ограничен объём каждого файла, так что именно на имиджбордах пользователи могли бы счесть удачею возможность уйти от PNG к lossless WebP. Болѣе естественным в этом случае представляется джаваскриптовый декодировщик WebP, дѣйствующій во браузере (что-то наподобие WebPJS или libwebpjs), причём такой декодировщик пользователи могли б даже ставить себѣ сами как юзерскрипт (мнѣ попадался и примѣръ именно такого юзерскрипта, подключающего WebPJS на нѣкоторомъ сайтѣ) — в этом послѣднемъ случае администрации на имиджборде достаточно прибавить WebP в список допустимых форматов, а больше делать вообще ничего не надо.

Руководимый этим представлением, я пошёл на Nowere и 6 апреля рекомендовал там запустить поддержку формата WebP, приводя аргументы в его пользу (подобные тѣмъ аргументам, которые я только что изложил в Telegram — но только не настолько подробные), но с тѣхъ пор не получил там никакого ѿвѣта.

Руководимый этим же представлением, я также пошёл ещё и на 410чанъ, 6 апреля рекомендовал там запустить поддержку формата WebP, приводя аргументы в его пользу (подобные изложенным на Nowere аргументам), но ѿвѣтомъ мнѣ был отказ, изложенный в форме «когда Apple добавит поддержку, тогда приходите» (а это de facto означает «никогда»).

Тут, конечно же, не одна компания Apple виновата, но и личное нежелание имиджбордовских хозяев грокнуть и использовать формат файлов, обладающий очевидными достоинствами и притом давнишний (предложен он был в сентябре 2010 года, скоро будет десять лѣтъ).

Имиджборды, названные в предшествующем сообщении, не были первыми проскочившими от анимированных GIF сразу к видео: законодателем мод для них, как и во многих других имиджбордовских обычаях, приходится признать 4chan, примѣрно 7 апреля 2014 года начавший поддерживать WebM, но никогда, насколько я понимаю, не помышлявший о поддержке WebP. (Я пишу «примѣрно», потому что сам 4chan сейчас указывает эту дату под блогозаписью словами «6 years ago», не упоминая конкретный день. Но так как «The Washington Post» в статье «Meet the technology that could make GIFs obsolete» упоминает о новинке как о появившейся в понедельник, а статья его датируется восьмым апреля 2014 года, то догадываться нетрудно.)

Через два мѣсяца с небольшим (18 июня 2014 года) поддержка анимаций появилась в Твиттере, причём изначально о ней было объявлено словами «можете загружать и просматривать анимированные GIF», но при пристальном вглядывании пользователям вскоре сдѣлалось ясным (как, напримѣръ, было сказано вон в той статье на сайте Mashable через два дня), что всѣ загруженные GIFы на самомъ дѣлѣ преобразовывались в видеозаписи MP4. А вот поддерживать WebP, по-видимому, Twitter не очень склонен: тѣ самыя правила на его сайте, которые объявляют о возможности опубликовать PNG «как есть» (без серверного переужатия) при определённых обстоятельствах (например, для малобитных или малопиксельных изображений, или для растущих в объёме при преобразовании в JPEG) и о возможности опубликовать JPEG «как есть» при сочетании определённых признаков (малый размѣръ, малый объём, неповёрнутость, достаточная степень сжатия) — тѣ же правила объявляют, что загруженные WebP в любом случае будут преобразованы в формат JPEG с качеством 85%. Это не радует, во-первых, потому, что lossless WebP не хуже PNG может распухнуть в объёме при преобразовании в JPEG, а во-вторых, потому, что animated WebP теряет, разумѣется, всю свою анимацию при таком преобразовании. Тут надо прибавить (и прибавляю), что animated WebP — не единственный такой формат анимации, который не укладывается на прокрустово ложе «анимированные GIF с преобразованием в MP4» и с которым за это Twitter решил побороться и побѣдить. Менѣе полугода назад (в конце декабря 2019 года) пользователи Твиттера были огорчены тѣмъ, что обнаруженная недѣлей ранѣе возможность публиковать анимированные PNG была у них отобрана Твиттером; и даже болѣе того: при этом Yahoo широко опубликовал слухи (позже поместив в постскриптум опровержение их), согласно которым злоумышленники воспользовались этой новой возможностью использовать анимации (не отключаемые через интерфейс Твиттера, в отличие от отключаемых MP4) для того, чтобы преступно атаковать эпилептиков, вызывая приступ. Но напрашивается вот какой вопрос: а для чего людям вообще понадобилось прибѣгнуть к анимированным PNG, если у них до этого была возможность загружать анимированные GIF в Твиттер? — уж конечно, они были недовольны либо результатами преобразования в MP4 (происходящего с внесением потерь, тогда как анимированные PNG сохраняют каждый кадр без потерь), либо недостаточною цвѣтностью анимированных GIFов: кадры анимированных PNG полноцвѣтны, тогда как каждый кадр анимированного GIF ограничивается 256-цвѣтною палитрою, а если для преодоления этого недостатка использовать пространственное и временнóе раздѣленіе нѣсколькихъ малоцвѣтныхъ кадров (какъ дѣлаетъ gifski), то нѣкоторые пикселы будут бѣшено моргать (сильнѣе, чѣмъ на дешёвых TN-дисплеях, также использующих временнóе раздѣленіе соседствующих цвѣтовъ для передачи промежуточных), да и упереться в официальные твиттеровские ограничения GIF (не больше 350 кадров, не больше 15 мегабайтов) будет очень просто. Возможно, этот же вопрос задали себѣ и в Твиттере, и тогда пользователям было обѣщано, что анимированные PNG, загруженные до отключения возможности такой загрузки, останутся — и даже что в будущем рассмотрен будет вопрос об обустройстве подобной возможности, но лучше и безопаснее (а значит, с предусмотренным отключением их для эпилептиков). Но вот ужé и апрель, а новых анимированных PNG (и тѣмъ болѣе WebP) нѣтъ в Твиттере.

Приведённый в предшествующем сообщении список сайтов, в 2014 году перешедших от поддержки анимированных GIF к поддержке видеоформатов, не стал бы полным без упоминания о том, что и сайт imgur (в октябре того же 2014 года) объявил о запуске нового формата GIFV, суть которого состояла (да и по сей день состоит) в конвертировании присланных его посетителями анимированных GIF на стороне сервера в видеозаписи одновременно двух форматов: WebM и MP4 — чтобы в дальнейшем каждому зрителю доставался тот формат, который поддерживается его браузером. Зато их страница загрузки файлов и доныне (через 5½ лѣтъ) не поддерживает загрузку файлов WebP (причём не только анимированных, но и простых), да ещё и никак не предупреждает посетителя об этом. Если только скинуть туда файл WebP (да ещё потратить время на ожидание окончания загрузки его на imgur), то тогда можно ещё дождаться сообщения об ошибке.

Казалось бы, этим состоявшимся в 2014 году переходом (с GIF-анимаций на видео, но не на WebP) двигала нѣкая логика: видеоформатное сжатие кадров и современнее, и происходит с потерями, так что должно порождать меньший объём файла. И так бы оно всегда и получалось, но только если бы в animated WebP всегда содержалось сжатие кадров способом lossy WebP, которое требует меньше усилий процессора и меньше оперативной памяти, но и слабѣе сжимает, чѣмъ современные видеоформаты. А между тѣмъ в animated WebP может использоваться и сжатие способом lossless WebP, использующее цѣлый ряд таких приёмов, которые в видеоформатах не применяются, зато по отношению к простым GIFкам (в которых несложные контуры, немногие цвѣта, отсутствуют плавные цвѣтовые переходы) дают превосходные результаты: и потери не вносятся в изображение при сжатии, и результат получается меньше по объёму файла, чѣмъ видео разумного качества (тут понятно, что можно и в видеофайл внести такие значительные потери, что он получится ещё меньше, но результат никого не обрадует). Один примѣръ именно такого частного случая приводится в хвосте гугловского FAQ об animated WebP: есть GIFка с пританцовывающим бананом, занимающая 86978 байтов, и преобразование её в видеоформат WebM порождает файл объёмом 32290 байтов, что очень хорошо, поскольку сжатие болѣе чѣмъ в два раза позволяет (по примѣру imgur) сохранять эту анимацию вмѣсто GIF в двух разных видеоформатах (и при этом всё же явно выиграть не только в объёме раздаваемого траффика, а ещё и в объёме хранимых файлов), однако же если вмѣсто WebM использовать анимированный lossless WebP, то тогда файл с результатом окажется ещё в 6½ раз меньше — 4764 байта. Болѣе того: так как FAQ тот — давнишний, то всѣ вы можете улучшить тогдашний результат Google ещё почти на треть, просто скачав новѣйшую версию (1.0.3) их программы gif2webp (как часть libwebp) и запустив команду «gif2webp dancing-banana.gif» самостоятельно — получится файл объёмом 3632 байта, в ≈24 раза меньше исходного GIF. Всё это означает, и даже вполне наглядно, что въ нѣкоторыхъ частных случаях анимированные lossless WebP не только благодаря отсутствию потерь, но и благодаря объёму файла недосягаемо превосходят результаты преобразования анимированных GIF в видеофайлы, так что давнее (с 2014 года) пренебрежение форматом WebP (и безусловное предпочтение ему видеоформатов, не всегда его превосходящих), проявленное множеством сайтов: и на имиджбордах, и в Твиттере, и у imgur — это печально.

В январе 2016 года в книге именно таких печалей появилась ещё одна, причём совершенно особенная, страница: Telegram во блогозаписи «GIF Revolution» объявил, что для любителей анимированных GIFов настало время возрадоваться, так как впредь такие GIFы будут Телеграмом перекодироваться в MP4, что означает экономию до 95% объёма и оттого возможность передавать и получать анимацию до 20 раз быстрее. Можно ли прибавить, что Telegram при этом повёл себя будто Twitter и отказался от употребления изображений в формате WebP? — нѣтъ, этого прибавить нельзя; но для WebP была уготована не многим лучшая участь, чѣмъ полнѣйшій отказ от поддержки: формат WebP в Telegram был загнан в своего рода загон, в своего рода гетто.

Драма, нѣсколькими словами очерченная въ послѣднемъ абзаце предшествующего сообщения, началась ещё в январе 2015 года, когда во блогозаписи «Stickers Done Right» пользователей Телеграма обрадовали извѣстіемъ о появлении поддержки стикеров. Так как тогда в первом из стикерпаков стикеров было не очень много (меньше полутора десятков!), то пользователям предложено было создавать свои собственные стикеры в качестве частично прозрачных изображений и сохранять их в WebP, а каждый клиент Telegram (такой, как Telegram Desktop, напримѣръ) с этого дня начал отображать любой файл WebP, скинутый в чат, в качестве стикера. Во блогозаписи восхвалялася способность WebP хорошо сжимать частично прозрачные изображения — способность, благодаря которой Telegram сдѣлался способным отображать стикеры впятеро быстрее, чѣмъ во прочих мессенджерах. Мѣсяца через четыре (в мае того же 2015 года) не только свои стикеры, но и свои наборы стикеров стало можно создавать, отправляя боту @stickers частично прозрачные изображения в формате PNG, помѣщающиеся в квадрат 512×512 пикселов вплотную (то есть одна из сторон прямоугольника прозрачного холста такого изображения должна быть равною 512px, а вторая — равна или меньше).

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

Если в Telegram Desktop нажать на скрепку и выбрать графический файл для вбрасывания его в чат, то появляется переключатель с позициями «Send as a photo» и «Send as a file». Что помѣшало прибавить к нему ещё третью позицию «Send as a sticker» для всѣхъ графических файлов (или только для WebP), а не создавать тождество сущностей «WebP» и «стикер»?

Если разработчики Telegram обнаружили (и похвалили!) высокую эффективность сжатия WebP, то что могло заставить их ограничиться её использованием только для стикеров? Почему нельзя хранить в этом формате и многое другое для экономии объёма и для ускорения передачи и приёма? Разве нѣтъ таких изображений, которые можно было бы конвертировать при отправке не в JPEG с потерями, а в lossless WebP без потерь, причём попробовать при отправке оба формата и выбросить JPEG, если файл lossless WebP меньше его, и тѣмъ достигнуть экономии по объёму, а не одной только безупречности внѣшняго вида нѣкоторыхъ изображений? (Подозреваю, что изрядная часть канала @PixeLove могла бы и обойтись без проJPEGовывания, и приходить к подписчикам побыстрее.) А разве нѣтъ таких GIF-анимаций, которые можно было бы конвертировать при отправке не в MP4 с потерями (и начать это с 2016 г.), а в анимированный lossless WebP без потерь (и начать это с 2015 г.), и притом с большей экономией по объёму? (Вряд ли вышеупомянутый примѣръ из хвоста гугловского FAQ о WebP единственен.)

А что там с использованием WebP не как внутрителеграмного хранилища, а как первоисточника изображения (пускай затѣмъ и преобразуемого в JPEG или MP4 при отправке)? Как можно восхвалять формат WebP за его степень сжатия изображений, но не готовиться к тому, что люди в так называемом реальномъ мірѣ (за предѣлами Телеграма) также пользуются этим форматом (восхваляя его также и за то же) и оттого они начнут рано или поздно притаскивать и в Telegram используемые ими изображения в файлах WebP — да такие, при создании которых никто и не мыслил об этих изображениях как о стикерах для Телеграма? Почему на эти файлы нельзя воздѣйствовать переключателем с позициями «Send as a photo» и «Send as a file»? Если во блогозаписи «Stickers Done Right» от стикера требуется прозрачность, то почему непрозрачные изображения из файлов WebP также стикеризуются? Если бот @stickers требует от стикера соѿвѣтствіе опредѣлённымъ размѣрам, то почему изображения из файлов WebP других размѣровъ также стикеризуются? Наконец, если анимированными стикерами работают не анимированные WebP, а экспортированные векторные изображения из Adobe After Effects, то почему из содержимого файлов animated WebP вырѣзается первый кадр анимации и также стикеризуется?

После ряда экспериментов можно догадываться, что и разработчики в Telegram также набрели на нѣкоторые из только что заданных мною вопросов (разумѣется, набрели даже раньше, чѣмъ я успѣлъ задать их) — и, задавшись ими, пришли к выводу о том, что придавать вид стикеров достаточно крупным файлам WebP не слѣдуетъ: методом тыка можно обнаружить, что достаточно крупные файлы WebP всё-таки отображаются почти «как файл» и в Telegram под Android, и в Telegram Desktop под Windows.

Я пишу «почти», потому что всякий другой файл, отправляемый «как файл», можно снабдить текстовою подписью до его отправки (а если выбрать в контекстном меню пункт редактирования, то и после отправки), однако же этакие достаточно крупные файлы WebP снабдить текстовою подписью никоим образом нельзя.

А ещё я неопредѣлённо пишу «достаточно крупные», поскольку это понятие, по-видимому, не было чётко опредѣлено и одинаково реализовано разработчиками. Можно обнаружить (и я обнаружил) такой файл WebP, который в Telegram Desktop под Windows будет выглядеть почти «как файл», однако в Telegram под Android будет показан как стикер. Болѣе того: это понятие, по-видимому, не привязано къ размѣру файла, так как можно обнаружить (и я обнаружил) два таких файла WebP одинаковаго размѣра (1920×2668 пикселов), из которых один файл (большего объёма, потому что lossless WebP) будет показан в Telegram под Android почти «как файл», а другой файл (меньшего объёма, потому что lossy WebP) в Telegram под Android будет показан как стикер.

То и другое и третье я считаю багом, о чём и сообщил в @BugReports, приложив всѣ обнаруженные примѣры.

Но иррациональность ситуации вокруг WebP в Telegram не исчерпывается вышеизложенными вопросами: можно задавать и другие.

Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому надо отправить WebP не как стикер, а как иллюстрацию или как файл? Зачѣмъ принуждать пользователя к преобразованию изображения из одного формата в другой при посредстве сторонней программы или чужого сайта, если сам Telegram, когда рѣчь идёт не о WebP, невозбранно способен прочитать изображение из PNG и пересохранить в JPEG? Мы же знаем, что и из WebP он также умѣетъ читать.

А какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому пришёл одиночный стикер (в формате WebP) и которому стикер настолько понравился, что пользователь захотел прибавить его къ нѣкоторому стикерпаку, но бот @stickers принимает только PNG и с болѣе жёсткими требованиями къ размѣру? Почему бот @stickers не принимает готовые WebP даже в том случае, когда они подходят по размѣру? (Если разработчики бота @stickers создают стикерпаки только в формате lossy WebP и притом опасаются накопления ошибок сжатия от послѣдовательных пересохранений из lossy WebP в lossy WebP, то можно же хотя бы lossless WebP принимать? Если были дополнительные опасения насчёт того, что начнут тогда из lossy WebP в lossless WebP перегонять для обхода ограничения, то тогда что мѣшаетъ сейчас из lossy WebP в PNG перегонять для обхода ограничения?)

Почему стикеры могут содержать прозрачные области, а обыкновенные иллюстрации — не могут? Нельзя ли частично прозрачные изображения обнаруживать и перегонять не в формат JPEG (вообще не поддерживающий прозрачность), а в формат WebP (дѣлая автоматический выбор в пользу lossy WebP или lossless WebP по объёму файла)?

Если анимированные GIF объёмом до 10 мегабайтов преобразуются в MP4 (для экономии объёма и траффика), а больше 10 мегабайтов не преобразуются (чтобы преобразовальник не надорвался), но всё же показываются анимированными, то нельзя ли то же самое дѣлать и с анимированными WebP, и с анимированными PNG? Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому нужно отослать анимированный WebP или анимированный PNG? Можно ли надеяться, что пользователь возьмёт в руки FFmpeg и самостоятельно создаст MP4 с потерей качества, если этакий-то пользователь может взять в руки и gifski, тѣмъ болѣе что объём получающегося GIF в Telegram ограничен аж 1½ гигабайтами?

Закончив задавать перечисленные выше вопросы, остаётся только накрыть лицо рукою, не в силах с ужасом вглядываться в грядущее. Если про Twitter и про imgur и про Telegram можно сказать, что они воздерживаются от настоящей поддержки формата WebP (который появился в 2010 году) и поддержки анимированных PNG (браузерная поддержка которых началась в 2007 году), то тогда откуда же взять нам столько терпения, чтоб хватило аж до того ≈2030 года (если не далѣе), в котором эти сайты такими темпами наконец сподобятся по-настоящему поддержать всѣ тѣ новѣйшіе форматы, которые явились или ещё явятся в сáмое ближайшее время, изобилуя достоинствами?

Выше я упоминал, напримѣръ, что поддержка графического формата AVIF приуготавливается в движке Chromium — но и Фонд Мозиллы не отстаёт, так что и поддержка в Файерфоксе также приуготавливается. Получается, что без AVIF останется та же доля пользователей, что и без WebP: и поклонники старого Internet Explorer (а не нового Microsoft Edge), и пользователи iOS, и ненавистники Firefox Quantum — так не станут ли зажимать его точно так же, как WebP сейчас? Будут ли в Twitter и в Telegram перегоняться иллюстрации из AVIF в JPEG, будет ли анимированный AVIF преобразовываться в MP4 или обрѣзаться до первого кадра с последующим JPEGованием, будет ли imgur проглатывать AVIF и выплёвывать ошибку? Или всё же примѣръ компании Netflix, пришедшей к употреблению AVIF вмѣсто JPEG, кого-нибудь чему-нибудь научит?

А как выглядит будущность того видеоформата AV1 (на формате ключевых кадров из которого основывается AVIF) — видеоформата, который прямо сейчас поддерживается тѣмъ же крýгом браузеров (Chromium да Firefox) всюду, кроме мобильных устройств, ещё не доросших до необходимой вычислительной мощности или специальной аппаратной поддержки? Будет ли AV1 радовать наше зрѣніе итогами примѣненія фильтра CDEF, предотвращающаго эффект «замыливания» чётких контуров в кадре, или AV1 ожидают долгие годы преобразования в AVC на стороне сервера или вообще отбрасывания за непонятность?

Значительно ли количество тѣхъ разработчиков движков фотохостинговых, или имиджбордовых, или микроблогосферических, или мессенджеровых, которые прямо сейчас с надеждою вглядываются в открытый исходный код будущей эталонной реализации формата JPEG XL и ждут от неё хотя бы той экономии пространства и траффика, которую обѣщаетъ обратимое преобразование из JPEG в JPEG XL без потерь? А когда менеджмент компании Netflix принимал решение о переходе на AVIF, там хоть кто-нибудь оговорился «ну это только на ближайший год, а там уж и JPEG XL подоспѣетъ»?

А не видно ли на горизонте цѣлое восходящее созвѣздіе новых видеоформатов? Во-первых, от Joint Video Experts Team к концу нынешнего (2020) года ждут видеостандарт VVC (он же, насколько я понимаю, MPEG-I Part 3), предназначенный стать слѣдующим шагом на том пути развития, на котором AVC и затѣмъ HEVC были предшествующими шагами. Во-вторых, шаг HEVC решили, так сказать, правильно переповторить: в феврале на сайте Bitmovin и в марте у Diego Gibellino можно было прочесть, что опять же к концу нынешнего (2020) года ожидается появление стандарта EVC (он же, насколько я понимаю, MPEG-5 Part 1), в котором базовый профиль будет свободным от лицензионных отчислений (а всё же сжимать кадры до 30% лучше, чѣмъ въ AVC при равном качестве), а поверх него будут работать коммерческие дополнения (способные на ¼ превзойти даже HEVC 10 Main), задуманныя какъ отключаемыя, но для заманухи называемыя «основным профилем» (main profile). В-третьих, постепенно обретает форму (уж не знаю, насколько это сейчас официально) задумка LCEVC (MPEG-5 Part 2) с двумя слоями корректирующих поправок, позволяющими хранить основную видеозапись в половинном разрешении (скажем, HD вмѣсто QHD — или, скажем, FullHD вмѣсто 4K) для экономии объёма файла (а значит, и траффика) и вычислительной мощности, но всё же обретать чёткость кадра после наложения корректирующих поправок.

Если ещё даже поддержку WebM в Twitter и в Telegram не завезли, то долго ли дожидаться, къ примѣру, EVC baseline? — посѣдѣть можно будет гораздо раньше, чѣмъ дождаться.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

Прочитав на канале «Джига на могиле» (@jiganamogile) вчерашние слова осуждения насчёт новой функции в Telegram, обеспечивающей возможность редактирования сколь угодно старых сообщений на каналах, я счёл нужным удѣлить десяток минут собственному рассуждению о том, какую пользу принесёт нам эта новинка, как с её появлением каналы в Telegram способны принять нѣсколько менѣе блогосферический и болѣе вики-подобный облик (с дописками, с поправками, с постскриптумами, с перекрёстными ссылками, с продолжительным пополнением оглавлений), какую дополнительную пользу поэтому могли бы принести разработчики Telegram, кабы предусмотрели историю правок (как в вики или как на Гитхабе) и притом ещё обеспечили дополнительное пространство для дописок, нарастив предѣльный объём сообщений во много раз (или хотя бы вдвое, как в Твиттере, позволив использовать вдвое больше таких символов, код которых в таблице Unicode не превосходит U+07FF и оттого в кодировке UTF-8 укладывается в двухбайтовом пространстве вмѣсто четырёхбайтового).

Приведённое выше десятиминутное рассуждение я сперва выложил в чате @tginfochat, но теперь оно будет и у меня на канале, и на канале @jiganamogile также доставлено.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

Он содержит, в частности, ретвиты сравнений пельменей с костюмами Met Gala.

🐦 Опубликован очередной сборник моих твиттеровских микроблогозаписей.

28 апреля появилась новая, долго готовившаяся, версия реализации P2P-распределённой файловой системы IPFS на языке Go — версия 0.5.0, содержащая множество улучшений (в частности, ускоренную работу DHT), множество полезных новинок (в частности, раздачу ѿдѣльныхъ доменных имён ѿдѣльнымъ CID при гейтовании).

Без значительного промедления (ужé на слѣдующій день — 29 апреля) я установил себѣ эту версию — и только тогда обнаружил: единственным, что работало, был демон файловой системы. Расширение IPFS Companion, установленное во браузере, не могло соединиться с демоном даже для того, чтобы показать количество соединений P2P. Также и web-интерфейс демона сообщал о невозможности соединиться с ним.

Обвинять в этой неработоспособности саму реализацию файловой системы я, однако же, никак не мог. Возникшая передо мною драма превозмогания имѣла другую причину: измѣненія, внесённыя в код web-интерфейса и расширения для соѿвѣтствія новинкам реализации IPFS, совершались на достаточно новой версии языка JavaScript, и оттого ужé не поддерживались используемым мною web-браузером.

Постоянные читатели моего блога ужé видѣли, что за нѣсколько послѣднихъ лѣтъ я нѣсколько раз упоминал о печальной судьбе тѣхъ пользователей браузера Mozilla Firefox, которые первоначально были привлечены к его использованию тѣмъ, что именно в Файерфоксе (впервые в истории браузеростроения) появилось множество API (программных интерфейсов), позволявших сторонним программистам создавать дополнения и расширения функциональных возможностей браузера. Много лѣтъ пользователи могли почти неограниченно наслаждаться или даже повседневной жизни своей не мыслить без тѣхъ возможностей, которыми обогащали Firefox эти дополнения: совершалось блокирование надоедливых рекламных блоков и призывов к регистрации, работали встроенные во браузер IRC-чатники и СУБД, перестанавливались и перестраивались и перекрашивались панели управления (и обвѣшивались дополнительными кнопками и индикаторами), реорганизовывались скачиваемые файлы, выяснялись цвѣта и метаданные изображений, появлялись удобные возможности поиска по словарям и по изображениям, дополнялось оформление и поведение нѣкоторыхъ сайтов. Но изрядная часть этих возможностей погибла, когда в августе 2017 года был объявлен, а затѣмъ в ноябре 2017 года (с выходом версии Firefox 57 под кодовым именем «Quantum») был реализован полный отказ от прежних API в пользу нового стандарта WebExtensions — стандарта болѣе безопасного, болѣе подходящего под новый многопоточный движок браузера, а также (это важно!) куда болѣе похожего на используемый в популярном браузере Google Chrome (а значит, изрядно уменьшившего усилия авторов, сочиняющих свои расширения для Chrome и для Firefox одновременно), однако обладающего меньшими возможностями API, так что ожидаемое поведение и даже само существование многих предшествующих расширений сдѣлалось технически невозможным.

Ужé к августу 2018 года накопилось достаточно статистики для того, чтобы я утверждал в Фидонете, что Firefox этим шагом самоубился (доля его пользователей прекратила расти, хотя предшествующие четыре месяца она росла). А в нынешнем апреле я измѣрялъ количество пользователей Файерфокса, до сих пор не получивших поддержку формата WebP (слѣдовательно, использующих Firefox 64 или болѣе ранний), и выложил в Твиттере результат: таких пользователей — примѣрно одна седьмая (а в России ещё больше — примѣрно одна пятая). То есть и отток пользователей (в том числе — потенциальных) произошёл, и проявилась склонность пользователей оставаться на старых доQuantumных версиях Файерфокса.

Не думайте, что всё это время я упоминал всё это из бескорыстной сострадательности къ сотням тысяч пользователей прежних расширений, которые были ущемлены из-за выхода Firefox Quantum! — нѣтъ, я и сам принадлежал к их числу, с 2017 года оставался вѣренъ болѣе ранней версии Файерфокса и терпел невозможность открывать ею графические файлы в формате WebP (поддержка которого появилась в Firefox 65) или видео AV1 (их поддержку ≈нормально добавили только в Firefox 67).

А вот ради IPFS я не утерпел — перешёл на Firefox 75.

Упомянутый в предшествующем сообщении переход к использованию браузера Firefox 75 оказался для меня менѣе неприятным, чѣмъ если бы я сразу перешёл в ноябре 2017 года на Firefox 57. Тогда, ≈2½ года тому назад, я был бы вынужден опираться на повседневное использование только таких расширений Файерфокса, которые смогли сохраниться с переходом на новые API: Adblock Plus, ColorZilla, HTTPS Everywhere, Image Search Options, IPFS Companion, Nuke Anything, Show fixed Go, Violentmonkey, Web Developer — но одних их мнѣ, конечно, недоставало бы. Однако к 2020 году с течением времени появились замѣнители многих оставленных в 2017 году расширений.

Напримѣръ, явилось расширение Copy Link Text на основе API WebExtensions, способное замѣнить аналогичное прежнее расширение — единственное различие состоит в том, что добавляемые новыми расширениями пункты контекстного меню всегда располагаются ближе к хвосту, а прямо под встроенным пунктом «Copy Link Location» такому новому пункту не быть. Явился и нѣсколько болѣе навороченный аналог — Link Text and Location Copier.

Ещё примѣръ: явилось расширение Foxy Gestures на замѣну прежнему расширению FireGestures для поддержки управления жестами, мышóю совершаемыми. Новые API налагают бóльшие ограничения: жесты не работают ни на мозаике страниц, наполняющей свежеоткрытую вкладку, ни в просмотрщике исходного кода, ни в настройках расширений, ни в перечне расширений на сайте Фонда Мозиллы — но за этим видна логика достижения большей безопасности, и притом в «обычном» web-сёрфинге на эти ограничения нельзя наткнуться, так что они не мѣшаютъ.

Гораздо болѣе тяжёлою является драма превозмогания, окружающая расширение Tab Mix Plus, поскольку большинство необходимых ему интерфейсов просто-напросто отсутствуют в новых Файерфоксах. Автор этого расширения создал показательное расширение «Tab Mix — Links», еле-еле служащее аналогом одной только (первой) страницы настроек прежнего расширения Tab Mix Plus — и эта страница состоит теперь в основном из подсказок о том, какую настройку пользователю слѣдуетъ самостоятельно совершить в Файерфоксе для достижения того или иного желаемого поведения гиперссылок, потому что сам API расширений перемѣнить эту настройку не способен.

В качестве аналога ещё одной возможности Tab Mix Plus — возможности сохранения и восстановления сеанса (то есть всего окна со всѣми открытыми в нём вкладками web-страниц) — сейчас наиболее популярно расширение Tab Session Manager другого автора, но и оно едва насчитывает 130 тысяч пользователей (блѣдная тѣнь прежней многосоттысячной аудитории менеджеров сеансов!) и притом сильно страдает от ограничений API, будучи в состоянии восстановить только послѣднюю из страниц, открывавшихся во вкладке (а не всю историю посещений), и притом не будучи способным нормально задать даже значок на вкладке, загрузка страницы в которую откладывается (чтобы не перенагрузить браузер при восстановлении сеанса, насчитывающего сотни страниц), так что задание значка приходится обеспечивать загрузкою в той вкладке специальной заглушки со странным адресом.

Нечѣмъ контролировать и порядок открываемых вкладок: вмѣсто этого приходится самому перемѣнять настройки «browser.tabs.insertAfterCurrent» и (или) «browser.tabs.insertRelatedAfterCurrent» на странице «about:config», да и то без окончательной гарантии результата.

Нѣтъ настроек, контролирующих то, какая вкладка дѣлается активною после закрытия нынешней — если не считать настроек закрытия вкладки жестом из Foxy Gestures.

Чтобы получить список недавно закрытых вкладок, служащий для отмѣны состояшегося закрытия вкладок, мнѣ пришлось поставить ѿдѣльное расширение — Undo Close Tab.

Располагать вкладки во много рядов также не получится. (Есть сборник стилевых модификаций, придающих новым Файерфоксам старый вид, и вкладки во много рядов там также есть — но, оказывается, ѿ этого сходит с ума подсистема перетаскивания вкладок, совершаемого для измѣненія их порядка, потому что её проектировали с расчётом на единственный ряд вкладок.)

Нѣтъ и возможности убирать и добавлять пункты контекстного меню, присущего корешкам вкладок.

Но всё-таки часть функций расширения Tab Mix Plus, перечисленных в моём предшествующем сообщении, взяли на себя другие расширения или внутрифайерфоксовые настройки. Того же нельзя сказать о цѣломъ рядѣ других расширений, которые погибли цѣликомъ и невозвратно.

Напримѣръ, нѣтъ и быть не может аналогов для расширения «Add Bookmark Here²», добавлявшего в каждую папку закладок удобную кнопку, служащую для прибавления открытой страницы именно к этой папке.

Напримѣръ, нѣтъ и быть не может аналогов для расширения «Clean and Close», добавлявшего в список закачек удобную кнопку, позволявшую одновременно очистить этот список и закрыть окно его.

Напримѣръ, нѣтъ и быть не может аналогов для расширения «ErrorZilla Plus», добавлявшего на страницу ошибки удобные кнопки, позволявшие достать желаемую страницу (оказавшуюся недоступною ввиду ошибки) из альтернативных источников: из Архива Интернета, из кэша Google, и так далѣе — или попинговать недоступный сайт.

Вроде бы нѣтъ и аналогов для расширения «Live HTTP Headers», позволявшего въ ѿдѣльномъ окнѣ в развёрнутом виде разглядывать заголовки всѣхъ HTTP-запросов и HTTP-откликов (а не тратить время на разворачивание их по одному, как это устроено в нынешнем ѿладчикѣ). Возможно, Netmon сдѣлается таким аналогом в будущем — но пока его список заголовков грѣшитъ неполнотою свѣдѣній.

Также нѣтъ и быть не может аналогов для расширения «Searchbar Autosizer», перемѣнявшего размѣръ поля поиска по мѣрѣ набора текста в нём: нынешние API, по-видимому, не способны вмѣшиваться в стили интерфейса браузера.

По-видимому, не появилось нормальных аналогов для расширения «SQLite Manager», позволявшего открывать и измѣнять базы данных в сáмом популярном их формате — SQLite. Появившиеся аналоги лишены прежней приятности цвѣтного табличного интерфейса.

По-видимому, нѣтъ и не будет прямых аналогов для расширения «Classic Theme Restorer», способного обеспечивать бóльшую компактность интерфейса — разве что ужé упоминавшийся сборник стилевых модификаций (я его ещё не смотрѣлъ) может содержать нѣчто подобное — так что пока что я вынужден увеличить размѣръ корешка вкладки (задаваемый настройкою «browser.tabs.tabMinWidth»), у меня бывший равным 48 пикселам (это одна сороковáя часть ширины экрана FullHD), до 60 пикселов (тридцать вторая часть той же ширины экрана). По умолчанию же в новых Файерфоксах он равен 76 пикселам, но пока ещё я никак не могу стерпеть то, как медленно (болѣе чѣмъ на ¼ медленнѣе) при такой настройке проматываются вкладки при нажатии на стреловидные кнопки по бокам однорядной панели вкладок, так что я поневоле остановился на шестидесяти пикселах.

Насколько я могу судить, также не появилось ни одного аналога расширения «UnMHT», способного открывать файлы MHTML — да и не появится, если правда то, что сказано в описании к расширению Save Page WE: в API WebExtensions не предусматривается чтение локальных файлов.

Я с удивлением обнаружил, что также не существует и аналога для расширения «Work Offline», обеспечивавшего видимость того переключателя между онлайновою и оффлайновою работою, который существовал ещё со времён Netscape Navigator, а теперь закопан глубоко в меню без надежды на ясную видимость.

Так как расширение FlashGot тоже не поддерживается в новых Файерфоксах, то я решил вмѣсто него остановиться на употреблении расширения Download Master совмѣстно с одноимённым менеджером закачек. В поведении этого расширения опять же замѣтнымъ оказалось недостаточное удобство API WebExtensions: так как API не позволяет дополнять новыми пунктами выпадающие списки в диалоговых окнах самогó браузера, то никак не возможно вручную всякий раз выбирать для каждой закачки, будет ли скачивать её Firefox или DM, и потому́ этот выбор дѣлается автоматически — в зависимости от объёма файла.

Я также с неприязнью вижу, что из настроек внѣшняго вида панели управления исчезли и вертикальные черты-раздѣлители, и пробѣлы неизмѣннаго (не растягивающегося) размѣра. Всѣ такие черты и пробѣлы, ранѣе мною на панели поставленные, продолжают показываться, но едва я уберу их с неё, как возвратить не смогу никогда, никогда.

Закончив говорить в предшествующем сообщении о проблемах, с которыми в новых версиях Файерфокса сталкиваются расширения, хочется заговорить и об оформлении браузера, тѣмъ болѣе что я ужé начал упоминать о том, что отсутствие компактности интерфейса принудило меня сдѣлать корешки вкладок болѣе широкими (если бы я не сдѣлалъ этого, то болѣе крупные поля корешка съели бы даже начальные буквы заголовка вкладки, превращая разные вкладки одного сайта в неотличимые по виду, так как значки-то на них одинаковы).

В новых Файерфоксах, по-видимому, погибли и прежние темы оформления, тему придётся подбирать заново (стоявшая у меня — начисто пропала при обновлении браузера), пока что я остановился на использовании «Brushed Metal — OSX». Вообще же очень многие темы оформления, на сайте Фонда Мозиллы находящиеся в списке самых популярных, вызывают у меня самое настоящее изумление своею популярностью, поскольку выглядят слишком художественно выразительными для того, чтобы всерьёз пользоваться ими: ну как это на их фоне вообще можно что-то прочесть (скажем, на корешке у вкладки, чтобы отличить её от соседствующих), не напрягая человѣческое зрѣніе до послѣдней крайности?

Кроме того, в новых Файерфоксах над страницею всегда располагается панель управления (с кнопками и строкою адреса), а вкладки — всегда над этой панелью, а не под нею. Соѿвѣтственно, у полноэкранного окна браузера в том левом верхнем углу, в который надёжно упирается курсор мыши, расположена не кнопка «Назад», а кнопка движения по ряду вкладок налево. Сперва я подумал было, что этакое расположение выглядит скудоумным, то есть что проектанты его не имѣли ни малѣйшаго представления о том, как воспользоваться законом Фиттса на пользу надёжного попадания по кнопке «Назад». Но после нѣсколькихъ дней употребления Файерфокса именно в таком виде, какой он приобрёл въ послѣдніе 2½ года, то есть с его невозможностью располагать корешки вкладок въ нѣсколько рядов, и притом ещё с узостью единственного ряда (во-первых, в нём нельзя подавить появление кнопок, перелистывающих налево или направо, или появление кнопки, вызывающей выпадающий список вкладок, а вѣдь всѣ три эти кнопки занимают мѣсто; во-вторых, так как этот ряд располагается над панелью управления, то именно в нём закладывается ещё и мѣсто под управляющие окном угловые кнопки; всё это приводит к тому, что в этом ряду еле-еле выстраивается всего-навсего двадцать восемь таких корешков вкладок, которые у меня имѣютъ шестидесятипиксельную ширину, то есть каждый из них занимает всего-навсего тридцать вторую часть ширины экрана FullHD) — после этого я убедился на своём опыте, что именно такой Firefox требует от пользователя, открывшего хотя бы три десятка вкладок (не говоря уж о нѣсколькихъ сотнях их), полной готовности очень часто перелистывать их туда-сюда — и при таком образе жизни кнопка, служащая для движения по ряду вкладок налево, оказывается замѣтно чаще нужною, чѣмъ даже кнопка «Назад», так что очень правильно в её пользу заставили работать закон Фиттса.

Хорошо ещё, что в расширении Foxy Gestures я заблаговременно настроил жест мышóю, позволяющий подать команду «Назад» из любого мѣста на странице, а также и два жеста для простейшей навигации по вкладкам («открыть предшествующую вкладку» и «открыть послѣдующую вкладку») — однако же для болѣе сложных переходов мнѣ всё-таки придётся пролистывать ряд вкладок или выпадающий список их.

Ключевое, важнейшее ѿличіе ѿ ситуаціи с многорядными вкладками состоит в том, что при однорядных вкладках остро ощущается (и не просто ощущается, а является реальным фактом повседневной жизни) именно то обстоятельство, что если открыть три десятка вкладок, то не всѣ онѣ будут одновременно видными в одном ряду, а если открыть болѣе полусотни, то и в выпадающем списке всѣхъ вкладок онѣ не всѣ будут одновременно видными. В 2017 году можно было обозреть хоть тысячу вкладок (достаточно двадцати пяти рядов вкладок, показывающих по сóрок корешков вкладок в каждом ряду), прибегая к помощи Tab Mix Plus, но в новых Файерфоксах сама возможность достигнуть такой обозримости была утрачена корешками вкладок.

Можно подозревать (и подозреваю), что утрата обозримости многих десятков вкладок, упомянутая въ послѣднемъ абзацѣ предшествующаго сообщенія, устроена была разработчиками намѣренно, то есть как нѣкое удобное средство, позволяющее дѣятельно стремиться к тому, чтобы пользователи новых Файерфоксов придерживалися своего рода информационной диеты, открывая как можно меньше вкладок, сознательно или подсознательно желая их обозримости — и тѣмъ самымъ способствовали и уменьшению усилий браузера, пропорциональных числу вкладок, и уменьшению потребления оперативной памяти. (Извѣстно, что Фонд Мозиллы стремился уменьшить потребление оперативной памяти хотя бы для того, чтобы невозбранно перейти в марте 2019 года к употреблению восьми параллельных процессов вмѣсто четырёх.) Для пользователей вроде меня (обновлением Файерфокса принуждённых помимо воли отказаться от прежних возможностей Tab Mix Plus) этакая информационная диета выглядит довольно суровою необходимостью сократить количество вкладок на порядок и даже болѣе — так, напримѣръ, лично у меня к концу апреля оставалось болѣе шести сотен открытых вкладок, о каждой из которых я думал (и небезосновательно): «Ѽ, вот интересный материал: надо бы не только прочесть его, но и позже упомянуть во блоге — а пока что пусть во вкладке повисит». И я очень рад был, что отыскалось расширение tabs2txt, позволившее утащить из прежнего Файерфокса полный список открытых вкладок в обыкновеннѣйшемъ текстовом виде (по одному адресу открытой страницы на каждой строке текста), так что список не был утрачен, а был вставлен мною в новом Файерфоксе в расширение Tab Session Manager, импортирован как готовый сеанс. Но теперь я буду, буду постепенно сокращать количество открытых вкладок: никуда не деться от этого. Получается, что в 2020 году всѣмъ моим читателям предстоит видеть у меня во блоге множество новых записей (и прежде всего — кратких микроблогозаписей в Твиттере, не требующих значительных усилий), и в записях этих я буду упоминать такие довольно давно прочитанные свѣдѣнія и обстоятельства, до которых примѣрно за 2½ года (а до нѣкоторыхъ — за болѣе короткое или болѣе продолжительное время) ещё не дошли руки у меня, а вот теперь (под давлением современных нюансов браузеростроения) всё же дойдут онѣ, да ещё как дойдут-то!

Что же касается невозможности добавить вертикальный раздѣлитель или нерастяжимый пробѣлъ из интерфейса настройки панелей инструментов в Файерфоксе (невозможности, о которой я упоминал ещё одним сообщением раньше въ послѣднемъ абзацѣ), то существует обходной путь достижения желаемого, упоминаемый на форуме MozillaZine и также ещё на сайте Super User. Суть его состоит в том, чтобы на странице «about:config» вмѣшаться в значение настройки «browser.uiCustomization.state», значение которой записывается, по-видимому, на языке JSON и содержит массив под названием «nav-bar», перечисляющий идентификаторы всѣхъ элементов навигационной панели инструментов. Если через запятую дописать в этом массиве ещё один идентификатор, начинающийся словами «customizableui-special-separator» и заканчивающийся уникальным номером, то на панели появится вертикальный раздѣлитель, а если через запятую дописать в этом массиве ещё один идентификатор, начинающийся словами «customizableui-special-spacer» и заканчивающийся уникальным номером, то на панели появится нерастяжимый пробѣлъ. Появится, впрочем, только после перезагрузки браузера.

А ещё один досадный недостаток интерфейса новых Файерфоксов состоит в том, что ещё 11 декабря позапрошлого (2018) года с выходом Firefox 64 Фонд Мозиллы решил отказаться от встроенного читальника RSS-потоков, так что читать RSS (или Atom, или другие подобные форматы) теперь можно только после установки одного из популярных расширений, возвращающих в Firefox эту способность. Для начала я установил RSSPreview для обнаружения RSS-потоков на сайтах и для предпросмотра RSS-потоков по одному; но я знаю, что существуют и навороченные каталоги-читальники RSS-потоков съ раздѣленіемъ источников на подкатегории и с генераторами лент чтения — среди таковых Feedbro выглядит наиболѣе популярным.