Was ich hier in erster Linie sehe, ist, dass wir Class-Attributes benutzen, speziell was Styling anbelangt und entsprechend weniger ID-Attribute.

Also zumindest alles vier meine ich jetzt gerade in dem Zusammenhang eigentlich mit CSS.

Kein Zweifel und Gott sei Dank, da gibt es ja auch eine positive Entwicklung.

Da gibt es ja auch einen interessanten, von der CSS-Arbeitsgruppe auch eine Liste von Sachen, die die eigentlich nicht mögen am Design von CSS.

So Probleme, also eine Liste, die auch schon seit 10, 15 Jahren oder sowas gepflegt wird.

Sehr interessante Punkte dabei, warum manches, die auch erklärt, warum manche Sachen so sind, wie sie jetzt sind.

Ohne euer Feedback wäre das hier alles gar nichts.

Und deshalb haben wir für euch einen Slack-Channel eingerichtet.

Unter draft.community könnt ihr beiträgen und mit uns Podcast-Hosts sowie der erlesenen restlichen Hörerschaft abhängen.

Wir diskutieren über den Podcast, tauschen Links aus und immer dann, wenn wir etwas Besonderes vorhaben, erfahrt ihr es dort zuallererst.

Also klickt doch mal rein unter draft.community.

Revision 693, Wir sind heute zu zweit und aus dem Team bin nur ich dabei, der Shep, und das bedeutet, wir haben einen Gast, und zwar den Jens Oliver Meiert.

Hallo Jens.

Moin, moin.

Moin, moin.

Du warst vor, 6 Revisionen, schon mal Gast.

Deswegen, also ich glaube, vorstellen musst du dich da nicht.

Ich glaube, das haben die Leute noch präsent.

Hört gerne da noch mal rein in die Folge, wenn ihr mehr über Jens erfahren wollt.

Verlinken werden wir dich natürlich in den Shownotes, wenn ihr mehr im Internet über Jens erfahren wollt.

Und was wir heute aber machen werden ist, wir haben vor sechs Revisionen über das Thema valides HTML gesprochen und da kam die Idee auf, dass wir ja auch nochmal zusammen eine Runde Glücksrad spielen können.

Aber eben auch, also das haben wir jetzt einfach mal so gesagt, dass wir uns beschränken eben auf HTML-Vokabular.

Also wir haben in unserem Glücksrad die Checkboxen CSS, SVG, JavaScript, Browser-APIs und Accessibility alle abgehakt.

Und jetzt ist nur noch HTML angehakt.

Genau.

Findet man unter working-graph.de slash Glücksrad.

Und genau, das funktioniert so, dass man einfach auf einen Knopf drückt und dann werden die MDN-Daten durchsucht von dem Dings hier und irgendwas zufällig ausgespuckt.

Und darüber quatschen wir dann.

Jawohl.

Freestyle.

Wir haben auch den Link natürlich zu der Doku und der MDN.

Könnt ihr auch nochmal reingucken.

Wir werden auch immer noch dazu.

Und genau, wir schauen mal, wo es uns hinführt und gegebenenfalls kommt was, wo mir dann einfällt, ah, da haben wir schon lang und breit meine anderen Glücksradfolge drüber gesprochen, dann würde ich Bescheid geben oder manchmal gibt es auch so Elemente, die sind halt so, das war meistens dann eher aus dem SVG-Kosmos, die sind so entweder eh gar nicht dokumentiert oder so weird, dass wir dann auch sagen, okay, wir machen einfach, lass uns nochmal drücken.

Genau, und ich würde vorschlagen, Da du der Gast bist heute, darfst du als erstes drücken.

Ich bin schon ganz aufgeregt.

Und jetzt läuft der Zuwurzgenerator.

Ja.

Er hat was relativ Antikes ausgespuckt.

Das es ganz lange gibt.

Genau, ID.

Ein globales Attribut, das man überall dran pappen kann.

Ja, ich muss glaube ich ein bisschen lachen hier schon, weil man gefühlt den Eindruck hat, dass da so ein bisschen eine Hexenjagd über die letzten Jahre lief, was das ID-Attribut anbelangt.

Und in dem Sinne eigentlich ein ganz interessantes Thema schon.

Erzähl mal.

Ich habe, glaube ich, eine Idee, was du meinen könntest, aber erzähl mal, was du meinst.

Was ich in erster Linie sehe, ist eigentlich unsere.

Immer verbreitetere Praxis, würde ich so wahrnehmen, dass wir Class-Attributes benutzen, speziell was Styling anbelangt und entsprechend weniger ID-Attribute, Also zumindest alles hier meine ich jetzt gerade in dem Zusammenhang eigentlich mit CSS.

Kein Zweifel und Gott sei Dank, da gibt es ja auch eine positive Entwicklung.

Ich glaube, ich mache das mal kurz zur Randbemerkung und trete auch mal einen Schritt zurück nochmal historisch.

Wir hatten ganz, ganz viele Jahre, so in den 90ern raus, aus den 90ern raus, in die 2000er, die Angewohnheit, oder einige hatten die Angewohnheit, Name-Attribute zu benutzen, um interne Links anzusprechen.

Und dann hatten wir so diese ganz lange konnte man sehen, dass das Entwickler dann Name- und ID-Attribute benutzten, bis irgendwann wirklich, ich glaube, da sind wir mittlerweile raus und das ist die positive Entwicklung, dass man sagt, okay, für interne Sprungmarken benutzen wir nur noch ID.

Das Lustige ist, wir haben gerade letzte Woche mit Manuel Matusowitsch eine Folge über Links aufgenommen.

Und da sprachen wir auch darüber, dass man eben früher Sprungmarken eben mit Name versehen hatte und man mittlerweile dann ja auf ID gewechselt ist.

Ja, das genau nach einer guten Folge.

Also Notiz für alle gerade, mich eingeschlossen hier nochmal die Folge auch zu Gemüte führen.

Ja, also ganz interessant in dem Sinne, weil da sind wir dann von weg, aber dann, ich weiß nicht, wie es zeitlich dann koinzidiert, wahrscheinlich jetzt eher weniger, aber dass letztendlich diese Best Practice, in Anführungszeichen, sag ich mal, aufkam, keine ID-Attribute als Elektron zu benutzen.

Und warum ich jetzt selber benutzen würde oder reinschmeißen würde, ich halte das für übertrieben letztendlich.

Also ich glaube, letztens kam mir auch mal ein Artikel unter, wo der Autor, ich weiß jetzt nicht mal, was das jetzt genau war, von wem das war, aber wo der Autor durchaus auch davon sprach, okay, ist ganz legitim, als Selektor zu benutzen, aber es kam halt auch in diesem ganzen Zuge, so wie managen wir CSS, und wir wollen jetzt nicht irgendwie, dass irgendwas eben halt mit der Spezifizität dann Spezifizität, ich weiß nicht, wie wir das auf Deutsch sagen, Spezifizität.

Ja, im Deutschen ist es Spezifizität und im Moment, im Deutschen ist es Spezifität, und im Englischen ist es Specificity.

Specificity, ja.

Die haben eine, sind mehr.

Genau, und dem zusammen kam das auf und ich glaube, es macht von dem Winkel dann auch Sinn, aber genau, es führte halt, glaube ich, zu dieser Idee, ID-Attribute zu vermeiden.

Ja, also ich glaube, das kam auch genauso.

Spezifität ist auf jeden Fall ein starkes Argument.

Heutzutage kann man natürlich auch hingehen und das entschärfen, indem man irgendwie sowas wie, ich glaube, is it is oder where, also eins der beiden führt ja dazu, dass es dann quasi keine Spezifität mehr trägt, wenn man es da reinwickelt.

Aber ich glaube, das kam vor allem auf zu der Zeit, wo man angefangen hat, ja so Komponentenbibliotheken zu bauen und Elemente eben mehrfach eingesetzt hat.

Und da habe ich das damals dann auch so in meiner eigenen Art zu coden, zu spüren bekommen, dass man damit auf die Nase fällt, wenn man eben Codeabschnitte mit IDs versieht, von denen man zunächst vielleicht auch annimmt, dass sie nur einmal vorkommen.

Und dann gibt es auf einmal die Anforderung im Projekt, dass wir brauchen das jetzt nochmal da an der anderen Stelle.

Und dann war das mit der ID halt dann blöd.

Ja, da sprichst du noch einen anderen guten Punkt an, im Sinne von, dass viel davon abhängt, wie gut wir unsere Projekte kennen oder vorhersehen können, was da passiert.

Je komplexer die Projekte sind, desto schwerer wird das.

Also es ist jetzt nachvollziehbar, dass wir so einen Trend dann hatten.

Auf der anderen Seite, wenn man weiß, dass man ein uniques Element hat und, Also wenn man jetzt irgendwie nicht darauf, gar keine Möglichkeit hat, mit einem anderen Selektor zu arbeiten, scheint ein ID-Selektor auch weiterhin probat zu sein.

Ja, du kannst übrigens ja auch mit einem Attribut-Selektor das Ding selektieren.

Das ist eigentlich ganz interessant, was du auch eben meintest mit where in dem Fall, also ohne Spezifizität.

Spezifizität bleibt einfach beim Englischen.

Um damit zu arbeiten, ist das eigentlich ganz smart, wobei auch wieder so interessant, wenn man bedenkt, dass es die Möglichkeit des Vektors Aber ja, nicht überraschend, dass unser Feld da durchaus erfinderisch ist.

Ja, ich benutze das übrigens auch umgekehrt.

Also umgekehrt benutze ich das sehr gerne, wenn ich eben so Komponenten irgendwo habe und die eben in einem bestimmten Kontext umgestaltet werden sollen.

Aber dann habe ich natürlich irgendwie das Problem, also dann muss ich ja irgendwie meine Spezifität so erhöhen.

Manchmal, also oder meistens ist das ja schon durch die Verschachtelung eines Elements in ein anderes gegeben, aber manchmal eben auch nicht.

Und dann gibt es ja so zwei verschiedene Tricks.

Also das eine ist, dass du quasi, du kannst ja eigentlich dieselbe Klasse zum Beispiel oder auch die ID-Chain, also es geht, auch wenn es ein bisschen weird ist, aber dann bekommst du so, dem Browser ist das egal, ob das jetzt plausibel ist oder nicht, aber du kannst dann quasi für jedes Kettenglied in deinem Selektor dann deine zusätzliche Spezifität.

Und ich mache das aber lieber dann mit Not.

Also ich mache dann einfach Not und dann stecke ich da rein so eine CSS-Klasse oder sogar eine ID manchmal, die ausdrückt, was ich damit mache.

Das ist dann meistens Specificity bin Strich Increase und dann also das gibt es auch nicht, dass kein Element nutzt diese Klasse oder ID, aber man weiß dann so, ah, okay, darum hat er das da reingesteckt, alles klar.

Hm, okay.

Äh.

Und ansonsten, ID ist natürlich so eigentlich ja meistens wichtig, um so Beziehungsgeflechte im Markup irgendwie auszudrücken oder im DOM.

Da finde ich, ist ja immer so ein bisschen das Problem, also da muss man das ja machen und ich weiß nicht, welche Lösung du da gefunden hast für wiederverwendbare Komponenten.

Also wenn du jetzt irgendwie so eine Kombo aus Label und Input hast und du hast dann mehrere davon auf einer Seite und ich weiß nicht, wie du das machst oder du hast vielleicht sogar mehrere Formulare mit denselben benamten Inputs drin, dann wird es dann nochmal trickier.

Dann kannst du die ID auch nicht mehr ableiten vom Namen, weil dann hättest du davon auch zwei wieder und das ist ja auch blöd und dann hast du ein Label für eine Checkbox, und du klickst das eine und die andere Checkbox da drüben wird die ganze Zeit an- und abgehakt und nicht die wo es daneben steht und so, wie machst du das?

Hast du da irgendwie einen Trick?

Also ich arbeite zur Zeit oder schon länger jetzt nicht mit größeren oder komplexeren Formularen ich glaube da ist das Da kann ich mir auch vorstellen, da gibt es dann interessante Konstellationen.

Was mir parallel einfällt, ist diese, ich glaube auch da letztens in einem Artikel untergekommen und die hier vielleicht für die Zuhörer als Kontext, also durch meine Arbeit an Frontend Dogma, wo ich mich viel mit dem beschäftige aus dem Feld passiert, ist es eigentlich eine tagtägliche Sache, sich wirklich durch mehrere Artikel, durch Videos und so durchzuarbeiten.

Deshalb werde ich vielleicht manchmal solche Referenzen machen.

Leider hier auch der Sleeper-Effekt, glaube ich.

Das weiß ich nicht mehr genau, von wem der dann in diesem Artikel war, aber dieses Thema allgemein über extrinsische und intrinsische Assoziierung von Labeln mit Formularelementen.

Ich bin selber ein großer Fan von der impliziten Assoziierung, weil die eben halt auch, da sind wir so indirekt mit dem ID eben halt wieder, bei dem ID-Adgibut wieder, weil die eben erlaubt, sehr einfaches Markup zu schreiben.

Also ich finde das immer gut, also jedes Mal, wenn ich an Formulare rangehe, in dem Sinne, das sind, wie gesagt, eher einfache Formulare, mag ich eben halt die Arbeit, letztendlich das Input-Element oder die Elemente jeweils im Nable-Element zu rappen und fertig ist.

Und daher ist dann eher wenig Arbeit mit einer Notwendigkeit für einen ID-Attribut.

Ich sehe es aber, also was du meinst, deine Frage eben halt und was viele eben halt sicherlich in der Arbeit mit Formularen haben, ist die Situation, dass man mit ID-Attributen auch arbeitet und.

Da gerade in komplexeren, formularen Wahrscheinlichkeitsabenteuerliche Konstellationen dann jeweils gibt.

Ja, auch allein deswegen, weil ich halt oft so Checkboxen und Radios gestalten muss und dann nutze ich in der Regel eben diesen Sibling-Selektor-Trick und dafür müssen die halt dann nebeneinander stehen, also dann kann ich es nicht verschachteln, damit ich eben das Checked entsprechend.

Eben auslesen und im Label anwenden kann als Grafik oder was auch immer.

Ja, interessant.

Okay, jetzt weiß ich ein bisschen mehr, was du im Sinn hattest gerade.

Ja, das ist wahrscheinlich Erfinderbeschwerden in manchen Szenarien.

Ja, ich mache es dann meistens so, also meine Lösung ist, dass ich, ich habe eine Template-Sprache, die ich dann benutze und da erzeuge ich mir dann immer so eine Unique-ID dann für diese Instanz dieser Komponente und da habe ich dann immer so eine Art ...

Suffix an den IDs dran, das sich eben ergibt aus dieser, UUID, die ist dann eben im For-Attribut, landet die dann genauso wie im ID-Attribut des Inputs und genau damit mache ich das dann und kann dann so Beziehungen herstellen und weiß halt, also die Wahrscheinlichkeit ist ultra gering, dass jetzt bei, wenn ich eine Komponente mehrere Male auf einer Seite benutze, dass da zufällig genau die gleiche UUID ausgewürfelt würde oder so.

Ja, klingt ja unwahrscheinlich.

Genau.

Nee, das tust du ja auf jeden Fall gut und ja, weiß nicht, vielleicht können wir noch mal kurz uns beschäftigen mit den, du darfst ja auch nicht beliebig die benennen, also die ID muss ja immer starten, glaube ich, also die darf nicht mit einer Zahl starten, wenn ich mich nicht irre und das haben die auch nicht geupdatet, ich gucke mal gerade.

Ja, ist relativ restriktiv, also die genaue Regel habe ich jetzt auch nicht so, ich glaube, meine mit Zahlen ist okay, aber das darf, glaube ich, mit Beginn oder sowas.

So war das meine ich.

Achso, nee, darf man wohl schon.

Ich dachte, da wäre was gewesen.

Also Space darf man nicht, das ist irgendwie klar.

Ich gucke mal nochmal in die Speck, ob die noch was dazu sagt.

Da gucke ich auch gerne.

Ja.

Ah ja, okay, doch.

ID scan consists of just digits.

Start with a digit.

Start with an underscore.

Genau.

Okay.

Nee, dann habe ich das irgendwie falsch im Kopf.

Oder vielleicht war es ja früher so, dass es da Restriktionen gab.

Ja.

Sowiel zum Thema ID.

Ich würde sagen, oder?

Sollen wir hier den Zufall nochmal walben lassen?

Ja, gerne.

Dann klicke ich mal.

Content Editable.

Ja, auch gut.

Hast du mit dem Mal gearbeitet?

jetzt?

Ja, tatsächlich, also immer mal wieder.

Also wofür das halt gut ist, also das haben wir ja mittlerweile, es gibt ja dieses Field Sizing CSS Attribut jetzt relativ neu, mit dem man so sagen kann, bitte Input oder Text Area wachse mit der Länge an Text, die in dich eingegeben wird.

Bei Text Areas muss man es eigentlich klassisch immer mit JavaScript irgendwie lösen und bei Inputs ging das ja nur mit so Content Editable Spans zum Beispiel, die dann eben so groß geworden sind wie das, was in ihm steht, also wenn man so Inline-Input-Felder hatte oder so.

Genau, ansonsten habe ich eine Combo-Box gebaut, also Combo-Select-Dings.

Also es taucht früher oder später immer in so Projekten auf mit einer gewissen Komplexität.

Die sind ja aus vielerlei Hinsicht wahnsinnig tricky zu bauen, also auch aus Accessibility-Sicht.

Genau, und da ist der Input auch ein Content-Editable.

Was daran liegt, dass sich diese Chips, also wenn du schon so Values ausgewählt hast, dann tauchen die dahinter eben als, oder davor, besser gesagt, als Chips auf.

Du kannst die dann wieder wegxen, wenn du möchtest.

Und genau, da ist halt ein Content Editor im Spiel.

Naja, interessant.

Also ich habe selber in der Praxis tatsächlich wenig gehabt in den Projekten, wo ich jetzt, oder wo ich dann arbeite.

Woran ich mich am meisten erinnere, ohne da jetzt so viel dranhängen zu können, ist tatsächlich die ursprünglichen Kombinationen, die es gab in der HTML-Arbeitsgruppe.

Ich meine, dass das schon Ende der 2000er-Gespräche war, ich glaube, es war eines der ersten Features eben halt, die letztendlich mit der neuen, mit HTML5 dann eben halt quasi aufkamen und das war ganz, also das ist irgendwie so hängen geblieben.

Ich glaube, das findet man jetzt sicherlich noch auf den ganzen Mailing-Listen eben halt viele Gespräche, Konversationen dazu, aber ich hatte den absoluten Eindruck, das war relativ früh Teil von HTML5, relativ früh war das auch stabil und ich hatte jetzt gerade irgendwann aufgeschnappt, weil das Glücksrad ja immer MDN mit verlinkt und MDN sprach davon, hat seit 2015 gut supported.

Mein Eindruck ist, dass das schon tatsächlich weiter zurückgeht.

Wahrscheinlich nicht jetzt an widely available bei Baseline jetzt eben halt, aber ich weiß nicht, aber ich kann mir vorstellen, da gab es einen Browser-Nachzügler dann in dem Fall, weil ich hatte den Eindruck, dass der Support schon früh auch relativ weit war.

Also wenn man hier unten guckt, dann also in der Support-Table, also Edge ist halt ab Version 12, aber es liegt daran, dass ja Edge erst mit 12 Edge war, also es war ja quasi die Fortführung von Internet Explorer, davor war es halt Internet Explorer 11, der ist ja aber in der Liste nicht mehr drin, logischerweise.

Weiß ich nicht.

Oder es liegt daran, dass dann Opera Mini, ich weiß nicht, ob es den noch gibt, also ob der dann so eher ausgestorben ist.

Oder war es vielleicht Presto, also die andere Opera Engine, Vielleicht sowas, ja.

Das geht hier jetzt zumindest aus der Tabelle so nicht so gut hervor, ne?

Aber man sieht schon, okay, schon Chrome 1, also sagt, glaube ich, schon viel.

Und Chrome war natürlich dann, ich glaube, auch das ist mir letztens nochmal runtergekommen.

Ich glaube, da ist es auch ganz interessant, sich diese ganzen Browser-Shares über die Zeit anzugucken.

Jetzt wünsche ich, hätte ich das noch besser in Erinnerung, aber es war ja dann erst in den 2010ern irgendwann, ich glaube, es hat drei, vier, fünf Jahre gedauert.

Bin ich nicht mehr ganz sicher.

so in dem Dreh, bis Chrome tatsächlich dann Nummer 1 Browser war, also den AI eingeholt hatte, aber nichtsdestotrotz, Chrome ist ja eigentlich super aus den Startlöchern gekommen.

Also Chrome wurde veröffentlicht, ich glaube, sofort, 2008 war das, ja.

Und dann gleich Millionen von Downloads und das ist ja eine wahnsinnige Erfolgsgeschichte eigentlich in dem Sinne oder auch nicht, weil manche würden das vielleicht auch jetzt anders betrachten, aber ja, aber entsprechend, genau, haben wir ja zurück zu dem Attribut, entsprechend gibt es auf der Seite schon sehr lange gut zu beurteilen.

Also HTML5 ist ja auch, letztlich hat er viel standardisiert, was der Internet Explorer schon seit jeher mitgebracht hat.

Unter anderem war das eben so Document Design Mode.

Also man konnte ein ganzes Dokument eben mit, also Document Dot Design Mode gleich True, dann so in so ein YZWIC-Dings umwandeln.

Und Content Editable war ja dann sozusagen die kleine Version davon für einzelne HTML-Abschnitte nur.

Ein anderes Ding, was ja auch eins zu eins übernommen wurde, war die Drag & Drop API und die wurde halt nicht verändert, obwohl die, eigentlich von der Usability total kacke war, aber eben weil es halt einfach schon so lange gab im IE, dass man gesagt hat, komm, wir nehmen das jetzt so und dann ist das halt so.

Genau, es wurde ja auch viel generell reverse-engineert und in Specs gegossen, was einfach so wild vor sich hin gewachsen ist früher.

Ich hatte da aber auch mal einen Blogpost geschrieben über so Dinge, die der IE angeht.

Im Englischen würde ich sagen, pioneert hat oder was so auf den zurückgeht und da tauchte das auch drin auf.

Das verlinke ich dann auch mal.

Ja, ich glaube, da gibt es ganz interessante, so historische Details und so eine echte Beschränkung aus Standardentwicklungssicht, also zu sagen, okay, man folgt diese, ja, dass man eben halt schaut, dass man letztendlich das berücksichtigt, was schon implementiert wurde.

Da gibt es auch einen interessanten, ich meine, ich habe den, finde den jetzt, ich habe den ganz kurz geguckt, auch von der CSS-Arbeitsgruppe auch eine Liste von Sachen, die die eigentlich nicht mögen am Design von CSS, so Probleme, also eine Liste, die auch schon seit 10, 15 Jahren oder sowas gepflegt wird, sehr interessante Punkte dabei, warum manches, die auch erklärt, warum manche Sachen so sind, wie sie jetzt sind, wobei jeder weiß, okay, das ist eigentlich kein gutes Spec-Design, nicht gut für die Sprache und einfach Sachen, die historisch so gewachsen sind.

Ja, genau.

Das hat man ja auch bei Bar-Time-Elementen gesehen, die es eben schon gab, die im Grunde deprecated waren, die aber irgendwie dann doch alle das weiterbenutzt haben.

Denen wurde einfach dann ein neues Leben eingehaucht, in dem denen ein anderer Zweck zugeteilt wurde.

Das klingt jetzt auch so semi-Zufallsgenerator, du hast so ein bestimmtes Element im Kopf, falls wir uns damit angucken sollen.

Ach so, nee, nee, also so zum Beispiel B für Bold Text ist ja so ein Kandidat, der deprecated war, weil es ja Strong gibt und dann haben die Leute aber B trotzdem benutzt und dann haben die halt gesagt, okay, dann ist jetzt B so für, ich glaube für Eigennamen und das gleiche für I und Ejelic, für I und EM, so.

Das ist ein, können wir, wollen wir da ein bisschen bleiben bei den Elementen?

können wir machen.

Ich wollte nur noch hinzufügen, Content Editable hat einen ganz groß, also so vielleicht zwei Dinge.

Du kannst ja bestimmte Dinge nicht machen wie hier Placeholder oder sowas.

Also jetzt mal ungeachtet dessen, ob du das möchtest, aber manchmal ist Placeholder ja ganz gut.

Da habe ich einen guten Trick.

Und zwar, wenn du kannst quasi dieses Element selektieren und wenn das Doppelpunkt empty ist, dann kannst du da quasi ein Pseudo-Element drin rendern.

Das den Placeholder-Text hat.

Und sobald du quasi reingehst und schreibst, dann ist ja nicht mehr empty und dann geht der Placeholder weg.

Sehr cooler Trick.

Und das andere ist, dass Content-Editable ja auch Rich-Text kann.

Das heißt, wenn du hingehst und Inhalte jetzt aus Word oder sowas, was halt so, vielleicht CMS-User machen, nimmst, die formatiert sind und reinkopierst, dann kopierst du eben auch die ganze Formatierung mit rein.

Und da ist vor relativ kurzer Zeit was dazugekommen, dass das eben abstellt.

Und zwar konntest du früher nur die Values true oder false setzen und jetzt kannst du auch plaintext-only setzen.

Und dann kümmert sich der Browser darum, um eben wirklich alles an Rich-Text-Formatierung rauszustrippen.

Und dann funktioniert das eigentlich so, wie man das glaube ich immer schon haben wollte.

Also quasi wie Command-Shift-V?

Ja, genau.

Ja, das ist tatsächlich noch nicht so alt, ne?

Ich glaube, in den letzten zwei Jahren, oder?

Ja, genau, zwei Jahre würde hinhauen, glaube ich.

Würde ich auch mal so sehen.

Ganz interessant.

Und jetzt drüber abbiegen auf hier Strong B und M und I und weiß nicht, da gab es noch eins.

Das fand ich großartig und die finde ich jetzt großartig aus der Sicht auch so, was die Geschichte von HTML und X-ATML eigentlich tatsächlich anbelangt, weil es gab dann, glaube ich, es hat auch einige Jahre gedauert.

Es ist alles im Feld, es dauerte immer erst mal.

Es ist alles erst mal präsent für ein paar Jahre, aber da hatten wir ja tatsächlich so diese Idee, Nee, wenn du irgendwo ein B-Element benutzt, dann musst du das durch Strong ersetzen und wenn du irgendwo ein E-Element hast, dann durch EM.

Und.

Dann war das Gospel irgendwie, dann wurde das irgendwie so runtergepredigt und HTML5, ich bin auch nicht sicher, du hast es vielleicht angedeutet und vielleicht hast du da noch Sachen jetzt gerade so, erinnerst du dich an Sachen, wie das dann ablief.

Ich bin nicht mehr sicher, ob HTML5 da irgendwie wirklich diesen Standpunkt bezogen hatte.

Ich meine nicht, vielleicht war es auch ein ex-HTML2-Relikt, ich würde das gar nicht mal ausschließen.

Auf jeden Fall war dann eigentlich schon auch relativ früh absehbar, nee, diese Elemente bleiben.

Und was interessant ist war und ich möchte das hier nicht, da in dem Fall möchte ich nicht so schlau daher schnappen, weil ich muss auch sagen, es hat bei mir auch eine, Weile gedauert, bis bei mir der Groschen gefallen ist was B und I eigentlich zum Beispiel wirklich bedeuten, wann wir das benutzen wollen, eben halt und dass die absolut legitim sind, die haben halt leider immer noch diesen Ruf und den, von, oder beziehungsweise ganz klar wir haben die präsentationsbezogen.

Aber die hatten eigentlich immer implizit, auch schon von der Historie her, den Bezug, dass wir in Papers zum Beispiel irgendwie eine, wirklich sagen wollen wir, eben einen Begriff hervor und man kann jetzt sagen, der ist präsentationsbezogen, wenn du so willst, aber diese Hervorübung des Begriffs war letztendlich schon etwas, um auch gleichzeitig eine andere Bedeutung zu signalisieren.

Also ich glaube zum Beispiel, ein Use-Case wäre jetzt zum Beispiel auch vielleicht einen übersetzten Begriff darzustellen, dass man den kursiv stellt.

Da kann man dann eben halt ein E-Element für benutzen.

Also persönlich habe ich das auch eher so, also ich benutze selber in meiner Praxis, also an den Seiten, die ich baue an den Projekten, öfter I-Elemente, B eigentlich fast gar nicht.

Also den Fall habe ich jetzt weniger, könnte ich wahrscheinlich auch schwerer erklären, aber I zum Beispiel ist eine Sache, dann hat man vielleicht einen fremdsprachlichen Begriff, stellt den eben halt kursiv, da ist nichts dabei.

Aber was interessant war eben, zurück zu dem eigentlichen Einwurf, ist eben halt, wir haben dann wirklich dann da, ich weiß nicht, ob es mit Schärfe geführt wurde, aber wir hatten dann diese Ansage so ungefähr so, ja, nee, nee, du kannst jetzt, darfst du kategorisch keine B&E-Elemente einsetzen, was einfach de facto falsch war.

Also zumindest für die längste Zeit.

Ich habe gerade mal geguckt, B, also ich wollte die Seite bei der MDN dafür öffnen, B heißt das Bring-to-Attention-Element.

Genau, was sagen die da?

The element is used to draw the reader's attention to the element's contents, which are not otherwise granted special importance.

Was jetzt die konkreten Beispiele sind.

Usage Notes.

Genau, es gibt schon Beispiele hier.

Ich bin mir da nicht immer so sicher.

Also manchmal ist ja auch die MDN-Doku nicht so, also manchmal liegen sogar die daneben.

Weil das ja auch teilweise wirklich nicht trivial ist.

Und bei I, das google ich auch noch mal.

Ja, spricht Alternate Voice, glaube ich.

Ah, die Idiomatic Text Element.

Das ist auch sehr schlau.

Das eine ist auch was mit B, das andere ist was mit I.

Represents a range of texts that is said from the normal text for some reason.

Such as technical terms, taxonomical designations.

Okay.

Ja.

Also ich glaube, also ich gucke jetzt auch, also die gucken beide ja anscheinend, wo wir jetzt gerade auch in die Spezifikationen rein so superklar wird es ja nicht.

Ich glaube, was hilfreich ist, ist so die Idee, wenn man die Historie von HTML im Kopf hat und sagt, okay, jetzt Berners-Lee und in diesem ganzen akademischen Kontext haben wir da vielleicht Papers mit aufgesetzt und, dargestellt und in akademischen Papers haben wir das, glaube ich, hier, dass man dann eher nachvollziehen kann, okay, hat man eine Fettstellung oder eine, ich weiß jetzt nicht, Deutsch spricht hier.

Italisierung, Kursivstellung.

Kursivstellung.

Kursivstellung und.

Benutzt das da eben halt und ich glaube, es ist letztendlich eine Übersetzung, also mein Wahrnehmung ist, es ist eine Übersetzung, dass man sagt, okay, um so ein Paper eben halt in HTML zu schreiben, brauche ich eine Möglichkeit, das eben halt kursiv zu stellen und mir ist da, glaube ich, einfach nicht hinter, aber ich glaube auch, wenn man dann eben halt ein Dokument schreibt, was eben halt ähnliche Use Cases hat, wo ich auch sage, ich möchte jetzt hier einfach was kursiv stellen, weil es einfach eine andere Stimme darstellt, ein bisschen anderen Content darstellt, es wird dann ein bisschen subtiler, aber dann merkt man auch eher, okay, es ist eigentlich angemessen.

Das ist keine Betonung, Es ist keine Emphasis, es ist auch keine Strong Emphasis.

Es ist einfach nur, fällt ein bisschen aus dem Rahmen, brauche ich ein anderes Element.

Spiegelt sich ja auch, glaube ich, nicht in den Screenreadern wieder, im Vorlesen oder sowas.

Also, ich glaube, das ist dann einfach, zählt ja dann als ganz normaler, also wie wenn es ein Span wäre oder sowas in der Art.

Wäre mir jetzt auch nicht bekannt, dass das jetzt groß anders hervorgerufen wird.

Was ich mich ja gerade gefragt habe und was irgendwie, weiß nicht, ich habe nie was drüber gelesen oder vielleicht doch und vergessen, aber auch nicht mit niemandem unterhalten.

Warum gibt es denn überhaupt, also warum hat das W3C überhaupt irgendwann mal Strong und EM aus der Taufe gehoben, um dann B und I abzulösen?

Weil ich glaube, in HTML4 waren die ja wirklich deprecated.

Das war halt so, nee, benutzt es nicht, aber dann haben es halt irgendwie alle doch benutzt.

Und die Browser können ja auch so Dinge aus Rückwärtskompatibilitätssicht eh nie abklemmen, so gut wie nie.

Genau, da frage ich mich, also was hat die überhaupt geritten für Dinge, wo es schon eben Elemente gab, neue Dinge zu entwerfen und dann überhaupt dieses ganze Dilemma entstehen zu lassen?

Du siehst mich hier wahrscheinlich auch beziehungsweise seit der Zuhörer jetzt weniger am rumschauen, weil hier ist es also Strong und EM, wir haben es jetzt eben beide schauen, sind tatsächlich schon seit HTML2 dabei, sind nicht seit der ersten Version dann.

Inkludiert und das gibt den Verdacht und waren seitdem auch immer dabei.

Und ich gucke gerade in die, ich schicke dir mal eben kurz auch den Link hier eben so rüber, aber ich schaue selber gerade mal eben, ob das irgendeine Indikation gibt, ist jetzt nicht viel bei, weil die Spezifikation damals, also jetzt, was wir für HTML2 haben zum Beispiel, wirklich, also sehr, sehr knappe Spezifikation eigentlich ist.

Sagt hier eigentlich, spricht hier jetzt nur ich vor in Emphasis und Strong Emphasis.

Ich weiß es jetzt so ad hoc nicht.

Ich befürchte, weil es seit HTML2 dabei ist, da war die Diskussion jetzt nicht groß, was jetzt irgendwie diese semantischen Nuancen anbelangt, dass man da einen Bedarf gesehen hat, wahrscheinlich eben halt so eine Art der Betonung wirklich abzubilden.

Und dadurch, dass, ich erinnere mich auch, aber da lässt mir mein Gedächtnis jetzt ein bisschen im Stich, wie das dann alles, zum Beispiel auch mit XHTML2 weiter lief.

Das vielleicht nochmal so als Randnotice, das war ja so lange das W3C-Projekt, so als Nachfolger von HTML4 slash XHTML1.

Aber es war so eine Art, keine Ahnung, sowas wie Duke Nukem Forever.

Also so eine Art Art Vaporware der Spezifikation.

Genau, was dann irgendwann, wo dann Schlussstrich drunter gezogen wurde, als irgendwie klar war, dass diese XML, diese.

Fetisch vielleicht irgendwie zu nichts führt für normale Menschen, die Webseiten bauen wollen und dann hat man halt HTML5 gemacht und gegebenenfalls ist da aber eben was reingeflossen von XHTML2, Ja, das ist auch ein interessantes Thema letztendlich.

Also X-Hatim L2 war wirklich, es ist fast ein bisschen schade, dass das nirgendwo hinging.

Aber ein anderes Thema vielleicht.

Nur zurück zu Strong and EM zum Beispiel, sind beide drin im Entwurf.

Also so ad hoc von den Entwürfen, die wir jetzt gerade sehen, keine Indikation, dass es, also ich wüsste jetzt auch nicht, wenn ich sehe, ob das irgendwann mal wirklich ganz rausgenommen wurde.

Vielleicht gab es auch Diskussionen, sicherlich gab es da Diskussionen darüber.

Aber ich kann mich jetzt auch an keinen Entwurf erinnern.

Aber klar, da wurde dann, es gab eine Phase, wo glaube ich, alles mal auf dem Frühstand war und man guckt halt, okay, weil das jetzt präsentationsbezogen ist nicht und so.

Und es gab eben halt diese Zeit, wo B&I und Strong und EM eben halt dann irgendwie.

Ja, letztendlich das eine durch das andere ersetzt werden sollte.

Ja, es gab ja auch Browser- Hersteller, die neue Elemente sozusagen einfach geschippt haben.

So IMG kommt ja auch aus dem Netscape-Browser.

wir haben dann gesagt, so wir machen das jetzt und wir nennen das auch nicht Image, weil muss man ja viel weniger tippen, wenn man das IMG nennt ähm, Wobei es ja einen Alias gibt zu IMG, das heißt, wenn du Image schreibst, dann ist es ja automatisch ein Alias auf IMG, also das kann man mal ausprobieren.

Und vielleicht ist es ja auch hier so gewesen, dass irgendwie der eine Browser, damals waren das ja jetzt nicht unbedingt Microsoft und Netscape, sondern noch, da gab es ja noch so Viola und Mosaik und Lip-Dub-Dub-Dub und so.

Genau, dass der eine das geschippt hat, der andere das und eigentlich meinten beide das Gleiche, wollten beide das Gleiche damit machen und dann musste man es eben vereinheitlichen und dann hat man gesagt so, ja, wie kann man das denn so machen, dass ihr irgendwie beide, happy seid und komm, dann gibt es eben beide Sachen so.

Ich frage mich gerade, wie fällt dir und anderen zu, dann auch bekannt diese von Jay Hoffman, glaube ich, diese History of the Web-Serie und Bücher, glaube ich.

Die Podcast-Serie, ne?

Da bin ich ein bisschen überfragt, ob er sowas macht.

Kann sein, ja.

Ich kenne jetzt sehr die schriftlichen, seine Artikel und auch das Buch dann dazu.

Ich freue mich gerade, ob er das sogar mal behandelt hat, beziehungsweise das klingt ein ganz interessantes Thema dafür auch.

Der Podcast ist auf jeden Fall mega geil, also super cool.

Ich habe den wahrscheinlich schon mal irgendwann erwähnt.

Genau.

Unsere Hörerinnen, ihr Hörer, ihr hört ja gerne Podcasts Und wenn er an sowas interessiert, Zeit, Historie, dann ist der Mieger.

Cool.

Genau, also auch da haben wir nicht so richtig den Durchblick, wie das gekommen ist.

Wir wissen nur, dass es so ist.

Sollen wir noch einen, also ich glaube, wenn man auf die Zeit guckt, dann könnten wir eine Runde spielen und dann haben wir schon so eine Dreiviertelstunde verballert.

Das stimmt, wir sind gut dabei.

Genau, ist aber nicht schlimm.

Alles gut.

Ich aktiviere hier mal den Generator nochmal.

Das Optschnell nennt.

Guck mal, das ist doch gut, weil wir hatten in der Vorbesprechung das einmal getestet und da hatten wir Opt Group.

Ja, das erlaubt uns sicherlich einen Schwenker dahin nochmal.

Letztendlich, was gibt es zu Optionen zu sagen?

Also ein Arbeitspferd in HTML-Formularen, oder nicht?

Ja, auf jeden Fall.

Was man ja irgendwie so gerne vergisst, ist, also ich würde sagen, bei Optionen, wenn man jetzt so spontan sagen würde, wo kann man das einsetzen?

Was würdest du sagen?

Was würde dir einfallen?

Ja, Select-Elemente.

Genau, würde mir auch einfallen.

Und ich würde aber dann auch wieder vergessen, also selbst, obwohl wir das in der Vorbesprechung hatten, dass es ja Opt-Group-Elemente noch gibt und man das ja da drin auch haben kann.

Und was ich jetzt hier auf der, was ich auch vergessen habe, was ich jetzt hier auf der Doku-Seite sehe, ist, es gibt ja immer noch das Data-List-Element.

Da muss ich auch gerade, bin ich so frei, gleich einzuhaken, weil genau daran muss ich auch gerade denken und das finde ich eigentlich fast noch interessanter gerade.

So Ad-Rock-List-Elemente eigentlich.

Und klar, das benutzt genauso das Option-Element.

Genau, das Data-List Element ist ja im Prinzip sowas wie, dass man zu Inputs, also ähnlich wie bei einer Combo-Box, die ich vorhin erwähnt hatte, dass man eben, so eine Vorauswahl bereitstellt an Dingen, an Werten.

Das Coole ist, dass du das ja auch wirklich so ziemlich bei allen Inputs anwenden kannst, also selbst bei Input-Type-Range zum Beispiel oder bei Datumselektoren.

Die Kollegen vom Wo wir sind, ist vorne Podcast, der leider, leider, der jetzt quasi der Stun gegeben hat.

Was ich auch verstehe, vielen Dank aber für eure, für euren tollen Podcast, die haben in der Folge 43, rumgespielt mit dem Data-List-Element und das an den Range-Slider dran gehängt und das finde ich total cool, also das so total underrated, das Data-List-Element.

Ja.

Ja, ja, das ist, was mir einfällt gerade, ist, also ich bin in mehreren Projekten und mag eben halt auch die Vielseitigkeit von der Implementierung halt, so was, Type Ahead und ähnliches anbelangt, so dass die Ergebnisse nicht vorselektiert werden.

Ich habe es irgendwann probiert noch für, ich erinnere mich so dumpf, wenn man, da habe ich mit, für das Web Development Glossary, für das es auch eine Webseite gibt, also webglossary.info und schneller Kontext da, also das Glossar besteht jetzt in der Webseitenversion geradeaus auch 3500 oder mehr Begriffen und es gibt auch eine Eingabe eben halt per, oder gab, ursprünglich wollte ich das per Data Distillment.

Mit dem Data-List-Element versehen, um eben halt eine schnelle Vorauswahl zu ermöglichen.

Stellte sich aber heraus, dass es auf einigen Geräten dann tatsächlich so langsam war und so schwer, also zumindest ein mobiler zu benutzen, dass ich mich dann, glaube ich, dann letztendlich dagegen entschieden habe, das dazu zu benutzen.

So eine Randbemerkung einfach, weil also für tausende von Einträgen könnte das eben auch ein bisschen zu schwer werden dann.

Ja, genau, das ist auch immer so ein bisschen am Data-List also Element, also beim Range Slider ist es dann weniger ein Problem und auch bei dem Date Picker nicht, aber so dieses, wie also wie gießen die Browser das in UI, das geht so ein bisschen in die Richtung wie Multi Select, das ist ja auch so teilweise sehr schmerzhaft, wie das abgebildet wird in den Browsern, und was man da für Einflussmöglichkeiten auf die Gestaltung hat.

Genau, und beim Datei, bei diesem Type Ahead, da weiß ich noch, ich weiß nicht, vielleicht ist es jetzt auch anders, aber da wünschte ich mir manchmal in den Browsern, und die sind sich da auch nicht einig, dass man definieren kann.

Also muss quasi vom Anfang des Worts gematcht werden oder kann es ein Wortbestandteil sein, der gematcht wird?

Also da sind die auch unterschiedlich, was die dann daraus filtern, meine ich.

Ja, das ist interessant.

Ich glaube, so als Nutzer kriegt man das wahrscheinlich weniger mit, wenn man jetzt nur mit einem Browser arbeitet, ist das Verhalten dann sicherlich konsistent, aber ich kann mir auch vorstellen, dass das klingt so, als ob das dann unter unterschiedlichem Browser-Namen halt unterschiedlich ist.

Das ist mir selber auch noch nicht aufgefallen, aber ja, wenn das nicht alles durchspezifiziert ist, dann.

Ist wahrscheinlich das Problem, ne?

Und sonst bei dem Options-Element würde mir noch einfallen, dass man ja eben neuerdings HRs dazwischen klemmen kann, wenn man möchte, wenn man so ähnlich wie mit B und I quasi einfach nur optisch eine Gruppe absetzen möchte.

Und ja, in der Vorbesprechung und eben haben wir es ja auch schon gesagt, das Opt-Group-Element gibt es ja auch noch, wo man auch einen Teil der Ausfallmöglichkeiten zusammengruppiert.

Wobei ich jetzt im Kopf gar nicht sagen kann, wie es sich zum Beispiel auf Mobile darstellt.

Auf Desktop ist es ja dann wirklich so, dass man so eine Eindrückung hat.

Also ähnlich wie so Listen.

Ich meine auf Mobile aber auch so, oder nicht?

Ich habe mal eben schnell nachgeschaut hier.

Was für eine Plattform hast du?

IOS oder Android?

Android.

Ich schaue gerade hier.

Das finde ich schnell.

Ansonsten gibt es noch die Möglichkeit, also Disabled Attribut haben wir.

Das ist irgendwie klar, dann kann man auch einzelne Options nicht auswählbar machen.

Und man kann auch noch ein Label Attribut dran setzen.

Das Attribut ist Text for the Label indicating the meaning of the Option.

Das müsste ich mal ausprobieren, weil ich gar nicht weiß, was dann passiert.

Denn das Option-Element ist ja jetzt kein so ein Void-Element, das sich selbst schließt.

Braucht aber wiederum auch keinen, ja, nimmt einen Inhalt, braucht aber keinen Antake.

Genau, und der Inhalt ist ja das, was man auch dann sieht, während die Value das ist, was dann eben im Formular abgeschickt wird, aber bei dem Label, da wundere ich mich, wenn man jetzt das Label setzen würde, was da wohl passieren würde.

Also, dann würde dann, würde ich das dann auch sehen.

Genau, das muss ich mal austesten.

Ja, da gibt es, glaube ich, auch tatsächlich, da gibt es noch ein paar Sachen, ein paar verschiedene Möglichkeiten, die man da mit dem Element oder mit dieser, Elementgruppe letztendlich dann hat.

Für mich so kurze Notizen, weil ich es eben gerade auf Android nochmal getestet habe, zumindest irgendwie, weil die Darstellung, klar, ist ein bisschen anders jetzt als auf Desktop, aber, Opgroup selber würde da auch so als nicht selektierbar und mit einer Einrückung der anderen Options dargestellt werden.

Okay.

Und mir ist gerade eingefallen, dass ich in MDN in diesem Code Beispiel ja sogar direkt reinkoden kann und habe da mal ein Label an so eine Option gesetzt und tatsächlich ersetzt das Label dann den, Text, der sozusagen Content des Option-Elements wäre.

Genau.

Gut zu wissen.

Wissen, dass man nicht braucht, mäßig wahrscheinlich.

Genau, weil ich wüsste nicht, wofür ich das benutzen könnte.

Aber irgendwie mag ich sowas ja immer.

Ja, mögen wir das nicht alle.

Ja, ja, wer weiß.

Irgendwann hängt man genau an der Situation und ist dann froh, dass man HTML-Güxtrad gespielt hat.

Ja.

Ja, ja, total.

Da findet man echt immer neue Dinge, also, die man einfach nicht erwartet.

Ja.

Wollen wir uns doch an einem probieren?

Ja, da kommen wir auch noch eins raus.

Dann...

Oh, ein Attribut, das heißt Writing Suggestions, zusammengeschrieben, das ich noch nie gehört habe.

Ich bilde mir ein, dass das auch relativ neu ist, ein paar Jahre oder so.

Aber es ist auch nicht jetzt irgendwas, das ich jemals mal benutzt hätte.

Ja, also ich sehe gerade, es wird in den Chromium und im Browsern und in Workkit unterstützt.

Firefox nicht.

Ja, und Limited Availability, ja klar.

Also das ist, das deutet schon darauf hin, dass das wahrscheinlich neuer ist.

Okay, also ich kenne das ja immer mit diesem Autocomplete, dass ich das dann manchmal abschalte für bestimmte, in dem Moment nicht Autocomplete.

Es gab auf jeden Fall ein Attribut, mit dem man dem Browser sagen kann, so hör auf, immer Felder vorauszufüllen.

Also wenn du so ein Feld wieder erkennst, dann macht er das ja manchmal, dass er dir dann anbietet, das wieder reinzuschreiben, was du schon mal reingeschrieben hast.

Das finde ich manchmal blöd.

Und er ist, ja, das Spellcheck.

Ja, aber genau.

Und da gibt es ja noch dieses, mit dem, dass er automatisch korrigiert, dass er so, dass du irgendwas reinschreibst.

Spellcheck oder nicht?

Spellcheck, stimmt.

Ja, das ist Spellcheck.

Ich versuche es auch gerade, die normale Spezifikation jetzt auf alles auf einer Seite sehr langsam gerade bei mir.

Some browsers provide writing suggestions to users as they type in editable fields.

Suggestions usually appear as grayed out text positioned after the text cursor, completing the user's sentence.

Das genau, also habe ich noch nicht so erlebt, also klar so aus der IDE oder so kenne ich das oder aus den Combev-Tools, aber sonst ist mir das noch nicht aufgefallen, finde ich aber auch interessant, müsste ich mal irgendwie auch tiefer nicht reingraben.

Ja, ja.

Ja, ja, ja.

Also ich, ja genau, ich überfliege hier auch gerade die Spezifikationseintrag.

Und ja, ich glaube auch, man denkt da jetzt eher automatisch an das, was wir in unserer täglichen Arbeit sicherlich in der IDE dann kennen, dass man die Möglichkeit hat, sowas letztendlich auch in der Text-Serie oder sowas mit anzugeben.

Ich weiß nicht, ob das jetzt durch die AI-Iffizierung der ganzen Browser kommt oder so.

Also ich meine, seit Chrome 124 wird das supported, was jetzt auch noch nicht so super, super lange ist.

Und seit Safari 18, was ja glaube ich die Version vor der aktuellen ist, meine ich.

Also jetzt sind sie ja gewechselt auf so ein quasi Jahreszahlschema.

Also hinteren Zahlen.

Auch für Safari?

Ich bin da gar nicht so...

Ja, alles.

Ja, okay.

Ja, interessant.

Müssen wir mal gucken, ob es da irgendwie so einen Web.dev-Artikel gibt oder irgendwo muss es ja, aber es ist mir wirklich überhaupt noch nicht unterbekommen.

Ja, man hat so den Eindruck zuletzt, also glaube ich in den letzten Jahren, wir sehen viel Polish in der, also Politur oder Polieren eigentlich der Spezifikation.

Also ich glaube, es gab ja auch so Sachen wie, ob das ja das Search-Element ist, und dann hatten wir noch, wo wir vorhin bei Formularen waren, Selected Content, war glaube ich auch ein Element, was neu dazu kam letztes Jahr dann, wenn ich mich nicht irre und also so kleinere Sachen, was jetzt nicht eine Welle durchs ganze Feld schickt und jetzt alle denken so, wow, okay, hier kommt passiert jetzt gerade irgendwas riesengroßes, aber Sachen, die, Developer und die User Experience dann letztendlich nochmal ein bisschen ja, dass man einfach mehr Feintuning machen kann und allem, ne?

Ja.

Ja, eine ganz gute Phase der Entwicklung da eigentlich.

Man merkt, wie das dann alles reift eigentlich gerade.

Wir haben eine sehr weitentwickelte Spezifikation, wo wir letztendlich genau gucken, dass wir Feintuning betreiben.

Clean-Up sehe ich jetzt weniger.

Das ist auch schwieriger natürlich, was wir jetzt so rückwärts, abwärts kompetenziert anbelangt.

Genau, das passiert ja wirklich selten.

Also jetzt ist ja hier, was ist das?

Das XSLT wird ja rausgebaut, was aber jetzt eher daran liegt, dass das ein Sicherheitsproblem ist.

Also eigentlich ist es ein Organisationsproblem, aber es resultiert halt in einem Sicherheitsproblem.

Weil ein einarmer, verlorener Mensch, der aus diesem Meme, das man so kennt, mit diesem riesen Jenga-Turm, wo dann so unten dieser eine Klotz ist, dann dieser Open-Source-Entwickler in Nebraska, der diese eine Library macht, auf der alle aufbauen.

Der musste sich darum kümmern und hat dann gesagt, so mache ich jetzt nicht mehr, ist mir zu blöd.

Es sind so viele Nutznießer, die sollen das mal machen.

Genau, und selbst Google schafft das aber jetzt mit seinem Personal nicht, das zu übernehmen und es weiter zu pflegen.

Und darum bauen das ja alle Browsersteller aus.

Also nicht nur Chrome, sondern eben auch Firefox, die das sogar noch früher wollten.

Ja, ich glaube, da gibt es ganz interessante Artikel auch gerade und Kontroversen zu dem Thema.

Also nicht nur hat das ja selber dann direkt Wellen geschlagen, weil ich glaube, oh Gott, wenn wir jetzt in das Thema nochmal kurz ran wollen und versuchen wollen, ich glaube, wenn ich die Geschichte im Sinn hatte, ist, dass Google letztendlich schon quasi entschieden hatte, okay, wir entfernen die Unterstützung dann davon und dann ging das, glaube ich, mit zum Video-AC, glaube ich.

Ja, dann war das ein bisschen zu schnell.

Also die haben die Leute abgeholt, richtig.

Genau, und das wirkte dann auch eher so, okay, man wird hier vor vollendete Tatsachen gestellt und dann hier ist es gar keine Diskussion.

Und dann gibt es, glaube ich, auch viel Missmut gerade eigentlich, was Googles und Googles Marktposition anbelangt.

Ich weiß nicht, ob man da komplett hingehen muss, aber natürlich ist das dann nochmal der Fluch der Marktführerschaft, glaube ich.

Also wenn man in der Position ist, dass man so viele Nutzer hat und so viel Verantwortung letztendlich fürs Ökosystem.

Dann dass man da auch einfach das aushalten muss, dass da entsprechend auch, oder dass es leider auch einfach der Fall ist, dass da mehr Aufmerksamkeit bekommt.

Ich selber, ich kann mir vorstellen, dass hier in unserer Runde hier und alle, die jetzt zuhören, dass, das wahrscheinlich kein konkretes Problem ist und man dem vielleicht sogar was abgewinnen kann im Sinne von, der wird eben halt was ein bisschen aufgeräumt quasi, aber das ist nicht die universelle Meinung.

Ja, es ist halt so ein bisschen auch Nostalgie, weil es auch irgendwie, XSLT ist ja schon eine geile Technologie, also ich, also.

Ich finde das schon Wahnsinn, was da schon seit Dekaden mit möglich ist, aber es nutzt eben keiner im Entwicklungsalltag.

Also ich weiß noch, ich habe 2006 in einem Projekt gearbeitet, Open Exchange hieß das.

Das war im Prinzip so eine Art Gmail-Konkurrent in Open Source, den Jonas, glaube ich, eingesetzt hat auch.

Und da war es schon so, dass wir Komponenten gebaut haben, die wir einfach beschrieben haben.

Und es gab einen XSLT-Transformationsschritt danach, der das, was wir geschrieben haben, dann in viel Komplex aus HTML umgewandelt hat, also sozusagen transpiliert hat.

XSLT ist ja im Prinzip eine Transformationstechnologie.

Und damals gab es eben noch nicht Rounded, also Border-Radius und so Zeugs.

Und die Knöpfe mussten aber alle natürlich rund sein und dann gab es ja diese Technik dieser Sliding Doors, wo man dann irgendwie so ganz viel HTML-Manager ineinander geschachtelt hat, wo dann runde Ecken links oben, rechts oben, rechts unten, links unten reingesetzt wurden und so verschiedene Hintergrundgrafiken am Ende zu dieser Illusion eines Knopfes mit runden Ecken geführt haben und das haben die halt alles darin gekapselt, sodass die als Entwickler diese ganze komplizierte Scheiße einfach nicht machen mussten.

Jawohl.

Klingt so, als könnte man denen dann nochmal einen Kasten Bier hinstellen.

Eigentlich schon, ja.

So ungefähr.

Also zumindest damals.

Wow, ja, das waren nochmal ganz andere Zeiten.

Ja, die waren eh super fit.

Also die haben auch damals schon, das war so die Anfangstage von Ajax.

Ich meine, der Term wurde ja erst so, also der Begriff wurde ja erst 2005, glaube ich, überhaupt erfunden.

Und zu der Zeit war es ja dann auch wirklich asynchrones JavaScript and XML, Dann kam ja relativ bald Jason auf als viel kompaktere Datenstruktur und die waren halt direkt vorneweg dabei und ich so, ja, Jason, keine Ahnung, ich kenne nur hier den Schlechter aus den Horrorfilmen, aber ihr werdet schon wissen, was ihr macht.

Also das war schon cool.

Du konntest das jetzt eher mitbekommen, ich kam noch gerade ins Stocken kurz, weil, wo du sagst, mit Ajax und 2005, und dann gab es ja den von Jesse James Garrett, glaube ich, seinen Artikel dann dazu.

Mir ist jetzt mit Fronted Dog mal was untergekommen, ich schick's hier mal rüber, ich weiß nicht, ob wir es in den Episoden, Notizen unterkommen wollen.

Ich kam da jetzt noch nicht dazu, auseinanderzunehmen, weil hier war irgendwo in nennt sich, das ist so sowas, was ich auch auf vorne-Doc mal aufnehme, auf irgendeiner Seite Syscon Media, war, ein Artikel, der 2006 rauskam, der über XML-for-Client-Side-Computing spricht, der aber wiederum sagt, dieser Artikel erschien im XML-Journal on March 10, 2004.

Ich kam noch nicht dazu, es ganz auseinander zu nehmen, um zu gucken, ob wirklich, weil da wurde ich dann auch stutzig und dachte, sehr komisch, gab es diesen Begriff wirklich erst seit 2005, aber man kann hier auch nicht sagen, also ich glaube im ganzen Artikel kommt auch nichts von XML HTTP Request vor und so müsste man vielleicht noch mal vor, vielleicht haben Zuhörer noch Lust sich das auch zugute zu führen und mit zu forschen, was hier eigentlich passiert ist, weil man hat immer so den Eindruck, so Jahr 2005 kam es auf, hier gab es, wenn die sich nicht irritten in dem Jahr gibt es nochmal eine Indikation, vielleicht wurde das in irgendeiner Form schon mal ein bisschen eher benutzt.

Ja.

Ich meine Das ist halt, ich meine im Kopf zu haben, das ist 2005.

Ah ja, hier steht es auch nochmal Februar 2005.

Genau, da hat er seinen Artikel geschrieben.

Ajax, a new approach to web applications.

Genau, das kam 2005, ja.

Seitdem haben wir das dann, ja, haben das.

Wohl sehr beliebt, ja.

Ja, können wir auch nochmal drauf verlinken, einfach so.

Spaß.

Genau, und zu XSLT wollte ich noch den Hörtipp geben zum Podcast Egalia Chats, den ich auch immer sehr gerne höre, mit Brian Cadell und Eric Meyer, wo die eben auch eine Episode zu diesem Thema haben und das auch nochmal darlegen, wie es halt dazu kam und dass das schon seinen Sinn hat, auch wenn der eine oder die eine oder andere vielleicht ein bisschen traurig ist, wenn es dann nicht mehr da ist.

Genau.

Ja, cool.

So ist das mit der Webplattform.

Ja, machst du nichts.

Aber kommt ja sehr selten vor, also das meiste bleibt und das ist ja eigentlich wirklich.

Also das Gleiche ist ja jetzt auch so ein bisschen der Fall oder ich glaube, JPEG-XL ist ja auch so ein Kandidat, wo man irgendwie guckt, wie man das in die Browser jetzt reinbringt.

Viele Leute wollen das ja haben, aber eigene Decoder bauen dafür wollen die auch nicht und sich dann auf so einen externen Decoder verlassen, birgt halt dann auch wieder dieses Risiko, dass das so ein Einfallstor wird für malicious Code.

Und ich glaube, die Mozilla-Leute, die regeln das so, dass die, das Ganze irgendwie nach, also die nehmen so eine JPEG-Excel-Library, kompilieren die nach Rust und haben das dann so in ihrem Browser, in der Sandbox quasi wie so ein, wie wenn man selber Rust, also da WebAssembly laufen lässt.

Ich meine, so regeln die das und können dann sich auf dieses Sicherheitsmodell stützen.

Ich weiß nicht, warum Chrome das nicht auch so macht oder ob die es vielleicht dann auch so machen werden.

Ähm.

Aber da hat man so eine ähnliche Problematik.

Ja, das ist, glaube ich, tatsächlich auch ein ganz interessantes Thema, oder nicht?

Also ich muss auch kurz, also erstmal eben schauen, wann kam JPEG XL auf.

Ich glaube, das ist wirklich auch eine alte Idee mittlerweile.

Und dann gab es ja so Sachen wie JPEG 2000 und sowas.

Und ich glaube, das ist noch viel, viel älter.

Ich glaube, 1990er vielleicht sogar.

Das ist unglaublich.

Also ich bin da gar nicht dran an dem Thema in dem Sinne.

Also da kann man wahrscheinlich wertschätzen, dass da eine gute Komplexität gibt, wenig Appetit da irgendwas zu machen.

Aber immer wieder greift man ja mal ein Thema auf oder ein Artikel, wo dann, ich glaube, Jake Archibald hatte letztens auch irgendwie, oder schreibt, glaube ich, öfter mal über Grafikformate auch und Komprimierungen davon und sowas.

Und man hat dann immer mal einen Kandidaten, der vielversprechend ausschaut.

Ich glaube, wir haben ja eigentlich mit WebP und mit Aviv eigentlich auch sehr spannende Formate da.

Ich glaube, da steigt die Adoption mittlerweile auch an.

Aber es ist eigentlich auch interessant zu sehen, wie langlebig allein JPEG, TIFF und PNG jetzt eigentlich sind.

PNG hat ja auch vor einem Jahr oder so, glaube ich, noch mal ein Update erfahren in der Spec.

Und genau, und Browser haben auch lange gebaut, um Animated-PNG zu unterstützen.

Das ist jetzt auch.

Ob das natürlich am Ende immer eine gute Idee ist, so von der Dateigröße her.

Ist einmal dahingestellt.

Also wahrscheinlich nutzt man es, wenn man Transparenzen hat oder so, wobei das ja auch mit, Animated WebP geht und AWEF glaube ich auch, aber es ist halt dann doch nicht so trivial wie mit PNG.

Ja.

Und ich glaube, JPEG XL hat vor allem den Vorteil, dass es.

Auf Multithreading ausgelegt ist beim Decoding und Encoding, was schon mal cool ist, was eben auch nicht überall geht.

Und dass man ohne viel Aufwand aus JPEG XLs auch JPEGs machen kann, also, einfach ableiten kann aus diesen Daten und man im Grunde auch nicht zwei verschiedene Formate speichern muss, obwohl man vielleicht hinten raus zwei verschiedene ausliefern möchte.

Ich glaube, das sind so die wesentlichen Vorteile davon.

Und so dahinter stehen oder die entwickelt haben das ja in erster Linie die Leute von Cloudinary oder Leute, die bei Cloudinary arbeiten, also so ein Image-CDN.

Ich gucke mal, ob ich da noch was gleich googeln kann, das wir dann verlinken können, wer da irgendwie mehr wissen will.

Ja, so haben wir jetzt tatsächlich noch ein bisschen Bildformate auch noch mit eingebaut.

Ja, genau, den Artikel von Jake, den habe ich auch schon rausgesucht.

Ah, okay.

Und genau, du hast am Anfang einen Artikel, glaube ich, hinsichtlich IDs erwähnt.

Vielleicht, wenn du den noch findest und mir raussuchen kannst, dann verlinke ich den.

Wenn nicht, dann werden unsere HörerInnen den auch irgendwie finden können.

Ich glaube, du hast zwei Dinge genannt, aber irgendwie beide, die du beide meinst, bei Frontend-Dogma drin hattest.

Müssen wir nochmal schauen, vielleicht stimmen wir uns nochmal ab.

Genau, das können wir damit inkludieren.

Ich habe hier immer noch offen, die nachzuschauen, weil vielleicht ist es noch interessant für den anderen, was diese CSS-Liste anbelangt.

Die schicke ich dir dann nochmal rüber und vielleicht tun wir die mit.

Ja, ja, die kenne ich auch.

Also die poppt immer mal wieder auf.

Sowas wie No-Rap.

Warum haben wir das mit Bindestrich geschrieben?

Das ist in CSS nicht üblich oder Current Color ist glaube ich auch so ein Kandidat gewesen mit so einem Die Kapitalisierung glaube ich davon, und die Liste ist immer länger geworden also die gibt es jetzt schon eine Weile und am Anfang waren es vielleicht irgendwie 20, 30 Punkte und mittlerweile ist die glaube ich ein bisschen länger, also ja, vielleicht auch für jeden der das bereits schon gesehen hat, nochmal interessant nochmal reinzuschauen, weil eben halt einfach nochmal mehr Sachen dabei sind und das ist immer cool, Ja, super.

Das hat doch Spaß gemacht.

Das war sehr, sehr kurzweilig, was wir ja daran sehen, dass sehr viel Zeit in Fluge vergangen ist.

Da knüpfen wir auf jeden Fall.

Machen wir nochmal irgendwann weiter.

Genau.

Ich glaube auch, dass unsere Hörer in diese Glücksfahrtfolgen ganz gerne hören.

Also habe ich so immer mal wieder gehört.

Vielleicht täuscht mich, es ist total langweilig, dann sage ich schon mal Entschuldigung.

Aber es wird weitere geben.

Ich glaube, ganz, ganz, ganz schöne Aktivität eigentlich für die ganze Familie.

Höchstrad auch direkt zu spielen.

Genau, unter dem Weihnachtstraum kann man das gut spielen.

Genau.

Ja, wenn ihr hörenden Input habt, dann gerne her damit auf den verschiedenen Kanälen, die alle auf unserer Webseite verlinkt sind, als Symbole.

Also das sind die ganzen Kanäle, auf denen wir unterwegs sind.

Am liebsten aber natürlich in unserem Slack, wo allerdings du, Jens, nicht bist, weil du ein Slack-Hiatus gerade praktizierst.

Aber dann leite ich das auf jeden Fall weiter.

Genau, ansonsten deine Kontaktmöglichkeiten werden wir auch verlinken.

Ja, und sehr gerne.

Freue mich immer.

Also E-Mail, Mastermind, Blue Sky, ähnliches.

Und genau, also vielen Dank auf jeden Fall an jeden fürs Zuhören.

Hat Spaß gemacht.

Ja, fand ich auch.

Dann sage ich mal, schönen Tag dir.

Danke.

Und wir lesen und sehen und hören uns.

Jawohl.

Alles Gute.

Bis dann.

Tschüss.