Как мы сообщали на прошлой неделе, Mozilla, Microsoft и Opera разочаровались в сайтах, которые нацелены только на -webkit свойства CSS3. Это делает их браузер плохим, даже если он использует идентичные или лучшие технологии. Чтобы решить эту проблему, они предлагают добавить поддержку префикса -webkit в браузеры, не относящиеся к webkit.
Хотя это в основном маркетинговое решение, это реальная проблема. Это решение огорчает многих веб-разработчиков, но мы заслуживаем нашей доли вины. В этой статье мы обсудим варианты, плюсы и минусы.
1. Ничего не меняется
Предположим, что ничего не сделано для решения проблемы с префиксом браузера.
ПРОФИ
- Браузеры продолжают реализовывать свои собственные префиксы, которые вы можете свободно использовать или игнорировать.
- Там нет ничего нового, чтобы узнать или проверить.
- Это кажется правильным, и решение порадует большинство веб-разработчиков.
МИНУСЫ
- Мы сохраняем четыре префикса и одно стандартное свойство. Таблицы стилей больше, чем необходимо, и их сложно проверить.
- Более ленивые или менее опытные разработчики будут продолжать ориентироваться только на браузеры webkit.
- Доля Chrome и Safari на рынке может возрасти до такой степени, что делает другие браузеры избыточными. Мы возвращаемся ко временам единого браузера и инноваций. Темные дни IE6-подобного господства возвращаются.
- Microsoft, Mozilla и Opera считают, что это реальная проблема: ничего не делать — это не вариант .
2. Браузеры без Webkit поддерживают префикс Webkit
Предположим, IE, Firefox и Opera поддерживают свойства с префиксом webkit.
Microsoft уже внедрила -webkit-text-size-adjust в мобильной версии IE. Хотя это нестандартное свойство для Safari (здесь нет text-size-adjust ), они выслушали отзывы сообщества и обратились за поддержкой . Это вряд ли случится снова, если Mozilla или Opera начнут добавлять свойства webkit в свои движки.
ПРОФИ
- Это быстрое и грязное решение, позволяющее отображать браузеры, не являющиеся webkit, а также Chrome или Safari.
- Разработчикам не нужно обновлять свои сайты.
- -webkit станет доминирующим префиксом; использование -moz, -ms или -o станет ненужным, а размеры файлов CSS уменьшатся
- Это мешает WebKit, Google и Apple стать слишком мощным. Если другой поставщик не согласен с реализацией, он может просто сломать ее или предоставить альтернативу. Разработчики могут не иметь возможности использовать свойство в любом браузере.
МИНУСЫ
- Это неправильно: один браузер не должен маскироваться под другой.
- Это вознаграждает небрежные методы разработки.
- Различные реализации браузера сделают некоторые свойства непригодными.
- Если разработчики сохранят свойства webkit, которые не работают в других браузерах, все больше пользователей переключатся на Chrome и Safari. Другие поставщики будут становиться все более неактуальными.
3. Все браузеры используют префикс -бета
Вместо отдельных префиксов, предположим, что в каждом браузере реализован один и тот же бета-префикс.
ПРОФИ
- Просто один префикс для изучения и использования.
- Размеры таблицы стилей уменьшены.
- Свойство явно экспериментальное; разработчики будут более осторожны с его использованием.
МИНУСЫ
- Как решение, оно мало отличается от каждого поставщика, использующего префикс -webkit.
- Различные реализации браузера могут сделать некоторые свойства непригодными.
- Продавцы вряд ли удалят свои префиксы; ситуация не изменится.
4. Экспериментальные свойства CSS появляются только в бета-браузерах
Предположим, что префиксные свойства отменены во всех браузерах. Новые экспериментальные свойства будут присутствовать только в ночных и бета-версиях — и они не требуют префикса.
ПРОФИ
- Для разработчиков становится невозможным использовать префиксный код или ориентироваться на определенные браузеры на рабочих сайтах.
- Сайты только для Webkit наказываются соответственно.
- Мы все работаем по конечным стандартам, а не по будущим.
МИНУСЫ
- Гораздо меньше разработчиков будут использовать и тестировать экспериментальные свойства. Это может привести к ошибочным реализациям.
- Новые свойства могут занять несколько лет, чтобы стать стандартизированным. Готовы ли мы ждать?
- Это никогда не случится. Если один поставщик решит сохранить префиксы в своем основном выпуске, они все будут.
5. Префиксы поставщиков отбрасываются после окончательной реализации
Когда свойство стабильно и реализовано без префикса, все предыдущие версии с префиксами удаляются из браузера.
ПРОФИ
- Это логичное решение.
- Это удаляет ненужный код. Раздувание библиотек уменьшается, а браузеры становятся более компактными и быстрыми.
- Он вознаграждает за хорошие практики развития и наказывает за плохие.
МИНУСЫ
- Он не предлагает немедленного разрешения для сайтов, которые ориентированы только на браузеры webkit.
- Это сломает сайты в одночасье — поставщики не захотят внедрять политику.
- Свойства могут занять годы, чтобы достичь стандартизации и графики реализации браузера отличаются. Префиксы ломаются в разное время, поэтому требуется постоянное тестирование и обслуживание сайта.
6. Процесс соглашения W3C становится быстрее
Предположим, что W3C применяет более быстрые методы стандартизации и публикует графики, детализирующие, когда ожидается, что свойство достигнет зрелости.
ПРОФИ
- Существующий процесс слишком медленный.
- Разработчики будут знать, когда можно использовать конечное свойство.
- Для префиксов поставщиков меньше шансов получить широкое распространение.
МИНУСЫ
- Процесс не намеренно медленный. Всегда будут практические и материально-технические проблемы для преодоления.
- Продавцы работают на разных скоростях, и невозможно точно оценить сроки доставки.
- Более быстрый процесс утверждения может привести к худшим реализациям, что сводит на нет смысл процесса стандартизации.
7. Лучшая евангелизация и больше образования в сообществе разработчиков
Мы не были бы в этом беспорядке, если бы разработчики писали кросс-браузерный код и понимали лучшие методики.
ПРОФИ
- Это хорошее решение, которое мы можем реализовать сегодня.
- Любой, кто демонстрирует пример кода с префиксными свойствами, может предоставить информацию о поддержке браузера со строгими оговорками.
- Каждый может помочь. Исправьте свой собственный код и контактные сайты, которые не совместимы с разными браузерами.
МИНУСЫ
- Нет никаких гарантий, что евангелисты и разработчики изменят свое отношение.
- Это слишком поздно? Методы передовой практики публикуются, но игнорируются.
- Там нет определенного центрального хранилища информации.
- Всегда будут новые, невежественные и неаккуратные разработчики. Никто не может стать экспертом в одночасье.
Единого решения проблемы префикса поставщика не существует. Лично я предпочитаю более быстрый процесс W3C, отбрасывая префиксы после реализации и улучшая евангелизацию. Но это требует серьезного изменения мышления, а не технических изменений.
В конечном счете, разработчики вызвали эту проблему: мы должны ее исправить. Не возникнет проблем, если мы будем избегать префиксных свойств или использовать правильные межбраузерные резервы. Если мы этого не сделаем, есть риск, что свойства CSS3, на которые мы полагаемся сегодня, не будут работать завтра.