Die alljährliche Umfrage zum State of CSS haben Vanessa und Schepp herangezogen, um über die dort aufgeführten brandneuen oder auch nicht mehr so neuen, aber dennoch interessanten CSS Features zu sprechen. Dies ist Teil eins von zwei Teilen. Unser Sponsor Dieser Podcast wird von NordVPN unterstützt. NordVPN ist ein Premium-VPN-Anbieter, der sich durch regelmäßige Updates […]
Die alljährliche Umfrage zum State of CSS haben Vanessa und Schepp herangezogen, um über die dort aufgeführten brandneuen oder auch nicht mehr so neuen, aber dennoch interessanten CSS Features zu sprechen. Dies ist Teil eins von zwei Teilen. Unser Sponsor Dieser Podcast wird von NordVPN unterstützt. NordVPN ist ein Premium-VPN-Anbieter, der sich durch regelmäßige Updates mit neuen und praktischen Funktionen von der Konkurrenz abhebt. In Kombination mit einem fairen Preis und der jahrelangen Erfahrung des Teams, das aus Cybersicherheits- und IT-Experten besteht, blickt NordVPN auf eine inzwischen 10-jährige Firmengeschichte zurück. Ein VPN ermöglicht die Verbindung ins Internet über einen virtuellen privaten Server eines spezifischen Standorts und verschleiert dabei die eigene IP-Adresse. Zusätzlich wird so der Datenverkehr verschlüsselt und sorgt so für mehr Anonymität im Netz. Damit auch du sicher im Internet unterwegs sein kannst, schau bei nordvpn.com/workingdraft vorbei und teste 30 Tage lang risikofrei mit der 30-Tage-Geld-zurück-Garantie! Schaunotizen [00:01:52] State of CSS Vanessa und Schepp beginnen mit der Feststellung, dass sich der Nutzen vieler neuer CSS Features nicht immer direkt erschließt, oder auch, dass einem der Umfang der Möglichkeiten, die sich aus neuen Features ergibt, nicht immer sofort klar ist. [00:07:15] CSS Writing Modes Beide haben wir nie Interfaces bauen müssen, die für andere Sprachen als von links nach rechts und von oben nach unten gelesene angepasst werden mussten. Wir haben die CSS Writing Modes aber durchaus genutzt, um Schrift auf engem Raum vertikal anzuzeigen. Irgendwie kommen wir auf die These, dass es bestimmt so etwas wie „Unter-Internets“ gibt, in der sich Konsumenten anders geschriebener Sprachen tummeln, dort die tollsten Web Dev Tricks gepostet werden, und wir davon aufgrund der Sprachbarriere überhaupt nichts wissen. [00:15:30] gap Property for Flexbox Wir sind uns einig, dass gap, welches neben CSS Flexbox auch von CSS Grid und (außer in Safari) CSS Multicolumn unterstützt wird, super praktisch ist. [00:21:43] Subgrid Subgrid betrachten wir noch als nicht einsetzbar, weil der Browser-Support noch nicht breit genug ist und es auch keine guten Fallbacks gibt. [00:22:21] content-visibility Bei content-visibility ist das anders. Das lässt sich trotz geringem Browser-Support super in Form von „Progressive Enhancement“ einbauen. Letztlich ist das nichts anderes als Lazy Rendering von Elementen. [00:22:40] @container Und auch Container Queries beginnen wir mittlerweile so einzusetzen, dass Dinge „graceful degraden“, wenn die Technik noch nicht zur Verfügung steht, was man mit @supports ja gut herausbekommen kann. [00:24:21] Media Queries Range Contexts Die neue Schreibweise von Media Queries in Form von Wertebereichen zwischen einem Minimum und Maximum, mit Hilfe von mathematischen Gräßer- und Kleinerzeichen finden wir gut lesbar und sie hilft auch ein paar Edge Cases zu vermeiden, auf die wir mit der derzeitigen Schreibeweise stoßen. Anders als von uns in der Aufnahme behauptet, werden die nicht nur von Firefox, sondern auch von Chromium unterstützt. Es dauert also noch eine Weil, bis wir die einsetzen können. [00:30:49] Logical Properties Logische Eigenschaften benutzen wir aus den gleichen Gründen nicht, wie im Zusammenhang mit den CSS Writing Modes genannt. Allerdings sehen wir durch unser Verhalten Zugänglichkeitsprobleme für Benutzer*innen, die mit Browser-Plugins eine Seite in ihre Sprache übersetzen lassen. Die könnten von Logical Properties profitieren. [00:32:07] Viewport-Percentage Length Units Die neuen Viewport Units sind eine praktische und willkommene Ergänzung zu den etablierten und lösen Probleme, die man speziell auf mobilen Geräten und ihren dynamischen Viewports hat. [00:32:53] backdrop-filter Der Backdrop-Filter hat es Vanessa besonders angetan. Der Backdrop-Filter macht für Dinge, die hinter einem Element durchschein[...]
Die alljährliche Umfrage zum State of CSS haben Vanessa und Schepp herangezogen, um über die dort aufgeführten brandneuen oder auch nicht mehr so neuen, aber dennoch interessanten CSS Features zu sprechen. Dies ist Teil eins von zwei Teilen.
Dieser Podcast wird von NordVPN unterstützt. NordVPN ist ein Premium-VPN-Anbieter, der sich durch regelmäßige Updates mit neuen und praktischen Funktionen von der Konkurrenz abhebt. In Kombination mit einem fairen Preis und der jahrelangen Erfahrung des Teams, das aus Cybersicherheits- und IT-Experten besteht, blickt NordVPN auf eine inzwischen 10-jährige Firmengeschichte zurück. Ein VPN ermöglicht die Verbindung ins Internet über einen virtuellen privaten Server eines spezifischen Standorts und verschleiert dabei die eigene IP-Adresse. Zusätzlich wird so der Datenverkehr verschlüsselt und sorgt so für mehr Anonymität im Netz.
Damit auch du sicher im Internet unterwegs sein kannst, schau bei nordvpn.com/workingdraft vorbei und teste 30 Tage lang risikofrei mit der 30-Tage-Geld-zurück-Garantie!
gap Property for Flexbox
Wir sind uns einig, dass gap, welches neben CSS Flexbox auch von CSS Grid und (außer in Safari) CSS Multicolumn unterstützt wird, super praktisch ist.
[00:21:43] Subgrid
Subgrid betrachten wir noch als nicht einsetzbar, weil der Browser-Support noch nicht breit genug ist und es auch keine guten Fallbacks gibt.
[00:22:21] content-visibility
Bei content-visibility ist das anders. Das lässt sich trotz geringem Browser-Support super in Form von „Progressive Enhancement“ einbauen. Letztlich ist das nichts anderes als Lazy Rendering von Elementen.
[00:22:40] @container
Und auch Container Queries beginnen wir mittlerweile so einzusetzen, dass Dinge „graceful degraden“, wenn die Technik noch nicht zur Verfügung steht, was man mit @supports ja gut herausbekommen kann.
[00:24:21] Media Queries Range Contexts
Die neue Schreibweise von Media Queries in Form von Wertebereichen zwischen einem Minimum und Maximum, mit Hilfe von mathematischen Gräßer- und Kleinerzeichen finden wir gut lesbar und sie hilft auch ein paar Edge Cases zu vermeiden, auf die wir mit der derzeitigen Schreibeweise stoßen. Anders als von uns in der Aufnahme behauptet, werden die nicht nur von Firefox, sondern auch von Chromium unterstützt. Es dauert also noch eine Weil, bis wir die einsetzen können.
[00:30:49] Logical Properties
Logische Eigenschaften benutzen wir aus den gleichen Gründen nicht, wie im Zusammenhang mit den CSS Writing Modes genannt. Allerdings sehen wir durch unser Verhalten Zugänglichkeitsprobleme für Benutzer*innen, die mit Browser-Plugins eine Seite in ihre Sprache übersetzen lassen. Die könnten von Logical Properties profitieren.
[00:32:07] Viewport-Percentage Length Units
Die neuen Viewport Units sind eine praktische und willkommene Ergänzung zu den etablierten und lösen Probleme, die man speziell auf mobilen Geräten und ihren dynamischen Viewports hat.
[00:32:53] backdrop-filter
Der Backdrop-Filter hat es Vanessa besonders angetan. Der Backdrop-Filter macht für Dinge, die hinter einem Element durchscheinen das, was der normale Filter für Elemente tut. Wir stellen fest, dass man mit Filtern, egal ob Backdrop-Filter oder normalem Filter, schnell zu dick auftragen kann. Weniger ist hier also wieder einmal mehr. Irgendwie kommen wir dann auf die Serie She-Hulk, die Vanessa sehr empfehlen kann.
[00:38:37] Intrinsic Sizing
Als nächstes sprechen wir über die Keywords fit-content, min-content und max-content, die man in width und height einsetzen kann und die ein Element abhängig von seinem Inhalt dimensionieren, ähnlich wie CSS Flexbox‘ flex-basis oder CSS Grids fit-content()-Funktion. Use-Cases gibt es aber eher wenige.
[00:44:12] accent-color
Vanessa liebt accent-color, das zum unkomplizierten „Themen“ von Browser-GUI aka „Replaced Elements“ genutzt werden kann. In manch einem Projekt reicht das schon, um die beteiligten Designer*innen glücklich zu machen, ohne dass man gleich Inputs & Co alle in neu (und barrierevoll) nachbauen muss.
[00:48:17] currentcolor
Zitat aus der „Incomplete List of Mistakes in the Design of CSS“ der CSS Working Group:
The currentColor keyword should have retained the dash, current-color, as originally specified. Likewise all other color multi-word keyword names.
Tatsächlich wird der Fehler des Camelcasens dieses Keywords nun in 2022 endlich korrigiert, allerdings nicht mit einem Bindestrich, sondern durch komplettes Lowercasen des Wortes. Das hat den Hintergrund, dass CSS größtenteils case-insensitive ist und die Änderung so rückwärtskompatibel bleibt.
[00:53:36] (Gradient) Color Spaces Auf die neuen Farbräume in CSS freuen wir uns schon. Die decken nicht nur mehr Farbraum ab, als das derzeit verwendete sRGB, sondern sind auch nach einem psychovisuellen Modell entwickelt. Und aufgrund ihrer Form ermöglichen die neuen Farbräume auch deutlich schönere Farbverläufe. [00:58:14] CSS Scroll Snapping Nun geht es endlich um das eingangs schon angesprochene CSS Scroll Snapping und Scrollen und Touchen und wir verweisen auf Adam Argyles irren CSS Café Talk zu dem Thema. [01:03:09] Variable Fonts Obwohl wir schon einige Vorträge zu dem Thema gesehen haben, haben wir der Praxis noch nicht einen variablen Font zum Einsatz gebracht. Das lohnt sich aber eigentlich auch erst, wenn man mehr als zwei bis drei Schriftschnitte benötigt. Zudem stellen die variablen Fonts manches Schriften-verarbeitende Tool vor Probleme. [01:08:47]line-clamp
Wir sehen line-clamp, mit dem man Texte nach so und so viel Zeilen abschneiden kann, mit gemischten Gefühlen. Einerseits erscheint es uns wie etwas unbeholfenes Interface-Design, bei dem störender Inhalt weichen soll. Andererseits finden wir schade, dass wir vom Browser keine Rückmeldung, z.B. in Form einer Pseudoklasse haben, wenn Text tatsächlich abgeschnitten wurde. So können wir gestalterisch nicht darauf eingehen und einen Hinweis auf mehr Text einblenden.
[01:13:25] font-display
font-display stammt aus dem Bemühen, die verschiedenen Verhalten von Browsern beim Anzeigen von Schriften zu vereinheitlichen bzw. einstellbar zu machen. font-display: swap ist hier meist die Einstellung, die man haben möchte.
Transkript
WEBVTT 00:00.000 --> 00:28.800 Revision 545. 00:28.800 --> 00:33.080 In den letzten Monaten ging's bei mir, wie wahrscheinlich bei vielen von euch, wieder 00:33.080 --> 00:37.200 ein bisschen mehr rund mit dem Reisen, ich war viel unterwegs mal in München bei meinem 00:37.200 --> 00:41.400 Arbeitgeber, aber jetzt kürze ich auch auf einer Konferenz in Berlin, da bin ich viel 00:41.400 --> 00:46.640 im Hotel oder unterwegs mit der Bahn und überall bin ich natürlich online, muss mal 00:46.640 --> 00:51.600 einen Vertrag bearbeiten, die E-Mails checken, mal eine Datei versenden und wenn ich dann 00:51.600 --> 00:56.160 in irgendwelchen öffentlichen Netzwerken unterwegs bin, ist mir natürlich wichtig, dass die 00:56.160 --> 01:03.760 ganzen Daten sicher sind, so und genau da kommt jetzt NordVPN ins Spiel. NordVPN ist 01:03.760 --> 01:09.880 ein Premium-Anbieter für VPNs, bieten sehr viel mehr als die Mitbewerber, wo durch regelmäßige 01:09.880 --> 01:15.240 Updates mit neuen praktischen Funktionen in Kombination mit dem fairen Preis und natürlich 01:15.240 --> 01:20.840 auch der jahrelangen Erfahrung in dem Bereich, da hebt sich NordVPN von der Konkurrenz ganz klar ab. 01:20.840 --> 01:25.800 Das zeigen auch die zahlreichen positiven Online-Bewertungen der 14 Millionen Nutzer vom 01:25.800 --> 01:31.040 Qualitätsvpn und wenn ihr jetzt sagt, das möchte ich gerne auch mal ausprobieren, dann 01:31.040 --> 01:37.720 schnappt euch den exklusiven Deal unter nordvpn.com slash workingdraft, da könnt ihr NordVPN 01:37.720 --> 01:43.080 risikofrei mit der 30-Tage-Geld-Zurück-Garantie testen. Alle Infos dazu gibt es natürlich 01:43.080 --> 01:48.240 auch nochmal in den Shownauts. Wir danken NordVPN für die Unterstützung von dieser 01:48.240 --> 01:54.120 Revision vom Workingdraft und jetzt viel Spaß mit der Sendung. Wir sind heute zu zweit, 01:54.120 --> 02:03.760 da hätten wir zum einen die Vanessa. Hallo. Hallo Vanessa und ich bin der Chef. Und wir haben uns 02:03.760 --> 02:11.600 gedacht, also vor ein paar Tagen oder Wochen vielleicht wurde die neue State of CSS Survey 02:11.600 --> 02:18.280 publiziert und wir haben gedacht, wir könnten die ja mal heranziehen und so ein bisschen durch die 02:18.280 --> 02:24.760 Durchhangeln, die nicht in allen Details durchgehen und einfach ein paar Sachen rauspicken und einfach 02:24.760 --> 02:32.720 mal darüber ein bisschen quatschen. Genau. Ich hatte ja sogar ein bisschen Bammel, diese 02:32.720 --> 02:37.440 Revision aufzunehmen. Ich freue mich natürlich auch sehr, Chef, dass du dabei bist gerade, 02:37.440 --> 02:44.960 weil ich immer das Gefühl habe, dass sie so 90 Prozent der Sachen, wo man dann so gefragt wird, 02:44.960 --> 02:50.640 kennst du das, benutzt du das, ungefähr nein antworten muss. Ich weiß auch gar nicht, 02:50.640 --> 02:55.560 woran es explizit liegt. Vielleicht ist es auch nur eine subjektive Fehleinschätzung, 02:55.560 --> 03:01.840 dass mir manche Sachen dann, ich glaube, diese Fehleinschätzung könnte daher kommen. Das finde 03:01.840 --> 03:05.160 ich jetzt persönlich nicht gut, aber es könnte so sein, dass ich manchmal die Begriffe dafür 03:05.160 --> 03:10.480 einfach nicht kenne, dass ich Sachen benutze, Apply Rules, dass ich weiß, es gibt jetzt eine 03:10.480 --> 03:15.200 Container Query und ich versuche sie mal, teste sie mal aus, aber dann gar nicht so die Verbindung 03:15.200 --> 03:20.920 mache, wie das ist ein Ding, das hat einen ganzen Namen, das ist ein Feature. Also das ist quasi 03:20.920 --> 03:28.080 die Sachen eigentlich schon benutzt, aber eben dir, du das gar nicht so quasi, wenn du dann sozusagen 03:28.080 --> 03:34.800 den Straßennamen davon liest, irgendwie gar nicht das in Verbindung bringst, damit, 03:34.800 --> 03:41.840 mit dem was du sowieso benutzt. Ja, genau. Und viele Dinge, die ich dann höre, 03:41.840 --> 03:51.240 nehmen wir mal Aspect Ratio als Beispiel, da war ein Riesentubel, allerdings bin ich dann nicht in 03:51.240 --> 03:58.080 der Gruppe, wo man sich total freut, dass es das jetzt gibt, weil ich trotzdem in Fulltime Job 03:58.080 --> 04:05.280 so darauf getrimmt bin, ich muss Sachen programmieren, die müssen in allen modernen Browsern funktionieren 04:05.280 --> 04:11.240 und da haben wir zwar jetzt nicht mal den Internet Explorer, der uns vielleicht manchmal im 04:11.240 --> 04:17.640 Weg gestanden ist und ich kann jetzt mittlerweile einfach Flexbox und Grid verwenden, aber dennoch, 04:17.640 --> 04:23.360 wenn ich jetzt höre, da kommt ein neues Feature raus und das ist oder das ist noch in Specs oder 04:23.360 --> 04:27.520 ähnliches, dann ist es auf meinen Kopf auch einfach relativ schnell wieder draußen, weil ich mir 04:27.520 --> 04:31.360 denke, gut in drei Jahren wird schon noch mal jemanden rufen, wenn man das jetzt tatsächlich 04:31.360 --> 04:41.160 richtig einsetzen kann und bei vielen ziemlich coolen Sachen habe ich das Gefühl, da bin ich 04:41.160 --> 04:45.520 nicht so die Kreative dafür, also ich habe, ich sehe dann, okay, da gibt es dieses Feature, 04:45.520 --> 04:49.520 bin mir aber unsicher, was ist denn jetzt eigentlich so der richtige Use Case dafür, 04:49.520 --> 04:57.680 zum Beispiel haben wir gerade ein bisschen was über Scroll Snap gelernt und unfassbar, 04:57.680 --> 05:03.240 unfassbar super, aber wenn ich quasi kein Design bekomme, wo mir jemand sagt, du kannst du das 05:03.240 --> 05:08.320 was dahin scrollen, dann komme ich gar nicht so kreativ auf die Idee, ich könnte ja mal hier 05:08.320 --> 05:15.240 so einen Effekt einbauen. Ja, dann, ja, dann stellt man die Verbindung nicht her, 05:15.240 --> 05:20.720 ja, man muss halt so irgendwie dann so ein bisschen Spieltrieb haben, glaube ich, 05:20.720 --> 05:28.680 also Hintergrund ist, dass wir gerade aus dem CSS-Kaffee Meetup kommen, wo der Adam A. Geil 05:28.680 --> 05:34.240 einen ganzen Vortrag über Scroll Snapping gemacht hat, gehalten hat, die man sich auch auf Video 05:34.240 --> 05:42.120 angucken kann und da echt super coole Anwendungen zusammen oder Anwendungsfälle vorgestellt hat, 05:42.120 --> 05:51.720 die irgendwie mit Scroll Snapping zu tun haben und dessen ganzen Property-Sambelsurium und das sind 05:51.720 --> 05:57.040 echt so viele verschiedene Dinge, aber muss man auch erst mal darauf kommen, ja. Also die, 05:57.040 --> 06:04.080 wenn man die Scroll Snapping, die sozusagen die Specklees oder was, oder das ist den Explainer, 06:04.080 --> 06:11.640 dann sind, wenn solche Sachen gar nicht erwähnt, weil eigentlich ist es erst mal so für irgendwelche 06:11.640 --> 06:18.360 swipebaren Slider gedacht oder so, aber der hat ja da ganz anderes Zeugs gezeigt und wenn man das 06:18.360 --> 06:25.160 dann sieht, dann ist es auch so, ja, klar, natürlich, liegt auf der Hand. Man muss irgendwie sich ein 06:25.160 --> 06:30.480 bisschen sozusagen, man muss so ein paar Schritte zurückgehen und sagen, wo wird der noch geswipet, 06:30.480 --> 06:36.640 eigentlich in User Interfaces und gescold und das ist eigentlich sehr viel mehr als man denkt, 06:36.640 --> 06:42.640 also gerade auf Mobilgeräten wird ja nur geswipet und gescold, ja, genau, da braucht man einfach 06:42.640 --> 06:50.240 auch ein bisschen, glaube ich, Luft, um kreativ zu sein. Die Ideen kommen ja mir dann in den absurdesten 06:50.240 --> 06:54.760 Situationen, also mir fallen dann auch manchmal Sachen ein, so cool, das muss ich mal ausprobieren, 06:54.760 --> 07:03.480 aber dann sitze ich auch nicht unbedingt immer im Rechnartan oder so. Ja, ich denke, eine ziemlich 07:03.480 --> 07:09.720 coole Sache, von der ich mal gehört habe und die haben wir hier auch im CSS Survey mit dabei, 07:09.720 --> 07:21.040 gleich bei der ersten Sektion über die Layouts, sind die CSS Writing Modes und schon relativ lang 07:21.040 --> 07:26.600 kenne ich so dieses Attribut, dass man die Direction in die Richtung setzen kann, was dann eben sehr 07:26.600 --> 07:32.000 hilfreich ist, wenn man nicht die normale in Deutschland gewohnte Schrift von links nach rechts 07:32.000 --> 07:38.800 hat, sondern eine von rechts nach links, aber mit Writing Mode habe ich mal was anderes ziemlich 07:38.800 --> 07:44.480 coole gemacht und zwar konnte ich damit auch Text vertikal erscheinen lassen und das habe ich 07:44.480 --> 07:49.040 mal von der Seite benutzt, wo so ein Bild war und statt jetzt einfach so eine Fig Caption oder 07:49.040 --> 07:55.080 Untertitel unter einem Bild darunter zu schreiben, konnte ich dann vom Layout, der das eigentlich 07:55.080 --> 07:59.480 super schön machen, also meinen Textblock, also war so recht eckig, da habe ich mein Bild, 07:59.480 --> 08:05.240 das war recht eckig und quasi mit der Bild-Unterschrift so ein bisschen ausgebrochen aus dem 08:05.240 --> 08:10.760 Layout, aber links daneben und habe das dann vertikal erscheinen lassen und davor dachte ich mir 08:10.760 --> 08:17.720 immer auch, wie ich davor meinte, was total sinnlos, wozu sollte man das jemals brauchen, 08:17.720 --> 08:22.000 als ich nur gelesen habe, dass es das gibt für eben, was will ich denn mit vertikalem Text 08:22.000 --> 08:26.560 und dann mit D zusammen, ach jetzt kann ich die Bild-Unterschrift da so links daneben, 08:26.560 --> 08:31.200 aber vertikal machen, das sah super aus, das hat echt einen schönen schönen Effekt gegeben. 08:31.200 --> 08:38.280 Geht auch glaube ich nicht, also ich denke, als ich das gemacht hatte, da gab es das noch nicht, 08:38.280 --> 08:42.600 ich bin mir wirklich niemals sicher als Jahre her und da habe ich noch rumgedrickst und sah 08:42.600 --> 08:46.760 nicht so cool aus und jetzt wirklich nur Writing Mode, Vertical und dann kann ich noch sagen, 08:46.760 --> 08:52.680 links rechts, links wie auch immer und dann sieht das ziemlich cool aus. Ja, aber ich 08:52.680 --> 08:57.400 gebe dir Recht, also eigentlich braucht man das nicht, also ich habe es auch nur für solche 08:57.400 --> 09:04.760 Use Cases benutzt, wo also manchmal ist das ja auch, braucht man es vielleicht auch so bei Tabellen, 09:04.760 --> 09:10.080 die man irgendwie auf Mobilgeräten noch zeigen möchte, wo vielleicht irgendwelche Sachen drin 09:10.080 --> 09:15.920 angehakt sind und dann will man oben die Spaltenüberschriften irgendwie noch da reinkriegen 09:15.920 --> 09:20.720 und dann kann man die auch so versuchen, vertikal zu stellen, aber da gibt es natürlich auch dann 09:20.720 --> 09:28.920 die Möglichkeit mit Transformen das zu rotieren, irgendwie so Sachen zu machen, aber genauso in 09:28.920 --> 09:35.520 dem Kontext habe ich das dann auch verwendet, aber ich habe in meiner ganzen Karriere habe 09:35.520 --> 09:42.800 ich noch nie Interfaces bauen müssen, die für nicht westliche Sprachen auch gedacht sind. 09:42.800 --> 09:49.080 Das ist mir auch aufgefallen, ich habe das dann mal so stehen gelassen, ich weiß gar nicht, 09:49.080 --> 09:54.040 ob das jetzt gut ist oder üblich, aber das ist mir auch aufgefallen, jetzt bin ich ja doch irgendwie 09:54.040 --> 10:03.240 über acht Jahre offiziell, also mit Werkstudentenzeit noch davor, aber dann so als fest eingestellte 10:03.240 --> 10:09.640 unterwegs und auch für verschiedenste Projekte, Kunden oder eigen der Produkte und noch nie 10:09.640 --> 10:17.880 war es irgendwie zur Debatte gestanden, dass man eine andere Schriftrichtung bräuchte, also alles 10:17.880 --> 10:23.200 mögliche schon mit spanisch und französisch und übersetzt und ja mal Dateien oder sonst welche 10:23.200 --> 10:30.880 Tours, aber es waren immer nur die gewohnten europäischen Sprachen, keine Ahnung oder vielleicht, 10:30.880 --> 10:35.920 ich glaube als Werkstudentin war das vielleicht mal der Fall und das hat mich aber da war ich 10:35.920 --> 10:40.400 zu weit weg, das hat mich niemand gefragt, dass ich das mache, das war da schon gegeben wahrscheinlich. 10:40.400 --> 10:44.640 Also ich weiß, ich hatte mal ein Projekt, da haben wir glaube ich auch 10:44.640 --> 10:55.120 verschiedene asiatische Sprachen gehabt, aber trotzdem haben wir nicht den Writing-Mode dafür 10:55.120 --> 11:03.400 geändert. Und da ich die asiatischen Sprachen ja nicht lesen und verstehen kann, kann ich jetzt 11:03.400 --> 11:10.640 auch nicht sagen, warum das okay war oder ob das nicht okay war, das war dann einfach für 11:10.640 --> 11:15.720 Porsche so was, die haben das dann lokalisiert. Ja, ich finde es aber deswegen so interessant, 11:15.720 --> 11:24.320 weil ich mich dann gefragt habe, ist es entweder so, dass all diese Länder, die eine andere 11:24.320 --> 11:29.280 Sprachrichtung haben, haben die ganz andere Webseiten als wir, haben wir das so zweigeteilte 11:29.280 --> 11:34.320 Welt, weil für mich ist Internet immer so, ist für alle gleich. Aber gibt es da vielleicht doch 11:34.320 --> 11:40.800 auch so was wie Regionen und leben wir in zwei verschiedenen Internetwelten da oder ist es so, 11:40.800 --> 11:45.360 dass diese Leute einfach wahnsinnig benachteiligt sind und mittlerweile gewohnt sind, ihre eigene 11:45.360 --> 11:50.480 Schrift dann doch von links nach rechts zu lesen oder einfach auf Englisch lesen, 11:50.480 --> 11:54.480 könnte ja auch sein. Ich weiß, das finde ich jetzt total interessant, hat jetzt nichts mehr mit 11:54.480 --> 12:02.200 CSS zu tun, fände ich aber interessant. Also ist jetzt so ein educated guest von dem, was ich in 12:02.200 --> 12:06.840 der Vergangenheit beobachtet habe, aber die, da ich das natürlich so erstmal diese ganze 12:06.840 --> 12:13.600 Computertechnik aus den USA kam, also ich meine, das fing ja schon bei uns an, so mit so früher so 12:13.600 --> 12:20.160 Probleme mit umlauten und sowas. Die Amis halt so, ja, weiß ich nicht, umlaute, was ist das? So, 12:20.160 --> 12:29.520 das ist ja zum Glück kein Problem mehr. Aber auch so Tastaturen, also sie hatten 12:29.520 --> 12:36.040 einfach viel mehr Zeichen und die können dann ja auch so im Prinzip sind das ja Ligaturen, 12:36.040 --> 12:40.680 die die dann, wenn die bestimmte Zeichen folgen auf einer normalen Tastatur, dann tippen, 12:40.680 --> 12:48.920 dann kriegen die das Zeichen, was sie möchten. Die haben schon echt gute Kniffe und Wege gefunden, 12:48.920 --> 12:54.800 wie die das dann adaptieren konnten, dass sie damit irgendwie alles ausdrücken können, 12:54.800 --> 12:59.320 machen können, was sie möchten. Aber ich glaube schon, dass es auch so ein bisschen so ist, 12:59.320 --> 13:08.200 dass, also, so wie es uns leichter fällt, irgendwelche romanischen Sprachen vielleicht zu 13:08.200 --> 13:16.160 lernen als kürillisch oder hebrisch oder eben asiatische Sprachen, ist es bei denen wahrscheinlich 13:16.160 --> 13:23.520 auch so und dadurch tummeln die sich eben in ihrer quasi in dem Unterbereich des Internet so, 13:23.520 --> 13:28.480 wie wir auch keinen Plan haben, was also wahrscheinlich gibt es noch viel mehr Inhalte in 13:28.480 --> 13:34.560 all diesen für uns nicht verständlichen Sprachen, die wir nie heben werden. Also so, 13:34.560 --> 13:41.240 wahrscheinlich sind da die tollsten CSS Tricks auch drin und Web Dev Sachen, aber wir haben keine 13:41.240 --> 13:47.720 Ahnung davon. Und auch vom Design sind die ja ganz unterschiedlich. Also die, wenn man sich so 13:47.720 --> 13:54.200 asiatische Seiten anschaut, dann sind die ja immer unfassbar vollgepackt und die haben auch einen 13:54.200 --> 14:00.600 ganz anderen Stil, da ist auch einfach so irgendwie so ein bisschen mehr To-va-bo. Aber das liegt wohl 14:00.600 --> 14:09.760 daran, dass die sind so für Scannen optimiert, die lesen weniger und scannen mehr. So habe ich 14:09.760 --> 14:17.120 das mal erzählt bekommen und durch diesen unterschiedlichen Ansatz sowas zu konsumieren, 14:17.120 --> 14:26.320 sind die auch anders strukturiert. Ja, das ist spannend. Aber vielleicht, da können wir ja direkt 14:26.320 --> 14:32.080 mal einen Aufruf an unsere Hörerinnen und Hörer machen, wenn ihr euch mit sowas auskennt oder 14:32.080 --> 14:41.440 ihr in Unternehmen arbeitet und an Projekten arbeitet, die viel Lokalisation machen. Und also 14:41.440 --> 14:49.040 ist immer ein super spannendes Thema und wie gesagt, wir haben das eigentlich nie gemacht. Und was 14:49.040 --> 14:56.800 ich halt so weiß, ist eben, wenn ich mal Vorträge gesehen habe oder irgendwie darüber mal was gelesen 14:56.800 --> 15:02.280 habe, aber das kommt ja auch nicht so häufig vor. Genau, dann seid ihr herzlich willkommen, 15:02.280 --> 15:09.480 eine Gäste bei uns. Genau, schreibt uns einfach an an Comments at WorkingDraft.de oder haut uns auf 15:09.480 --> 15:20.920 Twitter an. Eine andere Frage beim State of CSS ist die Gap by Flexbox. Und das ist jetzt 15:20.920 --> 15:29.040 tatsächlich eine Eigenschaft, die ich ununterbrochen verwende und die ich aus Versehen kennengelernt 15:29.040 --> 15:34.960 habe. Ansonsten hätte ich sie bewusst mal irgendwo gelesen, so, es gibt jetzt Gap for Flexbox, 15:34.960 --> 15:39.520 das wäre so einer der wenigen Sachen gewesen, wo ich gesagt hätte, das muss ich sofort einsetzen, 15:39.520 --> 15:44.520 jetzt zum Beispiel eben nicht wie bei Aspect Ratio, weil das ist ja supergeil, aber ich habe es halt 15:44.520 --> 15:48.360 irgendwie einmal nur hier gebraucht und da habe ich schon mein, wie weiß ich nicht mehr, mein 15:48.360 --> 15:56.240 Pettingtop von irgendwas 49, weil ich weiß es nicht mehr. Aber Gap habe ich so verstanden, 15:56.240 --> 16:04.720 dass das bei Flexbox gibt, weil ich habe Grid CSS im Einsatz und ich habe Flexbox im Einsatz bei 16:04.720 --> 16:09.640 verschiedenen Sachen und aber der aber auch mit Kollegen und Kolleginnen zusammen, wo wir 16:09.640 --> 16:14.760 alle so ein bisschen fullstackmäßige unterwegs sind. Das heißt, wenn gerade kein Frontendler mal 16:14.760 --> 16:21.240 wieder keine Zeit hat, dann können die von der Backend-Abteilung auch gerne mal einfach mal 16:21.240 --> 16:27.000 so ein bisschen HTML kopieren mit den richtigen Klassen. Wir sind ja mit Teilbund CSS im Einsatz, 16:27.000 --> 16:30.800 von daher muss man da nicht in den CSS-Datei gehen, sondern da wird meistens die Klasse dann mit 16:30.800 --> 16:40.080 übernommen und kam mein Kollege auf die Idee, er braucht dann eine andere Breite oder Spaces 16:40.080 --> 16:46.640 zwischen und hat ein Gap gesetzt. Daywind Gap von 4, das ist dann ein Rem. Und ich so, und ich 16:46.640 --> 16:51.600 noch so eine voll der Klugscheiße, Entschuldigung für das Wort, im Pull Request und so, ja, 16:51.600 --> 16:55.920 das ist ja Gap, das macht man doch nur bei Grid, es geht doch gar nicht. Und so, doch, 16:55.920 --> 17:00.960 das geht doch nicht so was, oh Gott, es tut mir so, es tut mir so unfassbar leid, 17:00.960 --> 17:07.120 dass ich hier rumgeschrien habe, bevor ich sie selber ausprobiert habe. Also Gap lässt sich 17:07.120 --> 17:12.880 auch bei Flexbox einsetzen. Und ich finde es großartig, weil ich auch gar nicht mehr so 17:12.880 --> 17:20.520 der Riesenfan bin, von Margin zu setzen für Spacings, was jetzt alles angeht von, ja, 17:20.520 --> 17:25.240 nicht unbedingt, es muss nicht mal ein Grid sein, wo es zwei Columns gibt, aber einfach, 17:25.240 --> 17:32.560 ich habe mehrere Elemente, Boxen wie immer untereinander und ich habe da schon gemerkt von 17:32.560 --> 17:37.440 unserem Design Team aus, wollen die da eigentlich immer 16-Pixel-Abstand haben. Also müsste ich 17:37.440 --> 17:42.040 hier jetzt unter alles, da ich Tabeln verwende mit Utility-CSS, müsste ich hier jetzt unter 17:42.040 --> 17:46.960 alles schreiben, Margin-Button von 8, da kommt man sich irgendwie manchmal ein bisschen blöd vor, 17:46.960 --> 17:50.000 wenn man die ganze Zeit Margin-Button 8, Margin-Button 8, Margin-Button 8 schreit und denkt, 17:50.000 --> 17:55.000 ja, es soll dich doch wieder eine Klasse draus machen. Aber ich kann stattdessen ja im Container 17:55.000 --> 18:01.560 drum rum einfach sagen, du weißt, du bist jetzt einfach Flexbox mit der Direktion von Column und 18:01.560 --> 18:06.360 ich gebe dir ein Gap von 8 und fertig. Und das funktioniert, da hat man kein Margin-Collapsing 18:06.360 --> 18:12.920 oder so weiter. Das ist ja angeblich. Nee, das ist auch super praktisch. Der Übergangszeit war 18:12.920 --> 18:20.560 so ein bisschen blöd, dass, also da, es gab ja mal eine Übergangszeit, da gab es Gap nur für Grid, 18:20.560 --> 18:27.520 also du bist ja nicht irgendwie, lagst ja ja nicht falsch, also es war ja auch mal so. Und dann, 18:27.520 --> 18:35.880 genau, da hieß es ja auch noch Grid Gap, glaube ich. Und dann haben die gesagt, so ja, ich glaube, 18:35.880 --> 18:43.440 bei Multicale kann man es auch verwenden. Das haben die sozusagen vereinheitlicht. Aber es gab 18:43.440 --> 18:50.920 eben eine Zeit, da ging es nur für Grid und dann wurde das in den Gap umbenannt und das Problem war, 18:50.920 --> 18:59.280 man konnte den, konnte keinen Feature-Test machen da drauf, weil man konnte dann eben nur auf Gap 18:59.280 --> 19:04.920 testen und Browser, die das für Grid unterstützt haben, aber nicht für Flex haben natürlich gesagt, 19:04.920 --> 19:13.480 so, jo, ich kann das ja. Also man konnte dann nicht so einen Code mit Gap für Flexbox nehmen, 19:13.480 --> 19:18.240 für die Browser, die das können und dann auf was anderes zurückfallen. Und darum habe ich dann auch 19:18.240 --> 19:24.720 mal jetzt, also da noch länger das Gap nicht benutzt, aber mittlerweile kann man das Problem 19:24.720 --> 19:31.920 losmachen. Mein zweiter Lieblingsuse-Case und der ist sogar wahrscheinlich noch praktischer, 19:31.920 --> 19:37.080 ist, wenn es darum geht und jetzt wieder in Verbindung mit Flexbox und nicht mit Grid.css, 19:37.080 --> 19:45.560 wenn ich einen Umbruch habe mit Flexwrap, wenn mein Viewport zu klein wird. Die Situation kommt 19:45.560 --> 19:51.920 relativ häufig vor, dass ich zum Beispiel auf der linken Seite, oder nehmen wir einfach, ich habe 19:51.920 --> 19:58.280 zwei Buttons, den Secondary-Button und den Primary-Button. Und wenn die im genügend Platz haben, 19:58.280 --> 20:04.360 sind die links und rechts nebeneinander und haben dazwischen den Abstand von 10 Pixel. Sobald ich 20:04.360 --> 20:08.720 aber umbreche, wahrscheinlich dann schätze ich mal, das Secondary-Button nach unten und der 20:08.720 --> 20:13.360 Primary-Button, der vorher rechts war, bleibt oben, also vielleicht noch die Order rumdrehen. Dann 20:13.360 --> 20:18.640 will ich ja nicht, dass der obere Button plötzlich einen Margin Left hat oder einen Margin Right 20:18.640 --> 20:23.160 hat von 10 Pixel. Das schaut ja doof aus. Und ich glaube, früher musste ich dann auch irgendwie, 20:23.160 --> 20:27.560 ah, bei dem Breakpoint, dann machst du das und bei dem Breakpoint machst du das. Das funktioniert 20:27.560 --> 20:31.760 aber auch nur, wenn der Text auch wirklich statisch ist und jetzt nicht übersetzt wird und mein 20:31.760 --> 20:37.600 Button dann unterschiedlich lang ist. Oder ich mache eher solche Sachen wie, gut, dann sind die 20:37.600 --> 20:42.280 Buttons jetzt halt Full-Wolf auf Mobile und dann passiert das und das. Aber jetzt auch kann ich 20:42.280 --> 20:47.360 eben das Gap angeben und ich kann das Gap hier horizontal und vertikal unterschiedlich angeben. 20:47.360 --> 20:51.120 Also ich kann sagen, wenn ihr nebeneinander seid, horizontal das Gap, 16 Pixel, wenn ihr 20:51.120 --> 20:59.320 übereinander seid, keine Ahnung, 20 Pixel. Mein Favorit aus der Layout-Section beim CSSW auf 20:59.320 --> 21:06.440 jeden Fall. Ja, das auf jeden Fall auch echt super praktisch. Ansonsten, ja, also du meinst es ja, 21:06.440 --> 21:14.360 es sind halt viele Dinge, die sind, die vergisst du einfach wieder, weil sie eben noch nicht von 21:14.360 --> 21:20.760 allen Browsern unterstützt werden. Also bei manchen ist das auch so. Also zum Beispiel bei mir 21:20.760 --> 21:27.560 fällt es, hier ist jetzt auch Subgrid aufgelistet. Das würde bei mir so da in diese Rubrik fallen, 21:27.560 --> 21:36.680 weil ich mir fällt kein guter Fallback für Subgrid ein und wenn man dann irgendwie zwei Code-Pfade 21:36.680 --> 21:43.440 hat, wenn es dann so kompliziert wird, dann kriegen halt eben alle, denen auch alle verstehen und 21:43.440 --> 21:46.880 dann baue ich jetzt nicht für die, die Subgrid können. Da habe ich auch keinen Performance-Vorteil, 21:46.880 --> 21:52.440 also es ist halt einfach dann, da muss dann nur noch mehr testen. Dann lasse ich das weg, 21:52.440 --> 21:57.520 genau. Und aber manche Dinge kann man halt schön als Progressive Enhancement benutzen, 21:57.520 --> 22:02.880 zum Beispiel hier dieses Content Visibility, das benutze ich ganz gerne, das ist ja so quasi 22:02.880 --> 22:10.720 Lazy-Rendering von Elementen. Die Browser, die das können, die profitieren halt davon, 22:10.720 --> 22:16.560 weil sie am Anfang eben noch nicht alles layouten müssen und die dies nicht können, 22:16.560 --> 22:22.360 die machen einfach das, was sie immer schon gemacht haben. Genau, und Container habe ich 22:22.360 --> 22:27.280 jetzt, also Container Queries habe ich jetzt gerade ins Projekt eingebaut, aber auch da, 22:27.280 --> 22:35.200 so als Progressive Enhancement für so bestimmte Edge-Cases und das ist dann einfach noch, 22:35.200 --> 22:42.360 also bei bestimmten Device-Breiten dann einfach noch ein bisschen harmonischer ist und das ging 22:42.360 --> 22:46.600 halt ganz gut mit der Container Query einfach. Also ich hätte auch Media Queries noch irgendwie 22:46.600 --> 22:54.400 reinwursten können, aber da das eigentlich eher abhängig war von der Größe des Eltern-Elements 22:54.400 --> 23:02.320 bot sich Container an und da habe ich dann einfach so einen, also zu dieser Container, 23:02.320 --> 23:11.240 das ist ja ein Edge Rule, da kommt noch hinzu, was war das, Container Name oder so setzt man dann 23:11.240 --> 23:17.640 oder Container Type und da habe ich einfach eine Feature Query drauf gemacht und gesagt, wenn das 23:17.640 --> 23:23.320 da ist, dann benutzt eben Container Queries und wenn nicht, dann machst du es halt irgendwie so, 23:23.320 --> 23:29.320 indem halt das, was zu groß ist, dann einfach mit negativen Margen in das, was rechts daneben 23:29.320 --> 23:36.040 ist, reinragt und dann ist das halt so. Dann kann das sich halt nicht kleiner machen, weil es das 23:36.040 --> 23:45.160 halt dann nicht mitkriegt. Es gibt dann noch so ein paar Dinge, die bekomme ich eher dadurch mit, 23:45.160 --> 23:52.080 dass mir Stylint zum Beispiel Bescheid sagt, hey, du schreibst da eine altmotische Art und Weise, 23:52.080 --> 24:00.320 wie irgendwas, irgendwas zu beschreiben. Ich hatte es bei RGBA Werten, dass man ja RGBA nicht mehr 24:00.320 --> 24:06.000 schreibt, sondern nur RGB und das Stylinte ist bei mir, die Linter sind generell bei mir eher scharf 24:06.000 --> 24:11.200 eingestellt, hat mir dann gleich auch gesagt, du schreibst doch einfach einen Prozent. Fand 24:11.200 --> 24:18.360 ich jetzt persönlich merkwürdig, so ich fände jetzt 0,2 irgendwie schöner als 20 Prozent, 24:18.360 --> 24:25.040 aber gut. Genau und das, was mir jetzt aufgefallen ist noch bei der Layout Section, 24:25.040 --> 24:31.840 wir haben jetzt auch die neue Art und Weise, wie man Media Ranges schreiben kann, also auch mit der 24:31.840 --> 24:38.920 Edge Rule, Edge Media und dann tatsächlich relativ hübsch geschrieben, 300 Pixel, kleiner, kleiner, 24:38.920 --> 24:45.920 kleiner gleich Worth, kleiner gleich 750 Pixel. Allerdings, wenn ich mich jetzt richtig erinnere, 24:45.920 --> 24:52.640 ging das ja schon immer gefühlt, indem man einfach sagte, mit der Edge Media Rule MinWolf von 300 24:52.640 --> 24:59.800 Pixel und zusätzlich eine Max-Wolf von 750 Pixel, von daher sehe ich das nicht als großes 24:59.800 --> 25:03.920 Feature und ich würde es wahrscheinlich mal mitbekommen, wenn ihr mir das Stylint sagt, 25:03.920 --> 25:08.160 das ist ja noch altmodisch geschrieben, datet das mal ab. Oder weißt du, ob es das noch einen 25:08.160 --> 25:14.800 anderen Vorteil gibt, außer es schaut schöner aus? Ja, so ein Vorteil ist, ich finde bei Media Curries 25:14.800 --> 25:20.560 ist es immer schwierig, vor allem, wenn man auch vielleicht wechselt zwischen Max-Wolts und MinWolts, 25:20.560 --> 25:27.240 dass man quasi genau das genaue Pixel erwischt, wo eben quasi, und das hast du dann durch die 25:27.240 --> 25:32.960 Schreibweise nicht, weil du kannst auch glaube ich auch, also du kannst nicht nur kleiner machen und 25:32.960 --> 25:41.320 größer, sondern eben auch kleiner gleich und größer gleich, also da finde ich das besser. Und ich 25:41.320 --> 25:47.680 glaube, wahrscheinlich ist es auch am Ende liserlicher die neue Schreibweise, aber die wird 25:47.680 --> 25:53.400 glaube ich nur von Firefox unterstützt und das dauert auf jeden Fall noch eine Weile, bis wir 25:53.400 --> 25:57.880 das einsetzen können, weil wenn Browser es nicht verstehen geht es halt einfach kaputt, 25:57.880 --> 26:06.080 da gibt es auch keinen Fallback. Liserlicher, keine Frage sehe ich auch so und ich glaube, 26:06.080 --> 26:14.400 mich zu erinnern, was du meinst, dass ich manchmal verwirrt war, wenn ich jetzt sage und die Max-Wolf 750, 26:14.400 --> 26:22.760 heißt es dann, geht es bis 750 Pixel oder geht es bis 749 Pixel? Ne, das geht dann bis, genau, 26:22.760 --> 26:29.560 geht dann bis inklusive, aber wenn du dann quasi mit der nächsten Media-Curry dann von da aus, also 26:29.560 --> 26:36.600 vom nächsten Pixel aus starten willst, dann musst du da quasi ein Pixel vorher stoppen und das war 26:36.600 --> 26:45.520 irgendwie immer nervig. Ich glaube, du hast aber für mich persönlich jetzt ein viel größeres 26:45.520 --> 26:50.880 Problem angesprochen, das ist die generelle Architektur, sich zu entscheiden mache ich Mobile 26:50.880 --> 26:57.120 First oder mache ich Desktop First, auf was optimiere ich und kann ich mich daran halten, 26:57.120 --> 27:00.840 dass ich tatsächlich zum Beispiel immer sage, ich habe immer alles mit Minowith. Ich weiß, 27:00.840 --> 27:09.960 es gab immer gute Ausreden davon manchmal, gerade dieses, dass ich das unten nur für den 27:09.960 --> 27:14.680 Screen Reader anzeigen möchte, zum Beispiel irgendwelche Labels, die einfach keinen Platz haben 27:14.680 --> 27:19.400 auf meinem Mobile Device gerade oder was heißt ich was und das habe ich dann immer mit Screen 27:19.400 --> 27:24.920 Reader Only gemacht und da brauche ich es ja tatsächlich umgedreht, da brauche ich meistens 27:24.920 --> 27:31.920 auf Mobile Breakpoints jetzt nur für Screen Reader auf Desktop zeigt es einfach normal an und 27:31.920 --> 27:39.680 da musste ich quasi dieses Mobile First wieder umdrehen, so zu sagen. Aber jetzt fällt mir 27:39.680 --> 27:46.120 gerade was auf. Wenn ich jetzt sage, ich habe hier einen Media-Curry und ich lasse den bis 27:46.120 --> 27:54.360 maximal 700 Pixel gehen und ich schreibe mir noch eine Media-Curry und sage ab 600 Pixel. Was hat 27:54.360 --> 28:07.560 denn dann recht? Wer kommt zum Zug? Naja, also wenn ich jetzt bei beiden die Font Size setze 28:07.560 --> 28:17.440 und ich sage bis 700 Pixel möchte ich 12 Pixel Font Size und ab 600 Pixel möchte ich aber 14 28:17.440 --> 28:26.800 Pixel Font Size. Dann gewinnt die Media-Curry, also die die zutreffende Media-Curry, die als 28:26.800 --> 28:40.320 letztes kommt. Der Begründung, dass es immer das späterer CSS ist. Genau, ja. Ich überlege 28:40.320 --> 28:53.040 gerade, ja, doch, genau. Und das müsste dann auch so sein. Ich würde das aber, um da 100 Euro 28:53.040 --> 28:57.800 drauf zu wetten, würde ich es einmal noch mal vorher koden und testen. Aber ich würde auch glauben, 28:57.800 --> 29:08.000 dass wenn die, also dass das auch davon abhängt quasi wo der Ursprung dieser Regel liegt, also 29:08.000 --> 29:16.520 so quasi in dieser CSS-Kaskade gibt es ja so Dinge, die Vorrang haben. Und also das, was ich gerade 29:16.520 --> 29:24.480 gesagt habe, dann auch wieder nur gilt, wenn zum Beispiel beides in den Author-Styles drin ist, 29:24.480 --> 29:31.760 aber wenn das eine in den User-Agent-Styles drin wäre, dann würde das halt einfach Priorität haben. 29:31.760 --> 29:37.800 Da würde ich bei den 100 Euro, denke ich, eigentlich fast mitgehen. Ich würde sonst sagen, dass die 29:37.800 --> 29:42.520 Gegebenheiten sonst identisch sein müssen. Ich hatte jetzt nur überlegt, wenn es zum Beispiel, 29:42.520 --> 29:50.160 wenn man sagt bis 700 Pixel, aber vielleicht ist es genauer, das heißt zwischen 400 und 700, 29:50.160 --> 29:56.960 ob das dann eine höhere Spezifität hat, als wenn es eine Media-Curry gibt, die nur sagt nur ab 600. 29:56.960 --> 30:02.560 Gut, kommen wir mal wieder raus aus dem Thema, wenn wir schon funktionieren. 30:02.560 --> 30:09.080 Geht es ansonsten bei der Layout-Section noch was, was dich vom, was du denkst, da sollte man noch 30:09.080 --> 30:16.440 mal ansprechen? Naja, das ist alles natürlich cool, was da drin ist, weil die haben natürlich nur die 30:16.440 --> 30:23.280 aktuellen Dinge rausgesucht. Logical properties, das schlägt dann die gleiche Kerbe wie diese 30:23.280 --> 30:29.600 Writing-Modes, die benutze ich tatsächlich auch nicht, weil ich einfach, für mich wäre das halt so, 30:29.600 --> 30:35.440 ja, du hast das ganz toll nach Bilderbuch gemacht, dass du irgendwie Inline und Blog benutzt immer 30:35.440 --> 30:43.000 und so, aber manchmal tue ich das auch, weil das vielleicht als Short-Hand cooler ist, aber ich 30:43.000 --> 30:51.240 brauche das halt nicht. Also ich habe nie Seiten, die den Writing-Mode wechseln oder sowas. Der 30:51.240 --> 30:58.320 einzige Use-Case, der mir einfallen würde, sowas zu machen ist, wenn jemand mit Google Translate 30:58.320 --> 31:04.400 Plug-in im Browser eben sich eine Seite übersetzt, kann man ja auch sagen, okay, also aus Accessibility, 31:04.400 --> 31:12.960 Gesichtspunkten stelle ich mich dem nicht in den Weg und Code entsprechend eben mit Block und Inline 31:12.960 --> 31:19.440 und wenn das dann eben eine Rechts- nach Links-Schrift ist, dann kommt halt die Webseite auch klar damit. 31:19.440 --> 31:25.840 Das mache ich aber noch nicht und da kann ich mir auch ein bisschen Arsch über meinen Haupt 31:25.840 --> 31:33.720 vielleicht streuseln. Ansonsten, ja, das sind ja noch neue Viewport-Units, die sind auch ganz 31:33.720 --> 31:38.920 spannend, die lösen so ein paar Probleme, die man halt so auf Mobile Devices hat, mit irgendwelchen 31:38.920 --> 31:45.760 sich beim Scrollen zurückziehenden UI, also Browser Chrome und vielleicht auch, wenn die 31:45.760 --> 31:52.840 Tastatur hochkommt und so Zeugs, aber das braucht man auch nicht immer. Aber da ist es halt schönes 31:52.840 --> 31:58.120 Progressive Enhancement. Ich würde sagen, wir können eigentlich zur nächsten Sektion gehen, 31:58.120 --> 32:04.480 die, wie heißt die? Ich weiß es nicht. Die Shaves and Graphics und die finde ich ganz toll. Da habe 32:04.480 --> 32:14.040 ich nämlich auch tatsächlich Sachen im Einsatz. Das eine ist der Backdrop Filter. Ich möchte jetzt 32:14.040 --> 32:18.240 mathematisch gar nicht versuchen zu erklären, was er genau macht, aber er macht es ziemlich hübsch. 32:18.240 --> 32:26.720 Also er macht so ein bisschen blurry Background und kann einen sehr hübschen Effekt geben bei 32:26.720 --> 32:32.520 Navigationsleisten, die so sticky sind oder irgendwas, was sticky ist und man möchte aber nicht 32:32.520 --> 32:38.800 zu einem einfach nur einen harten Background dahinter haben und dann braucht man ja normalerweise, 32:38.800 --> 32:43.800 macht man noch eine Border-Bottom-Linie oder einen Box-Shadow hin, wenn man es ein bisschen leichter 32:43.800 --> 32:49.480 haben möchte, aber einen zusätzlichen Effekt kann man haben durch den Backdrop Filter. Ich werde 32:49.480 --> 32:55.560 trotzdem ein bisschen vorsichtig den einzusetzen, denn es kann auch sehr schnell sehr schief gehen. 32:55.560 --> 32:59.920 Also das ist so ein bisschen wie bei Instagram-Filtern. Man wängt da so ein bisschen an, 32:59.920 --> 33:04.600 denkt sich, oh, das schaut aber gut aus und dann zieht man den Filter noch weiter hoch und denkt 33:04.600 --> 33:09.480 sich, oh, das sieht ja richtig gut aus und dann schaut man mal wieder, oder schaut jemand anders drauf 33:09.480 --> 33:14.800 und so, das ist sehr kriselig. Was machst du? Da ist ja schrecklich und genau so, da hatte ich auch 33:14.800 --> 33:19.080 das Gefühl, wenn man jetzt zum Beispiel einfach weiß auf weiß macht und man hat hier so ein bisschen 33:19.080 --> 33:25.840 blurry Effekt drin, aber jetzt habe ich ja normalerweise im Heter auch wieder was stehen oder in 33:25.840 --> 33:32.320 diesem Ding, was dann diesen Effekt hat. Man muss auf jeden Fall gucken, dass der Kontrast gut 33:32.320 --> 33:36.880 genug bleibt, dass ich das, was ich wirklich lesen sollte, auch gut lesbar habe und nicht 33:36.880 --> 33:43.600 dann irgendwie meine Grautöne dahinter habe. Vor einiger Zeit ging das noch nicht im Firefox, 33:43.600 --> 33:50.960 zumindest je nachdem, wie weit man da zurück supporten möchte und da hatte ich dann noch einen 33:50.960 --> 33:57.640 Check drinnen, ob der Backdrop Filter vorhanden ist, aber mit dem sehr leichten Fallback, 33:57.640 --> 34:02.240 wenn das nicht supportet wird, dann mache ich halt einfach einen weißen Hintergrund, dann 34:02.240 --> 34:09.400 voll weißen und wenn supportet wird, dann mache ich ein bisschen blur drauf. Sehr schick. Ja, 34:09.400 --> 34:17.200 genau, es sind im Prinzip die Filter, die man ja auch also so kennt und hat schon seit einigen 34:17.200 --> 34:24.640 Jahren, wo man sagen kann, also genau, damit filter ich nicht das Objekt selber, sondern 34:24.640 --> 34:31.440 der Hintergrund, der so dadurch sichtbar ist, der wird so gefiltert und dann wahlweise geblört 34:31.440 --> 34:37.800 oder entsättigt oder was auch immer. Total schön auch, finde ich, als Text auf Bildern. Weil das 34:37.800 --> 34:43.720 fand ich immer sehr schwierig, gerade wenn es irgendwie erst so eine Produkt- und Design-Idee 34:43.720 --> 34:49.640 war und da hat man dieses perfekte Bild mit dem perfekten Text drauf und der perfekten Länge 34:49.640 --> 34:55.200 und du siehst schon kommen, aber was machen wir, wenn da jetzt dynamische Bilder hochgeladen 34:55.200 --> 34:59.560 werden können, dass wir dann weiß, wie sollen wir das rausfinden, dass wir dann schwarzen Text 34:59.560 --> 35:05.560 auf weiß machen, aber das ist dann einfach so ein richtiger Einzeiler zu schreiben. Ich mache 35:05.560 --> 35:11.360 halt einen Text, der ist von dem Container her auf der vollen Breite und sagt, ich geb dir einfach 35:11.360 --> 35:19.360 einen Backdrop-Filter und dann bist du Aprilary und Schatz ist super cool, finde ich. Ja, das sind 35:19.360 --> 35:27.240 ja eh so, genau so Blend-Modes, Filter-Effekte, Backdrop-Filter, das ist ja alles so richtig, 35:27.240 --> 35:35.160 richtig coole Gimmicks, aber wie du sagst, genau, man muss halt immer, also man neigt dazu beim 35:35.160 --> 35:41.360 ersten Mal immer so in die vollen zu gehen und so wie bei Animationen, finde ich auch, also die, 35:41.360 --> 35:50.200 da ist am Ende dann doch eigentlich immer cooler, also wenn man die zurückschraubt. Ein bisschen, 35:50.200 --> 35:54.520 also so ist das früher auch immer mit diesem Blockbuster-Film gewesen, immer wenn die dann so 35:54.520 --> 35:59.120 cool, jetzt kann man beim Computer irgendwie Vulkanausbruch machen und cool, jetzt kann man 35:59.120 --> 36:04.440 Kometen auf die Erde drauf glatschen lassen und dann muss das alles mal gemacht werden und dann 36:04.440 --> 36:09.560 haben wir aber alle danach gesagt so, hier kommen Roland Emmerich, es ist ein bisschen zu viel, 36:09.560 --> 36:13.800 lass uns mal wieder so, lass uns jetzt, jetzt haben wir uns ausgeturbt und jetzt lass uns so die 36:13.800 --> 36:19.760 Sachen einfach so ein bisschen unterschwelliger einbauen, dass sie nicht so in your face dann 36:19.760 --> 36:26.440 daherkommen. Da muss ich ja sagen, da finde ich Star Wars schon ziemlich genial, so die 36:26.440 --> 36:32.520 richtig alten Filme bei Star Wars, ich finde es ist einfach, also vielleicht haben jetzt viele Leute 36:32.520 --> 36:38.400 eine sehr andere Meinung, aber ich finde es ist großartig gealtert mit dem Pew Pew Pew. Und das 36:38.400 --> 36:43.640 kann ich mir immer wieder anschauen, im Gegensatz dazu schaue ich mir manche doch je nachdem, 36:43.640 --> 36:49.640 wie man es jetzt einschätzen möchte, mittelalte Filme an und dann sehe ich da wie so eine 36:49.640 --> 36:56.840 Explosion und Feuer und das schaut einfach schrecklich aus. Ja, die hast du richtig. Und 36:56.840 --> 37:01.400 gerade gerade mit dem aktuellen CGI, es schaut halt trotzdem immer noch nur gut aus, 37:01.400 --> 37:08.480 wenn sie auf genügend Budget haben, aber dann dieses dieses schlechte CGI, wenn nicht so viel 37:08.480 --> 37:14.120 Geld reingesteckt wird. Da muss ich sagen, satt es doch damals, wo Leute, und das hoffentlich 37:14.120 --> 37:17.320 müssen sie eben nicht mehr machen, da ein stundenlang in der Maske sitzen, um sich grün 37:17.320 --> 37:26.200 anmalen zu lassen, aber es sah besser aus als dieses Pseudokrün. Ich spiele gerade auf Skihike an, 37:26.200 --> 37:31.560 was ist natürlich für mich großartig, großartige Serie, deswegen will ich eigentlich gar nicht 37:31.560 --> 37:42.200 schlechtes darüber sagen. Die ist gut, die kannst du empfehlen. Sehr kontrovers, großartig. 37:42.200 --> 37:48.880 Okay, ich finde so die Hike-Figur, die ist jetzt nicht so meine und damit... Das hat gar 37:48.880 --> 37:54.880 nichts mehr mit Hike zu tun. Da kam mein Mann zu mir und hat gesagt, das müssen wir, 37:54.880 --> 37:59.840 das musst du anschauen, das muss für dich so was los. Ja, das Vogue, ich habe gelesen, 37:59.840 --> 38:05.080 ich habe auch Bilder gelesen, das Vogue, und es geht tatsächlich gar nicht mal so viel um Hike 38:05.080 --> 38:13.360 oder Marvel, es ist doch, es ist ja Netflix, so, ist jetzt inklusiv und so. Haben sie natürlich 38:13.360 --> 38:20.760 etliche Leute natürlich extrem drüber aufgeregt, ist hier alles schrecklich und so, ja, aber ich 38:20.760 --> 38:31.200 große Fan. Gut, zurück zu CSS. Bei den Shapes gibt es auch noch ein anderes Antibut vom Bereich 38:31.200 --> 38:39.040 intrinsic sizing. Ich meine, das klingt ja schon total smooth, ne, intrinsic sizing. Und da gibt's 38:39.040 --> 38:45.200 die Einstellung fit content für die With, wo ich noch nie drüber nachgedacht habe, 38:45.200 --> 38:50.720 dass ich es brauchen könnte. Seit ich aber weiß, dass es es gibt, will ich es unbedingt überall 38:50.720 --> 38:56.200 einsetzen. Leider immer noch irgendwie begrinst, was mir einfällt, was ich jetzt damit tun könnte. 38:56.200 --> 39:01.000 Manchmal probiere ich es aus, ob ich damit vielleicht irgendwie was von Flexbox sizing fixen 39:01.000 --> 39:06.360 könnte, aber es geht trotzdem nicht. Dennoch mit fit content kann ich den Container um einen 39:06.360 --> 39:11.600 Textblock herum, also zum Beispiel über eine Headline, die ja generell im Blog ausgerichtet 39:11.600 --> 39:20.280 wird, auf den Content runter reduzieren. Beispiel, ich habe jetzt eine Überschrift und ich würde 39:20.280 --> 39:26.880 jetzt behaupten, oder ich würde jetzt eine Hintergrundfarbe runterlegen, dann werde ich auf der 39:26.880 --> 39:36.080 vollen Breite. Und auch hier mit diesem Einseiler zu sagen, Headline with fit content, ist es dann 39:36.080 --> 39:41.080 genau meine Hintergrundfarbe nur hinter dem Text und jetzt wirklich ganz dynamisch wie der Text 39:41.080 --> 39:50.360 ist. Und relativ mächtig, wenn man Use Cases dafür hat. Ja, ist auf jeden Fall cool, habe 39:50.360 --> 39:58.600 ich aber selber auch tatsächlich eher selten Use Cases dafür. Aber genau, es ist praktisch. Also, 39:58.600 --> 40:06.200 man kann auch damit mal irgendwie, wenn man Block Level Elemente irgendwie zentrieren will, 40:06.200 --> 40:12.400 das ist halt ganz gut, weil dann kann man, also ohne dass man, genau ohne dass man sich da auch 40:12.400 --> 40:17.880 verlassen möchte, also wenn du jetzt quasi ein Komponenten basiert denkst und du willst halt 40:17.880 --> 40:23.960 eine Komponente machen, die aber immer ein Block ist und die horizontal zentriert ist, 40:23.960 --> 40:29.040 also dann geht das ja nicht. Also kannst dann irgendwie Inline-Block machen und dann muss 40:29.040 --> 40:33.640 aber trotzdem das Außenrum müsste dann Text-Eleign-Center haben oder du nimmst halt Flex oder 40:33.640 --> 40:37.920 Grid, aber dafür muss halt auch das Außenrum mitspielen und wenn das halt kein Flex und Grid 40:37.920 --> 40:44.480 ist, dann ist es schon wieder, geht es schon nicht mehr und da kannst du dann eben sagen Fit Content 40:44.480 --> 40:52.280 und Margin Left und Right oder Margin Inline Auto und dann zentriert sich das horizontal. 40:52.280 --> 40:58.320 Weil es geht halt nur, wenn du eine Widz angibst. Aber durch das Fit Content hast du halt eine 40:58.320 --> 41:06.440 Widz angegeben, aber sie ist trotzdem eben die Schnur sozusagen zusammen auf die Breite des 41:06.440 --> 41:15.360 jetzt in dem Fall Textes da drin oder so. Und Fit Content ist auch nicht das Einzige, sondern es 41:15.360 --> 41:20.880 gäbe auch noch Min-Content und Max-Content. Leider finde ich dafür noch weniger Anwendungsfälle. 41:20.880 --> 41:27.440 Wenn man es braucht, ist es wahrscheinlich großartig. Also bei Max-Content kann ich ja 41:27.440 --> 41:32.040 tatsächlich, wenn ich mich richtig erinnere, aus meinem Container ausbrechen, dass ich sage, 41:32.040 --> 41:38.560 ich bin im Container, der hat 300 Pixel Breite und ich möchte jetzt aber sagen, ist mir egal, 41:38.560 --> 41:43.520 ich möchte, dass mein Text, wenn er länger ist, trotzdem einfach ausbricht, kann ich dann 41:43.520 --> 41:50.560 meinem Textparagraphen sagen, du hast eine Breite von Max-Content, egal ob du eigentlich Platz 41:50.560 --> 41:55.200 hast oder nicht und dann so lang wie der Text ist, geht dann auch wirklich der Text weiter, 41:55.200 --> 42:00.840 ohne dass er jetzt einen Zeilenumbruch macht. Ja, mir fällt ein, ich hatte, glaube ich, 42:00.840 --> 42:08.640 irgendwann in Chrome, hatte ich einen Back erzeugt, weil ich nämlich, ich glaube, 42:08.640 --> 42:16.200 ich hatte Firstline, hatte ich verwendet und Fit Content zugleich und der hat das halt in der 42:16.200 --> 42:24.600 falschen Reihenfolge ausgerechnet und hat dann ersten Fit Content gemacht und die Firstline 42:24.600 --> 42:32.240 ist ja sozusagen, die ergibt sich ja, also ich weiß nicht mehr genau wie das war, aber das war, 42:32.240 --> 42:37.920 glaube ich, so ein Intrinsic Sizing, aber die und die Firstline, also wie viel das ist, 42:37.920 --> 42:43.600 ergibt sich ja aus der Breite des Containers, in dem der Text steht. Genau und diese Firstline 42:43.600 --> 42:50.400 habe ich gestylt, aber irgendwie klappte das hinten und vorne nicht, weil der eben das irgendwie 42:50.400 --> 42:54.080 falsch rum ausgerechnet hatte und die Schrift war dann irgendwie größer und die hat dann auch wieder 42:54.080 --> 42:58.800 irgendwas auseinander gedrückt, also da habe ich auf jeden Fall den Browser übel zugesetzt und 42:58.800 --> 43:05.280 dann auch den Rückzug angetreten und auch eingesehen, dass das vielleicht auch so ein 43:05.280 --> 43:17.480 bisschen edgekäsig war von mir. Genau, soll man zu Color springen? Denn auch bei Color gibt es für 43:17.480 --> 43:24.680 mich zwei Highlights und das eine davon ist Accent Color und das war ein Beispiel, das habe 43:24.680 --> 43:29.800 ich gehört, ich wusste, das kann ich jetzt eh noch überhaupt nicht benutzen, aber da war ich so 43:29.800 --> 43:34.040 kleines Kind, hat auch Weihnachten gewartet, aber wann kann ich es benutzen, da wann kann ich es 43:34.040 --> 43:39.800 benutzen, da wann kann ich es benutzen, da wir wahrscheinlich alle die Situation kennen, Checkboxen 43:39.800 --> 43:46.480 und Radio Buttons zu stylen und es schon fast ein bisschen peinlich für mich irgendwann wurde 43:46.480 --> 43:50.520 zu erklären, das ist jetzt sehr kompliziert und ich brauche ein großes Ticket und wir müssen 43:50.520 --> 43:54.720 das überall testen und können wir nicht einfach, können wir nicht die ganze Webseite einfach blau 43:54.720 --> 44:02.120 machen, dann haben wir kein Problem mehr und mit Accent Color kann man jetzt der Checkbox und 44:02.120 --> 44:10.720 solchen ähnlichen Elementen eine eigene Background Color geben. Super, es ist super, 44:10.720 --> 44:16.680 keine Polyfills mehr, keine komischen Frameworks, keine Überschreibungen, wie war das Display 44:16.680 --> 44:20.600 hitten, nee, wir seh bitte die hitten Display nannen und stattdessen ein Bild hingemalt, 44:20.600 --> 44:29.760 Bild hingemalt haben wir, gell? Ja, also genau, man kann natürlich jetzt nicht alles umsteilen, 44:29.760 --> 44:39.160 sondern wirklich nur so quasi so die Farbwelt einstellen, der Inputs und immer da, wo die 44:39.160 --> 44:44.160 quasi irgendeine Farbe aufgreifen, dann entscheiden die sich dann eben für diese Accent Color, 44:44.160 --> 44:51.600 die dann vielleicht irgendwie zur Brand passt. Ja, aber der Check-Icon ist der Check-Icon, 44:51.600 --> 44:55.840 die Größe ist die Größe, Border Radius ist, weiß ich gar nicht. Man kommt schon relativ weit 44:55.840 --> 45:02.680 damit, ja. Aber die Farbe macht so, ich glaube, 80 Prozent von dem, was man da eigentlich erreichen 45:02.680 --> 45:05.760 möchte und dann wäre es wahrscheinlich schon eine Diskussion, wer brauchen wir jetzt wirklich den 45:05.760 --> 45:10.800 ganzen Hickack noch, um das perfekt zu machen oder reicht nicht einfach diese 80 Prozent gute 45:10.800 --> 45:15.880 Lösung, wo wir nur eine Reihe geschrieben müssen? Wenn man so den agilen Ansatz hat, 45:15.880 --> 45:21.560 dann kann man ja sagen, okay, das ist jetzt sozusagen die erste Ausbaustufe, mit der kann 45:21.560 --> 45:29.080 man schon gut arbeiten und wenn wir dann irgendwann merken, wir haben Zeit und Budget und uns ist 45:29.080 --> 45:36.200 das sehr wichtig, dann gehen wir da nochmal drüber und machen es dann, bauen es dann aus. Ich 45:36.200 --> 45:40.840 glaube, das wird auch von allen Browser mittlerweile unterstützt. Ich glaube, das ist auch Teil dieser 45:40.840 --> 45:46.840 Interop-Geschichte, wo die Browser erstellt, dass sich irgendwie alle, ich weiß nicht von diesem 45:46.840 --> 45:51.400 Jahr oder vom letzten Jahr, wo die sich irgendwie alle committed haben, so eine bestimmte Reihe an 45:51.400 --> 45:58.200 Dingen, eben alle zu supporten, damit Entwicklerinnen und Entwickler nicht immer so, also weniger zu 45:58.200 --> 46:03.600 kämpfen haben mit, hey, der Browser kann das und der andere kann aber dafür was ganz anderes, 46:03.600 --> 46:10.440 das kann aber der erste nicht und so, sondern okay, die Sachen sind praktisch, die setzen 46:10.440 --> 46:15.800 oder die implementieren die dann alle. Ja, ich denke, so ein bisschen das Problem war dann auch, 46:15.800 --> 46:23.560 der Safari war es erst ab 15.4, soweit ich weiß, was dabei ist und ich glaube, wir haben gerade 46:23.560 --> 46:38.880 erst 15.5 und Macbook-User ja normalerweise beim Safari, das wird schon alles irgendwie geupdatet, 46:38.880 --> 46:42.920 es ist nicht so wie damals, wo man noch irgendwie noch Internet Explorer sonst was supporten musste, 46:42.920 --> 46:48.520 weil irgendjemand durfte sein, Windows nicht upgrading, aber 15.4 ist schon echt relativ 46:48.520 --> 46:53.880 spät, also ich glaube, ich habe da auch bei mir im Analytics noch einige 15.3 und sowas dabei, 46:53.880 --> 47:00.320 allerdings gar nicht so schlimm, weil es passiert ja nichts, wenn nichts supportet ist. Also im 47:00.320 --> 47:04.160 schlimmsten Fall hat der Browser dann halt irgendwie die Default-Kalab, es geht ja nichts kaputt, 47:04.160 --> 47:09.520 von daher werde ich es für mich immer so mit ins Risiko einzubeziehen, was passiert überhaupt, 47:09.520 --> 47:14.920 wenn es nicht supportet wird, ist kaputt oder ist halt nur nicht super? Ja, ist halt nur blöd, 47:14.920 --> 47:21.680 wenn dann der Chef oder der Kunde, der der Chef des Kunden oder so genau diese Browser-System hat, 47:21.680 --> 47:28.240 dann ist ja immer ganz schlimm. Stimmt alle Google Chrome. Genau, aber du hast gesagt, 47:28.240 --> 47:35.360 du hast zwei Sachen, die du gut findest aus dieser Ecke? Ja, kurz und zu Exenkeller, am meisten setze 47:35.360 --> 47:40.400 ich es tatsächlich ein bei Prototypen oder Workshops oder sonst was, wo man sehr gerne irgendwie 47:40.400 --> 47:46.600 Beispiele hat, ich brauche eine Liste und ich habe halt jetzt keine Fancy Liste mit Special 47:46.600 --> 47:50.480 Bildern und Drag and Drop und sonst was, ich brauche irgendwie eine Liste und da macht es einen 47:50.480 --> 47:58.680 riesen Effekt wirklich, wenn ich da die Exenkeller einsetzen kann für so ein Prototyp, weil das Auge 47:58.680 --> 48:02.600 entscheidet ja mit und das zweite ist, das finde ich jetzt spannend und da musst du mich vielleicht 48:02.600 --> 48:10.160 aufklären, weil hier steht Current Color 2022 und Current Color ist so mein Liebling natürlich 48:10.160 --> 48:19.680 bei SVG, aber was ist Current Color Version 2022? Das ist eine sehr gute Frage. Kann das was anderes 48:19.680 --> 48:24.080 oder können wir jetzt vielleicht Current Color wo einsetzen, wo wir das davor noch nicht einsetzen 48:24.080 --> 48:34.440 konnten? Das mal schauen, also den Beispielen wird ja auch gar nichts, also für mich sieht 48:34.440 --> 48:45.400 das aus wie das Current Color. Ja, aber der Böppel ist da dran. Ah, oder? Nee. Okay, also ich hatte 48:45.400 --> 48:53.640 jetzt gerade kurz gedacht, also Current Color ist ja quasi so eine Art in Browser schon lange 48:53.640 --> 49:00.800 vorhandene Custom Property, die die aktuell eingestellte Textfarbe sozusagen widerspiegelt 49:00.800 --> 49:06.120 und das ist sehr praktisch und die wird ja auch implizit immer angewendet, also wenn wir jetzt zum 49:06.120 --> 49:13.280 Beispiel bei Bordern nur sagen würde 1px solid und keine Farbe definiert, dann ergänzt der Browser 49:13.280 --> 49:21.160 ja automatisch, dass die Farbe eben Current Color sein soll, also dann ist das die eingestellte 49:21.160 --> 49:27.120 Textfarbe. Es ist die eingestellte Textfarbe, also ich sehe hier gerade noch ein Beispiel, wo steht, 49:27.120 --> 49:36.280 dass die Color ist blue und danach ist der Background Current Color. Dann würdest du dann 49:36.280 --> 49:44.480 nichts mehr lesen können, weil blau auf blau dann in dem Fall, genau. Also ich weiß leider nicht 49:44.480 --> 49:51.600 genau, was dran neu ist, würde mich interessieren, aber es ist irrelevant, ob es die 2022 Variante 49:51.600 --> 50:00.840 ist oder die die Alter-Tümliche. Ich finde, ich ist so ein Hittenfeature von CSS, das ein bisschen 50:00.840 --> 50:07.360 unterschätzt wird, da ich das extrem gerne einsetz mit der Current Color mache. Ich mache 50:07.360 --> 50:12.800 auch gerne. Gerade super, ja gerade super und weitertänkt in verschiedenen Color-Schemes, 50:12.800 --> 50:17.400 dass du halt nicht zum Beispiel geht, dass man sagt, ich möchte meine Primary, ich möchte meine 50:17.400 --> 50:22.200 Primary oder ich möchte meine Grau-Hundert, meine Grau-Hundert, sondern einfach ich möchte halt 50:22.200 --> 50:27.800 meine Current Color, die ist hier gesetzt und es funktioniert wunderbar. Ja, ja auch für so Ghost 50:27.800 --> 50:32.920 Buttons halt super, die die so den Border in der gleichen Farbe haben sollen wieder Text und so, 50:32.920 --> 50:40.840 genau. Also mir ist ein Einfall gekommen, was jetzt neu daran sein könnte. Current Color ist 50:40.840 --> 50:47.960 quasi eins von, es gibt so eine, glaube ich, eine Webseite, da sind so CSS Mistakes aufgelistet 50:47.960 --> 50:54.600 und also die Pflege, glaube ich, die CSS Working Group und das ist auch ganz interessant, das mal 50:54.600 --> 51:02.520 zu einfach mal durchzugucken und was bei Current Color das Problem ist, aus deren Sicht ist dieses 51:02.520 --> 51:10.600 Camel Case, das ist eigentlich nicht üblich für CSS und ich glaube, dass was, also dieses Label... 51:10.600 --> 51:16.000 Aber man kann es klein schreiben. So Current Color zusammen ohne großes T. 51:16.000 --> 51:22.280 Ich habe es, ich habe es noch nicht ausprobiert, ich glaube früher konnte man es nicht und das ist 51:22.280 --> 51:30.280 das Neue, das ist quasi so wie bei RGB und RGB, also RGBA und RGB, dass das sozusagen repariert wird 51:30.280 --> 51:38.000 und man alias hat jetzt, also der so funktioniert, wie man das also immer wollte und genau das andere 51:38.000 --> 51:44.400 mit Camel Case wird wahrscheinlich immer supported bleiben, aber vielleicht wird das nicht mehr 51:44.400 --> 51:50.160 weiter kolportiert und dann ist alles so aus einem Guss. Das ist ja großartig, jetzt finde ich es aber 51:50.160 --> 51:54.920 noch mitzüge bei dem CSS Survey, mal schauen, ob das noch geandert wird. Also es steht tatsächlich 51:54.920 --> 52:03.560 Current Color in Voll-Lower-Case da mit 2022 und dem Code-By-Spiel steht aber Current Color mit 52:03.560 --> 52:10.440 großen C. Vielleicht war das dann nur so aus einem Muscle-Memory. Ja und das ist natürlich auch, ich 52:10.440 --> 52:15.960 weiß nicht, ob das Leute dann, ob die das realisieren, weil es ist ja wirklich ohne Erklärung hier, 52:15.960 --> 52:22.680 also selbst wir sind jetzt ja nicht so ganz direkt draufgekommen. Ich habe gesehen, 52:22.680 --> 52:28.560 dass es klein geschrieben wird, aber ich dachte, das kann ja nicht die große Neuerung sein. Ja gut, 52:28.560 --> 52:33.840 ich hoffe, es hat manche Leute sehr glücklich gemacht, dass jetzt korrekt ist. Ich kann das 52:33.840 --> 52:39.160 nachvollziehen. Ich freue mich jetzt einfach darüber, dass vielleicht dadurch die Current Color 52:39.160 --> 52:43.120 nochmal ein bisschen Aufschwung erlebt, damit man nochmal daran erinnert wird, dass es ja dieses 52:43.120 --> 52:50.760 sehr, sehr mächtige Feature gibt. Ansonsten, was ich nämlich auf der Seite sehe, ist das, 52:50.760 --> 52:55.640 was ich wieder mehr bezeichne, als es sind für mich dann eher Spielereien, die ich selten brauche, 52:55.640 --> 53:00.600 liegt wahrscheinlich auch einfach dran, dass ich beruflich halt immer einfach nur Designs 53:00.600 --> 53:06.800 umsetzen muss und nichts Kreative selber leisten muss. Ich sehe jetzt hier die Gradients, 53:06.800 --> 53:15.600 irgendwelche Dinge, die ich noch nie gehört habe, White Garmood Colors. Ja, das ist im Prinzip 53:15.600 --> 53:25.440 High Dynamic Range auch im Browser. Also RGB ist einfach begrenzt, indem man dann Farben 53:25.440 --> 53:30.080 ausdrücken kann und die Technik ist ja jetzt weiter. Also vor allem bei den Fernsehren kennt 53:30.080 --> 53:38.080 man das ja und man kann jetzt eben in andere Farbspaces gehen, die erst mal weiter sind, 53:38.080 --> 53:46.600 zum anderen sind hier aber auch ähnlich wie MP3 eher danach modelliert, wie du siehst und nicht 53:46.600 --> 53:53.440 so mathematisch. Und das, also weil es gibt so bestimmte Unzulänglichkeiten, zum Beispiel 53:53.440 --> 54:00.720 grün Töne, gibt es einfach viel zu wenig im RGB Raum und das kannst du halt lösen und 54:00.720 --> 54:06.480 die sind einfach ein bisschen knackiger und du hast halt auch dann nicht mehr dieses klassische 54:06.480 --> 54:11.480 Farbrat, was man kennt, weil also wenn du jetzt normalerweise einen Color Pick hast, hast du 54:11.480 --> 54:15.960 immer so einen Farbrat und dann gehen die Regenbogenfarben einmal außen rum und in der Mitte 54:15.960 --> 54:24.000 ist es ja dann in der Regel weiß oder so oder eben endsättigt und da hast du ja auch so ein 54:24.000 --> 54:28.520 bisschen das Problem manchmal, je nachdem, wenn du einen Gradient machst von einer bestimmten Farbe 54:28.520 --> 54:34.160 zu einer anderen, dann rechnet der Browser das auch so, dass tatsächlich eine gerade Linie 54:34.160 --> 54:40.080 durch diesen Kreis zieht und wenn du Pech hast, gehst du halt genau durch diese endsättigten Zone 54:40.080 --> 54:46.280 in der Mitte oder nah dran und dann sieht dein Gradient am Anfang gut aus, sondern am Ende 54:46.280 --> 54:50.840 gut aus, aber in der Mitte sieht der halt scheiße aus. Der sieht dann irgendwie, es ist einfach nur 54:50.840 --> 54:57.320 so eine dreckige Farbe, irgendwie keine Kuhle und wenn du, du kannst dann eben den den Farbraum 54:57.320 --> 55:05.160 wechseln, beim Gradient zeichnen und die anderen Farbräume haben halt nicht diese Eigenschaft 55:05.160 --> 55:13.040 und dann geht eben diese, quasi dieser Verlauf durchwandert eben einfach so nur knackige Farben 55:13.040 --> 55:20.520 und dann ist der einfach schöner so, dass es so ein bisschen was dahinter steckt. Genau und dann 55:20.520 --> 55:27.720 gibt es noch dieses Relative Colors, das ist so eine Farbfunktion, wo du quasi Farben aus anderen 55:27.720 --> 55:34.560 Farben leichter ableiten kannst, also dass du sagst, ich will die irgendwie den Roton und 55:34.560 --> 55:41.880 dessen Sättigung ungefähr haben, aber ich ändere die Helligkeit und dann kannst du dir eben eine 55:41.880 --> 55:49.200 Farbe schnappen, aus einem Custom Property zum Beispiel und die dann quasi in heller und dunkleren 55:49.200 --> 55:57.280 Nuancen umrechnen. Aber das ist, glaube ich, das mit den erwarteten Farbräumen, das gibt es ja 55:57.280 --> 56:02.000 jetzt schon so ein bisschen, also auf jeden Fall in Safari, in einem Browser bin ich mir nicht so 56:02.000 --> 56:10.840 ganz sicher und genau diese Farbfunktionen, die alle noch kommen, da arbeitet ja der Adam Argyle 56:10.840 --> 56:15.840 auch mit dran. Ich glaube, da müssen wir noch so ein bisschen warten, genau, aber die sind auch 56:15.840 --> 56:24.280 echt spannend. Ja, das wäre wahrscheinlich sogar den Punkt, sobald es unterstützt wird, wo wir 56:24.280 --> 56:29.960 als Entwickler, Entwicklerinnen auf unserer Design Team drauf zukommen können und sagen, hey, 56:29.960 --> 56:37.200 jetzt schau es mal, was da jetzt ein neuer Ding ist, alles möglich ist. Genau, aber das muss man 56:37.200 --> 56:40.960 testen, dann brauchen wir natürlich alle diese tollen Bildschirme und wir brauchen aber eigentlich 56:40.960 --> 56:47.400 auch, wenn wir es ganz korrekt machen, brauchen wir ja auch die Kackbildschirme, weil es ja so, 56:47.400 --> 56:55.200 wie sieht das halt einen Normallohn, der sich eben nicht so ein super Apple-Cinema-Display 56:55.200 --> 57:04.400 Eumel leisten kann. Ja, aber da gibt es ja schon so Sachen wie, ich glaube, mit generell die 57:04.400 --> 57:10.400 Berechnungen, was da alles jetzt möglich ist. Aber einfach mal auf die Zeit geguckt, würde ich mal zu 57:10.400 --> 57:16.560 den Interactions weitergehen. Ja, wir können auch zwei Teile draus machen. Ja, ja, machen wir sowieso, 57:16.560 --> 57:23.160 sonst sind wir hier noch zwei Stunden. Aber die Interaktionen, die haben ja so ein bisschen ja 57:23.160 --> 57:29.280 schon am Anfang angesprochen, weil dank des CSS-Kaffees heute kann ich da jetzt überall anhaken, 57:29.280 --> 57:37.960 habe ich ja alle schon gehört. Kenne ich. Kenne ich natürlich. Das Scroll Snap kennt man ja, 57:37.960 --> 57:43.440 hat man bestimmt schon mal so gehört, vielleicht nicht so wirklich selber eingesetzt, sondern 57:43.440 --> 57:50.440 irgendwie noch in so einem Karussell-Pluckin, das verwendet das dann eben. Da sind aber doch 57:50.440 --> 57:56.560 jetzt paar spannende Sachen dabei, über die ich so noch nicht ganz nachgedacht habe, wie zum 57:56.560 --> 58:03.240 Beispiel bei dem Scroll Snap-Type, das ich tatsächlich angeben kann, ob mandatory oder 58:03.240 --> 58:13.720 das andere. Proximativer das andere. Also für freiwillig oder verpflichtend. Ja. Und dann habe ich. 58:13.720 --> 58:18.800 Ob der immer snapen soll oder nur, wenn so ein Snap-Point irgendwie so in greifbar an hier ist, 58:18.800 --> 58:24.440 dass er den dann sich zu sich zieht und den dann einrastet. Ja, aber wo ich eben dann überlegt 58:24.440 --> 58:32.680 habe, mir würden wahrscheinlich Situationen für beide Sachen einfallen, wo das in Vollwerge war, 58:32.680 --> 58:37.640 eigentlich dachte ich erst, uu, verpflichtend klingt eher schlecht. Das kommt aber von sehr, 58:37.640 --> 58:42.520 sehr, sehr vielen schlechten Erfahrungen von Webseiten, die der Meinung sind, sie müssten 58:42.520 --> 58:48.120 meinen Scrolling-Behavior ändern, um mich auf einer Webseite sozusagen von slide zu slide, 58:48.120 --> 58:54.760 oder von slide, das ist schrecklich. Bitte, bitte, nehmt mir nicht meinen Scrolling-Behavior weg. 58:54.760 --> 59:00.240 Ich will den Text da lesen. Allerdings jetzt bei diversen Beispielen kann es, glaube ich, 59:00.240 --> 59:05.800 wirklich sehr cool werden, dass man auch sagt, okay, du musst jetzt irgendwie dahin pinchen. Und die 59:05.800 --> 59:12.680 Sachen, die ich heute gesehen habe, das waren ja, das war mir gar nicht vorher bewusst, 59:12.680 --> 59:17.440 dass wir jetzt tatsächlich bei Webseiten ja wirklich so eine Native-Behavior auf mobilen 59:17.440 --> 59:22.440 Endgeräten schaffen können, dass ich, ich habe, ich habe eine Liste von Elementen, 59:22.440 --> 59:27.360 habe ich irgendwie schön als Boxen markiert, sind auf Mobile alle untereinander, Platz für 59:27.360 --> 59:33.040 zwei nebenan, dann wäre ich nicht da. Und ich kann jetzt diese Geste machen, dass ich von rechts 59:33.040 --> 59:38.880 nach links wische, um zum Beispiel so einen roten Löschenanteil, einen Kartenanteil zu zeigen, 59:38.880 --> 59:43.640 wo ich dann eben schön snapen kann, dass ich sage, ich habe es jetzt schon ein bisschen 59:43.640 --> 59:47.680 rausgetrigger, jetzt möchte ich auch, dass ich den ganzen löschen Button sehe, egal ob ich jetzt 59:47.680 --> 59:53.680 als User meinen Finger noch weiter bewege oder nicht. Und genauso wie die Seite zu updateen, 59:53.680 --> 59:58.360 kennt man wahrscheinlich von Android, iOS auswendig, dass ich da einfach so nach oben drücken muss und 59:58.360 --> 01:00:03.520 das datet sich ab. Und diesen Effekt können wir auch machen, dass wir so einen noch einen unsichtbaren 01:00:03.520 --> 01:00:07.960 Bereich über unsere Webseite haben und wenn ich den so runterziehe, dass ich dann ein Loading-Spinner 01:00:07.960 --> 01:00:14.160 habe und gleichzeitig einen Updater für irgendwas starten kann. Unfassbar mächtig, also wenn da 01:00:14.160 --> 01:00:21.360 draußen gerade irgendjemand so mobile-only-Seiten macht, einsetzen, so cool, so richtig cool. 01:00:21.360 --> 01:00:28.560 Verliegen wir auf jeden Fall auch den Talk, also den, den hat er auch schon beim CSS-Thema gemacht, 01:00:28.560 --> 01:00:36.880 also und das CSS-Café, da hauen wir den auch noch raus, super inspirierend. 01:00:36.880 --> 01:00:43.160 Ja und ich denke, es ist eben wichtig, da gute Beispiele zu sehen, weil ansonsten, wenn ich jetzt 01:00:43.160 --> 01:00:47.920 hier bei dem Server bin, das sehe ich scroll-snap-types, scroll-snap-aligned, scroll-padding, 01:00:47.920 --> 01:00:56.080 over-scroll-behavior, why. Die Sachen alleine, wenn ich jetzt jedes CSS-Attribut alleine durchlese, 01:00:56.080 --> 01:01:01.680 verstehe ich noch nicht, welche Möglichkeiten mir das erübrigen sollen. Es ist dann doch 01:01:01.680 --> 01:01:05.520 schon, dass ich manche Verbindungen von Sachen brauche und auf einmal habe ich was, 01:01:05.520 --> 01:01:12.400 einen sehr, sehr coolen Effekt. Touch-Action gibt es noch, scrollbar, gutter. Und ich glaube, 01:01:12.400 --> 01:01:19.120 wir haben heute auch einen kleinen Trick gesehen, dass man mit einer Berichtungsangabe dann noch 01:01:19.120 --> 01:01:25.200 erreichen kann, dass die scrollbar einfach mal auf der linken Seite ist, wo ich sehr schmunzeln musste, 01:01:25.200 --> 01:01:33.440 weil ich irgendwann mal wegen irgendeinem Submenu, das eh schon in meiner Developer-Meinung sehr 01:01:33.440 --> 01:01:38.880 unwichtig war, kommt eh kein User jemals hin nach dem Motto und dann hat irgendjemand als Witz 01:01:38.880 --> 01:01:43.440 irgendein, weiß nicht mehr wer das war, aber aus dem Development-Team kam so ein Witz, 01:01:43.440 --> 01:01:48.240 wir können ja die scrollbar nach links machen und also, das geht ja gar nicht. Und es hat 01:01:48.240 --> 01:01:55.040 dummerweise jemand gehört, der das dann unbedingt haben wollt. Nein, nein, nein, nein, nein. So, 01:01:55.040 --> 01:02:04.400 jetzt wär's möglich. Jetzt wär's möglich, genau. Verkauf mal es, Teacher. Es ist doch immer mehr 01:02:04.400 --> 01:02:12.200 möglich, als man denkt. Ja, das ist auf jeden Fall super, genau. Ja, soll man dann hier bei den 01:02:12.200 --> 01:02:18.880 Interactions sozusagen... Ich würde noch eine Sektion weitergehen. Hast du noch was? Ich weiß 01:02:18.880 --> 01:02:27.000 gar nicht, was danach kommt. Die nächste ist nämlich die Typografie. Ja. Und da gibt es gar nicht so 01:02:27.000 --> 01:02:35.160 viele Punkte. Das eine sind die variablen Fonts. Das ist so ein Thema, das geistet bei mir auch immer 01:02:35.160 --> 01:02:42.520 und immer und immer wieder rum. Hab aber auch keinen Anstoß bisher gehabt, das jetzt tatsächlich 01:02:42.520 --> 01:02:49.440 einzusetzen. Es wäre wieder was, da müsste ich mal mit rumspielen, bis ich mich damit sicher fühle 01:02:49.440 --> 01:02:55.440 und dann würde ich es vielleicht mal auch tatsächlich einsetzen. Da würde ich mich auch echt 01:02:55.440 --> 01:03:01.520 interessieren, wie da so die Verbreitung ist, wie sehr das eingesetzt wird, ob das jemand einsetzt, 01:03:01.520 --> 01:03:10.280 ob ich schon Jahre zurück bin. Also ich glaube, du kannst das ja schon recht, also man kriegt ja 01:03:10.280 --> 01:03:16.040 immer so viele spektakuläre Variable von Demos gezeigt, also gerade wenn so Konferenztalks 01:03:16.040 --> 01:03:25.840 darüber sind. Aber so der Löwenanteil der Use Cases ist ja eigentlich, dass man anstatt 01:03:25.840 --> 01:03:33.720 mehrere Schriftsschnittdateien zu laden, eben einfach ein variablen Font lädt und der das 01:03:33.720 --> 01:03:43.120 alles quasi abbilden kann. Und die sind aber halt deutlich größer als ein Schriftsschnitt und meiner 01:03:43.120 --> 01:03:49.720 Meinung nach machen die sich dann erst bezahlt, wenn man wirklich auf eine hohe Anzahl Schriftsschnitte 01:03:49.720 --> 01:03:54.960 zurückgreifen muss. Also vielleicht so ab vier oder so, da würde ich sagen, da fangen variable 01:03:54.960 --> 01:04:05.760 Fonts an, dann die anderen zu überflügeln. Und das sind auch nicht so viele Projekte. Also die 01:04:05.760 --> 01:04:11.680 meisten begnügen sich vielleicht mit so zwei oder drei Schriftsschnitten und du hast bei den 01:04:11.680 --> 01:04:18.080 variablen Fonts auch so ein bisschen das Problem, dadurch, dass die ja programmiert sind, kannst 01:04:18.080 --> 01:04:23.640 du bestimmte oder funktionieren bestimmte Tools vielleicht auch nicht mehr, wo man die dann 01:04:23.640 --> 01:04:31.480 subsettet oder sowas. Also die kommen halt dann nicht klar damit und um mit Subsettingen kannst du 01:04:31.480 --> 01:04:35.400 die halt dann kleiner machen und so. Also ich glaube, das sind so dann eher so ein bisschen so die 01:04:35.400 --> 01:04:40.760 praktischen Hindernisse und deswegen habe ich auch noch keine variablen Fonts eingesetzt, weil 01:04:40.760 --> 01:04:50.840 bisher haben die mir noch keinen Vorteil geboten. Aber ich habe auch nichts gegen die. Der Browser 01:04:50.840 --> 01:04:57.640 Support ist hier absolut kein Hindernis. Es ist generell supported, aber wie du gerade richtig 01:04:57.640 --> 01:05:04.280 meintest, wir haben genau zwei verschiedene Fontfamilies. Wenn wir mal zufälligerweise 01:05:04.280 --> 01:05:12.080 in der dritte brauchen an ganz bestimmten Stellen, dann nehmen wir die Nativen vom System. Also wir 01:05:12.080 --> 01:05:17.440 brauchten da mal eine Mono Space und ich glaube, es gab eine andere bissel hübschere Mono Space, 01:05:17.440 --> 01:05:25.240 aber da ist jetzt auch egal, da müssen wir jetzt ein bisschen pragmatisch sein. Und an sich achten 01:05:25.240 --> 01:05:30.480 wir dann schon auch drauf, dass wir oder unser Design Team achtet da auch wirklich strikt drauf, 01:05:30.480 --> 01:05:36.480 nicht so viele verschiedenen Fontweights und ähnliches zu benutzen oder Italic hier und 01:05:36.480 --> 01:05:43.920 Italic da, was aber vielleicht auch das Design ein bisschen leichter macht. Ich weiß auch gar nicht, 01:05:43.920 --> 01:05:48.480 ob es eine gute Idee ist, sowieso, dass man acht verschiedene Fontweights benutzt. Vielleicht 01:05:48.480 --> 01:05:54.800 schaut es einfach besser, wenn man sagt, wir haben genau die 300, die 400 und dann die 700. Aber es 01:05:54.800 --> 01:06:00.800 500 und 600 gibt es halt nicht. Ja, aber es kann dann noch sein, also wenn du zum Beispiel noch Italic 01:06:00.800 --> 01:06:08.920 machst, also dann brauchst du ja quasi die ganzen Fettungsgrade nochmal in Italic Variante, dann 01:06:08.920 --> 01:06:14.640 kann ich mir das schon vorstellen, dass man das, dass man dann so in so Bereiche kommt, aber zum 01:06:14.640 --> 01:06:20.120 Beispiel Italic benutzen wir in unserem Projekt nicht und auch, ich weiß gar nicht, wie oft wir 01:06:20.120 --> 01:06:26.920 das überhaupt benutzt haben Italic in den Projekten. Das benutze ich maximal in Slack, wenn ich 01:06:26.920 --> 01:06:34.960 Bowl schreiben wollte und aus was sehen die Tastenkombination für Italic benutze. Und Italic 01:06:34.960 --> 01:06:39.120 und Bowl, das schaut eigentlich ja, also ich finde, schaut ein bisschen komisch aus. Also da gibt es 01:06:39.120 --> 01:06:44.560 mittlerweile ganz andere Möglichkeiten, die wir eigentlich nutzen, um Sachen zu highlighten. Meistens 01:06:44.560 --> 01:06:50.280 eher so, dass es, dass irgendwie eine Sache in den Bordern hat, mit fünf Pixel Bordern nach unten 01:06:50.280 --> 01:06:54.960 und wenn ich das hauere, dann, also so ein Italic kommt irgendwie für mich als Use Case einfach 01:06:54.960 --> 01:07:00.440 nicht mehr vor. Die Variablen von uns ist immer noch großartig, aber auch leider fehlt mir persönlich 01:07:00.440 --> 01:07:10.160 und beruflich vor allem der Grund, das einzusetzen. Ja, genau, aber vielleicht, also da kann ich mir 01:07:10.160 --> 01:07:15.560 auch vorstellen, dass wir da guten Input von unseren Hörern und Hörern bestimmt bekommen könnten, 01:07:15.560 --> 01:07:20.520 was das angeht und vielleicht übersehen wir ja auch bestimmte Vorteile. Ich bin ja total in meiner 01:07:20.520 --> 01:07:27.320 Bubble. Genau, so schickt uns gerne, wenn ihr da noch irgendwie Ideen einwendet und Co. habt, 01:07:27.320 --> 01:07:34.400 gebt uns da mal Bescheid, freuen wir uns drauf. Wiederum was anderes bei der Typografie, was ich 01:07:34.400 --> 01:07:45.920 auch ständig im Einsatz habe, ist die Line Clamp, was ein Attribut ist, um eine Ellipse nach 01:07:45.920 --> 01:07:50.840 mehreren Zeilen zu machen. Was großartig ist, weil das immer nicht ging und das ist jetzt ein 01:07:50.840 --> 01:07:58.680 Einzeiler und der ist ganz großartig, theoretisch. Ich würde sagen, im Endeffekt vielleicht doch 01:07:58.680 --> 01:08:06.360 kein Einzeiler, weil es nicht immer funktioniert. Das liegt jetzt aber nicht an der Line Clamp 01:08:06.360 --> 01:08:12.680 selber, sondern in diversen Einsatzgebieten, wenn da schon Flexbox-Container mit bestimmten 01:08:12.680 --> 01:08:17.480 Settings drum rum ist, dann funktioniert das immer nicht mehr, weil der Browser die Breite 01:08:17.480 --> 01:08:22.760 nicht richtig berechnen kann und dann gibt es komische Hex mit MinWolf 0 auf, und dann fragt man 01:08:22.760 --> 01:08:27.360 sie mal auf das Schkinn-Sitzel oder auf Parents. Wo muss ich MinWolf 0 setzen? Das heißt, es 01:08:27.360 --> 01:08:34.760 funktioniert leider nicht immer ganz so easy. Und das Zweite, eigentlich bin ich gar kein Fan 01:08:34.760 --> 01:08:42.960 davon, Sachen abzupunkten, weil warum sollte ich Sachen abpunkten in einer Welt, wo ich beliebig 01:08:42.960 --> 01:08:51.240 viel Space habe? Also schwierig. Das heißt, ich würde natürlich immer erst mal beim Design 01:08:51.240 --> 01:08:59.160 nochmal nachhaken, warum punkten wir da jetzt genau ab, weil vielleicht ist halt das Design in der 01:08:59.160 --> 01:09:04.440 Situation einfach falsch. Und gerade finde ich es dann schlecht, wenn man einfach nur weiß, 01:09:04.440 --> 01:09:08.720 dann Mobile Device wird dann einfach abpunkte, dann muss man vielleicht doch eher damit arbeiten, 01:09:08.720 --> 01:09:15.720 eine kleinere Fontgröße zu wählen oder ähnliches. Aber ich habe trotzdem ein paar schöne Use Cases, 01:09:15.720 --> 01:09:20.440 wenn ich zum Beispiel erwarte an einer Stelle, dass der User generiert, der Content reinkommt, 01:09:20.440 --> 01:09:25.000 und ich möchte einfach irgendeine Art von Fallback haben, dass ich sage, du, wenn du jetzt wirklich 01:09:25.000 --> 01:09:29.800 mal zwölf Zeilen lang wirst, das ist schon ein großer, großer Edge Case. Aber falls irgendjemand 01:09:29.800 --> 01:09:35.080 beschließt, da ganz viel Text reinzuschreiben, dann punkte doch nach zwölf Zeilen dann doch mal ab, 01:09:35.080 --> 01:09:40.240 sonst müssen wir vom Design her oder in dem Grid würde das einfach ausbrechen und dann haben 01:09:40.240 --> 01:09:51.240 wir hier einfach so einen Limiter drin. Und was ich dann verwenden würde, wäre ein Tool Tip. Und 01:09:51.240 --> 01:09:56.320 ich denke, dass es immer noch so ist, dass das Title Attribute so ein bisschen Accessibility 01:09:56.320 --> 01:10:00.760 Probleme hat, weil eigentlich würde ich gerne sagen, dann setze ich halt zusätzlich den Text 01:10:00.760 --> 01:10:06.280 als Title, dass ich, wenn ich mit der Maus drüber habe, ihn komplett sehe, weiß nicht, 01:10:06.280 --> 01:10:11.680 ob das immer noch so ist. Wir haben einen Tool Tip Library Popper.js, war das das, 01:10:11.680 --> 01:10:19.920 glaube ich. Sehr hübsche Tool Tips und ich denke, es ist auch Accessible, wo ich dann immer bei so 01:10:19.920 --> 01:10:25.760 abgepunkterten Text drauf setze. Am schönsten wäre es natürlich, wenn ich den Tool Tip auch nur mache, 01:10:25.760 --> 01:10:30.360 wenn tatsächlich auch der Text abgepunktert ist und ansonsten nicht. Das heißt, es hat 01:10:30.360 --> 01:10:37.480 genau, und da sagst du, dass das was, also was ich tatsächlich auch bei LineCamp, du finde, 01:10:37.480 --> 01:10:44.920 dadurch, dass das ja eine reine Layout-Geschichte ist und nicht irgendwie nix im Markup oder so 01:10:44.920 --> 01:10:50.800 was, weißt du einfach nicht, hat er denn jetzt was gepunktet oder ist der Text so kurz, dass er 01:10:50.800 --> 01:10:56.920 komplett zu sehen ist? Weil, wenn du jetzt so eine Pseudoklasse hättest, so was wie Doppelpunkt 01:10:56.920 --> 01:11:04.960 klemmt oder sowas, dann kannst du sagen, wenn was geklemmt wurde, dann quasi als Siblingselektor 01:11:04.960 --> 01:11:11.480 danach bitte das weiterlesen, den weiterlesen Link Display Block. Aber wenn man sowieso den 01:11:11.480 --> 01:11:21.040 ganzen Text sehen kann, also dann braucht man das halt nicht. Genau. Ich finde es halt ganz gut, 01:11:21.040 --> 01:11:27.360 manchmal, wenn man tatsächlich so irgendwo Anreißer platzieren möchte, die genau, und dann 01:11:27.360 --> 01:11:33.920 vielleicht irgendwie so in Kachel übersichten oder sowas, dann willst du ja schon das nicht. Also, 01:11:33.920 --> 01:11:40.320 du kannst natürlich irgendwie so ein Masonry versuchen, dann ist das okay, wenn Texte 01:11:40.320 --> 01:11:45.800 natürlich länger haben, aber Masonry ist halt wieder dann so, geht dann nur im Firefox, 01:11:45.800 --> 01:11:50.080 weil das im Grid unterstützt und ansonsten musst du wieder mit der JavaScript-Coil ankommen, 01:11:50.080 --> 01:11:56.160 ist alles doof. Aber sonst, wenn du so gute Übersichten hast und du räumst dann irgendwie den 01:11:56.160 --> 01:12:03.360 Anreißern Dreizeil in Platz ein und dann gibst du aber danach die Link zum Weiterlesen. Wenn man 01:12:03.360 --> 01:12:12.600 irgendwie mehr lesen möchte, dann ist das auch okay. Aber du weißt halt nicht, so ist es denn 01:12:12.600 --> 01:12:17.240 immer so, dass Weiterlesen Sinn macht, weil wenn dann nur zwei Teilen stehen, dann macht 01:12:17.240 --> 01:12:23.360 Weiterlesen ja nicht viel Sinn, weil dann ist der Satz ja schon zu Ende. Ja, also auch hier in dem 01:12:23.360 --> 01:12:31.520 bisgen anderen Kontext, aber ähnlich wie beim Backdrop-Filter, würde ich hier sagen, es ist 01:12:31.520 --> 01:12:38.000 super cool, aber eben mit Vorsicht zu genießen. Es ist wirklich aus eigener Erfahrung, dass ich 01:12:38.000 --> 01:12:42.400 damit mal angefangen habe, weil an der einen Stelle war das super und dann war das immer so, 01:12:42.400 --> 01:12:45.840 ach wir können ja allein klemmen, ach wir können ja allein klemmen und irgendwann schafft man 01:12:45.840 --> 01:12:49.360 auch die Website und sieht nur noch Punkte und fragt sich, warum haben wir so viele Punkte? Wir 01:12:49.360 --> 01:12:55.440 haben endlos viel Platz nach unten. Genau. Ein anderes, was ich hier bei der Typografie noch 01:12:55.440 --> 01:13:03.160 sehe, ist Front-Display, das ich tatsächlich kenne, weil mir Google Lighthouse sagt, du musst 01:13:03.160 --> 01:13:09.920 dann ein Swap hinzusetzen. Das ist so, so was ich mit Front-Display in Verbindung setze. Das 01:13:09.920 --> 01:13:17.600 heißt, ich weiß, was es tut, es verhindert das Flackern bei der Front, je nachdem, 01:13:17.600 --> 01:13:21.000 mit welcher Einstellung ich da jetzt ran gehe. Ich glaube, Auto ist einfach nicht voll. Ja, 01:13:21.000 --> 01:13:30.200 beziehungsweise ist es eigentlich eher gedacht, damit du, also um den Besucher möglichst schnell 01:13:30.200 --> 01:13:35.720 den Text zu zeigen. Also früher konnte man das ja gar nicht einstellen und dann haben manche 01:13:35.720 --> 01:13:41.040 Browser das auf eine bestimmte Art und manche auf eine andere Art gelöst. Also viele haben dann 01:13:41.040 --> 01:13:49.240 eben diesen Flash of Unstyled Text, glaube ich, Fault, ist das? Es gibt irgendwie Fault und 01:13:49.240 --> 01:13:56.320 Fuit für Invisible und Unstyled Text. Genau, und das war halt manchmal blöd und dann kann man 01:13:56.320 --> 01:14:02.280 eben über Front-Display jetzt steuern. Wie ist das? Also wenn jetzt der, das die Front-Datei noch 01:14:02.280 --> 01:14:07.640 nicht runtergeladen ist, soll der wirklich dann erst mal gar nichts zeigen oder so oder vielleicht 01:14:07.640 --> 01:14:13.640 erst mal eine Systemschrift zeigen und sobald dann der Front geladen ist, dann das wechseln, 01:14:13.640 --> 01:14:19.320 das wäre Swap oder soll... Stimmt, da gibt es ja eigentlich das Flackern dann, weil ich ja in Swap 01:14:19.320 --> 01:14:26.880 mache. Genau. Und du kannst auch sagen, also da gibt es noch einen Setting dessen, 01:14:26.880 --> 01:14:32.360 haben ich jetzt gerade vergessen hab. Ich weiß nicht, ob das Fallback ist. Vielleicht ist es Fallback. 01:14:32.360 --> 01:14:41.520 Da wartet, also dann kommt auch dieses Systemschrift und der Browser wartet... Nee, der Browser wartet 01:14:41.520 --> 01:14:46.320 eine ganz kurze Zeit. Wenn der Front es nicht schafft, dann kommt dieses Systemschrift und dann 01:14:46.320 --> 01:14:50.040 bleibt es auch dieses Systemschrift. Genau, das ist so das gute Laden. Das ist eigentlich auch genau 01:14:50.040 --> 01:14:55.800 so, wie ich das... Ich sage immer, wie man das so macht, aber meistens meines auch nicht so, 01:14:55.800 --> 01:15:02.600 dass der Teil doof. Das Verhalten von Loading Spinnern, wo es ganz klare, hoffentlich noch nicht 01:15:02.600 --> 01:15:08.400 wieder wiederbelegte Studien darüber gibt aus der Human-Computer-Interaction, dass es ablenken 01:15:08.400 --> 01:15:14.400 ist, wenn ich immer sofort ein Loading Spinner anzeige und viel besser fürs Auge, wenn ich einfach 01:15:14.400 --> 01:15:20.280 mal kurz nicht sehe und dann kommt halt Smooth was rein, anstatt dass da so Button-Click, 01:15:20.280 --> 01:15:24.720 Loading Spinner, Ergebnis schon da, alles flackert so, man hätte ja einfach, wenn das Ergebnis 01:15:24.720 --> 01:15:30.560 innerhalb von einer halben Millisekunde... Einfach kurz abwarten, ob das Ergebnis nicht 01:15:30.560 --> 01:15:33.800 eh gleich da ist, dann braucht man den Loading Spinner, auch er kann nicht erst irgendwie 01:15:33.800 --> 01:15:38.000 bemühen sozusagen. Genau, weil dann, wenn der Loading Spinner nur Zeit hat, um eine halbe 01:15:38.000 --> 01:15:43.880 Umdrehung zu schaffen, eher ablenken wirkt und eher langsamer für die Leute wirkt, die dann drauf 01:15:43.880 --> 01:15:49.440 schauen, weil irgendwas passiert ist und genauso funktioniert die Fallback-Einstellung. Das ist 01:15:49.440 --> 01:15:55.920 so ein Kompromiss zwischen Auto und Swap und ich denke der Browser wartet so ungefähr 100 01:15:55.920 --> 01:15:59.280 Millisekunden, aber ich glaube das ist so ein ungefährer, nicht exakter Bereich, so ein bisschen 01:15:59.280 --> 01:16:04.320 wie Time-Outsetzen und wenn wirklich nichts kommt, dann wird dann geswappt, ansonsten wird gewartet. 01:16:04.320 --> 01:16:10.760 Das finde ich also sehr gut, das auch in das Server rein zu packen, weil wieder was, was man 01:16:10.760 --> 01:16:17.000 sonst einfach nicht mitkriegt, dass es existiert und doch wahrscheinlich super, einfach von Google 01:16:17.000 --> 01:16:22.680 Lighthouse mal abgesehen, was da für komische Werte drinstehen, egal ob jetzt 70 oder 100 01:16:22.680 --> 01:16:28.000 oder sonst was, wahrscheinlich viel Unterschied für User machen kann im Empfinden der Seite. 01:16:28.000 --> 01:16:35.200 Es gibt noch optional, ist irgendwie wie Feedback, aber irgendwie ein bisschen anders, 01:16:35.200 --> 01:16:40.040 keine Ahnung, vielleicht ist optional besser, aber ich glaube irgendwie was anderes. 01:16:40.040 --> 01:16:48.560 Ja, eventuell ist aber optional auch das, was ich beschrieben habe. Genau, also es lohnt sich auf 01:16:48.560 --> 01:16:54.360 jeden Fall da mal durchzugucken, ich glaube empfohlen wird eigentlich schon immer Swap und 01:16:54.360 --> 01:17:00.480 wenn man so ordentlich preloadet seine Fonts, dann sind die eigentlich auch immer da, bevor der 01:17:00.480 --> 01:17:07.880 Browser anfängt zu zeichnen, also wenn die dann auch schön optimiert sind, also ich subsette dann 01:17:07.880 --> 01:17:13.440 die Schriften immer und hab nicht so viele Schrift-Schnitte und dann, wenn du die dann als 01:17:13.440 --> 01:17:20.560 Wapf 2 bereithältst, dann sind das so 25k pro Schnitt und das ist, das ist dann sehr okay, 01:17:20.560 --> 01:17:30.400 finde ich. Ja, dann Swap der Browser zwar, aber die Schriften sind so schnell da, dass das Swapping 01:17:30.400 --> 01:17:34.560 sozusagen schon vor dem ersten Zeichen dann passiert und du siehst es als Besucher, 01:17:34.560 --> 01:17:37.920 als Besucher siehst du gar nicht, siehst du kein Swapping, dann ist direkt schon von 01:17:37.920 --> 01:17:46.360 Anfang an der Font da. Es könnte sein, dass optional sich dazu entscheiden kann die Custom 01:17:46.360 --> 01:17:52.160 Font gar nicht mehr anzuzeigen oder zu laden, sondern einfach davor begleiten. Ja, genau, so was 01:17:52.160 --> 01:17:57.840 ist das. Genau, also dann eben nicht mehr für diesen Aufruf, sondern bei der nächsten Navigation, 01:17:57.840 --> 01:18:09.640 wenn dann der Font im Browser-Cache liegt. Da macht's ihn, gell? Ja, genau, aber ja, ich sag mal so, 01:18:09.640 --> 01:18:17.240 die Stakeholder, die kriegen das vielleicht auch nicht mit, weil die, weil die Schrift dann ja, 01:18:17.240 --> 01:18:21.360 weil die das nur beim ersten Mal sehen und dann denken die vielleicht noch so komisch und dann 01:18:21.360 --> 01:18:25.920 kann man denen sagen, ja, ja, ist es gefixt, hast du doch jetzt auch nicht mehr, aber eigentlich 01:18:25.920 --> 01:18:34.800 so richtig. Ja, das ist das. Das ist eine Sache, die sehe ich im Entwicklungsteam und da würde ich 01:18:34.800 --> 01:18:40.080 auch sagen, dass es schon in unserer Verantwortung auch solche Sachen proaktiv in die Hand zu nehmen, 01:18:40.080 --> 01:18:46.480 um nicht auf jetzt ein Projekt-Produktmanager, ich hau das immer übereinander, wer wer ist, 01:18:46.480 --> 01:18:52.800 zu warten, dass mir irgendjemand sagt, ich soll da doch jetzt mal, wenn du bist, 01:18:52.800 --> 01:18:56.760 das ist sogar ich habe Probleme hier, was ist optional, was ist vorbeig optional, 01:18:56.760 --> 01:19:03.120 auch nie davor gelesen. Also ja, ich meine nur, die stören sich wahrscheinlich, 01:19:03.120 --> 01:19:10.440 also Kunden würden sich wahrscheinlich daran stören, wenn so eine Seite erst mal ein System 01:19:10.440 --> 01:19:17.080 font lädt und erst beim zweiten Seitenaufruf dann die richtige Schrift artern und Designer 01:19:17.080 --> 01:19:24.080 natürlich auch, wenn die viel Wert legen auf die Typografie, deswegen, ja, denke ich sind so, 01:19:24.080 --> 01:19:29.200 die Use Case ist dann doch begrenzter für diese Optionalgeschichte, obwohl sie eigentlich ja auch 01:19:29.200 --> 01:19:42.440 ganz, ganz nett ist. Gut, und das war es von den ersten 1, 2, 3, 4, 5 Sections, würde ich sagen, 01:19:42.440 --> 01:19:51.320 dann machen wir hier einen Cut und vielleicht ist beim nächsten Mal, wenn wir uns im zweiten Teil 01:19:51.320 --> 01:19:56.200 darüber unterhalten, die Auswertung schon da, ich weiß nicht genau, bis wann das noch läuft, 01:19:56.200 --> 01:20:03.080 also aktuell ist quasi so die Teilnahmephase, also wenn ihr noch nicht auffahrt, dann könnt ihr das, 01:20:03.080 --> 01:20:07.120 könnt ihr da auf jeden Fall auch teilnehmen und wir haben auch gesehen, das war auch richtig cool, 01:20:07.120 --> 01:20:14.320 dass unter Learning Resources ist auch der WorkingDraftPodcast drin, zum 1. Mal, also ziemlich 01:20:14.320 --> 01:20:24.000 geil, den könnt ihr dann natürlich auch ankreuzen. Ich weiß nicht genau, ich glaube Ende, ja, 01:20:24.000 --> 01:20:28.080 es ist schon jetzt Ende Oktober, das heißt, also das könnte schon sein, dass bei der nächsten 01:20:28.080 --> 01:20:33.800 Aufnahme dann die Auswertung schon da ist und dann können wir natürlich weiter darüber sprechen, 01:20:33.800 --> 01:20:39.120 aber wir sehen auch, wieso das Antwortverhalten der Leute ist und können das so ein bisschen mit 01:20:39.120 --> 01:20:43.520 unserem eigenen dann nochmal abgleichen. Weil ich super froh bin, dass es jetzt noch nicht da ist, 01:20:43.520 --> 01:20:48.480 damit wir dann in ein paar Wochen sehen, dass ich vollkommen falsch lage mit meinen Einschätzungen, 01:20:48.480 --> 01:20:53.160 was man braucht, was wer kennt, wo ich da sage, ja, das kennt jeder, ne, es kennt niemand, 01:20:53.160 --> 01:21:01.360 schau ich komplett daneben. Ja klar, also hängt ja immer so ein bisschen davon ab, so was für eine 01:21:01.360 --> 01:21:08.800 Web-Anwendung man zu baut und was die halt auch so Verantwortung hat, ob man sich mit bestimmten 01:21:08.800 --> 01:21:14.720 Dingen mehr beschäftigt und mit anderen eben weniger. Ja, und eigentlich bin ich generell der 01:21:14.720 --> 01:21:22.440 Meinung, ich hoffe, dass sich der Durchschnitt mehr damit beschäftigt als ich, weil ich finde 01:21:22.440 --> 01:21:28.000 teilweise, dass das Web irgendwie ein langweiliger Ort geworden ist. Das war vor 20 Jahren, 01:21:28.000 --> 01:21:32.960 weil es alles noch spannend war, also bunt, da hatten wir GIFs, die oder acht pixel breite 01:21:32.960 --> 01:21:38.440 Hintergrundbilder, die repeated worden sind und alles verbunden hat geschrieben und es war auch 01:21:38.440 --> 01:21:44.160 alles zu laut und zu krell. Aber es war alles, jeder Seite war unterschiedlich und das war nicht 01:21:44.160 --> 01:21:53.760 so schön. Ja, alte Uma erzählt vom Krieger. Ja, ich habe letzte Woche, habe ich bei einer 01:21:53.760 --> 01:21:58.320 Hybrid-Konferenz zugeguckt, die in London stattgefunden hat, die auch sozusagen einen Spin-off 01:21:58.320 --> 01:22:06.600 des London Web Meetups oder Web Standards Meetups ist oder so. State of the Browser heißt das, 01:22:06.600 --> 01:22:12.720 also passt ja auch hier zu State of CSS, State of the Browser war das und einer der Vorträge war 01:22:12.720 --> 01:22:22.920 Coding Websites, like 1999 glaube ich, aber eben visuell wollte man dieses Ziel erreichen, aber man 01:22:22.920 --> 01:22:29.360 hat das eben natürlich nicht mit den alten Techniken gemacht, sondern mit brandneuen Techniken, 01:22:29.360 --> 01:22:36.360 also man hat dann irgendwie so World Clip Art gemacht, in dem man mit 3D und Clip Path und 01:22:36.360 --> 01:22:44.200 haste nicht gesehen, so in die Richtung und Gradient Text und Textfarben. Das war ganz 01:22:44.200 --> 01:22:50.560 interessant. Wenn ich sehe, dass das Video online ist, dann kann man das nochmal hier rein linken 01:22:50.560 --> 01:22:57.160 und ich dran denke, wenn ich die schon uns schreibe. Alright, dann bedanke ich mich für einen netten 01:22:57.160 --> 01:23:06.640 CSS-Plausch. Danke auch. Und wir danken auch den Hörern fürs Zuhören und melden uns dann 01:23:06.640 --> 01:23:11.880 irgendwie nächste Woche wieder mit irgendeinem spannenden Thema, das wir nicht kennen. Ich 01:23:11.880 --> 01:23:17.640 versuche auch nicht mal krank zu werden. Dass wir auch machen. Vielen Dank. Nur sechs Wochen 01:23:17.640 --> 01:23:25.400 wirken, Kraftpause gehabt. Das ist doch nix. Die Zeit, die vergeht doch so schnell. Super. Also, 01:23:25.400 --> 01:23:53.400 dann bis demnächst. Macht's gut. Ciao. Tschüss.