Ich glaube, wir müssen uns unbedingt erklären, was das ist. Wir sind hier von 2020 40 Prozent never heard of it
auf 2023 knappe 70 Prozent never heard of it.
Oh, das stimmt. Großartig.
Ja, das müssen wir natürlich ändern.
Content Visibility ist einfach eine Möglichkeit, Content im HTML als lazy zu rendern, zu markieren.
Content Visibility Autostate Change?
Oh, das kannte ich noch gar nicht. Ja, das feuert halt eben, wenn auf dem Ding Content Visibility Auto ist und wenn es halt
eben entweder anfängt zu rendern oder aufhört zu rendern.
Kennst du das auch? Du willst mit einer neuen Technologie starten, aber das Internet ist zu
voll mit wirrem Content in verschiedenster Qualität? Du suchst kompaktes Wissen,
was dich direkt produktiv macht. Mit echter Erfahrung von Experten und Expertinnen,
die für deine akuten Fragestellungen da sind? Dann solltest du mal im TrainerInnen-Netzwerk
von Workshops.de vorbeischauen. Hier findest du eine Community aus über 80 TrainerInnen,
welche gemeinsam Material erstellen, sich gegenseitig unterstützen und weiterbilden,
um möglichst nachhaltige und hochqualitative Weiterbildungsangebote zu schaffen. Es gibt.
Sowohl Intensivschulungen über mehrere Tage als auch Masterclasses,
welche dich über einige Monate unterstützen.
Bist du auf der Suche nach einer qualitativen Weiterbildung im Bereich Webentwicklung?
Oder möchtest du dich selbst als TrainerIn einbringen?
Dann bist du bei workshops.de genau richtig.
Schau einfach mal vorbei für alle Informationen. workshops.de Wir freuen uns auf Dich!
Music.
Herzlich willkommen zur Revision 588. Heute sind an Bord die Vanessa. Hallo.
Der Peter. Moin, moin.
Und ich bin der Shep. Und wir werden uns heute mal den vor ein paar Wochen herausgekommenen State of CSS anschauen.
Auch wenn wir mit dem State of HTML ja noch gar nicht durch sind,
machen wir jetzt mal eine kleine Pause und schauen da mal in die Themen rein
haben uns noch ein paar Sachen rausgepickt, also werden da nicht komplett durchgehen,
und ein bisschen unsere Gedanken zu bestimmten Dingen kundtun.
Also, vielleicht können wir noch vorab sagen, dass es wieder sehr cool ist,
dass wir da als Ressource, als Podcast, auch direkt zur Auswahl standen, das war cool.
Und 37 von euch haben das auch angehakt. Sehr cool. Vielen Dank.
Ich weiß gar nicht, wie das letztes Jahr war, was das für eine Zahl war,
aber bestimmt ist es jetzt gestiegen.
Waren wir letztes Mal auch schon eine vorauswählbare Option, oder waren wir noch
ein Freitextfeld? Nee, letztes Mal waren wir auch schon drin.
Aber nur bei dem Set of CSS, nicht bei dem Set of JS. Also ich weiß jetzt gar nicht, wie
das überhaupt zustande kommt, also nach welchem Kriterium das dann da reinwandert.
I don't know.
Und wir haben gedacht, genau, wir konzentrieren uns einfach mal vornehmlich auf Features.
Es gibt ja Demographics, also wo kommen die Leute her, die beantwortet haben und in welchem Land ist vielleicht irgendein Feature besonders angesagt.
Und dann gibt es Frameworks und CSS in JS. Genau, aber die wollen wir so ein bisschen ausklammern, glaube ich.
Das ist zumindest der Plan. Wir starten einfach mal chronologisch in den Features.
Und da haben wir als erstes Subgrid drinstehen.
Und da wäre meine Frage an euch, habt ihr Subgrid schon mal benutzt?
Äh, ich gucke jetzt auf Can I Use, ob ich das schon mal benutzt habe.
Baseline not widely supported.
Hm, wahrscheinlich hab ich das dann nicht benutzt, weil ich nämlich gesehen habe,
oh, das läuft ja irgendwie in relevanten Browsern nicht.
Na, aber kann ja sein, dass du als alter Forscher und Firefox-Benutzer vor allem,
dass du dann Subgrid damit schon mal gespielt hast oder so?
Ja, ja.
Das Ding ist halt eben, was gibt's da zu forschen? Also, ich meine, Subgrid ist ja irgendwie relativ sinnvoll
und relativ offensichtlich, dass man das braucht.
Mhm. Aber wofür braucht man das denn? Sollen wir das noch mal erzählen?
Klar, wenn du es kannst.
Also ja, also im Grunde geht es darum, dass du ja Dinge in einem Grid nur anordnen kannst,
wenn diese Dinge die direkten Kind-Elemente von einem Display-Grid-Container sind.
Du kannst dir behelfen, indem du halt irgendwelche Zwischenelemente per Display-Content sozusagen
im Render-Tree, aus dem Render-Tree rausnimmst und damit drücken dann deren Kinder sozusagen
als direkte Kinder des Containers nach oben, aber was du eigentlich lieber willst, ist es quasi so,
dass du ein Grit aufspannst und sagen kannst, das soll sich bitte jetzt nach unten durchvererben,
dass du also quasi auch die Kind Elemente auf Display Grit stellen kannst und sagen kannst.
Die Columns und Rows, die übernimmst du bitte einfach von dem Ober-Guru-Grit-Layout
und legst jetzt keine neuen an auf deiner Ebene.
Genau, also ich hab irgendwie ein Layout mit vier Spalten, dann stelle ich da eine Box rein, die über zwei Spalten geht,
sag bei dir, es hat Grid am Start, das heißt, bei der Box, die über zwei Spalten geht, sind auch selber zwei Spalten am Start.
Genau, und die sind auch in Sync eben mit den anderen Elementen,
die ja eigentlich eine Ebene drüber sind, sozusagen.
Und das ist ja eigentlich wirklich die Umsetzung des, sagen wir mal,
Layout-Gedankens im Sinne eines Grids, wie es ja eigentlich gedacht ist. Also,
konzeptionell, wenn du jetzt sagst, ich designe jetzt hier mir ein Grid, dann ist ja nicht vorgesehen, dass durch,
einfach nur den Umstand, dass da zufälligerweise ein paar verschachtelnde Diffs dazwischen grätschen, dass dann plötzlich deaktiviert wird. Ein Grid ist ja mehr so eine Aussage,
das gilt hier jetzt und sozusagen, dass da irgendwie ein vom Master-Grid abweichendes,
sonstiges Grid am Start, das sollte ja eher der Ausnahmefall sein.
Ja, ich weiß auch, dass das damals schon, also die Rachel Andrews, die war da irgendwie schwer hinterher.
Und die ist vielleicht auch so die Vordenkerin, was so das ganze Subgrid-Thema angeht.
Die wollte damals schon oder hat irgendwie hart dafür bekämpft,
dass Subgrid schon in die ursprüngliche Grid-Spezifikation hineinwandert.
Aber dann hat man sich eben darauf geeinigt, das zu separieren, einfach damit man nicht zu lange festhängt
und erstmal was shippen kann.
Und wie wir sehen, also ich meine, 2017, glaube ich, haben alle Browser Grids,
so innerhalb von, weiß ich nicht, zwei Monaten oder so freigeschaltet.
Und jetzt sind halt sechs Jahre vergangen seitdem, bis jetzt auch Subgrid in die Browser kommt. Also es, glaube ich,
ist ja noch nicht, aber soll ja dieses Jahr kommen, ist auch Teil dieser,
Interop 2023 Liste.
Also der Dinge, die eben, wo alle Browser gesagt haben, wir einigen uns darauf, dass wir daran dieses Jahr arbeiten
und das idealerweise dieses Jahr fertigkriegen.
Ja, aber noch ist es halt eben hinterflex oder noch nicht da.
Und deswegen hab ich damit noch nicht wirklich viel rumgespielt.
Und wahrscheinlich wird das eins von den Features werden, das so, sagen wir mal, eher unspektakulär wird,
wenn's denn da ist, weil plötzlich geht's.
Man kann eine ganze Reihe von Hacks und Workarounds ad acta legen,
und die Welt ist ein bisschen besser geworden.
Ja, genau. Nächstes Ding, das wir hier auf der Liste haben, wären Logical Properties.
Die sind jetzt nicht so neu, aber sind ja schon lange supported.
Die Frage wäre, ob die schon den Weg sozusagen in eure Muzzle Memory gefunden haben.
Oder ob ihr noch eher so sozusagen bei Top-Right, Bottom-Left festhängt.
Jupp. Letzteres, also quasi, ja.
Letzteres. Ja, 100 Pro.
Ja. Ich schreibe jetzt zwar keinen clear fix mehr heutzutage,
aber obwohl ich wusste, dass die da sind, und ich glaube, man kann sie ja sogar schon verwenden,
sind sie definitiv noch nicht im muscle memory.
Aber bei Savvy habt ihr da irgendwie, müsst ihr da lokalisieren in verschiedenen,
also irgendwie in nicht westliche Sprachen?
Also, nee.
Und da haben wir ganz klaren Kunden-Cut, was wir aufnehmen können,
damit wir das dann auch qualitativ liefern können, ja.
Ja, also bei mir ist es so, ich bin tendenziell immer so ein bisschen konservativer,
also so ein bisschen nach dem Motto,
da, also ich kann ja damit mehr Browser bedienen, wenn ich eben bei der alten Notation bleibe,
als wenn ich auf Logical Properties wechsle, also da fallen halt eher einfach so Browser hinten über.
Ob die relevant sind oder nicht, ist dann erstmal egal. Ich denke halt immer so,
wenn ich mehr mitnehmen kann, nehme ich halt mehr Browser mit.
Und ich benutze es dann eher, wenn ich irgendwie Shorthands habe, die ich woanders nicht habe.
So was wie MarginInline ist dann schon mal ganz cool oder MarginBlock.
Dann ist aber, irgendwann mal bin ich auf dieses Thema gestoßen,
dass User ja auch über Google Translate eine Seite automatisch übersetzen lassen können.
Mhm. Was, ich glaube, viele tun durchaus. Genau, das habe ich nämlich bei uns im Projekt festgestellt,
weil wir Content Security Policy da implementiert haben.
Und dann, das ist ja ein sehr langwieriger Prozess, und dann machst du ja erst mal nur so ein Reporting an,
um zu gucken, was denn überhaupt alles so an potentiellen Violations passiert.
Und wenn du halt so eine Browser-Extension hast mit einem Übersetzungstool,
dann injekten die halt Skripte in die Seite.
Und dann merkst du so, oh, es sind aber schon einige, die sowas benutzen.
Und da ist eben die Frage, ob man Logical Properties nutzen sollte.
Einfach, also auch wenn man selber vielleicht diese fremden Sprachen nicht shippt,
diese Lokalisierung nicht shippt,
aber ums eben Menschen, also aus Barrierefreiheitsgründen im Endeffekt,
also Menschen, die vielleicht das auf Arabisch übersetzen, dass für die das Layout eben auch funktioniert.
Aber das ist jetzt so, ich weiß nicht genau, wie diese Übersetzungstools arbeiten und ob das hilfreich ist
oder ob das jetzt irgendwie einfach nur eine These von mir ist.
Mehr und umgekehrt natürlich auch die Frage, ob diejenigen, die diese Übersetzungstools benutzen,
nicht sozusagen mit der Erwartung daran gehen, dass das, was da rauskommt, ja eh suboptimal ist.
Einerseits von der Übersetzung, weil Maschine automatisch, und andererseits ...
Also, wenn du so was machst, machst du das meistens nicht zum ersten Mal,
und dann weißt du, okay, das läuft vom Layout anders als üblicherweise,
aber es ist okay, weil ich benutze bewusst einen Workaround und kann mich damit abfinden.
Ja, also, schwer zu sagen, weiß ich nicht. Also, wenn dann Hörerinnen und Hörer wissen, wie es damit aussieht,
ob das in solchen Fällen hilft oder nicht, dann gerne Bescheid sagen.
Würde mich mal interessieren. Genau.
Ansonsten gibt's ja die Logical Properties schon lange. Es gibt sie für fast alles, nicht ganz für alles.
Also, so ein paar Sachen sind da irgendwie noch ausgenommen.
Bei manchen macht's auch keinen Sinn, glaub ich.
Genau, es gibt aber noch irgendwie Properties, die könnten's vertragen.
Es ist ja wahrscheinlich mehr so einfach ein neues Paradigma.
Insofern braucht man alles, was in dieses Ding reingeht, was nicht left, right, top, bottom ist.
Da musst du halt eben sozusagen das Vokabular so ausformulieren,
dass du wirklich deine Konzeption von links und rechts komplett hinten überfallen lassen kannst,
auch wenn's de facto nie passieren wird, dass du das halt brauchst.
Ernsthaft.
Ja. Ja, aber es gibt halt so Overflow X, Overflow Y,
so da sind die, so braucht man da Logical Properties oder nicht,
was mit Translate X und Y und so Zeugs, also, so, ähm.
Ist halt schwierig, das nachträglich irgendwie noch reinzuziehen, sowas überall.
Ja, das stimmt, aber, mei, kannste ja machen, dann einfach den alten Kram vergessen.
Ich hab jetzt hier gerade die Kommentare noch angeschaut. Also da, ich mein, das sind jetzt natürlich Internet-Kommentare, da kommt jetzt alles Mögliche.
Aber was ich jetzt hier lesen kann, ist einerseits, es gibt anscheinend jetzt keine guten oder nicht genügend Shorthands.
Oder auch, dass es schon Sachen gibt,
die will man eigentlich dann doch nicht an der Text Direction ausrichten,
wie SVG, Grafiken und Filter.
Aber die meisten Kommentare, die ich jetzt doch überfliege, ist dieses Nee, einfach immer total vergessen,
dass es keinen Switch gemacht, das Team nicht umtrainieren wollen.
Eher solche Gründe. Ich kann mir vorstellen, dass es vielleicht auch Post-CSS-Plugins gibt,
Gibt die das dann für einen übernehmen?
Laut den Kommentaren, ja. Ja.
Wir sagen jetzt alle ja, weil da war ein Kommentar, das das gesagt hat,
und wir interpretieren das so, und auf jeden Fall.
Ja, aber im Grunde ist das ja wirklich Doofarbeit, ne? Also, nur ...
Vielleicht gibt's halt wirklich Stellen, wo man das dann tatsächlich mal nicht möchte.
Und die würden dann wahrscheinlich hinten überfallen durch so einen Automatismus.
Hm, ja. Den Kommentar, das Kommentar, egal, den ich jetzt hier am liebsten mage, ist
I have used it, but to be honest, it did go well.
Ja, dann?
Also, das kannst du auf meine Lebenserfahrung mit Computern generalisieren.
To be honest. Ja, und irgendeine Person schreibt hier schon,
muss erstmal ein Tablet-Plugin dafür schreiben.
Aber ich glaube, die Leute, die es tatsächlich brauchen, kamen jetzt hier auch mit den positiven Kommentaren durch.
Ja.
Nächstes Ding, das wir hier haben, ist Content Visibility. Jawoll!
Ist irgendwie cool und zugleich natürlich, wie immer bei coolen Sachen,
auch ein bisschen der Footgun.
Ich glaub, wir müssen uns unbedingt erklären, was das ist. Wenn ich diese Grafik richtig verstehe,
wissen jedes Jahr weniger Prozente als vorher, beziehungsweise sagen mehr Personen als vorher, never heard of it.
Also wir sind hier von 2020 40 Prozent never heard of it auf 2023 knappe 70 Prozent.
Und das stimmt. Großartig.
Ja, das müssen wir natürlich ändern, auch um uns unseren Platz da im Voting weiterhin zu verdienen.
Kontinuosibility ist ja, glaube ich, auch erst 2020 irgendwie eingeführt worden oder 2021 und ist einfach eine Möglichkeit,
Content im HTML als Lazy zu rendern zu markieren.
Also ähnlich wie halt Bilder lazy geladen werden, kann man eben Teile des HTML idealerweise natürlich below the fold mit Content Visibility Auto
kennzeichnen.
Was man allerdings dann noch tun sollte, ist Container Intrinsic Size zu setzen.
Da sagt man im Grunde dem Browser,
du renderst ja jetzt dieses ganze Element nicht, aber reservier mal so und so viel Platz für den Inhalt.
Damit eben wenn der Benutzer oder die Benutzerin dahin scrollt und du das dann anfängst zu rendern,
zum Beispiel die Scrollbar nicht auf einmal anfängt,
Also wieder, also dann ist ja quasi, der Scroller würde dann schrumpfen,
weil der Browser merken würde, oh, hier muss ich ja irgendwie jetzt was hinzeichnen,
und dann ist die Seite ja doch viel länger,
und da muss ich jetzt mal die Scroll-Leiste anpassen.
Genau, und andersherum auch, bei dem Content Visibility ist es eben auch so,
dass der Browser dann irgendwann aufhört, das zu painten, wenn das quasi nach oben weggescrollt ist.
Wenn du da wiederum keinen Container Intrinsic Size angeben hast,
dann kollabiert das halt.
Und wenn das halt kollabiert, dann wird quasi der Inhalt nach oben gezogen
und du bist nicht mehr an der Stelle, in der du vorher warst.
Mhm.
Aber weißt du, ich denk mir halt, das passt ja eigentlich ganz wunderbar in dieses ganze Style-Containment-Zeug-Genre so rein.
Das funktioniert auf den ähnlichen Regeln.
Und ist ja sozusagen nichts weiter als so die, ich meine, wenn du dieses Konzept schon hast von dem Style Containment,
dass man wirklich sagt, weil du irgendwie eine definierte Größe hast,
kann man halt irgendwie gewisse Annahmen über das Rendering machen,
in dem Element drin, und dann halt eben zu sagen, dass die Annahme halt auch sein kann, wenn nicht sichtbar,
dann auch sich mit dem Kram da drin nicht zu befassen, ist ja eigentlich nur eine logische Fortsetzung davon.
Und ich denke halt mal, das ist ja auch vor allen Dingen anwendbar auf Dinge, die feste Größen haben.
Also irgendwelche hyperinteraktiven, massiv gerenderten, Geschichten, also Canvas-Animationen oder so, oder mein Gehirn geht jetzt sofort so irgendwie...
In meinen Präsentationen animierter Code, irgendwie tausende von Diffs mit zig CSS-Regeln drauf.
Wie wär's, wenn die einfach weg wären, wenn sie eh keiner sieht?
So, das sind ja die größten Bekannten, und dann denke ich halt eben, genau dafür ist das halt eben auch da.
Aber das ist halt wirklich eine Lösung für einen Spezialfall.
Und was ich halt daran besonders nice finde, ist ja das damit assoziierte Event.
Content-Visibility-Auto-State-Change.
Oh, das kannte ich noch gar nicht. Ja, haha.
Ja, das feuert halt eben, wenn auf dem Ding Content Visibility Auto ist und wenn es halt eben entweder anfängt zu rendern oder aufhört zu rendern.
Das heißt, du könntest ja theoretisch dann, wenn du sowas, ich hab jetzt keine Ahnung, ob das neu ist oder so, warte mal,
nicht schlecht ist die Kompatibilitätstabelle, nicht sehr viel schlechter als das Hauptding.
Also insofern ist das wahrscheinlich irgendwie so grob gleicher Jahrgang.
Aber ist natürlich super, weil du damit halt eben die Animation Pausie nicht nur unsichtbar machen kannst,
sondern tatsächlich auch damit assoziierte JavaScript-Funktionalitäten stoppen kannst,
wenn es raus scrollt. Das kannst du sicherlich auch mit einem Intersection Observer und Zeug
irgendwie hinhacken, aber wenn du sowieso irgendwie sagen willst, dieses Widget in
dieser Box unterliegt Style Containment und mit dem Style Containment sind doch
irgendwelche Javascript-Nebenwirkungen assoziiert, dann ist das doch ganz großartig.
Ja cool ich ansonsten finde ich halt so dieses css contain gibt es ja auch und dann gibt es ja will change und so das sind ja alles so auch so dinge um irgendwelche sachen sagen wir mal zu optimieren aber die haben halt eben auch alle,
irgendwelche nachteile und das ist halt so nicht irgendwie letztens auf social media will change als deine größte css enttäuschung aller zeiten angegeben ja ja der manuel matusowitsch hatte dann nämlich gefragt und,
Genau, also seine, und die wird ja auch in dieser Liste der CSS-Mistakes von der CSS-Working-Group,
die pflegen ja so eine Seite, wo so all unsere CSS-Fehler, die wir halt gemacht haben in der Vergangenheit,
und da ist ja vertical align auch drin, und das fand er auch, weil das, also es ging mir damals auch so,
ich dachte so, ah, cool, ich will was vertikal zentrieren, dann nehme ich natürlich vertical align.
Oh, geht gar nicht. Warum? Wieso?
Und geht das nur in Table Cells? Aber Will Change ist auch so eine Drecksproperty.
Also, weil jetzt genau, was ist die Highlightung? Es tut nichts, oder was ist das Problem damit?
Also, bei Watercolor Line, irgendwie falsche Erwartungen, verstehe ich.
Aber was ist bei Will Change das Problem?
Ja, Will Change, da ist halt das Problem, dass der Browser dann bestimmte Optimierungen vornimmt,
die aber wiederum anderen Fallout produzieren.
Also, das heißt ...
Und durch dieses Will Change ist halt auch quasi gar nicht klar,
was der Browser macht.
Sondern das kann sich von Version zu Version auch unterscheiden,
welche Optimierung er vorab vornimmt, um eben diesen ...
Also, man sagt ja im Prinzip so was wie Will Change und dann, glaub ich, Transform oder so was.
Also, hier wird irgendwann die...
Irgendwie das Ding durch die Gegend geschoben. Du kannst schon mal dich darauf vorbereiten im Browser.
Und eben, was der Browser dann macht, das ist halt dem Browser überlassen.
Und da sind halt manche Optimierungen sehr unangenehm.
Und deswegen würde ich's halt lieber nicht benutzen. Und dann soll eben der Browser machen, was er tut.
Aber eben in dem Moment, wo ich's dann, wo ich die Animation oder die Transition oder so
dann auch tatsächlich starte und nicht quasi vorab und danach die ganze Zeit schon.
Hm. Hm, hm, hm.
Tja. Im Prinzip funktioniert's wie gedacht, nur was gedacht ist, ist halt nicht so gut.
Ja. Und es ist halt auch nicht reproduzierbar. Also, ich weiß noch, dass die Leute von Greenstock
irgendwann auch gesagt haben,
dass Will Change halt irgendwie considered harmful, weil Chrome von einer Version zur nächsten
auf einmal andere Optimierung gemacht hat und dann irgendwie Bilder grisselig aussahen oder so was und und das ist halt so ist halt so eine Überraschungstüte.
Ja, das geht eigentlich nicht.
Ne, ich such das mal raus für die Shownotes.
Ja, ich hab auch schon die Liste der CSS-Fehler so gefunden, da im Wiki von der CSS-Working Group. Der erste ist ja mein Liebster, also whitespace-no-wrap.
Wenn ich Auto-Completion nicht hätte, würde ich das wahrscheinlich jedes Mal verkehrt machen.
Ja, hat er so ein paar gute dabei.
Ja, wobei ich mich halt fragen kann, kann man nicht irgendwie No-Rap ergänzend einfügen?
Neben No ohne Dash-Rap?
Könnte man, ja. Die haben ja auch, Karen Culler war ja auch da drin, das haben wir, glaube ich, letztes Jahr besprochen beim State of CSS, weil die das auch abgefragt haben.
Und ich glaube, da waren auch Vanessa und ich, die wir darüber gesprochen haben, und wir haben halt uns gefragt, was jetzt genau an Karen Culler so neu sein soll.
Das ist ja im Alt. Kleinschreibung. Genau, und das ist halt jetzt, gibt es ein Alias,
dass es nicht mehr CamelCase ist.
Weil die halt gesagt haben, nix ist CamelCase bei so Properties in CSS. Nur CurrentColor.
Das ist halt doof.
Das ist tatsächlich,
mir nie aufgefallen, weil ist halt so lange schon im Sprachgebrauch drin.
Aber ja, stimmt. Ist der komplette Fremdkörper. Krass.
Genau. Und dann haben wir ... Als Nächstes haben wir Container-Querys. Ja.
Habt ihr die benutzt? Ihr ... Ich weiß nicht, Vanessa macht ja auf jeden Fall
komponentenbasiertes Frontend-Entwickeln.
Joa. Da bieten sich die ja an.
Nutzt ihr die bei euch? Für Dinge?
Ich glaube ... Und du merkst schon an der Antwort, dass es sehr, sehr rare eingesetzt ist.
Ich glaub, der Firefox hat's ja auch immer noch hinterm Fleck, oder?
Wie war das? Oder hat der das jetzt? Ich bin grad unsicher.
Ich war da nicht ... Ich dachte, irgendwas mit Edge, aber vielleicht war's Firefox.
Aber ich dachte, das wär eigentlich schon fully supported.
Ja, dachte ich auch. Wir haben so ein bisschen die Regel, wir benutzen nur fully supported.
Sonst muss ich ja morgen gleich ... Nee.
Nee, also, ich weiß, ich hab's damit mal rumgespielt, da war's im Firefox noch nicht.
Genau, aber der hat fünf Versionen länger gebraucht als Chrome.
Ja, aber das ist ja auch eine Ebene.
Ja. Immerhin, das war ja Februar. Das ist ja für uns Frontend-Developer schon zehn Jahre her. Aber echt.
Genau, ich hab's einmal so im Progressive-Enhancement-Sinne verwendet. Ähm ...
Aber nur an einer Stelle. Und dann hab ich's aber erst mal wieder ausgebaut,
weil irgendwie fand ich dann ...
Also, mir ist auf jeden Fall aufgefallen beim Rendern, der Browser Dinge macht, und dann merkt der Browser.
Oh, der Container ist aber ja so und so groß.
Dann muss ich das jetzt ja doch noch mal anders machen.
Und wenn mir das dann auffällt beim Rennern, dann denk ich immer, oh nö, das ist mir zu langsam.
Ja, aber da muss ich jetzt mal ernsthaft die Frage stellen, fällt nur dir das auf?
Also merkt das die Nutzerschaft auch?
Nee, nicht unbedingt, aber das ist ja dann so ... Ich hab da immer so das Gefühl, dass das so der Death by a Thousand Papercuts ist.
Also je mehr ich diese Container-Queries einsetze, je mehr Komponenten die benutzen,
desto mehr extra Layoutrunden muss der Browser drehen und am Ende dann summiert sich's halt.
Und deswegen, also ich find die gut, so wie ich auch HASS gut finde und das bei HASS genauso praktiziere übrigens.
Aber ich benutze die sparsam, was aber eben auch an meiner...
An meinem Performance-Nazitum liegt vielleicht.
Bei den Container-Querys hab ich mal die Einheiten ganz gut gebrauchen können.
Ja, die sind auch cool, ja. Stimmt.
Das ist wirklich sehr nützlich. Also, Container-Querys an sich, keine Ahnung,
ich baue ja keine ernsthaften Webseiten-Layouts,
aber diese Einheiten, dass man sagen kann, ich hätte jetzt wirklich irgendwie mal dieses hier Viewport-Unit-artige Zeug,
aber halt eben bezogen auf ein beliebiges Diff, das ist schon sehr nice to have.
Ja, also generell finde ich es eigentlich auch total gut. Wahrscheinlich auch eher,
dass ich nicht wieder sofort dran denke.
Ja, da ist halt auch, da kann man ja auch dann irgendwie so Sachen lösen, wie ein Text skaliert sozusagen mit in der Horizontalen mit dem Container und so, das ist ja auch schwierig.
Also man hat dann zwar immer noch nicht alle Probleme gelöst, weil man natürlich trotzdem initial eben so den Text vielleicht mit Letter Spacing irgendwie so mit Sperrschrift quasi so breit machen muss wie ein Container.
Aber wenn man das einmal hat, dann kann der Container wachsen und schrumpfen, und dieser Text bleibt so in Relation immer gleich groß.
Ja. Also, wie gesagt, ich find die gut, und Hass find ich auch gut.
Und die guck ich mir auch ... Die zieh ich auch immer in Erwägung.
Aber wenn ich irgendwie einen Weg drumherum finde, dann wähl ich den derzeit immer.
Hm.
Ich muss mich für Hass immer irgendwie ... Ich kann mich daran erinnern, dass es das gibt.
Weil so mein Gehirn immer noch im CSS funktioniert, nur in eine Richtung Modus ist.
Und HES ist voll gut und löst halt wirklich die wenigen Probleme,
die man da halt echt definitiv mitlösen kann. Voll gut, aber ...
Das ist, glaub ich, nicht verkehrt, wenn man darauf noch geeicht ist, in die eine Richtung zu marschieren.
Und die andere nur im Notfall mal zu beschreiben. Ja, das ist schon krass.
Also, so ein bisschen wie als Flexbox und Grid kam und man Inlineblock und Floats vergessen musste.
Das fiel mir noch nicht so schwer, ich glaub, da gab's noch Flexbox-Froggy und dann war ich die ganze Zeit am Spielen, bis ich's konnte.
Aber ich hab ja grad auch in der Vorbesprechung erzählt, dass ich mal ein riesiges Problem hatte im Kopf mit dem Not-Selector,
weil das, was ich erreichen wollte, war, wenn hier jetzt eine Liste ist, also eine ul oder ol, dann möchte ich einen bestimmten Style anwenden,
Außer, es gibt ein Parent-Element mit einer bestimmten Klasse.
Und ich hab's in meinem Kopf nicht hinbekommen, das zu schreiben.
Ich hab gefühlt alles probiert, ich hab mit Chachipiti gestritten, alles Mögliche.
Und im Endeffekt hatte ich tatsächlich das Sternchen dahinter vergessen in meinem Not-Selector.
Aber das kam mir so weird vor, quasi in dem Not-Selector eigentlich doch den vorderen Teil zu schreiben.
Das ist schwierig, schwierig.
Okay, du musstest dann quasi ... Du hast dann not gehabt und in der Klammer drin dann quasi die Klasse,
an dem, was du nicht wolltest und dann freistelle Stern.
Ja. Ja, okay.
Ja, kuck. Aber es war einfach falsch rum. Ja, ich weiß gar nicht. Also, bist schon aus dem Fall.
Ich glaube, ich hätte das schon geschrieben als not parent Stern.
Nee, ich glaube, ich hätte das geschrieben als Not-Parent-OL, so hätte ich es gerne geschrieben.
Aber das ging irgendwie nicht.
Genau, da stimmt ja bloß ein einfacher Selektor, kein mit Kombinatoren.
Ist das so? Ist das immer noch so? Ich dachte, dass die mittlerweile auch ...
Das war mal so. Nee, du hast recht, das war mal so.
Du hattest auch noch so ein tolles Blogpost, wo in jedem Browser das irgendwie anders rauskam,
weil der Safari konnte schon komplexe Selektoren in Not.
Dann konnte ein Browser gar keinen Not, und Chrome konnte nur Not mit einfachen Selektoren.
Nee, das war nicht das. Das war tatsächlich so eine Frage nach dem Motto,
so werte CSS-Gurus, was meint ihr, was hier rauskommt?
Und die richtige antwort war natürlich jetzt kommt drauf an und das ist ja auch die botschaft gewesen daran wie du hast recht das könnte das war ja schon ewig in den spezifikationen mittlerweile können es auch alle allein.
Mein verhaltenes geändert das noch gar nicht auf dem zettel dass das ja mittlerweile anders sein könnte.
Ja. Ich habe mich jetzt wieder vollkommen verwirrt mit dem not springen wir schnell weiter weil ich bin mittlerweile doch überzeugt dass meine schreibweise auch funktionieren sollte.
Die sollte auch funktionieren nur ich wollte was ich nur sagen wollte war ich wäre genau vor die gleiche wand gelaufen wie du aber aus anderen gründen.
Auch das ist auf jeden fall task. Ja genau also du hast du hast nicht gewusst wie es geht und ich habe geglaubt zu wissen wie es geht und wäre deshalb verwirrt gewesen.
Ich wollte noch hinzufügen dass es ja nachträglich noch mal in den spex umgespekt wurde und zwar dahingehend dass,
dass es früher forgiving war und mittlerweile nicht mehr forgiving ist
hinsichtlich der Selektoren, die darin gelistet sind.
Wenn da ein Selektor drin ist, den der aktuelle Browser nicht kapiert,
dann wirft er das ganze Teil weg.
Das war früher nicht. Und der Grund ist, dass jQuery ein Motools gepullt hat.
Und die haben quasi selber Feature Queries gemacht.
Weil die hatten ja auch schon Doppelpunkt HES als Selektor ganz lange in jQuery.
Und die haben halt die, was die mit ihren ganzen Selektoren machen,
gegen die Browser-Feature testen, aber was sie eben...
Gemacht haben, ist HES zu testen, aber mit einem komischen Selektor,
sowas wie Doppelpunkt Visible, der auch jQuery-spezifisch ist.
Und dann hat der Browser gesagt, ah, cool, kann ich. Ich schmeiß keinen Fehler,
weil sonst würde er einen quasi einen Fehler werfen.
Und dann hat jQuery gesagt, ah, cool, dann kümmerst du dich darum.
Ich brauch nix machen.
Nur, dass der Browser halt eben keinen Fehler geworfen hat, aber dennoch nicht zum Beispiel Doppelpunkt Visible konnte.
Und dann musste das noch mal umgespeckt werden. Und jetzt wirft das eben in Jackery einen Fehler.
Und Jackery weiß dann, aha, okay, ich muss das jetzt selber übernehmen mit meiner Engine.
Und deswegen haben wir aber keine forgiving-Selektoren.
Und wenn man die haben will, dann muss man das Ganze eben noch mal in einen Doppelpunkt-Is
oder in einen Doppelpunkt-Were kapseln, die wiederum forgiving sind.
Ja, ich meine, bei denen macht das ja auch ein bisschen Sinn.
Dass die forgiving sind, bei Hass hätte mich das jetzt auch eher so ein bisschen überrascht.
Weil ich meine, es ist ja eine relativ klare Ansage bezüglich dessen, was los sein muss.
Und wenn das nicht zu interpretieren ist, dann ist es halt Sense.
So. Und dass der andere ist ja eine Auswahl, mehr oder minder.
Joa. Ja, ich finde es jetzt auch nicht schlimm. Manchmal ist es halt blöd, weil man dann
für Vendor-gepräfixten Kram,
Also, wenn man jetzt nicht is- oder weart nochmal nutzt, dann muss man eben Selektoren einfach mehrfach hinschreiben,
damit eben alle Browser die nehmen und nicht verwerfen, weil, keine Ahnung, Safari ein Modding da drin gefunden hat
und Firefox ein WebKitding da drin gefunden hat und die dann irgendwie alle die Zusammenarbeit verweigern.
Ich finde das sehr schön, dass auch Jackquery ein Mood Rule prügeln kann.
Das finde ich eine sehr schöne Formulierung Und mir als ehemaligem Noodles-Anhänger
ist das natürlich ein innerer Reichsparteitag.
Ja, das denk ich mir. Das denk ich mir.
So, letzter Punkt im Layout sind die Viewport-Units. Die gibt's ja auch schon ganz, ganz, ganz lange.
Aber neu hinzugekommen sind, sagen wir mal, Abwandlungen der Viewport-Units.
Und zwar die dynamische Viewport-Unit-Familie, die Small-Viewport-Unit-Familie
und die Large-Viewport-Unit-Familie.
Die ich auch jetzt neulich, also neulich habe ich die Small Viewport Unit Familie genutzt.
Die sind notwendig geworden, weil ja mobile Browser,
ihr Browser Chrome oder ihr Browser UI, je nachdem, wo man jetzt irgendwie, ob man gescrollt hat oder was man so treibt mit
seinem Smartphone, eben quasi,
einblenden und wieder wegfahren. Und damit Es ändert sich dann der Viewport,
beziehungsweise auch die Erwartung, was der Viewport sein soll denn jetzt gerade.
Also wo möchte ich Dinge denn verankern? Soll das jetzt quasi in dieser Safe Area sein,
die jetzt immer zu sehen ist, also dem Small Viewport?
Soll das verankert sein im Large Viewport, sodass es vielleicht auch von Browser Chrome verdeckt werden kann?
Oder möchte ich einen dynamischen Viewport-Unit verwenden,
der halt wächst und schrumpft, je nachdem, ob Browser Chrome gerade raus- oder reinfährt.
Und ich glaube, dass die klassischen Viewport-Units, die sind gealiast zu den, zur Large Viewport-Unit.
Also die sind quasi auf ihren Browsern dasselbe, eigentlich.
Genau, und früher haben auch noch die Browser, waren sich auch noch uneins darüber, ob der Viewport
quasi dynamisch, also ob der Viewport betroffen ist davon, wenn das Virtual Keyboard hochkommt.
Und jetzt hat man sich eben darauf geeinigt, also Chrome ist eingeschränkt auf die Safari-Linie,
dieses virtuelle Keyboard über die Seite zu legen, ohne dass quasi der Viewport dadurch verkleinert wird.
Also der dann quasi unten drunter weiter.
Und du kannst in Chrome, wenn du jetzt das alte Verhalten besser fandst, kannst du in Chrome über so ein Viewport-Metatext ein Opt-out machen,
dass du wieder quasi das alte Verhalten hast.
Okay. Und das ist nicht irgendwie spezifiziert, wie sowas sich zu verhalten hat?
Nee, das ist auch so eine quasi Lücke, so wie ganz früher war ja bei den Viewport-Units
gab es eine Diskrepanz bei den Browsern, ob die Scrollbars sozusagen,
also beeinflussen die die Viewport-Breite zum Beispiel oder nicht.
Dann hat man sich halt irgendwann auch im Sinne von, das verhindert so Endless Loops in unserem CSS,
hat man sich darauf geeinigt, eben zu sagen, okay, 100 Viewport Width geht halt quasi,
da zählt die Scrollbar nicht dazu.
Also das ist quasi, das geht dann unter der Scrollbar weiter.
Ist aber wahrscheinlich auch nicht spezifiziert, weil ich könnte mir vorstellen, so das Konzept Scrollbar
kannst du ja auch so oder so umsetzen.
Nee, ist spezifiziert, ja.
Okay. Es aber stinkt, weil manchmal will ich halt Sachen quasi so breit haben wie der Sichtbauplatz.
Es gibt halt keine Möglichkeit zu erfahren, wie viel Platz eben diese Scrollbar einnimmt.
Außer indem du am Anfang Feature-Tests machst, wo du Elemente erzeugst, wo der Scrollbar drin ist,
und du dann ausmisst, wie viel Platz dann quasi ein Diff, was du da reinplatzierst mit 100 Prozent Breite,
also wie viel das dann noch ist.
Und dann weißt du, aha, da muss der Rest quasi die Scrollbar sein.
Ja, und halt eben so das Konzept von Platzverbrauch, ne? Also, wenn du jetzt so einen Windows-95-artigen grauen Block da an der Seite hast, okay.
Aber wenn du jetzt so ein modernes Lightweight-UI hast, wo irgendwie die Scrollbar sowieso nicht da ist,
und nur wenn du die Maus auf dem Fenster hast, ist irgendwie da so eine ganz leichte Andeutung von so einem Ding,
weil du ja eh irgendwie über dein Touchpad oder per Geste oder per Touchscreen scrollst.
Wahrscheinlich schwierig, das auch irgendwie so definitiv festzunageln, wie es zu sein hat,
aufgrund der vielen, vielen Möglichkeiten, wie das ausgestaltbar sein könnte.
Ja, genau, also da wünsche ich mir aber dann, dass es so, es gibt ja diese Env,
diese Env, weiß ich nicht,
Environment-Variablen, also diese eigentlich grundsätzlich so funktionieren wie Custom-Properties, da gibt's ja so
irgendwie Save, Inset, Top und so Zeugs auf Safari.
Und da wäre es eigentlich ganz cool, wenn die da mal eine Env-Variable für eben
Scrollerbar-Breite nochmal anbieten würden. würden, fände ich, glaube ich, ganz, ganz cool.
Aber was ist denn die Breite? Also, wenn ich jetzt hier mein, ich gucke mir mein Chrome-Fenster an,
wie es jetzt ist, so mit dem, mit dem Zen-Caster da drin.
Und ich habe die Maus jetzt auf der anderen Seite von meinem Bildschirm,
wo unser Google-Doc ist. So, das heißt, ich habe auf dem Zen-Caster jetzt keinen sichtbaren Scroll-Balken, aber sobald ich die Maus rüberschiebe,
äh, dann kommt er da und ich kann da jetzt in dem Chat-Fenster zum Beispiel umscrollen. Wie breit ist denn jetzt die Scrollbar?
Die ist wahrscheinlich null, aber das liegt daran, dass es nichts mehr drin ist.
Also was steht in der Endvariable?
Ja, genau, in der Endvariable würde dann null stehen, weil die, also es gab auch lange Zeit,
das haben die Browser auch entfernt, es gab
Overflow Overlay, das heißt, du konntest quasi dann eine Scrollbar haben, aber die war dann sozusagen,
überlagert, also die überlagerte den Content, und das heißt, wenn du dann eine Width 100% hattest,
ging das halt unter diese Scrollbar.
Und das hast du dann bei diesen Scrollbars, die sozusagen On Demand sich einblenden oder wieder ausblenden, hättest du das auch.
Die sind ja auch so halbtransparent, du kannst da durchgucken und die manifestieren sich halt mit null Pixeln in deinem Layout.
Aber so diese Windows 95 Scrollbars, die manifestieren sich halt doch.
Und dann soll da, dann wäre es natürlich cool, wenn, ich meine du kannst natürlich
irgendwie so educated guesses machen, wie breit die wohl sind, aber ist irgendwie alles, alles nur gefummeln.
Ja, und das ist halt der Preis dann von der Plattform-Unabhängigkeit, dass es halt eben
so oder so oder so sein kann.
Wenn du irgendwie ein iOS-Ding baust, dann hast du das Problem natürlich nicht, aber
dann hast du halt auch nur ein iOS-Ding. Ja.
So, da haben wir den Layout-Block abgeschlossen. Shapes and Graphics, Intrinsic Sizing Keywords,
das ist, glaube ich, hier so Fit-Content, Max-Content, Mint-Content.
Großer Fan. Super, ne?
Ist total toll. Also, mir geht das da so wie früher Internet Explorer 6 debugging.
Das sieht irgendwie nicht aus, also probiere ich die Dinger durch,
bis es aussieht, wie ich will. Aber ich hab da keinen nicht intuitiven Zugang zu.
Okay. Nee, Moment, du hast da keinen intuitiven Zugang zu, richtig?
Äh, nein, ich hab da keinen nicht intuitiven Zugang zu.
Weil wenn ich einen nicht intuitiven Zugang hätte, wüsste ich ja, was ich tue.
Aber ich rate halt, dass das eventuell mein Problem löst.
Ja.
Moment, ich versuch's mal. Also, MinContent bedeutet, die Zelle, Container, egal,
ist jetzt so lange, wie mindestens der Content lang sein wird.
Max-Content, jetzt, ich weiß auch gar nicht, warum Max, aber da im Notfall brechen die Buchstaben in einzelne Zeilen um.
Und Fit-Content ist das, was gut ausschaut.
Also fit Content ist, wo die Zelle so lang ist, dass der Content da reinfittet.
Oder war Min und Max genau andersrum? Nee, ich denke schon, dass Min ist eben mindestens so lang, wie der Content lang ist.
Also ich glaube Min Content, ich überlege auch gerade, was fit Content nochmal macht,
aber Min Content ist quasi dann, das geht dann so... Du machst den Content so klein, wie du kannst.
Genau, und zwar... Max macht den Content so groß, wie er geht.
Nee, ich glaube, es ist andersrum. Ich dachte, es wäre mindestens so lang.
Nee, nee, also bei MinContent, da guckt er sich quasi das längste Wort an, das da drin steht.
Und das ist sozusagen, also, wenn da nicht Hyphenation an ist, dann kriegt er das ja nicht kleiner.
Und das ist dann sozusagen die Mindestbreite. Max ist, glaube ich, tatsächlich dann, dass der ganze Text ohne Zeilenumbruch in eine Reihe passt, glaube ich.
Bei mir so sehe er das andersherum.
Und Fit-Content, da muss ich jetzt selber überlegen. Fit-Content kann dir zum Beispiel einen coolen Effekt erzeugen,
wenn du jetzt eine Headline schreiben möchtest, und du möchtest, dass die Headline einen Textmarkeffekt hat,
dass die eine Background-Color hat.
Aber wirklich eben davon abhängig, wie lang dieser Text ist,
je nachdem, welche Sprache eingestellt ist,
dann kannst du schreiben, dass das Diff-Block hier hat die Breite des Textes,
und dann kannst du eine Background-Color blau geben, und dann ist das wirklich wie so ein bisschen Textmarker-mäßig
unterstrichen zum Beispiel.
Mhm. Da müsste MaxContent was anderes sein, aber ... Genau, aber das ...
Hey, hey, pass auf. Ich hab hier grad mal MDN aufgemacht. Sagt mir hier zum Thema FitContent in Practice, bla bla bla,
the box will use the available space never more than MaxContent.
Also, die sind sich dann schon sehr ähnlich.
Ah, okay. Außerdem ist FitContent anscheinend auch eine Funktion.
Anscheinend parametrisieren.
Also ich hab nachgeschaut, ihr hattet recht, Peter, ich mach das dann einfach, ich gehe einfach in die Dev-Tools und ich drück so lange, ich will auch schauen, wie es ausschauen soll.
So, das ist mein Weg zum Erfolg, das muss...
Ja, ich glaube, das ist aber generell bei CSS oft ein Weg zum Erfolg, oder?
Ja, muss ja nicht, also ich meine, mein Hauptbetätigungsfeld ist das nicht. Ich glaube, bitte?
Bei Flexbox neigt man ja auch, eher so rumzuprobieren.
Ja, gut, wenn man dann landet bei Minwulf Zero. Ja, Minwulf Zero ist sehr wichtig, das braucht man immer.
Ja, aber andererseits ist ja Flexbox ... Das mag zutreffen, aber du holst ja heutzutage wahrscheinlich,
die Flexbox-Kanone, sagen wir mal, für eher kleine Spatzen raus.
Also, das war ja früher so das einzige vernünftige Layoutmittel,
weil irgendwie hier ... Grid war noch nicht so weit.
Aber Floats haben schon immer genervt, also hast du halt Flexbox genommen und dann war das halt tatsächlich irgendwie schwierig, weil du halt irgendwie dein ganzes Layout damit irgendwie orchestrieren musstest.
Und jetzt, wenn ich halt irgendwie so mein großes Layout, meinen großen Layoutwurf machen möchte, dann greife ich halt eben schon eher zum Grid und das ist selbst in Abwesenheit von Subgrid ja noch relativ klar zu strukturieren.
Also da ist der Weg von so, ich hätte gern das zur Umsetzung, die dem relativ nahe kommt, recht direkt.
Und wenn ich bei Flexbox so was machen will, wie einfach nur die Navigationsleiste gleichmäßig spacen,
da muss ich da auch selten dran rumfummeln, weil einfach dann der Problemscope so klein ist, weißt du?
Mhm. Also, ich glaub, du hast recht, aber das spielt, glaub ich,
heutzutage nicht mehr ganz so die Rolle wie früher, als wir nur Flexbox und nichts Besseres hatten.
Ja.
Aber MinContent kann man auch einsetzen in Grid CSS, zum Beispiel bei so GridTemplateColumns.
Kannst du die angeben mit MinContent, Max-Content. Ich weiß jetzt nicht, ob die beiden zusammen Sinn machen, aber man kann sie auf jeden Fall drin einsetzen.
Es fehlt auf jeden Fall noch Moritz-Content.
Aber ja, ich hatte das eben, Schäfer-Düdels gerade meinte das.
Wo wir sind, ist vorne, Podcast. Nicht bei uns.
Das mal in einer, nicht Tabellenzelle, also doch Tabellenzelle sogar, mit wo ich die Hyphens anhatte.
Und dann hat das mit meinem Min- oder Max-Content nicht so funktioniert, wie ich das wollte.
Wahrscheinlich war es dann tatsächlich eben MinWiff, weil dann konnte jedes Wort dann doch gesplittet werden.
Und dann war das doch nicht so. Ich glaube, ich hatte da einen recht coolen Weg.
Ich schau mal kurz nach. Redet mal über was anderes.
Genau, wir können nächstes, als nächstes habe ich Linear Easing Function hier.
Kennt ihr die? Die ist auf jeden Fall hot off the press sozusagen.
Nee, die kann ich noch nicht erzählen. Da geht es darum, dass du mit den bisherigen
Bezierkurven ja bestimmte Konstellationen nicht abbilden kannst.
Also wenn du jetzt irgendwie sowas machen willst wie so Bounce mit Nachbouncen oder sowas und
Die CSS-Working-Group hat halt irgendwie sich lang in den Kopf darüber zerbrochen,
wie kann man das, also macht man dann irgendwie noch mehr Bézier-Anfasser und
Problem ist nur, das kriegt halt keine Programmiererin oder Programmierer gebaut,
also einfach, weil es so ist, einfach schwierig.
Kann man nur noch irgendwie mit einem Grafikprogramm machen und die Linear Function, da ist man eben auf die Idee gekommen, so hey, Moment, eigentlich
ist das auch gar nicht wichtig, dass die Kurve überall glatt ist, weil wenn wir
hinreichend viele Punkte einzeichnen können, dann ist sie sozusagen geglättet genug und
das Auge merkt es nicht.
Und das ist eben, was diese Linear Easing Function jetzt einem anbietet, dass man eben
beliebig viele Punkte dort hineinsetzt und die aber alle eben nicht weich verbunden sind,
also nicht mit einem Easing oder in einer Bezierkuhr, sondern alle quasi wie, wenn man
dass man halt diese Zahlen, Bilder, Malt quasi alle verbunden sind
mit einer geraden Linie.
Genau, also früher war Linie einfach nur ein Keyword für einfach, das geht halt von null nach eins konstant durch.
Und jetzt ist das ja im Prinzip eine Funktion, mit der du beliebig viele lineare Schritte machen kannst.
Und dann hast du sozusagen deine runde Animation aus diskreten Schritten zusammengesetzt,
statt wirklich über eine original Bezierkurve, weil man die nicht verkomplizieren wollte.
Genau, und Vanessa, hast du gefunden, was du suchtest? Ja, den Effekt, den ich haben wollte, war bei einer Tabelle,
die sich auch über quasi Pagination über mehrere Seiten erstrecken kann,
gab es eine Spalte, die gar nicht so oft wirklich befüllt ist.
Das war so ein bisschen ein special Ding. Gerade je nachdem, wie man die benutzt hat,
steht da vielleicht auch nie was drin in dieser Spalte.
Deswegen wollte ich nicht, dass diese Spalte immer 200 Pixel wegnimmt,
obwohl da vielleicht gar nix drinsteht. weil da eben auch teilweise mit Hyphen und keine Ahnung was,
der Content kann sehr dynamisch sein, dass sich das viel zu schnell umbricht.
Und den Mix, den ich gemacht hab, war ...
Die Width auf Max Content zu setzen und zusätzlich eine Max Width von ...
220 Pixeln anzugeben.
Mhm. Und dann hatte ich genau den Effekt, den ich haben wollte,
dass wenn wirklich in gar keiner von diesen Zellen der Spalte was drinsteht, war die so minimal.
Wie sie sein konnte, also dann ausgerichtet an dem Spaltenkopf, an dem Titel.
Und wenn da jetzt aber sehr viel Content drinsteht, dann wurde es trotzdem jetzt nicht breiter als 220 Pixel.
Okay. Und mein Kopf hatte dann auch wieder so ein bisschen die Probleme,
gleichzeitig eine Worth Max Content zu benutzen und eine Max Worth, die festgesetzt ist.
Aber hat super funktioniert.
Ja.
All right, dann haben wir jetzt noch hier drinstehen als letzten Punkt bei Shapes & Graphics die
View Transition API. Da habe ich auch letztens mich mal mit dem Peter ein bisschen drüber unterhalten.
Ich glaube, das war auch nicht Vorbesprechung, das war ...
Nee, genau. Und ich habe gesagt, Chep, das ziehe ich mir als nächstes rein.
Und? Weißt du, was ich mir nicht reingezogen habe seitdem? Long story short, wir haben ja schon ein bisschen drüber gesprochen, also die sind schon echt
cool, aber es gibt einfach noch so Use Cases, die ich hab das zwischenzeitlich auch gesehen, dass die, glaub ich, die auch ins Visier genommen haben.
Aber es gibt Use Cases, wo die eben noch nicht so gut funktionieren.
Und ich persönlich bin da an Grenzen gestoßen,
als ich, als ich eben mehrere Dinge auf der Seite hatte, die alle irgendwie zu ihrer, zu ihrem Zeitpunkt,
an dem sie meinten, dass sie fertig sind, eben View Transitions angestoßen haben,
um Dinge weich in den nächsten Zustand übergehen zu lassen.
Und da ist eben das Problem, dass die View-Transition immer nur bezogen auf die gesamte Seite funktioniert.
Und wenn dann irgendwo zwischendurch noch mal ein Element eine Transition anstößt, dann grätscht die,
in die globale View-Transition rein, und dann funktioniert das eben nicht mehr.
Das heißt also, was man braucht, ist idealerweise immer nur eine View-Transition, die auf einmal läuft.
Und alle anderen dürfen dann nicht laufen. Buchführen drüber, ob die gerade läuft oder nicht, und das muss man aber eben einbauen, und dann darf eben keine weitere angestoßen werden, bis,
eben die erste nicht fertig ist. Nein, nein, nein, also es kann doch nicht angehen, dass meine tolle Komponente,
irgendwie über irgendwelche globalen Belange buchführt, das ist doch voll anti.
Ja, deswegen hast du ja wahrscheinlich eine View Transition, einen View Transition Manager,
eine zentrale Instanz, an die du dich wendest, und der macht das dann. Also ich habe ja eine View Transition Manager
Aber ich weiß ja nicht, wie das bei dir aussieht.
Mit Decorators oder ohne? Immer mit Decorators, du kennst mich doch. Ja.
Meine Frage ist, gibt's da wirklich keinerlei Containment-Mechanismus,
den man da draufwerfen kann?
Wir haben vorhin drüber gesprochen, dass man alles Mögliche containen kann.
Warum gibt's kein View-Transition-Containment?
Also, gibt's halt noch nicht. Es sind ja noch ein paar Dinge offen bei den View-Transitions.
Momentan gibt's hier nur sozusagen für ...
Also innerhalb der aktuellen Seite, und dann eben für Single-Page-Applications
dementsprechend, was noch ansteht, ist eben für Multi-Page-Applications das auch zu implementieren, das kann man auch schon in Chrome hinter Flex testen,
und ich habe gesehen, dass die eben auch diese Probleme mit eben mehrere Bereiche
parallel transizieren, dass die auch ein Thema sind.
Stelle ich mir aber auf jeden Fall nicht so ganz einfach vor.
Insgesamt. Nee, konzeptionell halt nicht. Ich glaub, das ist, ähm,
also, was ich an CSS ganz spannend finde, ist, man kann da eher durch die Features durchscrollen,
die da echt so aus der Benutzung rausgefallen sind.
Also, das Beste sind irgendwie so die Media Features, Media Types, nee, nee, äh, Media Types, genau.
Also so Print, Screen und Handheld und so Zeug.
Mhm, ja, TV.
Ja, TV, genau, genau. Wo man halt echt einfach so sieht,
der damals aktuelle Tech-Tree einfach in CSS reingeflossen ist
und einfach so da reingewirkt hat und sich das da jetzt so festgebissen hat
und so als Rodiment noch drin ist,
obwohl das einfach keinerlei Kategorien mehr sind, die in der heutigen Welt noch irgendwie Sinn ergeben.
Und ich hab ja manchmal so den Eindruck, dass ich bei so gewissen,
CSS-Features, die heute reinkommen, mich halt so frage,
sind die nicht arg aus unserer Smartphone-Sicht geboren?
Weil, was du jetzt ja beschreibst als Problem, du hast mehrere View-Transitions und Integration
und die Grätsche und sich gegenseitig irgendwie in die Parade.
Um das Problem zu haben, brauchst du ein hinreichend komplexes User-Interface.
Wenn du nur eine Spalte hast, eine Page auf so einer Mobile-App,
dann hast du das halt nicht.
Und dann löst das natürlich auch super dein Problem, dass du aussehen willst wie eine native App.
Ja, ja, nee, also die sind schon gut, aber man muss eben auch so ein bisschen so ...
Wie das halt immer so ist, ne?
Also man muss ein bisschen aufpassen. Sind die gut? Also wirklich?
Oder ist das ein konzeptionelles Versagen, zu sagen, aha, es gibt jetzt halt hier genau diese Devices und die sind heutzutage der wichtigste Part und so, das mag ja alles sein,
aber dass man dann sozusagen dieses Feature auf eine Art und Weise konzipiert,
dass dieses Problem passieren kann.
So ähnlich wie du halt die annahme fortschreit ein tv gerät wird immer eine distinct abzugrenzende art von device sein mit seinem crt bildschirm und zeug.
Wo man ja eventuell auch einfach irgendwie mal in den fernseher hätte reingucken können sich startrekette angucken können und so auf die idee kommen können möglicherweise ist eine andere zukunft was bildschirme angeht denkbar.
Ja, also ich sag mal so, wenn du verschiedene Komponenten auf der Seite hast, die, sagen wir mal, Dinge nachladen und die dann eine Transition gerne ausführen möchten, also von Zustand alt auf Zustand neu, dann hast du das eigentlich idealerweise ja auf jeder Plattform.
Also, weil du hast ja auf Mobile nur ein anderes Arrangement,
aber im Grunde die gleichen Elemente drauf.
So sollte man ja Responsive Web Design idealerweise machen, dass man eben nicht Teile weglässt.
Also, das ist ja immer ärgerlich, wenn irgendwie auf Mobile Dinge gar nicht da sind.
Deswegen, und auch wenn sie eben nicht im Viewport sind, dann werden sie das, wenn sie halt irgendwie als Teil
ihres Update-Mechanismus ja auch View Transitions triggern,
außer du hängst da noch irgendwelchen Intersection Observer dran, der dann sagt so hey, diese Komponente ist ja sowieso nicht da, die braucht keine Transition, die musst du dann auch nicht triggern, dann sitzt du wieder auf Mobile, ein Vorteil.
Helfen mir vielleicht iFrames ganz einfach.
Äh, na ja, iframes helfen in bestimmten Belangen, und in anderen Belangen sind die halt wieder totale Scheiße, ne?
Natürlich sind die total scheiße, aber ich meine, um das spezifische Problem zu lösen.
Ja. Also, ich meine, wenn ich jetzt wirklich vernestete Dokumente habe,
so iframes in iframes und Zeug, und die View-Transitions da drin abfeuere.
Ich glaub, ich muss mir das Zeug mal anschauen und genau diese Dinge ausprobieren.
Gibt ja auch noch so Grauen wie Object Tags und so, Konsorten.
Also, ich glaube, ich bin insgesamt immer noch ein Proponent dieser neuen API.
Ich finde die ganz gut. Aber wie das eben so bei vielen Dingen so ist,
völlig ohne Sinn und Verstand kann man dann Dinge nicht benutzen.
Ich hätte vielleicht als 1.0 die Multi-Page-Version netter gefunden.
Ja. Wenn du jetzt wirklich irgendwie so gehst, du, ich will die größte Anzahl an Web-Applikationen
maximal irgendwie aufwerten können, mit irgendwie ein paar Zeilen.
Dann wären doch wirklich diese ganz klassischen MVC-Backendlastigen Geschosse,
die wären damit so instantan sehr viel besser geworden, sehr viel Single-Page-Appiger,
ohne dass man das ganze Ding in React neu schreiben muss.
Versus du jetzt eine bessere Möglichkeit hast, das Ding in React neu zu schreiben.
Vielleicht hätte man ohne diesen Schritt das machen können.
An sich schon, aber es wird wohl seinen Grund haben, dass das noch nicht freigeschaltet ist.
Yes. Ja, aber wenn, wenn ihr coole Demos habt, die ihr damit gebaut habt, also da gibt's ja durchaus echt richtig geiles Zeugs,
schickt sie doch rüber oder schmeißt sie uns als Links in unseren Community Slack, zu dem wir euch herzlich einladen.
Und dann bringt ihr uns alle mal hier schön zum Staunen. Ansonsten haben wir uns gerade Chat technisch darauf verständigt, dass wir hier einfach mal einen Cut machen.
Weil CSS ja dann doch umfangreicher ist. Und genau, wir machen das dann wie beim State of HTML.
Dass wir dann einfach uns noch mal zusammen raufen. Und den nächsten Teil uns dann zu Gemüte führen.
Du, aber dann reden wir wirklich über das geplante Thema, ne?
Nicht abschweifen hier mit obskuren Event-Händlern und so. Auf gar keinen Fall.
Bis dahin haben wir uns ja auch alle die API angeschaut.
Ja, haben wir.
Ja, schön die Hausaufgaben machen.
Genau. Okay. Genau, wir können ja mal gucken, wann wir das machen,
denn wir haben auf jeden Fall auch bald wieder Gäste da.
Und der Peter und ich müssen ja noch wirklich unseren dritten Teil und letzten hoffentlich von State of HTML machen.
Zu dem du natürlich auch herzlich eingeladen bist, Vanessa.
Genau, aber das steht ja auch noch auf unserer To-do-Liste.
Wir gucken mal. Was jetzt nicht bedeutet, falls hier gerade jemand zuhört und sich gedacht hat, heute ist der Moment, an dem werde ich schreiben. Ich habe ein Thema.
Trotzdem gerne schreiben. Wir haben noch ganz viel Platz. Ja, auf jeden Fall. Genau.
Nee, da freuen wir uns. Und wir finden immer Platz. Das ist doch alles kein Problem.
Genau. Wir sind sehr nett.
Ich weiß nicht, ob ich dazu jetzt ja sagen kann. Dazu brauchen wir eine externe Expertenmeinung.
Ich bin die externe Expertenmeinung. Ihr seid sehr nett.
Super. Dankeschön. Genau und ihr Hörerinnen und Hörer seid auch sehr nett, vor allem, dass ihr so schön immer zuhört bei uns. Vielen Dank dafür und genau, habt eine schöne Woche und dann hören wir uns nächste Woche wieder.
Bis dann. Tschüssi. Tschüss.
Music.
Musik.