Предсказание поставщика приставки: интервью Эрика Мейера из ALA Тантек Челик

Эрик Мейер из A List Apart, мастер CSS и поклонник префиксы, интервью Tantek Челик, веб - стандарты Mozilla ведут, по спорному плану Mozilla, чтобы поддерживать -webkit-приставочные свойства.

Тантек ускорил нынешний кризис в Web Standards Land на открытом заседании рабочей группы W3C CSS, на котором он отметил преобладание мобильных сайтов, использующих только WebKit, создав тем самым монокультуру браузера. Тантек обсудил решение Mozilla - Firefox Mobile притворился похожим на Webkit и поддерживает несколько -webkit-CSS-свойств - что вызвало множество споров в сообществе разработчиков стандартов, особенно когда представители Opera и Microsoft сразу согласились с этой проблемой и объявили о планах, аналогичных Mozilla. Следующее обсуждение было проведено через EtherPad, обмен мгновенными сообщениями, электронную почту и телефонные звонки.

Давайте начнем с основ. Что именно планируют сделать команды Mozilla, Opera и Internet Explorer?

Я не могу говорить за команды Opera и Internet Explorer. В настоящее время Mozilla анализирует мобильные веб-сайты на предмет нескольких проблемных ситуаций - сайтов, которые ищут строку агента пользователя WebKit и соответственно отправляют только высококачественный мобильный контент; и сайты, которые используют только или в основном -webkit-префиксные свойства.

Основываясь на этом анализе, мы планируем реализовать строку UA для Firefox Mobile, которая передает такой UA-сниффинг - по иронии судьбы, это похоже на то, как WebKit добавил «как Gecko» в свою строку UA при запуске Safari - и реализовать определенные -webkit-префиксные свойства для в каждом конкретном случае, когда это оправдано собранными данными.

Вы не собираетесь просто универсально карту , -webkit-чтобы -moz-? План состоит в том, чтобы поддерживать только ограниченное подмножество всех -webkit-свойств?

Правильно. Наша цель здесь - минимизировать количество других свойств с префиксом вендора, которые мы должны поддерживать только для тех, которые обоснованы данными, и это будет иметь значение для пользователей веб-сайтов Firefox Mobile. Данные, которые мы имеем до сих пор, не оправдывают полную поддержку всех -webkit-свойств.

Кроме того, мы рассматриваем поддержку только -webkit-префиксной версии свойства, если и / или когда мы также поддерживаем нефиксированную версию. Это предоставит веб-разработчикам опцию, основанную на стандартах, вместо использования префиксных свойств.

Но на данный момент мы не знаем, какие это будут свойства. Или мы?

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

Я предполагаю, что список со временем изменится. Похоже, что это создаст еще большую путаницу для разработчиков, поскольку вы будете поддерживать -webkit-префикс для некоторых свойств, а не для других. Как вы ожидаете, разработчики будут следить за тем, кто поддерживает чьи префиксы и какие свойства?

Свойства с префиксом поставщика никогда не должны зависеть от разработчиков. Они были и есть для экспериментальных реализаций и технологий, находящихся на стадии итераций рабочих проектов CSS в процессе стандартизации. Я ожидаю, что разработчики будут следить за нефиксированными свойствами и реализациями, которые их поддерживают. Это то, от чего могут зависеть разработчики.

Это не кажется реалистичным, хотя. Если бы разработчики придерживались того, от чего они могут зависеть - нефиксированных свойств - мы бы не оказались в такой ситуации.

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

Будет ли Mozilla вести список поддерживаемых префиксов для каких свойств?

Mozilla продолжит документировать, какие свойства поддерживает Firefox, со всеми распознанными префиксами на developer.mozilla.org.

Итак, это то, что вы планируете делать, но как насчет того, почему вы планируете это делать? Какова цель вашего плана?

Цель Mozilla состоит в том, чтобы открыть определенную для WebKit часть сети другим поставщикам точно так же, как много лет назад Mozilla и Opera должны были практиковать то, что поддерживают IE-проприетарные или только IE-технологии. Мы подняли проблему как монокультуры мобильной сети WebKit; а также недостаточность евангелизации для борьбы с ней, несмотря на то, что многочисленные евангелисты из Mozilla, Opera и Microsoft работают с веб-разработчиками над публикацией основанного на стандартах кросс-браузерного контента.

С таким большим количеством евангелизации правильная вещь, почему это было недостаточно?

За последние 10 с лишним лет евангелизация веб-стандартов была довольно эффективной, привела к повышению осведомленности и принятию действительного HTML + CSS, прогрессивному улучшению, ненавязчивому написанию сценариев, микроформатам и так далее. Однако, несмотря на усилия Mozilla и других, направленные на евангелизацию за последний год, мобильная сеть, ориентированная на WebKit, растет быстрее, чем мы можем евангелизировать, особенно в отличие от евангелизации, специфичной для WebKit, как явной, так и явной.

Я думаю, что это справедливый вопрос: что здесь пошло не так, как мы закончили с монокультурой мобильного веба WebKit, несмотря на то, что, по крайней мере, некоторые стандарты пропагандировали наоборот? Я не уверен, что это было что-то одно, я думаю, что было несколько факторов, которые вместе создали условия для возникновения и укрепления этой конкретной монокультуры.

Во-первых, инновации в WebKit помогли повысить ожидания того, что было возможно на веб-платформе - что, безусловно, было и остается очень хорошей вещью, поскольку продвижение потенциала открытой веб-платформы является целью, которую мы все разделяем.

Во-вторых, широкое распространение WebKit в iPhone, Android и BlackBerry. Это должно было быть предупредительным знаком; то есть, когда несколько поставщиков используют одну реализацию, высока вероятность появления монокультуры.

В-третьих, мы наблюдали сильную пропаганду -webkit-функций Apple и Google, особенно в части презентаций и демонстрационных сайтов «HTML5». Некоторые из этих сайтов «HTML5» впоследствии были обновлены несколькими префиксами, специфичными для поставщиков, для экспериментальных функций CSS (для большего количества кросс-браузерных демонстраций и кодирования). Тем не менее, подразумеваемое сообщение ранних версий только для WebKit все еще повторяет сегодня.

В-четвертых, почти на каждой конференции, посвященной веб-дизайну / разработке, были годы переговоров, на которых спикеры, взволнованные обсуждением и демонстрацией новейших достижений, демонстрировали сайты и код, созданные с -webkit-префиксными свойствами. Это обеспечивало неявное, если не явное, поощрение к цели и коду в первую очередь или только для WebKit, особенно на мобильных сайтах.

Наконец, все вышеперечисленное усугубляется тем, что рабочей группе CSS потребовалось много времени, чтобы стандартизировать некоторые из этих инновационных -webkit-свойств с префиксами, чтобы все ядра браузеров могли поддерживать их без префиксов, включая WebKit, и предоставлять веб-разработчикам стандартизированные стандарты. вариант, от которого они могут зависеть.

Вы сказали, что делаете это для пользователей Firefox Mobile. То есть этот план есть только в вашем мобильном продукте, а не в настольном браузере?

Строка UA для Firefox Mobile уже отличается от Firefox Desktop, поэтому да, эта часть, упомянутая ранее, относится к мобильному продукту. Что касается реализации определенных -webkit-свойств, то в настоящее время мы рассматриваем возможность их поддержки только в мобильных устройствах, что ограничивает возможности использования, а не предоставляет согласованную платформу Firefox / Gecko для веб-разработчиков, от которой они могут зависеть.

Поскольку цель здесь - обеспечить единообразие для всех мобильных пользователей, вполне вероятно, что в конечном итоге вы решите обеспечить единообразие для всех пользователей Firefox, не так ли? Таким образом, эта стратегия распространяется с мобильного на настольный компьютер.

Проблема, которую мы обнаружили, связана именно с мобильными веб-сайтами, которые были закодированы только для WebKit. Поскольку на рабочем столе гораздо больше разнообразия браузеров, там происходит гораздо меньше кодирования только для WebKit. Вот тут-то и возникает требование эффективности - если что-то на самом деле не помогает пользователю, нет никаких причин для его реализации. Таким образом, мы могли бы реализовать это на платформе Firefox, но в этом гораздо меньше смысла, если это не улучшит работу пользователей на рабочем столе. Мы все еще должны учитывать влияние на разработчиков, и этого может быть достаточно. Мы можем попробовать что-то в бета-сборках, чтобы получить обратную связь.

В том же духе, это не похоже на то, что останется ограниченным несколькими свойствами здесь и там. Похоже, что когда дверь открыта, в конце концов, вы дошли до того, что рассматривали -webkit-ее как свой собственный префикс. Или даже если Mozilla этого не сделает, то Opera или Microsoft сделают это в какой-то момент, и впоследствии вы будете вынуждены последовать их примеру. Правда или нет?

Я думаю, что это зависит от того, сможем ли мы открыть монокультуру мобильного веба WebKit или нет. История показала, что Mozilla и другим удалось открыть веб-монокультуру IE с ограниченной реализацией нескольких функций только для IE, таких как innerHTMLи XMLHttpRequest, которые впоследствии были стандартизированы с помощью W3C. В Firefox не было полной реализации функций только для IE. У Mozilla есть солидный послужной список очень продуманной и индивидуальной реализации возможностей веб-совместимости.

Но предположим, что, скажем, Opera работает вперед и повсеместно поддерживает -webkit-по причинам, аналогичным тем, когда у них некоторое время по умолчанию для строки UA был Internet Explorer. Разве это не заставит Мозиллу пойти по тому же пути? И если нет, то почему?

Если другой мобильный браузер поддерживает -webkit-универсально, я не вижу, как это повлияет на ситуацию, потому что доминирующий движок мобильного браузера, WebKit, уже поддерживает -webkit-универсально.

Питер-Пол Кох довольно убедительно сказал, что «нет WebKit». Вы видите это по-другому, очевидно.

Неважно, что Питер-Поль Кох говорит: «WebKit не существует» - важно то, что веб-разработчики верят и ведут себя так, как будто есть WebKit. Они кодируют и отправляют мобильные сайты соответствующим образом, анализируя строки WebKit UA и используя только -webkit-свойства. Этот эффект измерим. Отрицание этого не делает это не так.

И разработчики делают это для пользователей браузеров, не относящихся к WebKit, таких как Mozilla, Opera и Explorer, что сокращает или, в худшем случае, ухудшает их восприятие.

Правильно. Мы наблюдаем, что мобильные веб-сайты в мобильные браузеры, не относящиеся к WebKit, отправляют ультра-минимальные и функциональные возможности более низкого уровня или «функциональные телефоны».

По крайней мере, в некоторых из этих случаев вы полностью поддерживаете то, что они делают, за исключением того, что они скрывают это за -webkit-префиксами?

Да. Текущие версии Firefox поддерживают -moz-префиксные версии CSS3 градиентов, преобразований, анимации и так далее. Мы активно работаем с рабочей группой CSS, чтобы быстро усовершенствовать соответствующие спецификации и удалить префиксы поставщиков для таких стабильных функций. Таким образом, мы все можем помочь веб-платформе продвинуться со стандартами, а не с горсткой префиксов поставщиков.

Как часто сайт действительно сломан? Если сайт отличается, но все еще функционален, это то, чего мы ожидаем в Интернете. Похоже, вы действительно возражаете против того, что рендеринг вашего браузера менее резкий, а не то, что пользователи заблокированы. Действительно ли это угроза принятию и использованию браузеров, не относящихся к WebKit?

Они часто ломаются. Эти мобильные сайты нижнего уровня отличаются и значительно менее функциональны. Когда пользователи видят существенно худший опыт в другом браузере на сайте на том же устройстве, они обвиняют браузер, а не сайт или устройство.

Обещание префиксов вендоров состояло в том, что реализации могут быть протестированы на месте, а проблемы исправлены до того, как поведение будет формализовано. Это хорошо окупалось, например, градиентным синтаксисом, где были опробованы полностью несовместимые синтаксисы, и в итоге был найден единый синтаксис. Похоже, что этот план ставит под угрозу эту возможность - когда поставщики начнут поддерживать префиксы друг друга, мы также можем вообще отказаться от префиксов. Это разумный вывод?

Иногда в технологиях ожидается, что они будут безупречны, без каких-либо изъянов или ударов. Конечно, такие ожидания не имеют оснований в опыте, поэтому неясно, откуда они берутся. Префиксы вендоров CSS ничем не отличаются в этом отношении. На самом деле они были довольно успешными - многие браузеры годами экспериментировали с итерациями над различными функциями, в конечном итоге стандартизируя то, что работает.

В частности, у Mozilla есть отличный опыт пробовать вещи с -moz-префиксом на ранних этапах , а при стандартизации отправлять стандартное свойство без -moz-префикса, а также отбрасывать экспериментальную префиксную версию. Иногда на этом пути тоже возникали боли: например, сколько времени потребовалось, border-radiusчтобы стандартизироваться, каково это сейчас. Однако мобильная монокультура WebKit, вероятно, является первым случаем, когда мы столкнулись с серьезной проблемой с префиксами поставщиков. Должны ли мы отказаться от префиксов поставщиков сейчас, несмотря на их несовершенный, но впечатляющий послужной список?

Были призывы заменить префиксы вендоров на «универсальные» префиксы, такие как -x-или -beta-. Что вы думаете об этой идее?

Опыт показал в усилиях других стандартов , что , когда есть бета или экспериментальный префикс, как -x-, что каждый делает в конечном итоге поддерживать их навсегда в дополнении к версии без префикса. Например, проверьте заголовки вашей электронной почты - вы увидите много X-*заголовков. Или тот факт, что браузеры должны поддерживать image/x-pngв дополнение к image/pngизображениям PNG.

Напротив, с помощью префиксов вендоров CSS, Mozilla показала, что можно отбрасывать -moz-префиксные свойства и продвигать Интернет вперед. Я полагаю, что по крайней мере еще один поставщик браузеров смог в конечном итоге отбросить префиксные свойства своих поставщиков после того, как они отправили стандартные версии без префиксов.

Почему «универсальные» префиксы нельзя отбрасывать так же, как префиксы поставщиков? Какая разница?

Универсальные префиксы становятся надежными во всех браузерах, и, следовательно, сетевые эффекты, усиливающие их использование и поддержку, оказываются более сильными - возможно, достаточно сильными, чтобы требовать их неограниченной поддержки для обеспечения совместимости, как, например, вышеупомянутые X-*почтовые заголовки и типы контента.

Существует аналогичный риск, когда несколько браузеров поддерживают -webkit-свойства с префиксом. Этот риск может быть уменьшен и, возможно, даже преодолен, если несколько браузеров поддерживают эквивалентные свойства без префиксов, и мы призываем веб-разработчиков использовать их для продвижения вперед. Тем не менее, это не исправит специфичные для WebKit мобильные сайты, которые уже были отправлены.

Так что это направлено на решение проблемы сейчас, рискуя создать аналогичную проблему в будущем. Разве вы не просто откладываете боль?

Это, безусловно, сложная проблема со многими переменными и многими действующими лицами. Комбинация исправления прошлых проблем и предоставления надежного пути для будущего развития обеспечивает хороший баланс помощи пользователям и разработчикам. Мы основываем наш подход на изучении и сборе данных, и ожидаем его развития и повторения как такового.

Ни один подход не обходится без риска, но вообще ничего не делать или притворяться, что проблем нет, - это самый рискованный из всех, потому что он только ухудшает монокультуру мобильного веб-WebKit. В прошлый раз, когда у нас была веб-монокультура, она отбросила открытую сеть на годы.

Даниэль Глазман, сопредседатель рабочей группы CSS, призвал к действиям в ответ на ваш план. Есть ли у вас какие-либо предложения о том, что мы можем сделать, чтобы улучшить ситуацию?

Как веб-разработчики, мы можем сделать несколько ключевых вещей.

Во-первых, прекратите заниматься поиском и анализом контента, специфичным для «WebKit», особенно на мобильных устройствах.

Во-вторых, прекратите использовать только -webkit-префиксные свойства и либо используйте свойство без префикса там, где оно стандартизировано, либо «стабильно» для рабочей группы; или, если это не стабильно, используйте свойство с префиксом каждого поставщика, где они объявили или отправили поддержку.

В- третьих, помочь евангелизировать корректировки для любых сайтов , которые вы видите , которые будут делать WebKit конкретных UA-нюхают и / или используя только -webkit-префиксами свойства. Точно так же помогите проповедовать исправления для любых веб-сайтов, которые даже косвенно пропагандируют использование WebKit UA-сниффинга и / или использование только -webkit- префиксных свойств.

Самое главное, показать хороший пример. Используйте веб-стандарты в первую очередь на своих сайтах, в статьях и беседах. При обсуждении или демонстрации экспериментальных функций или действующих стандартов, будь то в одном браузере или во многих, будьте внимательны с предупреждениями и дайте понять, что блестящего сегодня может сломаться завтра.