Anatoly Vorobey (avva) wrote,
Anatoly Vorobey
avva

Category:

звук на веб-страницах и будущее веб-платформы

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-приложений?
Tags: интернет, программирование
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 133 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →