Smashing Podcast Episode 8 ze Stephanie Stimac i Aaronem Gustafsonem: Co nowego w Microsoft Edge?
Opublikowany: 2022-03-10W tym odcinku Smashing Podcast rozmawiam z Aaronem Gustafsonem i Stephanie Stimac z Microsoftu, aby dowiedzieć się więcej o zupełnie nowej wersji Microsoft Edge oraz o tym, jak wpływa ona na twórców stron internetowych na całym świecie, a także na jej wpływ na sieć.
Pokaż notatki
- Witryna internetowa, której chcemy i Twitter
- Stephanie i Aaron na Twitterze
Cotygodniowa aktualizacja
- „Mityczny Mityczny Człowiek-Miesiąc”,
autorstwa Johna Foremana - „Odtworzenie przycisku Arduino za pomocą SVG i <elementu podświetlonego>”
autor: Uri Shaked - „Jak przekazywać dane między komponentami w Vue.js”
autorstwa Matta Maribojoc - „Kompletny przewodnik po WordPress Multisite”,
przez Manisha Dudharejia - „Jak wzmocnić zespoły projektowe, mierząc wartość”
autor: Dave Cunningham
Transkrypcja
Drew McLellan: Jest menedżerem programu i badaczem użytkowników w zespole Microsoft Edge Developer Experiences, gdzie między innymi łączy się z programistami internetowymi, aby identyfikować problemy na platformie internetowej, dla których potrzebują rozwiązań, aby usprawnić ich codzienne przepływy pracy... orędownik standardów internetowych, ponownie z firmą Microsoft, gdzie ściśle współpracuje z zespołem Edge Browser, a także współpracuje z partnerami nad progresywnymi aplikacjami internetowymi i skupia się na kompatybilności między platformami... Razem są częścią zespołu The Web We Want Team , który jest projektem dostawców obsługującym wiele przeglądarek, który ma na celu nawiązanie dialogu z programistami internetowymi, aby pomóc w kształtowaniu przyszłego rozwoju platformy internetowej.
Drew: Wiemy, że obaj są z Microsoftu, obaj są oddani ulepszaniu sieci dla nas wszystkich, ale czy wiesz, że ich ostatnie spotkanie Web We Want odbyło się w balonie na gorące powietrze poza ziemską atmosferą? przed zeskokiem na ziemię w stylu Felixa Baumgartnera.
Drew: Moi Smashing Friends, witajcie Stephanie Stimac i Aarona Gustafsona.
Drew: Cześć Stephanie, cześć Aaron, jak się masz?
Aaron Gustafson: Rozbijam.
Stephanie Stimac: Ja też miażdżę.
Drew: Chciałem dziś z tobą porozmawiać o kilku bardzo interesujących zmianach, które miały miejsce w przeglądarce Microsoft Edge. Myślę, że większość z nas będzie wiedziała, że Edge jest tradycyjnie przeglądarką Windows 10, która zastąpiła ukochanego Internet Explorera. Prawdopodobnie pierwszą rzeczą, na którą powinniśmy zwrócić uwagę, jest to, że Edge nie jest już wyłącznie dla systemu Windows 10, prawda?
Aaron: Zgadza się.
Stephanie: Edge można znaleźć na Windows 10 i Mac OS. A potem nie jestem pewien, czy jest jeszcze dostępny w systemie Windows Seven.
Aaron: Tak, wierzę, że jest teraz również dostępny na Windows Seven i Windows Eight. No i oczywiście są też klienci mobilni na iOS i Androida.
Drew: Więc prawie każda nowoczesna platforma.
Stephanie: Tak.
Aaron: Z wyjątkiem Linuksa, mam nadzieję, że wkrótce.
Drew: Więc nawet użytkownicy komputerów z Linuksem mogą wziąć udział w akcji.
Aaron: W końcu taka jest nadzieja.
Drew: Fantastycznie. O ile rozumiem i popraw mnie, jeśli się mylę, ale Edge był technicznie kontynuacją bazy kodu Internet Explorera, czy to uczciwe?
Aaron: Tak, kiedy „Edge” zaczął po raz pierwszy, było to w zasadzie rodzaj wyrzucenia wszystkich rzeczy, o których zdaliśmy sobie sprawę, że były po prostu w tyle, rzeczy, które były zastrzeżone i takie tam. Wszystkie stare obiekty pomocnicze przeglądarki, elementy activeX i tym podobne. Więc został masowo wypatroszony. To była swoista szansa dla zespołu, aby naprawdę pozbyć się wielu starszych rzeczy i skupić się na standardowych rzeczach. Była to więc kontynuacja starego silnika Triton, ale w pewnym sensie przerobiona i przerobiona na silnik HTML Edge.
Drew: Więc to było jak ogromny remont domu w bazie kodu.
Aaron: Tak, zabierz to do stadniny.
Drew: Myślę więc, że największą zmianą, o której chcę porozmawiać w najnowszej wersji Edge'a, jest to, że jeszcze więcej takich starszych wnętrzności zostało wyrwanych i zastąpionych. Zainstalowano nowy silnik renderujący. Teraz jestem trochę świadomy używania żargonu, a ludzie, którzy być może nie są tak zaznajomieni z działaniem przeglądarek, mogą nie być w pełni zadowoleni z tego, co rozumiemy przez silnik renderujący. Myślę, że niektórzy z nas, którzy są w pobliżu i pracują w sieci od dłuższego czasu, zrozumieją te informacje, nawet jeśli nie pracują bezpośrednio z wewnętrznymi przeglądarkami. Ale ktoś, kto jest być może nowszy w tworzeniu stron internetowych, może nie rozumieć, co rozumiemy przez silnik renderujący. Czym więc jest silnik renderujący w przeglądarce? A które bity nie są silnikiem renderującym?
Aaron: Cóż, przeglądarka składa się z wielu różnych części. Silnik renderujący jest tym, o czym zwykle myślimy, gdy mówimy o tym, co jest faktycznie namalowane na ekranie io rodzaju interaktywnej warstwy rzeczy. I tak w świecie Chromium jest to silnik renderujący Blink.
Aaron: Jest jeszcze silnik renderujący WebKit, który uruchamia Safari. I to było oparte na silniku renderującym KHTML, który działał w Konquererze na początku.
Aaron: Silnik renderujący Trident, o którym wspomniałem wcześniej, był tym w Internet Explorerze dla Windows. Tantek Celik stworzył silnik renderujący Tasman jako część zespołu pracującego nad IE5 dla komputerów Mac.
Aaron: Tak więc istnieją różne silniki renderujące. I tak naprawdę myślę, że pojawił się nowy, o którym mówił właśnie Peter Paul Cox, zwany Flow. To jak wielowątkowy silnik renderujący oparty na SVG lub czymś w tym rodzaju. I jest nadchodząca przeglądarka, która została zaprojektowana dla dekoderów, urządzeń o naprawdę niskim poborze mocy.
Aaron: Ale tak, silniki renderujące, zbierają wszystkie twoje informacje i malują je na ekranie. Masz też swój rodzaj podstawowych silników JavaScript. Tak więc v8 w przypadku stosu typu Chromium. I do tego jest wiele różnych.
Drew: Kiedy mówimy, że stary silnik renderujący Trident, który pochodzi z IE i był w Edge, został zastąpiony. Właściwie mówimy o bicie, który maluje rzeczy na ekranie, a także o powiązanych rzeczach, takich jak silnik JavaScript. Czy to w porządku?
Aaron: Tak, w przypadku nowej wersji Edge'a w zasadzie nie ma żadnych podstaw starego Edge'a. Projekt Chromium to projekt open source, który uruchamia Chrome i Brave oraz kilka innych, Opera i tym podobne. A ten projekt zawiera silnik renderujący, zawiera silnik JavaScript, zawiera cały interfejs użytkownika. Obejmuje również proces budowania i wszystkie tego rodzaju rzeczy do faktycznego tworzenia przeglądarki.
Aaron: A więc w zasadzie mamy projekt Chromium, który stał się podstawą nowego Edge'a. Musieliśmy więc przejść przez proces, aby wyglądać jak Edge i dodać funkcjonalność, której potrzebowaliśmy, jeśli chodzi o synchronizację, używając kont Microsoft, tego rodzaju rzeczy.
Aaron: Tak więc nowy Edge nie dzieli żadnej linii w tradycyjnym sensie ze starym Edge, którym był Edge HTML, który odziedziczył po Trident i tak dalej. W przypadku większości z nich możesz wrócić do Mosaic.
Aaron: Ale tak, więc teraz nowym Edge'em jest Chromium, który bazuje na wcześniejszym WebKit, który bazuje na KHTML i tak dalej i tak dalej. Jest to więc zupełnie inna linia rodowa niż poprzednia.
Drew: Mam na myśli to, że to ogromna zmiana, prawda, że Microsoft nie ma już przeglądarki, która powstała we własnym kodzie. Ale w rzeczywistości bierze projekt open source i tworzy z niego własną przeglądarkę. To, jak sądzę, jest podobne do tego, co Apple zrobił kiedyś z WebKit. Co, to był KHTML oni… ?
Aaron: Tak, to Konqueror był… z K.
Drew: Tak, Konquerer, więc wzięli ten projekt open source i przekształcili go w Safari. A więc Microsoft robi podobną rzecz z projektem Chromium i zrobił z niego Edge'a?
Aaron: Zgadza się.
Drew: Jeśli siedzę przed Edge'em jako programista WWW, to, na co patrzę, jest unikalne dla Edge'a, co bym widział, czego nie widziałbym, gdybym siedział przed Chrome dla przykład?
Stephanie: Wiele funkcji w tej pierwszej stabilnej wersji jest zorientowanych na konsumentów. Pojawiają się więc kolekcje, które są całkiem fajnym sposobem na przeciąganie rzeczy z sieci do poszczególnych kolekcji, stąd nazwa. I możesz wziąć te dane i umieścić je w bocznym okienku, a następnie wyeksportować je do Worda i Excela, jak sądzę. Używałem go do projektów projektowych i innych rzeczy. Po prostu fajnie jest zbierać surowce.
Stephanie: Jedną z innych funkcji dla klientów Enterprise, dostępną tylko w systemie Windows, jest tryb IE. Dzięki temu Internet Explorer zostanie wyświetlony na karcie w Edge dla osób, które nadal potrzebują tych stron, które opierają się na starej technologii. Więc to jest całkiem fajne.
Stephanie: A jeśli chodzi o narzędzia programistyczne, teraz wszystko jest takie samo. Wiem, że nadchodzi kilka rzeczy, które zostaną przeniesione do Chromium, ale pracujemy nad fajną przeglądarką 3D DOM, nad którą zespół pracuje nad iteracją. A nadchodzi kilka innych narzędzi, które jeszcze nie istnieją w Chrome. Więc to jest ekscytujące.
Drew: Więc to wielka sprawa dla twórców stron internetowych, prawda? Ponieważ myślę, że zazwyczaj ludzie przyzwyczajają się do używania zestawu narzędzi programistycznych w wybranej przez siebie przeglądarce i dość często, szczerze mówiąc, jest to obecnie Chrome dla wielu programistów internetowych. Tak więc możliwość przejścia do Edge i znalezienia bardzo podobnego zestawu narzędzi programistycznych musi być nie lada atrakcją, myślisz?
Aaron: Tak, tak myślę. Chodzi mi o to, że jest to rodzaj rzeczy, w których będziesz mieć dokładnie ten sam zestaw narzędzi. Opieramy się na Chromium, w tym na wszystkich narzędziach programistycznych. Inwestujemy, jak mówiła Stephanie, w przeglądarkę 3D DOM. Dokonaliśmy wielu inwestycji w zakresie poprawy ogólnej dostępności narzędzi deweloperskich, dodawania do nich nowych narzędzi, pracy nad internacjonalizacją narzędzi deweloperskich.
Aaron: I jak wspomniała Stephanie, ogromna większość pracy, którą wykonujemy, w zasadzie wszystko, co nie jest związane z interfejsem użytkownika w Edge lub co wiąże się z naszą platformą synchronizacji lub podobnymi rzeczami, jest przesyłane strumieniowo do Chromium. Tak więc poprawki, które wprowadzamy, ulepszenia, które wprowadzamy w zakresie ułatwień dostępu, sprawią, że Chrome będzie lepszy, uczynią Brave lepszą, Opera lepszą. Zamierzają nawet ulepszyć Electrona.
Aaron: Więc naprawdę fajnie jest być częścią tego większego ekosystemu. I mieć wpływ poza naszą własną przeglądarką. A zatem narzędzia deweloperskie to obszar, w który zainwestowaliśmy wiele. Dużo pracowaliśmy również z partnerami z zespołu Chrome nad progresywnymi aplikacjami internetowymi. I próbując dowiedzieć się, czym są progresywne aplikacje internetowe lub jak powinny wyglądać w środowiskach komputerowych, ponieważ duży nacisk położono na urządzenia mobilne.
Aaron: Poza tym było dużo pracy między zespołem Dev Tools a ludźmi pracującymi nad VS Code, aby te narzędzia działały lepiej razem. Dzięki temu możesz zasadniczo uzyskać dostęp do narzędzi programistycznych z przeglądarki z poziomu kodu VS podczas debugowania swoich stron. I wszystko jest połączone, na przykład możliwość kliknięcia reguły stylu w narzędziach programistycznych Edge, w rzeczywistości zabierze Cię do tej linii w kodzie VS w arkuszu stylów. Co jest oszałamiające, to naprawdę fajne rzeczy.
Drew: To brzmi naprawdę ekscytująco. Wiem, że VS Code to coś, co wydaje się być bardzo popularne w społeczności twórców stron internetowych. Myślę, że w rzeczywistości sprowadziło to wielu ludzi z powrotem do Narzędzi Microsoft, którzy mogli odpłynąć na przestrzeni lat. Z pewnością wydaje się, że jest to inna era Microsoftu, podobnie jak tego rodzaju objęcie open source i nową wersją Edge. To wszystko wydaje się całkiem ekscytujące i całkiem odświeżające z punktu widzenia tworzenia stron internetowych.
Drew: Również z tego punktu widzenia wydaje się, że jest to naprawdę duże ułatwienie dla twórców stron internetowych, ponieważ jeśli niektóre z głównych przeglądarek, w szczególności Chrome i Edge, a także wspomniałeś Brave i Opera, to wszystkie używają tego samego renderowania prawdopodobnie zmniejsza masę problemów ze zgodnością i przeglądarek, które nie muszą być testowane w wielu różnych miejscach. Wszystko powinno działać tak samo, czy to sprawiedliwe?
Stephanie: Tak.
Drew: Niesamowite.
Aaron: To sen, prawda?
Drew: To zawsze jest marzenie. Budzi to jednak pewne obawy, ale nie w przypadku zmniejszenia zdrowej konkurencji na rynku. Podczas gdy Microsoft przesuwał swoją przeglądarkę do przodu, Google przesuwał swoją przeglądarkę do przodu. Apple, miejmy nadzieję, idealnie popchnie swoją przeglądarkę, Operę i wszystkich innych graczy. I to tworzy atmosferę zdrowej rywalizacji, w której wszyscy starają się nadążyć za sobą i wprowadzać ulepszenia. Jeśli wielu dużych graczy korzysta z tego samego silnika renderującego, czy cierpi na tym zdrowa konkurencja?
Aaron: To jest coś, co zdecydowanie mam, będąc od dawna osobą zajmującą się standardami sieciowymi, trochę zmagam się, nie sądzę… Całkowicie rozumiem uzasadnienie biznesowe. Z punktu widzenia Microsoftu miało to sens. A z perspektywy dewelopera front-endu fajnie jest nie musieć zajmować się wieloma różnymi silnikami.
Aaron: Ogólnie rzecz biorąc, ci z nas, którzy od dłuższego czasu pracują w sieci, z pewnością zauważyli dużą zbieżność w zakresie renderowania. Nie mamy tak wielu problemów, jak mówiliśmy w Netscape 4,7 dni, kiedy mieliśmy po prostu, wiesz, znałem firmy, które tworzyły unikalne arkusze stylów dla każdej innej przeglądarki, co było po prostu nie do utrzymania.
Aaron: Ale myślę, że to, co się teraz zmieniło, to to, że w pierwotnych wojnach przeglądarkowych mieliście wszystkie te zastrzeżone silniki i wszyscy byli w pewnym sensie w grze o jedność, jeśli chodzi o dostarczanie nowych funkcji platformy i nowych funkcji JavaScript . Lub w przypadku Microsoft odwrotnej inżynierii JavaScript w celu stworzenia J Script i próby wymyślenia, jak to wszystko dopasować.
Aaron: Ale teraz mamy możliwość pracy razem w projektach open source i nadal prowadzimy dialog i nadal, nie wiem, walczymy nie właściwym słowem, ale prowadzimy poważne dyskusje na temat wpływu różnych podejść. I nie zgadzać się ze sobą. I naprawdę pracować nad dopracowaniem specyfikacji. A także mieć konkurencyjne podejścia do kodu bazowego w kontekście, powiedzmy, projektu Chromium lub WebKit lub czegoś w tym rodzaju lub Mozilli w przestrzeni Firefoksa.
Aaron: A więc tak, z jednej strony straciliśmy inny silnik renderujący. I poczułem ten sam ból, gdy Opera zdecydowała się przejść do Chromium. Ale czuję się nieco pokrzepiony, będąc w Microsoft i widząc, jak bardzo jesteśmy zaangażowani w rzeczywisty udział w projekcie Chromium w znaczący sposób. I nie tylko siedzenie i akceptowanie wszystkiego, co pochodzi z Chromium, ale właściwie sprawdzanie tego, co wchodzi na platformę i uczestniczenie w tym.
Aaron: Więc trochę mnie to pociesza i czuję, że nie jesteśmy tam tylko po to, by czerpać z tego projektu i po prostu akceptować wszystko, co zostało przekazane przez wszystkich różnych ludzi, którzy mają udział w tym projekcie. Ale żeby tam również współpracować.
Aaron: Myślę, że nadal musimy dowiedzieć się, co to oznacza dla organów normalizacyjnych pod względem interoperacyjnych wdrożeń. Ponieważ w zasadzie, jeśli masz jakieś przeglądarki, które decydują, że nie chcą czegoś implementować, mogą całkowicie powstrzymać coś przed staniem się standardem. Nawet jeśli wszyscy programiści na świecie tego chcieli.
Aaron: I może nie być tak, że się z tym nie zgadzają. Po prostu mogą nie mieć przepustowości, aby zbudować tę funkcję. Wszyscy chcą mieć personel i tak dalej.
Drew: Myślę, że tak naprawdę współpraca w sieci jako platforma właśnie przeniosła lokalizacje z wszystkich zgadzających się na implementację tego samego w swoich indywidualnych bazach kodu do kilku głównych graczy pracujących razem w zasadzie na tej samej bazie kodu.
Drew: Chodzi mi o to, że wspomniałeś krótko o nieporozumieniach i oczywiście jest to coś, co może być problemem, jak sądzę, w każdym projekcie open source. Ale czy wiemy, jak to będzie działać, jeśli na przykład programiści z Google chcą zaimplementować jakąś funkcję, a programiści z Microsoftu naprawdę nie chcą, aby została ona zaimplementowana. Czy po prostu walczą o problemy z GitHub?
Aaron: Mam na myśli, że wiele z tych rzeczy dzieje się na otwartej przestrzeni, zarówno w problemach z GitHub, jak i Crbug, który jest narzędziem do śledzenia błędów Chromium. Nie jestem inżynierem przeglądarki, więc nie znam wszystkich szczegółów wewnętrznych elementów, ale wierzę, że jest wiele rzeczy, które możemy zasadniczo wyłączyć, jeśli ich nie chcemy.
Aaron: I wiem, że Google pracuje nad pewnym porządkiem lub sprzątaniem w ramach projektu Chromium, aby wyodrębnić więcej usług związanych z Google, aż do warstwy konwersji z Chromium na Chrome.
Aaron: A więc mamy podobny proces, biorąc Chromium i przekształcając go w Edge. I oczywiście nie chcielibyśmy na przykład sprawdzać projektu interfejsu Edge UI. Lub w kwestii Kolekcji, która jest bardziej skupiona na użytkowniku interfejsu użytkownika, o której wspomniała Stephanie, nie przesyłamy ich do Chromium. Te istnieją w rodzaju części interfejsu użytkownika.
Aaron: Tak więc, o ile rozumiem, gdy funkcje pochodzą z Chromium, mamy możliwość wyłączenia pewnych rzeczy, które mogą nam się podobać lub nie. I wiem, że Brave robi to samo, ponieważ mają znacznie inne podejście do prywatności niż Google. I możemy mieć nieco inne podejście niż którykolwiek z nich lub co ty.
Aaron: Więc myślę, że będą różne rzeczy, które wydarzą się w różnych momentach. Niektóre z nich będą rodzajem miejsca, w którym projekt zostanie przekonwertowany do przeglądarki z projektu open source. Część z nich będzie należeć do organizacji normalizacyjnych lub grup interesu w organizacjach normalizacyjnych i tak dalej.
Drew: I myślę, że to działa też w drugą stronę, prawda? Wspomniałeś, że przeglądarka nie ma pod ręką wystarczającej liczby inżynierów, aby opracować określoną funkcję. Tradycyjnie sposób, w jaki wszystko działało w organach normalizacyjnych, polega na tym, że potrzebujemy wielu różnych implementacji, zanim coś zostanie zaakceptowane jako część standardu. Oczywiście trzeba to rozgryźć, jeśli nie ma tak wielu dostępnych implementacji do testowania.
Drew: Ale na przykład, jeśli Microsoft chciał zaimplementować funkcję, a Google zdecydował, że po prostu nie ma zasobów, aby ją zaimplementować, nie było to wystarczająco wysoko na ich liście priorytetów, cóż, potencjalnie zamierzają i tak zdobądź go za darmo, ponieważ po prostu jest przesyłany strumieniowo do projektu open source. A potem mogą uzyskać do niego dostęp, a wszyscy jego użytkownicy odnoszą korzyści, a żaden z ich inżynierów nie musi poświęcać znacznego czasu na opracowanie tego.
Drew: To znaczy, gdyby Mozilla zdecydowała, że zrobi to samo z Firefoksem i po prostu zaadoptuje projekt Chromium, czy myślisz, że byłby to problem dla sieci?
Stephanie: To znaczy, powiedziałabym, że tak, ponieważ wtedy jesteśmy w tej monokulturze przeglądarek i szczerze mówiąc, kocham Firefoksa. Firefox ma świetne narzędzia, których nie ma Chromium. Myślę, że to byłoby naprawdę straszne do stracenia. I fajnie jest mieć niezależną przeglądarkę, która wciąż walczy o otwartą sieć. To znaczy, walczymy też o otwartą sieć, ale myślę, że to, co robi Firefox, jest nadal ważne.
Aaron: To znaczy, zastanawiam się, co by się stało, gdyby, powiedzmy, czy był to Chromium, czy WebKit, czy jakiś rozwidlenie istniejącego projektu open source, co by było, gdyby ciało standardów kontrolowało silnik renderujący i silnik JavaScript. I wszyscy twórcy przeglądarek przyczyniali się do rozwoju i ciągłego tworzenia tego. Czy to koniecznie byłoby złe, czy też dobre? Nie wiem Nie wiem, jaka jest na to odpowiedź, ale jest to dość ciekawa perspektywa, że jeśli… Przeglądarki nie są tanie i nieistotne w budowie, a zwłaszcza silniki renderujące. Prawdopodobnie raczej nie zobaczymy wielu nowych silników renderujących i dużych inwestycji w tym obszarze. Ponieważ tak wiele firm przestawiło się na koncentrację na swoich usługach.
Aaron: Z Apple, z całym iCloudem i całym ekosystemem. A Mozilla zrobiła podobne rzeczy z przejęciem Pocket i tym podobnych. A potem z pewnością jest zestaw produktów Google, zestaw produktów Microsoft itp. A Brave koncentruje się na prywatności i podstawowym znaku uwagi i tego typu rzeczach. Każdy ma swój mały ekosystem rzeczy.
Aaron: A więc nie wiem, czy będzie duże zainteresowanie tworzeniem nowego silnika renderującego i nowego silnika JavaScript, aby rzucić wyzwanie tym, które tam są. Jest to więc kwestia tego, czy nadal będzie istnieć rodzaj konsolidacji. A jeśli więcej osób jest aktywnie zainteresowanych ciągłym rozwojem i prowadzeniem tych trudnych rozmów o tym, dokąd zmierza silnik i dokąd zmierza platforma internetowa, czy to może być dobra rzecz, nie wiem. Jest to jednak rodzaj interesującego eksperymentu myślowego.
Drew: Naprawdę. Nowy Edge brzmi naprawdę ekscytująco. Bawiłem się trochę z wersjami beta i podobało mi się to. Jak myślisz, ile czasu zajmie, zanim nowa wersja pojawi się na świecie? Bo to, mam na myśli, zostało wydane dopiero w tym miesiącu, prawda, mamy styczeń 2020.
Aaron: Tak, 15 stycznia, w zasadzie trafił do ogólnej publiczności. Tak więc mieliśmy wersje deweloperską i beta Canary. Boże, kiedy zaczęliśmy to wprowadzać, Stephanie, pamiętasz?
Stephanie: Powiem sześć miesięcy temu, ale szczerze, po prostu to wyrzucam. Czuję się, jakbym używał Canary jako mojego codziennego kierowcy przez, jak się wydaje, miesiące.
Aaron: Tak, myślę, że jesteśmy trochę skrzywieni, ponieważ zaczęliśmy używać go wewnętrznie, zanim zaczęliśmy udostępniać go publiczności. Ale tak, myślę, że chcę powiedzieć, że zaczęliśmy dzielić się tym na Build w zeszłym roku, czyli w maju, myślę, że wtedy, gdy Wyspy Kanaryjskie i może trasa objazdowa, nie pamiętam, czy beta była wtedy. Ale tak, w pełni stabilna wersja wyszła 15-go.
Drew: Więc oboje jesteście zaangażowani w projekt o nazwie The Web We Want , który jest rodzajem inicjatywy wielu różnych twórców przeglądarek, zgadza się?
Stephanie: Tak, więc The Web We Want , myślę, że Aaron zaczął to w czerwcu lub tak i zaczęliśmy o tym rozmawiać. I tak, The Web We Want jest w zasadzie inicjatywą, a Aaron i ja byliśmy głównymi, którzy ją prowadziliśmy, ale byliśmy zainteresowani innymi dostawcami przeglądarek i ludźmi, którzy pracują w tych zespołach.
Stephanie: I jest to po prostu sposób na zebranie opinii od programistów na temat problemów, które mają w sieci. Ponieważ my, jako ludzie, którzy budują przeglądarkę, możemy skupić się na tych nowych błyszczących rzeczach, które chcemy wdrożyć. Ale programiści, jak zobaczyliśmy w tej inicjatywie, wciąż mają problemy z budowaniem wielu rzeczy, które nie są natywne w przeglądarce. To prawdopodobnie powinno być już rozwiązane, ale tak się nie stało.
Stephanie: I na tym właśnie polega inicjatywa, aby dowiedzieć się, jakie są obszary problemowe, a następnie zwrócić je z powrotem do przeglądarek i organów normalizacyjnych, jeśli to jest tego rodzaju problem.
Drew: Więc jaką formę to przybiera? Czy to coś, co robisz osobiście, czy to wszystko online?
Stephanie: A więc mamy do tego dwa elementy. Możesz więc przejść do webwewant.fyi i wypełnić formularz ze swoim problemem i przypadkiem użycia, który napotkałeś w Internecie. A potem Aaron i ja byliśmy, myślę, że pojechaliśmy, cóż, myślę, że zorganizowaliśmy sześć lub siedem wydarzeń w ramach konferencji lub spotkania.
Stephanie: A więc taka forma jest taka, że zwykle mamy sesję trwającą od 45 minut do godziny na konferencji, z którą współpracujemy. Osobom, które zgłosiły swoje problemy w sieci, dajemy szansę zaprezentowania ich przed panelem sędziowskim, który zazwyczaj jest ekspertem z branży.
Stephanie: A w międzyczasie zwykle mamy cztery lub pięć z tych problemów, które są prezentowane podczas sesji. A pomiędzy każdym z nich mamy panel sędziowski, który w pewnym sensie rozmawia o prezentowanej przestrzeni problemowej. I czy jest to ciekawa przestrzeń problemowa. Lub jeśli uznają, że dostawcy przeglądarek przydadzą się, aby nad tym popracować.
Stephanie: A potem, pod koniec tej sesji, nasi sędziowie wybierają, co ich zdaniem jest najpilniejszym problemem do rozwiązania. Mamy też komponent dotyczący odbiorców, więc odbiorcy sesji mogą również głosować na to, co ich zdaniem jest najpilniejszą rzeczą, którą dostawcy przeglądarek powinni naprawić.
Stephanie: A potem zabieramy te dane z powrotem do naszych zespołów. Obecnie zastanawiamy się, jak to rozproszyć między różnymi zespołami przeglądarek.
Drew: Czy są jakieś wyróżnienia, sugestie, które pamiętasz, a które szczególnie utkwiły w tobie?
Stephanie: Więc było kilka, ale ten, który ciągle mnie wyróżnia, to kontrolki HTML ciągle się pojawiają. I to jest dla mnie rzucające się w oczy, ponieważ pracuję teraz nad wykładem, który dotyczy kontrolek HTML i jak niemożność ich stylizowania lub rozszerzania jest problemem. Więc fajnie jest widzieć, że opinie powtarzają się jeszcze bardziej.
Stephanie: Zdarzyło się kilka naprawdę interesujących rzeczy, był taki, który służył do wyświetlania kolejności widoków źródłowych lub przeglądarki kolejności widoków źródłowych w narzędziach programistycznych, które, jak sądzę, miały do czynienia z przejmowaniem zawartości siatki i widzeniem, ponieważ można w pewnym sensie przesuwać rzeczy poza kolejnością, i posiadanie tego rodzaju identyfikacji, w jaki sposób rzeczy przepływają przez DOM. Myślę więc, że byłoby to naprawdę fajne, gdyby zostało zaimplementowane w narzędziach deweloperskich.
Aaron: Tak, było wiele zgłoszeń związanych z ułatwieniami dostępu, które były naprawdę fajne. Innym, który był związany z narzędziami deweloperskimi i dostępnością, zamiast przenosić testy dostępności do własnej części, była zakładka audytów, myślę, że jest tam, gdzie obecnie, tak jak latarnia morska przeprowadza testy dostępności, lub możesz użyć wskazówki internetowe lub informacje o ułatwieniach dostępu i tym podobne.
Aaron: Pomysł polega na tym, aby zacząć przechwytywać niektóre nisko wiszące owoce pod kątem błędów dostępności i na przykład bulgotać w konsoli. Tak więc, jeśli zauważy, że masz jakieś obrazy, w których brakuje tekstu alternatywnego lub naprawdę małe czcionki lub niewystarczający kontrast, może to faktycznie wyświetlić je jako błędy w konsoli. I to jest miejsce, w którym wielu programistów sprawdza, czy ich rzeczy działają poprawnie. To sprawiłoby, że dla ludzi byłoby trochę bardziej oczywiste, że mają problemy z dostępnością, które muszą rozwiązać.
Aaron: Możesz zobaczyć podobne sposoby włączenia tego do przeglądarki Dom lub narzędzi inspektora CSS, gdzie może oznaczać coś jako zbyt niski kontrast lub podświetlić element jako mający jakiś znany problem z dostępnością. Takie rzeczy byłyby całkiem interesujące.
Stephanie: Tak, chcę to odpiąć. W zeszłym roku na View Source w Amsterdamie zaprezentowano naprawdę ciekawą prezentację. To było wokół przeglądarki automatycznie naprawiające niektóre rodzaje problemów z dostępnością. I tylko z kolorem i kontrastem, a może niektórymi czcionkami są nieczytelne. Przedstawiona propozycja i studium przypadku były naprawdę dobrze przemyślane. Ale w pewnym sensie stawia to również interesujące pytanie, czy przeglądarka zacznie naprawiać rzeczy za Ciebie jako programistę, czy zamierzasz napisać zły kod, ponieważ nie musisz się tym martwić.
Stephanie: Więc to było interesujące, ponieważ pomysły, które wysunął i rodzaj wersji demonstracyjnej, były naprawdę fajne. Ale to w pewnym sensie oznacza to dla programistów, więc czy będą leniwi. Widziałem więc, jak wyszło z tego kilka fajnych rzeczy.
Drew: Więc wydaje mi się, że to dopiero początek, prawda, jeśli chodzi o inicjatywę. Sądzę więc, że nic nie zaszło tak daleko, jak faktycznie osiąganie nawet wczesnych etapów rozwoju z jakąkolwiek przeglądarką. Czy wiesz, jak ten proces będzie wyglądał, powiedziałeś, że wciąż próbujesz to rozgryźć, czy to prawda?
Aaron: Tak, wszyscy wciąż próbujemy to rozgryźć, ale mamy w to zaangażowane odpowiednie osoby. Mamy ludzi z Mozilli i Google, a także z Igalii, to oni wykonali dużo pracy nad siatką i są bardzo zaznajomieni z tym, jak działają wszystkie te standardowe rzeczy. Właściwie myślę, że robią teraz Metanol, robiąc implementację dla WebKit.
Aaron: Więc tak, mamy na pokładzie grupę ludzi, którzy są chętni do pracy nad tym i chcą, aby to odniosło sukces. I W3C również zwraca na to uwagę, co jest fajne.
Stephanie: Tak więc dla nas w tej chwili zajęliśmy, myślę, że mamy 12 najlepszych, wybraliśmy zwycięzców z każdego wydarzenia w zeszłym roku i podzieliłem ich na konkretne kategorie. Więc niektóre są skoncentrowane na narzędziach programistycznych, inne na HTML, platformach internetowych. A potem nie pamiętam, jaka była trzecia kategoria, to była po prostu ogólna.
Stephanie: A więc po stronie Edge'a zaczynamy przynajmniej się przyglądać, mam nadzieję, że wkrótce wypuszczę kilka ankiet na Twitterze, aby zebrać więcej informacji zwrotnych, aby potwierdzić, że są to problematyczne obszary, w które powinniśmy zainwestować czas w. A potem miejmy nadzieję, że pójdziemy stamtąd. Mam więc nadzieję, że w tym roku zaczniemy widzieć jakiś postęp. Ale w tej chwili jest trochę powolny.
Drew: To świetnie, ponieważ sieć jest w rzeczywistości platformą do współpracy. I myślę, że jako programista WWW, który buduje strony codziennie, zapominasz, że tak naprawdę są sposoby, aby wrócić do procesu i sprawić, by Twój głos był słyszany. I myślę, że to brzmi jak naprawdę świetny, łatwy sposób, aby Twój głos był słyszany.
Drew: Jeśli któryś z naszych słuchaczy chciałby przyjść na sesję Web We Want , czy coś się zbliża?
Stephanie: Jest kilka, więc pozwól, że podniosę tutaj moją listę. Cóż, Open Source Festival w Lagos w Nigerii. Aarona i mnie tam nie będzie, ale w rzeczywistości prowadzą to wydarzenie niezależnie.
Stephanie: A potem będę na SF HTML5 w San Francisco pod koniec marca. Wierzę, że to nic nie kosztuje, ale nie cytuj mnie na ten temat. Muszę sprawdzić. Więc jeśli jesteś w rejonie San Francisco, to tam go prowadzimy.
Stephanie: A potem SmashingConf w San Francisco w kwietniu. Tam to będziemy prowadzić.
Stephanie: I miejmy nadzieję, że TBD, wciąż patrząc na SmashingConf Austin.
Stephanie: I wierzę, że to wszystko, co mamy teraz w kalendarzu. Ale zamierzam zrobić małą wtyczkę tutaj, jeśli prowadzisz konferencję lub spotkanie i chcesz, aby ta sesja skupiona na społeczności odbyła się tam, skontaktuj się z nami, ponieważ jest naprawdę fajna.
Drew: Oczywiście, uważamy, że SmashingConfs są najlepszymi, do których można się udać.
Stephanie: Tak, tak, są.
Drew: Więc dla mnie to brzmi naprawdę ekscytująco. And I'm heartened to see all the big browser makers actually coming together and backing that sort of initiative to get out and to talk to web developers, talk to the people who are actually solving these sort of everyday problems, building websites and apps for their clients and for their companies.
Drew: I think it's really important to actually listen to the people who are at the coalface doing the work.
Drew: I normally ask at the sort of end of these episodes, what have you been learning lately? Because we're all about learning stuff here at Smashing, but really with Web We Want , I think you must be learning all these things all the time by speaking to web developers. So I really think we've covered masses there.
Drew: Is there anything else that you wanted to mention about Web We Want or about the new version of Edge that we hadn't talked about?
Aaron: I just think if folks have ideas, even just the germ of an idea, some cow path that you think should be paved for the web, reach out to us, let us know. We're happy to also work with you on kind of refining the submission. So, in a lot of cases we'll get a submission that's kind of a germ of an idea. It's not perfectly articulated or anything like that. And we work with those authors to make sure that we kind of capture what it is that they're looking to put out there. So, don't worry about your grammar or your spelling or anything like that. It's not like we just post it up as soon as you send it, we'll look at it, review it.
Aaron: And in some cases people have suggested things that actually exist, in which case we tell them, hey, you can actually do that and here's a way to do that. So we can, it's a little bit of stack overflow as well. Because he can tell you if there's something that you can do that already with standards.
Aaron: But yeah, I mean, we want any and all ideas on how we can improve the web. Hopefully they're actionable ideas. In some cases we get like, the web is too hard. And it's like, you know, I feel you, but, you know, not something browser vendors can really solve.
Aaron: But yeah, I mean, we want to know what is it that you're doing, where you're running into problems. We have the kind of saying, if you could wave a magic wand and fix something on the web, what would it be?
Aaron: And yeah, so you can can hit us up via the forum. Stephanie mentioned webwewant.fyi. Or we're webwewantfyi on Twitter. Yeah, please reach out.
Stephanie: I will also pile on just to talk something about Edge that also, the team is super hungry and eager to get feedback from all of our users. So if you're in Edge and there's something you don't like or there's something you love, there's a little feedback icon you can click. All of the teams see that feedback and are looking at it. And if you have a problem are very proactive and engaging. And you can always ping MS Edge Dev on Twitter if you have a problem and it hasn't been addressed yet. So trying to be super proactive and really build a browser that not only developers want to use, but the world.
Drew: If you, dear listener, would like to hear more from Aaron or Stephanie, you can follow them on Twitter where he's @AaronGustafson and she's @seaotta. You can find The Web We Want at webwewant.fyi.
Drew: Thank you for joining us today Aaron and Stephanie, do you have any parting words?
Stephanie: Thanks.
Aaron: Adios.