Smashing Podcast Episode 8 mit Stephanie Stimac und Aaron Gustafson: Was ist neu in Microsoft Edge?

In dieser Folge des Smashing Podcast spreche ich mit Aaron Gustafson und Stephanie Stimac von Microsoft, um mehr über die brandneue Version von Microsoft Edge und ihre Auswirkungen auf Webentwickler weltweit sowie ihre Auswirkungen auf das Web zu erfahren.

Notizen anzeigen

• Die Web We Want- Website und Twitter
• Stephanie und Aaron auf Twitter

Wöchentliches Update

• „Der mythische mythische Mann-Monat“,
  von John Foremann
• „Neuerstellen des Arduino-Tasters mit SVG und <lit-element>“,
  von Uri Shaked
• „So übergeben Sie Daten zwischen Komponenten in Vue.js“,
  von Matt Maribojoc
• „Ein vollständiger Leitfaden für WordPress Multisite“,
  von Manish Dudharejia
• „So stärken Sie Designteams durch Wertmessung“,
  von Dave Cunningham

Abschrift

Drew: Wir wissen also, dass sie beide von Microsoft sind, sie sind beide bestrebt, das Web für uns alle besser zu machen, aber wussten Sie, dass ihr letztes Web-We-Want- Treffen in einem Heißluftballon außerhalb der Erdatmosphäre stattfand? bevor er im Stil von Felix Baumgartner wieder auf die Erde springt.

Drew: Meine Smashing Friends, bitte heißen Sie Stephanie Stimac und Aaron Gustafson willkommen.

Drew: Hallo Stephanie, hallo Aaron, wie geht es dir?

Aaron Gustafson: Ich bin der Hammer.

Stephanie Stimac: Ich schlage auch.

Drew: Ich wollte heute mit Ihnen über einige sehr interessante Entwicklungen sprechen, die mit dem Microsoft Edge-Browser vor sich gegangen sind. Ich denke, die meisten von uns werden wissen, dass Edge traditionell der Windows 10-Browser ist, der den allseits beliebten Internet Explorer ersetzt hat. Das erste, was wir wahrscheinlich beachten sollten, ist, dass der Edge nicht mehr exklusiv für Windows 10 ist, oder?

Aaron: Richtig.

Stephanie: Sie finden Edge unter Windows 10 und Mac OS. Und dann bin ich mir nicht sicher, ob es schon für Windows Seven verfügbar ist.

Aaron: Ja, ich glaube, es ist jetzt auch für Windows Seven und Windows Eight verfügbar. Und dann gibt es natürlich noch die mobilen Clients für iOS und für Android.

Drew: Also so ziemlich jede moderne Plattform.

Stephanie: Ja.

Aaron: Bis auf Linux, das hoffentlich bald kommt.

Drew: Also können sogar Linux-Desktop-Benutzer an der Aktion teilnehmen.

Aaron: Schließlich ist das die Hoffnung.

Drew: Fantastisch. Also, soweit ich es verstehe, und korrigiere mich, wenn ich hier falsch liege, aber Edge war technisch gesehen eine Fortsetzung der Internet Explorer-Codebasis, ist das fair zu sagen?

Aaron: Ja, als Edge anfing, war es im Grunde genommen, all das Zeug herauszureißen, von dem wir erkannten, dass es nur irgendwie herumhinkte, Dinge, die proprietär waren und solche Sachen. All die alten Browser-Hilfsobjekte und ActiveX-Sachen und solche Sachen. Es wurde also massiv entkernt. Es war eine Art Gelegenheit für das Team, eine Menge Altlasten loszuwerden und sich auf das Standardmaterial zu konzentrieren. Und so war es eine Fortsetzung der alten Triton-Engine, aber irgendwie umgestaltet und in die Edge-HTML-Engine umgewandelt.

Drew: Es war also wie eine massive Hausrenovierung innerhalb der Codebasis.

Aaron: Ja, bring es zu den Gestüten.

Drew: Ich denke, die größte Änderung, über die ich mit der allerneuesten Version von Edge sprechen möchte, ist, dass noch mehr dieser Art von älteren Eingeweiden herausgerissen und ersetzt wurden. Und es wurde eine neue Rendering-Engine installiert. Jetzt bin ich mir ein wenig bewusst, Fachjargon zu verwenden, und Leute, die mit der Funktionsweise von Browsern vielleicht nicht so vertraut sind, sind möglicherweise nicht ganz zufrieden damit, was wir unter einer Rendering-Engine verstehen. Ich denke, einige von uns, die schon lange im Internet unterwegs sind und damit arbeiten, werden diese Informationen mitbekommen haben, auch wenn wir nicht direkt mit den Interna von Browsern arbeiten. Aber jemand, der vielleicht neu in der Webentwicklung ist, versteht vielleicht nicht, was wir mit einer Rendering-Engine meinen. Was ist also eine Rendering-Engine in einem Browser? Und welche Bits sind keine Rendering-Engine?

Aaron: Nun, ein Browser besteht aus vielen verschiedenen Teilen. Die Rendering-Engine ist das, woran wir normalerweise denken, wenn wir darüber sprechen, was tatsächlich auf den Bildschirm gemalt wird, und eine Art interaktive Ebene der Dinge. In der Chromium-Welt ist das die Blink-Rendering-Engine.

Aaron: Und dann ist da noch die WebKit-Rendering-Engine, die Safari ausführt. Und das basierte auf der KHTML-Rendering-Engine, die Konquerer in den frühen Tagen ausführte.

Aaron: Die Trident-Rendering-Engine, die ich zuvor erwähnt habe, war die von Internet Explorer für Windows. Tantek Celik hatte die Tasman-Rendering-Engine als Teil des Teams entwickelt, das an IE5 für Mac arbeitete.

Aaron: Es gibt also all diese verschiedenen Rendering-Engines da draußen. Und tatsächlich glaube ich, dass es einen neuen namens Flow gab, über den Peter Paul Cox gerade gesprochen hat. Das ist wie eine Multithread-Rendering-Engine, die auf SVG oder so ähnlich basiert. Und dafür gibt es einen demnächst erscheinenden Browser, der für Set-Top-Boxen entwickelt wurde, wirklich stromsparende Geräte.

Aaron: Aber ja, die Rendering-Engines nehmen all Ihre Informationen und malen sie auf den Bildschirm. Und dann haben Sie auch Ihre zugrunde liegenden JavaScript-Engines. Also v8 bei der Art des Chromium-Stacks. Und auch dafür gibt es verschiedene.

Drew: Also, wenn wir sagen, dass die alte Rendering-Engine Trident, die aus dem IE kam und in Edge war, ersetzt wurde. Wir sprechen eigentlich über das Bit, das Dinge auf den Bildschirm zeichnet, und auch über damit verbundene Dinge wie die JavaScript-Engine. Ist das fair?

Aaron: Ja, im Fall der neuen Edge-Version ist im Grunde keine der Grundlagen des alten Edge vorhanden. Das Chromium-Projekt ist ein Open-Source-Projekt, das Chrome und Brave und eine Reihe anderer, Opera und dergleichen, ausführt. Und dieses Projekt enthält die Rendering-Engine, es enthält die JavaScript-Engine, es enthält die gesamte Benutzeroberfläche. Es enthält auch den Build-Prozess und all diese Dinge, um den Browser tatsächlich zu erstellen.

Aaron: Und so haben wir im Grunde das Chromium-Projekt, das zur Grundlage für den neuen Edge wurde. Und so mussten wir den Prozess durchlaufen, es wie Edge aussehen zu lassen und die Funktionen hinzuzufügen, die wir in Bezug auf die Synchronisierung benötigten, indem wir Microsoft-Konten verwendeten, all diese Dinge.

Aaron: Der neue Edge teilt also keine Abstammungslinie im traditionellen Sinne mit dem alten Edge, das Edge HTML war, das von Trident geerbt wurde und so weiter und so fort. Und Sie können für die meisten davon den ganzen Weg zurück zu Mosaic gehen.

Aaron: Aber ja, jetzt ist das neue Edge Chromium, das auf WebKit davor basiert, das auf KHTML basiert und so weiter und so weiter. Es ist also eine völlig andere Abstammung als die vorherige.

Drew: Also, ich meine, das ist eine gewaltige Änderung, nicht wahr, dass Microsoft keinen Browser mehr hat, der aus seinem eigenen Code stammt. Aber nimmt tatsächlich ein Open-Source-Projekt und erstellt daraus einen eigenen Browser. Was ich denke, ähnelt dem, was Apple damals mit WebKit gemacht hat. Was, war es KHTML, das sie …?

Aaron: Ja, es war Konqueror war der … mit einem K.

Drew: Ja, Konquerer, also nahmen sie dieses Open-Source-Projekt und daraus wurde Safari. Und so macht Microsoft mit dem Chromium-Projekt Ähnliches und hat Edge daraus gemacht?

Aaron: Richtig.

Drew: Wenn ich mich als Webentwickler vor Edge setze, ist das, was ich sehe, einzigartig für Edge, was würde ich sehen, was ich nicht sehen würde, wenn ich mich vor Chrome setzen würde Beispiel?

Stephanie: Viele der Funktionen in dieser ersten stabilen Version sind derzeit verbraucherorientiert. Es kommt also Collections heraus, was eine ziemlich coole Art ist, Sachen aus dem Web in einzelne Sammlungen zu ziehen, daher der Name. Und Sie können diese Daten nehmen und sie in eine Art Seitenbereich einfügen und sie dann nach Word und Excel exportieren, glaube ich. Ich habe es für Designprojekte und andere Dinge verwendet. Es ist einfach cool, Ressourcen zu sammeln.

Stephanie: Eine der anderen Funktionen für Unternehmenskunden, die nur unter Windows verfügbar ist, ist der IE-Modus. Das wird Internet Explorer also tatsächlich innerhalb einer Registerkarte in Edge für Leute darstellen, die immer noch diese Seiten benötigen, die auf alter Technologie beruhen. Also das ist ziemlich cool.

Stephanie: Und was die Entwicklerwerkzeuge angeht, ist im Moment alles gleich. Ich weiß, dass wir einige Sachen in Kürze haben, die auf Chromium portiert werden, aber es gibt einen coolen 3D-DOM-Viewer, der in Arbeit ist und an dem das Team iteriert. Und es gibt einige andere Tools, die es in Chrome noch nicht gibt, die kommen werden. Das ist also spannend.

Drew: Das ist also eine große Sache für Webentwickler, nicht wahr? Weil ich denke, dass sich die Leute normalerweise daran gewöhnen, eine Reihe von Entwicklertools in ihrem Browser ihrer Wahl zu verwenden, und ehrlich gesagt ist das heutzutage für viele Webentwickler oft Chrome. Also zu Edge wechseln zu können und einen sehr ähnlichen Satz von Entwicklertools zu finden, muss ein ziemliches Unentschieden sein, denken Sie?

Aaron: Ja, ich denke schon. Ich meine, es ist die Art von Sache, bei der Sie genau das gleiche Werkzeugset haben werden. Wir bauen auf Chromium auf, einschließlich aller Entwicklungstools. Wie Stephanie bereits erwähnte, haben wir viel in den 3D-DOM-Viewer investiert. Wir haben viel investiert, um die allgemeine Zugänglichkeit der Entwicklungstools zu verbessern, neue Tools hinzuzufügen und an der Internationalisierung der Entwicklungstools zu arbeiten.

Aaron: Und wie Stephanie erwähnte, wird die überwiegende Mehrheit der Arbeit, die wir leisten, im Grunde alles, was nicht UI-spezifisch für Edge ist oder unsere Synchronisierungsplattform oder ähnliches betrifft, all das wird in Chromium gestreamt. Die Korrekturen, die wir vornehmen, die Verbesserungen, die wir für die Barrierefreiheit vornehmen, werden Chrome besser machen, Brave besser machen, Opera besser. Sie werden sogar Electron besser machen.

Aaron: Also, es ist wirklich schön, Teil dieses größeren Ökosystems zu sein. Und in der Lage zu sein, über unseren eigenen Browser hinaus Einfluss zu nehmen. Daher waren Entwicklungstools ein Bereich, in den wir viel investiert haben. Wir haben auch viel mit Partnern im Chrome-Team an progressiven Web-Apps gearbeitet. Und versuchen Sie herauszufinden, was progressive Web-Apps tun oder wie sie in Desktop-Umgebungen aussehen sollten, da der Schwerpunkt stark auf Mobilgeräten lag.

Aaron: Und dann gab es noch viel Arbeit zwischen dem Dev Tools Team und den Leuten, die an VS Code arbeiten, damit diese Tools besser zusammenarbeiten. Damit Sie im Wesentlichen vom Browser aus innerhalb von VS-Code auf die Entwicklungstools zugreifen können, während Sie Ihre Seiten debuggen. Und alles ist irgendwie miteinander verbunden, wie wenn Sie in den Edge-Entwicklungstools auf eine Stilregel klicken können, führt Sie das tatsächlich zu dieser Zeile im VS-Code in Ihrem Stylesheet. Was überwältigend ist, es ist wirklich cooles Zeug.

Drew: Das klingt wirklich spannend. Ich weiß, dass VS Code etwas ist, das in der Webentwicklungs-Community sehr viel Anklang zu finden scheint. Ich denke, es hat tatsächlich viele Leute zu Microsoft Tools zurückgebracht, die im Laufe der Jahre möglicherweise abgedriftet sind. Fühlt sich sicherlich wie eine andere Ära von Microsoft an, ebenso wie diese Art der Umarmung von Open Source und der neuen Version von Edge. Aus Sicht der Webentwicklung scheint das alles ziemlich aufregend und ziemlich erfrischend zu sein.

Drew: Auch aus dieser Sicht scheint dies eine wirklich große Erleichterung für Webentwickler zu sein, denn wenn einige der großen Browser, insbesondere Chrome und Edge, und Sie haben Brave und Opera erwähnt, was auch immer, alle das gleiche Rendering verwenden Engine, was vermutlich Massen von Kompatibilitätsproblemen und Browsern erspart, die nicht an vielen verschiedenen Stellen getestet werden müssen. Es sollte alles gleich funktionieren, ist das fair?

Stephanie: Ja.

Drew: Erstaunlich.

Aaron: Das ist der Traum, richtig?

Drew: Das ist immer der Traum. Es gibt jedoch ein wenig Anlass zur Sorge, nicht wahr, es reduziert eine Art gesunden Wettbewerb auf dem Markt. Während Microsoft seinen Browser vorantreibt, treibt Google seinen Browser voran. Apple bringt hoffentlich idealerweise seinen Browser voran, Opera und all die anderen Player. Und das schafft diese Atmosphäre des gesunden Wettbewerbs, in der jeder versucht, mit dem anderen Schritt zu halten und sich zu verbessern. Wenn viele große Player alle dieselbe Rendering-Engine verwenden, leidet diese gesunde Konkurrenz?

Aaron: Das ist etwas, womit ich definitiv zu kämpfen habe, da ich seit langem ein Experte für Webstandards bin, ich glaube nicht … Ich verstehe die geschäftliche Rechtfertigung dafür. Aus Microsofts Sicht machte es sehr viel Sinn. Und aus Sicht eines Frontend-Entwicklers ist es schön, sich nicht um einen Haufen verschiedener Engines kümmern zu müssen.

Aaron: Ich meine, im Großen und Ganzen haben diejenigen von uns, die schon lange im Web arbeiten, sicherlich eine Menge Konvergenz in Bezug auf das Rendering gesehen. Wir haben nicht mehr so ​​viele Probleme wie damals in den Tagen von Netscape 4.7, wo wir einfach so etwas hatten, wissen Sie, ich kannte Firmen, die einzigartige Stylesheets für jeden verschiedenen Browser erstellten, was einfach unhaltbar war.

Aaron: Aber ich denke, was jetzt irgendwie anders ist, ist, dass Sie damals in den ursprünglichen Browserkriegen all diese proprietären Engines hatten und jeder in einem Spiel der Überlegenheit war, wenn es darum ging, neue Plattformfunktionen und neue JavaScript-Funktionen auszuliefern . Oder im Fall von Microsoft Reverse-Engineering von JavaScript, um J-Script zu erstellen und herauszufinden, wie man alles zusammenfügt.

Aaron: Aber jetzt haben wir die Möglichkeit, tatsächlich in Open-Source-Projekten zusammenzuarbeiten und immer noch den Dialog zu führen und immer noch, ich weiß nicht, nicht das richtige Wort zu streiten, sondern ernsthafte Diskussionen über die Auswirkungen verschiedener Ansätze zu führen. Und einander widersprechen. Und wirklich daran zu arbeiten, die Spezifikationen wirklich gut zu machen. Und auch konkurrierende Ansätze für den zugrunde liegenden Code im Kontext von beispielsweise einem Chromium-Projekt oder WebKit oder so etwas oder Mozilla im Firefox-Bereich.

Aaron: Also ja, einerseits haben wir eine weitere Rendering-Engine verloren. Und ich fühlte denselben Schmerz, als Opera sich entschied, zu Chromium zu wechseln. Aber ich fühle mich etwas ermutigt, bei Microsoft zu sein und zu sehen, wie engagiert wir sind, tatsächlich auf sinnvolle Weise am Chromium-Projekt teilzunehmen. Und sich nicht einfach nur zurücklehnen und einfach alles akzeptieren, was Chromium nachgelagert kommt, sondern tatsächlich prüfen, was in die Plattform einfließt, und sich daran beteiligen.

Aaron: Das ermutigt mich ein bisschen und ich habe das Gefühl, dass wir nicht nur da sind, um von diesem Projekt zu nehmen und einfach alles zu akzeptieren, was von all den verschiedenen Leuten weitergegeben wird, die an diesem Projekt beteiligt sind. Aber auch dort tatsächlich mitzuarbeiten.

Aaron: Ich denke, wir müssen noch herausfinden, was dies für Standardisierungsgremien in Bezug auf interoperable Implementierungen bedeutet. Denn wenn Sie einige Browser haben, die entscheiden, dass sie etwas nicht implementieren wollen, können sie etwas davon abhalten, ein Standard zu werden. Auch wenn alle Entwickler dieser Welt es wollten.

Aaron: Und es ist vielleicht nicht so, wo sie damit nicht einverstanden sind. Sie haben möglicherweise einfach nicht die Bandbreite, um die Funktion zu erstellen. Alle drängen auf Personal und so.

Drew: Ich schätze wirklich, die Zusammenarbeit im Web als Plattform hat sich von allen, die sich darauf geeinigt haben, die gleichen Dinge in ihren individuellen Codebasen zu implementieren, zu einigen großen Akteuren verlagert, die im Wesentlichen auf der gleichen Codebasis zusammenarbeiten.

Drew: Ich meine, Sie haben kurz Meinungsverschiedenheiten erwähnt, und das ist offensichtlich etwas, das ein Problem sein könnte, denke ich, in jedem Open-Source-Projekt. Aber wissen wir, wie das funktionieren wird, wenn zum Beispiel Entwickler von Google ein Feature implementieren wollen und Entwickler von Microsoft das wirklich nicht implementiert sehen wollen? Streiten sie sich nur wegen GitHub-Problemen?

Aaron: Ich meine, viele dieser Dinge passieren offen, entweder bei GitHub-Problemen oder im Crbug, dem Bug-Tracker für Chromium. Ich bin kein Browser-Ingenieur, daher kenne ich nicht alle Details der Interna, aber ich glaube, dass es eine Menge Dinge gibt, die wir im Grunde ausschalten können, wenn wir sie nicht wollen.

Aaron: Und ich weiß, dass Google innerhalb des Chromium-Projekts an einer Art Aufräumarbeiten oder Haushaltsführung gearbeitet hat, um mehr von den Google-bezogenen Diensten und dergleichen zu extrahieren, bis hin zur Ebene der Konvertierung von Chromium zu Chrome.

Aaron: Und so haben wir einen ähnlichen Prozess, bei dem Chromium in Edge umgewandelt wird. Und natürlich möchten wir zum Beispiel nicht das Design der Edge-Benutzeroberfläche überprüfen. Oder die Sache mit Sammlungen, die eher eine UI-Benutzer-Fokus-Sache ist, die Stephanie erwähnt hat, wir streamen diese nicht in Chromium. Diese existieren in Art des UI-Teils.

Aaron: Also, soweit ich es verstehe, haben wir, wenn Funktionen aus Chromium kommen, die Möglichkeit, bestimmte Dinge abzuschalten, die uns gefallen oder nicht gefallen. Und ich weiß, dass Brave das Gleiche tut, weil sie einen ganz anderen Ansatz zum Datenschutz haben als Google. Und wir haben vielleicht eine etwas andere Einstellung als jeder von ihnen oder was auch immer Sie haben.

Aaron: Also ich denke, es wird Dinge geben, die an verschiedenen Stellen passieren. Bei einigen davon wird das Projekt vom Open-Source-Projekt in den Browser konvertiert. Einige davon werden innerhalb der Normungsorganisationen oder Interessengruppen innerhalb der Normungsorganisationen und so weiter sein.

Drew: Und ich denke, es funktioniert auch andersherum, nicht wahr? Sie haben einen Browser erwähnt, der nicht genügend Ingenieure zur Verfügung hat, um eine bestimmte Funktion zu entwickeln. Traditionell haben die Dinge in Standardgremien so funktioniert, dass wir mehrere verschiedene Implementierungen benötigen, bevor etwas als Teil des Standards akzeptiert wird. Offensichtlich muss das herausgefunden werden, wenn nicht so viele Implementierungen zum Testen verfügbar sind.

Drew: Aber zum Beispiel, wenn Microsoft ein Feature implementieren wollte und Google entschied, dass sie einfach nicht die Ressourcen haben, um dieses Feature zu implementieren, stand es nicht hoch genug auf ihrer Prioritätenliste, nun, möglicherweise werden sie es tun Holen Sie es sich trotzdem kostenlos, weil es einfach in das Open-Source-Projekt gestreamt wird. Und dann können sie darauf zugreifen und alle ihre Benutzer profitieren, ohne dass einer ihrer Ingenieure besonders viel Zeit für die Entwicklung aufwenden muss.

Drew: Ich meine, wenn Mozilla beschließen würde, dasselbe mit Firefox zu tun und einfach das Chromium-Projekt zu übernehmen, denkst du, dass das ein Problem für das Web wäre?

Stephanie: Ich meine, ich würde ja sagen, denn dann sind wir in dieser Browser-Monokultur und ehrlich gesagt, ich liebe Firefox. Firefox hat einige großartige Werkzeuge, die Chromium nicht hat. Das wäre, glaube ich, wirklich schrecklich zu verlieren. Und es ist irgendwie nett, eine Art unabhängigen Browser da draußen zu haben, der immer noch für das offene Web kämpft. Ich meine, wir kämpfen auch für das offene Web, aber ich denke, was Firefox tut, ist immer noch wichtig.

Aaron: Ich meine, ich frage mich irgendwie, was passieren würde, wenn es, sagen wir, Chromium oder WebKit oder ein Fork eines bestehenden Open-Source-Projekts wäre, was wäre, wenn ein Standardisierungsgremium die Rendering-Engine und die JavaScript-Engine kontrollieren würde. Und alle Browser-Hersteller trugen zur Entwicklung und Art der fortlaufenden Schaffung dessen bei. Wäre das unbedingt eine schlechte Sache oder wäre es eine gute Sache? Ich weiß nicht. Ich weiß nicht, was die Antwort darauf ist, aber es ist eine interessante Aussicht, dass, wenn … Browser nicht billig und belanglos zu bauen sind, insbesondere Rendering-Engines. Es wird wahrscheinlich relativ unwahrscheinlich sein, dass wir eine ganze Menge neuer Rendering-Engines und große Investitionen in diesem Bereich sehen werden. Weil sich so viele Unternehmen auf ihre Dienstleistungen konzentriert haben.

Aaron: Mit Apple, mit all seiner iCloud und seinem gesamten Ökosystem. Und Mozilla hat mit der Übernahme von Pocket und dergleichen einige ähnliche Dinge getan. Und dann gibt es natürlich noch die Google-Produktsuite, die Microsoft-Produktsuite usw. Und Brave konzentriert sich auf den Datenschutz und das grundlegende Aufmerksamkeitszeichen und solche Dinge. Jeder hat irgendwie sein kleines Ökosystem von Dingen.

Aaron: Also, ich weiß nicht, ob es ein großes Interesse geben wird, eine neue Rendering-Engine und eine neue JavaScript-Engine zu bauen, um die vorhandenen herauszufordern. Es ist also eine Art Frage, ob es weiterhin eine Art Konsolidierung geben wird. Und wenn mehr Leute aktiv an der laufenden Entwicklung interessiert sind und diese schwierigen Gespräche darüber führen, wohin sich die Engine und die Webplattform entwickeln, könnte das eine gute Sache sein, ich weiß es nicht. Es ist aber irgendwie ein interessantes Gedankenexperiment.

Drew: Das ist es wirklich. Der neue Edge klingt wirklich spannend. Ich habe ein bisschen mit den Betas herumgespielt und das genossen. Wie lange wird es Ihrer Meinung nach dauern, bis diese neue Version weltweit verfügbar ist? Weil es, ich meine, erst diesen Monat veröffentlicht wurde, nicht wahr, wir haben Januar 2020.

Aaron: Ja, am 15. Januar ging es im Grunde zur allgemeinen Audienz. Wir hatten also die Canary-Entwickler- und Beta-Versionen. Meine Güte, wann haben wir damit angefangen, Stephanie, erinnerst du dich?

Stephanie: Ich würde sagen vor sechs Monaten, aber ehrlich gesagt werfe ich das einfach raus. Ich habe das Gefühl, dass ich Canary seit gefühlten Monaten als meinen täglichen Fahrer verwende.

Aaron: Ja, ich denke, wir sind etwas verzerrt, weil wir damit angefangen haben, es eine Weile intern zu verwenden, bevor wir anfingen, es der Öffentlichkeit zugänglich zu machen. Aber ja, ich denke, ich möchte sagen, dass wir letztes Jahr auf der Build damit begonnen haben, es zu teilen, was im Mai gewesen wäre, ich glaube, als die Canary und vielleicht die Umleitungsroute, ich erinnere mich nicht, ob die Beta damals draußen war. Aber ja, die vollständig stabile Version kam am 15. heraus.

Drew: Sie sind also beide an einem Projekt namens The Web We Want beteiligt, das eine Art Initiative zwischen vielen verschiedenen Browserherstellern ist, richtig?

Stephanie: Ja, also The Web We Want , ich glaube, Aaron hat damit letzten Juni oder so angefangen und wir haben angefangen, darüber zu reden. Und ja, The Web We Want ist im Grunde eine Initiative und Aaron und ich waren die ersten, die es betrieben haben, aber wir hatten Interesse von anderen Browser-Anbietern und Leuten, die in diesen Teams arbeiten.

Stephanie: Und es ist im Grunde nur eine Möglichkeit, Feedback von Entwicklern zu Problemen zu sammeln, die sie im Web haben. Weil wir als Leute, die den Browser bauen, uns irgendwie auf die neuen glänzenden Dinge konzentrieren können, die wir implementieren wollen. Aber Entwickler, wie wir durch diese Initiative gesehen haben, gibt es eine Menge Dinge, mit deren Erstellung sie immer noch Schwierigkeiten haben, die im Browser nicht nativ sind. Das sollte jetzt wahrscheinlich gelöst sein, ist es aber nicht.

Stephanie: Und genau darum geht es bei der Initiative, herauszufinden, was diese Problembereiche sind, und diese dann zurück zu Browsern und Standardisierungsgremien zu bringen, wenn es sich um diese Art von Problem handelt.

Drew: Also, welche Art von Form nimmt das an? Machst du das persönlich oder läuft alles online?

Stephanie: Wir haben also zwei Komponenten. Sie können also zu webwewant.fyi gehen und ein Formular mit Ihrem Problem und Ihrem Anwendungsfall ausfüllen, auf den Sie im Internet gestoßen sind. Und dann waren Aaron und ich, ich glaube, wir haben, naja, ich glaube, wir haben sechs oder sieben Veranstaltungen innerhalb einer Konferenz oder eines Treffens veranstaltet.

Stephanie: Das sieht so aus, dass wir normalerweise eine 45-minütige bis stundenlange Sitzung auf einer Konferenz haben, mit der wir zusammenarbeiten. Und wir geben Leuten, die ihre Probleme, auf die sie im Internet gestoßen sind, eingereicht haben, die Möglichkeit, diese einer Jury zu präsentieren, die normalerweise aus Branchenexperten besteht.

Stephanie: Und zwischendurch haben wir normalerweise vier oder fünf dieser Probleme, die während einer Sitzung präsentiert werden. Und zwischen all dem haben wir unsere Jury, die über den Problemraum spricht, der präsentiert wird. Und ob es ein interessanter Problemraum ist oder nicht. Oder wenn sie denken, dass es für Browser-Anbieter sinnvoll wäre, daran zu arbeiten.

Stephanie: Und dann lassen wir unsere Juroren am Ende dieser Sitzung das ihrer Meinung nach dringendste Problem auswählen, das es zu lösen gilt. Und wir haben auch eine Publikumskomponente, sodass das Publikum für die Sitzung auch darüber abstimmen kann, was seiner Meinung nach das dringendste Problem ist, das Browseranbieter beheben sollten.

Stephanie: Und dann bringen wir diese Daten zurück zu unseren Teams. Und wir sind gerade dabei, herauszufinden, wie wir das auf die verschiedenen Browser-Teams verteilen können.

Drew: Gibt es irgendwelche herausragenden Merkmale, Vorschläge, an die Sie sich erinnern und die Ihnen besonders im Gedächtnis geblieben sind?

Stephanie: Also, es gab ein paar, aber das, was mir immer wieder auffällt, sind HTML-Steuerelemente, die immer wieder auftauchen. Und das fällt mir auf, weil ich gerade an einem Vortrag arbeite, in dem es um HTML-Steuerelemente geht und inwiefern es ein Problem ist, sie nicht formatieren oder erweitern zu können. Und deshalb ist es irgendwie cool zu sehen, dass sich dieses Feedback noch mehr wiederholt.

Stephanie: Es gab einige wirklich interessante, es gab eine für eine Quellansichtsreihenfolge oder einen Quellreihenfolge-Viewer in den Entwicklungswerkzeugen, die, glaube ich, damit zu tun hatten, Grid-Inhalte zu erfassen und zu sehen, weil man Dinge irgendwie aus der Reihenfolge bringen kann, und diese Art zu identifizieren, wie die Dinge durch die DOMs fließen. Also, ich denke, das wäre eine wirklich coole Sache, die in den Entwicklungstools implementiert werden könnte.

Aaron: Ja, es gab viele Einsendungen zum Thema Barrierefreiheit, was wirklich toll war. Eine andere, die sich auf Entwicklungswerkzeuge und Barrierefreiheit bezog, war tatsächlich, anstatt die Barrierefreiheitstests in einen eigenen Teil des zu verbannen, war es die Registerkarte Audits, ich denke, dort ist es derzeit, wie Lighthouse einige Barrierefreiheitstests durchführt, oder Sie könnten es verwenden Webhinweise oder Einblicke in die Barrierefreiheit und so weiter.

Aaron: Die Idee dahinter ist, tatsächlich damit anzufangen, einige der niedrig hängenden Früchte in Bezug auf Zugänglichkeitsfehler zu erfassen und diese zum Beispiel in der Konsole hochzusprudeln. Wenn es also sieht, dass Sie einige Bilder haben, denen Alt-Text fehlt, oder einige wirklich kleine Schriftarten oder nicht genug Kontrast, könnte es diese tatsächlich als Fehler in der Konsole ausgeben. Und das ist in der Regel der Punkt, an dem viele Entwickler überprüfen, ob ihre Sachen richtig funktionieren. Das würde es den Leuten ein bisschen klarer machen, dass sie Probleme mit der Barrierefreiheit haben, die sie angehen müssen.

Aaron: Und Sie könnten einige ähnliche Möglichkeiten sehen, dies in den Dom-Viewer oder die CSS-Inspektor-Tools zu integrieren, wo etwas als zu kontrastarm markiert oder ein Element mit einem bekannten Zugänglichkeitsproblem hervorgehoben werden könnte. So etwas wäre ziemlich interessant.

Stephanie: Ja, ich möchte das huckepack nehmen. Letztes Jahr wurde bei View Source in Amsterdam ein wirklich interessantes vorgestellt. Es ging darum, dass der Browser bestimmte Arten von Barrierefreiheitsproblemen automatisch für Sie behebt. Und nur mit Farbe und Kontrast oder vielleicht sind bestimmte Schriftarten nicht lesbar. Und der Vorschlag und die vorgestellte Fallstudie waren wirklich, wirklich gut durchdacht. Aber es stellt sich auch diese interessante Frage: Wenn der Browser anfängt, Dinge für Sie als Entwickler zu reparieren, werden Sie schlechten Code schreiben, weil Sie sich darüber keine Sorgen machen müssen.

Stephanie: Es war also interessant, weil die Ideen, die er vorbrachte und vorführte, wirklich cool waren. Aber das bedeutet das für Entwickler, also werden sie faul werden? Also, ich habe einige coole Sachen gesehen, die dabei herausgekommen sind.

Drew: Also ich denke, es ist noch ziemlich früh, nicht wahr, für die Initiative. Ich schätze also, wir haben noch nie gesehen, dass irgendetwas so weit gegangen ist, dass sogar frühe Entwicklungsstadien mit Browsern erreicht wurden. Wissen Sie, wie dieser Prozess aussehen wird, Sie sagten, Sie versuchten immer noch, es herauszufinden, ist das richtig?

Aaron: Ja, wir versuchen alle immer noch, es herauszufinden, aber wir haben die richtigen Leute involviert. Wir haben Leute von Mozilla und von Google und auch von Igalia, sie waren diejenigen, die einen Großteil der Grid-Arbeit gemacht haben, und sie sind sehr vertraut damit, wie all diese Standard-Sachen funktionieren. Tatsächlich denke ich, dass sie gerade Methanol machen und die Implementierung für WebKit machen.

Aaron: Also ja, wir haben eine Menge Leute an Bord, die daran interessiert sind, daran zu arbeiten, und die daran interessiert sind, dass es erfolgreich wird. Und das W3C achtet auch darauf, was cool ist.

Stephanie: Also, für uns haben wir im Moment die, ich glaube, wir haben 12 Top, wir haben die Gewinner von jedem Event des letzten Jahres genommen, und ich habe sie irgendwie in ihre spezifischen Kategorien eingeteilt. Einige konzentrieren sich also auf Entwicklungstools, andere auf HTML, Webplattformen. Und dann kann ich mich nicht erinnern, was die dritte Kategorie war, es war nur irgendwie allgemein.

Stephanie: Und so fangen wir auf der Edge-Seite an, uns zumindest damit zu befassen, ich werde hoffentlich bald ein paar Twitter-Umfragen veröffentlichen, um mehr Feedback zu sammeln, um zu bestätigen, dass dies Problembereiche sind, in die wir Zeit investieren sollten in. Und dann werden wir hoffentlich von dort aus gehen. Ich hoffe also, dass wir irgendwann in diesem Jahr beginnen, eine Art Fortschritt zu sehen. Aber im Moment ist es ein bisschen langsam.

Drew: Das ist großartig, weil das Web tatsächlich eine sehr kollaborative Plattform ist. Und ich denke, als Webentwickler, der tagtäglich Websites erstellt, vergisst man, dass es tatsächlich Möglichkeiten gibt, in den Prozess einzugreifen und sich Gehör zu verschaffen. Und ich denke, das klingt nach einer wirklich großartigen, einfachen Möglichkeit, Ihrer Stimme Gehör zu verschaffen.

Drew: Wenn einer unserer Zuhörer zu einer Web-We-Want- Session kommen wollte, gibt es dann welche?

Stephanie: Es gibt ein paar, also lass mich meine Liste hier hochziehen. Also, naja, Open Source Festival in Lagos, Nigeria. Aaron und ich werden nicht dort sein, aber sie führen diese Veranstaltung eigentlich unabhängig voneinander durch.

Stephanie: Und dann werde ich Ende März bei SF HTML5 in San Francisco sein. Ich glaube, das ist kostenlos, aber zitieren Sie mich nicht dazu. Ich muss überprüfen. Wenn Sie sich also in der Gegend von San Francisco befinden, führen wir es dort aus.

Stephanie: Und dann die SmashingConf San Francisco im April. Wir werden es dort ausführen.

Stephanie: Und hoffentlich TBD, immer noch auf der SmashingConf Austin.

Stephanie: Und ich glaube, das ist alles, was wir im Moment im Kalender haben. Aber, um hier einen kleinen Beitrag zu leisten, wenn Sie eine Konferenz oder ein Treffen veranstalten und möchten, dass diese Community-fokussierte Sitzung dort abgehalten wird, wenden Sie sich bitte an, weil es wirklich cool ist.

Drew: Natürlich sind die SmashingConfs hier unserer Meinung nach die besten.

Stephanie: Ja, ja, das sind sie.

Drew: Für mich klingt das alles sehr, sehr aufregend. 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.