Пользователь
57,4
рейтинг
17 февраля 2013 в 13:09

Разработка → Потенциальные проблемы с монокультурой WebKit

Несколько дней назад стало известно, что Opera переходит на браузерный движок WebKit, на котором уже сейчас работают десятки других браузеров: Chrome, Safari, браузеры почти всех мобильных систем: iOS, Android, Amazon Kindle, BlackBerry 10, Tizen, Symbian, PlayStation 3 и проч.

На десктопах доля WebKit не такая большая (около 40%), но вот на самом перспективном рынке мобильных систем у WebKit практически монопольное положение.

Это вполне знакомая ситуация для многих, кто помнит положение дел в вебе в 2001-2005 годах, когда более 90% браузеров работало на одном движке (Trident, MSIE). К счастью, сейчас ситуация не настолько опасна: новый претендент на монополию — свободная технология, которая разрабатывается под лицензией Open Source, но всё равно остаются специфические риски.

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

Другими словами, Opera признала WebKit в качестве своеобразного стандартного движка, на котором работают «многие другие браузеры». Здесь речь идёт ни больше ни меньше, о зарождении браузерной монокультуры. У неё есть краткосрочные преимущества: это общая экономия ресурсов, ведь все работают над одним проектом. Легче разрабатывать сайты под одну платформу, а не под несколько, проще создавать интерактивные веб-приложения. Но есть и обратная сторона медали, потому что веб — это платформа. Недостатки монокультуры здесь имеют долговременный характер, считает один из разработчиков компании Mozilla Стив Финк (Steve Fink).

Стив Финк предлагает представить на секунду, что все мобильные системы перешли на движок WebKit. К чему это приведёт?

1. Обратная совместимость багов. Баги есть везде. Представим баг в рендеринге SVG, из-за которого фоновые изображения шириной в простое число пикселов, например, отключают прозрачность изображения. За год существования такого бага целая куча сайтов будет от него зависеть, то есть они создают дизайн с учётом этого бага. В какой-то момент баг пофиксили. Вышла новая девелоперская бета браузера. В ней рушатся все эти сайты. Патч изымают из релиза, обработка бага просто фиксируется в логах браузера. Если весь мир сидит на WebKit’е, то такая ситуация всех устраивает. Баг теперь стал частью веб-платформы.

2. Предотвращение инноваций. Представим, что через пять лет группа хакеров выпустит инновационный браузер, который равномерно расходует ресурсы всех 100 ядер стандартного процессора 2018-го года, а не полностью отжирает одно ядро на каждую вкладку. Ребята проделали героическую работу для поддержки фичи на 99% всех веб-сайтов. Вдруг эта доля падает до 98%, почему? Потому что только что вышла новая бета Webkit с новой фичей, которую многие сразу внедрили в продакшн. Вскоре доля падает до 90%: в WebKit появился неустранимый баг, который случайно ломает модель распределённой нагрузки. 80%, дело сделано, хакеры пошли писать социальную сеть для домашних птичек.

3. Чрезмерный контроль. Крупные компании имеют чрезмерное влияние на разработку браузера и могут способствовать. Например, они могут внедрить DRM в обработку HTML в браузере или блокировать создание неких инновационных API, которые угрожают их основному бизнесу или бизнесу партнёров.

4. Сложность и непредсказуемость. Комитеты по стандартизации отмирают за ненадобностью, а разработка новых стандартов диктуется рыночной необходимостью. Разработчикам веб-сайтов остаётся гадать, какие стандарты будут поддерживаться и какие появятся новые, исходя из рыночной конъюнктуры.

5. Путаница. Стив Финк приводит пример из нынешней ситуации с некоторыми фичами CSS, которые непонятно как работают. Разработчикам на них уже плевать, они работают над следующей версией стандарта CSS5. Документация не обновлялась несколько лет. В сети можно найти сотни инструкций и видеороликов с объяснением, как использовать эти фичи CSS. В итоге, документация остаётся для тех, кто не может смотреть видео на Youtube.

В результате, пишет Стив Финк, веб становится гораздо функциональнее, чем он был в 2013 году. Новые стандарты разрабатываются быстрее? мгновенно внедряются в браузер и повсеместно на всех сайтах. Все браузеры сразу начинают поддерживать фичу, которую только вчера Apple представила в новом девайсе. Но в монокультуре без согласованных стандартов поддержка любой фичи может исчезнуть так же быстро, как появилась. То, что сегодня быстро и удобно реализовать, завтра может перестать работать. В любом случае, документации не описывают функции целиком и полностью с той глубиной, с которой их реально можно использовать, а реализация не гарантирует совпадения со спецификациями. Это ведь тот мир, к которому мы стремимся, не правда ли?

Стив Финк пишет, что монокультура не обязательно плохая вещь, как выбор TCP или кремния для микросхем. Это может быть хорошая вещь, но только при том условии, что она стабильна и неизменна. Хотя, даже в том же TCP находят изъяны. Но в такой системе как веб, которая стремительно развивается, где постоянно появляются новые технологии и новые незакрытые ниши, необходимо существование нескольких не связанных друг с другом агентов, которые координируют свои действия. Достаточно изучить, что такое конкуренция и зачем она нужна в экономике.
Анатолий Ализар @alizar
карма
751,5
рейтинг 57,4
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (76)

  • +20
    … считает один из разработчиков компании Mozilla Стив Флинк (Steve Fink).

    … группа хакеров выпустит инновационный браузер, который равномерно расходует ресурсы всех 100 ядер стандартного процессора 2018-го года, а не полностью отжирает одно ядро на каждую вкладку

    Не знаю как у него, но у меня Firefox отжирает на одну вкладку все, что есть.
    • +21
      Надо подождать еще 5 лет же.
    • +23
      Ну вот у меня Firefox как раз умеренно ест память и процессор, а с хромиумом как раз так — откроешь два-три гугла, уже 100% CPU load и гигабайта памяти съеден.
      • +3
        Слез с chromium как раз из-за прожорливости, firefox жрёт меньше значительно, и даже как мне кажется работает быстрее (но это может лишь кажется). Пока сижу на одном мало известном браузере на qtwebkit и не знаю что всё же выбрать (у текущего много минусов), но на chromium возвращаться не хочется уже.
        • +1
          Leechcraft? :)
          • 0
            QupZilla :)
      • 0
        Может быть у тебя и у maxmert флэш реклама жрёт CPU? Больше нечему жрать.
  • –1
    Для конкуренции надо чем-то выделяться. Так как как только ты что-то будешь коммитить в вебкит это появится у всех, то начнутся форки, фичи которые «проходят тестирование» в течении пары версий браузера. А самое страшное, что начнут вкладывать основную часть ресурсов не в вебкит, а в свистоперделки оболочки, который позволят выделиться.

    Надеюсь этого всего не случится, но рынок…
    • +1
      Думается мне они так и так вкладывают основную часть в свистоперделки, а не в вебкит (если браузер на нем). По поводу форков, само собой они сделают форки, а фичи будут периодически сливать в основную ветку, Сейчас скорее всего происходит точно так же, хотя бы потому, что версия webkit у Safari имеет свои баги, а у Chromium свои.
    • +8
      Вебкит по LGPL распространяется, запроприетарить изменения в движке не получится, придётся публиковать исходники.
      • 0
        Вообще-то LGPL можно перевести и в закрытый код — правда это достаточно непросто.
        Даже GPLv3 можно перевести в закрытый код (см. пример MicroTik RouterOS)
        • +11
          Даже GPLv3 можно перевести в закрытый код (см. пример MicroTik RouterOS)

          Нельзя. MicroTik также предоставляет исходники, но делают это как полные мудаки.
          • –1
            ru.wikipedia.org/wiki/МСВС
            Знаете где получить исходные тексты модифицированного GPLv3 ядра Linux?
            • +5
              Как только куплю аппарат на MCBC, сразу вам отпишусь, дал мне производитель исходники или нет. А пока у меня нет прав их требовать.
              • –2
                Чисто технически по GPLv3 Вы можете запросить именно исходники ядра — и Вам их должны предоставить, в электронной форме точно.
                • +9
                  Чисто технически никто мне ничего не должен, поскольку у меня нет законно полученной скомпилированной версии программы, то и исходники на нее я не могу требовать. А то, что они там у себя ее используют и не открывают коды вовне, это их личное дело (Goobuntu вам, как пример, подойдет?).
                  • 0
                    у меня нет законно полученной скомпилированной версии программы

                    А в число законных способов получения программы под GPL разве не входит просто скопировать её откуда угодно?
                    • –1
                      Входит, если автор программы под GPL не указал обратного. Полная версия Qtiplot (c поддержкой скриптов и Ctrl+Z) вам, как пример, подойдет?
                    • +2
                      Это не значит, что можно влезть в окно к разработчику и скопировать ее с его личного компа, когда вам понадобится программа. Просто потому, что она под GPL. Он должен зарелизить ее на публику или продать вам.
                      • 0
                        Я о том, что любой купивший, на сколько я понимаю, имеет право распространять полнофункциональные копии (даром или по любой цене, какакой захочет, ничего не отчисляя автору), и любой, получивший такую копию, имеет право требовать и исходники (правда, вроде, не от исходного автора, а от того, от кого он получил копию программы, хотя, может, и от автора, не знаю точно этот момент).
                    • +1
                      Нет. GPL, грубо говоря, значит, только то, что получая программный продукт под лицензией GPL вы имеете право получить исходные коды программы под той же лицензией. GPL не обязывает выкладывать сорцы в публичный доступ и в ситуациях когда софт не распространяется (например внутренний корпоративный софт) — то эти требования вообще не вступают в силу.
            • +5
              Исходники есть у заказчика ОС МСВС — Министерства обороны.
            • +1
              Но ведь линукс распространяется под GPLv2.
              К тому же, как справедливо отметили выше, те, кто использует МСВС, вполне имеет доступ к исходникам.
              • 0
                Для Linux — да забыл, его таки не перевели на 3 версию, но вот OpenSolaris — под GPLv3
                • 0
                  Это не мешает Solaris быть закрытой проприетарной системой. Но тут сначала была курица, а только потом яйцо.
                  • 0
                    Поправка — форки OpenSolaris — например Illumos и SmarOS можно получить, также как и исходники оригинала. А вот Solaris распространяется под EULA — что собственно всегда и было.
    • +1
      Вебкит это то, что отвечает за отрисовку HTML. Отрисовываться страница должна у всех одинаково, от этого будет проще и пользователям и разработчикам. А вот фичи, не связанные непосредственно с отрисовкой, каждый волен реализовывать так, как ему хочется. К таким фичам относится например система расширений, управление жестами, каталоги закладок, менеджеры загрузок и т.д.

      Пользователь, выбирая браузер, в очень малом количестве случаев выбирает движок. Чаще всего он выбирает оболочку поверх этого движка, которые стандартизировать никто не собирается
      • +2
        Последние несколько лет шла война, кто больше тестов «на поддержку html5 и css3» пройдет. Причем зачастую в жертву количества шло качество.
        Сейчас все запросто может обернутся тем, что развитие html пойдет медленнее. Незачем же его развивать, кроме как для поддержки каких-то третьих продуктов, вроде рекламы или видеозвонков в g+.
      • 0
        Плюсую — рендеринг это одно, но есть еще движок JavaScript например. Safari и Chrome оба на WebKit, но у Safari движок JS это SquirrelFish/Nitro, а у Chrome — гугловский V8.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +8
    Вопрос к верстальщикам, поправите если не прав.

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

    А разве сейчас куча сайтов не зависит от какого нибудь бага IE? Мне казалось, что сайт верстается с поддержкой багов всех браузеров и получается, что если WebKit станет монополистом то придется учитывать баги одного браузера а не нескольких.
    • +3
      Если баг в браузере-монополисте, то все сайты вынуждены обходить его. Когда этот баг исправят, проблемы будут на всех сайтах и это никак не обойти.

      Сейчас, если исправят баг в каком либо браузере и из-за этого будут проблемы, то можно просто для этого сайта использовать другой.
      • +6
        ну не совсем так — у нас есть баг в IE — для конкретной версии IE делается хак — для остальных браузеров пишется «нормальный» код.
        Как только поправили в IE — в новой версии хак уже не работает — а работает нормальная реализация.
        Все довольны.
        • +2
          Если для IE, то да. Для IE можно делать хаки под конкретные версии. Для остальных браузеров такой возможности нет (или я не встречал).

          Т. е. если мы сделали хак под webkit (а это приходится делать нередко: несмотря на широту поддрежки css качество у него не очень), он будет работать под все версии, в том числе и после исправления. Поправьте меня, если есть другие способы.
          • 0
            Более того в IE есть режимы совместимости, благодаря которым даже в IE 10, можно запускать сайты написанные для IE 6-7.
            • –1
              Да только его надо принудительно включить — и кто это будет делать? Писать на сайте для IE10 — включите режим совместимости.
              Там правда есть какие-то директивы для включения режима по умолчанию, но… имхо это не выход.
              • +1
                Добавляете один мета-тег X-UA-Compatible и всё, IE сам всё переключит. Так что не мелите чушь про «писать на сайте». Более того для старых сайтов без доктайпов этот режим включается автоматом.

                Ведь существует не только проблема того, что нужно поддерживать старые браузеры на новых сайтах, но и новые браузеры должны поддерживать старые сайты.
          • 0
            Можно по UA определять браузер и его версию и добавлять класс .chrome22 с помощью JS, а после опираться на него в CSS или JS.
      • –3
        Я думаю что даже сейчас доля webkit достаточно большая для того чтоб не использовать другую технологию, а поправить на сайте то что вылезло.
      • –2
        О каких проблемах идет речь? Они починят баг и сломают функционал, который помог обойти проблему? Из воздуха просто взято мне кажется. Сталкивался с подобной проблемой в вебките, хоть баг и починили, но у меня никаких проблем не возникло.
        Что значит можно использовать другой? Это какая-то новая политика разработчиков сайтов. Так и писать на главной, «Привет сейчас в хроме баг поюзай фаерфокс!» Или речь идет о эксперементах с новейшими фичами, которые интересны только гикам?
    • +1
      Именно об этом говорит опыт IE6. Например, блок с заданной шириной или высотой оборачивал плавающие блоки. Лишь несколько лет назад началось избавление от этого наследия, и сейчас такие сайты выглядят анахронизмом.
  • +26
    Кажется, высосано из пальца.
  • +8
    Непонятно, почему все забывают, что абсолютно все вендоры форкают WebKit для разработки своих браузеров. Это убивает половину пунктов сходу.

    Баги веб-платформы? Вспомните, сколько раз уже возникала ситуация, когда бага на уровне движка была в Safari и отсутствовала в Chrome (ровно, как и наоборот).

    «Предотвращение инноваций» — и снова, сравните Safari / Chrome по скорости внедрения «новинок».

    «Чрезмерный контроль» — попробуйте ввести DRM с таким количеством вендоров-участников с их осознанием среды / аудитории и прогнозируемой реакцией последней. Mission impossible.

    «Сложность и непредсказуемость» и «Путаница» — просто высосаны из пальца.

    То, что сейчас происходит — абсолютно естественный процесс. Его нельзя форсировать (говоря о WebKit-стандарте), нельзя обелять или очернять целиком. Opera, как мне кажется, совершила чуть более, чем полностью правильный шаг.
    • +5
      «Чрезмерный контроль»
      Google, Apple и другие маинтейнеры WebKit договариваются и вносят коммит в мастре бранч — все :) [, это может быть преподнесено под соусом «для блага пользователей»]
      • –2
        Это возможно в Safari/Chrome. В WebKit(есть такой браузер, аналог Chromium)/Chromium это не включат.
        Или как всегда будут форки на подобие Iron.
    • +1
      Баги веб-платформы? Вспомните, сколько раз уже возникала ситуация, когда бага на уровне движка была в Safari и отсутствовала в Chrome (ровно, как и наоборот).
      Ага, и возникала потому что либо в Сафари была более старая версия движка, либо, наоборот, баг свежий, и в Сафари его ещё нет. Например, я сталкивался с глюком масштабирования фонового изображения (на масштабе 110%). Сначала он был только в Хроме, а потом воспроизвёлся и в шестом Сафари.
      «Предотвращение инноваций» — и снова, сравните Safari / Chrome по скорости внедрения «новинок».
      Внедряют быстро, действительно так бывает. Но очень сыро. Почему та же Опера исправляет баги с колонками? Спецификации уже много лет.

      Так что форки форками, а не всё так идеально.
  • +2
    Про хакеров очень слабо понял пример.

    И в частности:

    > 80%, дело сделано, хакеры пошли писать социальную сеть для домашних птичек.
    • +1
      Видимо, имелось в виду, что если браузер поддерживает всего 80% сайтов (т.е. не поддерживает каждый пятый сайт), им перестанут пользоваться.
    • +10
      Там перевод слишком ализаровский. На самом деле:

      Группа хакеров создаёт новый браузер, который равномерно загружает все сто ядер обычного для 2018 г. лаптопа, в отличие от существующих браузеров, требующих по ядру на каждую открытую вкладку. Они переписали всё ядро браузера, и в результате их героического труда новый браузер поддерживает 99% веб-сайтов. Нет, уже 98%: в webkit только что добавили новую фичу, и все её сразу же начали использовать в своих сайтах (а чего ждать?) Оппа, уже 90%: в новом webkit обнаружился баг, который нарушает работу с потоками. Что, уже 80%? Что случилось? Выпускайте этот браузер как можно скорее, пока ещё не всё потеряно! Группа хакеров опускает руки и идёт писать социальную сеть для домашних птичек.
      • +1
        Спасибо, все стало на свои места, перевод в статье и впрямь кривоват.
    • –2
      Вот глупые хакеры. Не догадались баг исправить.
  • +1
    Просто у кого-то появился очень сильный конкурент, вот и заворчали.
  • –6
    А мне вот кажется, что «монокультура» это здорово, и, что опасения господина Флинка высосаны из пальца.
    Я очень давно мечтаю забыть слово «кроссбраузерность» и думаю, что «монокультура» этому способствует!
  • +5
    Стив Флинк == Steve Fink?
    Почему не указано, что это перевод? больше 70% поста это перевод.
    • –3
      Сорри, что-то глюкануло, исправил Финка. Насчет перевода, нельзя указать на перевод, котрой покрвывает меньше 100% поста, да это и не принято считать переводом, это типа вкрапления цитат. :)
      • +4
        Вообще-то по-хорошему надо дать ссылку на оригинальную статью Стива Финка.
  • –2
    Стив Флинк просто очкует за мобильную ось от Мозиллы. По сути осталось 2 платформы. IE можно не считать — да, с ним считаются, под него пишут костыли, но разрабатывать на его основе что-то никто не собирается. А мозилла остается в подавляющем меньшинстве.
    • +4
      Это Вы скажите куче ентерпрайзных приложений, особенно в конторах где запустить/установить другой броузер запрещается политиками безопасности. GPO и подписями. И приложения, у которых ActiveX компонентов может быть не один десяток.
      Не считая уже того, что под IIS'ом живет куча сайтов из TOP100, недавно пробегала даже статистика с примерами — черта с два скажешь, что это сделать на Asp.Net'е.
      • +1
        IIS никак с IE не связан, можно и на IIS хостить сайт, который не будет отображаться в IE. Ентерпрайзерные приложения конечно имеют свой кусок в пироге. Но речь шла прежде всего о рядовых пользователях, которым кроме порнушки и пукающих котов вконтакте по сути больше ничего не надо.
        • 0
          половина из них вообще не парится и пользуется как раз таки ие для того же вконтактика, если им кто-то из продвинутых друзей не посоветует альтернативу
  • +1
    Это напоминает мне ситуацию с ядром Linux. Есть один открытый проект. Над ним работает множество компаний. Но при этом собрать ядро можно с миллионом разных конфигураций. И у каждого дистрибутива ядро Linux своё.
    Полагаю с WebKit ситуация будет похожая. Поддержка тех или иных фич (файловых систем, специфичного железа) в ядре Linux реализуется в модулях. Думаю в Webkit со временем появятся подключаемые модули для поддержки 3d-video, CSS6, HTML7.
  • +15
    Бред пожилого клопа.

    Почему? — Потому…

    Что имеем сейчас:

    В HTML:
        <meta http-equiv="X-UA-Compatible" content="IE=9">
    


    … несколькими строками ниже:
        <!--[if IE 9]>
        <link rel="stylesheet" href="css/iehacks.css" type="text/css" rel="stylesheet">
        <![endif]-->
        <!--[if lte IE 8]>
        <style>
        * html div.gradientBackground {
            position: absolute;
            z-index: 0;
            left: 0px;
            top: expression( parseInt( document.documentElement.scrollTop + document.documentElement.clientHeight - this.offsetHeight , 10 ) + "px" );
        }
        </style>
        <![endif]-->
    


    Теперь CSS:
    div.gradientBackground {
        position: fixed;
        width: 100%;
        height: 100%;
        top: 0px;
        left: 0px;
        background: #444948;
        background: url(data:image/svg+xml;base64,/* длинная строка в base64 */);
        background: -moz-linear-gradient(top,  #444948 0%, #404042 25%, #363e3c 50%, #31343e 75%, #272d3b 100%);
        background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#444948), color-stop(25%,#404042), color-stop(50%,#363e3c), color-stop(75%,#31343e), color-stop(100%,#272d3b));
        background: -webkit-linear-gradient(top,  #444948 0%,#404042 25%,#363e3c 50%,#31343e 75%,#272d3b 100%);
        background: -o-linear-gradient(top,  #444948 0%,#404042 25%,#363e3c 50%,#31343e 75%,#272d3b 100%);
        background: -ms-linear-gradient(top,  #444948 0%,#404042 25%,#363e3c 50%,#31343e 75%,#272d3b 100%);
        background: linear-gradient(to bottom,  #444948 0%,#404042 25%,#363e3c 50%,#31343e 75%,#272d3b 100%);
        filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#444948', endColorstr='#272d3b',GradientType=0 );
    }
    


    … несколькими строками ниже:
    /* FF fix */
    @-moz-document url-prefix() {
        div.main-content-block-second-header ,
        div.main-content-block-first-header {
            font-family: Arial, sans-serif;
            font-weight: bold;
        }
    }
    


    Про различия в JS говорить не буду, т.к. к WebKit'у они отношения не имеют.

    Что же мы будем иметь в исходниках при условии наличия WebKit в качестве стандартной базы для рендера html в браузере?

    Пример с теми же исходниками, что привёл выше.

    В HTML:
        <link rel="stylesheet" type="text/css" href="css/style.css">
        <script type="text/javascript" src="js/init.js"></script>
    


    В CSS:
    div.gradientBackground {
        position: fixed;
        width: 100%;
        height: 100%;
        top: 0px;
        left: 0px;
        background: linear-gradient(to bottom,  #444948 0%,#404042 25%,#363e3c 50%,#31343e 75%,#272d3b 100%);
    }
    


    Если же обнаруживается какой-то баг в WebKit с отступлением от стандартов до какой-то определенной версии — задаём условие в init.js:
    function getWebKitVersion(){
        var version = 0;
    
        var regexp = /Safari\/([\d.]+)/;
        var result = regexp.exec(navigator.userAgent);
    
        if(result) {
            version = parseFloat(result[1]);
        }
        
        return version;  
    }
    
    $( document ).ready(function(){
        if ( getWebKitVersion() < 537.17 ){
            var ss  = document.createElement( "link" );
            ss.type = "text/css";
            ss.rel  = "stylesheet";
            ss.href = "537_17_hack.css";
            document.getElementsByTagName( "head" )[0].appendChild( ss );
        }
    });
    


    Всё. Проблемы нет. Код проще. Код понятнее. Поправили багу в вебките? — Хак не подгрузился и всё.

    Если я не прав — пинайте ногами, но… Переход на WebKit — это благо для цивилизации. К тому же, то, что WebKit будет использоваться в качестве базы, совершенно не отменяет того, что в каждом конкретном браузере будут собственные уникальные фичи. Пример с Сафари и Хромом — в хроме по-дефолту WebGL включен, в Сафари — нет. Оба на базе WebKit.

    Делаем выводы. :)
    • +1
      Товарищи, если минусите — объясняйте, в чём не согласны или в чём я не прав. А то как-то не хорошо.
    • +11
      1. Экспрешны для IE пишут только очень глупые и неопытные люди. Настоящие разработчики используют изящную деградацию.
      2. Для градиентов можно смело отбрасывать:
        • SVG;
        • старый синтаксис Webkit;
        • префиксы -moz- и -o-: давно отброшены, старые версии браузеров неактуальны;
        • префикс -ms-: никогда не существовал в стабильной версии браузера;
        • фильтры IE: тормозят браузер (и без того небыстрые старые IE), портят сглаживание шрифта;
        • to bottom или top можно не писать — это направление градиента по умолчанию.
        в итоге можно оставить лишь сам градиент, вариант для деградации (картинка или цвет фона) и префикс -webkit-.
      3. Не представляю, зачем вам понадобился хак для Файрфокса. У него есть особенности, но обычно они исправляются Firefox-специфичными псевдоклассами.

      Вы сильно преувеличиваете.
      • –3
        Разве моё преувеличение сильнее, чем преувеличение и теория заговора в статье?

        Почему-то на ум пришла аналогия, как когда-то, во времена готичного черного доса, в коде было необходимо поддерживать тонну разнообразного железа, чтобы всё работало адекватно на разнородных системах. Потом пришли DirectX и OpenGL+OpenAL. Развитие технологий не остановилось.

        Когда-то, во времена, когда компьютеры были большими, каждый процессор имел свой набор инструкций. Потом пришёл 8086 и началась эпоха x86. Развитие технологий не остановилось.

        Когда-то, давным давно не было IBM-совместимых компьютеров…

        С оглядкой на эти истории у меня возникает резонный вопрос: почему же переход на WebKit сулит нам стагнацию в развитии веб-технологий и пахнет катастрофой?

        Не очередной ли это виток закономерного развития, когда куча разрозненных и обособленных разработок, а так же компаний, которые эти самые разработки поддерживают, объединяются и общими усилиями начинают двигаться в ОДНОМ направлении вместе?

        Как мне кажется, преувеличение в этой статье, вкупе с теорией заговоров, гораздо более спекулятивное, чем мой пример с перегнутой палкой в CSS (зато ярко).

        В конце-концов, WebKit — проект открытый.

        Не нравятся варианты, которые предлагают вендоры? — Возьми, да собери свой. И собери его не с нуля, а с использованием тонны кода высококвалифицированных разработчиков от крупных вендоров, которые этот проект поддерживают.

        Нравятся варианты, которые предлагают вендоры, но чего-то нехватает? — Собери свой с нужным функционалом. В качестве примера могу привести проект Роджера Вонга, который взял WebKit и привинтил к нему Node.js: github.com/rogerwang/node-webkit

        Не вижу совершенно никакой проблемы.
        • +5
          В целом, да, преувеличение сильнее. Вот вы говорите, Webkit — проект открытый, и сами до этого приводили пример с хаком для Вебкита. А почему он всё ещё нужен, если проект открытый? В этом вся и штука.

          И в DirectX отсутствуют вещи, которые есть в OpenGL, а эмуляция обходится слишком дорого. Более того, с этим уже сталкиваются браузеры в реализациях WebGL, так как далеко не у всех пользователей есть драйвера с хорошей поддержкой OpenGL. Вот вам и стандартизация.

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

          Не очередной ли это виток закономерного развития, когда куча разрозненных и обособленных разработок, а так же компаний, которые эти самые разработки поддерживают, объединяются и общими усилиями начинают двигаться в ОДНОМ направлении вместе?
          Вы читали статью? Хотя бы первый пункт? Там ещё про баги говорится.

          Не нравятся варианты, которые предлагают вендоры? — Возьми, да собери свой. И собери его не с нуля, а с использованием тонны кода высококвалифицированных разработчиков от крупных вендоров, которые этот проект поддерживают.
          Это вы веб-разработчикам говорите? У них другая специализация.

          Не вижу совершенно никакой проблемы.
          Попробуйте перечитать статью и осмыслить. Судя по комментарию, вы её недопоняли.
          • –3
            Возможно, недопонял. Или понял как-то по-своему.

            Сохранение багов ради обратной совместимости? — Это да, это перспектива плачевная. Но тем не менее, выше в комментариях уже писали на примере того же Хрома и Сафари, когда какой-то баг есть только у одного из них.

            Взглянем на потенциальную проблему с другой стороны (допустим, переход на WebKit состоялся, кроме старого доброго IE — чтобы перешёл он нужно, наверное, второе пришествие): есть куча браузеров, которые реализуют, например, 95% рекомендаций HTML6 и CSS4, а напротив них есть семейство IE, которое только-только осилило HTML5 и CSS3… Что останется делать MS? — Правильно, догонять и перегонять.

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

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

            Если я правильно понял статью (поправьте, если нет), то суть её сводится следующему: отсутствие конкуренции и наследование багов ради обратной совместимости, тотальная слежка за всеми и пресечение инноваций. Вот этого, на мой взгляд, точно не будет, потому что крупные игроки никогда на пойдут на то, чтобы быть равными — для выживания в бизнесе необходимо развитие, а без конкуренции в развитии нет смысла.
            • +5
              На мой взгляд, конкуренция сохранится до тех пор, пока существуют хотя бы 2 базы для браузеров. И конкуренция эта будет тем ожесточенней, чем более крупные игроки будут выступать с обеих сторон.
              Уже было. См. Netscape vs. Internet Explorer.

              Дело было так: один браузер изобретал какую-то штуку, например, тег img или фреймы. Спустя некоторое время второй внедрял у себя тоже, куда деваться. Первая реализация была с недостатками, и все к ним адаптируются. Второй вынужден копировать эти недостатки. Это и есть к слову та самая обратная совместимость багов.

              Мы до сих пор имеем некоторые последствия тех времён. На стандарты в такой ситуации всем плевать. В итоге получаем трудноперевариваемую кашу из технологий. Те же фреймы живут до сих пор, только в HTML5 от них отказались.

              Если я правильно понял статью (поправьте, если нет), то суть её сводится следующему: отсутствие конкуренции и наследование багов ради обратной совместимости. Вот этого, на мой взгляд, точно не будет.
              Ваше мнение понятно, только оно ниоткуда не следует, учитывая написанное мною выше.
              • –2
                Хорошо… Раз сейчас происходит абсолютно то же самое наследование багов (с добавлением щепотки своих) и наплевательство на стандарты, то чем тогда плох переход на единую платформу? — В этом случае хотя бы новые баги не будут появляться, при попытке скопировать баги чужие…
                • +2
                  Где это сейчас происходит наследование багов? Наоборот, всё стандартизуется, браузеры постепенно внедряют стандарты и потихоньку исправляют дефекты.
                  • –2
                    Вы меня почти переубедили.

                    Не переубедили только в том, что переход оперы на WebKit — это плохо.

                    Было 4 «стороны конфликта»: Chrome+Safari vs. Firefox vs. IE vs. Opera

                    Стало 3: Chrome+Safari+Opera vs. Firefox vs. IE

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

                    Я веду к тому, что конкретно ЭТО — хорошо.
                    • +2
                      А я нигде такого не утверждал. Есть определённые риски, вот об этом и речь. Что в итоге получится, покажет время.
                • +4
                  Получим ситуацию, аналогичную IE. На стандарты плевать, потому что «лучший валидатор — это браузер».

                  История уже знает много примеров, когда доминирование одной платформы приводило к стагнации. А платит за это все — веб-разработчик.
                  • 0
                    А точнее, его работодатель. :)
                    • 0
                      Да. Под веб-разработчиком понимается не отдельная личность, а компания.
  • –2
    Все те, кто пишут такие статьи, забывают, что WebKit — это не движок, а набор абстракций, оставляющих очень много возможностей для конкретной разработки («порт» в терминах WebKit). Т.е. проблема монокультуры — это в целом валидная проблема, но WebKit здесь — исключение.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.