Du kannst es heutzutage nicht einfach die Emoji ausschließen.
Und schon das simpelste Smiley-Face macht halt deine String-Länge eins größer,
als sie tatsächlich ein Zeichen ist. Mhm.
Und noch einen kurzen Einwurf eben, bevor wir zum Counter-Style kommen.
Sorry, dass ich unterbreche, aber ich wollte halt eben nur, ehre wem Ehre gebührt,
noch kurz in den Raum werfen, dass bei Font-Size-Adjust immer noch bei Chrome nix geht.
Was? Ja, während Firefox und Safari das ordentlich am Start haben und schon seit Ewigkeiten.
Natürlich gibt's halt den einen, nämlich den Performance-Pups. Seine Heiligkeit.
Shep, der erste, der natürlich hingeht und mit CSS-Containment da auch das letzte
Mikrosekündchen aus seinem Frontende-Rendering rauskratzt. Ist ja klar.
Aber ich hab die alle schon wieder zurückgerollt. Liebe Hörer.
Music.
Und Hörerinnen, Feiert am 7.1.
Von 15 bis 18 Uhr mit uns die 600. Podcast Episode bei einem einzigartigen Online-Event.
Denn wir veranstalten eine Fischbowl-Diskussion. Bei einer Fischbowl-Diskussion
können einige Teilnehmer und Teilnehmerinnen im Kreis diskutieren,
während andere im sogenannten äußeren Kreis zuhören und dann einsteigen können.
Wir freuen uns sehr auf diese interaktive und dynamische Form für einen Austausch
zwischen uns Web-Devs. Meldet euch über den Meetup-Link in den Shownotes an
und seid Teil dieses spannenden Formats.
Wir freuen uns schon sehr auf euch und jetzt erst mal viel Spaß bei der folgenden Revision.
Revision 597. Und wieder sind wir heute zu zweit. Da hätten wir zum einen den Peter. Moin, moin.
Und ich bin der Shep. Und in der letzten Revision haben wir uns die Neuerung
des aktuellen und der nun entscheidenden Safaris so ein bisschen als Thema genommen.
Und haben da so ein bisschen durch die Release
Notes aus der Stable- und Technology-Preview-Version durchgeschaut.
Und, ähm ... Ja, da wollen wir heute mit weitermachen. Vielleicht schaffen wir
uns heute durch den Rest zu arbeiten.
Vielleicht nicht. Mal gucken. Wir dürfen uns nicht am Ende von den Safari-Leuten überholen lassen.
Wenn die schneller Sachen releasen, als wir Sendungen aufnehmen, haben wir ein Problem.
Ja, das fände ich gut. Ja, dann lass uns loslegen.
Okay, dann würde ich sagen, fangen wir mal mit dem an, den wir im Prinzip noch
in das Release von letzter Revision, die 178, hätten reinbauen können, wenn wir wollten.
Aber wir haben einen thematischen Cut gemacht und nicht mehr über die Cookie
Store API gesprochen, wo es in Safari jetzt neu das Change Event gibt,
das unterstützt wird, bzw. in der entsprechenden Technology Preview.
Und allgemein gibt es die Cookie Store API. Das ist ja im Prinzip einfach Cookies,
aber mit einer API, die nicht komplett zum Abgewöhnen ist, oder? Ja, genau.
Also Asynchron, eine Get-Methode, eine Set-Methode, eine Get-All-Methode,
eine Delete-Methode und nicht irgendwelchen kryptischen String-Manipulationskrempel.
Ja, genau. So wie man das eigentlich von, ja, weiß ich nicht,
ist das, wie nennt man das, ist das Iteraturen oder sowas?
Also sowas wie irgendwie Set und Map und so?
Nee, das würd ich nicht sagen, also Iteratoren sind das nicht.
Das ist ja alles auch asynchron, es sind doch keine asynchronen Iteratoren.
Aber es sind halt eben vernünftige APIs.
Cookies sind ja ein Key-Value-Speicher, machen wir uns nix vor.
Und die bisherigen APIs haben das ganz gut verborgen, dass das eigentlich unter der Haube der Fall ist.
Und das bedient sich jetzt halt wirklich wie eine Map mit eben einem Key-Value-Speicher.
Ja, genau, und wurde auch höchste Zeit, das ist ja so eines der ...
Eines dieser Dinger, die es schon irgendwie lange in Browsern gibt,
und die aber irgendwie nie, also die unzureichend irgendwie unbefriedigend waren in der Benutzung.
Weil ein Cookie ja letztlich im Grunde nur aus einem großen String besteht.
Und ich glaube, du konntest ja in JavaScript, wenn du document.cookie gleich
machst, ich meine, war das dann nicht so, also da konntest du dann einen einzelnen Wert hinzufügen?
Also es war sozusagen, oder man kann die ändern.
Und wenn du das dann aber ausgelesen hast, hast du immer den gesamten String
bekommen. Ich weiß nicht mehr genau, wie es war.
Vielleicht ist es aber auch, in beiden Fällen immer manipuliert man den gesamten String.
Auf jeden Fall muss man sich dann eben viel drum herum bauen,
mit dem man dann den String splittet und passt und so weiter.
Genau, das ist genauso, wie du beschrieben hast.
Und ich meine, ich kann ja verstehen, wie man zu der API kommt.
Weil am Ende sind es halt eben alles Strings, aber die Strings sind ja bloß
ein User-Interface für den Key-Value-Store.
Und Document Cookie ist halt wirklich so die banalste Implementierung von dem,
nämlich dieses Implementierungsdetail, dass es sich als String manifestiert,
nehmen wir tatsächlich auch als API.
Und dann, genau, hat man entweder manuell String Splitting betrieben oder man
hat halt irgendeine Library benutzt, die halt sowas wie den Cookie Store implementiert
hat. Derer gibt es viel zu viele.
Also asphaltierbar. Damals in jQuery gab es doch da auch schöne Utilities.
Ganz genau, ganz genau. So krempel halt eben.
Und so gehen wir halt eben jetzt hin und sozusagen vereinheitlichen halt das,
was alle sowieso wollen, nämlich den Key-Value-Store als Key-Value-Store benutzen
mit einer ordentlichen API.
Und jetzt kann halt eben das auch der Safari, beziehungsweise der kann halt
auch dieses Change-Event. Und jetzt haben wir halt nur noch den Firefox,
der das nicht so richtig kann.
Also nur unter der Annahme, dass es halt jetzt demnächst auch wirklich im realen
Safari landet, wenn nicht gar schon benutzbar ist.
Genau, also ich habe ja gelernt, dass diese Technology-Previews,
auch wenn die herauskommen, bevor ein Stable-Browser released wird,
das dann nicht unbedingt bedeutet, dass die Features dann auch in dem davorigen Stable drin sind.
Ich glaube, vieles von dem, was wir jetzt hier besprochen haben in diesen verschiedenen
Podcast-Teilen wandert auch in den 17.2er rein,
der jetzt auch irgendwann ansteht oder vielleicht rauskommt,
wenn diese Folgen auch rauskommen.
Ja, ich hab grad nochmal geschaut, hab hier den Mozilla Bug Tracker,
den entsprechenden Eintrag gefunden, wo dieses Ding implementiert werden soll.
Sie haben halt so ein Proof of Concept implementiert, aber sonst ist auf diesem
Issue nicht so wahnsinnig viel los.
Gibt's denn dafür auch so ein Polyfill? Die API muss man ja schon mal loslegen.
Genau, hier gibt es was von.
Joa, anscheinend schon.
Und sieht ganz gut aus.
Ist auch schon eine Weile alt. Also letztes Release ist aus Sommer 2020.
Aber muss auch sagen, der Chrome unterstützt es ja auch schon sehr lange, seit der 87er Version.
Das ist ja, was weiß ich, wie lange her. Und genau seitdem hat's ja nicht mehr
viel an der API-Oberfläche getan.
Also insofern muss so ein Polyfill sich dann auch nicht mehr,
muss auch nicht mehr weiterentwickelt werden, wenn er das alles dann abdeckt.
Okay, ich sehe gerade, dass tatsächlich bei der Cookiestore-API noch ganz schön
Bedenken bestehen bezüglich des Umgangs mit Nicht-UTF-8-Cookies.
Das ist irgendwie nicht ganz geklärt, wie sie damit umgehen sollen.
Okay, aber die Frage ist, wie geht denn Document.Cookie mit nicht-UTF-8-Cookies um?
Eigentlich müsste das vor den genau gleichen Problemen stehen.
Ja, es scheint halt nur so zu sein, dass es nicht spezifiziert ist.
Also z.B. Chrome, also nur laut den Issues, die ich jetzt hier gerade lese,
ist auch gleich alles in den Show Notes verlinkt, Werte Hörerinnen und Hörer,
aber zum Beispiel Chrome droppt dir einfach, also wenn der auf einen Cookie
trifft, der nicht UTF-8-codiert ist,
und man arbeitet auf dem mit Document Cookie rum, also nutzt Document Cookie,
um das abzufragen, dann taucht er da drin nicht auf.
Wenn der halt nicht korrekt dekodiert. Ja.
Ja, warum nicht? Also, die sollen ... Ja, okay.
Dann sollen die sich einfach mal einigen auf irgendein Vorgehen.
Dokument Cookie yields nothing if any of the cookies have non-UTF-8 values.
Aha. Und, äh, Cookies, äh, okay.
Und Cookie Store API gibt alle Cookies raus, inklusive derer mit non-UTF-8 values,
aber die enthalten dann keinen Wert.
Also, empty string. Das Hauptproblem scheint da zu sein, das Hauptproblem scheint
wirklich zu sein, man hat sich darauf nicht geeinigt. Weil ich meine,
Document Cookie kann ja so kaputt nicht sein, weil das ist ja im Moment das
Einzige, was es gibt und was alle benutzen.
Ja. Und möglicherweise würde man damit ja vielleicht durchkommen,
wenn man jetzt sagt, Document Cookie bleibt ja weiterhin da,
das kommt ja nicht weg, aber jetzt gibt es die schöne neue API und könnte in
dem Zuge ja ohnehin das, was de facto passiert, nämlich alle benutzen diese eine Codierung,
dann auch einfach da so rein implementieren, aber man müsste es halt wahrscheinlich
irgendwie aufschreiben und das scheint im Moment nicht der Fall zu sein.
Ja, okay. Naja, vielleicht, also ich meine,
ich weiß nicht, wie Safari das jetzt genau implementiert, aber wenn die das
so implementieren wie Chrome, dann hat man ja sozusagen schon irgendwann einfach
Fakten geschaffen. Dann ist das eben so.
Ich meine, das ist ja kein Drop-in-Replacement für die alte API,
wo man irgendwie kompatibel sein muss zu der. Da würde ich das ja verstehen.
Das ist jetzt ein komplett neues Ding. Und wenn die Regeln von Anfang an klar
sind und man benutzt das und die sich später nicht mehr ändern, dann ist es ja auch okay.
Ja, ähm, wie gesagt, es geht, glaub ich, ausschließlich darum,
den Standard Richtung Fertigstellung zu bringen.
Die Implementierung machen wir die Implementierung machen. Aber bevor man sagen
kann, das ist der neue Standard-TM, an den sich alle zu halten haben,
um dann auch so Hinterherkriecher wie Firefox zu motivieren,
dazu müsste, glaub ich, schon aufgeschrieben werden, was passiert,
wenn der Text komisch kodiert ist. Weil das könnte ja durchaus vorkommen.
Aber im Grunde muss man ja nur Reverse-engineeren, was Chrome schon lange shipped,
weil wir hatten ja in der letzten Revision auch über diese Import-Attributes gesprochen.
Da mit dem Assert und hier, wie ist es jetzt, wie heißt es jetzt,
With? Import-Attributes, genau. Genau.
Und ich meine, im Grunde ist das ja genauso. Also, das gibt's jetzt schon lange.
Das ist nicht hinter irgendeinem Feature-Flag, das ist nicht hinter einem Origin-Trial.
Und damit hat das Chrome-Team letztlich Fakten geschaffen, so ein bisschen wie
... Genau, auch wenn die nirgendwo niedergeschrieben sind, letztlich ist es
so. Und ist ja auch nicht schlimm.
Also, in Ermangelung einer Ansage haben die halt einfach gesagt,
wir machen das halt jetzt so.
Und dann, genau, ich find auch keine der Varianten jetzt irgendwie dramatisch oder doof oder so.
Nö, solange Document Cookie weiter da ist, ist das gut. Man müsste,
wie gesagt, nur entscheiden und offiziell sich für eine Variante halt,
dann müsste man sich darauf committen und das aufschreiben. Nur darum geht's, glaube ich. Ja.
Hey, wo wir grad bei Unicode sind, weißt du, was ich letztens festgestellt hab?
Nee. Die Segmenter API gibt es noch nicht in Firefox.
Okay, die kenne ich gar nicht, aber das, ja. Internationalisierungs-API?
Kennst du ja. Kenne ich nicht. Also, Intel, ja, aber das nicht.
Der Segmenter ist halt so, splittet dieses Ding, diesen String,
weil irgendwie so, weißt ja, String Length hat ja nichts mit Länge der Zeichen
zu tun, das sind ja die Unicode-Code-Punkte.
Und je nachdem, wie der Mond steht, kannst du ja alle möglichen Blödsinn machen.
Also angefangen bei so Dingen wie, Keine Ahnung, ein A mit einem Axon obendrauf
ist halt entweder ein A mit einem Axon obendrauf als ein Zeichen oder ist es
so die Kombination aus kleines lateinisches A plus Axon auf den Kameraden obendrauf.
Ja. So, das ist halt das eine. Das kannst du ja durch String-Normalisierung
und dann mit dem Iterator-Protokoll in den Griff kriegen.
Aber du hast ja auch Graphem-Cluster.
Also so Zeug wie Daumen hoch plus Hautfarbe in genau dieser Abfolge ergibt das.
Oder, keine Ahnung, Mann-Emoji, Zero-Width-Joiner, Handhalt-Emoji,
Zero-Width-Joiner, noch ein Mann-Emoji, hast du zwei Typen, die sich Händchen halten.
Und das kriegt das Iterator-Ding natürlich nicht hin, weil das halt eben sich
denkt, okay, das sind ja alles valide,
Unicode-Code-Punkte, teilweise zusammengesetzt aus Surrogate-Pairs,
aber jedes Emoji für sich ist halt eben so ein Eintrag.
Und das ist halt ein Graphem-Cluster. Und das kriegst du tatsächlich nur über
die Internationalisierung API hin, das zu splitten, ohne riesigen Aufriss zu haben.
Also wenn du wirklich sowas haben willst, wie, wie viele sichtbare Zeichen sind
da jetzt drin? Wenn ich eine Monospace-Schriftart habe, wie breit muss ich dieses Ding machen?
Das geht nur damit, und das gibt es noch nicht in Firefox. Da habe ich letztens
festgestellt und war völlig entsetzt.
Okay, ja, ja, ich mein, die haben natürlich auch einfach irgendwie im Vergleich
zu den anderen Engine-Betreibern deutlich weniger Women- und Men-Power.
Ähm, und, na ja, sie werden immer mehr zum Engine-Problembär.
Also nicht, dass das, was die anbieten, schlecht wäre, aber so featuremäßig
dauert's echt immer eine ganze Weile, bis Dinge in Firefox kommen.
Ja, das ist halt so das eine, wenn man jetzt irgendwie auf das Problem des individuellen
Browsers runterbrechen möchte.
Aber ich meine, stell dir vor, du baust eine Web-Anwendung und willst String splitten.
Mhm. So, geht halt nicht.
Ja. Es sei denn, du lädst irgendwie 7 MB Dependency rein, wo halt dann die ganzen
Unicode-Tabellen, die der Browser ja schon hat, nochmal in JavaScript nachgeladen
werden und ständig aktualisiert werden müssen und Zeug. Ja.
Und du kannst ja so Sachen wie ein String splitten. Einfach in JavaScript geht halt nicht so.
Also jedenfalls nicht im Frontend. Das ist schon ein bisschen krass.
Ja, das heißt, es braucht wieder mehr Open Source Contributions,
um sozusagen die Lücken zu füllen, die Firefox hat.
Theoretisch geht das ja, aber ist natürlich auch nicht trivial.
Nee, vor allen Dingen das Zeug ist nicht trivial.
Weil ich hab mich halt eben gefragt, warum ist denn so, das ist ja einfach Unicode, dachte ich mir.
Warum muss denn Stringsplitten in Grapheme Cluster irgendwie in der Internationalisierungs-API wohnen?
Ja, ist eine gute Frage. Weil du musst, wenn du das machst. Vielleicht hat das
aber auch mit asiatischen Zeichen zu tun, dass die vielleicht auch diese Features nutzen.
Und das dann sozusagen in beiden gut aufgehoben wäre.
Also sowohl im String als auch in dieser Internationalization API.
Und man dann eben gesagt hat, ja, ich mein, ja ... So Emojis,
schön und gut, aber letztlich irgendwie, es geht halt um Internationalisierung.
Und dann packen wir es da rein.
Genau, es stimmt halt so zum Teil. Also du hast zum Beispiel,
also diesen Segmenter, den kannst du halt verwenden, um das wirklich so auf
Grapheme-Cluster-Ebene zu splitten.
Oder du kannst auch so Sachen machen, wie splitte das zum Beispiel an Worte-Grenzen.
Und je nachdem, was du für eine Sprache hast, ist halt so eine Wort-Grenze schon sehr individuell.
Also so im Gesamtkontext der API macht das Sinn. Aber tatsächlich auch für das
reine Unicode-Problem, für das Grapheme-Cluster-Problem, tatsächlich brauchst du eine Sprache.
Weil du hast halt so Späßchen wie Türkisch, wo sie ja zwei verschiedene Is haben.
Und bei dem Design von Unicode haben sie das lateinische I recycelt für das
türkische I mit dem Punkt obendrauf. Also für das Kleine.
Das heißt, wie das jetzt zu bewerten ist, als was für ein Buchstabe oder gegebenenfalls
als eine Grenze irgendwie in dieser Segmentalogik, musst du tatsächlich für
so Dinge wie, was ist denn das für ein Buchstabe, oder halt eben ist das jetzt
Graffiti im Cluster, ja, nein, vielleicht, brauchst du tatsächlich immer die Sprachangabe dazu.
Ja okay, so ein bisschen wie halt hier diese Sanitizer API,
mit der man sozusagen ein safes inner HTML betreiben kann, das aber sozusagen
wissen muss, in welches Element wird denn jetzt injectet und was ist dann an
Elementen überhaupt erlaubt da drin?
So braucht man halt Kontext. Ja genau.
Also alles ganz extrem spannend. Man darf halt nicht, man muss da mal sehr aufpassen,
dass man nicht irgendwie in den Kaninchenbau reinfällt, wenn man da anfängt zu gucken.
Ja, ich glaube, das sind natürlich aber auch Kaninchenbaus.
Weiß ich nicht. Ist das ein Kaninchenbau, wissen zu wollen, wie viele Buchstaben in einem String sind?
Achso, das nicht, aber eben diese, alles was mit Sprache oder Internationalisierung
zu tun hat, ist ein Kaninchenbau.
Ich will doch nur wissen, wie lang mein String ist. Und da hängt halt zufälligerweise
der ganze Sprachkrempel dran.
Also ich, weißt du, muss man aufpassen, nicht in den Kaninchenbau zu fallen,
ja prima, der Kaninchenbau beginnt bei, wie viele Zeichen sind denn das?
Also schwierig, sich da fernzuhalten. Naja, oder du sagst halt,
in den meisten Fällen funktioniert halt in meinem Szenario String Length gut
und dann bleibt es halt dabei, so. Ja, nee.
Du kannst halt heutzutage nicht einfach die Emoji ausschließen.
Und schon das simpelste Smiley Face macht deine String-Length als größer,
als sie tatsächlich ein Zeichen ist.
Und wenn du irgendwie Krempel machst, der irgendwie genau sein muss,
dann ist das schwierig. Ja.
Na denn, wieder was gelernt auf jeden Fall. Ja, ich hätte drauf verzichten können.
Es wäre einfacher gewesen, wenn ich feststellen könnte, das geht ja einfach
so, weil dann hätte ich ja gar nicht weitergeforscht.
Allein das war mir nicht vergönnt und jetzt könnt ihr an meinem Leitteil haben.
Sehr gut, dafür ist unser Podcast da, das ist ja eigentlich hier sozusagen,
was ist das hier, Selbsthilfegruppe eigentlich?
Ja, das ist tatsächlich Selbsthilfegruppe, Therapie, Supervision,
ja auch so ein bisschen. Stimmt, ne? Mhm, stimmt.
Sollen wir zum nächsten super Themenpunkt springen? Das sollten wir.
Das Search-Element, darüber hatten wir, glaube ich, hatten wir eventuell auch
beim State of HTML gesprochen, bin ich nicht mehr hundertprozentig sicher.
Und Geast im Grunde, oder ja, Geast in Code, was man bisher vielleicht,
wenn man denn das korrekt gemacht hat, irgendwelche Elemente mit dem Role gleich
Search ausgestattet hat. Also im Prinzip so wie ...
Oh, das ist ein Element, das eine implizite Aria-Rolle mit sich führt.
Die eben auch Search heißt.
So wie Nav der Rapper für die Navigationsleiste ist, ist Search der Rapper für
das Suchformular. Ja, genau.
Genau. Also jetzt nicht bahnbrechend, aber einfach trotzdem schön, dass es das gibt,
weil dann benutzen das Menschen vielleicht und dann ist automatisch hat man
ein bisschen mehr Semantik in seinem Dokument.
Ja, gibt es irgendwo Usage-Statistik für das Role-Attribut?
Gibt's bestimmt, ich würd sagen, sechs Alter noch. Ich hab das Gefühl,
das ist irgendwie so geheimes Templar-Wissen, dass wir Nerds,
also wir zwei, die hier reden, und die drei, die uns zuhören,
wir wissen, dass das existiert.
Aber so die Leute, die den ganzen Tag damit beschäftigt sind,
halt da ihre WordPress-Webseiten und ihre Rail-Komponenten rauszuballern.
Ach so, ja, nee, nee, das glaub ich auch nicht.
Also, idealerweise muss man das ja auch gar nicht wissen. Das heißt also,
wenn man das richtige HTML benutzt ...
Ja, ja, gut, aber du hast es ja gerade beschrieben als einen sozusagen Ersatz für.
Also früher hätte man da ein ARIA-Attribut drauf gemacht.
Und nur darauf bin ich eingestiegen, weil ich nämlich jetzt gesagt hätte,
früher hätte man gar nichts gemacht, das wäre ein DIV gewesen,
und jetzt kriegt man erstmals einen ARIA-Roll, weil die meisten von diesem ganzen
Kreml weil wir gar keinen Plan haben.
Und insofern ist das tatsächlich ein größeres Upgrade, weil,
hey, dann ist das jetzt plötzlich überall drauf, wenn man den Leuten sagen kann,
hier, HTML-Element, mach dein CSS einfacher, sieht besser aus,
und du kriegst halt on top noch ein Barrierefreiheits-Feature.
Ja, ja, genau, also das ist ja irgendwie immer der Hintergrund für so neue Elemente.
Also nicht nur, dass man irgendwie geforscht hat, benutzen die Leute ständig
irgendwie was mit ID, gleich in dem Fall Search, sondern eben auch,
haben die das dann auch entsprechend ausgezeichnet mit den ARIA-Roles? Nee, natürlich nicht.
Okay, kein Wunder, wir haben ja auch kein Element, das das irgendwie inhärent mit sich bringt.
Lassen wir es einfach jetzt mal eins bauen, weil irgendwie braucht jede Seite Search.
Und dann können wir so ein Element auch mal irgendwie erschaffen.
Genau. Nee, also deswegen bin ich da sehr positiv für, Weil wenn's darum geht,
den ganzen Diff-Suppen Einhalt zu gebieten, helfen meiner Erfahrung nach die
Roller-Attribute nicht so viel.
Aber so diese groben Baustücke wie NAV und Search und Main und so,
die bringen dann die Welt insgesamt schon mehr voran. Mhm.
Guck mal, ich hab hier im Web Almanac von 2022, weiß gar nicht, noch kein 23er.
Die haben jetzt auch hier untersucht Main, Header, NAV und Footer.
Die ja auch entsprechende Aria, also die auch Aria-Rollen haben,
die nicht genauso gleich heißen.
Also, gibt Role Main, das passt zu Main. Dann Header hat Role Banner.
Nav hat Role Navigation. Und Food hat Role Content-Info.
Und genau, also Main hat ein Drittel der Seiten.
Und entweder ein Role oder ein Element haben zwei Drittel der Seiten für alle anderen.
Was aber auch irgendwie logisch ist, Weil Main kam ja viel später erst,
so wie Surge jetzt dazu kam. Genau, und ...
Seiten, die diese Rolle benutzen oder die explizit Role benutzen,
sind eher so im Bereich, sagen wir mal, 10 bis 20 Prozent.
Ja, und ich vermute, dass bei denen auch durch Komponenten-Libraries der Anteil
künstlich erhöht ist, weil da, glaube ich, die Wahrscheinlichkeit,
dass irgendwelche Hyper-Nerds sich da extra viel Sorge drum gemacht haben,
ist die Wahrscheinlichkeit ein bisschen höher.
Unterstelle ich jetzt mal. Genau, und man sieht aber auch, Einige,
die das sozusagen als doppelt gemoppelt auf das Element setzen,
für eben ältere Browser, die das Element noch nicht kennen und dementsprechend
von sich aus nicht diesen Role setzen.
Dieser Tage theoretische ältere Browser.
Genau. Und heutzutage wäre es ja so, könnte man sagen,
ja, benutze Search, und wenn du aber möchtest, dass alle Browser davon jetzt
auch profitieren, selbst die, die Search noch nicht kennen, Dann kannst du da
ein RollSearch noch zusätzlich doppelmoppelig draufsetzen.
Ja, kannst du machen.
Ich meine, da könntest du aber genauso gut einen Diff mit dem Roll nehmen, oder?
Genau, das würde im Grunde nichts ändern.
Also, ich bin da immer ein sehr großer Fan von, wenn man da die Möglichkeit
findet, irgendwelche semantischen HTML-Elemente noch einzubauen,
die wirklich überall so weitgehend standardisiert vorkommen,
wie halt eben Search-Formulare, dann ist super.
Ja, finde ich.
Genau, dann haben wir in Safari 17 also verfügbar Popover, Popover Target und Popover Target Action.
Ich weiß gar nicht, ob wir ... Wir haben auf jeden Fall in irgendwelchen Kontexten
schon darüber gesprochen. Du hast auf jeden Fall ... Wieder beim State of HTML.
Genau, dann verweisen wir da einfach hin.
Ja, das machen wir. Und nur in der Vollständigkeit halber noch,
Das ist damit jetzt, wenn es im Safari gelandet ist, tatsächlich überall vorhanden.
Auch im Firefox ist es drin. Es ist nur noch hinter Flags. Das muss wahrscheinlich
also noch ausgeschliffen werden.
Und dann wird es demnächst da auch freigeschaltet. Und dann kann man das wirklich überall benutzen.
Auf jeden Fall cool. Coole Neuerungen in den Webstandards.
Ja, ja, ja, ja. Habe ich auch direkt so eingebaut in meine in meine Präsentation,
mit der ich so über die Enterprise-Konferenzen tingle.
So, wir kommen in Frieden, neueste Übertragung aus der Frontend-Galaxie,
wo ich so den Java-Jungs und Mädels immer mal so zeigen möchte,
hey, es gibt mehr als ein DIV.
Und da kann man die natürlich irgendwie sehr gut kriegen mit irgendwie neues
JavaScript-Feature hier, und guck mal, Treibstoff hat was Neues erfunden.
Aber ich finde das immer besonders toll, wenn ich denen sagen kann,
guck mal, hat so HTML, muss überhaupt nichts zu machen.
Das kannst du auch in dein ältestes XML-Gerümpel noch einbauen,
in das du überhaupt gar kein kleinseitiges JavaScript reinbekommst.
Und dann wird es trotzdem ein bisschen besser.
Das gilt für Search wie für Popover. bin ich also auch ein extrem großer Fan von.
Genau, dann hat Safari, glaube ich, aber eigenmächtig was Neues eingeführt,
und zwar, dass man HRs, also ich würde sagen,
ich weiß nicht, so Trennlinien in Selects einbauen kann, um vielleicht so verschiedene
Gruppen zu kennzeichnen an, selektierbaren Optionen.
Ich glaub, damit sind die die Ersten, richtig?
Ich weiß nicht, ob sie die Ersten sind. Chrome hat das ab Version 119 auch.
Okay, der müsste gerade rausgekommen sein.
Oder es müsste im Begriff sein, hier rauszukommen, während wir das hier aufnehmen.
Ich hab hier schon 119 und ich hab ...
Also, die sind auf jeden Fall ... Also, ganz so eigenmächtig ist es nicht.
Ist es nicht einfach so, die machen das und der Rest folgt, sondern da scheint
das Agreement drüber zu geben, dass das wohl existieren soll.
Ja, genau, ist ja auch sinnvoll. Also, es ist jetzt kein irgendwie,
Buh, machen die, find ich doof, weil macht Chrome ja auch gerne mal.
Ähm, aber es ist eben selten, dass ein anderer Browser als der Chrome-Browser
mit solchen Dingen voranprescht.
Ja, was heißt voranpreschen? Es steht halt in den Standards,
Also dürfte es da wohl Agreement drüber geben, also passt das schon.
Ja, ist ja auch wieder ganz gut, weil auch das eventuell vielleicht ja in einigen
wenigen Fällen schon reicht, um so den Drive zur Select-Elemente aber mit 3.000
DIVs gebaut, vielleicht ein bisschen zu reduzieren. Ja, definitiv.
Weil ich meine, das Select hat ja viele Probleme, wir haben ja schon sehr,
sehr oft drüber geredet. und.
Vielleicht ist da ja eine Möglichkeit, da den Druck runterzunehmen,
tatsächlich einfach so ein paar mehr Dinge zu erlauben.
Was ich halt im Zuge dessen auch erst noch gelernt habe, ist,
dass man auch einfach Skripts in einem Select haben kann.
Okay, aber ich ... Genau, aber ...
Du kannst wahrscheinlich alles in Select-Zahlen stecken. Es wird nur alles ignoriert
wahrscheinlich, außer eben bestimmte Dinge wie Opt Group, Option und jetzt halt
neuerdings HR, oder? Ja, Moment, was heißt denn ignoriert?
Also, ich meine, der Parser muss ja irgendwas damit anstellen.
Na ja, genau. Also, ich hab's nicht ausprobiert. Ich würde sagen ... äh ...
Genau, also zwei Möglichkeiten. Das eine ist, dass es einfach nur nicht Weg
findet in der Darstellung.
Das andere ist, dass der Parser solche Dinge korrigiert und sie zum Beispiel
irgendwie hinter das Schließen-Attack des Selects, also so quasi hinterher rausnimmt
aus dem Element und es dann hinterher wieder einhängt,
so wie das halt bei manchen Dingen auch ist, wo irgendwelche Tags geöffnet werden,
und dann noch ein Tag geöffnet wird und dann wird aber erst mal das erste wieder
geschlossen und dann das zweite erst, was ja irgendwie nicht geht.
So, da haben ja Browser auch gewisse Mechanismen, wie sie damit umgehen.
Und ich könnte mir vorstellen, dass es bei den Selects auch so sein könnte.
Ich habe jetzt gerade mal, Spaß des halber, in ein Select-Element einen P-Tag reingeschrieben.
Wird tatsächlich nicht angezeigt, also taucht nicht im User-Interface auf,
aber der Text hinter dem P-Tag landet im Shadow-Root des Select-Elements.
Das heißt, das heißt, also das, okay. Moment, falsch, falsch,
falsch, ich habe es falsch gesehen.
Was passiert ist, die Tags werden weggestrichen, aber der Text-Content landet tatsächlich im Select.
Das ist also, was der Parser macht. Der schmeißt die ganzen Texte und Elemente
weg, aber der Textcontent bleibt drin und weil der aber in keiner Option steht, macht der nix.
Also, es gibt kein Warn-und-Warn-Effekt. Also, es sieht aus wie eine Option,
aber lässt sich nicht bedienen wie eine Option, oder was? Nee,
nee, ist überhaupt nicht da. Ach so.
In deinem DOM ist dieser Text drin, aber dargestellt kriegst du ihn nicht.
Genau, er ist nicht dargestellt, aber er ist da und auch nur der Text-Content
ohne die ganzen Text-Drumherum. Mhm.
Okay, ja, interessant, dass er das nicht irgendwie ganz rauswirft,
weil ... Aber gut, ist halt so. Ja.
Hätt ich jetzt auch gedacht. Aber nun, mei, ne? Ist vielleicht irgendwie relevant für irgendwas.
Aber ja, Scripts und auch Template-Elemente können im Select-Element stehen.
Ebenso wie halt hr, jetzt neu, und schon immer schon Options und OptGroup. Mhm.
Ja, okay, also Script und Style,
das ist dann quasi per Standard auch erlaubt, oder was? Style nicht.
Erlaubt sind Option, OptGroup, hr und die Script-Supporting-Elements,
und das sind Script-Tag und Template-Tag.
Von klein hat keiner was gesagt. Stimmt hast du, genau hast du nicht gesagt.
Und warum das so ist? Weiß man das? Script würde ich sagen, Document Right.
Kannst du ja über ein Script Options da rein kriegen. Ja, stimmt.
Template weiß ich jetzt allerdings nicht, warum man das würde haben wollen.
Vermutlich auch für so Use Cases wie das Template wird halt dann irgendwann
von einem Script interpretiert und dann ist da irgendwie Logik drin, JSON,
Handlebar, Syntax, irgendwie sowas.
Und damit drückst du dann aus, was am Ende wirklich da drin auftauchen soll,
frontend-seitig, würde ich jetzt raten.
Oder vielleicht für, kommt das vielleicht von diesem Select und dann Is,
also dieser, was ist das, wie nennst du das nochmal?
Diese Customize Build-Ins.
Das die sozusagen befähigt sein sollen, auch mit Templates zu arbeiten.
Das ist aber jetzt auch so eine Verschwörungstheorie. Was haben die damit?
Die haben ja mit dem Template an sich nichts zu tun.
Weil das ist ja bloß eine API, womit du da JavaScript draufhängen kannst.
Ich glaube, die Idee ist, Templates sind halt eben allgemein Templates.
Und so die Idee, irgendwie eine Liste auszudrücken über, keine Ahnung,
Select Element auf, Select Element zu und dazwischen halt eben ein Template,
dass dann irgendwie ausgewertet wird von irgendeinem Javascript,
ist jetzt ja nicht komplett irrsinnig, ne?
Und sozusagen die Logik des HTML-Parsers, die betrifft ja nicht nur den Browser,
sondern die betrifft ja theoretisch auch andere Implementierungen.
Also wenn du deine Template-Engine baust, ist es ja nicht beknackt,
irgendwie Syntax zu nehmen, die erst mal per se HTML und auch gültiges HTML ist.
Und in die Gültigkeit fällt halt mit rein, dass Templates in Selects existieren dürfen.
Und wenn das dann so eine, finde Templates und ersetze sie innerhalb,
ja, das Parents durch das, was das Ergebnis des Templates auswertend ist,
das macht schon irgendwie Sinn, glaube ich.
Also auch jenseits von Custom Elements oder so.
Ja, interessant. Das sind so die wichtigen Dinge, die man wissen muss,
auf jeden Fall für das nächste Web-Developer-Quiz,
bei der nächsten, was weiß ich, Nerd-Konferenz oder so. Genau,
da könnt ihr dann damit auftrumpfen, dass ihr noch wisst, was Document Right ist. Aha.
Okay, dann stürzen wir uns doch mal auf den nächsten Eintrag hier,
nämlich es gibt für Font Size Adjust jetzt in den aktuellen Webkit-Versionen
einen neuen unterstützten Value, nämlich From Font.
Font Size Adjust, erinnere ich mich noch, das war dieses Teil,
das die unterschiedlichen wahrgenommenen Größen durch die unterschiedlichen
X-Höhen bei unterschiedlichen Schriftarten aneinander angleicht,
sodass man die Dinger ähnlich aussehen lassen kann, auch wenn sie ganz unterschiedlich aufgebaut sind,
der optische Eindruck eben harmonisch ist.
Und dazu muss man immer irgendwie wissen, was die X-Höhe von irgendwelchen Schriftarten ist.
Ja, genau. Und oder man müsste sich auf einen Wert auch festlegen.
Und was man jetzt also, wo man das halt zum Beispiel braucht,
Dort ist beispielsweise in unseren Shownotes auf der Seite, da haben wir dann
eben, so wie jetzt in dieser Folge, das auch der Fall sein wird,
dann kennzeichnen wir eben Codeschnipsel mit dem Code-Tag und haben dann eben
ein Monospace-Font da drin.
Und der wirkt halt bei der gleichen Schriftgröße immer irgendwie komplett anders
als der Fleece-Text umherum. Und um das so ein bisschen harmonisch aufeinander
abzustimmen, da kann man dann eben die font-size-adjust verwenden.
Und da kann man jetzt eben from font machen. Und das bedeutet, dass er sich dann.
Orientiert an dem Font, der quasi drumrum liegt, meine ich.
Irgendwie so. Habe ich aber jetzt auch vor ein paar Tagen länger reingeschaut
gehabt, oder wie er wieder die Beziehung ist, sozusagen.
Da, from font, wie ist es denn hier? Was steht hier? Wichtig.
Also geht halt zu der Schriftart hin, die es schon gibt, und liest da aus,
was da die entsprechenden...
Ja, vielleicht hab ich's aber auch falsch erklärt. vielleicht ist es auch eher
so, dass er im Font-Stack guckt und dann sozusagen sich da bedient an dem ersten
Font, den er darin findet.
Genau.
Ich glaube, irgendwie so in die Richtung geht's.
Genauer kann man das selber nicht sagen, aber das ist zumindest die Zielrichtung,
wo man das benutzt. Und from font ist dann einfach nochmal, macht den Umgang
wahrscheinlich einfach ein bisschen leichter noch.
Hmm. The first available font, la la la la la, is defined to be the first font
for which the character bla bla bla, is not excluded by Unicode range.
Okay, also, die first available font ist die erste Schriftart,
die nicht irgendwie per Unicode range das Leerzeichen ausschließt.
Und richtig holt sie sich aus den Font-Families raus, die halt in der Font-Family-Property
angegeben sind, oder halt eben aus der Default-Schrift, wenn keine Font-Family definiert wurde.
Hinweis, ist egal, ob die Schrift tatsächlich ein Symbol für ein Space hat.
Das spielt keine Rolle, wichtig ist halt nur, dass Space nicht ausgeschlossen ist per Unicode-Range.
Das ist ja schön.
Genau, dann haben wir als nächstes noch Hyphenate-Character als CSS-Eigenschaft.
Also da kann man dann angeben, ob man Text trennen möchte mit einem anderen
Zeichen als dem Bindestrich.
Dann Counter-Style, da kann man dann irgendwie sein... Moment,
warte mal, warte mal. Was ist der Use-Case für Hyphenate-Character? Was ist der Use-Case?
Warum würde ich denn was anderes als einen Strich verwenden wollen?
Vielleicht auf ausgestaltuerschen Gründen? Okay, also irgendwie so ein Alternativ-Glyph,
wenn das irgendwie besonders mittelalterlich aussehen soll.
Genau, ich guck grad mal. Also hier in dem Beispiel haben sie ein Gleichzeichen verwendet.
Das weiß ich nicht, ob das irgendwie einen Hintergrund hat. Ich vermute nicht.
Ja, Specifications, see also. Genau, du guckst in die Spezifikationen.
Ich frag derweil mal den Wikipedia beim Bindestrich, ob es da irgendwie eine Geschichte gibt.
Wobei das ja so sein sollte, nehm ich an, Du brauchst ja für die Silbentrennung
sowieso die korrekt eingestellte Sprache.
Und dann müsste sich der Browser ja auch für das korrekte Zeichen entscheiden,
wenn es da Unterschiede bei den Sprachen gibt.
Ähm, äh, genau.
Okay, also es gibt, also die haben jetzt hier in den Specs ein Beispiel,
und da ist das Gleichzeichen wohl, entspricht dem Canadian Syllabix-.
Aha.
Was das wiederum sein soll, Canadian Syllabix oder ja, das weiß ich nicht.
Ja, ich sehe auch gerade, dass es da verschiedene Unicode-Zeichen gibt,
die man aus verschiedenen Gründen dafür verwenden können wollte, wenn man möchte.
Okay, ich bin überzeugt. Und noch einen kurzen Einwurf, bevor wir zum Counter-Style kommen.
Sorry, dass ich unterbreche, aber ich wollte nur, wem Ehre gebührt,
noch kurz in den Raum werfen, dass bei Font-Size-Adjust immer noch bei Chrome nix geht.
Was? Ja, wenn Firefox und Safari das ordentlich am Start haben und schon seit Ewigkeiten.
Okay, das muss man auf jeden Fall mal herausstellen, dass auch das gibt es.
Jaja, also ist hier nicht alles nur so, dass hier Firefox der Einzige ist,
der die Welt zurückhält. Mhm.
Genau, dann haben wir Counter-Style. Ich, äh, genau, da kann man einfach dann,
äh, eigene Arten von, von Countern, ähm, Counter-Stilen sozusagen definieren,
wenn einem so die vorgegebenen nicht reichen.
Äh, wir reden von CSS-Countern, richtig?
Ja, genau. Okay, wann hast du die zuletzt benutzt?
Ähm, also, äh, also in Auflistung natürlich.
Aber du meinst jetzt, ob ich die dann konfiguriere nach dem Motto,
hier, ordered list und dann bitte mit römischen Zeichen oder sowas?
Meinst du das? Also, ob ich das benutze? Das benutze ich eher selten.
Okay, dann ist das ja doch kein CSS-Counter, weil da gibt es ja dieses Ding,
das so wirklich diesen Inkrementierungsmechanismus hat und die am Ende einen
String irgendwo reinrendert.
Ach so, äh, ja, also diese Counter, die hab ich tatsächlich benutzt.
Äh, genau, aber es geht hier tatsächlich eher darum, ähm, das Aussehen festzulegen von, äh, Auflistung.
Ja, okay, das hab ich jetzt auch gesehen. Und weniger ums Zählen selbst.
Genau, okay, macht ja mehr Sinn. Also, das ist ein weniger absurder Use Case.
Ja, genau, aber den Zähler, den benutze ich, hatte ich auch letztens benutzt,
In einem Grid gebe ich einfach einen Index sozusagen per CSS weiter an die Kind-Elemente.
Und die können das dann aufgreifen, quasi dann bei so einer Top-Ten-List,
diesen Counter einfach nehmen und den dann anzeigen.
Weil ich könnte natürlich auch die Elemente selber counten lassen,
das würde auch gehen. Also das wäre aber ebenfalls dann der Counter.
Oder ich müsste es ansonsten eben ein Index per Template reingeben.
Also da müsste ich dann in einen Data-Index oder so in meiner Template,
meinem HTML hochzählen und in die Komponente reingeben.
Mochte ich aber nicht und habe ich dann eben hier mit dem Counter gemacht.
Und den kann man dann ausgeben.
Genau, den kann man dann ausgeben, genau, den kann man ausgeben.
So, man kann den übrigens auch nutzen,
um CSS-Variablen auszugeben, nämlich indem man den Startwert von einem Counter
auf den Wert einer CSS-Variablen setzt, und dann kann man den Counter ausgeben.
Also, falls das mal irgendwer braucht.
Also, anders kriege ich denn eine CSS-Variablen nicht in Content rein?
Genau, in Content klappt das, glaube ich, nicht, meine ich. Aha.
Okay, das ist ein sehr schöner Hack.
Und genau, was ich auch festgestellt habe, ist, also, wir hatten das Thema Footguns
ja schon irgendwie ein paar Mal.
Und Contain ist halt, ist eine von diesen CSS-Footguns.
Und da habe ich mich dann gewundert, dass das Account da nicht funktioniert.
Und habe dann gelernt, dass wenn man Contain-Style setzt, ich glaube,
Contain-Style war das, meine ich,
dass dann eben dieser Indexwert von außen nicht mehr hineingereicht wird in
dieser Art und Weise abgeschirmten Element.
Das hatte mich auch verwundert. Ich hatte erst so, oh, da ist ein Bug.
Hier wird das irgendwie nicht mehr aufgegriffen korrekt.
Dann hab ich aber in der Spec gelesen, ah ja, okay, das soll so sein.
Faszinierend. Ich hab im Kopf gehabt, dass das so ist. Ich dachte mir,
wird eh niemand verwenden. Niemand wird jemals darauf stoßen,
dass das passiert. Und siehe da.
So kann man sich täuschen. Einen gibt's.
Natürlich gibt's halt den einen, nämlich den Performance-Papst.
Dass seine Heiligkeit Shep der Erste, der natürlich hingeht und mit CSS-Containment
das letzte Mikrosekündchen aus seinem Frontend-Rendering rauskratzt.
Aber ich hab die alle schon wieder zurückgerollt, weil's immer so ein Side-Effekt
gibt, den man nicht haben will. Zum Beispiel ...
Äh, mag ich auf Bilder oder auf Elemente, die Bilder enthalten,
auch gerne so einen Contain-Strict in dem Fall zu setzen. Zusammen mit Aspect-Ratio.
Aber ich hab dann nicht bedacht, dass natürlich noch irgendwelche alten Browser
unterwegs sind, die kein Aspect Ratio können.
Und wo dann sozusagen die Höhe dann nicht festgelegt ist. Und wenn die Höhe
nicht festgelegt ist und du containst, machst dann kollabiert das ganze Teil.
Also, ja, es ist alles nicht so einfach.
Aber das müsstest du ja dann hinkriegen, indem du das Contain-Kommando von einem
Feature-Query mit dem Aspect Ratio abhängig machst, oder? Ja,
ja, genau. Das könnte ich machen.
Am Ende hab ich das Aspect Ratio ersetzt durch ...
Zumindest hier bei den Bildern nehm ich dann einfach ein SVG,
das die Aspect Ratio hat.
Das aber im Prinzip sonst leer ist. Und der Browser benutzt das dann sozusagen
als das Element, was sozusagen den Rahmen aufzieht. Spacer GIF 2.0.
Ja, so ein bisschen. Ich könnte das natürlich mit dem Bild selbst auch machen.
Aber genau, also wenn ich dann sowas benutzen möchte wie Object Fit oder so,
dann muss ich ja bestimmt, also wenn ich z.B.
Immer 16 zu 9 Aspektratio haben will, aber verschiedenste Bilder da reinlade
und dann mit Object Fit die passend mache, dann brauche ich halt irgendeine Größe.
Und klar, genau, funktioniert das eigentlich ganz gut mit einem SHG. Faszinierend.
Dann im CSS-Bereich haben wir auch neu und vielleicht fast eine der coolsten Dinge,
nämlich, dass auch die letzten Accessibility-Probleme von Display-Contents beiseite
geräumt sind, offenbar.
Das war ja damals schon bei Display-Contents so ein Thema, aber in allen Browsern,
dass sozusagen diese Logik,
dass ein Element zwar im DOM-Tree ist, aber aus dem Render-Tree komplett spurlos
verschwindet und seine Kind-Elemente seine Position einnehmen.
Das hat wohl die Browser auf dem falschen Fuß erwischt, dass sowas überhaupt
eben möglich ist, und hat so einige Accessibility-Probleme dann aufgeworfen.
Und dann hat es ja relativ lange gedauert, bis die Browser das alles gefixt
haben. Dann war Safari noch so der letzte Problembär, was das anging.
Das ist wohl jetzt auch passé.
Und das ist deswegen gut, weil ich finde, Display Contents ist ein total nützliches
Werkzeug, gerade um irgendwie Dinge vielleicht responsiv zu gestalten.
Also weil du dann auf bestimmten Breakpoints oder auf bestimmten Größen möchtest
du vielleicht irgendwelche Hilfscontainer-Elemente haben.
Und in manchen anderen Breakpoints willst du die eben vielleicht nicht haben.
Weil du irgendwie Flex benutzt oder Grid oder so was.
Und Grid und Flex ja beide, also jetzt mit Subgrid, ändert sich das aber im
Grunde ja nur auf die unmittelbaren Kind-Elemente wirken.
Und wenn du dann auf einmal, wenn du dann möchtest, dass ein Enkelelement sich
einreiht in so ein Flex, dann steht dir ja sozusagen das Kind-Element irgendwie
im Weg, weil das dazwischenhängt in der Ebene.
Und das kannst du halt dann mit Display Contents aus dem Render Tree rausnehmen
und schon greift dann eben das Flex auf das Enkelelement.
Ich finde das ein sehr schönes Beispiel dafür, dass irgendwas konzeptionell
super einfach sein kann, aber in der Implementierung dann das genaue Gegenteil ist.
Du kannst jedem sofort erklären, was Display Contents macht.
Das Ding ist dann so, als wäre es nicht im Rendering Tree und dann nimmst du
das Flex Beispiel, das du gerade hattest und dann hat es jeder Mensch sofort verstanden.
Aber die Browser, ne? Mhm. Ja, äh, genau, also, ich mein, theoretisch könnte es ja auch so sein,
dass du eine gewisse, eine bestimmte ARIA-Landmark oder so hast,
auf dem Ding, das du auf Display-Contents setzt.
Und wenn's halt diese Landmark und diesen ARIA-Role und das ARIA-Attribut auf
einmal nicht gibt, wo der Browser das aber eigentlich bisher immer davon ausgehen
konnte, dass wenn ich dieses Kind-Element habe,
dann kann das ja nur Kind von folgendem Element sein.
Und dann muss ja diese Rolle oder diese ARIA-Property da sein.
Aber nee, ist es jetzt nicht mehr, weil es ist zwar im DOM-Tree,
aber es ist eben nicht mehr im Render-Tree.
Und was macht jetzt der Accessibility-Tree draus? Ja.
Und ich meine halt auch ganz jenseits von Accessibility. Was ist,
wenn du Display Contents auf ein Replaced Element anwendest?
Hab ich noch nicht ausprobiert, müssen wir mal machen. Ich kann dir sagen, was das macht.
Das ist so eins meiner schönen Beispiele für, wie gesagt, konzeptionelle,
einfach in der Implementierung komplex.
Es gibt tatsächlich in der entsprechenden Spezifikation, wo sie jetzt aktuell
ja ihr ganzes, im Prinzip, den Display ...
Das ganze Displaykonzept ja neu machen mit dem Outer und dem Inner.
Mhm. Und wo halt eben auch Contents drin definiert ist.
Da gibt's einen wunderbaren Anhang, wo die Liste der offiziellen Unusual Elements,
aufgeführt werden und wie die mit Display-Contents interagieren.
Und da hast du einerseits so die Replaced Elements, wie irgendwie Image oder
Select auch, wo die einfach zu Display-Non-Computen, weil die ja in dem Sinne
keinen Contents haben, den sie rendern können, also werden sie einfach unsichtbar.
Und du hast dann natürlich auch noch so Kandidaten mit ganz,
ganz besonderen, sagen wir mal, Rendering-Geschichten, wie irgendwie Legend
zum Beispiel, dieses unstylibare Monstrum da bei den Field-Sets.
Dass dann sozusagen dadurch einfach auch dem demagifiziert wird und tatsächlich
einfach nur seinen Content darstellt, was es ja normalerweise halt nicht tut,
sondern allerlei seltsamen Krempel noch on top macht.
Naja, und dann halt noch einen ganz anderen Krempel für SVG, MFML und Konsorten.
Aber es gibt offiziell unusual elements, also select, du bist jetzt aufgeschrieben als seltsam.
Ja, zu Recht. Zu Recht, halt nur für Profis.
Dann gibt's eine neue Media Query namens Scripting. Wo man, äh,
die kann die Werte haben, äh, none, ich glaub, partial, und,
äh, wenn man halt normal quasi, äh,
der Default ist, I don't know, weiß ich nicht. Äh, kann man gleich mal nachgucken.
Letztlich ... Partial ist cool, das könnte ich endlich meine JavaScripts beschreiben.
Die funktionieren so halb.
Ja, genau. Wenn die nur halb funktionieren, dann, ähm, genau,
Genau, dann ist das die Media Query für dich.
Äh, genau, aber letztlich geht's
darum, abzufragen, äh, kann ich Skripte ausführen auf dem Gerät und ...
Genau, ah nee, Quatsch, nicht Partial, sondern ... Partial hab ich jetzt woanders
hier im Kopf, Initial Only so.
Genau. Und Enabled. Genau, Enabled ist der Standardfall. Also,
JavaScript funktioniert, ist, äh, aktiviert.
Scripting None wäre, wenn ich im Browser, sofern ich das überhaupt noch kann,
JavaScript deaktivieren in den Settings, oder vielleicht einen Browser habe,
der das nicht hat, wie vielleicht der Lynx oder so.
Und dann Scripting initial only, dass man eben nur einmal zu Beginn JavaScript
ausführen kann, aber im Anschluss nicht mehr.
Das wäre wahrscheinlich, würde so Browser betreffend wie hier Opera Mini,
oder ich glaube auch hier der Amazon Silk, sind beides so eben Browser,
wo Server das Initial-Rendern erledigen und dann das Ergebnis an die Clients schicken.
Aber dann ist es eben nicht mehr sonderlich interaktiv in diesen Clients.
Ja, oder dein Drucker, ne? Auf den trifft das ja auch zu.
Also quasi, wenn du ein Dokument dann zum Druck schickst, meinst du,
ne? Das ist dann ... Genau, weil du hast ja dann nicht kein Script,
sondern das würde ja schon funktionieren.
Also von so Dingen wie Document.Write, die halt so in den HTML-Parts eingebaut
sind, bis hin zu wirklich so was, was sagt irgendwie, keine Ahnung,
Onload oder DOM-Content-Ready.
Ich baue hier ein paar Dinge um.
Aber über so Initial-Only kannst du halt eben zum Beispiel wissen,
dass niemand jemals was anklicken wird und dadurch irgendwie ein Skript laufen
lassen wird, dass dann irgendwie das Ding aufpoppt.
Also machen wir lieber alles auf Displayblock.
Ja, jetzt ist halt natürlich, gerade wenn ich hier so in den entsprechenden
Working Draft von den CSS-Specs reingucke,
dass tatsächlich bei Initial Only gar nicht so klar definiert ist,
also unter welchen Umständen sich ein Browser tatsächlich als Initial Only ausgeben sollte.
Mhm. Also, es ist ja ein Spektrum von wirklich so, also, ja,
Script an, Script aus, easy peasy. Aber Initial Only ist ja tatsächlich auch
... Wann ist zum Beispiel diese Initial-Phase vorbei?
Wann entscheidet zum Beispiel auch deine Druckpreview, wann sie fertig ist und
sagt, das ist das Ding, das ich hinterher zum Drucker schicke?
Wie viel Skript läuft halt noch dann? Ja.
Loadhandler, DOM-Content-Ready, was ist mit Timeouts, die ich im Loadhandler
gestartet habe? Mhm. Ich glaub, das ist gar nicht festgelegt, wa?
Äh, genau. Ich glaube, das ist auch der Grund. Ich glaube, der neue Safari unterstützt
auch nur die quasi an-aus Varianten und nicht diese,
weil das, und ich weiß auch gar nicht, ob ein anderer Browser das unterstützt. Ich gucke gerade mal.
Genau, CSS Media Scripting auf Can I Use und, und, und, und.
Also da steht jetzt nichts zu diesem Initial Only Browser Also,
Compatibility, hm, also angeblich.
Aber das ist ja das Problem damit, dass Initial Only nicht gut definiert ist,
weil wenn es nicht definiert ist, kann ja jeder sagen, wir können das. Ja.
Also gerade als Webbrowser, als normaler Webbrowser, kannst du ja halt wirklich
so sagen, keine Ahnung, mein Scripting ist ja entweder an oder aus, ich bin ja kein Drucker.
Ja.
Ja, und es, genau, es fängt, also man kann auch nicht solche Fälle abfangen, damit,
die ja häufig auftreten, dass irgendwie JavaScript zwar initial da ist,
aber dann aus irgendwelchen Gründen kaputt geht.
Weil's partial ist, weil's von mir geschrieben wurde. Ja.
Genau. Naja, ich weiß nicht genau, also, ich bin mir noch nicht ganz sicher,
ob das einen Riesenmehrwert bietet.
Also, so die bisherigen Methoden sind ja immer gewesen,
du setzt eine Node.js-Klasse auf den Root zum Beispiel, und dann führst du eben
ein Skript aus direkt im Anschluss, das das dann wegnimmt.
Und wenn eben Scripting deaktiviert wäre, dann bliebe es bei Node.js.
Ja, aber das ist halt so ein makroskopischer... Das ist so ein makroskopisches
Ding. Aber du würdest jetzt ja vielleicht eine Web-Component bauen wollen,
die funktioniert, aber trotzdem irgendwie einigermaßen gut druckbar ist.
Mhm. Aber warum nutzt du dann nicht AdMediaPrint?
Ähm ... Ja, okay, gut. Dann für den spezifischen Fall von Drucken sicherlich.
Aber dann haben wir halt eben auch noch, wie gesagt, so Fälle wie deine angesprochenen
Proxy-Browser, den Opera Mini und Konsorten.
Also, der makroskopische Ansatz mit der Node.js-Klasse funktioniert halt sehr
gut, sobald du halt die Seite als Gesamtheit in der Hand hast.
Aber sobald du sagst, ich bin irgendwie Komponentenautor sein,
und das soll dann überall funktionieren unter allen Umständen,
inklusive Drucker, inklusive Opera Mini, inklusive normale Browser,
dann ist das schon ganz gut, wenn du sozusagen auch auf der Ebene die Möglichkeit
hast, das zu steuern, unter der Annahme halt eben, dass dieses Initial Only
ordentlich supported und verstanden und korrekt implementiert ist.
Was ja im Moment nicht der Fall zu sein scheint. Ja. Also ich sehe das da auch eher weniger.
Also ich denke, da kannst du ja auch, du könntest ja auch sagen,
in meiner Komponente ist halt ein Script, dass auf der Komponente diese Klasse
wegnimmt oder eben aufsetzt oder so.
Das würde ja auch gehen, aber vielleicht ... Moment, worauf setzt du die Klasse?
Also, ich meine, die Web-Component existiert ja ohnehin nur,
wenn Scripting erst mal vorhanden ist. Ja, genau.
Aber sagen wir mal, also, du hast ja jetzt gerade diese Komponente genannt.
Ja. Als Beispiel. und sie könnte ja auch, die Komponente muss ja keine Web-Component
sein, die von JavaScript abhängig ist.
Dann könnte ich immer noch auf den Document-Root zugreifen, weil der muss ja quasi da sein.
Oder ich sage eben, ich scripte und lese aus auf dem Root dieser Komponente, auf dem Root-Element.
Ja, okay, also du kannst auf den DocumentRoot zugreifen. Was machst du dann mit dem?
Genau, dann kannst du da deine ... Setzt du da eben auch deine Klasse drauf
oder eben nimmst sie weg.
Nein, nein, nein, nein, nein, nein, nein, nein, nein, nein. Als dahergelaufene
Webcomponent modifizierst du nicht mein globales Dokument.
Du bleibst schön da eingeboxt zwischen deinen Tags.
Alles andere ist sehr, sehr uncooles Verhalten.
Okay. Dann brauchst du das natürlich.
Stell dir vor, du hast drei Komponenten von drei Autorinnen.
Und die machen alle das Gleiche mit ihrer Node.js-Klasse und setzen sich da
gegenseitig hin und nehmen sie sich gegenseitig wieder weg.
Die machen irgendwas asynchrones oder was? Nee, die würden natürlich,
weil die anständig programmiert sind, würden die natürlich Namespaces verwenden, ist ja klar.
Ja, oder wir nehmen einfach diesen Media Query und alles ist easy.
Oder das, genau. Also ich glaube, ich könnte mir vorstellen,
dass sowas vielleicht eher cool ist, da wo du Media Features benutzen kannst.
Also vielleicht in irgendwie responsiven Bildern. Vielleicht hast du da einen
Grund, warum du das ändern möchtest, wenn Scripting aus ist, keine Ahnung.
Oder wenn Scripting an ist, benutzt du ein SVG.
Und in dem kannst du dann rumwursten. Wobei das dann ... Ja,
das ist ja auch schwierig.
Egal. Ja, oder du hast ein SVG genau in dem ... Nee, in dem Scripte laufen.
Das geht ja auch wieder in den Bildelementen nicht.
Aber so in die Richtung, denke ich, so ein bisschen.
Ja. Es ist auf jeden Fall knifflig, aber zumindest mal der An-Aus-Schalter,
der ist jetzt in Safari drin.
Und ich nehme mal, das ist auch das, was die meisten anderen Browser,
die da bei Can I Use, sagen, Job, ich kann das meinen, wenn sie sagen, ich supporte das. Ja.
Genau. Dann in CSS haben wir noch ImageSet, jetzt ohne Prefix.
Das war vorher WebKit-ImageSet. Genau, und was Image, also das gibt's schon
auch mega, mega lange im Webkit und auch in Chrome, weil geforkt.
Und initial konnte das eben nur mit so einfach zweifach, dreifach,
Screen DPIs oder Screen Pixel pro,
Pixel, wie nennt sich das?
Punkt pro Pixel oder sowas erarbeiten. Du konntest aber jetzt keine anderen
Dinge angeben, wie zum Beispiel,
wenn du AWEF unterstützt, dann nimm dieses Bild aus dem Image-Set,
wenn du aber WebP unterstützt, dann bitte dieses.
Und das haben die jetzt auch standardkonform nachgerüstet.
Also der Startup wurde dann aufgegriffen und weiter ausspezifiziert und sieht
das eben vor und WebKit hat das eben jetzt angeprefixed und auch diese ganzen Dinge reingebaut.
Okay, wie sieht's bei den anderen Browsern mit der Unterstützung von dem ganzen Krempel aus?
Äh, ich glaube ... Chrome kann das auch, aber nicht Firefox.
Aber das werden wir gleich feststellen.
Also, Image-Set an sich können sie ja alle.
Ah ja. Hm ... Okay, nee, dann ...
Äh, genau, nee, tatsächlich können sie das alle. und der Safari ist halt jetzt
der einzige, bei dem es dann auch nicht mehr geprefixed ist. Ja.
In cursor and content properties, gradients are not supported as arguments to an image set. Wat?
Ich kann das in cursor angeben?
Wo hast du es gelesen? Was hast du nochmal gelesen?
Ich habe gelesen, ähm, ich bin in der Kompatibilitätstabelle bei MDN,
äh, untersteht, äh, in Cursor and Content Properties gradients are not supported
as arguments to image set.
Okay, ich hab hier auch den entsprechenden Backtracker Eintrag, äh, für die Details.
Äh, also ist das ein, also ich sehe das jetzt hier bei Can I use als Firefox Problem? Ja, genau, ja.
Ich bin nur gerade etwas entsetzt darüber, dass ich damit quasi mir einen Cursor
aus Gradients bauen kann.
Ja, warum nicht? Außerhalb von Firefox. Ja, klar, warum nicht?
Mhm.
Genau, und du kannst, also, auf die Nutzung von Linear Gradient bin ich irgendwie,
bin ich noch nicht gekommen, aber macht irgendwie Sinn.
Genau, man kann ja ein Bild angeben und ein Gradient ist ja nichts weiter als ein generiertes Bild.
Und du kannst wohl auch Kalk bei der Auflösung benutzen.
Also da, wo bisher immer ein 1x, 2x stand,
da unterstützen die Browser wohl auch die Nutzung von Kalk. wie auch immer das
dann aussieht. Ah, mhm. Okay.
Ja gut, aber ich meine, du brauchst es ja... Also im Image-Set, Kalk.
Ich meine, macht ja spätestens bei Gradients irgendwie Sinn.
Es ist halt nur etwas... Auf den Trichter muss man halt eben erst mal kommen.
Ja, ich versuche hier irgendwie mal ein Beispiel zu finden. Aber,
aber, aber... Naja, finde ich nicht.
Image-Set, CSS-Image-Set.
Interessant. Muss man mal im Hinterkopf behalten. Ja, ich find das halt wirklich
immer faszinierend, an so diesen Bugs an den Edge Cases.
Es ist halt wirklich so, du hast halt konzeptionell diese Dinger.
Also, ich meine, Image ist ja einfach nur eine Value in so CSS.
Einfach so ein Datentyp. Und den kannst du halt irgendwie da mit einem Gradient
hier basteln oder mit einem Image-Set oder sonst wie.
Und du würdest halt eben tatsächlich auch meinen, dass es dann einfach überall
an so Dinge wie den Cursor oder halt eben den Hintergrund von irgendeinem Diff
einfach so reingesetzt wird. aber dass da unter der haube wirklich gewaltige
aufriss betrieben wird, damit das einigermaßen einheitlich aussieht,
merkt man halt immer wieder an sowas.
Dass das halt nicht alles architekturtechnisch auch einzigartig,
äh, quatsch, einheitlich ist.
Okay, das wäre dann, würde ich mal sagen, das image set.
Und dann kommt jetzt eine ganze menge krempel, von dem ich exakt gar keine Ahnung
habe, aber es sind sehr viele Akronyme mit Großbuchstaben und Zahlen dahinter.
Und immer wenn das der Fall ist, dann riecht das für mich immer so nach irgendwelchem
obskuren Performance-Cramper. Also würde ich jetzt einfach mal an der Stelle
die Bühne dem Chef überlassen.
Ja. Also was JPEG XL ist, kann ich mir noch vorstellen.
Ja, was ist das denn?
JPEG 2.0. Und weil 2.0 irgendwie zu sehr nach Web 2.0 klingt,
hat man das XL genannt. Untertitel der Amara.org-Community,
Ja, genau. Also, genau. JPEG-XL ist ein neues Bildformat, das von Cloudinary,
also dem Bilder-Dienst, die bieten halt alles Mögliche rund um Bilder an.
Entwickelt wurde.
Und das, was daran ganz schön ist, ist, dass es in sich selber,
glaube ich, also auch eine JPEG-Schicht enthält, wenn ich recht informiert bin.
Und dann man sozusagen ohne Umrechnungsvorgang auch einfach das JPEG nehmen
und einem Client, der kein JPEG-XL kann, dann zuschickt.
Und wer JPEG-XL kann, der kriegt halt dann die volle Ladung.
Und genau der Vorteil von JPEG-XL gegenüber anderen neuen Bildformaten wie vielleicht
WebP oder Evive ist, dass es eben kein Spinoff von einem Videoformat ist.
Und das bedeutet wiederum, dass so Sachen wie Progressive Rendering unterstützt werden.
Das heißt also, JPEG XL kann sozusagen in vielen verschiedenen Detailgradschichten ein Bild.
Abspeichern und eben zurückgeben an den Browser und der Browser kann dann mit
eben herein immer mehr herein tröpfelnden Daten das Bild erst eben grob aufgelöst
rendern und dann immer immer feiner werden.
Also wie so ein normales progressives JPEG. Ja genau.
Ich habe das jetzt richtig Ich habe nicht verstanden, dass in dem Format eingebaut
ist. Also man gibt mir so eine Datei, dann ist da sozusagen durch schlaue Verfahren
drin die Daten, die ich als normales JPEG interpretieren kann und die Daten,
die ich als fancy JPEG interpretieren kann. Ja, genau. Und künstliche ist dann trotzdem kleiner.
Ich glaube, ich weiß nicht, ob es kleiner ist, ähm, aber es ist zumindest nicht
sehr viel größer und hat aber eben zahlreiche extra Features.
Also, die Feature-Liste ist auf jeden Fall lang. Also, ich glaub,
du hast dann auch ... Also, alles, was man so haben will, so Transparenz und
so, was bei JPEG nicht geht, ich glaub, das ist alles da mit drin. Hm.
Ähm, genau, aber so ein bisschen sträuben sich die Chrome-Macher gegen dieses
Bildformat, warum auch immer.
Also, die hatten das experimentell mal in Chromium-Browser drin.
Und dann, also hinter Flags. Und dann hat das Chrome-Team vor ein paar Monaten
gesagt so, ja, weil das halt keinen Uptake, also jetzt keiner nutzt,
jetzt keinen Uptake erfährt,
werfen wir das jetzt wieder raus aus der Codebase.
Und dann haben alle gesagt so, ja, aber wie soll das mit dem Uptake weil es
ist ja irgendwie hinter Flex, da geht das ja gar nicht.
Äh, ja, äh, weiter im Programm. So. Äh, la, la, la, ich möchte nichts davon hören.
Gehen Sie weiter, hier gibt's nichts zu sehen, außer unserem schönen WebP,
das ist doch viel besser.
Genau, also ich, keine Ahnung, was da die Motivation ist, vielleicht ist es
auch einfach kompliziert, dieses Bildformat irgendwie auch zu pflegen oder vielleicht
zu portieren auf andere Plattformen. Also, der Chrome-Browser bringt ja so seine
eigenen Decoder mit für alles.
Und der Safari zum Beispiel, der jetzt auch JPEG-XL unterstützt,
wie übrigens auch der Firefox, wenn ich mich nicht irre.
Oder auch nicht. Naja. Oder es ist auch Interflex. Die greifen auf die ... auf das OS zurück.
Also, je nachdem, was das Betriebssystem so unterstützt, unterstützt eben Safari
mal mehr oder mal weniger Bild- und Videoformate.
Genau, und das hat jetzt eben Einzug erfahren in Sonoma, also die aktuelle MacOS-Version,
und dann eben auch in den Safari-Browser.
Genauso wie Hike, also dieses High-Efficiency-Image-Compression-Format,
das, glaube ich, die iPhones intern benutzen.
Das kann man kann man jetzt eben auch im Browser verwenden für Bilder und AV1,
also der Videocodec, der wird jetzt auch unterstützt von Safari.
Also nicht AVIF, das Dateiformat für Bilder, sondern AV1, der Videocodec, von dem AVIF abstammt.
Aber noch mal kurz eben zurück zu den Bildchen. Also wenn ich mir jetzt hier
die Feature-Liste von JPEG XL angucke, dann könnte das ja, wenn ich es so richtig
sehe, tatsächlich ein Bildformat sein, sie alle zu knechten.
Weil der kann ja Animation, der kann ja Transparenz und der kann so progressives
Decoding mit so dem Effizienzgedanken. Ja.
Plus Lizenzfrei und so Gedöns. Ja. Wofür brauche ich den Rest?
Also was macht mir dieses Hike im Vergleich?
Ich kann es dir nicht genau sagen, also evtl. kann High Dynamic Range Crample
den JPEG-XL nicht kann, wobei ich glaube, HDR können die auch.
Ja, ist eine gute Frage.
JPEG XL liest sich auf jeden Fall gut. Vielleicht ist es eine Frage von,
was wird Hardware-dekodiert, was nicht, so ein bisschen.
Wobei das ja auch nur eine Frage der Zeit ist, bis dann irgendwelche Chips vielleicht
auch nativen Support für das Dekodieren von JPEG XL haben. Hm.
Also, okay, ein Gedanke, der mir halt noch kommt, ist, JPEG ist halt verlustbehaftet,
und vielleicht will man das nicht haben unter allen Umständen.
Aber ich mein, jetzt so für die generische Webseite. Verlustfrei komprimieren?
Verlustfreies JPEG-Transcoding mit einer Dateigrößeneinsparung. Was heißt das?
Genau, das ist dieses Transcoding, dass du quasi dann genau...
Verlustfreies Encoding, einschließlich Unterstützung des Alpha-Kanals.
Dann weiß ich wirklich nicht.
Ja, genau. Also eigentlich ein gutes Bildformat.
Und was vielleicht in dem Zusammenhang auch interessant ist und vielleicht auch
der Grund sein könnte, warum JPEG XL sich durchsetzen könnte in Zukunft,
oder zumindest in allen Browsern landet.
Es gab letztens einen Artikel von Jason Grigsby.
Und da ging's darum, dass wir jetzt ja die Container-Queries haben.
Und wir, wenn wir alles richtig machen wollen, ja jetzt keine Media-Queries
mehr nehmen, sondern nur noch Container-Queries. Wir aber das Problem haben,
dass die responsivee Bildernotation sich weiterhin stützt auf den Viewport.
Das heißt also, wir können ein Bild niemals optimal konfigurieren für ein,
sagen wir mal, Container-Konzept,
wo das Bild eben mal in einem großen Container ist und mal in einem kleinen
Container, weil wir ja nur, sozusagen,
das nur in einer Weise hart verdrahten können. Ja.
Also, die Idee ist jetzt auch nicht neu, aber sie ist jetzt eben noch mal aufgepoppt
im Kontext mit JPEG, XL und Container Queries, dass man vielleicht dem Browser das überlassen möchte,
zu entscheiden, bis zu welchem Punkt man ein Bild lädt.
Und bis es eben hoch aufgelöst genug ist und dass der Browser dann quasi selber
die Reißleine zieht und sagt so, okay, cool, bezogen auf die Größe,
die dieses Bild in diesem Container hat, reicht mir jetzt diese Datenmenge.
Und das kann halt JPEG XL leisten. Also, das wäre sozusagen ein Bildformat Escape
Hatch für dieses Problem. Hm.
Das ist natürlich nicht die optimalste Lösung, wenn du mich fragst. Warum nicht?
Das würde ja sehr viel Komplexität wegnehmen. Du würdest Bilder vielleicht in
Zukunft dann einfach gar nicht mehr responsiv einbinden, sondern nur noch als Image.
Aber eben das Bildformat ist ein JPEG-XL.
Aber wenn du dieses Problem sozusagen auf der Webstandards-Ebene als gelöst
ansiehst, weil es gibt ein Bildformat, das das kann, das wäre ja ein bisschen suboptimal.
Statt dass es der Standard aus sich selbst herauslöst.
Weil mit Bildformaten kann ja aller möglicher Blödsinn passieren,
wie kann ersetzt werden, findet kein Uptake, oder wird verdrängt von irgendwas
anderem aus irgendwelchen Gründen. Ich meine, das ist ja nun kein...
Es geht ja nicht um die Meriten von so einem Standard notwendigerweise,
wie eben einem Bildformat, sondern auch um alles Mögliche an so Externalitäten
wie irgendwelchem Lizenzgebimsel und so.
Gut, das stehe ich jetzt bei JPEG XL jetzt akut nicht an, weil irgendwie lizenzfreie
und BSD-Lizenz und so weiter.
Aber so rein vom Prinzip her, finde ich, sollte es für diese Viewport-Lösung
schon eine eingebaute Lösung aus dem sich damit befassten Standard hergeben.
Und nicht nur so unter der Ausnutzung von mehr oder minder technischen Details
eines bestimmten Bildformats.
Ja, die Webplattform arbeitet da auch an einer Lösung dran.
Und zwar so, dass Bilder, die du lazy-lädst, Die brauchen kein Sizes-Attribut mehr.
Weil das Sizes-Attribut im Prinzip ja nur ein Hinweis an den Browser ist.
Oder besser gesagt, nicht an den Browser, sondern sogar an den Ressourcenscanner,
der quasi vorweg über das Dokument saust.
Also, dass man dem sagt, hey, du hast, ist das noch nichts gelayoutet?
Keiner sieht das Bild bisher. Aber später wird es bei Mobile so breit sein.
Und auf Desktop so breit. Und du weißt ja jetzt, ob du Mobile oder Desktop bist.
Gehe das passende Bild schon mal holen. Aber wenn du ein Bild eben,
wenn ein Bild lazy ist, dann wird es ja sowieso erst geladen,
wenn das Layout da ist. Ja.
Weil nur dann entscheidet sich ja, ist das Bild jetzt im Viewport oder eben außerhalb?
Das kann man nicht am HTML alleine erkennen. Und dann braucht man das Sizes-Attribut
auch nicht mehr, weil der Browser die Infos hat.
Das heißt also, die Plattform arbeitet daran, das zumindest zum Teil zu lösen,
indem man eben für lazy geladene Bilder kein Sizes-Attribut mehr braucht.
Ist das schon so spezifiziert, oder ist das jetzt so in der Diskussion?
Ich glaube, zuletzt war es in der Diskussion, Aber möglicherweise ist das jetzt schon weitergedient.
Loading Attribute, Lazy Load Resumption Steps, ach du dickes Ei,
das sind viele rote Boxen hier.
Warte mal, das war, ich guck mal gerade, CSS Working Group war das,
auf GitHub eine Diskussion glaube ich, und dann Sizes und und und Lazy.
Das war die Miriam-Suzanne, glaube ich, die das vorgeschlagen hat. Ah ja, hier.
Oder die das, die da zumindest, äh... Oder da, wo ich geguckt hatte,
das vorgeschlagen hatte. Ich schmeiß dir jetzt mal einen Link rüber.
Ja, ich bläse nämlich hier gerade in den HTML-Specs erst mal.
Ja. Wie sie da das mit dem Lazy-Loading gemacht haben.
Und die nutzen ja tatsächlich einen Intersection Observer. Ist ja spannend.
Also, macht ja irgendwie Sinn für, ne? Ja, genau. Aber die benutzen tatsächlich
den Intersection Observer und nicht ein abstraktes Konstrukt,
das Intersection Observer-äquivalent ist.
Sondern es ist eine Intersection-Observer-Instanz.
Mhm. Also, ich muss jetzt gleich, wenn wir damit fertig sind,
mal mit dem Lazy-Loading-Attribut im Intersection Observer und Prototype-Patching
spielen, nur um zu gucken, ob das stimmt und was man da kaputt spielen kann. Mhm.
Beim CSS-Day hatte ich mit einem Chrome-Enginee gesprochen und den gefragt,
ob denn Lazy Builder die gleiche primitive unten drunter nutzt,
wie eben der Intersection Observer, weil ich hatte diese These irgendwann mal
hier im Podcast aufgestellt,
dass viele der neuen Webplattform-Features quasi unten drunter als Basis einen
der neuen Observer nutzt.
Aber der meinte, das sei nicht der Fall.
Also vielleicht ist das sozusagen eher sowas wie, Stellt es euch vor,
wie, aber wie ihr das dann konkret implementiert.
Ist euch überlassen. Intersection Observer wird hier tatsächlich benutzt,
und sie sagen, um Himmels Willen, das sollten wir eigentlich nicht tun.
Aber ich meine, die Frage ist ja auch tatsächlich, also, du kannst ja mit diesen
ganzen Spezifikationen, die sind ja immer nur so, dass die das beobachtbare
Verhalten beschreiben.
Sprich, die könnten ja bei Chrome was komplett anderes benutzen,
was sich halt nur genauso verhält wie ein Intersection Observer.
Aber die Spezifikationslogik ist halt genau am Intersection Observer entlang erzählt.
Ja gut, das macht auch Sinn. Also ich denke, der Vergleich mit dem Intersection
Observer, der ist sinnvoll.
Allerdings muss ich sagen, so habe ich das bisher noch nicht gesehen,
weil die benutzen jetzt ja wirklich zum Entlangerzählen wirklich eine Public API.
Sprich, das was ich jetzt gerade so skizziert habe, ich modifiziere den Prototypen,
da müsste ich einfach, indem ich den Prototypen vom Intersection Observer patche,
ich ja am Lazy Loading Image beobachtbare Effekte erzielen können.
Und ich bin nicht sicher, dass das eine gute Idee ist, dass das überhaupt geht.
Also, ich kann mir vorstellen, dass es eher so ist, dass das,
was die Intersection Observer API exponiert, dass das auf einer primitiven Aufbaut,
die die gleiche sein könnte wie das bei den Lazy Buildern.
Das tut das beim Patchen des Intersection Observers, aber eben nur die API zerpatcht
sozusagen, aber nicht diese zugrunde liegende Primitive.
Genau, das, was du grad beschrieben hast, die zugrunde liegenden Primitiven,
das ist, was sie machen wollen, aber was sie nicht machen können,
weil elendig lange Diskussion hier. Mhm.
Ähm, hab ich jetzt nicht so in der Kürze der Zeit erfassen können, warum das so ist.
Aber ja, das, was du da beschreibst, ist viel sinnvoller. Nämlich,
also, ich meine, das Verhalten, was wir jetzt da skizzieren von wegen,
wir patchen die Politik, das will man ja gar nicht haben. sondern man will halt
irgendwie sagen, den original Intersection Observer irgendwie in die Finger bekommen.
Aber weil der halt nur so als Standalone-Konstrukt spezifiziert ist,
also es gibt den Intersection Observer, aber keinen genauer spezifizierten Unterbau
dessen, geht das, was du beschrieben hast, noch nicht.
Und was man halt wirklich jetzt verbessern muss, ist die Spezifikation vom Intersection
Observer, dass man den in Form von Primitives von Engine-internen Primitives
ausformuliert, damit diese Engine-internen Primitives verwendet werden können
von der Lazy-Loading-Logik hier in den Spezifikationen.
Aber so, wie es hier jetzt steht, wenn das so implementiert ist,
wie es hier der Text sagt, dann müsste ich tatsächlich damit irgendwelche beobachtbaren
Effekte auslösen können.
Und wenn das ginge, wäre das ein Problem. Aber das scheint ja erkannt zu sein,
sonst hätte es hier nicht so viele rote Boxen. Ich bin gespannt. Jo, ich auch.
Ja, und ich glaube, das war es erst mal, was die Bildformate angeht.
Also mal gucken, wie das mit JPEG XL weitergeht. Hat man das jetzt geklärt,
ob Firefox den unterstützt? Er hat auch einen Command-Line-Fleck, den man angeben kann.
Und dann kann er das. Also de facto nicht wirklich.
Ja, genau. Aber sie sind auf jeden Fall in favor für dieses Bildformat.
Und irgendwie das Chrome-Team aus irgendwelchen Gründen nicht. Ja.
Die auch nicht so ganz klar sind. Genau, das ist halt intransparent.
Oh nein, eine große Firma, die intransparent ist. Was machen wir denn da bloß?
Neues Feature vom Safari ist also ein kleines, aber nützliches.
Man kann PWAs jetzt auch auf Desktop installieren. Also, add to Dock.
Ich weiß ja immer noch nicht, wie erfolgreich PWAs so in der Durchschnittsbevölkerung
sind, was so diesen Installationsprozess angeht.
Ich glaube, dass das alles irgendwie...
Nicht so richtig funktioniert, hab ich den Eindruck. Auch mit mobilen Apps.
Ja, da möchte man meinen. Ich bin der gleichen Meinung, ich habe den gleichen Eindruck.
Aber meine Freundin, die ist ja Psychologin, und die macht ja ihre Ausbildung
zur Psychotherapeutin.
Das ist ja eine Ausbildung, die du auf ein Psychologiestudium obendrauf aufsattelst.
Das ist ein riesiges, aufwendiges Ding. Da musst du absurde Tests bestehen und
so eine Prüfung ablegen.
Das ist alles reines Gatekeeping und völliger Bullshit. Also jedenfalls die Prüfung so in dem Sinne.
Und die hat halt so eine Übungs-App. Und das ist eine Progressive Web App.
Und die hat sich die auch installiert?
Ja. Sie konnten mir, irgendwann habe ich sie halt eben gefragt.
Die App ist ja nett gemacht und die macht ja auch so Pling, das ist so ein bisschen
gamifiziert, wenn du die Frage richtig beantwortest.
Das ist also Multiple Choice. Also geht der Nerd natürlich, und sie geht halt
jeden Abend durch diese Fragebögen durch und halt so üben, üben, üben.
Und natürlich gucke ich dann irgendwann und sage so, ey, was ist das denn,
das sieht ja gut aus. haben die dann eine extra App für gebaut.
Und so, nee, das ist eine Webseite. Irgendwann war die plötzlich bei mir installiert, ich find das voll gut.
Ja, cool. Und die hat exakt null Nerdpunkte auf einer Skala von eins bis zehn.
Mhm. Und das scheint irgendwie zu funktionieren. Also, ich bin mir seit dem
Erlebnis echt nicht mehr so sicher, was da jetzt Ross und Reiter sind.
Also, für so was macht das ja total viel Sinn.
Ja, ja, macht's auch. Aber ich mein, was natürlich so ein Punkt ist,
ist, dass sie hier zumindest nicht sagen kann, wie die Anwendung jetzt auf ihrem Gerät gelandet ist.
Also, ja, ich denke mal, das wird wahrscheinlich so ein Requester gewesen sein.
Ja, wir zum Prompt gehabt haben. Ja, ganz normal. Wahrscheinlich ist das ein
Android-Gerät mit Chrome, der macht das ja dann immer. Genau.
Und dann wird sie das wahrscheinlich geklickt haben. Ja, also aber eben dieses
so, hey, ich installiere mir jetzt eine Web-App, sich da hinzusetzen und zu
sagen, das nehme ich mir heute vor.
Das macht wahrscheinlich keiner. Ist eher so ein, ach, okay, ja.
Installieren, ja, okay, mach ich. Aber ist das nicht die Intention?
Also soll das nicht genauso funktionieren?
Eher auch doch. Also ich denke mir halt eben, seitdem ich keine Bankart 100
mehr habe, habe ich das Problem bei meinen diversen Erklärbeereinsätzen in den
verschiedenen Großstädten, nicht einfach so in jeden beliebigen Bus einsteigen
zu können, sondern ich muss mir tatsächlich ein Ticket besorgen.
Und das kannst du ja nicht überall einfach über die DB-App machen,
damit das einfach ein einheitlicher Prozess ist, sondern jeder verdammte Verkehrsverbund
hat ja im schlimmsten Fall seine eigene App.
Und die haben halt alle Apps.
Und dann musst du halt dir immer so ein Ding installieren und dann für jedes
Ding einzeln die davon überzeugen, jawoll, hier ist meine Kreditkarte,
weil du kannst kein Google Pay, du kannst kein PayPal, was kann ich denn bei dir machen, bla Keks.
Wenn das alles Webseiten wären...
Erstens müsste ich mir da nicht immer dieses Mistding installieren.
Und zweitens wird ja mein Telefon per se merken, okay, Kollege,
du bist jetzt öfter in, keine Ahnung, München, und du benutzt jetzt zum dritten
Mal innerhalb eines Monats diese App. Ich hätte da mal eine Idee für dich.
Das wäre doch eigentlich der Use Case. Klar, ich bin jetzt hier ein Nerd,
ich kann mir so eine App installieren, und ich kann das auch vorher planen, bla, Keks, bla.
So Sachen, die man halt hin und wieder mal nutzt, wo halt eben einfach die Maschine
merkt, es wäre jetzt eine gute Idee, der Nutzerin dem Nutzer vorzuschlagen,
das Ding dann einfach jetzt mal mit einem
Icon auch auf dem Homescreen zu persistieren. Das ist ja ein Use Case.
Also ich frage mich jetzt mittlerweile wirklich, ich hatte den gleichen Eindruck
wie du vor ein paar Monaten noch, dass ich so dachte, dieser ganze Progressive
Web App-Krempel, das wird irgendwie nix, weil das nutzt ja keiner.
Aber mittlerweile bin ich mir echt nicht mehr sicher, ob da jetzt Henne oder Ei fehlen.
Ob es da an Apps fehlt, oder ob es da einfach tatsächlich an Nutzern und Need fehlt.
Weil wirklich jede Fahrkarten-App und jede Taxi-App wäre halt wirklich als so
eine Progressive Web App besser aufgehoben, da bin ich mir sicher.
Ja. Vor allem jetzt, wo es ja überall funktioniert. Ja, schwer zu sagen, ich weiß es nicht.
Ich weiß auch nicht genau, wie der mobile Safari das macht, wenn man auf eine
PWA-fähige Seite kommt, ob der auch so einen Request da hat oder nicht,
ob man das da eher so quasi,
so wie mit, da gibt es ja dann hier quasi oben das Knöpfchen.
Wo man das dann, glaube ich, shared oder so was in der Art. Oder so ähnlich läuft das.
Und dann kann man aber da sein quasi Homescreen auch auswählen.
Und dann wird es dahin gepackt.
Also, ob Safari einen dann proaktiv fragt, oder ob man da selber auf die Idee
kommen muss, das weiß ich jetzt nicht.
Ja, und das proaktiv Fragen ist meines Erachtens halt wirklich wichtig.
Dass diese Use Cases, wie halt eben die Quiz-Webseite oder die Taxi-App,
dass das abgedeckt ist. Ja.
Und dann könnte man sich's halt eben ersparen. Ich mein, das ist ja allein schon
bizarr, dass jeder gammelige Verkehrsverbund hingeht und sich eine eigene App leistet.
In der Regel leisten sie sich zwei Apps und eine Webseite.
Da könnte halt alles eins sein. Ja.
Aber theoretisch sogar dann ... Das ist doch hier die Epic gegen Apple und Epic
gegen Google-Klage, der sich auch hier die Rails-Macher angeschlossen haben,
dass man bei einer App eigentlich ja ...
Man darf ja eigentlich nur die Zahlungsanbieter oder das Zahlungsportal der
mobilen Betriebssysteme oder des Stores oder so was benutzen.
Ist das nicht da irgendwie, dass die geißeln?
Ich meine, das ist so der Hintergrund, dass da alles über diesen Store abgewickelt
werden muss, damit die ihren Cut nehmen. Mhm.
Im Prinzip hast du eine Kaskade der Mittelsmänner. Da ist es wirklich nur so,
dass der größte Mittelsmann dem zweitgrößten Mittelsmann auch noch was abnehmen möchte.
Und das scheint jetzt Gegenstand dieses ganzen Streits da zu sein.
Und das umgehst du natürlich dann alles mit einer Web-App.
Ja, ist ja auch korrekt. Ich meine, am Ende bezahlst du mit der Kreditkarte
oder SEPA oder Paypal oder sowas.
Das heißt, was soll da jetzt praktisch gesehen wirklich schiefgehen,
wenn eine Web-App das so macht?
Du hast ja nichts davon, dass du dass du deine Kreditkarte noch mal durch den
Google Play Store durchdudeln kannst. Das scheint mir reine Wegelagerei zu sein.
Ja, ist es auch. Und dieses ganze Argumentieren von wegen, das ist für die Sicherheit
Blahkeks, äh ... Das kauf ich halt nicht. Ja.
Ja, genau. Da gibt's sogar Beispiele von irgendwelchen ...
Dregs-Apps, die man sich installieren
kann im Store. Also bei Google Play jetzt noch mehr als bei Apple.
Ja, wirklich. Wenn du als Betreiber von so einem App-Store globale Harm-Reduction
machen würdest, würde ich nicht an dem Problem rumdoktern.
Da gibt es dickere Dinge, die erschlagen werden müssten.
Hey, das Wichtigste bei so einem Riesenprozess ist ja immer,
egal, wer verliert, wer gewinnt. Hauptsache, da kriegt einer von den beiden
aufs Maul. Die können das beide ganz gut gebrauchen.
Mhm. Okay.
Dann kommen wir jetzt zum nächsten Punkt, der definitiv in deinen Vorgarten fällt. Was?
Nämlich hier das V-Flag bei Wreck-Echsen.
Wird jetzt unterstützt. Ich hab gar keine Ahnung, was das macht.
Naja, du, Shep, als alter Wacken-Teilnehmer, du kennst das doch aus dem Black-Metal-Umfeld,
wenn man besonders true sein möchte, schreibt man das U als V.
Okay. Return mit V, kennst du? Ja, natürlich.
So, und genauso ist es mit regulären Ausdrücken auch. Da schreibst du nämlich
jetzt, wenn du Unicode-Support haben möchtest, nicht mehr U, sondern V.
Okay. Und das meine ich, meine ich komplett ernst.
Also das ist tatsächlich die Idee dahinter. V aktiviert erst mal so grundsätzlich
Rage-X-Unicode-Support.
So in dem Sinne, was wir vorhin beim Segment schon besprochen haben.
Mhm. Du hast so Dinge wie, keine Ahnung, einfache Emoji, also irgendwie so Smiley-Face
oder so was, zusammengesetzt aus zwei Code-Punkten, weil nicht in der BMP,
sondern irgendwie so ein astrales Symbol.
Und du matchst irgendwie so einen Charakter. Mit dem U-Flag versteht Rage-X
halt eben, dass dieses Smiley-Face ein Charakter ist und nicht zwei.
Obwohl er aus zwei Code-Punkten zusammengesetzt ist. Das ist ja immer das U-Fleck.
Jetzt würdest du aber wahrscheinlich hingehen und würdest nicht matchen wollen
das spezifische Smiley Face, sondern du würdest erst mal sagen,
wir definieren diese zusammengesetzten Graphem-Cluster mit dem Zero-Width-Joiner,
wo wir halt irgendwie so sagen,
Mann und Joiner und Hand halten und Joiner und Hand halten ergibt einen Graphem-Cluster.
Die definierst du aus deiner Realität erstmal raus, weil das Problem ist ungelöst.
Aber du sagst jetzt, ich hätte gern irgendwie etwas, das alle Emoji matcht, Außer diesen drei?
Wie machst du das? Das Problem ist, das kannst du gar nicht so einfach machen.
Erstmal so grundsätzlich so etwas wie alle möglichen Emoji-Matchen kannst du
mit so Geschichten wie Unicode-Ranges natürlich machen.
Aber es gibt ja auch Sets, die du angeben kannst.
Wo du wirklich sagen kannst, das ist jetzt irgendwie so eine Gruppe und die
werden halt in JavaScript-Drag-Action angegeben mit einem Backslash,
P, Schweifklammern und dann schreibst du da den Namen von diesen Gruppen rein.
Zum Beispiel gibt es halt eine Gruppe Emoji.
Und da sind halt Emoji drin, aber halt eben aus historischen Gründen auch eine
ganze Menge anderer Krempel und in unserem Beispiel willst du jetzt wirklich
alle Emoji matchen mit Ausnahme des Clownface.
So als Beispiel. Ja. So, aber wie machst du das?
Wie kannst du was wieder irgendwo rausnehmen. Und das Ding ist,
mit dem V-Flag kriegst du halt den Unicode-Support, sodass du erst mal überhaupt
über Emojis arbeiten kannst, dass du Emojis als einen Token verstehen kannst.
Und du kriegst in den Character-Classes, also den Dinger mit den eckigen Klammern, Set-Logik.
Du kannst also wirklich sagen, ich hab hier ein Set von Characters,
und daraus exkluden würde ich gerne jenes Set an Characters,
und die Restmenge, die matchst du dann.
Du kannst also erstens Character-Classes, die mit den eckigen Klammern verschachteln
und du kriegst da drin einen Haufen Operatoren, also Minus Minus zum Beispiel
für Exklud und kannst dann in deinen regulären Ausdrücken diese Setlogik machen,
um genau das auszudrücken.
Okay, also es ist im Prinzip wahrscheinlich letztlich.
Hm?
Wird das greift das dann wahrscheinlich auch auf die gleiche primitive zu wie
das neue Intel Feature und die haben wahrscheinlich gesagt, jetzt bauen wir
das ein. Was können wir damit noch machen?
Da könnten wir doch noch direkt mal das V-Flag noch implementieren bei Rag-Xen.
Ja gut, also ich meine, das Primitiv, auf das sie zugreifen,
sind halt die Unicode-Blöcke.
Da steht ja halt eben drin, welcher Code-Punkt welchem Symbol zugeordnet ist.
Und dann werden die halt darüber hinaus noch in diesen Gruppen gebündelt.
Das sind halt einfach benannte Gruppen.
Da gibt es halt wieder eine riesige Tabelle, wo drin steht, Aha, okay, keine Ahnung.
Das ist jetzt die Klasse, in der alles drin ist, was Whitespace ist, zum Beispiel.
Aber die Gruppen sind halt eben halt vorgegeben, fest, und da sind halt gegebenenfalls
irgendwelche Teile drin, die dir nicht passen. Also, was lässt du als Letter durchgehen?
Zum Beispiel, wenn du jetzt sagen willst, ich will Buchstaben matchen.
Na gut, was ist ein Buchstabe? Da kannst du halt irgendwie auch das phönizische
Alphabet mit reinpacken, wenn du lustig bist. Aber willst du das? Vielleicht nicht.
Aber dann, du kannst ja eben nicht deine eigenen Sets bauen,
beziehungsweise du kannst dir diese eigenen Sets nicht bauen ohne V,
aber mit V kannst du ganz einfach sagen, ich matche mir die Welt,
wie sie mir gefällt, mache hier Set Intersections und Exclusions und so weiter und dann baue ich mir,
sagen wir mal, für diese makroskopischen Operationen genauer zusammen,
was ich eigentlich haben möchte.
Ich kann also mit diesen, diese Dinger, diese Gruppen, diese Sequenzen,
muss ich nicht einfach nur so hinnehmen, sondern ich kann mit denen ein bisschen
spielen und dafür ist das V da.
Also V steht wirklich für Unicode, so leid mir das tut.
Ja, aber auf jeden Fall schön erklärt. Mit Wacken und, äh, Gothic und dem U und dem V.
Es ist ja möglicherweise so, dass genau für die Veranstaltung,
die ich noch Ende der Woche haben werde, ich genau das vorbereitet habe. Mhm.
Siehst du dich gut aus damit. Ja, ich brauch eine Tüte Buntes für die Enterprise-Entwickler,
damit ich denen sagen kann, guck mal, im Web haben wir das Neues, das Neues, das Neues.
Das geht vom Search-Element über Garbage-Collection-Gewimsel in Javascript bis
hin zu den Regex-Geschichten, damit für alle was dabei ist. Sehr nice.
Du hattest eben die Sets erwähnt und da auch sozusagen Exclusions und solche
Begriffe fallen lassen.
Die Javascript-Sets haben auch neue Methoden erfahren und hinzugefügt bekommen,
die auch in so eine Richtung gehen, also dass man Sets, dass man bei zwei Sets
sozusagen herausfinden kann, was ist irgendwie der Unterschied in deren Einträgen
oder was sind die Gemeinsamkeiten.
Oder man kann die, glaube ich, dann auch zusammenhängen mit Union oder so. Genau.
Also, du kannst halt mit den Dingern Setlogik dann betreiben.
Es ist ja schon ein bisschen seltsam, dass wir in JavaScript Sets haben,
aber keine Set-Logik damit machen können.
Also ich finde das ja nicht seltsam, weil ich keine anderen Programmiersprachen
nutze, die Sets haben, die diese Set-Logiken dann unterstützen.
Aber du erinnerst dich doch, auch wenn es ein bisschen was her ist,
an die Mengenlehre, die du noch zu Schulzeiten mal mitgenommen hast. Nope.
Und du verwendest auch kein Typescript, dann fällt mir da jetzt wirklich nix mehr ein. Siehste?
Genau, aber ich kenn's halt von so ... Du hast, weiß ich nicht,
zwei geometrische Formen oder 3-D-Formen und möchtest die eben ...
Möchtest dann die verbinden und willst dann quasi nur die Überlappung von den beiden erhalten.
Oder du möchtest das eine vom anderen ausschneiden.
So, da hab ich meine Analogien für solche Sachen.
Genau das Gleiche ist es, die gleiche Begrifflichkeit. Hast du entweder bei
deiner 3D-Form oder im 2D-Bereich, fällt mir grad ein, so Vektorgrafik.
Ich leg diese zwei Kreise übereinander.
Genau, das ist es nur mit den Einträgen in einem Set. Da wird einfach nur das
nachgerüstet, was sowieso da sein sollte.
Also Intersection, Union, Difference, bla, bla, bla. Ist das ein Subset von
dem anderen, ist dieses ein Superset von jenem, was man halt eben so haben möchte,
ist im Moment in Stage drei.
Sieht also ganz gut aus. Und, ähm, ja.
Ja. Klingt auch sinnvoll, dass es das gibt.
Ich wüsste jetzt spontan wahrscheinlich nicht, was ich damit machen wollen würde,
aber vielleicht wenn ich ein,
SVG-Editor bauen würde und die einzelnen Punkte dann ins Set sette,
vielleicht könnte ich das dann da auch benutzen,
um diese Operation durchzuführen.
Und weiß jetzt aber nicht, bis jetzt nur so ein Brainfart von mir. Ja.
Ja, aber ich habe auch gerade noch mal mich durch die Issues hier durchgeklickt,
die scheinen wirklich alle größeren Probleme mit diesem Proposal auch ausgeräumt zu haben.
Ähm, ja, auch hier gibt's auch den, den, den, äh, Track, das Tracking für die Stage 4.
Stage 4 ist ja dann, wenn's tatsächlich, äh, angenommen und verabschiedet ist.
Und das ist jetzt aktiv in Arbeit, weil die größten Probleme alle wohl weg sind.
Gut so. Können wir gebrauchen.
Macht, wird mich trotzdem erst wirklich froh machen, wenn wir auch die Records und die Tuples haben,
äh, damit ich tatsächlich Structs haben kann, so, die nicht irgendwie objektidentitär
das Gleiche sein müssen und ich halt rausfinden kann, ist irgendwas,
was diesen Vektor beschreibt, auch schon drin in diesem Set,
ohne dieses Objekt haben zu müssen? Mhm.
Das kennt man ja, da rant ich ja seit Jahren drüber. Ja.
Da fällt mir nur quasi als Randnotiz ein, dass es das ja, glaub ich,
für DOM-Nodes gibt es das ja.
Ich glaube, dass es dann ... das ist equal, ne? Das ist dann quasi ...
Nicht ... ist es die gleiche DOM-Node, sondern ...
Ist sozusagen ... Also ist sie sozusagen ein Duplikat der aktuellen Note meine ich.
Okay, äh, in den ist equal.
Ah. Wartet, weil meine Tastatur einfach direkt in den Browser ein Dollar 0 dort
ist equal ist equal Note gibt's ist equal Note ja, dann ist es das okay.
Äh, Mdm ist equal Note.
Die Noten sind gleich, wenn sie den gleichen Typ haben, um die Charakteristiken zu definieren.
Zahl der Kinder und so weiter, Attribute, Match und so weiter.
Ah gut, zweimal in dem Text steht also drin und so weiter und so weiter.
Die spezifischen Dinge variieren, je nach Typen der Noten. Okay, ja, das ist ja spannend.
Ich meine, das könnte natürlich mit, das ist natürlich eine super Sache für die DOM-Nodes.
Ja, du könntest halt dein, das was du da benutzt, könntest du sozusagen in Fake-DOM-Nodes
oder in, natürlich in Echt-DOM-Nodes, aber sozusagen nur als Steigbügelhalter
genutzte DOM-Nodes umwandeln und dann könntest du ein IsEqual-Node machen.
Okay, das ist ausgesprochen kriminell. Aber so ist doch Webentwicklung, oder?
Oder nicht? Ja, aber ich glaube, das würde tatsächlich auch ...
Nnnnicht funktionieren. Warte, was ist die Attributelist? Is a list exposed?
Blablabla. Attributelist. Also, die Frage ist halt eben, geht das?
Also, weil so Records und Tuples, die könnten ja eh nur beinhalten ...
Dinge, die in erster Näherung JSON-kompatibel wären. und halt eben mal Ausschluss,
also was heißt JSON-kompatibel werden?
Du hast halt Primitives, die halt in Listen oder Objekten ausgedrückt werden können. Ja.
Und das könntest du ja tatsächlich auch machen, wenn du so was wie BigInt,
was halt nicht JSON-kompatibel ist, rauswirfst. Und daraus könntest du ja theoretisch
einen JSON-String machen.
Und das könntest du ja theoretisch in irgendwie das Data-List-Ding von irgendeinem DIV reinstecken.
Und das DIV dann halt eben sozusagen als Träger dieser Daten verwenden.
Aber dann könntest du es ja auch direkt JSONifizieren. dann hast du Strings,
die sind ja auch dann unterschiedlich.
Du verwendest ja quasi entweder... Ja, du könntest dann quasi die JSON-Strings vergleichen, wobei,
naja, okay, dann müsste man noch sicherstellen, dass die Reihenfolge der Properties immer gleich ist.
Und dann könnte man JSON auch vergleichen.
Aber du, Shep, was du jetzt machst, kann man ja technisch runterkochen zu,
du beschreibst einen ungewöhnlichen, aber einen definitiven Hash-Algorithmus.
Und da kannst du auch ein Hash-Algorithmus nehmen. Ja, das stimmt wohl.
Ja, das ist nämlich, was ich im Moment mache, und das nervt mich zur Hölle.
Na ja, was willst du machen? Ad ist halt so, Ad wird nicht besser. Ad wird nicht besser.
Was aber besser wird, sind die Dev-Tools von Safari.
Unglaubliche Überleitung. Ha, ha, ha, ha, ha!
Äh, ja, werden sie und gleichzeitig auch nicht. Warum, sag ich gleich,
ähm, die Dev-Tools ... bieten jetzt die Möglichkeit, ähm, echte ...
Äh, iPhones oder iPads sozusagen aus sich heraus zu starten via Xcode-Simulator.
Ähm, und das ist eigentlich cool. Moment, also, da ist ein iPadOS in meinem Browser drin?
Oder wie, versteh ich das? Ja, also im Endeffekt kannst du
brauchst halt Xcode und den Simulator und dann kann Safari das dann da rein
reichen und du hast dann ein echtes simuliertes Gerät und nicht einfach nur
ein auf Gerätegröße verkleinerten Screen und irgendwie ein paar Polyfills, die das,
die irgendwie Touch und so Zeugs dann nach F'en.
Okay. Genau, das ist eigentlich cool.
Was ich daran doof finde, ist, also ich habe ja hier so einen kleinen Mac Mini,
der hat, also ich habe einen Mac Mini und ich habe jetzt auch einen MacBook Pro.
Und auf dem Mac Mini ist es so, der hat nur, glaube ich, 256 Gigabyte Speicher,
was im Grunde okay ist für so Entwicklungszeugs.
Aber wenn du halt Xcode und Simulatoren installieren willst, dann ist das zu klein.
Und ich kann es hier halt nicht nutzen, weil mir, weiß nicht,
ob Safari oder Xcode ... Irgendwer sagt mir auf jeden Fall so,
ja, nee, ist nicht, weil dein Speicherplatz zu klein ist.
Und das find ich schon ein bisschen krass.
Also, dass man diese Simulatoren nur nutzen kann, wenn man, weiß ich nicht,
einen halben Terabyte SSD hat oder so.
Ist schon ein bisschen eine kranke Welt.
Ja, weil ich mein, du hast das ja on top deiner ganzen übrigen Entwicklungsgeschichte. Mhm.
Wenn du dann noch irgendwie ... Mh ... Ja.
Jetzt ist vielleicht der Mac Mini nicht die typischste Workstation,
aber du hast eventuell eine Entwicklungsumgebung, die anders constrained ist,
weil du in virtuellen Maschinen wohnst oder so, die nicht 100 Prozent abrufen
können von dem, was an Hardware da ist,
weil deine Firma so tickt oder so. Ja.
Das hört sich jetzt schon nach einem Problem an.
Genau, also, ich mach auf dem auch im Grunde nicht viel anderes als entwickeln,
also, der ist jetzt irgendwie nicht meine Spaßmaschine oder so.
Genau, da reicht der Speicherplatz dann schon gar nicht mehr aus. Oh.
Das machst du nix. Was haben wir hier? Das hab ich, genau, 256 Gigabyte.
Genau, verfügbar hat der jetzt sogar nur noch, also, warum auch immer, 36 Gigabyte.
Und das reicht halt dann nicht, um Xcode mit einem Simulator zum Beispiel irgendwie draufzupacken.
Also gefühlt fühlt sich diese Zahl irgendwie an, als wäre das reichlich was.
Aber irgendwie scheint das nicht zu sein.
Genau. Ist natürlich so. Da steckt ja auch viel in so Geräten drin und so weiter und so fort.
Aber ja, was fände ich besser? Ich glaub, ich fänd vielleicht cool so was wie
einen Apple-eigenen Browser-Stack-Service oder so was.
Oder dass man vielleicht Browser-Stack integriert in die Dev-Tools.
So was fänd ich halt auch ganz cool. Warum machen die das nicht selber?
Könnten die auch selber machen, ja. Also ich meine, ich hab jetzt keine Ahnung,
was so Extensions in Safari können.
Aber zumindest so für Firefox und Chrome würd ich sagen, gib mir mal ein paar
Wochen Zeit und dann krieg ich da irgendwie so ein, okay, Proof of Concept hin.
So schwer kann das nicht sein.
Genau. Aber für die eine oder den anderen ist das auf jeden Fall ein praktikables,
ein praktikabler Weg, seine, sein Werk zu testen und ...
Weil man halt für den fettesten Mac Pro aller Zeiten auf dem Schreibtisch stehen hat.
Zum Beispiel. Genau, ein M3 Ultra, der wahrscheinlich erst eine Woche nach dem
Release dieser Folge rauskommt.
Ja, oder es ist halt einfach ein Gerät mit fetter Platte drin,
ne? Das wird ja auch reichen.
Also an der Leistungsfähigkeit per se dürfte es ja nicht scheitern. Nee, das stimmt wohl.
Hätte ich auch machen können, aber da ich jetzt zumindest diesen Mac Mini eigentlich
wirklich nur zum Entwickeln nutzen wollte, und klar, so Node-Modules-Folder können groß werden,
Aber genau, ich habe auch nicht so viele verschiedene Projekte,
an denen ich gleichzeitig sitze.
Ähm, erschien mir das jetzt irgendwie, äh, overkill.
Wahnsinn, ey. So viel ... So viel Bytes besetzt dadurch das,
damit du halt eben mal kurz gucken kannst, ob's im iPhone auch gut aussieht.
Ja, also, ich mein, du kannst natürlich immer noch das machen, was bisher auch ging.
Also, es ist so, glaub ich, einfach dann so, wie das die Chrome DevTools machen.
Geräte nach Fs, wobei die, glaube ich, auch so Presets haben die rausgenommen,
also du kannst jetzt noch so einen Responsive Mode machen, wo du quasi das Fenster
selber größer und kleiner ziehst,
was ja auch im Grunde okay ist, aber es ist dann halt nur eine Annäherung und nicht das echte Ding.
Da fühle ich mich ja doch irgendwie etwas bestärkter drin,
immer jedes Mal, wenn ich mir irgendwas neues computeriges kaufe immer
das nächste zu kaufen was ich in die finger kriegen kann also ist schade zumindest
nicht einfach nur damit ich halt eben möglichst möglichst lange jahre meine
ruhe haben kann und nichts weitermachen muss als alle als alle paar schaltjahre
mal das betriebssystem zu upgraden ja aber du weißt halt auch wirklich nicht
was so um die ecke kommt was plötzlich echt extrem viel leistung absaugt wie halt eben das.
Wobei, da hast du dann vielleicht irgendwann eher das Problem,
dann holst du dir irgendwie eine dicke Platte, und dann wird deine CPU-Plattform
nicht mehr unterstützt.
Also, so, keine Ahnung, wenn du jetzt einen Intel Mac hast oder so,
dann ist irgendwann vorbei mit OSX-Update, Updates, Mac OS-Updates.
Und ... Joa, aber du könntest, du musst ja nicht unbedingt zu den Apfeltaschen gehen.
Du kannst ja auch bei uns hier auf dem technologischen Tree die einfach so drei
Schritte weiter hinten bleiben, so hier in der Bronzezeit.
Da gibt's keine neuen CPU-Plattformen, da bleibt das alles am Funktionieren bis ans Ende aller Tage.
Ich mein, du benutzt ja Linux, aber bei Windows 11 ist ja auch schon so,
wenn die und die Komponente nicht eingebaut ist, dann kannst du nicht upgraden auf Windows 11.
Geht dann auch nicht. Komponente, was meinst du?
Du brauchst irgendwelche DRM-Sachen, glaub ich, in deinem BIOS.
Also die müssen unterstützt werden, und dann kannst du auf Windows 11 upgraden. Okay.
Und sonst hängst du halt auf 10 fest, oder du musst halt ...
Ich glaub, das kannst du dann natürlich auch irgendwie wieder hacken.
Und dann kannst du es irgendwie umgehen. Aber grundsätzlich ist es eben so,
dass Windows 11 dann sagt, nee, es geht nicht, leider.
Ja, meine Meinung ist und bleibt, bei den Betriebssystemen ist es wie mit den Frontend-Frameworks.
Da ist nicht unbedingt eins besser als das andere, sondern da kommt es einfach
nur darauf an, mit was kommst du am besten persönlich klar und das nimmst du
dann und dann akzeptierst du die ganzen Vor- und die ganzen Nachteile,
weil er passt halt einfach zusammen. Ja.
Und da kannst du nicht irgendwie sagen, mein Linux ist besser als dein Windows, weil...
Nee, nee, genau. Das würde ich so... nee, genau, würde ich auch nicht sagen.
Ist ja so, als würde man irgendwie sagen, React ist besser als Angular,
weil... das ist doch... ich meine, das versucht ja nicht mal jemand zu sagen.
Nee, nee. Also, das ... Ich glaub, das gab's früher vielleicht mal,
aber mittlerweile nicht mehr, oder?
Ja, ich seh ja auch selten diese ganz klassischen irgendwie,
wer Windows benutzt, ist doof und riecht nach Luluflame-Wurst.
Das gibt's ja auch nicht mehr.
In dem Sinne, vielleicht liegt das einfach daran, dass ich zu alt bin und nicht
irgendwie auf TikToks das noch sehe, was da abgeht.
Man weiß es nicht. Aber ja. Das ist jedenfalls meine verallgemeinerte Software-Theorie.
Da ist vielleicht auch was Wahres dran. Juhu! Dann habe ich doch was Wahres
gesagt. Dann können wir doch auf die Sendung einen Deckel drauf machen.
Ja, cool. Machen wir. Was haben wir gebraucht hier? Ach, nur zwei Stunden.
Länger als das letzte Mal. Aber das Coole ist, wir haben uns komplett durchgearbeitet.
Ja, und der Mac Mini weint auch noch. Nicht wegen zu vielen Bytes,
die wir mit unserem Audio-Gequatsche verlegt haben. Der weint ja sowieso nie,
der ist ja immer ganz leise und brav und so.
Fein, fein. Das ist ja auch sehr beeindruckend.
Cool, dann bedanke ich mich für viele Dinge, die ich mal wieder gelernt habe.
Das ist ja, wie haben es gesagt, ein bisschen Therapiesitzung hier,
aber auch eben sozusagen eine Gelegenheit, voneinander immer wieder zu lernen.
Genau, das hält uns selber ja auch immer schön auf Stand.
Diese einmal die Woche aufnehmen Sessions.
Ja, sonst wüsste ich halt nix über irgendwie Audio und Bildkodex und... Oder ist equally node.
Ja, das ist... auf dem Ding muss ich tatsächlich noch rumdenken und ein bisschen
rumspielen, ob man das nicht vielleicht tatsächlich für diverse Dinge gebrauchen könnte.
Ja, also hackst du jetzt erstmal da auf rum oder auf Intersection Observer?
Ich werde auf meinen Slides rumhacken, weil ab morgen muss ich was liefern und
ich bin noch nicht ganz fertig.
Aber ich habe morgen eine lange Bahnfahrt, da werde ich mal gucken,
ob ich auf irgendwas von dem rumhacke.
Zuhörerschaft, bitte nehmt mich an die Kandare, wenn ich auf Mastodon nicht
irgendwas zu diesen Themen von mir gegeben habe in den letzten Monaten.
Also deine Zufahrt wirst du ja wahrscheinlich wieder dokumentieren und wo du
strandest und so, das kennen wir ja.
Nein, nein, nein. Ich muss nur von Kiel nach irgendwie Hamburg und von Hamburg
nach München in eins durchfahren. Also kein wildes Gefummel.
Da gibt es keine Stranden.
Das läuft pünktlich ab, weil es muss pünktlich sein.
Ah, okay. Also das heißt kein Polizeieinsatz auf den Gleisen und quasi Umwegfahren und so Sachen.
Kein Polizeieinsatz an den Gleisen, keine Türen, die sich nicht öffnen,
keine Reisenden, die gewalttätig werden.
Was hatten wir noch so? Klimaanlagen, Ausfall, Fahrzeug kaputt.
Zugführer weiß nicht, was für einen Zug er gerade hat.
Okay, ich drücke die Daumen. Es wird funktionieren, ich wüsste gar nicht, was schiefgehen soll.
Wunderbar. Wenn ihr höhere Feedback habt, mit welchen Dingen der Peter sonst noch rumhacken könnte,
oder generell zu den Themen, die wir hier besprochen hatten,
oder zu eurer Sicht auf die Größe von den Safari-Emulatoren oder so,
dann genau meldet euch gerne.
Hüpft in unser Community Slack, den ihr auf unserer Webseite verlinkt findet
auf der Startseite und ja, wir würden uns dann nächste Woche wieder und da geht es um,
da geht es um, worum geht's?
Ich glaube, ich weiß es, ich gucke noch mal sicherheitshalber nach.
Genau, also wir haben letztes Jahr, Ende des Jahres haben wir mit dem Joe sozusagen
einen Blick in die Glaskugel geworfen, was so die Web-Entwicklungstrends sein werden im neuen Jahr.
Und der Joe ist jetzt nach einem Jahr wieder zu Gast.
Und dann werden wir schauen, welche seiner Vorhersagen oder unserer Vorhersagen
sich bewahrheitet hat, welche nicht und welche neuen Prognosen wir für das Jahr 2024 abgeben möchten.
Also bleibt uns gewogen und bis nächste Woche. Bis dahin, Tschüssi!
Music.
Untertitel im Auftrag des ZDF für funk, 2017.