Working Draft   /     Revision 547: The State of CSS (Teil 2)

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 zwei von zwei Teilen. Teil eins könnt Ihr hier nachhören.

[00:01:00] Schaunotizen

[00:02:03] Das prefers-reduced-data Media Feature Das prefers-reduced-data Media Feature (HTML), bzw. die prefers-reduced-data Media Query (CSS) wird derzeit nur von den Chromium-Browsern unterstützt, und das auch nur hinter Flags. Hiermit könnt Ihr (teilweise) steuern, was an Daten zusätzlich geladen werden soll, je nachdem ob der Wert auf no-preference oder reduce steht.

Wir sprechen in dem Zusammenhang auch über sogenannte „Browser Interventions„, die Simon Pieters in diesem Twitter-Thread genauer ausführt.

Außerdem findet der Poor Man’s Dark Mode Erwähnung.

[00:18:37] :focus-visible Die Kurzfassung der Funktionsweise der :focus-visible-Pseudoklasse ist, dass diese nur dann zum Tragen kommt, wenn der Browser ein Interaktionsmuster feststellt, bei dem die benutzende Person einen visuellen Fokus-Indicator benötigt. Damit kann man die von Designern und Chefs verhassten Fokus-Outlines wegstylen, um sie im Falle eines aktivierten :focus-visible wieder zurück zu bringen.

Die Langfassung dessen, was hinter :focus-visible (und inert) steht, könnt Ihr in dieser Folge der Igalia Chats Podcastreihe nachhören.

[00:21:15] Color Schemes Dieser von Vanessa erwähnte Artikel beinhaltet alle Infos zu den verschiedenen Color Schemes, die man benötigt. [00:22:00] Das ::marker-Pseudoelement Mit Hilfe von ::marker lässt sich nun endlich(?) das Aufzählungszeichen von Listen greifen und stylen. Wir sind uns allerdings nicht sicher, wie sehr uns das tangiert.

Wichtig zu wissen ist nämlich, dass man bei ::marker nur ein Subset an CSS-Eigenschaften zum Stylen zur Verfügung hat.

[00:24:45] :has() Dank der Ideen eines brillanten WebKit-Ingenieurs zur Umgehung der drohenden Performance-Probleme, ist Ende 2021 naben Container Queries auch der zweite Traum aller Frontend-Enwickler*innen, der Parent-Selector Wirklichkeit geworden!

Wir erwähnen kurz die Tatsache, dass es auch beim :last-child-Selektor aus Performancegründen länger gedauert hat, bis dieser in allen Browsern verfügbar war.

[00:28:46] :where() Mit :where() kann man einerseits stellvertretend mögliche Selektoren auflisten, um sich nicht per Selektoraufzählung wiederholen zu müssen. Das kann :is() allerdings auch. Der Unterschied von :is() zu :where() ist jedoch, dass :is() die Spezifität des  Selektors in der Auflistung mit der höchsten Spezifität übernimmt, während die Spezifität von :where() bei 0 (null) verbleibt, ähnlich wie beim Universalselektor *.

Und das wiederum ermöglicht zusammen mit anderen Neuerungen wie den globalen Eigenschaftswerten unset und revert gänzliche neue Arten von CSS-Resets.

[00:30:39] Warum heißt es manchmal CSS Variablen und manchmal Custom Properties? Wir klären die Frage, ob beides vielleicht unterschiedliche Dinge sind (Spoiler: sind sie nicht), und warum das Ganze offiziell nicht „CSS Variablen“ heißt.

Dann erwähnen wir Lea Verous Talk über Custom Properties vom letzten CSS Day, der sehr weit in die Tiefe geht und Dinge wie Toggle-Switches und mehrere Ebenen von verschachtelten Custom Properties zeigt.

[00:37:56] @property Über @property ging es vor nicht all zu langer Zeit in der Folge Revision 534: CSS Houdini, gescheitert?. Dank @property kann man CSS Custom Properties typisieren, so dass der Browser im Anschluss weiß, wie er den Wert im Rahmen einer Animation interpolieren kann. Oder man definiert, ob eine Custom Property sich vererbt, oder eben nicht. Und zu guter Letzt kann man einen initialen Wert festlegen, den die Custom Property hat, wenn Ihr kein Wert zugewiesen wurde.

@property --property-name {
  syntax: "";
  inherits: false;
  initial-value: #c0ffee;
}

Ein schöner Nebeneffekt von „dummen“, also nicht-typisierten Custom Properties ist die Tatsache, dass man von diesen z.B. Farben mit verschiedenen Transparenzen oder Farben mit ähnlichen HSL-Werten ableiten kann.

[00:41:58] @supports() @supports() ist eine im Browser eingebaute Feature Detection für CSS Eigenschaften und/oder bestimmte Eigenschaftswerte. Verwenden wir beide gerne und viel.

Neuerdings lässt sich mit Hilfe der selector()-Funktion in einem @supports auch herausfinden, ob CSS Selektoren vom Browser unterstützt werden.

[00:43:46] min(), max() und clamp() Alle drei Funktionen sind aus unserer Sicht sehr nützliche Ergänzungen von CSS. Bei min() und max() haben wir allerdings wie die meisten anderen Entwickler*innen das Problem, dass wir zunächst zum falschen greifen wollen, weil wir das Gegenteil des Funktionsnamens erreichen wollen.

clamp() wiederum findet meist im Rahmen von Fluid Typography Anwendung.

Und schließlich erwähnen wir noch die Tatsache, dass man innerhalb von min(), max() und clamp() kein calc() benutzen muss, weil die schon von Haus aus Mathematische Ausdrücke als Werte unterstützen.

[00:47:14] Dies und das Wir rauschen als nächstes schnell noch über ein paar CSS Features drüber:

• will-change finden nicht nur wir sehr problematisch und raten vom Einsatz ab
• Cascade Layers aka @layer sind ein spannendes neues Konzept. Es gibt dazu einen tollen Talk von Bramus van Damme. Use-Case sind vermutlich Design Systeme.
• Mit ::part() kann man von außen Teile eines Shadow DOMs stylen, sofern die Autoren desselben diese Teile mit einem part-Attribut markiert haben.
• Trigonometrisch Funktionen wie sin(), cos() und tan() sind sinnvolle Ergänzungen, um komplexe Transformationen zu berechnen.
• CSS Nesting ist nett, haut uns aber nicht so vom Hocker. Außerdem wird es wohl noch etwas länger dauern, bis man das einsetzen kann.
• Die image-set()-Funktion ist sowas wie srcset, nur in CSS. Wird in einer Vorversion mit -webkit--Prefix schon seit langem von Safari und Chromium unterstützt.
• Die image()-Funktion ist so etwas wie die Nachfolgerin der url()-Funktion. Sie räumt ein paar historische Probleme von url() aus, wie zum Beispiel, dass man darin keine Custom Properties verwenden kann. Darüber hinaus rüstet image() weitere Fähigkeiten nach, wie etwa ein Bild aus einer Farbe zu generieren, so dass man keinen Gradienten mehr dafür missbrauchen muss. Und man kann auch nur Bildausschnitte via Fragment-Notation verwenden. Der Browser-Support ist aber nicht vorhanden.

[00:53:09] CSS Frameworks Wir gehen kurz die aufgelisteten Frameworks durch und stellen fest, dass wir nur die wenigsten davon kennen. Außerdem werden hier echte CSS Frameworks wild mit Komponentenbibliotheken gemischt. Welche verwendet Ihr denn und was gefällt Euch an denen gut? Joined uns im Community Draft und sagt es uns! [00:58:53] CSS in JS Noch viel weniger Plan als von Frameworks haben wir von den verschiedenen CSS-in-JS-Bibliotheken

Vanessa erinnert sich jedoch an eine alte Folge, in der Hans und Schepp ausschließlich über CSS in JS diskutiert haben: Revision 468: CSS in JS.

[01:07:08] Other Tools Schepp nutzt weiterhin sehr gerne SCSS, weil es sehr angenehm ist, damit zu arbeiten und sein CSS zu organiseren. Bei Vanessa kommt es ein wenig von den in Projekten eingesetzten Scaffolding-Tools und deren „Serviervorschlägen“ an, welche Art Pre- und Postprozessoren am Werk sind.

An weiteren Tools nutzt Vanessa noch Stylelint, Purge CSS, Prettier, Autoprefixer und CSS Nano. Dadurch dass diese Dinge aber eben oft automagisch von Scaffolding-Tools gesetupped werden, steht man auch schonmal wie der Ochs vor dem Berge, wenn etwas nicht geht, weil man nicht weiß, was denn genau alles in einem Projekt am Werk ist. Schepp hingegen ist mehr so der Typ, der alles selbst aufsetzt und konfiguriert, der damit am Anfang zwar langsamer ist, er aber immer weiß, was passiert. Von CSS Nano rät Schepp hingegen ab. Aus CSS lässt sich einfach nicht so viel an Minifizierung herausholen, als dass es sich lohnne würde die Risiken einzugehen, die mit CSS Nano daherkommen.

Als Entwicklungsbrowser nutzt Vanessa den Microsoft Edge, während Schepp weiterhin auf Chrome setzt. Beide schwärmen wir aber auch von extra für Entwickler*innen gebaute Browser wie dem Sizzy-Browser oder Polypane.

Zu guter Letzt gehen wir noch auf eine Art K.O.-Umfrage ein, in der man sich in mehreren Duellen für eines von zwei Kriterien entscheiden soll, die einem bei der Auswahl eines Tools wichtiger ist. Am Ende der Duell-Reihe bleibt dann das wichtigste Kriterium übrig. Die Duelle sind unserer Meinung nach aber seltsam gegeneinander aufgestellt.

[01:31:45] Resources Im Kapitel über die Learning Resources freuen wir uns schließlich sehr darüber, dass unser Podcast es hineingeschafft hat. Mega! Transkript

WEBVTT

00:00.000 --> 00:04.760
Hallo und herzlich willkommen zu einer neuen Revision des Working Draft Podcast.

00:30.000 --> 00:36.600
Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch.

00:36.600 --> 00:40.880
Auf patreon.com slash Working Draft könnt ihr uns ein paar Euro in den Hut werfen.

00:40.880 --> 00:44.720
Aus euren Beiträgen und unseren gelinglichen Werbeeinnahmen bezahlen wir allerlei teure

00:44.720 --> 00:49.080
Software-Abos und das Honorar unserer Audioproduzerin. Wenn ihr euch auch beteiligen

00:49.080 --> 00:52.600
wollt, könnt ihr das unter patreon.com slash Working Draft sehr gerne machen.

00:52.600 --> 01:00.360
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

01:00.360 --> 01:07.240
Wir befinden uns in Revision 547 und mit mir hier ist wieder mal die Vanessa.

01:07.240 --> 01:08.240
Hallo.

01:08.240 --> 01:14.400
Denn wir haben uns gedacht, wir versuchen den restlichen Teil des State of CSS,

01:14.400 --> 01:19.760
der State of CSS Survey, abzuarbeiten. Wir haben ja vor zwei Revisionen angefangen

01:19.760 --> 01:25.080
mit einem ersten Teil. Also rein von den Kapiteln her sind wir glaube ich nicht bis ganz auf

01:25.080 --> 01:31.000
die Hälfte gekommen, aber es gibt noch ein paar Sachen, über die können wir vielleicht

01:31.000 --> 01:33.800
schneller drüber weg hüpfen. Wir schauen mal.

01:33.800 --> 01:38.400
Ja, wir können zum Beispiel schon ganz schnell drüber weg hüpfen über CSS in JS, davon

01:38.400 --> 01:39.400
habe ich keine Ahnung.

01:39.400 --> 01:46.080
Ja, genau, aber noch sind wir ja nicht da, weil wenn wir chronologisch vorgehen, also

01:46.080 --> 01:52.040
wir waren zuletzt im Bereich, würde ich sagen, oder? Sonst kommen wir ja ganz durcheinander.

01:52.040 --> 01:56.800
Also zuletzt, wir haben gesprochen über Layout, über Shapes and Graphics, zumindest haben

01:56.800 --> 02:02.840
wir jetzt so die Überschriften gestaltet über Colors, Interactions und Typography

02:02.840 --> 02:07.560
und als nächstes, oder wir würden heute starten mit Accessibility.

02:07.560 --> 02:19.520
Und hier bei der Accessibility haben wir ja ganz verschiedene Rubriken. Die haben teilweise

02:19.520 --> 02:25.560
auf die UI Auswirkungen, aber teilweise auch, und das fand ich hier ganz spannend, ja auch

02:25.560 --> 02:29.960
auf die Daten, die geladen werden können. Dementsprechend fange ich vielleicht gleich

02:29.960 --> 02:37.520
mal mit einem Attribut an, das ich gar nicht wusste, dass es in CSS so existiert, beziehungsweise

02:37.520 --> 02:45.040
ich habe es mal gehört und dann wieder vergessen, und das ist das PrefersReducedData und hier

02:45.040 --> 02:49.520
ist das Beispiel angegeben, also der Wert davon, von dieser Eigenschaft ist dann auf

02:49.520 --> 02:56.680
Reduced gesetzt, also AddMediaQuery und falls PrefersReducedData auf Reduced gesetzt ist,

02:56.680 --> 03:03.120
dann wird hier als Body die FundFamilySystemUI gewählt, damit man jetzt diese FundFamily

03:03.120 --> 03:09.840
anscheinend nicht runterladen kann. Und da finde ich, für mich ist CSS hier wieder ein

03:09.840 --> 03:14.200
Beispiel dafür, dass CSS mich überraschen kann, wie mächtig es sein kann. Es ist eben

03:14.200 --> 03:21.720
nicht nur, wir machen coole rote Borders irgendwo hin, sondern wir können damit auch tatsächlich

03:21.720 --> 03:28.600
Payload sparen für die Nutzer. Ich frage mich trotzdem, eine FundFamily kann durchaus,

03:28.600 --> 03:32.080
also gerade wenn man hier so mehrere auf einmal lädt, ich meine die meisten haben wahrscheinlich

03:32.080 --> 03:36.560
irgendwie zwei verschiedene FundFamilies und dann nochmal drei verschiedene Größen,

03:36.560 --> 03:41.120
aber auch das ist schon ein bisschen was und ich kann hier tatsächlich aus eigener Erfahrung

03:41.120 --> 03:47.000
sprechen. Ich habe hier nämlich tatsächlich so einen Gigabyte mobile Datentarif. Ich komme

03:47.000 --> 03:51.040
nicht weit, also im Homeoffice ist auch kein Problem, da frage ich mich, was will ich mit

03:51.040 --> 03:55.920
dem ganzen Gigabyte anstellen. Wenn ich einmal mit dem Zug irgendwo hin fahre, ist das ein

03:55.920 --> 04:02.480
Gigabyte weg und ich erschrecke, wie riesig seitens sind, wenn ich nur eine Speisekarte

04:02.480 --> 04:07.080
auf irgendeiner Seite nachschauen kann und danach, keine Ahnung, acht Megabyte weniger

04:07.080 --> 04:11.960
drauf habe, das finde ich immer erschreckend. Ja, trotzdem würde ich mich hier fragen,

04:11.960 --> 04:18.920
hast du schon mal eingesetzt und wie siehst du da die Relation zu, sollte man nicht zuerst

04:18.920 --> 04:27.400
an Bildern, JavaScript und etc. ersparen? Also diese konkrete Media Query, die habe

04:27.400 --> 04:34.040
ich noch nicht eingesetzt, weil die gibt es noch nicht so ganz so lange, also nicht ganz

04:34.040 --> 04:40.840
so lange heißt wahrscheinlich auch schon zwei Jahre, doch, aber was, also ich habe das,

04:40.840 --> 04:50.160
bei der rheinischen Post habe ich das JavaScript-Pendant benutzt und da habe ich Werbung abgeschaltet,

04:50.160 --> 04:55.480
meine ich, wenn man das angegeben hatte. Ich weiß es nicht mehr hundertprozentig, ich

04:55.480 --> 05:01.680
habe es auf jeden Fall so programmiert, dass Werbung abgeschaltet wird, wenn die Datenverbindung

05:01.680 --> 05:09.760
zu schmalspurig ist, weil dann lädt weder das eine, also weder die Infos, die man lesen

05:09.760 --> 05:14.360
möchte, noch die Werbung und dann ist es irgendwie alles für die Katz, dann muss eben

05:14.360 --> 05:20.080
die Werbung abgeschaltet werden. Genaue generell würde ich natürlich sagen, sollte man ja

05:20.080 --> 05:26.280
gucken, dass man seine Seite so baut, dass das vielleicht nie notwendig ist, also dass

05:26.280 --> 05:32.520
man immer zu Datensparen wie möglich arbeitet. Ich kann mir vorstellen, wenn du jetzt wirklich

05:32.520 --> 05:37.400
irgendwie eine ganz miese Verbindung hast und so, dass man dann sagt, ok, ich will wirklich

05:37.400 --> 05:42.600
das so runter gestrippt haben auf das wirklich Wesentliche und mir ist jetzt auch die Schriftart

05:42.600 --> 05:50.400
egal, finde ich schon auch nicht so ganz schlecht, so was zu machen. Genau, ansonsten würde

05:50.400 --> 05:55.280
ich sagen, ich glaube, dass die Browser auch schon selber so ein paar Heuristiken haben,

05:55.280 --> 06:02.560
was sie wie laden, wenn jetzt die Datenverbindung schlecht ist. Das nennt sich bei Chrome, das

06:02.560 --> 06:08.600
glaube ich, Interventions oder so was. Die haben dann irgendwelche Trigger, dass der

06:08.600 --> 06:14.080
dann entscheidet so, nee, eigentlich müsste ich jetzt irgendwie das hochaufgelöste Bild

06:14.080 --> 06:20.320
laden, aber ich bin auf so einem leistungsschwachen Gerät oder einem mit so einer kleinen, dünnen

06:20.320 --> 06:24.280
Verbindung, dass ich das jetzt einfach nicht mache. Genau, und dann werden, glaube ich,

06:24.280 --> 06:31.240
auch bestimmte Sachen quasi zwangsweise asynchron geladen, die sonst eher blockierend wären.

06:31.240 --> 06:41.400
Genau, deswegen, also ich glaube, man nutzt es nicht so oft, aber ich glaube, ich finde

06:41.400 --> 06:47.320
es trotzdem ganz schön, dass es das gibt. So würde ich das jetzt mal aus dem Bauch

06:47.320 --> 06:52.360
raus sagen. Aber es ist natürlich auch wieder, ich finde gerade bei CSS mit den ganzen Media

06:52.360 --> 06:56.680
Queries finde ich es zunehmend schwierig, das alles abtesten zu können. Also wenn jetzt

06:56.680 --> 07:04.240
zum Beispiel, also du hast dann die Dimensionen, quasi Geräte, Bildschirmgrößen, dann hast

07:04.240 --> 07:08.880
du vielleicht noch Media Queries für die Datengeschwindigkeit und dann haben wir jetzt hier noch so ein

07:08.880 --> 07:14.000
paar andere Media Queries mit irgendwie Dark Mode, Bright Mode und Reduced Motion und vielleicht

07:14.000 --> 07:20.360
noch hier diesen, weiß nicht, der Contrast Mode auch noch aktiv hier drin ist, ich glaube

07:20.360 --> 07:26.720
aus Colors und das sind ja alles Dinge, die du dann, also alles sozusagen Zustände, in

07:26.720 --> 07:32.680
denen du deine Seite testen musst und ich finde, das ist ja schon bei Responsive Webdesign

07:32.680 --> 07:38.720
schwierig, alles immer auf allen Geräten abzutesten und das, also ich finde, das wird

07:38.720 --> 07:44.880
dann so ein bisschen viel alles. Wobei man jetzt für alles, was ich hier im Service sehe,

07:44.880 --> 07:48.760
also das habe ich auch gerade schon mal durchgesprochen, ich wiederhole es nur nochmal ganz kurz, wir

07:48.760 --> 07:54.800
haben Prefers Reduced Motion, Prefers Colors Scheme, Prefers Reduced Data, Colour Contrast,

07:54.800 --> 07:59.440
Colors Scheme, Prefers Contrast, Force Colors, Focus Visible, da muss man gleich nochmal

07:59.440 --> 08:04.600
drüber sprechen. Ich glaube, alles Dinge sind, da brauche ich jetzt zumindest noch kein

08:04.600 --> 08:11.360
Voice Over oder Gerät, Software, die mir die Sachen vorliest, ich glaube, du musst mir

08:11.360 --> 08:16.600
auch teilweise mehrere Sachen durchtesten, also vielleicht dementsprechend, wenn man da

08:16.600 --> 08:21.960
so ein paar Steps hat, aber ich mache hier auf jeden Fall, was du meinst, weil ich überlege

08:21.960 --> 08:26.040
auch gerade, weil ich wollte gerade sagen, ja gut, vielleicht kannst du dir so einen

08:26.040 --> 08:33.000
Tag im Monat vornehmen, wo du alle deine zehn Steps aber durchprobierst, allerdings klingen

08:33.000 --> 08:37.120
da manche Eigenschaften doch schon so, als die müsste ich dann doch jedes Mal testen,

08:37.120 --> 08:41.600
wenn ich mal was ändere, nur um sicher zu gehen, ob, keine Ahnung, jetzt Leute mit

08:41.600 --> 08:47.000
einem höher gestellten Kontrast nicht plötzlich gar nichts mehr sehen oder Sachen überlappen,

08:47.000 --> 08:49.480
weil da einmal ein Wortschätzung geändert wird.

08:49.480 --> 08:53.360
Genau, ja und das funktioniert dann vielleicht auf dem Desktop, aber funktioniert das dann

08:53.360 --> 08:59.000
auch auf dem Mobile, das heißt, da müsstest du es da auch nochmal dir angucken und das

08:59.000 --> 09:04.600
finde ich ist so ein bisschen die Krugs mit diesen vielen Queries, die man theoretisch

09:04.600 --> 09:10.840
verbauen kann, dass man irgendwann das nicht mehr irgendwie hinkriegt, die alle zu testen

09:10.840 --> 09:17.960
und man vielleicht Queries drin hat, die kaputt gehen im Laufe der Zeit, weil man sie nicht

09:17.960 --> 09:22.080
wieder getestet hat, also weil man sie einmal eingebaut hat und dann nicht nochmal guckt

09:22.080 --> 09:26.360
und da vielleicht besser gefahren wäre, wenn man sie gar nicht erst eingebaut hätte,

09:26.360 --> 09:29.880
also so ein bisschen wie mit ARIA, also die...

09:29.880 --> 09:33.960
Ne, die erste Regel von ARIA, verwende kein ARIA?

09:33.960 --> 09:39.520
Genau, also wenn du es, wenn es irgendwie geht, dass der Browser oder das Betriebssystem

09:39.520 --> 09:44.800
das irgendwie selber geregelt bekommen, dann ist es vielleicht manchmal besser, die machen

09:44.800 --> 09:48.240
zu lassen, anstatt da selber immer zu versuchen, Einfluss zu nehmen.

09:48.240 --> 09:55.320
Eine Media Query, die mir jetzt vor allem ein sehr bekannter Begriff war, war die Prefers

09:55.320 --> 09:58.200
Color Scheme auf Dark gesetzt.

09:58.200 --> 10:04.880
Ich muss tatsächlich sagen, dass wenn ich die verschiedenen Color Modes oder Color Scheme

10:04.880 --> 10:11.680
selbst implementiere, ich äußerst selten diese Media Query verwende per se, sondern

10:11.680 --> 10:17.480
meistens tatsächlich mit JavaScript einen Tockeler habe, der nachfragt, möchtest du

10:17.480 --> 10:23.560
Dark, möchtest du Light oder möchtest du Auto, weil so übersetzt wäre ja, Ad Media

10:23.560 --> 10:29.440
Prefers Color Scheme Dark, quasi so der Autotockel und da möchte ich normalerweise Nutzerinnen

10:29.440 --> 10:34.640
schon irgendwie die Chance geben, das umzuändern und da habe ich auch teilweise Erfahrungen

10:34.640 --> 10:40.520
gemacht, dass so ein zweiter Color Modus, ob der jetzt Dark ist oder keine Ahnung, was

10:40.520 --> 10:45.680
weiß ich, gelb oder braun, der muss schon auch recht gut designt sein, also das Design

10:45.680 --> 10:50.120
muss gut designt sein, ansonsten ist vielleicht dann doch nur der Light Mode besser.

10:50.120 --> 10:56.860
Mit dem Punkt, den du gerade gesagt hattest, man muss das ja ständig testen, das kann

10:56.860 --> 11:01.960
schon mal passieren, dass man da sonst eher was verhunzt und eine Nutzerin oder Nutzer

11:01.960 --> 11:06.800
kommt und sagt, hä, wieso ist die Seite einfach nur, da steht kein Text Hubsi, die Font Color,

11:06.800 --> 11:10.360
es ist gleich wie die Background Color, ja und so ein Dark Mode zu designen ist auch

11:10.360 --> 11:13.480
tatsächlich glaube ich so ein bisschen eine Herausforderung, man tut es nicht so oft und

11:13.480 --> 11:17.880
dann stellt man sich die Fragen, muss ich einfach nur invertieren oder muss quasi, wenn

11:17.880 --> 11:22.240
ich jetzt eine Modal offen habe, schon noch der Background ja dunkler sein auf dem Dunklen?

11:22.240 --> 11:27.600
Anstatt eben aufgehellt zu werden, weil du ja quasi invertierst, ne?

11:27.600 --> 11:32.160
Weil bei Twitter habe ich das glaube ich bei der Nachrichtenbox gesehen, dass die einen

11:32.160 --> 11:36.640
hellen Schatten hat und das finde ich teilweise relativ irritierend.

11:36.640 --> 11:40.320
Ja, in der Tat, ja.

11:40.320 --> 11:42.440
Andere Gedanken oder auch gleiche Gedanken?

11:42.440 --> 11:49.520
Ne, also da gebe ich dir absolut recht, also es gibt ja auch diesen, also es gibt ja diesen

11:49.520 --> 11:56.560
Dark Mode für Arme, also wo man quasi einfach hingeht und sowas macht wie ein Invert und

11:56.560 --> 12:03.520
dann haust du auf die gesamte Seite und dann nimmt man sich alle Bildelemente und Videoelemente

12:03.520 --> 12:09.360
und invertiert die wieder zurück und was man auch noch machen muss, ist, dass man nach

12:09.360 --> 12:15.440
dem Invertieren muss, kann man dann noch mit dem Pew-Filter die Farben wieder korrigieren,

12:15.440 --> 12:20.040
weil du möchtest ja, dass, sagen wir mal, grüne Sachen immer noch grün sind und rote

12:20.040 --> 12:26.000
Sachen immer noch rot, an sich gar nicht mal so schlecht aber dann im Detail merkst du

12:26.000 --> 12:31.680
dann so, ne, also es irgendwie funktioniert es nicht, weil es ist halt dann nicht nur

12:31.680 --> 12:38.720
das Farbrad, es ist dann die Sättigung der Farben, die dann sich ändert und das kannst

12:38.720 --> 12:44.840
du dann nicht mehr allgemein irgendwie drüber bügelnd korrigieren und darum eigentlich

12:44.840 --> 12:49.720
richtig sollte es so sein, dass man das auch dann dediziert designt und dann müsste man

12:49.720 --> 12:55.280
das eigentlich auch so das eigene Produkt immer in hell und in dunkel auf einem Bildschirm

12:55.280 --> 12:56.280
haben parallel.

12:56.280 --> 13:02.360
Ja, also die Webseite, an der ich jetzt seit über zwei Jahren arbeite, hat auch einen

13:02.360 --> 13:03.360
Dark Mode.

13:03.360 --> 13:11.480
Manchmal frage ich mich, ob das so eine Developer-Entscheidung war, also es kommen auch Entwickler und Entwicklerinnen

13:11.480 --> 13:17.200
auf unsere Seite und benutzen die und von daher dachten wir uns, es wäre doch so nett, wenn

13:17.200 --> 13:22.600
wir dann unseren Freunden und Kolleginnen und Kollegen aus anderen Firmen noch so einen

13:22.600 --> 13:23.600
Dark Mode schenken könnten.

13:23.600 --> 13:32.040
Also bei uns war das jetzt nicht Produkt- oder Design-getrieben, das kam schon aus der Developer-Ecke

13:32.040 --> 13:35.440
und dementsprechend stolper ich da auch immer wieder über Problemchen, es funktioniert

13:35.440 --> 13:39.520
für mich ganz gut, da ich tatsächlich einfach den Auto-Modus an hab und jetzt wird es eh

13:39.520 --> 13:43.360
super frühdunkel, das heißt ich teste schon automatisch, weil ich hab plötzlich um 16

13:43.360 --> 13:49.120
Uhr einen dunklen Screen und kann es sehen, ich hab teilweise, genau das war grad ein guter

13:49.120 --> 13:53.840
Punkt, den du gerade gesagt hast mit den Medien, denn wenn ich das über die Klasse steuer,

13:53.840 --> 14:00.040
also das heißt ich mach nicht Prefers Color Skin Mode, sondern ich setze je nach Javascript

14:00.040 --> 14:03.760
dann eben eine Klasse, die dafür sorgt, dass alles dunkel oder alles hell wird oder alles

14:03.760 --> 14:10.000
gelb oder alles braun, das hat zwei Problemchen, das eine ist Javascript muss es normalerweise

14:10.000 --> 14:16.400
erst laden, Möglichkeit, Lösung dafür Nummer eins, ich kann stattdessen statt Local Storage

14:16.400 --> 14:20.960
oder sowas reinzuspeichern, in die Cookies speichern und dann Server-Seite rendern, das

14:20.960 --> 14:25.480
funktioniert natürlich optimal bei Light und Dark, aber nicht bei Auto, weil bei Auto weiß

14:25.480 --> 14:29.920
ich ja nicht, was grad los ist, da muss ich es doch wieder per Javascript schreiben, also

14:29.920 --> 14:36.080
Lösung zwei, Crucial Javascript tatsächlich inline laden ist eine Möglichkeit, klingt

14:36.080 --> 14:40.040
aber so, hu, darf ich das, ist das jetzt so ein Fall?

14:40.040 --> 14:45.960
Und das zweite ist, das Picture Tag unterstützt ja auch die Prefers Color Scheme, oder?

14:45.960 --> 14:50.600
Dass es sagen kann, die Source ist jetzt dies oder die Source ist jetzt jenes, die Möglichkeit

14:50.600 --> 14:53.640
hab ich ja natürlich nicht mehr, wenn ich das einfach per Klasse setze, sondern dann

14:53.640 --> 14:57.880
müsste ich, was macht man dann, lade ich dann mit Javascript, schreibe ich dann erst die

14:57.880 --> 15:04.760
richtige, den richtigen Pfad rein oder mach ich den, aber das ist aber nicht gut, also

15:04.760 --> 15:07.920
ich mein man kann ja auch sagen, ich glaub das ist nicht gut, das kannst du mich vielleicht

15:07.920 --> 15:11.400
gleich verbessern, ich kann ja auch beide Bilder laden und eins auf Display None und

15:11.400 --> 15:16.160
eins auf Display Block setzen, bin mir gar nicht sicher, ob ein Bild geladen wird, wenn

15:16.160 --> 15:19.120
das auf Display none ist, oder browserklug genug sind, das nicht zu tun.

15:19.120 --> 15:25.000
Jaja doch, die laden das schon, außer du machst Loading gleich lazy.

15:25.000 --> 15:27.800
Loading, ja aber dann wird's immer noch geladen?

15:27.800 --> 15:38.480
Nee, dann wird's nicht geladen, weil, also wenn du das ganz normal einbenützt, ne nicht

15:38.480 --> 15:42.360
normal, also dann wird's sogar glaub ich nur eingebunden, wenn's wirklich sichtbar

15:42.360 --> 15:47.400
ist, also so ähnlich wie der Intersection Observer arbeitet, der auch nicht triggert,

15:47.400 --> 15:52.120
wenn du ein Display None hast, oder wenn du Wits oder Height auf Null hast, dann triggert

15:52.120 --> 15:59.640
der auch nicht, und was ja auch logisch ist, und genau bei, wenn du's aber nicht lazy

15:59.640 --> 16:08.000
machst, dann ist halt, du hast ja zwei HTML-Parser, so denen der quasi alles kann und weiß und

16:08.000 --> 16:12.920
der dafür dann eben einfach länger braucht, und dann hast du ja diesen Pre-Parser oder

16:12.920 --> 16:17.800
Ressourcenscanner, der quasi vorne weg rennt und schon mal so guckt, hey wo sind Style

16:17.800 --> 16:21.600
Sheets, wo sind Bilder, ich lad schon mal, ich schmeiß alles in die Network-Queue rein,

16:21.600 --> 16:28.360
damit das irgendwie bis hier mein großer Bruder oder meine große Schwester, die Super-Parserin

16:28.360 --> 16:35.960
da soweit ist, das dauert noch, und dieser Pre-Parser, der lässt die Finger halt von

16:35.960 --> 16:41.800
Bildern, die lazy markiert sind, aber nicht von Bildern, die nicht lazy sind, und weil

16:41.800 --> 16:47.640
er ebenso schnell aber dumm ist, kann er ja auch noch kein CSS-Parsen und kann ja auch

16:47.640 --> 16:52.600
noch nicht sagen, ist ein Bild jetzt irgendwie sichtbar oder nicht, oder ist das in Viewport

16:52.600 --> 16:56.720
oder nicht, und das ist eben erst bei lazy der Fall.

16:56.720 --> 17:02.920
Da hat er halt den Nachteil, dass lazy-Bilder auch tatsächlich erst geladen werden können

17:02.920 --> 17:12.000
vom Browser, wenn das Dom gebaut ist und der Rendertree gebaut ist, weil erst dann stellt

17:12.000 --> 17:14.440
sich eben heraus, also ist das Bild sichtbar oder nicht.

17:14.440 --> 17:22.520
Ein weiteres Problem ist, ob ich Bilder überhaupt tatsächlich manipulieren kann in dem Sinne

17:22.520 --> 17:30.960
oder darf, wir haben ja auf dem, auf unserer Seite auch viele Dateien, die Nutzer und Nutzerinnen

17:30.960 --> 17:36.240
hochladen und die können dann auch einen weißen Hintergrund haben, also jetzt nicht irgendwie

17:36.240 --> 17:41.040
schön transparent, wie wir das unser Design-Team und fragen, könnt ihr das genau schön ausschneiden

17:41.040 --> 17:45.760
und da, da, da, sondern da haben wir ja keinen Einfluss drauf, und da möchte ich eigentlich

17:45.760 --> 17:51.240
gar nicht drauf hoffen, dass am Ende das Richtige rauskommt, und das Zweite ist, wir

17:51.240 --> 17:58.080
hatten auch eine Sektion, wo wir Logos anderer Firmen angezeigt haben oder vielleicht auch

17:58.080 --> 18:02.440
hochladen durften, da wird es dann so ein bisschen heiklig, weiß einen zum Beispiel

18:02.440 --> 18:05.760
gar nicht, darf ich das Bild jetzt einfach invertieren, weil dann ist es ja nicht mehr

18:05.760 --> 18:11.280
das Original-Logo, manche bieten extra einen Dark-Mode-Logo noch zusätzlich an, manche

18:11.280 --> 18:17.760
nicht, also es ist ein bisschen tricky, ich habe gerade bei Notion geguckt und sehe, sie

18:17.760 --> 18:22.000
haben auf jeden Fall einen Dark-Mode, da muss ich das, da muss ich mal ausprobieren, was

18:22.000 --> 18:26.760
da eigentlich passiert, wenn ich da mehrere Bilder hochlade, ob sie da sagen, da geben

18:26.760 --> 18:31.360
wir uns Mühe, manchmal würde ich auch sagen, ja gut, wenn jemand halt ein Bild hochlädt

18:31.360 --> 18:37.960
mit einem weißen Hintergrund, ja, das ist halt so, ne?

18:37.960 --> 18:44.240
Ja, gut, Focus Visible, magst du uns erzählen, warum so viele Frontend-Entwickler und Erwicklerinnen

18:44.240 --> 18:47.480
auf Focus Visible gewartet haben und was es kann?

18:47.480 --> 19:01.640
Ja, also Focus Visible ist, dass der Browser diese Focus Visible Pseudoklasse dann aktiviert,

19:01.640 --> 19:08.880
wenn man nicht mit einem Pointer-Device unterwegs ist, also da gibt es ja jetzt nicht viel,

19:08.880 --> 19:18.160
es ist halt dann Tastatur und genau, dann kann man sich eben da dran hängen und sagen, ich

19:18.160 --> 19:27.760
gestalte oder ich nehme Outlines weg und bringe sie aber zurück, wenn Elemente eben diese

19:27.760 --> 19:34.000
Focus Visible Pseudoklasse bekommen, also man kann damit eben, man hat ja früher immer

19:34.000 --> 19:38.360
das Problem gehabt, dass irgendwelche Leute gesagt haben so, hey, das sieht immer ein

19:38.360 --> 19:44.280
bisschen blöd aus, wenn man hier irgendwas anklickt, dann ist da halt eine Outline drum

19:44.280 --> 19:50.520
oder dann ist da so ein gepunkteter Outline drum und jetzt kann man eben sagen, okay, mit

19:50.520 --> 19:56.520
Focus Visible gestalte ich diese Outline nur für den Fall, wo jemand die auch tatsächlich

19:56.520 --> 20:02.000
braucht, also nicht mit einer Maus arbeitet oder mit dem Finger und einen Focus Indikator

20:02.000 --> 20:03.000
braucht.

20:03.000 --> 20:08.320
Die lange Geschichte ist irgendwie doch deutlich kompliziert, das hat wohl auch richtig lange

20:08.320 --> 20:15.160
gedauert, dieses, das Focus Visible überhaupt zu sozusagen auf die Straße zu bringen und

20:15.160 --> 20:22.440
da würde ich verweisen auf einen anderen Podcast, nämlich die Igalia Chats und da gab es vor

20:22.440 --> 20:29.000
ein paar Monaten, also vielleicht vor zwei oder drei, gab es mal eine Folge zu genau

20:29.000 --> 20:36.400
diesem Thema und da war noch was vergessen, genau, aber da geht es ging es um diesen Themenkomplex

20:36.400 --> 20:40.800
und das umfasst dann doch ein bisschen mehr, als wir alle denken, genau.

20:40.800 --> 20:50.360
Gut, den verlinken wir dann gerne in den Notizen, ich würde jetzt auch dann weitergehen

20:50.360 --> 20:57.320
zu der Sektion der Selectors, aber noch einen Satz zu der Colorscheme, die man zum Beispiel

20:57.320 --> 21:02.360
auf light dark setzen kann, da habe ich auch, da verlinke ich auch einen Artikel in den

21:02.360 --> 21:09.600
Schaunotizen drüber, weil es da einen ziemlich, ziemlich guten Online gibt, der da alles

21:09.600 --> 21:14.880
drüber erklärt und ich vor kurzem gebraucht habe und diese eine Webseite erklärt alles,

21:14.880 --> 21:18.040
das ist jetzt zu viel, das möchte ich gerade kurz nicht zusammenfassen, das ist ein sehr

21:18.040 --> 21:22.040
langer ausgiebiger Artikel und dann kann man es kopieren, wenn man es braucht oder nicht

21:22.040 --> 21:23.560
kopieren, wenn man es nicht braucht.

21:23.560 --> 21:30.360
Ja cool, ja gerne, den kenne ich glaube ich auch nicht, genau, dann haben wir als nächstes,

21:30.360 --> 21:39.440
bei den ist, oh sorry, bei den Selectors würde ich dann auch gleich beim Darkmord bleiben,

21:39.440 --> 21:45.560
der verfolgt mich jetzt heute so ein bisschen, oh Moment, entschuldige, ich habe da was übersprungen,

21:45.560 --> 21:51.520
das waren die Other Features, das machen wir als Cliffhanger für später, wenn das kommt.

21:51.520 --> 22:03.600
So, Selectors fängt an mit dem Marker, den Doppelpunkt Marker, der könnte, der hätte

22:03.600 --> 22:08.080
vielleicht damals meinen Beruf erleichtern können, heutzutage weiß ich nicht, ob mir

22:08.080 --> 22:14.560
Sachen einfallen, wo ich ihn wirklich brauche, Marker kann ich dazu verwenden bei List Items,

22:14.560 --> 22:20.280
das könnte jetzt sein bei einer nummerierten oder unnummerierten Liste, aber zum Beispiel

22:20.280 --> 22:25.320
auch bei einer Summary, wo ich sowieso ein natives Akkordium habe, wo ich ja auch so

22:25.320 --> 22:30.640
einen Tockel habe, beziehungsweise nicht Tockel, sondern Marker, habe ich jetzt damit die Möglichkeit,

22:30.640 --> 22:38.640
mir meinen eigenen Marker per Content zu setzen und auch zu stylen wie eine Font Size oder,

22:38.640 --> 22:40.920
bin mir ziemlich sicher auch die Font Color.

22:40.920 --> 22:49.560
Ja, ich überlege gerade, also ich weiß, dass es so ein reduziertes Set an Properties sind,

22:49.560 --> 22:55.280
die man beim Marker benutzen kann, ja, also ich kann von mir sagen, dass ich, glaube

22:55.280 --> 23:01.920
ich, Marker noch nicht oft benutzt habe, vielleicht sogar gar nicht und auch nicht sehnsüchtig

23:01.920 --> 23:08.760
darauf gewartet habe, also ich kam schon so einigermaßen ohne klar, aber ist trotzdem

23:08.760 --> 23:14.560
gut, dass man jetzt sozusagen einen Anfasser hat für diese Böppel und Dinger.

23:14.560 --> 23:23.120
Ja, vielleicht sind wir im Web gerade einfach nur zu einer falschen Zeit, also wir haben,

23:23.120 --> 23:31.160
zumindest bin ich kaum noch auf normalen Webseiten, Dokumentenseiten unterwegs, sondern alles

23:31.160 --> 23:37.640
ist so ein bisschen app-mäßig, interaktiv, in verschiedenen Bereichen und Layouts aufgeteilt

23:37.640 --> 23:43.560
und zurzeit ist es, glaube ich, einfach super uncool, native Marker zu benutzen, sondern

23:43.560 --> 23:49.480
normalerweise ist es einfach List-Item-None, die meisten Listen, die ich baue, sind ehrlich

23:49.480 --> 23:56.960
gesagt ein Grid und falls es jemand nicht weiß, man muss nur, weil man ein Grid macht, muss

23:56.960 --> 24:01.840
man nicht einfach ein Diff-Element nehmen, man kann da ganz, ganz cool eine Unordered

24:01.840 --> 24:06.840
List nehmen und das Ganze in LEs packen, also es ist immer noch ein sehr schönes Grid,

24:06.840 --> 24:10.400
aber das sind natürlich keine Listen-Punkte, aber vielleicht wird die Zeit wieder kommen,

24:10.400 --> 24:16.120
wo wir einfach nur wieder Text auf einfarbiger Hintergrundfarbe lesen wollen und dafür finde

24:16.120 --> 24:20.560
ich es ja schon ziemlich spannend, nicht nur die Standard-Pöppel zu haben.

24:20.560 --> 24:27.240
Ja, ich denke mal, in so einem Zeitungsumfeld, wo man eben viel mit Typografie und sowas

24:27.240 --> 24:30.800
arbeitet, da ist es ja schon, da ist es bestimmt ganz gut, ja.

24:30.800 --> 24:35.920
Ja, genau, ja vielleicht auch im Print-Format könnte es spannend sein, dass man da jetzt

24:35.920 --> 24:40.760
keine komischen verpixelten Bilder versucht zu drucken, ja gut.

24:40.760 --> 24:47.680
Das zweite war für mich auch ein Riesenaufschrei in meiner Twitter-Bubble, ich weiß nicht,

24:47.680 --> 24:51.760
warum ich nicht drauf gewartet habe, irgendwie vielleicht habe ich was falsch gemacht, aber

24:51.760 --> 25:00.480
das ist das Doppelpunkt Has-Attribut, womit ich jetzt zum ersten Mal quasi die Reihenfolge

25:00.480 --> 25:07.800
sozusagen umdrehen kann, dass ich nicht nur sagen kann, ich möchte das Image stylen,

25:07.800 --> 25:11.840
wenn es in einem Anchor liegt, sondern ich kann auch sagen, ich möchte jetzt den Anchor

25:11.840 --> 25:18.440
stylen, wenn dieser Anchor ein Image hat, so boom, ich habe es leider noch nicht eingesetzt,

25:18.440 --> 25:24.440
ich hatte keinen Grund, aber vielleicht liegt es am Utility-CSS-Ansatz, den ich verfolge,

25:24.440 --> 25:26.880
dass ich grundsätzlich ein bisschen anders style.

25:26.880 --> 25:31.800
Ja, ja das ist in der Tat natürlich dann immer ein bisschen schwieriger so.

25:31.800 --> 25:37.040
Es funktioniert, es ist kein technisches Problem, technisch kann ich genauso gut bei Tailwind

25:37.040 --> 25:40.720
quasi diese ganzen Pseudo-Elemente verwenden.

25:40.720 --> 25:48.360
Genau, aber du musst halt dann, genau du hast halt keine Anfasser aus deinem oder du

25:48.360 --> 25:52.640
müsstest dir quasi ein Plugin bauen, damit du da wieder so quasi mit Klassen arbeiten

25:52.640 --> 25:59.720
könntest im Tailwind quasi einklang, aber das wird ja, denke ich, kommen, ist ja auch

25:59.720 --> 26:02.800
eine neue Version von Tailwind raus, weiß nicht, ob die da schon irgendwas haben.

26:02.800 --> 26:06.880
Die sind, ich bin mir bei Haze per se nicht ganz sicher, aber die sind wirklich relativ

26:06.880 --> 26:13.080
weit, also falls man da noch Vorurteile hat, die unterscheiden, man kann schon extrem viel

26:13.080 --> 26:21.280
von dem Advanced CSS auch mit Tailwind CSS umsetzen, nur was mir gerade auffällt ist,

26:21.280 --> 26:26.480
ich benutze Tailwind CSS ja auch nur im Umfeld von komponentenbasierten Frameworks, wie jetzt

26:26.480 --> 26:33.160
Svelte, Vue.js etc., und da habe ich eher die Situation meistens, dass ich per JavaScript

26:33.160 --> 26:39.440
meine Klassen setze und da quasi per JavaScript sage, wenn ich da jetzt drin ein Image erwarte,

26:39.440 --> 26:45.560
ich meine die Situation hatte ich tatsächlich einfach noch nicht wirklich, aber ja, dass

26:45.560 --> 26:50.600
ich die meisten Klassen setze, ich konditionell über JavaScript und nicht über Haze Attribute

26:50.600 --> 26:51.600
dann.

26:51.600 --> 27:01.360
Ja, also ich glaube Haze ist einfach schon richtig krass, also ist auch so toll, dass

27:01.360 --> 27:07.880
man da, ich glaube das war ja, ich glaube das war dann ein Apple Ingenieur, der irgendwie

27:07.880 --> 27:11.800
eine Idee hatte, wie man das dann doch eben performant umsetzen kann, weil das war eigentlich

27:11.800 --> 27:16.440
immer das Problem, warum, also der Wunsch danach, den gab es ja schon lange, aber das

27:16.440 --> 27:23.160
war immer so ein Performance-Problem eben quasi auf Kind-Elemente zu gucken, die in

27:23.160 --> 27:30.800
einem Element drin sind, so ein bisschen wie es früher ja auch kein Last Child gab, weil

27:30.800 --> 27:36.480
das schwierig zu implementieren war, weil man ja quasi mit dem streamenden HTML hatte, man

27:36.480 --> 27:40.520
mit jedem Child-Element, das dazukam, war dann das neue Child-Element auf einmal das

27:40.520 --> 27:45.960
Last Child und nicht mehr das davor, da musste man quasi die ganze Zeit neu-painten, so ein

27:45.960 --> 27:51.640
bisschen sowas war das und genau, ich habe schon so einige Demos gesehen, was damit möglich

27:51.640 --> 27:57.280
ist, also das ist so ein bisschen wie bei Flexbox und Grid, man muss so alte Dinge,

27:57.280 --> 28:02.400
die man noch so im Kopf hat, wo man weiß, so die Dinge kann man nicht machen und nur

28:02.400 --> 28:08.040
so kann man Dinge machen, das muss man alles so ein bisschen wieder sozusagen vergessen

28:08.040 --> 28:14.500
und auf Erkundungstour gehen und das ist schon krass, was manche Leute damit bisher schon

28:14.500 --> 28:20.600
gebaut haben, obwohl das halt total jung ist noch, ja freue ich mich auch drauf, also

28:20.600 --> 28:23.840
da lasse ich mich auch immer gerne inspirieren und ich habe es jetzt auch schon das erste

28:23.840 --> 28:31.600
Mal in Production geschippt für so einen kleinen Edge-Case, den ich damit abfange,

28:31.600 --> 28:37.840
der halt dann in Browsern, die das nicht unterstützen, so wie jetzt im Firefox, dann ist der Edge-Case

28:37.840 --> 28:48.240
halt immer noch so der Edge-Case, genau. Und dann haben wir als letztes noch in der Liste

28:48.240 --> 28:56.520
Wear, habe ich ebenfalls noch nicht eingesetzt, hast du Erfahrung? Ich habe das auch noch

28:56.520 --> 29:03.000
nicht eingesetzt, ich glaube aber, dass der Browser Support ziemlich gut ist und man kann

29:03.000 --> 29:11.960
damit eigentlich ganz gut so Resets bzw. Basis-Stylings machen und zwar aus dem Grund, weil Wear genauso

29:11.960 --> 29:21.440
wie der Sternchen, also der Universalselektor, also null Spezifität hat und so kann man

29:21.440 --> 29:26.720
quasi dann in einem Reset zum Beispiel alle seine Elemente einfassen in einem Wear, da

29:26.720 --> 29:34.000
auflisten und den bestimmten Styles geben und dann kann man später z.B. mit einem ganz

29:34.000 --> 29:41.640
normalen Elementselektor könnte man hingehen und eben diese Resets überschreiben, ohne

29:41.640 --> 29:52.280
dass man da so einen Spezifitätskrieg starten muss gegen den Reset. Genau und die Browser

29:52.280 --> 29:57.840
Compatibility Table sagt, alle aktuellen Browser unterstützen das. Ja und nicht nur

29:57.840 --> 30:04.280
alle aktuellsten, sondern auch so ein bisschen zurücklegend, also bei Chrome geht es bei

30:04.280 --> 30:11.600
knapp 90 los, bei Safari ist 14 auch dabei, da hat man mit Safari normalerweise eher andere

30:11.600 --> 30:16.560
Probleme, wenn man so ein Input Date hat oder ähnliches, aber der Browser Support ist auf

30:16.560 --> 30:25.000
jeden Fall vorhanden. Ja. So, dann sind wir durch diese Sektion auch schon durch und dann

30:25.000 --> 30:29.720
kann ich den Übergang von vorher machen, entschuldige, das war jetzt enttiefen. Bei

30:29.720 --> 30:38.120
den Other Features geht es los mit CSS Variablen und Custom Properties. Weil ich das jetzt gerade

30:38.120 --> 30:43.320
auch so vorlese, das ist tatsächlich was, wo ich ständig drüber stolper. Warum heißt

30:43.320 --> 30:48.080
es eigentlich CSS Variablen, aber irgendwie auch Custom Properties? Ist es das Gleiche?

30:48.080 --> 30:57.880
Oder sind Custom Properties ein Set? Nee, also eigentlich sind das Custom Properties und aber

30:57.880 --> 31:06.240
so deren Straßenname ist sozusagen CSS Variablen, aber und das liegt daran, also warum die nicht CSS

31:06.240 --> 31:12.800
Variablen offiziell heißen, liegt daran, dass das sozusagen ein Tiefstapeln der Fähigkeiten

31:12.800 --> 31:21.160
wäre, weil man dann ganz schnell so Analogien zu SAS hat und die Custom Properties, die können

31:21.160 --> 31:27.240
ja mehr, also das sind ja dann, also die können ja zum Beispiel, die können vererbt werden oder

31:27.240 --> 31:34.680
die haben einen Fallback-Mechanismus, wenn die eben nicht bestimmt sind und man einen var zu

31:34.680 --> 31:40.960
griff macht, kann man ja als zweiten Parameter sozusagen einen Fallback angeben und genau und

31:40.960 --> 31:49.360
sie können eben auch dynamisch verändert werden im Lifecycle des Dokuments und das ist halt so,

31:49.360 --> 31:57.360
das sind mehr Fähigkeiten als Less oder SAS Variablen hatten und man kann ja als Variablen

31:57.360 --> 32:04.000
nehmen, aber sie sind halt, sie können auch mehr und es gibt ja auch so Tricks, zum Beispiel von

32:04.000 --> 32:10.280
der Lea Wiru oder so dokumentiert, dass man das als Toggle Switches benutzen kann ganz gut.

32:10.280 --> 32:19.320
Indem man zum Beispiel der Off-Switch ist ein Leerzeichen, weil das ein gültiger Wert bei

32:19.320 --> 32:26.040
jeder CSS-Property sein kann, wenn er auch eben dann am Ende nichts bewirkt und die,

32:26.040 --> 32:32.160
dann kann man aber auch Initial wählen, was die Variabel dann sozusagen außer Kraft setzt und

32:32.160 --> 32:39.400
man kann dann hingehen und mit der var-Funktion diese Variable ansprechen und wenn da Initial

32:39.400 --> 32:44.360
drin steht, wird der Fallbackwert automatisch genommen und wenn eben das Leerzeichen drin ist,

32:44.360 --> 32:51.240
dann wird das Leerzeichen verwendet und also damit kann man halt dann quasi diesen Fallback an und

32:51.240 --> 32:58.320
aus toggeln und so, also das ist schon ganz cool. Die Geschichte hat mich gerade dran erinnert,

32:58.320 --> 33:07.000
dass es bei Svelte, wenn man in das HTML-Template dynamische Variablen einfügen möchte, hat sich

33:07.000 --> 33:12.200
Svelte ganz bewusst dazu entschieden, nur eine geschwungene Klammer zu verwenden, also schon

33:12.200 --> 33:17.480
eine vorne und hinten, aber jetzt nicht diese doppelgeschweifte Klammer, da das zu sehr an

33:17.480 --> 33:24.560
Handlebars erinnern würde und das kann ja auch viel, viel weniger. Okay, sehr gut, dann habe

33:24.560 --> 33:30.680
ich das auch gelernt. Die Custom Properties habe ich recht oft im Einsatz, klingt ein bisschen falsch,

33:30.680 --> 33:35.240
als würde ich da oft Sachen damit überschreiben und wieder überschreiben. Ich habe es in so ein

33:35.240 --> 33:42.120
paar Komponenten einfach drin, manchmal auch um Padding dynamisch zu setzen, ich glaube auch bei

33:42.120 --> 33:52.520
ein bisschen komplexeren, UI komplexeren Komponenten, wo ich teilweise auch Browser Colors mit, also so

33:52.520 --> 33:57.640
Mozilla und Chrome noch und Safari Sachen irgendwie noch einzeln setzen muss. Das kommt aber gar nicht

33:57.640 --> 34:02.920
so oft vor, sondern das, was ich vor allem mit den Custom Properties mache, ist es mir den

34:02.920 --> 34:10.720
Dark-Mode-Ticken generisch zu machen und hier, ich habe es ja vorher schon erwähnt, dass so eine

34:10.720 --> 34:16.680
Dark-Mode designtechnisch nicht einfach ist, denn es ist nicht einfach, wir invertieren die ganzen

34:16.680 --> 34:24.240
Farben und es ist vor allem auch nicht, jedes Mal, wenn wir jetzt im Light-Modus die blaue Farbe haben,

34:24.240 --> 34:30.640
haben wir im Dark-Mode die dunkelblaue Farbe. Manchmal ist es einfach ja, aber hier, aber hier

34:30.640 --> 34:35.200
halt nicht, aber hier brauchen wir jetzt einfach eine andere Farbe und da habe ich bei uns in der

34:35.200 --> 34:42.640
Codebase festgestellt und das kam erst nach der Erfahrung von Monaten, wo ich gemerkt habe, okay,

34:42.640 --> 34:47.960
jetzt ist mir schon recht auffällig, dass wir diese Farbe im Dark-Mode immer mit dieser Farbe

34:47.960 --> 34:55.400
ersetzen und aus diesen bestimmten Gruppen, die ich da sehen konnte, habe ich mir dann Custom

34:55.400 --> 35:05.640
Properties gemacht und das, die kann man nicht nur im AdMedia-Color etc. überschreiben, sondern ich

35:05.640 --> 35:09.680
kann tatsächlich ja auch vor das Doppel.Rule zum Beispiel auch noch einen Klassennamen setze

35:09.680 --> 35:14.360
und damit auch überschreiben. Dann habe ich so mein festes Set an, diese Farben immer mit

35:14.360 --> 35:20.560
diesen Farben übersetzen, aber manchmal meist dann doch noch mal explizit im Code und gvg andere

35:20.560 --> 35:27.320
Klassen und Attribute. Ja, das ist übrigens auch noch so ein spannender Use-Case, dass man

35:27.320 --> 35:34.320
Custom Properties ja auch unterschiedlich setzen kann, je nach Media-Query. Das ist ja auch so,

35:34.320 --> 35:40.480
genau, da kann man schon echt viel machen, also wir haben ja eben schon, ich hatte eben schon

35:40.480 --> 35:48.760
Lea Weru genannt, die hat einen tollen Talk auf dem CSS-Stay auch wieder abgeliefert über eben

35:48.760 --> 35:54.640
nur Custom Properties, also dass man da auch einfach wahnsinnig viel mehr machen kann,

35:54.640 --> 36:00.000
dass man eben auch Custom Properties in Custom Properties verwenden kann und diese dann auch

36:00.000 --> 36:04.800
wieder irgendwo verwenden kann. Und was wir hier auch in der Liste haben, es gibt ja noch diese

36:04.800 --> 36:14.880
aus CSS Houdini, diese Ad-Property-Geschichte, da hatten wir auch mal eine Houdini-Folge vor

36:14.880 --> 36:24.880
vielleicht ein paar Monaten, da waren wir glaube ich auch beide Teil davon und wo man eben Custom

36:24.880 --> 36:32.360
Properties dann typen kann, das ist halt auch toll und dann, wenn sobald der Type da ist,

36:32.360 --> 36:41.600
dann kann man die eben auch animieren, was vorher nicht ging. Ja und wie du schon vorher auch schon

36:41.600 --> 36:47.720
erwähnt hast, bei der Hintergrundfarbe, bei meinem Dark Mode konnte ich dann unsere, was weiß ich,

36:47.720 --> 36:54.520
Grey 9100 Farbe setzen, aber im Light-Modus konnte ich sie zum Beispiel einfach weglassen, weil es

36:54.520 --> 37:00.040
ist ja, da hatte ich ja keine, also ich muss nicht unbedingt jetzt White als Background-Color setzen,

37:00.040 --> 37:06.320
sondern da war halt nichts vorhanden, also funktioniert es auch weiterhin, was schon sehr

37:06.320 --> 37:13.080
gut ist. Während wir uns jetzt gerade so unterhalten, fällt mir aber doch durchaus auf und ich frage mich,

37:13.080 --> 37:18.120
ob CSS ein bisschen kompliziert geworden ist, eigentlich war es auch schon immer kompliziert,

37:18.120 --> 37:27.120
falls jetzt jemand hier noch unerfahren ist im Web-Development unterwegs ist, es ist vollkommen

37:27.120 --> 37:33.400
okay, sehr viele Sachen von die, die wir gerade besprechen, vielleicht auch alle davon nicht zu

37:33.400 --> 37:39.400
kennen und man kommt schon sehr weit mit CSS, also ich, wie gesagt, ich setze vielleicht von dem,

37:39.400 --> 37:44.360
was wir bisher besprochen haben, auch mit Teil 1, keine Ahnung, ich kann jetzt nur grob raten,

37:44.360 --> 37:48.920
aber ich glaube schon ein Viertel wäre schon hohes, na nicht mal wahrscheinlich, dass ich diese

37:48.920 --> 37:57.160
Funktionen oder Attribute oder Queries überhaupt einsetze. Zum Beispiel das nächste, Property,

37:57.160 --> 38:06.920
kannst du erzählen, was AddProperty ist und macht? Genau, das ist tatsächlich das, was ich meinte,

38:06.920 --> 38:14.960
also dieses, dass du Properties typen kannst, also du kannst quasi nachträglich eine Property

38:14.960 --> 38:24.680
set-upen sozusagen, weil sonst ist die einfach quasi dummer String und dieser AddProperty,

38:24.680 --> 38:34.840
AddRule, kannst du eben sagen, hey, die CustomProperty mit dem Namen, die soll vom Typ,

38:34.840 --> 38:41.760
also die ist, jetzt ich sag's dir, dann weißt du Bescheid, die ist vom Typ Color, das also behandelt

38:41.760 --> 38:50.240
die so und dann kannst du noch sagen, ist das eine Property, die sozusagen vererbbar ist in

38:50.240 --> 38:55.760
der Kaskade oder nicht, also haben wir auch bei anderen Properties, dass es manche gibt,

38:55.760 --> 39:03.760
die eben sich runter vererben oder manche andere eben nicht, also zum Beispiel wäre Font Size,

39:03.760 --> 39:10.520
vielleicht, das vererbt sich, aber Display Flex nicht, weil da sind ja die Kinder nicht auch

39:10.520 --> 39:17.000
automatisch dann auf diesem Display Mode, genau, dann kann man noch eine Initial Value setzen,

39:17.000 --> 39:26.040
wenn die Property eben jetzt irgendwie gar nicht belegt ist, genau und sobald man die getypt hat,

39:26.040 --> 39:32.200
dann kann man die in der Animation zum Beispiel verwenden und dann weiß der Browser, aha, okay,

39:32.200 --> 39:38.840
das ist eine Farbe, dann weiß ich auch, wie ich interpolieren muss zwischen Start und Endwert,

39:38.840 --> 39:45.120
während vorher, als es eben dieses AddProperty noch nicht gab und wir das noch nicht benutzen

39:45.120 --> 39:51.640
konnten, um eine Property zu typen, der Browser gesagt hat, keine Ahnung, ich kann jetzt versuchen,

39:51.640 --> 39:58.080
irgendwie rauszufinden anhand von irgendwie Raute oder so, dass es eine Farbe ist, aber das

39:58.080 --> 40:05.160
probiert er eben nicht, er sagt, für mich ist jede Custom Property, die nicht getypt ist, ein String

40:05.160 --> 40:11.040
und wenn du das animieren willst, dann ist es einfach ein harter Cut von A nach B, irgendwann

40:11.040 --> 40:18.360
an der 50% Marke, was aber ganz cool ist an dieser Tatsache, dass für den Browser eine Custom Property

40:18.360 --> 40:27.760
ein String ist, du kannst, das machen die Tailwind Leute auch, du kannst ganz cool Farben

40:27.760 --> 40:37.440
composen, nämlich du kannst hingehen und kannst zum Beispiel in eine Custom Property nur, also den

40:37.440 --> 40:46.720
Teil von RGBA Farbe zum Beispiel also reinstecken, der die R, G und B Werte darstellt, also du könnt

40:46.720 --> 40:58.280
zum Beispiel machen Custom Property Doppelpunkt 255,255,255, wer dann quasi weiß, aber du machst

40:58.280 --> 41:04.000
nicht RGB oder RGBA oder so, sondern du hast nur diese drei Werte und die Kommata und dann kannst

41:04.000 --> 41:10.520
du später eben hingehen und zu einer Farbe definieren mit RGBA Klammer auf und dann setzt

41:10.520 --> 41:17.520
du da war und die Custom Property rein und machst dann noch mal Komma 1, dann wäre die quasi

41:17.520 --> 41:29.320
komplett weiß und nicht durchsichtig oder du kannst hingehen und Komma eben 0,5 machen Klammer zu und

41:29.320 --> 41:36.480
dann hast du also ausgehend von dieser einen Custom Property eine halbtransparente Farbe erzeugt,

41:36.480 --> 41:42.560
das finde ich eigentlich auch echt richtig cool und da ist es halt von Vorteil, dass dem Browser das

41:42.560 --> 41:50.960
alles irgendwie Schnuppe ist. Ja das stimmt, das ist dann von Vorteil, also wie wir sehen ein weiteres

41:50.960 --> 42:00.880
Beispiel wie CSS noch mächtiger wird sogar mit Typisierungen. Das nächste Attribut ist das Add

42:00.880 --> 42:07.840
Supports, da habe ich auch im Teil eins drüber gesprochen über den Background Blur, den ich im

42:07.840 --> 42:12.800
Einsatz hatte und genau dafür habe ich dieses Add Supports benutzt, um zu schauen wird dieser

42:12.800 --> 42:21.200
Background Blur den überhaupt unterstützt, weil wenn nicht kann der sonst einen relativ kontrastlosen

42:21.200 --> 42:27.720
Effekt ergeben, weil dann wenn ich zum Beispiel jetzt einen weißen Farbe auf weißer Farbe habe

42:27.720 --> 42:32.040
und die eine ist dann irgendwie halt 80 Prozent transparent damit der Blur gut ausschauen würde,

42:32.040 --> 42:37.920
wenn er denn da wäre, dann ist es natürlich dann ist es einfach viel zu wenig Kontrast und dann

42:37.920 --> 42:43.080
kann ich rausfinden wird es unterstützt und falls nicht dann, was weiß ich, dann mache ich halt 100

42:43.080 --> 42:50.120
Prozent Background Color und eine Border irgendwie drunter, um das nachzuschauen. Hier jetzt zum

42:50.120 --> 42:54.800
Beispiel bei dem Server war es mit DisplayTableCell und DisplayListItem, dass ich dann bestimmte

42:54.800 --> 43:02.160
Sachen vergeben kann, also so die klassische Feature Detection. Ich weiß nicht ob ihr da noch

43:02.160 --> 43:15.240
irgendwas zu sagen möchtest, sonst? Ich benutze die gerne und viel. Ja, ein gutes Ding. Und vielleicht

43:15.240 --> 43:22.440
als Ergänzung, es gibt jetzt auch Add Supports und da gibt es die die Selektor Funktion und dann

43:22.440 --> 43:30.960
kannst du sagen, kannst eben auch auf die Unterstützung von Selektoren testen. Das muss ich sagen,

43:30.960 --> 43:37.080
brauchte ich bisher jetzt noch nicht so viel. Ich überlege auch, wann ich das einsetzen würde,

43:37.080 --> 43:42.280
kann ich nicht sagen, aber es ist auf jeden Fall jetzt noch neu dazugekommen, dass man das auch

43:42.280 --> 43:53.360
Feature Detecten kann. Gut, ansonsten sehe ich in der Liste einige Dinge, die ich nicht verwende.

43:53.360 --> 43:58.920
Ich mache jetzt einfach mal das letzte, das ich verwende und danach übergebe ich an dich. Das

43:58.920 --> 44:07.160
letzte von meiner Seite werden die CSS Comparison Functions wie Min, Max oder Clamp. Clamp, super

44:07.160 --> 44:13.720
mächtig. Ich habe relativ selten das Problem, dass ich es verwenden müsste, die ich eher im

44:13.720 --> 44:19.400
Einsatz habe, ist es Min, Max zu berechnen. Ich habe auch jedes Mal in meinem Kopf das Problem,

44:19.400 --> 44:24.680
brauche ich jetzt Min oder brauche ich jetzt Max. Eigentlich ist es sehr eindeutig, aber jedes Mal

44:24.680 --> 44:33.040
muss ich mir danach nachdenken und ausprobieren, ob ich jetzt richtig bin. Das ist so oft bei Boxen,

44:33.040 --> 44:38.720
die ich zum Beispiel habe, was machen die meistens? Die sind meistens fixiert und ich kann sie dann

44:38.720 --> 44:45.280
innerhalb scrollen mit einem Overflow Setting. Da ist dynamischer Content drin und ich bin mir

44:45.280 --> 44:51.200
einfach nicht sicher, wie groß das ist. Da gebe ich dann meistens entweder Min oder Max Werte an,

44:51.200 --> 45:01.560
dass ich sagen kann, ich möchte mindestens 300 Pixel Höhe haben. Funktioniert aber, also ich

45:01.560 --> 45:06.320
habe, meine ich jetzt nicht so wie Min Height, sondern ich habe hier auch dynamische Werte drin,

45:06.320 --> 45:11.080
die dann zum Beispiel, das eine ist Pixel und das andere ist zum Beispiel Viewport Width oder

45:11.080 --> 45:16.360
Viewport Height und dementsprechend sage ich, du bist so und so viel von der View Height,

45:16.360 --> 45:22.720
aber wenn du eh schon so klein bist, weil alles ganz klein gezogen wurde von dem Browser Fenster,

45:22.720 --> 45:29.920
du solltest schon mindestens 300 Pixel groß sein. Ja genau und man macht ja dann immer so,

45:29.920 --> 45:38.800
wenn du quasi den kleineren der beiden, also quasi wenn du das Maximum begrenzen willst,

45:38.800 --> 45:42.760
brauchst du die Min Funktion und wenn du das Minimum begrenzen willst, brauchst du die Max

45:42.760 --> 45:46.920
Funktion und das ist immer so ein bisschen irritierend. Ja es ist es ist komplett logisch,

45:46.920 --> 45:56.440
aber genau, mein Kopf will da immer nicht so gleich ganz mitspielen. Ja ja Klemp ist ja ganz

45:56.440 --> 46:04.000
gut für so, weiß ich nicht, ich glaube das nennt sich Fluid Typography, also dass du quasi sagst,

46:04.000 --> 46:12.960
ich möchte so die Schriftgröße orientieren, also verankern an der an der zur Verfügung stehenden

46:12.960 --> 46:22.720
Viewport Größe, aber möchte sicherstellen, dass sie nicht kleiner wird als X und größer als Y,

46:22.720 --> 46:28.800
da ist Klemp ganz gut vielleicht noch mit dem Hinweis verbunden, dass man die Schrift,

46:28.800 --> 46:33.600
dass man also die Schrift nicht nur an den Viewport koppeln sollte, sondern auch immer noch eine

46:33.600 --> 46:42.640
quasi eine am besten eine Rem Komponente noch hinzuaddieren sollte. Genau und da vielleicht

46:42.640 --> 46:50.640
noch abschließend der Hinweis, dass Min, Max und Klemp alle quasi Kalk schon beinhalten,

46:50.640 --> 46:57.680
das heißt also wenn ihr einen der Werte mit Kalk da reinschreiben wollt, dann braucht ihr das nicht,

46:57.680 --> 47:04.120
weil dann könnt ihr also dann könnt ihr Kalk die Funktion weglassen und einfach die Berechnung als

47:04.120 --> 47:14.520
Wert reinschreiben und das ist dann sozusagen kommt dann frei Haus noch dazu. Gut, dann haben

47:14.520 --> 47:26.280
wir auf dieser Seite hätten wir noch übrig willChange, addLiar, das Pseudo Element Part,

47:26.280 --> 47:43.360
die trigonometrischen Funktionen, Sinus, Cosinus und Tangos, CSS and Nesting, Image und Image Set.

47:43.360 --> 47:51.240
Ja, können wir ja schnell drüber fliegen, also willChange finde ich ganz schlimm, benutze ich nie,

47:51.240 --> 47:58.600
berate ich auch immer von ab, ist der allerletzte Dreck, weil man irgendwelche Browserheuristiken

47:58.600 --> 48:06.280
damit triggert, die man am Ende sich oder Geister ruft, die man dann wieder loswerden will. Genau,

48:06.280 --> 48:15.000
Cascade Layers sind spannend, da könnte man, da würde ich jetzt auf einen Talk von Brahmos

48:15.000 --> 48:26.880
Van Dam verweisen, CSS Café, der super war, genau ich, also das ist spannend vor allem für Leute,

48:26.880 --> 48:35.120
die vielleicht irgendwie Komponentensysteme bauen, vielleicht auch so White Label Geschichten. Genau,

48:35.120 --> 48:39.320
ich weiß noch nicht genau, wann ich das mal einsetzen werde, aber es auf jeden Fall gut zu

48:39.320 --> 48:49.360
wissen. Genau, Shadow DOM Part, die Part, ja das ist eine Pseudo Element Funktion, da kann man dann

48:49.360 --> 48:58.440
eben in seinem Shadow DOM gekapselten Konstrukt bestimmte Teile markieren, als von außen eben

48:58.440 --> 49:04.160
erreichbar und gestaltbar und das die erreicht und gestaltet man von außen eben mit dieser Part

49:04.160 --> 49:13.440
Funktion. Venus, Cosinus, Tangents ist vielleicht mal irgendwann interessant, wenn man so, ja wenn

49:13.440 --> 49:20.160
man ein bisschen komplexere Transforms machen will, denke ich. Ich hatte mal die Idee, wenn die da

49:20.160 --> 49:24.160
sind, das ist aber so viel Arbeit, dass ich es wahrscheinlich nicht machen werde, aber ich

49:24.160 --> 49:31.640
hätte ja gerne mal so eine Art komplexe Berechnung dann gebanct zwischen JavaScript und CSS,

49:31.640 --> 49:37.600
um zu gucken, wer dann schneller ist, wenn du diese ganzen Funktionen hast, weil du hast ja

49:37.600 --> 49:43.480
dann auch Calc und Min und Max und du kannst auch runden mittlerweile und absolut gibt's, geht auch

49:43.480 --> 49:49.400
schon und das fände ich halt ganz spannend, ist aber unfassbar viel Arbeit, so ein Konstrukt

49:49.400 --> 49:53.720
erst mal zu bauen, was dann auch lang genug rechnet, dass man da überhaupt einen Unterschied

49:53.720 --> 50:02.280
messen kann und darum werde ich das wohl nie machen. Genau und CSS-Nesting finde ich okay,

50:02.280 --> 50:07.760
haut mich aber jetzt auch nicht so dermaßen vom Hocker, weil man soll ja eh nicht so tief

50:07.760 --> 50:16.560
nesten und ist leider aber auch unglaublich nicht abwärts kompatibel, so dass es noch 10 Jahre dauert,

50:16.560 --> 50:24.640
bis man da wahrscheinlich genessetes CSS ausliefern wird. Genau, dann gibt es Image Set,

50:24.640 --> 50:32.760
das ist so eine Art Source Set für Bild Properties, also wo man irgendwie bisher URL benutzt hat,

50:32.760 --> 50:42.400
gibt es eigentlich auch schon ziemlich lange, aber mit WebKit-Prefix. Genau und dann gibt es

50:42.400 --> 50:49.280
noch abschließend hier auf der Seite die Image Funktion, die eigentlich ein Ersatz für URL ist

50:49.280 --> 50:55.840
und erst mal grundsätzlich ähnlich arbeitet und das ist quasi so ein, die Browser-Ersteller

50:55.840 --> 51:05.280
brauchten das sozusagen als Escape-Hatch, weil URL hat den Nachteil, dass du kannst URL eben,

51:05.280 --> 51:12.160
oder das, was in der Klammer steht, kannst du eben mit Anführungszeichen schreiben und ohne und diese

51:12.160 --> 51:18.400
Tatsache, dass das geht, macht das Parsen davon so kompliziert, dass man dann nicht in der Lage war,

51:18.400 --> 51:24.760
da neue Funktionen aufzusatteln, weil man eben nicht wusste, ist das jetzt quasi noch eine URL

51:24.760 --> 51:30.560
oder ist das jetzt schon, ist das jetzt ein weiterer Wert und darum hat man gesagt, okay,

51:30.560 --> 51:37.000
dann müssen wir dafür eine neue Funktion sozusagen aus der Taufe heben, die Image heißt und da kann

51:37.000 --> 51:42.240
ich auch eine URL reintun, aber in Anführungszeichen nur, aber ich kann halt dann auch noch weitere

51:42.240 --> 51:48.480
Sachen machen oder ich kann zum Beispiel auch eine Fallback-Farbe definieren oder ich kann auch

51:48.480 --> 51:57.480
ein Hintergrundbild erzeugen, das nur aus der Farbe Blau besteht und aber sich sonst wie ein

51:57.480 --> 52:05.560
Bild verhält, aber ich mach das einfach in CSS, nämlich Image, Klammer auf Blue mache. Genau,

52:05.560 --> 52:11.960
das wären so die Dinge, die es hier gibt. Die letzten beiden sind glaube ich aber auch

52:11.960 --> 52:18.520
Null Supporter, also Image ist sowas von überhaupt gar nicht supported und Image Set eben nur mit

52:18.520 --> 52:28.200
Präfix in Safari und Chrome. Ja, dann vielen Dank für die Zusammenfassung, da habe ich gar

52:28.200 --> 52:34.480
nichts mehr weiter hinzuzufügen, sondern würde weitergehen zu den CSS-Frameworks. Wir haben am

52:34.480 --> 52:40.520
Anfang noch gar nicht erwähnt, das Survey ist zu dem Zeitpunkt, zu dem wir diese Revision hier

52:40.520 --> 52:46.440
aufnehmen, schon geschlossen. Die Ergebnisse liegen aber leider noch nicht vor und gerade

52:46.440 --> 52:50.800
bei den CSS-Frameworks, da finde ich es doch eher spannend, jetzt tatsächlich schon die Ergebnisse

52:50.800 --> 52:55.160
zu sehen, also da würde ich auch super gerne dann nochmal drüber sprechen, sobald die Ergebnisse

52:55.160 --> 53:02.400
da sind. Wir könnten sie jetzt mal ein bisschen bei uns anschauen, was wir eigentlich benutzen,

53:02.400 --> 53:10.720
benutzt haben, kennen, gar nicht kennen und zwar gehen wir dann davor, ich lese mal einfach von

53:10.720 --> 53:15.760
oben nach unten vor, das sind jetzt hier so zehn Stück und ich bin einfach, ich wäre einfach so

53:15.760 --> 53:20.880
gespannt darauf, was du jetzt sagst und was das, was die Ergebnisse später sagen, weil man ja

53:20.880 --> 53:27.720
doch immer wie gesagt eine Bubble drin ist und hier geht es nämlich los mit Bootstrap und ich

53:27.720 --> 53:33.200
kann mir so ein bisschen vorstellen, dass das so ein bisschen ist wie jQuery oder PRP, das ist

53:33.200 --> 53:39.360
tot, das gibt es nicht mehr und eigentlich benutzen 99% oder zumindest mal 90% der Webseiten halt

53:39.360 --> 53:44.800
immer noch jQuery und PRP und sie sind sowas von gar nicht tot und Bootstrap ist für mich so ein

53:44.800 --> 53:50.320
Klassiker der CSS-Frameworks, vielleicht sogar das erste, was ich verwendet habe, BEM ist ja

53:50.320 --> 53:57.240
kein Framework, das ist ja eine Namenskonvention, von daher würde ich sagen, I used it, would not

53:57.240 --> 54:03.920
use it again, allerdings bin ich hier wirklich noch bei Bootstrap von vor x Jahren, ich habe

54:03.920 --> 54:12.360
gehört, dass sich das auch deutlich weiterentwickelt hat und verbessert hat. Ja, also ich habe das

54:12.360 --> 54:21.200
tatsächlich auch hier so ausgewählt, aber ich bin generell kein, ich nutze halt keine CSS-Frameworks,

54:21.200 --> 54:29.600
das ist halt irgendwie, das bin halt nicht ich, außer Tailwind. Tailwind ist doch kein, Moment,

54:29.600 --> 54:36.520
da muss ich jetzt, Entschuldigung. Na ja, hier steht ja CSS-Framework, steht ja hier. Und ich

54:36.520 --> 54:44.760
wollte gerade sagen, also Bootstrap ist ja eigentlich eine UI-Library gewesen, aber ich

54:44.760 --> 54:49.720
glaube, Bootstrap ist hier eine Liste drin, weil das gleichzeitig auch, also du kannst das auch

54:49.720 --> 54:58.920
nur als Utility-Framework benutzen, ähnlich wie Tailwind. Also das ist so ein bisschen underrated,

54:58.920 --> 55:06.520
was das da kann. Und ich glaube, so ist das hier aufzufassen und da ist Bootstrap auch jetzt

55:06.520 --> 55:13.000
irgendwie gar nicht so schlecht. Trotzdem, wenn ich schon so ein Utility-Class-Framework benutzen

55:13.000 --> 55:20.000
würde, dann ist Tailwind einfach the way to go. Die anderen, die kenne ich halt auch gar nicht und

55:20.000 --> 55:24.640
ich habe überhaupt keinen Antrieb, die mir anzugucken, tatsächlich. Gut, da kommt es vielleicht

55:24.640 --> 55:30.520
wirklich dann drauf an, was die eigenen Ziele sind, die man verfolgt. Also wenn es jetzt drum

55:30.520 --> 55:37.160
gehen würde, zum Beispiel für mich selber so interne Tools zu schreiben oder für die Firma

55:37.160 --> 55:43.760
interne Tools zu schreiben, dann würde ich da wahrscheinlich nicht das CSS selber machen, außer

55:43.760 --> 55:49.400
ich haue es wirklich als einen Prototypen runter und mache dann wirklich mit Tailwind CSS, wo ich

55:49.400 --> 55:55.920
mir noch nicht mal eine CSS-Datei öffnen muss. Aber da finde ich generell jetzt UI-Frameworks

55:55.920 --> 56:00.200
auch mal gar nicht schlecht, wenn man sich da das Leben einfach halten möchte. Wir haben es zum

56:00.200 --> 56:05.960
Beispiel einfach bei unserem Admin-Interface tatsächlich mit Bulma in Einsatz. Nicht, dass ich

56:05.960 --> 56:10.920
jetzt sagen möchte, dass Bulma jetzt noch, das hatte seinen Sinn und Zweck. Ich glaube aber,

56:10.920 --> 56:16.640
das ist immer noch in dem Sinne supported, aber jetzt nicht mehr modern. Hat auch teilweise

56:16.640 --> 56:22.920
Utility-Einstellungen. Also ich kann so Margin-Botten und Margin-Top kann ich schon auch angeben. Also

56:22.920 --> 56:27.200
so ein bisschen was kann es auch in die Richtung. Ansonsten ist es sehr klein und beschränkt, was

56:27.200 --> 56:31.440
aber für unseren Fall jetzt eben genau das Richtige war, weil man muss auch dann nämlich nicht für

56:31.440 --> 56:37.280
lernen. Man braucht keinen Frontend-Entwickler, Entwicklerinnen, um die Klassen zu setzen. Das

56:37.280 --> 56:42.320
kann komplett Full-Stack-mäßig benutzt werden. Hat man eben diese Klassen wie Button, isPrimary,

56:42.320 --> 56:48.400
isSecondary, die sind recht selbsterklärend. Und dadurch, dass die Möglichkeiten so limitiert

56:48.400 --> 56:55.280
sind, limitiere ich mir halt auch die Möglichkeiten zu versuchen, was Cooles zu machen, was dann aber

56:55.280 --> 57:01.000
doch nicht cool wird, sondern da kann ich mir dann doch vielleicht auch Zeit sparen. Ja, also zum

57:01.000 --> 57:06.600
Zeit sparen sind die super. Bootstrap habe ich genau deswegen jetzt auch wieder so gehört, dass es

57:06.600 --> 57:11.920
eben doch echt aufwärts ging und auch schon vor Jahren ging. Nicht nur jetzt erst kürzlich. Dadurch,

57:11.920 --> 57:17.640
dass sie eben auch echt wieder aufgeholt haben und nicht dieses, wie es vor sieben Jahren war,

57:17.640 --> 57:22.760
mit yet another Bootstrap-Website, wo halt alle Webseiten gleich aussahen und alle den gleichen

57:22.760 --> 57:28.120
blauen Button hatten. Da muss ich meine kleinen Vorurteilchen immer noch loswerden. Das ist bei

57:28.120 --> 57:35.120
mir einfach mit dem Namen zu verknüpft. Etwas, was ich jetzt persönlich, ich meine, ich kenne es

57:35.120 --> 57:43.160
aber so gar nicht weiter angeschaut habe. Im Detail ist Materialize CSS, wenn dann eher so als

57:43.160 --> 57:49.120
Inspiration, dass ich es mir doch angeschaut habe, aber ich habe es nie benutzt in dem Sinne. Ja,

57:49.120 --> 57:54.880
wir sind da einfach vielleicht gar nicht so furchtbar bewandert, aber vielleicht sind unsere

57:54.880 --> 58:01.240
Hörerinnen und Hörer da bewanderter und haben irgendwie noch ein, zwei gute Hinweise zu den

58:01.240 --> 58:07.640
hier gelisteten CSS-Frameworks oder UI-Frameworks oder wie auch immer man das jetzt hier betrachten

58:07.640 --> 58:14.680
muss. Und ihr könnt da auch eins empfehlen aus bestimmten Gründen. Ja, es wäre jetzt ein bisschen

58:14.680 --> 58:17.800
langweilig, wenn ich jetzt durch die Liste durchgehe und jedes Mal sage, benutze ich nicht,

58:17.800 --> 58:25.600
benutze ich nicht. Ich lese nochmal kurz alle vor. Bootstrap, Materialize CSS, Ant Design, Semantic,

58:25.600 --> 58:38.520
UI, Bulma, Foundation, UI-Kit, Tachions, Prima und Tailwind CSS, Pure CSS und Halfmoon. Was ich

58:38.520 --> 58:46.320
finde, was bei der Liste fehlt, ist Windy CSS. Was ich jetzt gerade allen Tailwind-Freunden doch mal

58:46.320 --> 58:55.880
ans Herzen legen würde, mal reinzuschauen, was Windy CSS ist. Das kommt auf dem im nächsten

58:55.880 --> 59:01.920
Kapitel tatsächlich. Das heißt nämlich CSS in JS. Also vielleicht ist das irgendwie,

59:01.920 --> 59:08.640
ist das dann auch so ein Ding, keine Ahnung. Ja, muss ja wahrscheinlich. Genau, aber auch hier bin

59:08.640 --> 59:14.040
ich komplett raus und tatsächlich, das hatte ich auch mal irgendwann zu dir gesagt, ich glaube ja,

59:14.040 --> 59:23.960
dass die Leute, die vielleicht eben in dem Kapitel und hier in diesem Kapitel ganz viel kennen

59:23.960 --> 59:30.600
und sagen so, ja, habe ich schon mitgearbeitet, wahrscheinlich auch eher weniger Low-Level-Kram

59:30.600 --> 59:37.520
kennen und machen. Also das ist natürlich, ihr schreibt uns, wenn das komplett falsch ist,

59:37.520 --> 59:45.560
ja, also ich würde aber sagen, die einen sind so mehr High-Level, die benutzen quasi so die

59:45.560 --> 59:53.840
fertigen Konstrukte und wollen Strecke machen und dann gibt es eben so Nerds wie mich und Vanessa

59:53.840 --> 01:00:02.000
vielleicht, die dann lieber irgendwie alles handkneten und langsamer sind, aber dann ganz

01:00:02.000 --> 01:00:09.400
genau irgendwie wissen, was sie wollen und eben was sie nicht wollen. Ja, jetzt hatte ich auch

01:00:09.400 --> 01:00:13.400
gerade irgendwie gesagt, wozu auch, aber ich weiß gar nicht, warum, weil verbinden kann man ja,

01:00:13.400 --> 01:00:21.560
das eine schließt immer das andere nicht aus. Das ist eine Sache, die mich bei jetzt Tailone CSS

01:00:21.560 --> 01:00:28.000
von beiden Seiten, also von extrem dafür und extrem dagegen so ein bisschen stört. Es gibt

01:00:28.000 --> 01:00:33.400
ja keinen Grund, warum ich nur weil ich jetzt Utility CSS normalerweise schreibe, gibt es ja

01:00:33.400 --> 01:00:38.760
keinen Grund, der mich aufhalten würde, nicht auch mal eine Komponentenklasse zu schreiben und

01:00:38.760 --> 01:00:47.680
die anzuhängen. Es ist halt eher schwierig zu argumentieren, warum benutze ich das jetzt als

01:00:47.680 --> 01:00:53.760
Klasse und warum mache ich das hier und ich finde es nur dann problematisch, wenn man wieder eine

01:00:53.760 --> 01:01:00.520
Klasse, Komponentenklasse schreibt und die anzuhängen, weil man die Dokumentation von

01:01:00.520 --> 01:01:05.760
Tailone nicht gelesen hat und nicht wusste, wie man es genau schreiben musste. Dabei sind da auch

01:01:05.760 --> 01:01:09.880
wirklich extrem gute Sachen schon möglich, als was mir jetzt gerade anfällt. Ich kann auch

01:01:09.880 --> 01:01:16.000
arbitrare Werte zum Beispiel setzen, indem ich sage, wirklich in meinem HTML Klassenattribut

01:01:16.000 --> 01:01:22.600
drinnen, dass ich schreiben kann, min, h für die Minheit und dann in diesen eckigen Klammern 340

01:01:22.600 --> 01:01:28.680
Pixel und habe mir dann eine Klasse on the fly erstellt. Sowas habe ich dann hin und wieder schon

01:01:28.680 --> 01:01:34.680
gesehen, dass das halt wieder ausgelagert wird ins CSS, um zu schreiben Minheit Doppelpunkt 340

01:01:34.680 --> 01:01:43.280
Pixel, dabei wäre es eben auch möglich. Jetzt frage ich mich nur gerade, ja ob, wie sehr das

01:01:43.280 --> 01:01:48.600
stimmt, naja das würde mich jetzt echt interessieren und da fragen wir am besten wirklich alle Hörer

01:01:48.600 --> 01:01:53.640
und Hörerinnen, die sich jetzt nicht nur mit den Frameworks, die wir gerade vorgelesen haben,

01:01:53.640 --> 01:02:02.000
sondern auch mit den folgenden Bibliotheken, den Styled Components, JSS, Styled JSX, Emotion,

01:02:02.000 --> 01:02:10.440
CSS Modules, Styled System, Stitches, Fehler habe ich noch nie gehört, Lunaria, AstroTurf, Twin,

01:02:10.440 --> 01:02:18.600
Theme UI, Vanilla Extract und Vindy CSS Auscannern. Ich brauche ganz dringend Nachhilfe bei euch, wie

01:02:18.600 --> 01:02:27.780
ihr CSS dann in der Realität so einsetzt. Manchmal habe ich das Gefühl, dass viele viele React

01:02:27.780 --> 01:02:33.360
Developer hier auch super hilfreich sein könnten, weil ich das oft auf der Ecke eben dann auch höre,

01:02:33.360 --> 01:02:37.680
weil es vielleicht dann zu JSX und dann macht es irgendwie vielleicht auch einfach Sinn CSS in

01:02:37.680 --> 01:02:43.200
JS zu verwenden. Ich glaube vor Ewigkeiten, vielleicht zwei Jahre oder sowas jetzt her,

01:02:43.200 --> 01:02:50.920
hast du schäftig mit Hans mal drüber unterhalten und es war auch eine grandiose Revision, da ihr auf

01:02:50.920 --> 01:02:59.880
zwei komplette unterschiedlichen Bereichen wart. Also Hans mit ja ja JSX super, CSS in JS super und

01:02:59.880 --> 01:03:05.520
du eben auf der anderen extremen Seite. Ja ich kann mich dunkel erinnern, aber die müssen wir

01:03:05.520 --> 01:03:11.720
raus krammen, da muss ich schon sehr lachen und ich weiß und das beste ist jetzt bei den Cliffhanger,

01:03:11.720 --> 01:03:17.120
man muss auf jeden Fall bis ans Ende dieser Revision warten, weil die Auflösung, was jetzt

01:03:17.120 --> 01:03:23.040
besser ist oder was sinnvoller ist, die war schon ziemlich gut. Echt? Ich weiß es schon gar nicht

01:03:23.040 --> 01:03:30.200
mehr. Die war groß, das das beste Resümee aller Zeiten. Okay, ja cool, dann vielleicht höre ich

01:03:30.200 --> 01:03:36.160
mir die trotzdem auch nochmal an, ja gute Idee. Also von der ganzen Liste, nur nochmal abschließend

01:03:36.160 --> 01:03:40.800
zu dem Thema, ich habe Emotion immer und immer wieder gehört, styled components habe ich schon

01:03:40.800 --> 01:03:47.280
vor langer Zeit gehört und dann habe ich mir das angeschaut, das ist nicht mein Style, das ist nicht

01:03:47.280 --> 01:03:55.520
meine Welt. Ich glaube es gibt ja welche hier drin sind, die tatsächlich auch durch JavaScript dann

01:03:55.520 --> 01:04:02.560
in den Browser reingeknallt werden und dann gibt es welche, die schreibt man zwar in JavaScript,

01:04:02.560 --> 01:04:09.760
aber kompiliert die dann zu CSS und dann ist das eben, dann liegt das da schon als fertiges CSS

01:04:09.760 --> 01:04:14.720
herum. Genau, welche das sind, weiß ich jetzt nicht so genau. Ich habe jetzt auch bei den meisten

01:04:14.720 --> 01:04:21.160
tatsächlich, also ich habe eigentlich fast überall never heard of it, not sure what it is, angeklickt

01:04:21.160 --> 01:04:27.080
oder im besten Fall heard of it und aber not interested und ich habe ganz unten gesagt so,

01:04:27.080 --> 01:04:33.040
also overall happiness, ich bin einfach da, ich habe keine Meinung, ich habe einfach neutral

01:04:33.040 --> 01:04:39.640
gesagt, keine Ahnung, ich bin nicht unzufrieden, aber nicht zufrieden, weil das überhaupt gar

01:04:39.640 --> 01:04:46.480
nicht mein Feld ist, dass ich backere. Was ich als Vorteil sehen könnte, auch da bin ich mir nicht

01:04:46.480 --> 01:04:53.520
sicher, ob es wirklich so ist. Ich habe nur eine Vermutung, dass wenn man jetzt tatsächlich aus

01:04:53.520 --> 01:04:59.240
der eher wirklich reinen JavaScript-Ecke kommt, dann könnte ich mir vorstellen oder würde es mir

01:04:59.240 --> 01:05:04.560
auch hoffen oder fände es einfach sehr cool, wenn diese Libraries dafür helfen würden vielleicht

01:05:04.560 --> 01:05:11.920
so den Einsprung in CSS zu machen und tiefer zu gehen. Ich hoffe oder ich bin mir sicher,

01:05:11.920 --> 01:05:18.280
bestimmt ist es so, dass man auch mit diesen Bibliotheken nicht ein reduziertes Set an

01:05:18.280 --> 01:05:24.120
Möglichkeiten hat, sondern auch genauso gutes, genauso kreatives, genauso komplexes CSS schreiben

01:05:24.120 --> 01:05:29.800
kann, aber vielleicht wird man so ein bisschen anders ans Thema rangeführt. Wir beide kommen

01:05:29.800 --> 01:05:35.520
wahrscheinlich einfach wirklich aus diesem, wir haben so lange HTML und CSS gemacht und irgendwann

01:05:35.520 --> 01:05:42.120
kam so ein bisschen JavaScript und JQuery dazu und für mich mein Gefühl ist es, als hätte ich zwar

01:05:42.120 --> 01:05:49.160
nie was anderes gemacht, weil es mir so viel Spaß macht, aber wirklich auf die letzten mehreren Jahre,

01:05:49.160 --> 01:05:55.520
Jahrzehnte fast gesehen, ist mein JavaScript-Anteil ja gar nicht so groß in dieser Zeit. Ja, die,

01:05:55.520 --> 01:06:00.800
ich glaube auch, dass viele dieser Frameworks auch vielleicht ihren Ursprung gefunden haben,

01:06:00.800 --> 01:06:08.840
also so, ich mein React ist ja jetzt auch, wie alt ist React irgendwie? 2015? Ich bin nicht ganz sicher,

01:06:08.840 --> 01:06:16.560
aber es ist schon für 2014, 2015 oder sogar noch früher. Also das irgendwie, die alle auch

01:06:16.560 --> 01:06:24.760
sonst, also die alle nicht, aber so die Prominenten ja auch aus dieser Zeit stammen, wo React so stark

01:06:24.760 --> 01:06:32.800
an Traktion gewonnen hat und JavaScript einfach total der Hype war und so ein CSS halt einfach

01:06:32.800 --> 01:06:40.640
ein bisschen ruhiger war und man vielleicht mehr Unzulänglichkeiten von CSS eben mit JavaScript

01:06:40.640 --> 01:06:48.840
auch ausgeglichen hat, aber CSS ist halt einfach jetzt, also da passiert jetzt so viel, da kommt so

01:06:48.840 --> 01:06:59.600
viel Neues, dass das vielleicht auch ja ein Grund dafür ist, warum vielleicht ich mich jetzt auch

01:06:59.600 --> 01:07:09.240
da gar nicht tiefer mit beschäftige, weil ich halt sehe, dass das gar nicht nötig ist. In der nächsten

01:07:09.240 --> 01:07:16.560
Sektion, genannt Other Tools, geht's gleich los mit Pre- und Post-Processors und da würde ich,

01:07:16.560 --> 01:07:24.800
ähnlich wie auch schon heute mal gesagt, mich fragen, teilweise wie viel Gewinn das alles

01:07:24.800 --> 01:07:32.360
gebracht hat, aber wie viel es auch verkompliziert hat, gerade was jetzt Bildpipelines und wie hieß

01:07:32.360 --> 01:07:38.520
das von früher, bevor man Webpack und sowas hatte? Das ist immer noch Grunt und Galp oder so?

01:07:38.520 --> 01:07:47.440
Grunt und Galp, ich fand auch Galp viel leichter zu konfigurieren. Aber hiermit bin ich immer so

01:07:47.440 --> 01:07:52.000
drüber gestolpert oder bin ich früher drüber gestolpert und sehe auch heutzutage noch Artikel

01:07:52.000 --> 01:07:55.840
drüber, was ist eigentlich Sass und was ist eigentlich Lesson, ist das nicht irgendwie das

01:07:55.840 --> 01:07:59.200
gleiche, aber eigentlich schreien mich jetzt gleich ganz viele Leute an, dass es doch was ganz

01:07:59.200 --> 01:08:05.160
unterschiedliches ist und warum schreien schon wieder alles so. Es gibt noch Post-CSS, das können

01:08:05.160 --> 01:08:11.040
jetzt wahrscheinlich die Tailwind-CSS wieder ganz gut oder die Tailwind-2-User noch, Stylus und

01:08:11.040 --> 01:08:17.160
Assembler-CSS. Ist es für dich einfach, solche Sachen zu wissen, was es ist, wie du es einsetzt,

01:08:17.160 --> 01:08:22.280
was ist Pre, was ist Post oder ist das für dich auch eher in der Rubrik, man muss es halt mal

01:08:22.280 --> 01:08:29.160
irgendwie konfigurieren und dann wird es hoffentlich funktionieren? Nee, also das ist für mich noch

01:08:29.160 --> 01:08:38.520
okay hier. Also Webpack ist natürlich ungeschlagen an der Spitze der magischen Tools, die, wenn sie

01:08:38.520 --> 01:08:45.560
dann, wenn die Magie versagt, einen in den Wahnsinn treiben. Genau, Sass ist manchmal auch so ein

01:08:45.560 --> 01:08:49.760
bisschen so, weil wenn man das installiert, dann muss das ja immer einen Bein re-kompilieren,

01:08:49.760 --> 01:08:53.600
das geht dann halt manchmal auf irgendwelchen Plattformen nicht und so, das nervt dann auch.

01:08:53.600 --> 01:08:59.000
Ganz genau, das ist so mein Problem, was ich mit Sass hatte, wo es dann halt einfach in der

01:08:59.000 --> 01:09:04.840
in der Umgebung nicht mehr funktioniert hat. Ja und dann, was machst du dann? Genau, wobei ich

01:09:04.840 --> 01:09:11.720
glaube, ich meine, es gibt jetzt ja Dart-Sass und nicht mehr C-Sass und ich glaube, da ist es,

01:09:11.720 --> 01:09:15.800
genau da ist es irgendwie, ist es ja glaube ich nicht mehr nötig, das ist aber vielleicht irre

01:09:15.800 --> 01:09:21.760
ich mich auch. Genau, Sass... Das ist korrekt, aber du brauchst natürlich auch die Plattform,

01:09:21.760 --> 01:09:28.520
wo du dann Dart-CSS benutzen kannst. Genau, ich finde Sass immer noch fantastisch, ich benutze es

01:09:28.520 --> 01:09:39.720
auch und zwar ein bisschen auch zum, also für Variablen, die ich vielleicht auch, die ich mit

01:09:39.720 --> 01:09:45.000
Custom Properties ablösen könnte mittlerweile, also jetzt wo langsam alle Browser gestorben sind,

01:09:45.000 --> 01:09:53.080
die keine Custom Properties können, aber ich finde eigentlich an Sass am besten die Convenience,

01:09:53.080 --> 01:10:01.560
dass man eben seinen CSS gut in einzelnen Dateien organisieren kann und dass man auch so BEM-Klassen

01:10:01.560 --> 01:10:07.160
einfach, also man muss nicht, muss die nicht immer ausschreiben, weil die teilweise recht

01:10:07.160 --> 01:10:12.760
lang werden können, sondern man kann da ganz gut eben mit dem Kaufmenschen und Zeichen, das ja

01:10:12.760 --> 01:10:20.840
viele fürs Nesting verwenden, kann man ganz gut eben einfach sagen, keine Ahnung, Komponenten,

01:10:20.840 --> 01:10:27.040
Name und dann ist da drin verschachtelt einfach so ein kaufmännisches und und dann unterstrich

01:10:27.040 --> 01:10:34.360
unterstrich child oder sowas und der expandet das dann zum vollen Klassennamen, ich muss nicht so

01:10:34.360 --> 01:10:39.960
viel tippen, genau dafür finde ich es gut, ich kann überall Media Queries reinstecken und so die

01:10:39.960 --> 01:10:45.160
die Vorteile, die mag ich an Sass und darum möchte ich das eigentlich immer noch gerne benutzen.

01:10:45.160 --> 01:10:52.320
Genau, das habe ich mal benutzt in einem Projekt, aber konnte gegen Sass irgendwie nicht anstinken,

01:10:52.320 --> 01:10:59.600
das einzig gute ist halt, du brauchst das, das braucht nur JavaScript und Post CSS würde ich

01:10:59.600 --> 01:11:07.760
ja eigentlich eher so sehen als ja so ein CSS-Parser, der dir dann die Möglichkeit gibt,

01:11:07.760 --> 01:11:17.360
das CSS noch zu manipulieren, wenn du das denn möchtest, also so wie so ein AST-Parser und da

01:11:17.360 --> 01:11:23.320
das nutze ich dann auch und baue mir da eigene Plugins oder ich nehme halt Plugins von von anderen

01:11:23.320 --> 01:11:29.880
Leuten, die irgendwelche Dinge machen, genau das also Post CSS habe ich eigentlich auch immer

01:11:29.880 --> 01:11:38.880
im Einsatz und die anderen Stylus war mal eine Zeit lang auch so ein JavaScript-basierter

01:11:38.880 --> 01:11:45.480
Pre-Processor, der aber jetzt glaube ich gar nicht mehr so en vogue ist und Assembler kenne ich nicht.

01:11:45.480 --> 01:11:52.960
Die nächste, der nächste Block hier werden über Utilities ein bisschen durchgemischt,

01:11:52.960 --> 01:12:04.800
beginnt mit Style-Lint, dann Part CSS, Purify CSS, Prettier für die Indentions, Style-Code,

01:12:04.800 --> 01:12:14.920
Syntax, ein bisschen zurechtschubser, der Auto-Prefixer für die Vendor-Prefixes, CSS-Nano,

01:12:14.920 --> 01:12:18.160
ich hoffe ich spreche diese ganzen Sachen jetzt immer korrekt aus, ich schreibe die normalerweise

01:12:18.160 --> 01:12:25.720
nur und etwas, was ich noch nie gehört habe, A-CSS. Kenn ich auch nicht. Kennst du A-CSS? Ok, gut. Wow.

01:12:25.720 --> 01:12:35.520
Puh. Selber im Einsatz habe ich Style-Lint, Purge CSS, Prettier, Auto-Prefixer und je nach

01:12:35.520 --> 01:12:42.400
Projekt jetzt auch CSS-Nano und ich glaube jetzt für mich persönlich, für diese Prozessoren und

01:12:42.400 --> 01:12:50.480
Utilities ist es nicht das Problem von diesen einzelnen Tools, sondern wie magisch ist gerade

01:12:50.480 --> 01:12:55.560
mein Projekt-Setup, das ich verwende, also wie du es gerade schon gemeint hast. Entweder ich habe

01:12:55.560 --> 01:12:59.920
jetzt, es muss ja nicht unbedingt immer nur Webpack sein, aber entweder ich habe mir irgendwas mit einer

01:12:59.920 --> 01:13:06.040
CLI automatisiert generieren lassen, teilweise ist vielleicht noch mal die Config eigentlich

01:13:06.040 --> 01:13:10.720
versteckt und ich habe noch eine zweite Config drüber und das funktioniert dann eben einfach.

01:13:10.720 --> 01:13:15.120
Es ist dann immer nur ein Problem, wenn dann tatsächlich ein Problem auftritt und dann bin

01:13:15.120 --> 01:13:20.760
ich mir gar nicht sicher, ob ich überhaupt einen Auto-Prefixer habe, weil das vielleicht eher in

01:13:20.760 --> 01:13:25.680
der Config in Node-Modules versteckt ist und ich weiß gar nicht, dass ich einen Auto-Prefixer habe

01:13:25.680 --> 01:13:31.800
und ich denke, das funktioniert magisch so. Ja, das ist ja immer dieses klassische Make-or-buy diese

01:13:31.800 --> 01:13:45.480
Fragestellung, also ich glaube, dass ich bin mehr so der Make-Typ, also ich setze mir halt dann auch

01:13:45.480 --> 01:13:52.000
meine Bundler selber auf und meine Task-Runner, auch das dauert halt alles länger und das ist ja

01:13:52.000 --> 01:13:56.640
im Content-Management, das ist ja überall so, bei Content-Management-Systemen auch oder bei

01:13:56.640 --> 01:14:04.640
Bootstrap auch, dass man sehr schnell Erfolge feiert und dann sind da immer so, jetzt müsste

01:14:04.640 --> 01:14:10.960
ich aber noch so diese letzten 20 Prozent, die fehlen noch, aber wir sind jetzt schon so weit,

01:14:10.960 --> 01:14:19.320
das sollte auch schnell gehen und dann steckt man eben 80 Prozent der Zeit da rein, die Tools dann

01:14:19.320 --> 01:14:28.080
anzupassen, dass sie dann am Ende das alles machen, was man möchte und genau deswegen mache

01:14:28.080 --> 01:14:36.000
ich halt das lieber sozusagen von Hand, habe dann, bin dann langsamer zu Beginn, am Ende eben schneller,

01:14:36.000 --> 01:14:43.200
weil ich genau weiß, was drin steckt und habe ihren linearen Fortschritt sozusagen als diesen

01:14:43.200 --> 01:14:49.600
Hockeystick, der dann aber immer am Ende dann abknickt und zu einem Plateau wird, wenn man dann Probleme

01:14:49.600 --> 01:14:59.840
kriegt. Dann nochmal würde ich noch einmal über die Utilities drüber gehen, Style-Lint, damit hatte ich

01:14:59.840 --> 01:15:04.560
eigentlich noch nie Probleme, ich habe es einfach immer mit installiert und lasse den Linter dann

01:15:04.560 --> 01:15:13.440
auch beim, ja komm mit, Push, Merchrequest, wie man es jetzt halt einstellen will, laufen. Ich finde

01:15:13.440 --> 01:15:18.880
es immer ganz nett, weil ich den dann einfach immer mal wieder upgrade. Manchmal bin ich YOLO unterwegs

01:15:18.880 --> 01:15:23.320
und schaue mir die Breaking Changes gar nicht erst an, sondern schaue, was danach kaputt ist. Meistens

01:15:23.320 --> 01:15:27.760
ist aber wirklich, also sehr sehr selten ist, was kaputt, bei dem Teil 1 habe ich schon gesagt, war

01:15:27.760 --> 01:15:34.280
da mal was mit, es gibt jetzt eine modernere Sonntags für RGBA, weiß jetzt tatsächlich nicht, ob das

01:15:34.280 --> 01:15:41.040
jetzt notwendig war für mich das zu ändern, so sind eben Linter. Purge CSS und Purify CSS sind

01:15:41.040 --> 01:15:53.120
beide, um nicht verwendetes CSS aus dem Bundle, das dann gebildet wird, rauszuschmeißen bzw. gar

01:15:53.120 --> 01:16:03.640
nicht rauszuschmeißen, wie man es jetzt drehen will. Genau, Tailwind bis 2 genutzt hat,

01:16:03.640 --> 01:16:09.200
vielleicht ist deswegen auch Purge CSS ein bisschen bekannter. Purge CSS selber hat eine

01:16:09.200 --> 01:16:16.520
eigene Seite darüber, wo es sich selbst mit Purify CSS und ich glaube auch un-CSS selbst

01:16:16.520 --> 01:16:24.560
vergleicht. Genau, bei Tailwind ist ja grundsätzlich das große Problem an utility-based CSS-Frameworks

01:16:24.560 --> 01:16:29.200
nicht nur Tailwind gewesen, das ist natürlich sehr viele Klassen besitzt und wenn man diese

01:16:29.200 --> 01:16:34.920
alle schippen würde, ich glaube das letzte Mal, aber das ist bestimmt auch noch anders gewesen,

01:16:34.920 --> 01:16:43.160
bei Tailwind waren das mal zwei Megabyte, die jetzt gerade im Sinne von Code Sandbox auch mal

01:16:43.160 --> 01:16:48.680
schnell eine Code Sandbox auf dem Mobile aufgemacht, schon sind zwei Megabyte weg fürs CSS, nicht so

01:16:48.680 --> 01:16:52.520
tolles sind, die sorgen eben dann dafür, dass tatsächlich, wenn ich jetzt nur meine drei

01:16:52.520 --> 01:16:59.600
Martian-Klassen verwende, auch nur diese drei exportiert werden. Das funktioniert eben dann auch ganz

01:16:59.600 --> 01:17:07.240
über Post-CSS, mittlerweile Tailwind 3 funktioniert komplett anders, es hat die eigene Engine dabei,

01:17:07.240 --> 01:17:15.240
die dafür sorgt, dass quasi das CSS erst gebildet wird, in dem die Dateien untersucht werden, was

01:17:15.240 --> 01:17:23.400
denn rein muss, anstatt zu schauen, was muss raus. Ja und Prettier, bist du Fan von Prettier oder bist

01:17:23.400 --> 01:17:35.280
du Anti-Fan von Prettier? Nee, weder noch, also ich finde es, ich finde es eigentlich, ich finde es okay, genau,

01:17:35.280 --> 01:17:47.760
ist nur, ja, ich finde es gut, genau, also ich finde, weil man sich konfiguriert mit Style-Lint und konfigure

01:17:47.760 --> 01:17:52.960
ich mir zum Beispiel ja auch so, dass ich dann sage, so weiß ich nicht, Indentation Level, dann habe ich gerne

01:17:52.960 --> 01:17:59.960
meine Properties in der Sortierung, also nicht alphabetisch, das ist ja für mich so wie die

01:17:59.960 --> 01:18:07.560
Klopapierrolle falsch rum drauf hängen, sondern eher so quasi nach Funktionsblöcken, also erst mal

01:18:07.560 --> 01:18:16.960
Position und Layout, dann Farben und dann Schrift und Typografie und am Ende vielleicht Animation und

01:18:16.960 --> 01:18:25.960
dann so Krempel und dann finde ich das halt ganz schön, wenn man da vielleicht irgendwen hat, der

01:18:25.960 --> 01:18:37.200
das schon für einen alles passend umsortiert. Ja, ja, also für Tailwind-Klassen habe ich auch einen

01:18:37.200 --> 01:18:42.640
Sortierer, ich weiß jetzt gar nicht, ob das ein Package war oder ein Winter war oder ob ich das einfach nur

01:18:42.640 --> 01:18:48.360
ein VS Code installiert habe, aber ich sortiere mir auch die Tailwind-Klassen zurecht, aus dem Grund,

01:18:48.360 --> 01:18:54.640
weil dann kann man sich nicht mehr darüber streiten, wie es richtig ist. Ja, Auto-Prefixer, für mich jetzt

01:18:54.640 --> 01:19:01.360
nichts weiter dazu zu sagen. Ja, der wird sich ja irgendwann auch erübrigen, wenn, also weil das mit

01:19:01.360 --> 01:19:08.880
den Prefixen ist ja gar nicht mehr so gängige Praxis und genauso, was ich glaube irgendwann

01:19:08.880 --> 01:19:21.520
kann man den einfach rausnehmen. Und bei CSS-Nano, da gehöre ich dann doch in die Rubrik, dass ich mit

01:19:21.520 --> 01:19:28.000
irgendeinem Tool mir das Projekt erstellt habe und über irgendeinen Minifizierer oder CSS-Nano oder

01:19:28.000 --> 01:19:32.440
ähnliches kommt meistens irgendwie mit und das funktioniert dann und muss nicht geändert werden.

01:19:32.440 --> 01:19:40.040
Also bei CSS-Nano, da muss man... Ja, ist ein Kompressor, wird komprimiert, oder? Genau, also der macht so Sachen,

01:19:40.040 --> 01:19:47.080
also tatsächlich kannst du bei CSS ja gar nicht so viel, also kannst du nicht so viel machen wie mit

01:19:47.080 --> 01:19:57.600
irgendwie in JavaScript mit Aglify und Thurser oder wie das heißt. Was man halt machen kann, ist so

01:19:57.600 --> 01:20:05.040
Media Curries zusammensortieren, aber davon kann ich eigentlich nur abraten. Also das scheint dann

01:20:05.040 --> 01:20:10.200
erstmal mal ganz gut zu funktionieren, aber dadurch, dass man die Kaskade dann verändert,

01:20:10.200 --> 01:20:24.360
schießt man sich dann doch für später in den eigenen Fuß, hat keinen Wert. Und ja, die nächste

01:20:24.360 --> 01:20:32.520
Frage sind Browsers. Mit der Frage, welche Browsers du bei der Arbeit vor allem... Ich kann

01:20:32.520 --> 01:20:39.240
Primarily gerade nicht übersetzen. Also in welchen man in erster Linie arbeitet, zumindest in der

01:20:39.240 --> 01:20:47.120
ersten Entwicklungsphase. Genau das. Ja, sehr schön finde ich Internet Explorer 8 und 10. Ja, da bin

01:20:47.120 --> 01:20:51.840
ich auf die Ergebnisse gespannt, die irgendwann rauskommen, aber ich glaube, das werden nicht so

01:20:51.840 --> 01:20:59.960
viele sein. Ja, kurz die vollständige Liste, wir haben den Edge, Chrome, Safari, Firefox, EE 11,

01:20:59.960 --> 01:21:07.320
EE Eltar, Opera Mini, Safari iOS, Chrome iOS, Chrome Android, Firefox Android, Samsung Internet,

01:21:07.320 --> 01:21:17.640
Vivaldi, Brave, UC Browser, Opera und PolyPane. Ja. Hey, wo ist das CC Browser? Da fehlt das CC Browser.

01:21:17.640 --> 01:21:23.040
Der CC Browser? Kannst du nicht den CC Browser? Stimmt, du hast mal davon erzählt, der ist so ein bisschen wie

01:21:23.040 --> 01:21:30.840
PolyPane, das ist so ein Entwicklerbrowser, richtig? Ja, das... Ich glaube, das Wort Browser wird dem

01:21:30.840 --> 01:21:36.320
ganzen nicht mehr gerecht. Das ist ein Ding. Das ist ein Ding, das bräuchte meine eigene Revolution.

01:21:36.320 --> 01:21:42.960
Also ich habe ja den PolyPane. Ich finde ihn ja auch ganz gut. Bei mir ist nur das Ding, ich arbeite fast

01:21:42.960 --> 01:21:47.160
immer auf einem 13 Zoll Laptop. Ich habe ja schon mal gesagt, ich bin ja so ein bisschen minimalistisch

01:21:47.160 --> 01:21:54.160
unterwegs. Aus dem Grund, weil früher, als ich noch erst zwei und dann einen großen Bildschirm

01:21:54.160 --> 01:22:01.320
hatte und eine Maus und nochmal eine extra Tastatur, dann habe ich immer rumgeheult, wenn ich eben das

01:22:01.320 --> 01:22:06.560
nicht zur Verfügung hatte. Und dann konnte ich ja gar nicht arbeiten, also nur mit so einem kleinen

01:22:06.560 --> 01:22:14.480
Bildschirm. Und das ging mir an mir selber so auf den Keks, dass ich gesagt habe, nee komm, ich brauche

01:22:14.480 --> 01:22:19.680
das alles nicht. Im zweiten Bildschirm habe ich es sowieso nie so richtig genutzt. Ich arbeite einfach auf

01:22:19.680 --> 01:22:25.080
meinem 13 Zoller. Hat den Vorteil, dass man eben auch mal die Perspektive oder ich die Perspektive

01:22:25.080 --> 01:22:29.800
immer habe von Menschen mit kleineren Bildschirmen und nicht immer die Perspektive von Menschen mit

01:22:29.800 --> 01:22:36.400
riesen Bildschirmen. Und der Polypane verbraucht halt relativ viel Platz und das ist halt auf 13 Zoll

01:22:36.400 --> 01:22:43.840
dann, weil der halt so, du kannst halt mobile und Tablet und Desktop so alles nebeneinander dir

01:22:43.840 --> 01:22:48.640
anzeigen und auch gleichzeitig bedienen und das ist super. Aber auf einem 13 Zoller ist das halt

01:22:48.640 --> 01:22:57.880
dann das in dem Fall nicht so super. Genau. Ja ich glaube, dass bei dem Sysy Browser, ich verwende

01:22:57.880 --> 01:23:04.600
gar nicht hauptsächlich die Funktion mehr, da mehrere Devices anzuschauen. Meistens liegt es

01:23:04.600 --> 01:23:09.920
auch am fehlenden zweiten Monitor gerade. Aber es hat so super coole Einstellungen, dass du schnell

01:23:09.920 --> 01:23:14.880
mal deinen Color Scheme ändern kannst, auch auf Auto oder Dark zu setzen, ohne dass du jetzt in deine

01:23:14.880 --> 01:23:21.560
Mac OS oder Windows Systemeinstellungen reingehen musst und wirklich viele kleine hilfreiche Tools.

01:23:21.560 --> 01:23:28.560
Ich denke, das Problem, das es hat, ist die Lernkurve, weil man sich erstmal mit diesem

01:23:28.560 --> 01:23:34.560
ganzen Ding befassen muss. Das kam mir ein bisschen vor wie Photoshop-Lernen wieder. Und das ist

01:23:34.560 --> 01:23:39.280
natürlich so eine kleine Hürde, als ich gedacht habe, jetzt habe ich ja voll den krassen

01:23:39.280 --> 01:23:46.240
Entwicklungsbrowser und ups, ich muss den erstmal lernen. Ja genau, das ist ja bei allen genauso auch

01:23:46.240 --> 01:23:58.200
eine IDE irgendwie gut zu kennen, ist hilfreich und ja. Genau. Ansonsten persönlich, ich muss

01:23:58.200 --> 01:24:05.960
natürlich alle Sachen im Safari testen und ich benutze den Safari privat aufgrund der device

01:24:05.960 --> 01:24:12.360
übergreifenden Lesezeichen und diesen ganzen Spesen. Ich würde den Safari absolut nicht zum

01:24:12.360 --> 01:24:16.440
entwickeln verwenden. Ich bin gespannt, ob es diesmal ändert, aber natürlich muss ich die

01:24:16.440 --> 01:24:20.440
ganzen Sachen testen, weil es doch der Browser ist, wo am meisten die Sachen ein bisschen

01:24:20.440 --> 01:24:30.200
anders funktionieren. Dementsprechend entwickle ich in erster Linie im Edge Browser und das richtet

01:24:30.200 --> 01:24:36.160
sich aber teilweise, also es richtet sich meistens nach der User-Gruppe, die in erster Linie auf die

01:24:36.160 --> 01:24:40.520
Webseite geht, für die ich da gerade arbeite und das ist einfach der Chrome Browser. Ich

01:24:40.520 --> 01:24:45.360
habe Chrome nicht installiert, ich habe Brave nicht mehr installiert, dementsprechend bleibt

01:24:45.360 --> 01:24:53.760
Edge übrig für meinen normalen Use-Case. Darf ich kurz fragen, also Chrome hast du vielleicht nicht

01:24:53.760 --> 01:24:59.720
installiert, weil irgendwie du keine Lust auf die ganzen Google Sachen hast vielleicht, aber Brave

01:24:59.720 --> 01:25:09.360
wäre quasi das Gegenteil, da sind die Gründer so ein bisschen zu rechts orientiert, oder so

01:25:09.360 --> 01:25:22.400
ja. Okay, ja ja. Und anti-Regenbogen-Farben. Ich weiß nicht, was die richten. Ja, ich versuche

01:25:22.400 --> 01:25:27.560
auch gerade über die Wörter zu stolpern, weil ich die richtigen Wörter sonst nicht kenne,

01:25:27.560 --> 01:25:33.080
aber Brave genau haben die Gründersachen, ich weiß gar nicht, ob es Gründer sind, ich habe keine

01:25:33.080 --> 01:25:37.960
Ahnung, ehrlich gesagt, ich glaube, ob es mehrere sind, aber ich habe da doch einiges drüber gehört,

01:25:37.960 --> 01:25:42.840
das nicht so ganz freundlich war, und da es genügend Alternativen gibt, gibt es auch für mich

01:25:42.840 --> 01:25:49.240
keinen Grund, so ein Produkt dann zu unterstützen, indem ich es nutze, aber wollte mich davon

01:25:49.240 --> 01:25:57.320
eigentlich auch abgrenzen. Und beim Chrome war bei irgendeiner macOS-Version das Problem. Puh,

01:25:57.320 --> 01:26:00.680
das ist jetzt ein bisschen, jetzt erinnere ich mich nicht mehr richtig, aber da kam so ein

01:26:00.680 --> 01:26:07.880
Windows-Server mit, und da waren ganz viele Geschichten, und jedes MacBook, das schon auf

01:26:07.880 --> 01:26:14.200
dem macOS-Version war, ist die CPU-Hype explodiert, und ich habe irgendwie eine Erinnerung, dass das,

01:26:14.200 --> 01:26:19.920
was dieser Windows-Server macht, auch eh nicht so geil ist, und hat da auch gesagt, ja, pff, wozu

01:26:19.920 --> 01:26:23.800
brauche ich Chrome, weil da gab es, gibt ja Brave, und jetzt war es auch, wozu brauche ich Brave,

01:26:23.800 --> 01:26:35.400
gibt ja Edge, so war dann die Laufbahn. Ja, ja, definitiv nachvollziehbar. Also ich bin in

01:26:35.400 --> 01:26:45.840
Chrome immer unterwegs, genau, und dann, ja, dann zum Testen, dann nehme ich halt den Firefox,

01:26:45.840 --> 01:26:54.800
und dann starte ich Browser-Stack oder habe vielleicht ein iOS-Gerät und teste dann auf iOS,

01:26:54.800 --> 01:27:02.280
genau, das sind so die Kandidaten, und ganz, ganz selten gucke ich auch mal mit dem Internet Explorer

01:27:02.280 --> 01:27:08.360
11 einfach, um zu schauen, wie sehr alles auseinanderfliegt, und dann denke ich mir oft,

01:27:08.360 --> 01:27:15.320
hey, das fliegt ja gar nicht so sehr auseinander, nicht schlecht, so freue ich mich drüber. Nee,

01:27:15.320 --> 01:27:23.680
ist ein schöner Mitnahmeffekt. Bei der letzten Box auf dieser Seite von den Other Tools, ich meine,

01:27:23.680 --> 01:27:27.680
das Server ist jetzt schon geschlossen, kann ich aber jetzt auch noch jeder Person draußen empfehlen,

01:27:27.680 --> 01:27:31.520
das mal selber durchzuklicken, da geht es, und das ist einfach so eine schöne UI allein,

01:27:31.520 --> 01:27:39.400
deswegen schon, bei der Library-Evaluation, wie man sich selbst dafür quasi entscheidet,

01:27:39.400 --> 01:27:47.400
wie man eine neue Bibliothek evaluiert, und da sind solche Sachen dabei wie die User Base Size,

01:27:47.400 --> 01:27:56.680
die Developer Experience, Hype und Momentum, Accessibility Features, Creator und Team,

01:27:56.680 --> 01:28:06.840
Community and Inclusive, Inclusivität, ich versuche das Problem dieses Englisch zu lesen,

01:28:06.840 --> 01:28:10.280
und ich versuche es noch in meinem Kopf zu übersetzen, dann denke ich mir, da kommt eh nur

01:28:10.280 --> 01:28:17.480
was Falsches raus, und dann kam was Falsches raus. User Experience und Dokumentation, kann man sich

01:28:17.480 --> 01:28:23.320
mal selber da so hinterfragen, weil ich habe da schon ein bisschen gebraucht, um mich zu entscheiden,

01:28:23.320 --> 01:28:27.440
zwischen teilweise, was möchte ich antworten, und was wäre die ehrliche Antwort auch?

01:28:27.440 --> 01:28:32.920
Ja, das ist ja so wie so ein Turnier, also quasi Accessibility gegen Dokumentation,

01:28:32.920 --> 01:28:39.720
was ist dir wichtiger? Okay, dann ich habe Dokumentation angeklickt, Dokumentation kommt

01:28:39.720 --> 01:28:47.320
weiter, Accessibility ist raus, und so am Ende gibt es dann eben ein Gewinner-Ding. An sowas

01:28:47.320 --> 01:28:54.960
finde ich halt immer nur blöd, dass manchmal so zwei doofe Sachen gegeneinander gepitcht werden,

01:28:54.960 --> 01:29:03.560
und dann ist das so, ja, also finde ich jetzt irgendwie doof, da hätte ich was anderes, da hätte

01:29:03.560 --> 01:29:08.720
ich an anderer Stelle eben zwei, die gegeneinander gepitcht werden, beide rausgeworfen, und dafür

01:29:08.720 --> 01:29:16.000
lieber hier zwei weitergelassen, aber. Also ja, genau, vor allem das unten User Experience

01:29:16.000 --> 01:29:21.280
gegen Dokumentation, also wie soll man sich denn da entscheiden? Ich weiß auch nicht so ganz genau,

01:29:21.280 --> 01:29:25.480
was ist der Unterschied zwischen Developer Experience und Dokumentation, ich weiß gar nicht.

01:29:25.480 --> 01:29:35.800
User Experience ist ja theoretisch deine Kundschaft sein, genau. Ja, aber es gibt hier ganz oben,

01:29:35.800 --> 01:29:43.120
da ist es User Base Size versus Developer Experience, und unten ist es die User Experience

01:29:43.120 --> 01:29:48.600
versus Dokumentation, aber ich dachte einfach eine geile Dokumentation wäre das gleiche wie

01:29:48.600 --> 01:29:52.560
eine Developer Experience, vielleicht ist das jetzt ein bisschen einseitig betrachtet. Ja gut,

01:29:52.560 --> 01:29:57.200
auf jeden Fall dazu. User Experience versus Developer Experience, würde ich eigentlich

01:29:57.200 --> 01:30:07.760
so super schnell sagen User Experience, aber kann man auch anders argumentieren. Ja,

01:30:07.760 --> 01:30:13.160
ich finde halt, ja, das ist nicht leicht, ich glaube, das ist aber auch, muss man jetzt auch

01:30:13.160 --> 01:30:21.120
gar nicht so, sind auf jeden Fall alles Aspekte, die eine Rolle spielen, und ob man da immer alles

01:30:21.120 --> 01:30:27.600
so und immer nur sagen kann, so hier das ist mir jetzt am allermeisten Wert, weiß ich nicht,

01:30:27.600 --> 01:30:35.360
ist halt jetzt so die Spielart von dieser Survey. Ja, ist ja auch nicht, dass im Endeffekt nur das

01:30:35.360 --> 01:30:40.520
zählt, diese eines, was am Ende rauskommt, aber es ist vielleicht ganz spannend, sich das mal

01:30:40.520 --> 01:30:47.480
anzuschauen, um sich selbst zu hinterfragen, auch die Tools, die man so bisher ausgewählt hat,

01:30:47.480 --> 01:30:54.000
nach bestimmten Kriterien, und jetzt so retrospektiv zu sagen, war das eigentlich gut oder hätte ich

01:30:54.000 --> 01:31:01.240
vielleicht doch nicht dem Hype folgen sollen, oder bin ich nicht auf den Hype aufgesprungen,

01:31:01.240 --> 01:31:07.160
und jetzt ist der Zug schon abgefahren, wie auch immer. Ich würde jetzt einmal noch mal kurz

01:31:07.160 --> 01:31:13.440
weiterspringen zu der CSS-Benutzung. Da wollte ich fragen, ob wir das vielleicht einfach überspringen

01:31:13.440 --> 01:31:19.840
wollen, weil das ist relativ öde. Ja, genau. Ich würde es nur kurz erwähnen, dass die beiden noch

01:31:19.840 --> 01:31:25.680
da sind, also dass das alle mal kurz gehört haben, wie man CSS selber benutzt, Testing Environment,

01:31:25.680 --> 01:31:31.520
CSS versus JavaScript Balance, was macht man eigentlich selber mehr, ich glaube, das ist dann

01:31:31.520 --> 01:31:37.760
einfach wirklich für die Statistik der Ergebnisse dann interessant und nicht jetzt so alleine gesehen,

01:31:37.760 --> 01:31:42.920
und der letzte Schritt wäre noch ein bisschen Ressourcen, wie man eigentlich CSS lernt,

01:31:42.920 --> 01:31:47.920
wie man sich up-to-date hält, etc. Genau, da ist bei den Ressourcen, da ist natürlich ganz,

01:31:47.920 --> 01:31:55.960
ist sehr schön, dass wir da tatsächlich auch den Weg reingeschafft haben. Ja, das ist super. Ja,

01:31:55.960 --> 01:32:09.320
sehr cool. Genau. Ja, es gibt viele spannende Ressourcen. Genau. Und da sind wir natürlich

01:32:09.320 --> 01:32:20.520
auch gespannt, was da rauskommt. Ja, ich würde sagen... Damit eröffnet, würde übrigens bald

01:32:20.520 --> 01:32:28.240
in Preview Mouth auch State of JS 2022. Ja, da werden wir auf jeden Fall auch wieder das

01:32:28.240 --> 01:32:36.840
retweeten, wenn wir das sehen. Ich hatte auch den Hauptmacher dieser Surveys, das ist der Sascha

01:32:36.840 --> 01:32:44.800
Greif, den hatte ich auch mal angeschrieben, ob der sich vorstellen könnte, die Ergebnisse im CSS

01:32:44.800 --> 01:32:52.720
Kaffeemieter mal so ein bisschen zu präsentieren. Mal gucken, ob das was gibt. Finde ich auf jeden

01:32:52.720 --> 01:32:59.880
Fall schön. Ja, super. Ein paar Minuten haben wir dann doch wieder aufgenommen. Ja, haben wir den

01:32:59.880 --> 01:33:08.960
zweiten Teil noch hier schön verarbeitet. Und mal sehen, was hier die Ergebnisse sagen. Ich glaube,

01:33:08.960 --> 01:33:15.040
da werden wir jetzt keine Revision mehr zu aufnehmen, aber wir werden auf jeden Fall sehr

01:33:15.040 --> 01:33:20.840
gespannt, dann da reingucken. Ja, auf jeden Fall tweet ich dann auch über die Ergebnisse und

01:33:20.840 --> 01:33:26.680
wenn sie draußen sind, über ein Working-Draft-Twitter. Genau. Vielleicht müssen wir das nächste Mal ein

01:33:26.680 --> 01:33:30.680
bisschen früher aufnehmen mit dem Espresso-Tring. Ich entschuldige mich für diese ganzen Versprecher

01:33:30.680 --> 01:33:40.120
heute. Alles gut. Das ist ein sehr subjektiver Eindruck. Alles gut. Genau. Ja, ich hatte auch

01:33:40.120 --> 01:33:43.440
noch ein paar technische Probleme, deswegen haben wir ein bisschen später gestartet und waren

01:33:43.440 --> 01:33:47.960
jetzt aber eh schon eigentlich müde. Hast du dein Powernap noch gemacht, das du machen wolltest?

01:33:47.960 --> 01:34:01.960
Nein, ich war auf TikTok stattdessen. Na ja, kann man nichts machen. Super. Ja, dann kannst du jetzt dir gemütlich machen im Bett.

01:34:01.960 --> 01:34:09.960
Betten jetzt kann ich nicht einschlafen. Schon zu spät. Dann kannst du TikTok gucken. Bevor alle denken,

01:34:09.960 --> 01:34:16.400
dass es draußen zwei Uhr nachts wäre. Es ist jetzt 22.19 Uhr. Ja, aber für manche, für Frühaufsteher

01:34:16.400 --> 01:34:25.160
ist es halt schon spät. Genau. Ich werde ja auch morgens immer von Kindern aus dem Bett sozusagen

01:34:25.160 --> 01:34:34.520
geprügelt bzw. der Wecker sagt mich, er sollte aufstehen, damit dann irgendwie für die Kinder

01:34:34.520 --> 01:34:41.680
alles fertig gemacht werden kann. Insofern kann ich das nachvollziehen. Ich hatte jetzt letztens eine

01:34:41.680 --> 01:34:49.040
Situation, ein Erlebnis, eine Erfahrung gemacht, das ich noch nie hatte. Wir waren zu viert in

01:34:49.040 --> 01:34:57.200
München beim Essen. Kollegen waren da, kamen angereist. Man sieht sich sonst nie und ich wusste

01:34:57.200 --> 01:35:03.880
aber gar nicht, dass alle Frühaufsteher sind. Zwei andere sind danach noch auf die PUSH-Konferenz

01:35:03.880 --> 01:35:07.680
gegangen und ich halt wieder nach Hause gefahren und habe dann aber noch so gemeint, weil ich

01:35:07.680 --> 01:35:13.320
habe ja eh nur alkoholfrei oder Wasser getrunken, weil ich gefahren bin und gemeint so, ja,

01:35:13.320 --> 01:35:19.760
wollen wir noch was trinken oder wollt ihr noch was trinken? Obwohl ich selber schon so ein

01:35:19.760 --> 01:35:24.080
bisschen müde wurde. Ich dachte, ich kann ja jetzt nie wieder der Party-Pupa sein. Und dann haben wir

01:35:24.080 --> 01:35:32.760
alle gesagt, ja nee, ist doch 21 Uhr, wir gehen jetzt raus. Es wird Zeit fürs Bett. Das war so ein schönes Erlebnis.

01:35:32.760 --> 01:35:40.440
Zum ersten Mal ist mir das passiert, dass wir alle einfach gehen durften. Man wird ja auch älter und

01:35:40.440 --> 01:35:48.760
Morgenstund ist ja auch nicht schlecht. Morgenstund ist die beste Stunde. Auf jeden Fall. Super, also

01:35:48.760 --> 01:35:59.680
dann guten Abend, gute Nacht. Vielen Dank den Hörern und Hörern fürs rein zeppen sozusagen und

01:35:59.680 --> 01:36:03.800
dann hören wir uns nächste Woche wieder. Tschau, tschau. Bis dann, tschüss.

01:36:29.680 --> 01:36:33.440
Beep, Beep, Beep, Beep.