 Leave no one behind, lasst niemanden zurück. Wahrscheinlich habt ihr dieses Hashtag schon mal irgendwo gesehen, online oder offline in den letzten Wochen und Monaten, die hinter uns liegen und die wir viele von uns nicht leicht waren. Lasst niemanden zurück. Mein Name ist Thomas Steiner. Ich arbeite für Google in Hamburg und heute möchte ich darüber sprechen, niemanden zurückzulassen und für moderne Browser zu bauen mit progressiven Verbessern, als wäre es 2003. 2003. In diesem Jahr haben Steven Champion und Nick Fink das Konzept progressiven Verbessern eingeführt. 2003. Das ist, wow, 18 Jahre her. Aber progressives Verbessern ist heute noch wichtig. Eine der Gründe für progressives Verbessern ist es, den Einsatz neuer Technologien und Strategien zu ermöglichen, ohne dabei einen Browser oder ein Gerät zurückzulassen. Lasst niemanden zurück. Aber was soll das heißen in der Praxis? Schauen wir uns eine ziemlich coole App an, an die ein paar von euch sich vielleicht aus der Zeit von Fenster 95 erinnern werden. Malen. Jemand hat malen einen JavaScript nachgebaut, sodass man es heute im Browser verwenden kann. Wenn du es ausprobieren willst, scan einfach den QR-Code auf der Folie. Mit dem Sprühdosen-Werkzeug kann ich auf die Leimwand malen. Zum Beispiel kann ich schreiben, lasst niemanden zurück. Aber da ich kein begnadeter Graffiti-Künstler bin, ist es vielleicht eine bessere Idee, das Textwerkzeug von malen zu verwenden. Also schreibe ich, lasst niemanden zurück, nochmal. Aber diesmal als Text. Wenn mir der vorgegebenen Stil der Arealschriftarten nicht gefällt, kann ich aus insgesamt 24 alternativen Schriftarten auswählen. Einer davon ist der ikonische Klassiker Comic Sans MS. Wenn ich allerdings in der Schriftartenverwaltung auf meinem MacBook nachschaube, sehe ich da 310 Schriftarten, die auf meinem Laptop instudiert sind, inklusive Wingdings, was sozusagen Emoji vor Emoji war. Und auch inklusive Google Sans, Google's Firmenschriftart, die ausschließlich auf dem Laptop von Google Angestellten instudiert ist und die es nicht anderweitig gibt, auch nicht als Webfund. Was der Browser von all diesen lokalen Schriftarten exponiert, ist nur die Gruppe der sogenannten Web-Sicheren Schriftarten. Dies beinhaltet weder Wingdings noch Google Sans. Die gute Nachricht ist, dass es einen Vorschlag für eine API namens lokalen Schriftarten Zugriffsapplikationsprogrammierschnittstelle gibt, so dass ich schlussendlich lasst niemanden zurück in Google Sans schreiben könnte. Du kannst da einen Bildschirmschuss des Entwurfs-Topments auf der Folie sehen. Aber bevor ich näher auf die lokalen Schriftarten Zugriffsapplikationsprogrammierschnittstelle eingehe, möchte ich noch erläutern, wo diese API eigentlich herkommt. Wenn du auf die Kopfzelle des Spec-Emburfs schaust, kannst du sehen, dass er von der Web-Plattform Brutkastengemeinschaftsgruppe veröffentlicht wurde. Wenn ich mich über den Link auf die Gruppe durchblicke, lande ich auf einer Seite des World Wide Web Consortiums, kurz W3C, von woher sich die Homepage der Gruppe erreichen kann. Die sieht so aus. Unten auf der Seite ist ein Link zur Satzung der Gruppe, was in der Sprache des W3C die Liste der Aufgaben ist, um les ich die Gruppe kümmern soll. Das ist die Satzung der Web-Enquator-Community-Gruppe. Wenn ich ein Messer runter scroller, kann ich da lesen, die Web-Enquator-Community-Gruppe stellt ein leichtgewichtiges Forum zur Verfügung, um neue Web-Plattform-Features vorzuschlagen und zu diskutieren, zum Beispiel die lokal schriftarten Zugriffsapplikationsprogrammierschnittstelle. Wenn ich weiterlesen, steht mir in der Satzung, dass jeder Vorschlag in seinem eigenen Depot innerhalb des GitHub-Kontos der Gruppe diskutiert wird. Wenn ich zurückgehe auf die Homepage der Gruppe, kannst du dort eine Riesenliste an Links auf GitHub-Depots sehen, in denen die Arbeit an neuen Web-Plattform-Features stattfindet. Wenn du Atelaugen hast, hast du vielleicht die Local-Fund-Access-API in der unteren Linken Ecke entdeckt. Niedelsrück zur Satzung, in der es heißt, wenn Vorschläge und Unterstützer gewinnen und stabiler und reifer werden, dass es dann in Betracht gezogen wird, sie in eine W3C-Arbeitsprobe zum Gerieren, wo sie ab Kurs Richtung Empfehlung gebracht werden können. Hm, auf Kurs Richtung Empfehlung. Was ist das? Zum Glück gibt es ein W3C-Dokument, das das erklärt. Passenderweise heißt es W3C-Prozessdokument und es beschreibt die organisatorische Struktur des W3Cs und seine Prozesse, Verantwortlichkeiten und Funktionen, die den W3C ermöglichen, seine Mission zu erfüllen. Irgendwo in der Mitte dieses Dokuments findet sich dieses Flussdiagramm des W3C-Standardisierungsprozesses. Du kannst sehen, dass Empfehlung der Endzustand in diesem Fluss ist. Wenn wir das Flussdiagramm nach rechts verschieben, dann wäre die Webplattform Incubator Community Group ganz am Anfang. Einige der Firmen, die bevollmächtigte in die WECG-Enzenten, sind Intel, Microsoft und Google, unter vielen anderen. Was besonders ist dann Intel, Microsoft und Google, ist, dass diese drei Firmen ihre Kräfte vereinigt haben, in einem Unterfangen namens Projekt Fugu. Projekt Fugu ist jetzt endlich der Kontext, wo ein paar Leute zusammenkommen, um zu diskutieren, wie Lokalinstellte, Schriftarten, Webindings oder Google Sands ihren Weg finden könnten in Applikationen wie Malen. Das Resultat dieser Diskussionen ist ein Wurf einer Spezifikation für eine Local Fund Access API, die wir ganz am Anfang gesehen haben. Nachdem ich jetzt erklärt habe, wo diese API herkommt, lass uns nun endlich schauen, wie man sie benutzt. Zuerst beginne ich mit Feature Detection, indem ich schaue, ob das Funds Interface im Navigator Objekt existiert. Denkt dran, ihr geht alles darum, niemanden zurückzulassen. Nicht alle Rouser werden diese API unterstützen, weshalb sorgfältige Feature Detection und progressives Verbesser nötig sind. Der nächste Schritt ist, um Erlaubnis zu fragen, um diese API zu benutzen. Das passiert mittels der Navigator Permissions Request Methode, der ich ein Objekt mit der Eigenschaft Name und einem Wert von Local Funds übergebe. Wenn der Start ist davon irgendetwas anderes als Granted ist, werfe ich einen Fehler. Anhandfalls mache ich weiter. Jetzt kann ich eine Liste aller lokale Schriftarten bekommen, indem ich Navigator Funds Query aufrufe. Das gibt mir einen asynchronen Interrate zurück, über den ich mit einer Vor-Off-Schleife iterieren kann. Jedes Fund-Meterdata-Element hat einen Postscript Namen, einen vollen Namen und eine Familie. Für mehr Details kannst du einen Artikel lesen, den ich geschrieben habe. Scan einfach den QR-Code auf der Folie, um den Artikel zu finden. Das ist dein brandneuer Vorschlag für eine API. Was bedeutet, dass ich im Moment eine Flag namens Fund Access im Browser setzen muss, um die API zu testen. Ich habe eine kleine Demo gebaut, die die API in Aktion zeigt. Du kannst hier reichen unter local-fund-access.glitch.me oder du scanst den QR-Code auf der Folie. Das erste, was ich sehe, wenn ich die App öffne und klicke, ist der Dialog, der mich um Erlaubnis fragt, die API zu nutzen. Der konkrete Text könnte sich noch ändern in der Zukunft, aber derzeit fragt nicht der Browser, ob er auf die Schriftarten auf meinem Computer zugreifen darf, sodass ich Typografie mit Vor-Wiedergabe-Treue erzeugen kann. Wenn ich den Dialog akzeptiere, erscheinen die Schriftarten in der Auswahlbox. Ich kann auf Schriftarten im Wendling suchen und jedes Schriftarten-Element aufklappen, um Schriftarten-Variationen zu sehen. Mich schon gesagt habe, es ist sehr früh im Leben dieser API. Also sollte irgendetwas komisch aussehen oder sich sonderbar anfühlen, kannst du und solltest du sogar Feedback geben. Im Spec-Entwurf-Document ist ein Link auf das Github-Depot, wo die Spezifizierungsarbeit abläuft. Wenn ich durchblicke, lande ich auf der Issues-Sektion des Depots und kann die existierenden Issues lesen oder kommentieren oder Neues erstellen, zum Beispiel um eine neue API-Form vorzuschlagen oder im Konsistenzen in der API aufzuzeigen. Problemen in der Spec-Eine-API sind das eine. Aber ein anderes Problem können Implementierungsfeder in Chrome sein. Jede API, an der wir arbeiten, hat einen Eintrag auf Chrome-Plattformstyles. Wenn du nach Local-Fund-Access suchst, kannst du alle Details zur Chrome-Implementierung finden. Für jede API gibt es einen Link zu einem Tracking-Bug, indem die Arbeit an dieser API getrackt wird. Wenn ich mich zum Bug durchklicke, kann ich alle Commits, Kommentare, zugewiesenen Software-Engineure und so weiter sehen. Falls ich ein Implementierung-Problem in Chrome feststelle, wäre dies der Ort, um das zu melden. Die Local-Fund-Access-API ist nur einer von vielen vielen APIs, an denen wir im Kontext von Projekt Fugu arbeiten. Mehr kannst du auf unserem Fugu-API-Tracker sehen, den du reißt, indem du den QR-Codes kennst. Wenn du den Fugu-API-Tracker aufmachst, kannst du all die APIs sehen, die wir schon ausgeliefert haben. All die APIs, die derzeit in Origin-Trails sind. All die APIs, die derzeit in Dev-Trails sind. All die APIs, an denen die Arbeit schon begonnen hat. Und schlussendlich all die APIs, die wir in Erwägung ziehen. Diese Werkzeit mag sich vielleicht ein bisschen überwältigend anfühlen. Aber keine Sorge. Das Google Developer Relations Team, den ich angehöre, hat Artikel zu allen derzeit nutzbaren APIs geschrieben, die leicht verdaulich sind und die alles enthalten, was Entwickler wissen müssen, um loszulegen. Du kannst alle unsere Artikel finden, indem du diesen QR-Codes kennst. Und denkt halt, was auch immer du brauchst. Lass niemanden zurück. Benutzt diese APIs als progressive Verbesserung. Wo immer möglich, versuche eine Basis-Version deiner App bereitzustellen, für Benutzer die Browser verwenden, die nicht die neusten APIs verwenden. Und damit vielen Dank fürs Zuschauen und frohes progressives Verbessern. Mein Name ist Thomas Steiner und ich werde versuchen, alle Fragen, die du hast, in den Kommentaren, per Twitter oder für E-Mail zu beantworten.