Das heißt also, dieses Attribut, das wir jetzt also in HTML,
einem Input-Type-Checkbox geben können, steuert ausschließlich das Aussehen.
Ja, du möchtest doch nicht etwa darauf hinaus, dass sie das besser in CSS verfrachtet hätten?
Ich weiß nicht, ob sie es besser in CSS verfrachtet oder vielleicht auch in
den Müllschlucker verfrachtet hätten.
Aber ist das nicht de facto ein Präsentationsattribut? Ist das nicht allein
left mit anderen Mitteln?
Ja, ist es eigentlich. Ich weiß nicht, wie es euch geht.
Ich habe schon sehr oft Probleme im Web gehabt, mit Toggls zu verstehen,
ist dieser Toggl jetzt an oder aus? Mhm.
Music.
Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch.
Auf patreon.com slash workingdraft könnt ihr uns ein paar Euro in den Hut werfen.
Aus euren Beiträgen und den gelegentlichen Werbeblöcken bezahlen wir Domains,
Server, diverse Software-Abos und natürlich das Honorar unserer Audio-Producerin.
Danke euch allen für eure treue Unterstützung.
Revision 611. Wir sind heute zu dritt.
Da hätten wir aus dem Team die Vanessa. Hallo. Servus. Dann den Peter. Moin, moin.
Und ich bin der Shep. Und das bedeutet, heute haben wir keinen Gast und keine
Gästin, sondern wir wollen uns einfach mal wieder mit dem Safari befassen.
Einfach weil der ja nur alle Jubiläare mal rauskommt und dann aber immer einen
großen Haufen Neuerungen mitbringt.
Also nicht, dass die anderen Browser nicht auch viele Neuerungen hätten,
aber das bietet sich dann einfach an. Und in der Regel sprechen wir dann ja
auch über die anderen Browser.
Und wir reden nicht über den Digital Markets Act, oder?
Nee, also da tanzen wir, glaube ich, ein bisschen aus der Reihe,
oder? Weil das war jetzt ja viel Thema.
Wir beobachten das einfach. Und vieles hat sich ja auch schon wieder von alleine erledigt.
Möglicherweise auch durch andere Podcaster, die darüber gesprochen haben,
aber Apple rudert ja erstmal in die eine Richtung und dann rudert es auch wieder zurück. Mhm.
Genau. Aber ich denke, über den Safari freuen wir uns dann auch immer,
wenn es Neuigkeiten gibt, weil es ja auch bedeuten könnte, dass diverse Sachen nachgezogen werden.
Absolut. Und manche Sachen sind, also bei manchen Dingen sind die ja auch sozusagen
First Mover mittlerweile.
Ja, das stimmt. Ja, bei anderen Sachen, boah, ich habe letztens wieder festgestellt hier.
SVGs und CSS, dProperty als CSS setzen, dass man so den Pfad von einem Pfad
halt in CSS bestimmen kann, geht immer noch nicht.
Aber ist das denn geplant, dass das mal gehen soll? Andere Browser können das, allesamt.
Echt? Safari kann das nicht. Aha, das heißt, du brauchst ein SVG im Grunde gar
nicht mehr mit irgendwie Krempel im Marker füllen.
Du könntest das theoretisch alles über CSS fast regeln.
Naja, du kannst ja sowieso Sachen wie irgendwie Fill, Color und keine Ahnung,
so Zeug kannst du ja eh setzen.
Also diese ganzen Präsentationsattribute und der Pfad, also dProperty von einem
Path, Path ist auch ein Attribut und auch ein Präsentationsattribut.
Und alle anderen Browser können das. Dass du einfach so die Path-Function in
CSS hast und die halt eben dann einen Datentyp Pfad gibt.
Jetzt frage mich nicht, wie das aussieht mit Faden animieren und so.
Ich weiß, dass Chrome das kann.
Ja, wahrscheinlich so wie Offset-Path in CSS ja auch, glaube ich,
so was zumindest in so einer eventuell identischen Schreibweise entgegennimmt. Ja, möglich.
Jedenfalls D-Property in CSS in Safari geht halt gar nicht.
Okay. Tja. Naja, Safari hat ja eigentlich immer seine Stärken eigentlich in CSS, würde ich sagen.
Weniger in Web-APIs und in letzter Zeit eigentlich auch vermehrt im HTML.
Die haben sich auch so ein paar Leute, die bei Mozilla raus ausgestiegen wurden
oder sind geschnappt, die alle sozusagen nah an der WG-HTML-Spec sind.
Und ich finde, das merkt man auch. Also Und darüber sprechen wir auch gleich,
also dass da im HTML-Bereich sich auch einiges tut.
Sollen wir direkt damit einsteigen, weil das wäre auch das erste Thema eigentlich,
das wir uns rausgesucht hatten aus den Release Notes.
Nämlich, das ist jetzt ganz neu.
Ich weiß nicht, ob ihr in der Spec, aber zumindest in Safari ein Switch-Attribut
für Input-Type-Checkboxen gibt,
wo man die sozusagen in eine Browser-eigene Switch-Komponente schalten kann.
Jetzt musst du mir natürlich erst mal erzählen, was der Unterschied ist zwischen
einem Switch und einem Checkbox.
Eigentlich ist es ja so, glaube ich. Ja, ein Switch-Toggle, genau.
Ah, Switch ist ein Toggle, gut. Also eine Checkbox.
Also im Grunde unten drunter eine
Checkbox. Ja, klar. Also rein technisch gesehen ist das eine Checkbox.
Und deswegen ist es wahrscheinlich eben auch so, dass Apple den Input vom Typ
Checkbox erwählt hat, um dieses Switch-Attribut anzureichern.
Also Moment, Moment, warte mal. Also es gibt also auf der funktionalen Ebene
keinen Unterschied zwischen einer Checkbox und einem Switch-Toggle, richtig? Ja.
Ja. Das heißt also, dieses Attribut, das wir jetzt also in HTML einem Input-Type-Checkbox
geben können, steuert ausschließlich das Aussehen.
Ja, du möchtest doch nicht etwa darauf hinaus, dass sie das besser in CSS verfrachtet hätten?
Ich weiß nicht, ob sie es besser in CSS verfrachtet oder vielleicht auch in
den Müllschlucker verfrachtet hätten.
Aber ist das nicht de facto ein Präsentationsattribut? Ist das nicht allein
left mit anderen Mitteln?
Ja, ist es eigentlich. Also es ist auch tatsächlich die Frage,
warum man das, man hätte ja auch zum Beispiel die Appearance-Eigenschaft in CSS nehmen können,
wo man ja auch, glaube ich, zumindest in Grenzen, bestimmte Input-Typen so aussehen
lassen kann wie andere Input-Typen, indem man einfach die Appearance dann wechselt.
Und ich sag jetzt mal, ich weiß nicht, ob das in der Tat wirklich geht,
aber bei einem Input könntest du einfach sagen, Appearance Text Area vielleicht.
Und dann wäre es zwar im HTML immer noch ein Input-Type Text,
aber rein visuell sähe es vielleicht aus wie eine Text Area.
Jo. Ja, ist ein berechtigter Einwand.
Wo diese Toggles ja herkommen, würde ich sagen, ist so aus dem Mobilbereich
und tatsächlich auch vom iPhone,
weil ich das Gefühl habe, dass die mit diesen Toggles als erstes irgendwie kamen
und eigentlich auch alle Interface-Elemente, zumindest in den nativen UIs,
die wir mit Checkboxen umsetzen würden,
bei sich mit Toggles abbilden.
No. Aber ich meine, Toggle ist ... Apple-Toggle, der einzige,
den man, glaube ich, so dann verstehen kann zumindest schon mal.
Weil ich weiß nicht, wie es euch geht.
Ich habe schon sehr oft Probleme im Web gehabt, mit Toggles zu verstehen,
ist dieser Toggle jetzt an oder aus?
Was bei einer Checkbox halt leider sehr einfach war.
Aber was ich jetzt auch mitbekommen habe, ist, dass bei Vision Pro,
bei dem Operating System von der Vision Pro, gibt es auch keine Checkboxes mehr.
Es gibt, glaube ich, nur noch Radio-Buttons. Also Checkboxen schauen dort aus wie Radio-Buttons.
Nur so am Rande. Also ich glaube, Apple macht da jetzt mal ein modernes Umstrukturierung.
Das ist aber auch sehr gewagt. Sehr gewagt ist, weil das ja tatsächlich zwei
unterschiedliche Bedienparadigmen sind.
Aber wir machen ja eh alle Toggles, deswegen ist auch schon wieder egal.
Ich habe letztens einen Artikel gelesen, den finde ich natürlich gerade nicht
wieder, aber wo irgendwer darüber geweint hat, dass entweder Radio-Buttons oder
Checkboxes, eins von beiden, aber tatsächlich so ein bisschen auf dem aussterbenden Ast sind.
Aus genau diesem Grund, dass das einfach so, dass dieses Bedienen-Konzept Radio-Buttons,
also, wann sieht man die schon mal?
Das ist halt wirklich ausgesprochen selten geworden. Ja, wenn da ein Select fällt, so ein Dings.
Ja, aber Select ist natürlich auch schwierig. Also speziell,
wenn es halt wirklich so ein Nimm das linke oder das rechte ...
Ist, also sagen wir mal so, man kann ja sich dazu entscheiden,
keine Radio-Buttons mehr zu haben, aber dann sollte man tatsächlich auch keine
Bedienelemente mehr haben, die wie Radio-Buttons funktionieren,
und halt eben Radio-Buttons haben, die dann einfach aussehen wie Toggle,
obwohl sie Radio-Buttons sind, wenn ihr versteht, was ich meine.
Also das sind dann unterschiedliche Bedienkonzepte, so eine Checkbox und ein
Radio-Button und ich meine, grundsätzlich ist den meisten schon noch gewahr,
dass es diese beiden unterschiedlichen Dinger gibt und wenn sie entsprechend
aussehen, Wissen die meisten Leute auch, wie es zu benutzen ist.
Aber es gibt halt wirklich diese Tendenz, entweder alles zu vertockeln,
auch die Dinger, die halt besser ein Radio-Button wären vielleicht.
Und wenn man Radio-Buttons hat, stylt man sie so, als wären sie Checkboxes,
damit wirklich keiner mehr weiß, wo oben und unten ist.
Das ist so ein Trend, den ich wahrnehme. Jetzt noch mal zurück zum Thema,
was ist gerade unser Problem damit, dass es ein Keyword gibt, das Twitch heißt?
Weil generell ist es ja schon hilfreich, dass ich irgendwas machen kann,
damit es nativ ausschaut wie ein Tockel, damit ich nicht wieder mit CSS irgendwas
stylen muss, was dann zum Beispiel reingezoomt oder rausgezoomt teilweise ganz
furchtbar wird mit Custom-Styles.
Aber ihr meintet, dass es vielleicht bessere Möglichkeiten gegeben hätte,
als einfach das HTML-Keyword-Switch anzuhängen?
Also ich trolle bloß, indem ich darauf hinweise, dass das ein Präsentationsattribut
ist und dass das einen Schritt entfernt ist von Font-Tags mit einer Size 7.
Das heißt nicht, dass es schlecht ist, aber ich bin der Meinung, das ist es.
Aber gibt es besser Alternativen für sowas? Weiß nicht. Also Shep's Idee mit
Appearance finde ich irgendwie ganz nett, aber Appearance ist halt ein sehr
grober Hammer, ist so mein Eindruck.
Also womit man halt wirklich sagen kann, was dein Beispiel ja war,
Du-Tags-Area sieht jetzt aus wie ein Button.
Was halt riskant ist, zumal es halt eben ja keine etablierte Kategorie-Toggle
gibt, die wird ja hierüber erst eingeführt.
Aber das kann man ja machen, also grundsätzlich, Also wenn man ein Switch-Attribut
ersinnen kann, dann kann man das ja in CSS genauso machen.
Also die einzige Erklärung, die ich vielleicht dafür hätte, warum man sich dafür entschieden hat,
ist vielleicht, weil dieses Element
in sich noch allerlei so quasi Shadow-DOM-Strukturen mit sich führt,
die der Browser eben nicht bauen würde,
wenn man das irgendwie nur per CSS triggern würde.
Also ist jetzt nur mal so eine Verschwörungstheorie. Und dass du dann eben bei
diesem Toggle-Switch vielleicht auf den runden Toggle-Nupsi zugreifen kannst
und den umfärben kannst.
Und das, was da drunter liegt, die farbige Fläche vielleicht und solche Dinge.
Ja, das stelle ich mir leichter vor, wenn man das in HTML, so komplett in HTML
alles hält, um das so realisieren zu können, als wenn man das irgendwie aufteilt.
Ja, ich meine, die spannende Frage ist natürlich, will das am Ende überhaupt
jemand verwenden und sich damit abfinden, dass, weil es ja ein natives Form-Control
ist, das in jedem Browser anders aussehen wird?
Oder passiert damit das gleiche wie mit den Checkboxes, nämlich man nimmt das
als sozusagen Backend für irgendeine Div-Konstruktion?
Na, ich glaube, es gibt halt die und die. Also es gibt diejenigen,
denen das erst mal genug ist.
Also man kann ja auch mit X in Color dann eben schon so ein bisschen was machen.
Da haben wir ja auch schon mal drüber gesprochen.
Also du hast, glaube ich, auch mal gesagt, dass es für dich erst mal so im ersten
Step meistens ausreicht, was man da so mit X and Color machen kann.
Genau, und dann gibt es eben die Leute, die ein Produkt bauen,
weil sie nicht das sehr ausgefeilt ist, wo dann auch wirklich alles gestaltet werden muss.
Denen wird es nicht reichen. Ich weiß auch nicht, ob das irgendwie ARIA-mäßig
irgendwas anderes noch kommuniziert. Vermutlich schon.
Es wird wahrscheinlich auch vielleicht ein Roll-Switch haben oder sowas in der Art.
Also aus meiner Erfahrung heraus ist aber tatsächlich auch eine Checkbox immer
noch leichter umzustylen, als so ein Tockel komplett zu stylen ist.
Da gibt es schon wirklich einige Dinge zu beachten, damit die Klickfläche groß
genug ist, damit die Transition schön hübsch genug ist, damit diese runden Borders
auch in dieser Border von der anderen Border drin sind.
Dann überhaupt die Entscheidung, was ist eigentlich, wie schaut Disabled aus,
wie ist es links, wie ist es rechts.
Und diese Entscheidung hast du bei einer Checkbox nicht zu treffen?
Da weiß ich schon mal, wenn da eine Checkmark ist, dann ist schon mal an.
Beim Toggle weiß ich zumindest schon mal nicht, ist links ran oder ist es rechts
an, wenn ich das selber entscheiden muss.
Ja, okay, das stimmt.
Aber du hast einen validen Punkt. Ist es denn dann gut genug oder fangen die
Leute wieder an, dann ihr eigenes CSS da dran zu klatschen?
Also meine Erfahrung mit diesen Inputs ist halt immer so, dass der größte Kritikpunkt
ist, das sieht ja aus wie irgendwas.
Also Input Type Date sieht auf dem Chrome anders aus als auf dem Firefox,
als im Safari, als auf dem iPhone.
Und das ist halt nur innerhalb eines gewissen Wirkungsbereichs gut,
nämlich man hätte gern irgendwie ein mobile optimiertes User Interface,
aber im Desktop geht dann immer das große Geweine los, weil da kriegen wir die
Farbe nicht rein und das sieht hier und da anders aus und bei uns soll die Woche
aber an dem Tag anfangen und nicht an dem.
Oder halt irgendwie auch so durchaus valide Einwände, wie wir wollen halt zwei
Monate auf einmal anzeigen und nicht ein, weil Flugbuchung oder so.
Und das führt dann halt immer dazu, dass für alle nicht trivialen Fälle das
Ding reimplementiert wird, was ja auch, wenn die nicht trivialen Fälle halt
nun mal vorliegen, wie halt, ich muss zwei Monate anzeigen, dann ist das halt so.
Aber da scheint ja dann die Tendenz hinzugehen. Und vor allen Dingen formt das
natürlich auch, wenn das sozusagen für die ganzen ernsthaften Leute mit den
ernsthaften Produkten, die Shep vorhin angesprochen hat, ist,
die formen halt eben auch das Narrativ, weil diejenigen,
sind, die die Blogs vollschreiben und dann denkt sich jeder,
ah, okay, Input Type Date kannst du eh nicht gebrauchen, nimmst du JavaScript
Library mit sieben Megabyte Dependencies und dann wird das zum de facto Standard.
Hat, wenn halt die native Implementierung nicht weit genug springt.
Ich weiß aber auch nicht, wie man das reparieren oder verhindern sollte,
weil ich glaube, so ist das halt einfach, dass es halt unglaublich schwierig
ist, da One-Size-Fits-All zu finden, was so Inputs angeht.
Ich meine, Chef, wir haben ja schon öfter mal über die Idee einer sortierbaren Tabelle.
Gesprochen, wo ich ja seit Jahr und Tag der Meinung bin, dass wir es niemals
als Standard geben, weil das einfach sich einfach sagt, lass mal sortierbare
Tabelle machen, aber dann im Detail Weil so unterschiedlich sein muss pro Anwendung,
dass sich da eine Standardlösung, die dann auch verwendet wird, nicht finden lässt.
Und ich glaube, das ist halt bei vielen Form-Controls ganz genauso.
Ja, man müsste mal, also das haben wir jetzt natürlich versäumt zu tun,
nachlesen, wie es jetzt eigentlich dazu kam.
Also da wird es wahrscheinlich irgendwo eine Diskussion in irgendeinem GitHub-Issue
gegeben haben von Leuten, die auch so ein bisschen was auf dem Kasten haben, denke ich.
Ähm, was dann eben resultiert ist in diesem neuen Attribut.
Ich weiß auch nicht, was andere Browser-Hersteller davon halten oder Engine-Programmierer
und ob das jetzt auch in den Webstandard hineingeflossen ist.
Also ich weiß, dass halt ... Ich finde auch die grundsätzliche Idee,
wenn du jetzt Webseiten baust, die nicht nur Mobile-First,
sondern auch einfach Mobile-Only gedacht sind, dann finde ich,
und gerade wenn du davon ausgehst,
dass viele deiner User auf einem Apple-Device da draufgehen,
dann finde ich das eigentlich schon ziemlich easy für mich denn als Web-Dev,
dass ich wirklich sagen kann, ich habe da so ein Grid oder Flex oder was auch
immer eine Table, wo ich links mein,
Label habe und rechts diesen Toggle und das schaut halt einfach aus wie bei,
wie man es von iOS gewohnt ist und ich muss da nicht viel rumstylen,
dann würde ich eigentlich auch schon gerne dieses native Ding verwenden.
Meine Checkbooks auf nativ ist schon schon ein bisschen oldschool.
Auf der anderen Seite, ich finde Toggle ist tatsächlich auf dem Desktop immer
so ein bisschen merkwürdiger, wo ich mir denke, kann man nicht einfach Checkboxen verwenden.
Hm. Ich glaube, es gibt da, vielleicht könnt ihr mich dann noch mal dran erinnern,
weil ich denke, dass Checkboxen nicht nur zwei, sondern sogar drei States haben.
Also zwei States werden unchecked und checked.
Aber ich, da gibt es noch ein Wort, das kann ich kaum aussprechen.
Ich glaube, es heißt indeterminate.
Indeterminate. Dankeschön. Und ich habe davon mal gehört. Was ist das?
Was macht das? Wozu brauche ich das?
Was das ist, ist, wenn sie weder angehakt noch nicht angehakt ist,
wenn die Entscheidung nicht getroffen ist.
Genau. Ja, das klingt sinnvoll. Ich glaube, es gibt auch diesen Fall,
dass du quasi so File-Trees hast, wo du dann, oder sagen wir mal,
du diese, wenn du so Programme installierst und du hast so ein Tree und dann fragt er dich so.
Welche Programmbestandteile möchtest du installieren und dann hakst du so bestimmte
Unterpunkte an, aber andere nicht und dann ist quasi der Oberpunkt für diese
Unterpunkte der wäre auch an- oder abhackbar.
Und der, also wenn du jetzt zum Beispiel sagen willst, komm,
ich will alles haben, was in diesem Zweig drin ist, dann hackst du einfach das Eltern-Element an.
Und dann werden automatisch die Haken bei allen Kind-Elementen gesetzt.
Und da gibt es doch diese Checkbox, die eben so einen Zwischenzustand hat.
Weil eben nicht alle Kind-Elemente selektiert sind, sondern nur ein paar und
ein paar andere eben nicht.
Ich glaube, das ist so dieser indeterminate state, oder?
Das ist genau das Beispiel, das MDN auch auflistet, vorangehend dem Satz,
es gibt nicht besonders viele Use Cases für dieses Feedback.
Aber mache ich das als User? Kann ich als User zu diesem Stand kommen?
Oder setze ich als Developer den Standhoos dann per JavaScript in bestimmten Fällen? Letzteres.
Das ist nur so eine DOM-Property, die kannst du setzen. Die gibt es auch nicht
als HTML-Attribut. Das ist ein sehr seltsames Style.
Der sehr seltsame Style, den sollte es jetzt aber zumindest bei Toggles oder
Switches dann nicht geben. Da hast du, glaube ich, nicht mal unchecked und checked,
sondern dann hast du on oder off.
Und kein Zwischending. Okay, es sei denn, ich setze das. Es ist ja bloß eine
DOM-Property. Ich kann ja machen, was ich will. Ich bin ja schon groß. Was passiert denn dann?
Aber ich glaube, dass es das nicht gibt bei Switches. Also du hast gerade gesagt, bei den Switches,
also bei den Checkboxen ist es ja, glaube ich, so, dass wenn die nicht gecheckt
ist und man das Formular übermittelt, dann wird auch nichts übermittelt.
Das wäre natürlich cool. Ich überlege gerade.
Ich fände es cool, wenn das beim Switch dann anders wäre.
Wenn er auch den Off-State übermitteln würde, glaube ich. Ich glaube, das fände ich gut.
Macht wahrscheinlich keinen Unterschied. Was ich eigentlich mag,
ist, dass man etwas mit Absicht verschickt, wenn die User-Eingabe davor unterschiedlich war.
Also das heißt, ich registriere mich irgendwo und ich setze gar keinen Wert
für irgendeinen Boolean-Value.
Andersherum, ich setze einen True Value für einen Boolean Value und wenn ich
dann mich entscheide zu jetzt schalte ich es aus, dann möchte ich explizit False schicken.
Und wenn ich nie damit interagiere, dann schicke ich nie was mit.
Ja, also ich habe auch diesen Fall, also ich habe so eine facettierte Suche,
wo du quasi Kategorien anhaken kannst von Dingen, die du irgendwie angezeigt haben möchtest.
Und ich hätte halt gerne ein Interface-Element, wo ich in der Lage bin,
eine Kategorie auch bewusst abzuwählen.
Also wo ich sagen kann, zeigt mir alles, aber echt von dieser Kategorie bitte
nicht, das nervt einfach nur.
Also quasi, dass man Dinge umkehren könnte. Das haben die halt jetzt leider auch nicht umgesetzt.
Das hätte mir gut gefallen. So ein Thumbs-Down.
Ja, genau, so ein Thumbs-Down-Ding. Eine Spezifikation scheint es ja hier gar nicht zu geben.
Also in dieser Ankündigung rechtfertigen sie das sehr viel. Und warum das jetzt
unbedingt sein müsste, aber irgendwie was verlinkt haben sie nicht,
was wie eine Spezifikation aussieht, oder?
Weil ich wollte gerade rausfinden, was ist denn dann, wenn ich hier Indeterminate
auf True stelle oder sonstigen Käse machen.
Aber irgendwie scheint das jetzt wirklich nur so ein Ding zu sein,
was sie mal eingebaut haben. Und jetzt gucken wir mal, was passiert.
Ja, ich kenne einen Herrn Peter K., der das bald herausfinden wird,
was passiert, wenn man diesen Indeterminate State setzt auf diesen Dingern.
Nun, dann kenne ich einen Herrn Schepp, der mir ein kostenloses MacBook zur
Verfügung stellt mit aktuellstem macOS drauf, damit ich den Safari ...
Oh, ich habe sogar ein Leihgerät für dich.
Schick, aber ...
Eine Sache, die mir noch eingefallen ist, ist ... Jetzt wechselt er das Thema.
Peter, du bist auch hier, wir treffen uns in Mainz, dann gebe ich dir das. Machen wir.
Eine Sache, die mir noch eingefallen ist, ist, dass natürlich durch so ein in
HTML eingebackenes Attribut es auch schwerer wird,
den Look zu wechseln, wenn ein und dieselbe Seite auf Desktop und auf Mobile läuft.
Also vielleicht will man ja auf Mobile, weil da eben alles Toggle-Switches sind,
weil das halt so gelernt ist, Toggle-Switches haben, aber vielleicht auf Desktop dann nicht.
Und da muss man dann ja auch wieder, also entweder einen Switch wieder umhecken
zu einer Checkbox oder die Checkbox eben,
wie man es bisher auch getan hat auf Mobile, zu einem Switch-Toggle wieder umfriemeln per CSS.
Ja, also ich denke, de facto wird es nicht umhinkommen, dass man da,
weil da alle so ihre speziellen kleinen Anforderungen haben,
wie es aussehen soll, wie es sich verhalten soll, da ohnehin dieser gleiche
Hack gemacht wird, der vorher auch da war.
Also ich bin jetzt nicht ganz so militant gegen diese Switch-Control,
wie das jetzt vielleicht klang.
Ich denke halt nur, es ist ausgesprochen lustig, dass wir das Jahr 2024 haben
und da immer noch im Prinzip Präsentations-HTML-Attribute eingeführt werden.
Ja, also so ein bisschen, finde ich, sind diese neuen HTML-Attribute.
Wir hatten es ja auch irgendwann letztens mit diesen exklusiven Akkordeons,
also mit den Detail-Elementen, in denen man ein Name-Attribut geben kann.
Und wenn man halt mehrere Detail-Elemente mit dem gleichen Name hat,
dann sorgt das eben dafür, dass immer nur eins von denen aufklappen kann.
Und wenn andere vorher aufgeklappt waren, dann klappen die wieder zu. zu.
Das klingt ja auch eigentlich erstmal cool, aber so je länger man drauf rumdenkt,
so wie jetzt bei dem Switch-Attribut, desto mehr Ungereimtheiten entdeckt man und.
Und das ging auch wahnsinnig schnell. Also dieses, hey, ich hab die Idee,
wir machen exklusive Akkordeons.
Was haltet ihr davon, wenn wir das Details-Element einfach nehmen und ein Name-Attribut drauf machen?
Zwei Wochen später war dann der erste Browser raus, der das schon implementiert
hatte, so ungefähr. Vielleicht auch einen Monat später.
Aber sehr viel länger hat's auch nicht gedauert.
Und das wundert mich dann manchmal schon.
Also es ist ja schon cool, dass HTML sich auch wieder weiterentwickelt.
Weil es ist ja auch irgendwie lange stehen geblieben.
Aber vielleicht ist das jetzt auch wiederum zu überstürzt. Es ist halt vor allen
Dingen ein Indikator, wenn sie es in einen Browser implementiert bekommen in
der kurzen Zeit, dann würden es wahrscheinlich die meisten Entwicklerinnen und
Entwickler auch mit JavaScript hinkriegen.
Wenn du das halt eben vergleichst mit so was wie dem ganzen Dialog-Gedöns,
mit halt irgendwie diesem obersten Layer und der Background-Pseudoklasse und
hast du nicht gesehen, das mal eben nachzuimplementieren, Denn JavaScript ist
halt kein Kindergeburtstag.
Und da macht es, glaube ich, schon Sinn, ein natives Feature zu haben.
Und da hat es ja auch ewig gedauert, bis die Browser das alle irgendwie im Griff hatten.
Also ich denke halt immer so, wenn es ohne weiteres wirklich schnell einzubauen
ist, dann muss es halt entweder wirklich was sein, was wirklich den absoluten
Trampelfad massiv asphaltiert, weil das halt wirklich alle auf eine gleiche
Weise schon so machen, sehe ich hier nicht so richtig.
Und es muss halt eben dann am Ende auch irgendwie eine Chance darauf haben,
dass es angewendet wird und nicht durch CSS wieder ersetzt wird.
Das sehe ich hier auch nicht so richtig.
Und beim Akkordeon gleiche Geschichte.
Ja, und es muss vielleicht auch einen Mehrwert bieten. Also zum Beispiel bei
den Dialog-Elementen wird ja dann automatisch alles inert geschaltet,
wenn das im Model-Modus geöffnet wird.
Also dass quasi alles dahinter tatsächlich nicht klickbar und nicht mehr untappbar ist und so Sachen.
Das ist ja ein Riesenaufwand, das selber zu tun. Oder was jetzt Chrome implementiert
hat, ist ja dieser Close-Watcher.
Das heißt also, dass du auch so Shortcuts ausführen kannst kannst auf deinem
Smartphone die in nativen Anwendungen eben auch signalisieren sollen,
dass du gerne einen Overlay schließen möchtest.
Und das kannst du eben jetzt auch, also das Dialog-Element horch da direkt drauf.
Also du kriegst halt schon einen Mehrwert geboten.
Ich weiß nicht, wo der Mehrwert jetzt zum Beispiel bei den exklusiven Akkordeons liegt.
Können die Dinge verhindern, die wir als Programmiererinnen vielleicht irgendwie
immer verkacken, sowas wie was ist, wenn man ein Akkordeon aufklappt,
ein Link klickt, auf eine Seite kommt, zurückkommt, landet man wieder im aufgeklappten
Akkordeon, kann ein Browser das?
Sowas vergessen wir ja eigentlich immer.
So, das fände ich dann okay oder wenn man Akkordeons hat, die exklusiv sind
und man klappt eins weiter unten auf,
dann muss sich ja das, was oben ist, wieder schließen und wenn das einen sehr
langen Text hat, dann scrollt ja quasi quasi die Seite nach oben hin raus,
weil ja da oben sich so ein Riesending schließt.
Schafft der Browser das, quasi so ein Scroll-Anchoring zu betreiben,
dass ich quasi nicht das aus der Sicht verliere, was ich eigentlich gerade angucken wollte.
Ich hätte noch was ganz anderes. Das Name-Attribut ist meines Erachtens eine
ziemliche Katastrophe, weil dem musst du ja irgendeinen String geben und darüber
koordinieren sich die Dinger.
Was machst du jetzt, wenn du Shadowdom hast?
Weil das ist dann ja sein eigener kleiner Scope. So ähnlich wie das zum Beispiel
mit irgendwelchen Labels ist und du hast in einem Shadow-Root dann irgendwo
einen Input drin und du willst das labeln.
Du willst nicht das Shadow-Root-containende Element labeln, sondern du willst
das Ding im Shadow-DOM labeln.
Und das geht halt eben nicht, weil diese String-Referenzen nicht durch diese
Abstraktionsmembran durchgehen.
Ist das bei Name genauso oder nicht? Wenn es so ist, ist das doof.
Wenn es nicht so ist, ist es anders als bei allem anderen.
Wenn du eine JavaScript-API da dran basteln musst, dann hättest du es doch einfach
dir gleich ersparen können und einfach sagen können, wir überlassen das den
Entwicklerinnen und Entwicklern, das zu lösen.
Die können ja selber sehen, ob sie dieses Problem haben und das lösen müssen
oder ob sie einfach sagen, hier, QuerySelectorAll, hast du nicht gesehen,
ich mache halt einfach ein bisschen JavaScript da oben drauf.
Also, ich bin da ganz bei dir, da ist ein riesen Rattenschwanz an Problemen drin.
Alle, die du genannt hast, sind total die Validen. Mir wäre halt zuerst das
Shadowdom-Beispiel eingefallen mit diesen ganzen String-Referenzen.
Da gibt es halt keine gute Lösung für Und was die ja im Prinzip jetzt machen,
ist ja, wir haben ja Shadow DOM, das Problem ist bekannt, das existiert und
jetzt schaufelt man einfach noch mehr Features auf diesen Problemhaufen drauf,
statt zu sagen, okay, müssen wir das irgendwie alles fundamental neu denken,
müssen wir vielleicht vorher eine Spezifikation schreiben, die irgendwie es
erlaubt, Referenzen durch Shadow DOM Grenzen durchzupassen.
Und wenn wir weder das eine noch das andere haben, sollte man vielleicht erstmal
jetzt nichts machen. Und lieber so Sachen wie ein Dialog machen,
wo es das Problem, glaube ich, in der Form nicht gibt.
Ja, mal sehen. Wir beobachten das einfach, was da jetzt passiert.
Auch, ob das Switch angenommen wird oder nicht.
Genau, und dann reflektieren wir da einfach in einem Jahr noch mal drauf.
Genau, und wenden uns jetzt einem Thema zu, das überhaupt nichts damit zu tun
hat, irgendwelche Form-Controls mithilfe von HTML umzugestalten. Richtig?
Ja, fast. Wir haben noch ein neues HTML vergessen, das auch Form-Controls umgestaltet.
Oh nein. Darauf geht es wahrscheinlich hinaus, oder? Ich? Nein.
Es gibt Safari und, glaube ich, auch Chrome unterstützen, dass man in Selects
Optionen voneinander abgrenzen kann mit einem HR-Element.
Ganz neu.
Moment, warte mal. Aber es verwendet ja niemand native Select-Felder.
Ja, ich glaube jetzt nicht niemand, niemand. Also ich mache das ja schon,
ich mache das ja so, dass ich quasi das Select,
das jetzt nicht die Optionslist enthält, dass ich das eigentlich schon immer
umgestalte, aber im Grunde unten drunter das Select noch da ist.
Und wenn man dann da draufklickt, dann geht auch das native Select mit seiner,
also zumindest die Optionslist davon auf.
Und da könnte ich von HR profitieren, theoretisch.
Gibt es denn nur einen HR oder gibt es dazu auch noch so einen Grouping-Category-Titel?
Dafür gibt es ja Opt-Group. Genau, das gibt es, das hat aber glaube ich kein, hat das einen Titel?
Nee, das kann nur wiederum gruppieren, aber hat kein,
kein Legend wie ein Fieldset hätte, oder? So meine ich, wäre das.
Ich habe vor ungefähr 100 Jahren das zuletzt benutzt, muss ich aber gestehen.
Also dann stelle ich die Frage mal um, warum möchte ich das denn verwenden,
eine HR in einem Select-Feld?
Tja, das ist eine sehr gute Frage. Naja, ich meine, du willst das vielleicht
irgendwie so gruppieren, also keine Ahnung, welchen Lieferdienst willst du haben
und dann ist er nach Länderküchen gegliedert und die Länderküchen sind voneinander
abgesetzt nach Kontinent.
Ist jetzt im Select nicht die dämlichste aller Ideen? Ich meine,
wenn du auf dem Mac oben jetzt eines der Menüs öffnest, dann hast du diese horizontalen
Trennlinien da ja auch drin.
Ich denke mal, das wird wahrscheinlich auch wieder der Antrieb gewesen sein,
so was in HTML einzubauen.
Ich weiß aber auch nicht, warum man das mit einem HTML-Element machen muss.
Da kommen wir eigentlich wieder zu diesem Punkt, Vielen Dank.
Warum, also, mach doch einfach die Options stylbar. Das wär cooler gewesen.
Und dann könnte man ja das Endchild-Option zum Beispiel mit einem Border versehen.
Boah, aber wenn du das machst, machst du, glaub ich, echt so eine Familienpackung Würmer auf.
Weil du kannst ja nicht die Leute die Options einfach so irgendwie stylen lassen,
sonst gehen die ja da drin hin und machen irgendwie so Zeug wie 3D-Transformation in deinem Select.
Und dein Select ist ja irgendwie ein nativ gerendertes Widget,
das heißt, dann musst du dafür sorgen, dass plötzlich die ID-Transformationen
supportet werden, irgendwie da bei deinem fancy macOS, früher auf deiner Windows-Möhre
oder halt irgendwie bei dem cork-sanktalen Linux vom Nerd nebenan.
Ja, aber du kannst ja zum Beispiel auch scrollbar stylen, zumindest in Grenzen.
Das ist das Ding. Dann musst du Grenzen definieren und dann ist es am schlimmsten,
weil dann hast du die Leute ja quasi angefüttert und dann gleich der große weiße
Hai fangen sie dann an und tauchen bei dir im Bug-Tracker auf und sagen,
warum kann ich nicht das auch noch machen?
Hast du nicht mal irgendwie geschaut, was im DOM-Tree oder Accessibility-Tree,
ich weiß nicht mehr genau, was aus diesen HRs dann wird letztendlich?
Nee, das hatte ich tatsächlich nicht getan. Nee, dachte du wärst das gewesen.
Aber ich habe eine Liste von so Sachen offen, die mir genau diese Informationen geben.
Du hast ja gerade gesagt, Browser supporten das, richtig?
Also ich hatte den Eindruck, dass das auch in Chrome eingerüstet worden wäre.
Ich wollte nur nach deiner Definition von Support fragen, das ist alles.
Also, weil ich habe die Kompatibilitätstabelle hier. Das ist bei allen als Partial Support markiert.
Bei den Chrome-Derivaten ist das so, dass das nicht im Accessibility-Tree repräsentiert ist.
Und wenn man mit Pfeiltasten durch das Select geht, dann tauchen diese Dinger
nicht auf, sondern man springt direkt zwischen den Options hin und her.
Was? Also dann hast du keine Trennerbalken da drin, oder was?
Genau, du wirst sie nicht sehen, wenn du das mit den Pfeiltasten machst. Okay.
Was ja gut ist, weil du willst ja niemals eine HR auswählen.
Was aber schlecht ist, weil du willst ja sehen, dass da eine HR ist.
Also ich hätte jetzt gedacht, dass man dann einfach, man springt immer noch von Option zu Option.
Und wenn dann HR zwischenliegt, dann wird die eben übersprungen,
weil man würde sie ja sowieso nicht anspringen können mit der Tastatur,
auch in anderen Kontexten. Du würdest sie aber wahrnehmen können.
Ich meine, wenn du es einfach anklicken würdest, geht dein ganzes Select auf.
Dann siehst du, erste Option, zweite Option, eine HR, dritte Option, vierte Option.
Genau, du würdest sie sehen, das meinst du.
Genau, du würdest sie wahrnehmen. Aber wenn du nur mit den Pfeiltasten dieses
Ding navigierst, wirst du nicht wahrnehmen, dass da eine HR ist.
Ist das jetzt irgendwie ein Lapsus oder ist das bei Intent? Keine Ahnung.
Ich würde mal annehmen, dass das nicht spezifiziert ist, weil traditionell ja
die HTML-Spezifikationen über Inputs nur sagen, sagen, das Input vom Typ so
und so ist ein Input vom Typ so und so.
Und die definierenden DOM-API aber sagen nichts über das Verhalten,
weil du ja nicht willst, dass der Datepicker auf deinem Desktop-Chrome genauso
funktioniert wie der Datepicker auf deinem winzigen iPhone. Richtig?
Und deswegen ist das wahrscheinlich nicht festgelegt. Ich scroll grad mal durch
die Spezifikationen, da steht exakt nichts zu da.
Aber es ist zumindest drin, richtig? Partial Support, ja.
Nee, aber, achso, ich dachte, du guckst grad in die HTML- Spezifikationen.
Achso, du guckst da rein und da sind ja immer diese Marker und richtig,
die dir da anzeigen, welche Engine was unterstützt.
Aber zumindest kann man sagen, anders als bei dem Switch-Attribut,
HR-Elemente in Selects sind zumindest im Webstandard.
Ja, sie werden jetzt nicht vom HTML-Paser rausgeschmissen, aber zum Beispiel,
wie gesagt, in Chrome ist es nicht im Accessibility-Tree und per File-Navigation
ist es nicht erfahrbar. Im Firefox offenbar schon.
Das heißt, du kannst da was auswählen, was keine Option ist, was auch Banane ist.
Und HR taucht auch nicht im Accessibility-Tree auf und das waren ja im Prinzip
alle Browser, die es gibt, bis auf Safari.
Was machst du? Auch nicht im Accessibility-Tree. Tja, schwierig.
Also ich hätte ja gesagt, dass es, also wenn schon, denn schon,
dann sollte es auch im Accessibility-Tree auftauchen, oder?
Also weil eine Horizontal-Ruler- Komponente ist ja, hat ja schon einen informativen
Charakter. Es ist ein semantischer Cut, ja.
Vor allem, wenn es nicht mit CSS und irgendeiner Border gemacht wird.
Also eigentlich auch wieder ein Griff ins Klo, oder? Weiß ich nicht.
Ich glaube, das ist mehr so nicht entscheidbar. Also da gibt es keinen offensichtlich richtigen Weg.
Weißt du, ich will einen Button haben, da gibt es einen offensichtlich richtigen Weg.
Ist ein Ding, dass du anticken kannst, wo was drinsteht, was du auch mit dem
Keyboard fokussieren kannst, kannst Enter drücken, schickt Formular ab.
Das lässt sich, glaube ich, irgendwie so in endlich viel Worten beschreiben
und auch spezifizieren und umsetzen.
Aber, weißt du, eine Trennung in diesen ganzen Options drin,
die aber irgendwie selber nicht so eine Entität sein soll, die wahrnehmbar sein
soll, aber nicht rein visuell sein soll, ist halt schwierig.
Also so rein semantisch würde ich sagen, ist das HR-Element,
glaube ich, gar keine so schlechte Wahl. Es gäbe Schlimmeres als das.
Ich meine, OptGroup ist ja so der nächste Verwandte, im Select jetzt semantisch
gesehen, und das ist ja auch ein HTML-Tag.
Aber warum würde man denn.
Verhindern wollen, dass jemand mit assistiven Technologien den die HR wahrnimmt,
die jemand, der zum Beispiel sehend ist, wahrnimmt.
Ich gehe davon aus, dass das nicht gewollt ist. Ich gehe davon aus,
dass das ein Versehen, also noch nicht implementiert ist, weil schnell,
schnell die ganzen Blinden, lassen wir mal hinten runterfallen, wie das so üblich ist.
Also davon gehe ich aus, aber wirklich so die Sache mit, ist das Ding jetzt
selektierbar oder nicht? Ist es eine anwählbare Entität im Select oder nicht?
Ist halt irgendwie unklar. Also irgendwie nicht, würde ich jetzt sagen,
aber ich würde auch sagen, weil du kannst ja auch HRs in HTML kannst du ja auch,
wahrnehmen über assistive Technologien,
ohne dass du sie antaben musst.
Also ich nehme an, dass die wahrscheinlich genauso in den Listen,
also es ist jetzt ich nehme an, es ist vielleicht auch nicht richtig,
aber so wie du dir irgendwie die Überschriftenstrukturen ausgeben lassen kannst,
die Links auf einer Seite und so.
Könnte ich mir vorstellen, dass HR-Elemente auch eine Rolle spielen bei assistiven Technologien.
Übrigens, ich habe jetzt mal das naheliegende gemacht. Ich habe mir das Opt-Group-Element
angeschaut. Auch per Tastatur nicht anwählbar.
Also das wäre sozusagen prior art, auf die man sich berufen könnte.
Und die Dinger haben natürlich Labels.
Gibt ein Label-Attribut auf dem Opt-Group-Element und dann taucht das halt eben
tatsächlich als belabeltes das Ding da drin auf.
Macht ja auch irgendwie Sinn. Man muss ja sehen, in welcher Kategorie man drin
ist. Wo ich mich jetzt halt eben frage.
Wofür brauchen wir diese HR, wenn wir Opt-Group haben? Man könnte ja auch eine
Opt-Group ohne Label zulassen, dann hätte man ja im Grunde sowas.
Ja, oder wenn man schon Präsentationsattribute macht, so wie beim Switch-Element,
wäre das doch vielleicht der bessere Move.
Also Opt-Group und dann irgendwie ein Attribut, keine Ahnung,
Type, hat dann halt ein Default, der dann halt sein Textlabel ist und einen
anderen Type, der dann halt irgendwie Separator hast du nicht gesehen ist.
Ja, I don't know. Auch da wäre wahrscheinlich wieder interessant,
mal sich sozusagen das rückwärts zu lesen, wie es dazu kam.
Was mir wirklich in den Spezifikationen fehlt, ist so ein bisschen genau das.
Also wirklich so eine High-Level-Change-History.
Du hast den ganzen Kram natürlich bei GitHub, aber da sind halt eben auch so
Rechtschreibfehler-Korrekturen drin. Und das Dokument ist so komplex,
dass das nicht nachzuvollziehen ist, finde ich jedenfalls.
Also da wären wirklich so Release-Notes wie jetzt hier der Safari.
Das macht eigentlich ganz cool.
Anscheinend gab es das Feature ja 2006 schon mal.
Das ist dann nur wohl hops gegangen bei HTML-Parser-Strukturierungen und wurde
2018 als neuer Request wieder entdeckt.
Das ist allerdings leider auch die einzige Info, die ich aus ihrem WebKit-Blog-Artikel rausbekomme.
Ansonsten steht hier eigentlich einfach nur, dass es wichtig ist,
sich darüber bewusst zu sein, dass dieses Feature visuelle Separatoren darstellt
und nicht für assistive Technologien gedacht sind.
Aber dann einfach Punkt, nicht so weil, also ohne Begründung.
Die Geschichte, die sie da verlinken, ist tatsächlich eine sehr schöne und genau
die, die ich sonst gerade referiert hätte. Ja, ja. SGML, das waren noch Zeiten.
Genau, wir verlinken ja auch auf dieses Post und darin findet ihr dann auch
den Link zu dieser Geschichte.
Ja, es ist halt eben alles nicht so trivial mit diesem ganzen Frontend-Krempel.
Dann würde ich sagen, verlassen wir doch die die den HTML-Bereich, oder?
Und widmen uns mal wieder was anderem. Nämlich CSS vielleicht, oder?
Ja, dem ewigen Ziel.
Der heilige Gral von CSS.
Der da wäre? Sachenvertikal zentrieren. Ah, okay.
Also als Neuerung gibt es jetzt das, was man in Flexbox und in Grid machen kann,
nämlich, dass Kind-Elemente vertikal oder horizontal platziert werden können.
Das hat man jetzt auch für Block-Elemente oder für Block- und Table-Layouts.
Wobei die Spezifikationen spannenderweise nicht sagen, dass das für Table-Layout
funktionieren soll, sondern nur für Block-Elemente.
Ähm, keine Ahnung, was die sich bei Safari jetzt da gedacht haben.
Ist, glaub ich, auch nicht so wichtig, weil wahrscheinlich ist Table-Layout
ja eh, ähm, also keine Ahnung, wann hat zuletzt irgendwer von euch mal Display-Table
oder Display-Table-Cell verwendet?
Hm, lange nicht mehr. Also, ich benutze hin und wieder mal Tables.
Also, selten, wenn tatsächlich tabellarische Daten anzuzeigen sind.
Aber die kommen ja dann selbst schon mit diesem Display-Type daher.
Bei diesem Layout-Mode, da muss ich ja eigentlich nichts mehr dran ändern.
Und dann willst du ja auch, dass es als Tabelle gelayoutet ist und nicht irgendwelche
seltsamen Alignment-Dinger macht.
Ja, genau. Und da ging ja übrigens lustigerweise Vertical-Align ja immer schon.
Also in Table-Cells. Also insofern, ja.
Das ist halt auch in meiner Erinnerung der Grund, warum ich jemals Display-Table-Cell
geschrieben habe, damit ich das nutzen kann. Ja.
Genau, aber wir sagen danke, ne? Ist schon okay, passt, nehmen wir gerne mit.
Jo, gibt noch keine Kompatibilitätstabelle bei MDN, die da geupdatet wäre,
inwiefern das jetzt in Blogelementen geht. Also, nur noch mal zur Verdeutlichung.
Align-Content läuft dann überall, was nicht Display-Inline ist, mehr oder minder.
Und man muss das nicht extra noch für Display-Flex machen oder so was.
Genau, bei Display-Inline wäre es ja auch echt merkwürdig, wenn es,
also, und da gibt es ja Vertical-Align, Also, das geht ja da auch eigentlich.
Passt. Passt. Finden wir gut, nehmen wir mit.
So, hey, nächstes Thema. Das finde ich gut, weil das wollte ich sowieso die
Tage mal recherchieren.
Und jetzt kann ich mir das sparen, indem ich meine Werten mit Podcasterinnen
und mit Podcaster kostenlos für mich die Arbeit machen lasse.
Referiert mir doch mal was über CSS-Scoping. Ich habe mich damit noch gar nicht befasst.
Also ich würde sagen, der Name sagt ja schon vieles, es ist eigentlich auch
ein Feature, das wir schon mal hatten
mit diesem Scope-Attribut auf Style-Elementen da hatten wir glaube ich,
Irgendwann mal, glaube ich, im Kontext von einem Glücksrad. Also einen Host-Kontext
muss man ja unbedingt auch kennen.
So hießen ja auch unsere Episoden. Ja, da müssen wir uns noch einen mit dem
Peter machen. Peter schuldet uns immer noch einen Host-Kontext. Das stimmt.
Ja, das holen wir auch noch mal nach. Das müssen wir auch noch mal machen, ja.
Genau, also man kann mit dem, mit AdScope, mit der AdScope-Rule kann man die
darin definierten CSS-Angaben,
scopen an ein Element, also dass das quasi, dass die nur in diesem Element Anwendung
finden und das wiederum erlaubt es einem bei den Selektoren weniger,
aufpassen zu müssen, sag ich mal, oder weniger,
spezifisch zuzuschneiden für ein Element, sondern man kann dann wirklich ganz ganz.
Hemmsärmelig Element als Selektoren nutzen und Und es würden nur die Elemente
ausgewählt, die im Scope eines Elternelements sich befinden.
Also kann ich die selektorenspezifischer machen oder die selektorenspezifischer zu machen? Genau.
Und du hast darüber hinaus auch die Möglichkeit.
Den Scope auch an einer gewissen Stelle wieder aufhören zu lassen.
Das heißt also, wenn du jetzt sowas hast wie, du hast Tab-Container und du möchtest
die Tabs und vielleicht auch die Panels gestalten, dann könntest du einen Scope aufziehen,
der sozusagen von dem Außenbereich der Tab-Paneele geht bis jeweils zu dem Inneren
der Panels selbst, wo dann der Content reinkommt.
Und könntest dann eben einfach mit Elementselektoren arbeiten und die würden
eben tatsächlich nur die Elemente erfassen, die innerhalb deiner Tab-Komponente sich befinden,
aber dann nicht mehr die Elemente, die sich im Content befinden,
den du in das Paneel eines Tabs reinsteckst.
Also keine Ahnung, zum Beispiel links, also sagen wir mal die Tab diese Reiter wären links,
dann könntest du die eben, dann müsstest du die nicht mit irgendwelchen speziellen
Klassen versehen, sondern du könntest einen Scope aufziehen, der eben vom,
Route des Tab-Elements geht bis zu den Paneelen und könntest dann da die A selektieren
und mit denen machen, was auch immer du tun möchtest, würdest aber aber dann
in einem vielleicht Fließtext,
der in dem Paneel drinsteht, der auch einen Link enthält,
da würdest du den Link eben dann verschonen und nicht auch noch erfassen.
Okay, das heißt, dann kann ich ja tatsächlich die Styles so relativ selbstbeschränkend
auslegen, ohne mich selbst damit in Schwierigkeiten zu bringen,
weil ich diese Lektoren überspezifisch mache.
Ja. Also so eine softe Abstraktionsborder auslegen.
Genau. Und das geht auch in QuerySelector und Konsorten, das ist ja sehr schön.
QuerySelector, da bin ich gerade. Also, da kannst du ja hier die Scope-Pseudoklasse
auch verwenden und so Zeug. Genau, aber das konntest du immer schon.
Das ging vorher schon. Okay, verstehe. Also du konntest quasi sagen, bitte selektier.
Nur, genau, das ging immer schon, dass dieses Doppelpunkt Scope-Pseudo,
diese Pseudoklasse quasi das Element Element meint,
auf dem du die QuerySelector-Methode ausgeführt hast. Ach so.
Also du konntest es quasi dann miterfassen, theoretisch.
Ach so, dann findet QuerySelector auch sich selbst so ähnlich wie irgendwie
hier Closest auch sich selbst matcht, wenn's geht und in die Ansatz das mal
rein... Ich hab's nicht ausprobiert, deswegen weiß ich's nicht hundertprozentig.
Also wo ich's benutzt habe, ist, wenn du sowas machst wie, du hast einen Container
und willst die direkten Kind-Elemente davon greifen mit QuerySelectorAll,
dann kannst du eben deine Query schreiben mit Doppelpunkt Scope und dann dem Kind-Kombinator.
Und dann, keine Ahnung, H2 oder so was.
Ja, genau. Was man ja nicht machen kann, man kann ja nicht mit dem Kombinator
anfangen. Genau. Also du brauchst ja irgendwas zum Kombinieren.
Und da nimmst du dann eben die Scope-Pseudoklasse und dann würden wirklich nur
die direkten Kind H2s, jetzt in meinem Beispiel, von dem Element selektiert,
auf dem du die QuerySelectorAll-Methode ausgeführt hast.
Okay, das heißt, die Scope-Pseudoklasse hat mit Scoping nichts zu tun?
Ich glaube nicht. Also doch, man kann auch innerhalb eines Scope-Blocks matcht
es das Ding, was den Scope-Block definiert. Okay, alles klar. Ja.
Genau, und dann ist vielleicht noch eine Sache zu erwähnen bei dieser Add-Scope-Rule,
und zwar, dass da auch eine Relevanz hat, wie nah ein Element,
das betroffen ist, am Scope sitzt.
Und da gewinnt dann nämlich, welches am nächsten am Scope dran ist.
Ach so, wieder, wenn sich die Regeln und die Scopes überschneiden. Genau.
Und das ist vielleicht irgendwie auch noch,
also muss man einfach im Hinterkopf haben, weil das nicht so funktioniert, wie man das sonst kennt.
Normalerweise ist es ja so, dass wenn du CSS-Regeln hast, die die gleiche Spezifität haben,
dann greift ja diejenige Regel, die eben später im CSS kommt.
Und bei dem Scoping, da ist das eben nicht so.
Da wird zusätzlich auch darauf geschaut, okay, also die Spezifität ist jetzt gleich.
Es ist zwar so, dass eine dieser Angaben später im CSS kommt,
dennoch guckt der Browser dann,
wie weit ist der Abstand von den jeweiligen Scopes zu den Elementen und wenn
da der Abstand von einem dieser überlappenden Scopes eben kürzer ist,
dann gewinnt diese Angabe, auch wenn sie vielleicht im CSS später erscheint.
Und da kann man dann so Sachen machen wie eben so diese verschachtelten Dinger,
dass wenn man weißen Hintergrund hat, dass wenn man da was rein verschachtelt,
dass sie dann schwarzen Hintergrund haben soll.
Und wenn man da wieder was rein verschachtelt, dann wieder ein weißer Hintergrund.
Das ist ja so ein bisschen schwer,
ein CSS mit klassischen Selektoren zufriedenstellend abzubilden. Mhm.
Und ich sehe auch gerade einfach Style-Element nehmen, in ein Parent-Element
reinsetzen und darin die Styles einfach in einen At-Scope-Block ohne irgendwie
Angabe von eben den Scope-Limits anzugeben.
Heißt, der implizite Scope-Root ist das Parent-Element, in dem man diesen Inline-Style drin hat.
So wie man das früher von Style-Scoped kannte. Genau.
Und ja, im Prinzip, das ist, was man eigentlich erwarten würde,
wenn man jetzt mal wirklich HTML ernst nimmt, von wegen, das,
was da das Kind-Element ist, beeinflusst halt eben, wo drin es definiert ist.
Was ja eigentlich sehr schön wäre, was ich jetzt halt noch gerne hätte,
wäre, wenn ich dann dieses Style-Element nehme und ich projiziere es ins Shadow-Dom,
dass dann die Regeln in dem Shadow-Root gelten, wo er rein projiziert wird,
per Slot, und nicht auf dem Parent, was wahrscheinlich nicht stimmen wird,
aber was halt sehr gut wäre.
Sag doch mal, was meinst du?
Also, Parent-Element hast du, schreibst ein Style-Element rein, Inline-Style.
Und den slottest du dann ins Shadow-Root von dem Parent-Element.
Dann hast du ja trotzdem CSS-Regeln geschrieben, die sozusagen außerhalb vom
Shadow-Root definiert sind und da wirken.
Du würdest ja nur sozusagen die UI-Repräsentation durch das Shadowroot-Portal
in den Slot rein projizieren. Und dann wäre es in dem Slot gescoped.
Das wäre mein Traum-Szenario.
Und das dürfte eigentlich so nicht der Fall sein, weil es halt dann,
was die Webseite angeht, immer
noch ein Style-Element ist. Es ist ja ein Style-Element in der Webseite.
Und der Shadowroot ist ja im Prinzip bloß so eine Art Stargate,
wo du es halt eben dann rein projizieren kannst.
Aber es existiert ja de facto außerhalb davon und deswegen gelten die Styles außerhalb davon.
Was ich halt derzeit so gerne hätte, ist, Ich schreibe jetzt Scope rein,
projiziere das in einen Slot, badabing, badabung, gilt halt dann im Shadow-Root.
Weil guck mal, wenn du jetzt sowas in der Richtung haben willst,
musst du heutzutage den Weg entweder gehen mit irgendwie deklarativen Shadowdom,
das heißt, du musst dann deinen ganzen Krempel, den du in der Parent-Komponente
hast, noch mal in so ein Template rappen, was beknacktes.
Oder du machst das, was ich im Moment mache, nämlich du klonst dann Style-Elemente
in den Shadow-Root rein und deaktivierst sie in der Parent-Webseite,
was noch viel bescheuerter ist.
Aber halt eben das, worüber ich mich damals entschieden habe.
Das wäre halt eigentlich ganz cool, weil dann könntest du jetzt wirklich dann
so was machen wie, du willst da dieses Shadow DOM gestalten in dieser Komponente,
die wir dir geben, wo dann zum Beispiel, keine Ahnung, unser Switch-Element drin ist.
Geht ganz einfach, schreibst einfach zwischen die beiden HTML-Tags eine Style-Regel
rein und die gilt dann automatisch dafür.
Muss man sich nicht mit Pseudo-Elementen einen abbrechen, mit diesem komischen Part-Selektor.
Das könnte alles weg sein, wenn man sozusagen die Skopigkeit auch projizieren könnte.
Ja, also Peter, ich finde ja sowieso, dass du viel zu wenig in den verschiedenen
Webstandard-Issue-Trackern mitmischt.
Guck mal, jetzt hast du so einen coolen Bug in Firefox aufgemacht, direkt geht die Post ab.
Ja, direkt geht die Post ab, nachdem ich so lange auf Mastodon gejammert habe,
bis der Freddy das Ding mal in die richtige Kategorie schiebt,
wo Leute, die damit was zu tun haben, das auch sehen.
Ach, Schnickschnack. Ich bin auch voll der Meinung, dass das so sein sollte,
aber dann brauche ich halt irgendeine Art von Browser-Sugar-Daddy,
der mich dafür bezahlt, dass ich das mache.
Mhm, ja. Naja, vielleicht muss
man ja nur erst mal loslegen und irgendwann findet sich dein Sugar-Daddy.
Mal gucken, vielleicht ist das so.
Ja, genau. Ansonsten, wer da federführend für die Spec war, ist die Miriam Susanne. Ah, ja.
Die hat ja eh ein paar coole, die hat ja ständig irgendwie haut hier geiles Zeug raus.
Und die ist ja auch so jemand wie du. Also die war ja eigentlich auch sowas
wie eine unabhängige Web- oder CSS-Forscherin.
Okay. Hat ja auch viel so im SAS-Bereich gemacht. Mhm.
Und irgendwann wurde die dann angefragt, ob sie denn nicht irgendwie Lust hätte,
die ein oder andere Spec sozusagen zu spearheaden.
Und Und ja, also da kommt echt super viel krasses Zeug mittlerweile von der.
Die sollte man verfolgen, die schreibt nur gutes Zeug.
Und die ist auch sehr lustig und nett.
Nur gute Takes. Ja.
Ja, wir haben jetzt hier schon einiges zusammengequatscht. Und wie die letzten Male auch.
Ich hatte mich am Anfang gefragt, ob wir es diesmal schaffen.
Aber wir schaffen es nicht. Wir schaffen es nicht in einem Take.
Nee. Genau, und wir haben auch ein, sowieso ein zeitliches Ende gesetzt in zehn Minuten spätestens.
Und deswegen würde ich einfach vorschlagen, wir sind jetzt so relativ in der
Mitte von den Themen, die wir uns so rausgepickt hatten.
Dann könnten wir einfach jetzt einen Cut machen und die Part zwei dann nächste Woche wieder machen.
Wir sollten auf jeden Fall noch eine Retrospective jetzt darüber machen,
warum wir immer Spillovers haben.
Okay. Ich glaube, ihr beide wisst überhaupt nicht, wovon ich rede.
Ihr seid ja in anderen Bereichen unterwegs. Doch, hallo. Ich habe das alles verstanden.
Verstanden. Aber ich kann das auch beantworten, weil wir so quatschlieselnd sind.
Das ist halt so. Und wir gehen halt dahin, wo es wehtut und fragen halt,
braucht das eigentlich überhaupt mal jemand mit mehr als nur ausschließlich
reinem alten, gelangweilten Mann, der sagt, früher war alles besser.
Das mag ja auch eine Rolle spielen. Aber wir können uns ja zumindest noch eine
bessere Zukunft vorstellen.
Und das ist halt eben, glaube ich, echt die Killer-Kombi, die die Podcast-Länge nach oben treibt.
Ich habe noch einen Gedanken zu dem Switch-Toggle. Und zwar habe ich auch tatsächlich
in Vergangenheit relativ oft Checkboxen implementiert, die aber ausschließlich
wirklich Boolean-Values waren.
Das heißt jetzt nicht unbedingt eine Checkbox-Liste, wie ich es ja auch mit
einem Select machen könnte, dass ich sagen könnte, ich möchte diese fünf Sachen
von einer Liste aus 15 Sachen auswählen,
sondern dass ich wirklich nur wirklich eine Methode brauchte,
um etwas an- oder auszuschalten, bestimmte Settings.
Und ich denke, dass dieses Element jetzt rein in der UI dafür gedacht ist,
wenn du an- oder ausmachen willst, diese eine Setting, dann nutzt den Toggle.
Und wenn du den Usern vermitteln möchtest, ihr sollt hier von einer Gruppe an
Sachen etwas auswählen, dann, ihr müsst jetzt etwas selektieren, dann die Checkbox.
Und ich glaube, da, wo ich es aber trotzdem sehr, sehr merkwürdig fände,
so einen Tockel zu haben, wäre so was wie ich erkenne die AGB an.
Ich glaube, das ist so international, das muss einfach eine Checkbox sein.
Das kannst du nicht ausschalten.
Das ist required, dass du diesen Haken setzen musst.
Allerdings, wie bitte? Du hast gerade gesagt, aus einer Gruppe von Sachen 1
auswählen, wäre das nicht ein Radio-Button?
Mehrere auswählen. Ah, okay, mehrere. Zum Beispiel in der Farbauswahl.
Ich möchte schwarz, weiß, pink.
Aber ich meine, eure Diskussion oder unsere Diskussion vorher war ja tatsächlich
eher drüber, ob das ein HTML-Attribut sein muss oder wäre das nicht anders besser gegangen.
Aber ich habe jetzt seitdem drüber nachgedacht, warum sie überhaupt beschlossen
haben, dass es dieses, egal mit welchem Weg, so ein natives Element geben sollte.
Und ich glaube, das ist dafür gedacht, für diese An-Aus-Settings. Hm.
Okay, das ergibt Sinn.
Ich glaube, ich versuche auch noch mal zu gucken, ob ich da noch irgendwie einen
Issue-Tracker finde, wo noch ein bisschen was drinsteht oder so.
Spezifikation wäre halt echt nett, dass man irgendwie so weiß,
was soll das überhaupt? Die einzige Möglichkeit jetzt zu erfahren,
was man damit machen kann, so Stichwort Indeterminate und Konsorten,
ist halt, ja, installiere dir Safari.
Ja, ich habe ja Safari hier, aber eben anscheinend noch nicht eine neu genuge Version dafür.
Ja, da gibt es ein paar Anleitungen. Vielleicht musst du auch macOS kurz updaten Ja, genau.
Sonst hätte ich das, ich hatte das eben schon mal hier testen wollen, ging aber nicht.
Es ist natürlich auch eine interessante Herangehensweise, die Leute dazu zu
bringen, über die Neuerungen Bescheid zu wissen und auch darüber zu diskutieren,
indem man sie einfach mal so ein bisschen, wie wir jetzt das Empfinden so mal
hü-hot mal kurz releasen.
Anstatt das da ewig in Threads und Issues rumhängen zu lassen,
müssen es die Leute wieder vergessen.
Ich möchte jetzt nicht unterschreiben, dass das die richtige Methode wäre, Browser zu entwickeln.
Aber zumindest haben wir schon mal zwei Podcast-Episoden-Themen damit vollbekommen
Total gut, ja eigentlich, genau, weiter so würde ich sagen Auf jeden.
Genau, wenn ihr Hörerinnen und Hörer irgendwie Meinung zu diesen HTML- und CSS-Neuerungen
habt Und im Speziellen zu den von uns kontrovers oder kritisch gesehenen,
dann dürft ihr uns auf jeden Fall gerne schreiben oder mit uns diskutieren in unserem Slack.
Den findet ihr auf unserer Webseite verlinkt.
Und genau, ansonsten würden wir uns oder ist der Plan, dass wir nächste Woche uns um Teil 2 kümmern.
Wenn alles hinhaut, ist ja auch schon mal anders gelaufen, aber das wird der
Plan und genau, dann schauen wir mal, was wir da noch ausgraben.
So machen wir das. Und euch erstmal vielen Dank.
Das war eine sehr anregende Diskussion. Vielen Dank zurück. Und genau,
schöne Woche euch. und vielen Dank fürs Zuhören.
Dankeschön, tschüssi. Bis zum nächsten Mal. Tschau. Tschüss.
Music.
Musik Musik,
Musik Musik Musik Bis zum nächsten Mal.