Dlaczego finalizacja specyfikacji HTML 5 zajmuje tyle czasu? [Zamknięte]

Czytałem to i jedno zdanie przykuło moją uwagę (moje podkreślenie):

Ian Hickson, największy krytyk XHTML, był ojcem HTML 5, zorientowanej na akcję specyfikacji malucha, która nie osiągnie dorosłości do 2022 r. , Choć niektóre z nich można dziś wykorzystać.

Czy to prawda? Czy to naprawdę cykl programowania HTML 5? Dlaczego to trwa tak długo? Co sprawia, że ​​tak trudno jest zrobić to dobrze, że nie będzie to ostateczne aż za 11 lat?

Data wspomniana w procesie finalizacji została ustalona tak daleko w przyszłość, ponieważ proces standardów dla specyfikacji HTML został skonfigurowany w taki sposób, że gwarantował szeroką akceptację specyfikacji.

Trochę tła: istnieją dwa ciała normalizacyjne, które pracują nad wersjami roboczymi związanymi z tym, co powszechnie nazywamy „HTML5”: konsorcjum World Wide Web Consortium (W3C) i grupa robocza ds. Technologii hipertekstowej Web Application (WHATWG). Przed lipcem 2012 r. Obie grupy pracowały (głównie) razem nad rozwojem HTML.

Głównym procesem było przejście przez serię kamieni milowych:

• Roboczy projekt:  specyfikacja jest w trakcie aktywnego rozwoju i dyskusji
• Wersja robocza ostatniego wezwania (LCWD): specyfikacja jest w większości kompletna, a realizatorzy mają możliwość zgłoszenia jakichkolwiek ostatnich zastrzeżeń do specyfikacji, zanim wejdzie ona w proces finalizacji
• Kandydat Zalecenie:  Spec skutecznie sfinalizowane i bezpieczny w użyciu dla implementors i autorów treści
• Zalecenie: dwa niezależne, w pełni interoperacyjne wdrożenia specyfikacji zostały w pełni ukończone

Kamień milowy LCWD rozpoczął się w 2011 r., A faza rekomendacji dla kandydatów miała nastąpić stosunkowo niedługo w 2014 r. Był to ostatni kamień milowy, zalecenie, które wymagało dwóch pełnych wdrożeń specyfikacji, co zajęłoby kilka lat i jest przyczyną 2022 r. data.

W tym modelu pierwszym prawdziwym kamieniem milowym, które dotyczyło autorów treści (nie twórców agentów użytkownika, takich jak przeglądarki) była LCWD, ponieważ specyfikacja miała być w większości sfinalizowana. Po ukończeniu LCWD HTML5 osiągnąłby kamień milowy Rekomendacji dla kandydatów i byłaby ostateczną specyfikacją z wyjątkiem nazwy: byłbyś w stanie wdrożyć go bezkarnie, ponieważ ostatni etap, Rekomendacja, nie mają wpływu na treść standardu i są w dużej mierze nieciekawe dla autorów treści.

Jednak w lipcu 2012 r. W3C i WHATWG sformalizowały podział na sposób opracowania wersji roboczej HTML5. Ten podział, który funkcjonuje od kilku lat, tworzy dwie różne „ścieżki” HTML:

• Standard życia opracowany przez WHATWG i zwany po prostu „HTML”, w którym specyfikacja nigdy nie jest w pełni kompletna. Ustanowiono rozsądny konsensus w sprawie normy, ale nie ma wymogu wdrożenia wszystkiego.

• Okresowe, stabilne migawki standardu opracowanego przez W3C jako specyfikację HTML5. We wrześniu 2012 r. W3C proponuje osiągnięcie kamienia milowego zalecenia dotyczącego „HTML 5.0” w 2014 r., Z migawkami punktów co dwa lata (np. „HTML 5.1” w 2016 r.).

Ze względu na to pierwsze, HTML5, tak jak go zrozumieliśmy, jest teraz użyteczny . Niestety, ponieważ jest to standard życia, używanie go jako autora treści wymaga zrozumienia implementacji każdego agenta użytkownika.

Prosta odpowiedź: Projekt opracowany przez komitet

Zaletą tłumu ludzi spoglądających na projekt jest to, że cała grupa wymyśli różne aspekty, o których nie pomyślał pierwotny projektant. To plus.

Kiedy projektant jest dużym tłumem, wszyscy mają różne programy i zwierzaki, które chcą dostać się do normy z jakiegokolwiek powodu. Czasami cechy są ze sobą sprzeczne, czasem polityka wiąże się z decyzjami itp. Osiągnięcie porozumienia przez dużą grupę ludzi zajmuje dużo czasu. To jest minus.

Na lepsze lub gorsze, W3C zdecydowało się na opracowanie swoich standardów w ten sposób.

Ponieważ krytyczne jest, że ma rację.

• Potrzeba czasu, aby wszystko było w porządku - raz ustawiony standard HTML5 będzie dostępny przez długi czas. Musi być jak najlepszy i musi mieć rację. Wymaga to debaty ekspertów, prób i błędów, wkładu użytkowników i programistów oraz analizy statystyk

• Kiedy zmienia się standard, czyjaś aplikacja gdzieś się psuje - Standardy muszą być poprawne za pierwszym razem. Z każdą zmianą standardu czyjaś aplikacja gdzieś na świecie zrywa się z nową wersją. To wymaga od nas, jako programistów, naprawy, co kosztuje czas i pieniądze. Za pierwszym razem musi mieć rację.

• Niejasność musi zostać usunięta - Łatwo powiedzieć, że tak właśnie działa tag canvas, gdy na stronie jest tylko tag canvas, ale co z tym, kiedy znajduje się w innym tagu? Co z kombinacjami tagów? Jak powinni renderować? Jak powinny się renderować z atrybutami stylu X ustawionymi w poszczególnych kombinacjach?

Premia: spójrz na specyfikację HTML5 w jej obecnej formie, a zobaczysz, co się w nią dzieje.

Długie? Prawie 8 lat zajęło microsoftowi, aby prosty CSS2 prawie nie działał w IE7, podczas gdy obsługa DOM1 w javascript jest nadal zepsuta w IE8. To specyfikacja z 1998 roku.

Dlatego w ciągu najbliższych 20 lat nie zobaczysz szerokiego zastosowania HTML5 w multimediach. To bardzo skomplikowane, niedokończone, wydajność jest do kitu. Nawet proste rzeczy, takie jak gniazda sieciowe, są wyłączone ze względów bezpieczeństwa.

Niektóre rzeczy nie będą działać jako otwarte standardy. Czy gry lub MM w środowisku, które powinny działać na cienkim kliencie i wspierać pełną degradację? To szaleństwo.

ZMIENIONO: Tak, pierwszy to nadmierna komplikacja. Masz jedną wtyczkę flash, która jest taka sama w każdej przeglądarce i działa tak samo za każdym razem. To proste i skuteczne rozwiązanie. Jeden interfejs, raz dokonujesz zmiany, rekompilujesz i viola - masz wtyczkę do wszystkich przeglądarek na rynku, wykorzystując warstwę pośrednią między przeglądarką a wtyczką.

Z drugiej strony masz 10 przeglądarek i chcesz dodać np. obsługa multimediów / filmów. Oznacza to, że każda firma będzie musiała wdrożyć odtwarzacz multimedialny od zera, a każdy chce czegoś innego. Apple chce H.264, więc właściciele witryn zapłacą tantiemy za kodek do odtwarzania filmów, Google i Mozilla chcą VP8, aby ich firma nie miała wpływu na patenty Apple itp.

Tak więc kończy się to wdrażaniem rzeczy, których wszyscy chcą (na początek zrobiliby to VP8 lub H.264).

Aby więc przezwyciężyć różnice, Adobe zaimplementuje H.264 we flashu, użyje dostępnego już strumieniowania i stosu DRM i ... będzie gotowy. 3-4 miesiące i masz działającą technologię ze współczynnikiem adopcji 98%.

To proste, decyduje jedna firma, dzięki czemu mogą szybko wprowadzać ogromne zmiany i nie będą musieli dodawać „pomysłów” 20 innych członków „ciała standaryzującego”. Oprócz HTML5 jest może 10-15 lat za flashem w multimediach. Różnica będzie się powiększać. W najnowszej wersji MAX avant można było zobaczyć obsługę kontrolerów gier i pełnoekranowe aplikacje wyścigowe 3D, działające z lampą błyskową w pełnym FPS, wsparcie przyspieszania sprzętowego i tak dalej. Tymczasem mozilla może teraz odtwarzać wideo H.246 bez awarii przeglądarki, ale tylko odtwarzać. Wciąż brakuje jakiejkolwiek dodatkowej funkcjonalności (takiej jak pełny ekran, przesyłanie strumieniowe, szybkie przewijanie do przodu)!

Poza tym myślę, że W3C marnuje zasoby, próbując uczynić HTML5 jakąś częściowo wypaloną kopią flasha. To nie zadziała ... to jak próba zrobienia Flasha kopią HTML. Nie zadziała

Zasadniczo nakłonienie grupy ludzi do uzgodnienia czegoś jest raczej trudne. Nie wspominając o tym, że istnieją różne problemy do rozwiązania. Na przykład trwa (była?) Debata na temat tego, jakiego kodeka użyć do wideo.

Na lepsze lub gorsze, większość specyfikacji potrzebuje trochę czasu, aby się wykręcić.

Mark Pilgrim mówi o tym w swoim „Dive Into HTML5” tutaj: http://diveintohtml5.org/past.html Wydaje się, że wiele osób nie lubi wersji książkowej, ponieważ nie jest wystarczająco techniczna, ale w tej sekcji Redakcja jest dość uzasadniona.

(Edycja: Chciałem tylko podać odniesienie do mojego komentarza na temat osób, które nie lubią „gadatliwej” jakości książki: sprawdź recenzje na amazon . Osobiście podobało mi się czytanie i uważam, że ma ona charakter informacyjny, więc przebieg może się różnić. )

Część problemu polega na tym, że specyfikacja nie zostanie sfinalizowana, dopóki nie będą co najmniej dwie główne implementacje specyfikacji - co najmniej dwie oddzielne przeglądarki w pełni ją obsługujące. Tak więc specyfikacja musi być wystarczająco kompletna do pełnego wdrożenia, następnie musi zostać faktycznie wdrożona, a następnie można ją sfinalizować.

Część problemu: Chcę ogg theora w przeglądarce. Czy sie zgadzasz? Nie. Chcesz H.264. Ale czy się zgadzam? Nie. To jest problem między Google, Mozillą, Microsoftem, Apple, Adobe i wszystkimi korporacjami grającymi za HTML 5. Starają się maksymalizować przychody i być monopolistą. Jego intensywna konkurencja. To trwa dłużej.