BROADCASTS.com

Diese Revision war eigentlich mit Thema geplant, aber ein spontaner famili\xe4rer\nNotfall hat unser Programm kurzfristig ge\xe4ndert. Mit dem einen verbliebenen der\ndrei geplanten G\xe4ste, n\xe4mlich Florian Geierstanger (Web / Twitter), sind Hans\nund Schepp daher auf eine weitere Runde Gl\xfccksrad umgeschwenkt.\n\n\nGL\xdcCKSRAD\n\n[00:03:40] \n\nDirekt als erstes schickt uns das Gl\xfccksrad auf eine Zeitreise weit in die\nVergangenheit, zu dem uns bislang unbekannten -Element. Dieses\nNetscape-spezifische Element schien zu formalisieren, was Entwickler*innen\ndamals mit dem sogenannten Spacer-GIF bewerkstelligt haben. Wie so oft, wenn\netwas in die Browser eingebacken wird, gab es eine Extra-F\xe4higkeit obendrauf: So\nkonnte man mit Hilfe des type-Attributs Abst\xe4nde auch nur in einer Achse\nerzeugen, was bei Bildern so nicht ging. 2010 schrieb der damalige\nMozilla-Entwickler Henri Sivonen anl\xe4sslich der Entfernung des dazugeh\xf6rigen\nCodes aus Gecko auch etwas \xfcber das Element. Schepp denkt an den HTML Tags\nMemory Test und \xfcberlegt, ob es dort wohl akzeptiert wird (wird es nicht).\n\n[00:12:35] \n\nAls n\xe4chstes geht es wieder leicht zur\xfcck in die Zukunft, und um das im Rahmen\nvon HTML5 eingef\xfchrte -Element. Hans erinnert sich, dass man es analog zu\nden \u2013 und -Elementen mit alternativen Dateiformaten f\xfcttern kann\nund der Browser pickt sich das heraus, was er abspielen kann.\n\n\n\nFlorian findet an dem Element doof, dass sich der Audioplayer beim Navigieren zu\neiner anderen Seite schlie\xdft. Schepp f\xe4llt zu dem Thema ein, dass es die Media\nSession API gibt, die u.a. dieses Problem ausr\xe4umen soll. Und Hans wiederum\nerinnert sich daran, wie er diese API im nie zum Einsatz gekommenen Working\nDraft Audio Player verwendet hat. Die Macher des Podcasts Wo wir sind ist vorne\nhaben das Problem (f\xfcr Navigationen innerhalb der Seite) mit turbolinks gel\xf6st.\n\nDesweiteren kommen wir auf Audio-Transkription und m\xf6gliche Wege zur Darreichung\nselbiger zu sprechen.Zwar gibt es den WebVTT-Standard und die dazugeh\xf6rigen,\nspeziell formatierten .vtt-Dateien f\xfcr Untertitel und Transkripte, aber leider\nkann sie das -Element nicht darstellen. Das macht in sofern Sinn, als\ndass die Abk\xfcrzung \u201eWebVTT\u201c f\xfcr \u201eWeb Video Text Tracks Format\u201c steht. Bleibt in\nso einem Fall also nur, auf ein -Element umzuschwenken. Verr\xfcckterweise\nkann aber auch ein -Element Video abspielen!\n\nWir sprechen dar\xfcber, dass wir hier im Podcast keine Transskripte haben, was\ndaran liegt, dass die uns bekannten maschinellen Tools gro\xdfe Probleme mit\nunseren Inhalten haben. Eine manuelle Transkription haben wir bislang nur einmal\nmachen lassen. Die war zwar exzellent, doch st\xf6ren wir uns an den\nArbeitsbedingungen in der Branche (\xfcber die wir erst im Anschluss daran\nerfuhren). Florian bringt eine neue AI-basierte L\xf6sung namens \u201eWhisper\u201c ins\nSpiel, die sehr gut funktionieren soll und die wir uns als Hausaufgabe\nmitnehmen.\n\nHans fragt, welchen m\xf6glichst einfach gehaltenen Audioplayer wir empfehlen\nk\xf6nnen, worauf uns eigentlich nur MediaElement.js einf\xe4llt.\n\nSchepp weist auf ein Learning hin, das er vor einiger Zeit hatte, n\xe4mlich dass\ndie HTMLMediaElement.play()-Methode im Standard und entsprechend auch in den\nBrowsern 2016 nachtr\xe4glich auf Promises umgestellt wurde.\n\nAbschlie\xdfend preisen wir die Tatsache, das man die Abspielgeschwindigkeit von\nMedien via JavaScript mit dem playbackRate-Attribut beeinflussen kann. Florian\nempfiehlt daf\xfcr ein Browser-Plugin namens \u201eVideo Speed Controller\u201c, das daf\xfcr\nauf Seiten die etwas abspielen ein Interface einblendet.\n\n[00:33:07] XMLHTTPREQUEST.STATUS\n\nGibt bei AJAX-Requests den HTTP-Antwortcode zur\xfcck. Ist der Request noch nicht\ndurchgegangen, steht der Wert auf 0 (Null).\n\n\n\nDas spannendste an der XMLHttpRequest-API ist seine Entstehungsgeschichte: Das\ndamalige Outlook Web Access Team (was Gmail, nur eben 10 Jahre fr\xfcher war)\nben\xf6tigte die API, um Inhalte dynamisch nachladen zu k\xf6nnen. Weil damals XML\nallerorten gehyped wurde, und alles mit \u201eXML\u201c im Namen gro\xdfe Chancen hatte, in\nden Internet Explorer eingebaut zu werden, kam man auf die Idee, die API mit\n\u201eXML\u201c zu prefixen und so in den IE einzuschmuggeln.\n\nAu\xdferdem erinnern wir uns an das Konzept von JSONP, das aber eigentlich\n\xfcberhaupt gar nichts mit der XMLHttpRequest-API zu tun hat, und mit dem man\nCross-Origin-Datentransfers vor CORS realisiert hat.\n\n[00:46:13] DAS ITEMTYPE-ATTRIBUT\n\nDieses HTML-Attribut stammt aus dem schema.org-Vokabular, welches Markup um\nstrukturierte Daten anreichert. Je nachdem, was f\xfcr eine Art Inhalt man damit\nauszeichnet, stellt Google diesen in seinen Suchergebnissen angepasst dar. Wie\ndas aussieht, kann man sich in Googles Such-Galerie anschauen.\n\n\n\nSchepp empfiehlt, heutzutage statt auf HTML-Attribute besser auf JSON-LD zu\nsetzen, weil man mittlerweile ja eher in Bauk\xe4sten denn in Seiten denkt und dann\nein zentraler Ansatz f\xf6rderlicher ist.\n\n[00:54:43] DIE @FONT-FACE-AT-RULE\n\nWir alle kennen diese At-Rule, um den Browser mit Schriften bekannt zu machen,\nund um diese dort einzustellen. Aber wusstet Ihr auch, dass das, was Ihr dort\nhinein schreibt, keine Properties, sondern Descriptoren sind? Hierzu f\xe4llt uns\nTab Atkins-Bittners CSS-Begriffe-Lexikon ein (in welchem Descriptoren allerdings\nnicht erw\xe4hnt werden).\n\n\n\nSchepp weist auf die recht neuen Descriptoren ascent-override, descent-override,\nsize-adjust und line-gap-override hin, die dem Finetuning der vertikalen\nPositionierung innerhalb einer Text-Zeile und des \u201eDurchschusses\u201c von Schriften\ndienen, aber vor allem Layout-Shifts beim Austauschen von Schriften per\nfont-display: swap verhindern sollen. Leider ein stark unterdokumentiertes\nFeature, von dem Schepp nur im Rahmen eines Talks von Jake Archibald gelernt\nhat. Florian kennt ein gutes Tool, um das einzustellen, n\xe4mlich den\nFallback-Font-Generator.\n\nIn Sachen Performance empfiehlt Schepp, @font-face direkt in das HTML zu packen,\num dem Browser fr\xfchzeitig die entsprechenden Infos bereitzustellen und ihn die\nSchriften nicht erst in einem extern liegenden Stylesheet entdecken zu lassen.\nVon Zach Leatherman gibt es dar\xfcberhinaus auch einen spannenden Talk zum Thema\n\u201eSchriften schnell laden\u201c. Nach seinem Talk haben wir noch ein paar Extrainfos\nim Rahmen eines Interviews aus ihm herausgequetscht.\n\nFlorian bringt das Thema \u201elokale Schriften\u201c ins Spiel. Neben der altbekannten\nlocal()-Funktion gibt es neuerdings auch die Local Font Access API, mit der man\nauch schon in gewissen Browsern herumspielen kann. Schepp meint sich daran zu\nerinnern, dass Figma diese API schon nutzt \u2013 aber das stellt sich wohl als\nIrrtum heraus.