Microsoft: WebKit zatrzymuje rozwój standardów i innowacje w Sieci

Firma Microsoft broni standardów sieciowych — taka szokująca wiadomość niedawno obiegła świat IT. Obrońca już jest, oskarżony również, ale o co w tym wszystkim chodzi?

Można by w tym momencie przytoczyć wiele mądrości ludowych, można przytoczyć dzieje pierwszej wojny przeglądarek i jej wpływu na strony internetowych. Ale przecież nie jesteśmy aż tak wredni, aby wytykać błędy popełnione w przeszłości, prawda? Dziś Microsoft jest inną firmą. Teraz dba się o to, aby twórcy aplikacji mogli obejść się bez pisania kodu pod konkretne przeglądarki. Są tego tak pewni, że z IE 10 usunięte zostały komentarze warunkowe. To jednak nie wystarczyło, aby strony dobrze się wyświetlały w Internet Explorerze. Postanowiono wskazać winnego obecnego stanu rzeczy: silnik WebKit — brzmi znajomo, prawda?

WebKit zyskał na popularności w momencie, gdy projektem zainteresowało się Google. Tempo rozwoju projektu wtedy znacząco wzrosło. Praca była owocna, pojawiła się cała garść nowych technologii, które były implementowane w ramach tzw. prefiksów producenckich (-webkit-*). Nie ma w tym niczego złego, ponieważ takie są założenia CSS. Świat twórców witryn zalany został poradnikami jak stworzyć fantazyjne strony z animacjami, których nie powstydziłby się Adobe Flash. Oczywiście takie strony działały tylko pod WebKitem. Duży problem powstał gdy Google Chrome oraz Safari zdobyły łącznie ogromną popularność.

Obecnie te przeglądarki odpowiadają za nieomal połowę wszystkich odwiedzin w Stanach Zjednoczonych (Statcounter, Listopad 2012). Obraz zmienia się diametralnie, gdy weźmiemy pod uwagę jedynie przeglądarki na smartfonach. Wtedy dominacja produktów opartych na WebKicie powiększa się do ponad 85 procent. Poza Operą, inne przeglądarki praktycznie nie istnieją. Mobilna wersja IE jest jak Yeti — już dawno nikt nic nie słyszał (możliwe, że Windows Phone 8 coś w tej kwestii zmieni), a Mozilla nie potrafi przekonać skutecznie większej rzeszy użytkowników do swojej przeglądarki.

Duża (gigantyczna?) popularność jednego silnika ma negatywny wpływ na sieć. Twórcy stron i aplikacji internetowych „zapominają” o innych przeglądarkach i korzystają jedynie z prefiksów odpowiednich dla WebKita (np.-webkit-border-radius), zapominając kompletnie o zaimplementowaniu podstawowej, standardowej wersji. Jeszcze większy problem może powstać przy obsłudze zdarzeń dotykowych. W IE 10 zaimplementowany został interfejs Pointer Events, który teoretycznie jest alternatywą dla Touch Events — zgłoszonego do prac w W3C i który już uzyskał status kandydata do rekomendacji. Microsoft oczywiście swój interfejs również zgłosił do W3C, choć dopiero we wrześniu, miesiąc po wydaniu wersji RTM Windows 8. Wszystko wskazuje jednak na to, że W3C będzie chciało połączyć oba interfejsy w jeden.

Na zbyt duży udział WebKita wcześniej w tym roku narzekały Mozilla i Opera, dla których problem z nowymi właściwościami w CSS3 dosłownie rzuca się w oczy. Produkty obu firmy muszą się mierzyć z opinią, że to WebKit jest bardziej innowacyjny. Taka pozorna, niczym w tej chwili nie poparta opinia sprawia, że w znakomitej większości poradników i przewodników po nowościach w CSS3 dominuje prefiks producencki dla WebKita, mimo iż MSIE, Firefox i Opera równie dobrze mogłyby sobie z własnościami poradzić.

Opera ostatnio posunęła się do tego stopnia w walce o twórców aplikacji, że ich najnowsza wersja przeglądarki bez dodatkowych modyfikacji obsługuje część właściwości stworzonych dla WebKita. Microsoft próbuje w inny sposób rozwiązać problem powstałego bałaganu: proponuje, aby aplikacje internetowe — tam, gdzie jest to możliwe — same dostosowywały się do konkretnej przeglądarki.

Trudno tutaj nie odmówić korporacji z Redmond racji. Celem nadrzędnym jest dotarcie do jak najszerszego grona odbiorców, a pobocznym to, aby nie tworzyć zbędnego kodu. Warto się zainteresować rozszerzeniem Web Essentials dla Visual Studio, które znacznie ułatwiają pracę z takim kodem.

Sytuacja, która ma miejsce teraz na rynku przeglądarek internetowych, jest efektem zarówno szybkiej implementacji nowinek w kolejnych wydaniach WebKita, rozdźwięku w cyklach rozwojowych przeglądarek oraz braku możliwości aktualizacji do IE 10 dla użytkowników Visty czy XP. To nie sam WebKit (ani pomysłowość jego twórców), a raczej powolne prace W3C, które utrudniają standaryzację, są tutaj problemem. Tymczasem twórcy przeglądarek muszą ścigać się z potrzebami swoich użytkowników, którzy chcą dynamicznych, multimedialnych stron internetowych.

Wróćmy jednak do początku tego wieku. Należy pamiętać, że problem z Internet Explorerem 6 zrodził się nie w momencie jego premiery, a kilka lat później, wskutek zaniedbań w cyklu wydawniczym tego produktu. Podobnie jest z WebKitem — póki WebKit jest intensywnie rozwijany, a przeglądarki są często aktualizowane, to nikt nie obudzi się z ręka w nocniku. Tylko czy warto ryzykować stworzenie drugiej, podobnej w skutkach sytuacji?