| звук на веб-страницах и будущее веб-платформы |
[июн. 14, 2018|07:26 pm]
Anatoly Vorobey
|
Allow audio to autoplay, but optionally mute output
Внимательное прочтение этого бага (а также блог-записи, на которую он ссылается) полезно, мне кажется, для понимания важных проблем веб-девелопмента и веба как платформы. Прочитал, и, как говорили в давние времена, "долго думал".
Контекст этого бага - история с проигрыванием звука внутри браузера, через интерфейсы HTML5. Ввиду того, что многие сайты и страницы откровенно задалбывают тем, что врубают звук сразу при открытии страницы, некоторое время назад возникло желание их в этом ограничить. Уже долгое время в мобильных браузерах веб-приложениям запрещено включать звук до того, как пользователь каким-то образом отреагирует на страницу (например, дотронется до экрана). А с недавней версии Хрома то же самое поведение стало дефолтным на десктопе.
Казалось бы, все хорошо и правильно, и не на что жаловаться. Но автор этого баг-репорта утверждает (и довольно убедительно аргументирует), что технический способ, которым это было сделано, неверный. Вместо того, чтобы заглушить (mute) звук до тех пор, пока пользователь не проявит какой-то интерес к странице, браузер возвращает ошибку, когда код на джаваскрипте пытается что-то проиграть. Но проблема в том, что огромное количество сайтов уже написаны таким образом, что они эту ошибку не понимают и все приложение перестает работать после нее. Если посмореть на комментарии в баг-репорте, там разработчики Хрома просят привести примеры и их просто забрасывают примерами. Тут и игры всякие на HTML5, и мультимедийные приложения разного рода, и целые фреймворки, и всякие утилиты для голосового общения, и арт-проекты, и что угодно еще. Возможно, некоторые из них можно счесть нелегитимно пытающимися что-то немедленно проигрывать при открытии; а про другие можно сказать, что это явно заложено в их цель существования и это то, что пользователь хочет. Так или иначе, все они продолжали бы работать без проблем, если бы браузер делал "заглушку", а не "ошибку", и все они теперь сломаны этим изменением и требуют починки. Естественно, в куче случаев эта починка просто невозможна - у данного проекта нет больше разработчиков, и сайт/страница просто перестают работать, например.
На самом деле я незнаком с этой проблематикой, и совершенно не уверен в том, что автор баг-репорта и те, кто пришли с ним соглашаться, правы. Мне это кажется убедительным, но вполне возможно, что есть и другие убедительные аргументы в пользу "ошибки", а не "заглушки"; собственно, один из них я легко могу сформулировать сам - "так правильнее" с точки зрения инженерной чистоты интерфейса, а если кто-то написал вызов функции без проверки ошибки, пусть исправит код. Может, есть и другие аргументы еще лучше. Но меня занимает не столько вопрос того, как правильно поступить в данном конкретном случае, сколько сложившаяся ситуация со всей платформой на этом примере.
Действительно, посмотрите, как это выглядит с точки зрения веба как платформы. Современные HTML/JS развились до такой степени, что можно строить на них действительно сложные и богатые приложения, но как эти приложения выглядят с точки зрения стабильности интерфейсов? На примере этого бага мы видим, что можно написать "программу" под "операционной системой" веба (т.е. веб-сайт), она будет прекрасно работать, потом пройдет год-два, что-то изменят в браузере, и она перестанет работать. Причем пусть не у всех сразу, если один браузер изменили, но у очень многих или даже большинства. Причем нет такого, как в обычных ОС, что если вы не переходите на новую версию ОС (новый Windows, скажем), то как минимум те программу, что у вас уже есть, продолжают работать. Нет, браузеры само-апдейтятся все время у всех, и практически никто не остается со старыми версиями, поэтому платформа все время находится в движении. И из-за того, что набор интерфейсов феноменально сложный и запутанный (в сравнении, скажем, с Win32 или POSIX), мы получаем ситуацию, при которой:
1) все нетривиальные приложения нужно вручную тестировать на всех главных браузерах, а потом периодически тестировать снова на новых версиях
2) изменения в браузере, которые могут сломать ваше приложение, вообще могут никак не касаться "официального" стандарта. Скажем, это изменение со звуком в Хроме никак не относится к стандарту, это типичное "внутреннее" решение, деталь имплементации. Но из-за вышеупомянутых особенностей платформы оно легко может повалить огромное количество "программ".
В итоге мы получаем платформу, на которой, чтобы остаться на месте, нужно постоянно бежать вперед. Если вы "просто" сделали что-то очень крутое HTML5, и запустили сайт, вы не можете просто забыть про него и надеяться, что он будет работать через год и два и три. Если это не сайт, а UI-библиотека на гитхабе, и не получала коммитов последние три года, можно ожидать, что она просто не будет работать в последних Хромах/Сафари/Эджах (я преувеличиваю? осадите меня, если так; но два-три примера такого мне точно недавно попадались).
— У нас, — сказала Алиса, с трудом переводя дух, — когда долго бежишь со всех ног, непременно попадёшь в другое место.
— Какая медлительная страна! — вскричала Королева. — Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте.
Не очень знаю, что можно с этим сделать; и пришли мы к этому, по сути дела, в результате того, что все занимались хорошим и правильным, казалось бы, продвижением веб-платформы. Но конечный результат кажется мне немного тревожным. Подумайте хотя бы об архивации и истории. Мы можем сегодня запускать ДОС-приложения 1990 года через DosBox, или игры для разных приставок 90-х через эмуляторы. На чем вы сможете запустить веб-приложение 2015 года в 2030-м? Вы думаете, оно будет работать на браузере 2030-го? Нет. Вы думаете, браузер 2015-го сохранится и вы сможете легко его запустить в 2030-м? Тоже не факт (технологические условия для этого есть уже и сейчас, но квест "найди Хром 2011-го года, запусти его в виртуальной машине и посмотри через него снимок такого-то сайте в archive.org" доступен только продвинутым пользователям, полагаю, а чрезвычайная сложность и фрагментация платформы, меняющейся от года к году, затрудняет это все больше и больше со временем).
И еще такая мысль. Сравните эту ситуацию с Flash-приложениями, от которых мы в основном избавились в последние годы, и веб-разработчики в целом этому радовались. Действительно, Flash-проприетарный формат, плохо поддерживался Adobe, куча проблем с секьюрити, трудно интегрировать с окружающим HTMLем и современной мобильной реальностью... насколько лучше уметь все то же самое делать в HTML5, правда? Ладно, забудем про миллион существующих игр/приложений и перепишем их в HTML5, ладно. Я это говорю без сарказма, я сам в общем рад был забыть о Флеше и его глюках и не тыкать больше в его бесконечно раздражающий интерфейс. Но если подумать, Флеш как минимум был стабильным стандартом. Как минимум, игры, написанные на нем в 2011-м, без проблем работали в 2015-м, без всяких изменений. Можем ли мы надеяться на то же самое в случае таких прекрасных, богатых и сложных HTML5-приложений? |
|
|
