Czego sobie życzyliśmy

Myślę, że czeka nas kłopot, choć nie mogę powiedzieć tego na pewno. Kłopoty — kłopoty, które znam . Jednak rampa do niej; Tylko o tym słyszałem. Robię to dopiero od dziesięciu lat. Ostatnim razem przegapiłem wszystkie przygotowania. To, co mogę powiedzieć na pewno — to, co wiem z doświadczenia — to to, że nigdy nie spełniło się moje życzenie w gniewie, nie żałując tego.

Dziesięć lat (nie mam nic przeciwko temu) to dość długi czas. Kiedy po raz pierwszy udałem się na staż w zakresie projektowania stron internetowych, stary dobry Internet Explorer był już pośmiewiskiem.

„Jeśli zauważysz, że fragment Twojej treści pojawia się i znika, a sekcje strony są rysowane tylko w połowie, są to dobre wskazówki, że element wymaga układu. [...] Poprawka hasLayout obejmuje jedynie zadeklarowanie właściwości CSS, która powoduje, że element uzyskuje układ, podczas gdy zwykle nie miałby układu domyślnie.”

— Internet Explorer ma właściwość Layout

Nienawidziłam IE. Czuję, że teraz mogę sobie z tym poradzić. starałem się nie; Naprawdę, szczerze. Powiedziałbym ludziom, że fajnie było wspierać, jeśli możesz w to uwierzyć.

Ponieważ wszystkie inne przeglądarki stawały się coraz łatwiejsze w obsłudze, próbowałem przekonać siebie, że wciąż istnieje wyzwanie dla dziwacznego starego IE. Stało się to nawet powodem do dumy: stałem się tak dobry w rozwiązywaniu niejasnych problemów z IE, że nauczyłem się ich unikać w trakcie mojego codziennego rozwoju, nie pozostawiając nic (no cóż, mniej) do przerażenia go w IE i zobacz, co się zepsuło”.

W pewnym sensie to zabawne. Zabawa . To było kłamstwo, które sobie powtarzałam.

 /* Fixes #2588: When Windows Phone 7.5 (Mango) tries to calculate a numeric opacity for a select (including “inherit”) without explicitly specifying an opacity on the parent to give it context, a bug appears where clicking elsewhere on the page after opening the select will open the select again. */

— jQuery Mobile źródło

Nienawidziłem tego. Nienawidziłem IE, w każdym z jego wcieleń. Nienawidziłam tego tak samo jak wszyscy inni.

„Internet Explorer 6 ma zagadkowy błąd dotyczący wielu pływających elementów; znaki tekstowe z ostatniego elementu pływającego są czasami duplikowane poniżej ostatniego elementu pływającego. ... Bezpośrednią przyczyną jest nic innego jak zwykłe komentarze HTML, takie jak <!-- end left column --> , umieszczone pomiędzy pływakami, które pojawiają się w sekwencji.”

— Błąd zduplikowanych postaci Explorer 6

To była strata mojego cholernego czasu. Wszystkie te godziny, które spędziłem zgarbiony nad niestabilną maszyną wirtualną — przeładuj, czekaj, wrzuć bezsensowną poprawkę do bezsensownego błędu, przeładuj, awaria , ponownie otwórz IE, czekaj, dwukrotnie sprawdź, czy buforowanie nie było czynnikiem, przeładuj, czekaj, i powtórz. Mogłem zrobić o wiele więcej w swoim czasie — mogłem nauczyć się o wiele więcej.

Byłem pewien, że to nie tylko powstrzymywało moją pracę i nie tylko powstrzymywało sieć, ale powstrzymywało mnie jako programistę. Co do drugiego punktu, myślę, że nie myliłem się całkowicie — cała niejasna wiedza o błędach przeglądarki IE 6-7, którą zgromadziłem, jest teraz bezużyteczna. Wszystko, co muszę pokazać, to mimowolne wzdrygnięcie się na słowo „filtr”, nieodgadniona preferencja dla padding nad margin i głęboko zakorzeniona, ale w dużej mierze nieuzasadniona obawa przed z-index​

„…dodatkowe odstępy powodują pobranie niewłaściwych stylów, jeśli rzeczywista nazwa klasy jest podciągiem (lub superciągiem) innej nazwy klasy”.

— Błąd parsowania białych znaków w IE5/Mac

Chciałbym, żeby to odeszło. Odinstalowany przez sprytnego i szeroko rozpowszechnionego wirusa, zakazany przez prawo, Microsoft w końcu zdecydował się ograniczyć straty swojego tandetnego silnika renderującego i przestawił się na silnik renderujący Firefoksa, Gecko – cokolwiek – po prostu sprawi, że zniknie . Ale nie. Sieć wciąż się rozwijała, a my, programiści, biliśmy się naprzód, łodzie pod prąd, nieustannie przenoszeni w przeszłość.

Pojawił się Chrome, Firefox stawał się coraz lepszy, nowe funkcje były wprowadzane, ekscytujące i nieskończone możliwości zaprezentowane przez nadejście responsywnego projektowania stron internetowych rozprzestrzeniły się przed nami, a także (skrótowo) pamiętaj, że masz tylko kilka dni aby wszystko działało mniej więcej w starym IE, więc nie daj się ponieść emocjom.​

„JEŚLI używasz IE8 I używasz metody CSS uporządkowanej numeracji list opisanej powyżej, ORAZ HTML, który ma klasy używające atrybutów CSS counter-reset i counter-increment jest UKRYTY podczas ładowania strony, WTEDY zawsze, gdy jest to ukryte. Wyświetlany jest HTML, WSZYSTKIE automatyczne liczby będą wynosić ZERO, ALE TYLKO JEŚLI NA TEJ STRONIE JEST UŻYWANY CSS :hover PSEUDO-CLASS!”

— Błąd „unoszenia” IE8: najbardziej niesamowity błąd IE w historii?

Trudno sobie wyobrazić, by w dzisiejszych czasach doświadczać tego rodzaju frustracji, przynajmniej dla nas, stosunkowo starszych osób. Nie mówiąc o tym, że w dzisiejszych czasach nie ma niesamowitej ilości pracy związanej z dostrajaniem rzeczy w różnych przeglądarkach — wiem aż za dobrze, że jest. Ale trudno nie poczuć okazjonalnego ukłucia „w moich czasach wszystko, co mieliśmy, to pływaki i pozwól, że opowiem Ci o błędzie podwójnego marginesu w IE ”, gdy usłyszysz o niewielkiej różnicy w działaniu CSS Grid w jednej przeglądarce do innego.

Myliłem się; Chcę to jasno powiedzieć. Nieźle, że jesteś sfrustrowany. Nie sądzę, żeby nikogo winić za frustrację tymi starymi błędami przeglądarki, tak samo jak nie sądzę, żeby kogokolwiek winić za frustrację związaną z jakimkolwiek aspektem tworzenia stron internetowych. Nie, myliłem się, dochodząc do wniosku, do którego doprowadziła mnie złość: pragnienie ujrzenia Tridentu spalonego do ziemi i ziemi, na której kiedyś stał, solonej.

Podejrzewam, że tylko jedna dramatycznie ironiczna rzecz wyrasta z tej zasolonej ziemi: te same frustracje, narodzone na nowo dla nowej generacji twórców stron internetowych. Kiedy zaczynałem karierę, kilka lat po wojnach przeglądarek, te nasiona już się zakorzeniły. Ponieważ przez pewien czas — czas przed moim — my, twórcy stron internetowych, przeklinaliśmy Netscape w ten sam sposób. Słabsza, bardziej podróbka, bezsprzecznie gorsza przeglądarka. Ale Internet Explorer — programiści pokochali tę przeglądarkę. I życzyli sobie, aby te inne przeglądarki — złe przeglądarki — po prostu odeszły : odinstalowane przez sprytnego i szeroko rozpowszechnionego wirusa, zakazanego przez prawo, Netscape w końcu zdecydował się zmniejszyć straty swojego tandetnego silnika renderującego i przełączyć się na silnik renderujący IE, Trident — cokolwiek — po prostu spraw, żeby to odeszło . Te niezbadane błędy Internet Explorera nie powstały przez przypadek lub niedbalstwo. Pojawiły się, ponieważ wygrał Internet Explorer i uwielbialiśmy go za tę wygraną.

Widzisz, nasza frustracja i nasz gniew okłamały nas, jak zwykle. Powiedzieli nam, że obsługa tych innych, gorszych przeglądarek nie tylko wstrzymywała naszą pracę i nie tylko wstrzymywała sieć, ale także nas jako programistów. To była strata naszego cholernego czasu. Powiedzieliśmy więc sobie, że to nie tylko dla naszego dobra, ale dla dobra całej sieci .

Ważyliśmy IE tylko trochę więcej. W naszych decyzjach daliśmy mu tylko trochę więcej do powiedzenia. I tak, mając tak wiele żetonów, Microsoft odpowiednio grał w swoje karty — kto mógłby ich winić? Wszyscy budowali dla nich strony internetowe w pierwszej kolejności, a inni w drugiej kolejności. Ich słowo nie było prawem , ale z pewnością było czymś więcej niż sugestią . Jasne, tu i ówdzie odbiegały od standardów sieciowych (tylko trochę), ale w końcu, czy coś zaimplementowanego przez The Biggest Browser i tak nie było de facto standardem? Poza tym wspieranie lepszej, szybszej i łatwiejszej przeglądarki było usługą dla samej sieci! Razem z Microsoftem pchaliśmy internet do przodu! Każdy wygrywa.

Silnik renderujący, który obecnie obsługuje przeglądarkę Edge firmy Microsoft — EdgeHTML — jest rozwidleniem strasznie starego Tridenta. Z pewnością jest to okrojony i znacznie ulepszony widelec Tridenta, ale nie jest, powiedzmy, powszechnie oceniany na podstawie własnych zalet. Zespół EdgeHTML zawsze miał kilka wad: pierwsza była techniczna, ponieważ dogonienie takich przeglądarek jak Safari, Firefox i Chrome wymagało ogromnej ilości czasu i wysiłku. Drugi był emocjonalny. To my – ty i ja – znudzeni latami Internet Explorera, wpatrujący się w wesołą niebieską małą literę „e” z zimną pogardą.

Kilka tygodni temu zespół Edge ogłosił, że wkrótce porzuci EdgeHTML na rzecz Blink, silnika renderującego, który napędza Chrome. Dzięki tej zmianie ostatnie kilka pozostałych żarów Tridentu zostanie na zawsze zgaszone. Życzenie, którym podzieliłem się z tak wieloma, w końcu się spełni. Jak na ironię, jak się okazuje, EdgeHTML stał się całkiem solidnym silnikiem renderującym.

Blink to projekt open-source prowadzony i zarządzany przez Google. Obsługuje zarówno Chrome, jak i Operę, z których ta ostatnia podobnie porzuciła swój własny silnik renderujący kilka lat temu.

Z przytłaczającym marginesem Blink jest (i będzie w coraz większym stopniu) sposobem postrzegania sieci na całym świecie. Blink jest szybki, stabilny, pełen nowoczesnych funkcji i — w porównaniu do rozwoju wciąż rozwijającego się EdgeHTML — bezbolesny .

Być może stało się już za późno, by uchronić nas przed tymi starożytnymi błędami IE, ale nasza praca będzie łatwiejsza teraz, gdy jest o jeden silnik renderujący mniej do obsługi. Ty i ja stracimy trochę więcej naszego zbiorowego obciążenia „ale czy to działa w różnych przeglądarkach”. Nasze projekty pójdą sprawniej, a sieć straci tylko trochę więcej tego, co kiedyś ją powstrzymywało.

Jako zarządcy silnika napędzającego tak dużą część sieci, cóż, słowo Google nie będzie prawem , ale z pewnością więcej niż sugestią . I być może w ciągu najbliższych kilku lat będą odbiegać od standardów sieciowych tu i tam (celowo lub przypadkowo) w najmniejszym możliwym stopniu. Ale w końcu, czy coś zaimplementowanego przez The Biggest Browser samo w sobie nie jest swego rodzaju de facto standardem? Poza tym, jak możesz się kłócić? W końcu faworyzowanie lepszej, szybszej i wydajniejszej przeglądarki sprawia, że ​​sama sieć jest usługą. Wraz z Google będziemy rozwijać internet. Wszyscy wygrają.

Oznacza to, że tak długo, jak małe odchylenia od standardów i drobne, dokuczliwe błędy nie rosną z czasem — dzięki bliźniaczym siłom entropii i samozadowolenia. Chyba że decyzje, które podjęliśmy dla dobra sieci (razem w parze z firmą reklamową notorycznie wrogą w prywatność) zaczną wydawać się nieco mroczniejsze, a w naszych umysłach zacznie nabierać kształtu nowy straszak — chyba że znajdziemy że nasze stare lęki i frustracje znów wzrosły (jak feniks, który renderuje kilkaset pikseli od miejsca, w którym powinien, i migocze w dziwny sposób podczas przewijania).

Nie potrzeba wiele wyobraźni, aby zobaczyć nowsze, bardziej ekscytujące silniki renderujące, które pojawią się w ciągu najbliższych kilku lat. Wystarczy niewielka wyobraźnia, aby zobaczyć, jak zawodzą z powodu braku wsparcia, ponieważ preferujemy „przeglądarkę, której wszyscy używają” — najpierw z wyboru, a później być może w niechętnej służbie „dolnej linii”.

Znowu jednak nie wiem. Sam nigdy nie widziałem, żeby tak się działo z silnikiem renderującym. Właśnie usłyszałem całą historię i tylko z pierwszej ręki wiem, jak się kończy. Znam zakończenie z bólu starych psychicznych blizn; od mimowolnego wzdrygnięcia się na niektóre fragmenty kodu i pamięci mięśniowej, która zmusza mnie do unikania innych. Znam to z dowcipów w rozmowach konferencyjnych, które zawsze wydawały się trochę zmęczone, ale wciąż rezonowały tak samo, w sposób, w jaki nie pozwalałem sobie przyznać, i wciąż mówiłem z sekretnym życzeniem, które nosiłem głęboko w sercu. Gorzkie, nienawistne życzenie.

Ale hej, posłuchaj. Nigdy więcej. Teraz to znaczy – nigdy bym tego nie zrobił. Naprawdę uwielbiam błąd silnika renderującego, teraz. Tak.

„Przekształcenia CSS 3D z perspective() są renderowane na lewą stronę”.

— bugs.chromium.org

To właściwie fajny błąd, prawda? Jak zabawa w pewien sposób . Ty wiesz?

To zabawne.

Będzie fajnie .