Wir haben kürzlich mit Elad Shechter über seinen neuen CSS-Reset gesprochen, und kurz darauf hat Josh Comeau seinen eigenen veröffentlicht.
Wir befinden uns in einer Art neuer Ära der CSS-Resets, in der… man eigentlich keinen mehr braucht? Es gibt nicht *so* viele gravierende Unterschiede bei der Standardformatierung zwischen Browsern, und bis du anfängst, Dinge zu formatieren, hast du sie wahrscheinlich sowieso schon zurechtgestutzt. Und so sind „moderne“ CSS-Resets vielleicht eher eine Sammlung von meinungsstarken Standardformatierungen, die nützliche Dinge tun, die du bei all deinen neuen Projekten haben möchtest, weil du eben so tickst.
Wenn ich mir Joshs Auswahl ansehe, scheint es mir so: eine Sammlung von Dingen, die nicht besonders meinungsstark in Bezug auf das Design sind, aber das Design *unterstützen*, indem sie Dinge sind, die praktisch jedes Projekt haben will.
Ich werde es durchgehen und 🔥 feurig heiße Meinungen dazu abgeben.
*, *::before, *::after {
box-sizing: border-box;
}Heck ja. Früher haben wir das hier als globalen Feiertag betrachtet. Obwohl mit immer mehr Layouts, die von Grid und Flexbox gehandhabt werden, habe ich das Gefühl, dass dies heutzutage etwas weniger nützlich ist. Wenn du ein Layout mit fr Einheiten einrichtest und Dinge flexibler gestaltest, kommt das box-sizing Modell nicht mehr so sehr ins Spiel, selbst wenn padding und border beteiligt sind. Aber hey, ich ziehe es trotzdem vor, dass es vorhanden ist. Ich denke zwar, wenn es in ein CSS-Reset aufgenommen wird, sollte es das Vererbungsmodell verwenden, da es auf diese Weise einfacher ist, es für eine Komponente rückgängig zu machen.
* {
margin: 0;
}Das ist im Grunde der Grund, warum das „Stern“-Logo von CSS-Tricks existiert. Früher habe ich dieses kleine Snippet in meinen CSS-Resets geliebt. Es gab eine Zeit, in der es sich wie eine Übertreibung anfühlte, aber ich glaube, ich mag es wieder. Ich mag, wie explizit man sein muss, wenn man überhaupt irgendeinen Abstand anwendet. Persönlich würde ich auch padding: 0; verwenden, da Listenelemente dazu neigen, etwas Abstand zu haben, der sie herumschiebt. Wenn du Abstandsdinge ausradierst, radiere sie gleich alle aus.
html, body {
height: 100%;
}Wahrscheinlich ein guter Plan. Josh sagt: „Erlaube prozentuale Höhen in der Anwendung“, was ich nicht sagen kann, dass es in meinem Tagesgeschäft häufig vorkommt, aber es bewirkt Dinge wie, dass der Body-Hintergrund nicht den erwarteten Raum ausfüllt.
Zu schade, dass body { height: 100vh; } hier nicht ausreicht, aber ich habe das Gefühl, dass das aus irgendeinem Grund, den ich mir gerade nicht erklären kann, nicht so zuverlässig ist. Vielleicht hat das etwas mit der Fußzeilen-Navigation in iOS Safari zu tun?
body {
line-height: 1.5;
-webkit-font-smoothing: antialiased;
}Ich kann mich auf das -webkit-font-smoothing: antialiased; Ding nicht einlassen. Ich denke, es macht die Schriftart dramatisch dünn und das gefällt mir nicht. Ich habe nichts dagegen als Werkzeug, aber ich würde es nicht global auf all meine Projekte anwenden.
Ich neige auch dazu, globale typografische *Größen*-Dinge auf den html Selektor zu legen, einfach weil der „Root“-Teil von rem das <html> Element impliziert – nicht den <body> – und ich mag es, Dinge in rem zu dimensionieren und dann die Root-font-size auf Root-Ebene in Media Queries anzupassen.
Dieser 1.5 Wert fühlt sich nach einer guten Standard-line-height an (ich bin eher ein 1.4-Typ, aber ich gehe lieber nach oben als nach unten). Aber sobald er gesetzt ist, fühle ich mich magnetisch angezogen, ihn für Überschriftenelemente zu reduzieren, wo er *immer* zu viel ist. Das könnte über Selektoren wie h1, h2, h3 geschehen (vielleicht brauchen h4–h6 das nicht), aber Josh hat einige CSS-Tricks in Arbeit mit diesem Snippet, das es nicht in das endgültige Reset geschafft hat
* {
line-height: calc(1em + 0.5rem);
}Das ist clever, wie die 0.5rem für kleine Schriftarten weit reicht, aber keinen so großen Einfluss auf große Schriftarten hat. Ich könnte mir vorstellen, das bei einem Greenfield-Projekt auszuprobieren. Vorherige Arbeit hier ist von Jesús Ricarte in „Using calc to figure out optimal line-height.“
img, picture, video, canvas, svg {
display: block;
max-width: 100%;
}Gute Sache für ein CSS-Reset. Der block Display-Typ dort verhindert diese ärgerlichen line-height Lücken, die mich immer umbringen. Und du willst fast nie, dass diese Medienblöcke breiter als das Elternelement sind. Ich glaube jedoch nicht, dass picture notwendig ist, da es nicht wirklich ein formatierbarer Block ist? Könnte mich irren. Ich würde wahrscheinlich auch iframe und object da hineinwerfen.
p, h1, h2, h3, h4, h5, h6 {
overflow-wrap: break-word;
}Gute Sache, auf jeden Fall. Es ist schlecht, wenn ein langes Wort (wie eine URL) ein Element breit erzwingt und ein Layout verdirbt. Ich neige dazu, das auf etwas zu werfen – wie article oder .text-content oder so etwas – und es in diesen ganzen Bereich kaskadieren zu lassen (was auch Text auffangen würde, der sich zufällig in einem unpassenden Element befindet), aber es stört mich nicht, es auf spezifische Textelemente angewendet zu sehen.
Wenn du das tust, möchtest du wahrscheinlich li, dl, dt, blockquote an diese Kette hängen. Trotzdem ich versucht habe, das mehrmals zu recherchieren (hier ist ein Spielplatz), weiß ich immer noch nicht zu 100 % genau, welches die richtige Mischung aus Zeilenumbruch-Eigenschaften ist. Es gibt word-break: break-word;, von dem ich denke, dass es im Grunde dasselbe ist. Und ich denke, es ist generell am besten, auch hyphens: auto; zu verwenden… richtig??
#root, #__next {
isolation: isolate;
}Ich verstehe nicht ganz, was hier passiert. Ich verstehe, dass dies eine React/Next-Sache ist, bei der du die App an diese Roots bindest, und ich verstehe, dass es einen Stack-Kontext erzeugt, ich verstehe einfach nicht, warum es *spezifisch* nützlich ist, diesen Stack-Kontext auf dieser Ebene zu *haben*. Gleichzeitig sehe ich aber auch kein besonderes Problem damit.
Alles in allem – ziemlich cool! Ich sehe es immer gerne, was andere Leute für CSS-Resets verwenden (und sogar vorschlagen).
Ich arbeite schon eine Weile an meinem eigenen. Es ist etwas mehr als ein Reset und etwas weniger als eine Bibliothek. Ich versuche, es super klein zu halten, aber auch einige vernünftige Standards zu haben
https://bedrocss.austingil.com/
Schön! Erinnert mich ein wenig an MVP CSS, aber vielleicht etwas abgespeckter.
Basierend auf dem Blogbeitrag klingt die Idee mit
#root, #__next { isolation: isolate; }so, dass sie sicherstellt, dass du, wenn du irgendwann ein Modal hinzufügst, das ein React Portal verwendet, um das Modal als direkten Nachkommen desbodyeinzufügen, nicht aufz-indexProbleme stößt, bei denen bestimmte Elemente auf deiner Seite über deinem Modal gerendert werden würden.Ein weiteres interessantes CSS-Reset ist Sanitize.css
Es ist sogar noch meinungsstärker als Joshs bestehendes.
https://csstools.github.io/sanitize.css/
Re: Wortbruch-Cocktail, das ist das Snippet, das ich 2016 erstellt habe. (Einige Teile sind wahrscheinlich inzwischen veraltet) und ich benutze es weiterhin als Utility-Klasse in meinen Projekten: https://stackoverflow.com/a/36555643/2382115
Ich würde sagen, dass das Anwenden dieser Stile auf das picture-Element eine gute Sache ist. Es passiert nicht jedes Mal, aber ich bin schon auf viele Situationen gestoßen, in denen ich wollte, dass ein img seinen Container füllt, nur um mit „haHA! Ich bin der Container!“ von einem picture-Element konfrontiert zu werden, das seinen Container nicht füllte. Dann muss ich beides ansprechen, und… Es ist ziemlich hässlich, und ich habe das Gefühl, ich muss kommentieren, was passiert, wenn ich das tue, da es plötzlich eine Einzelfallentscheidung ist :/
Also ja, das picture-Element kann definitiv so gestylt werden und kann definitiv Probleme verursachen, wenn du es am wenigsten erwartest. Wahrscheinlich am besten, es im Voraus zu erwischen, wenn du ein neues Projekt beginnst.
Ich sehe viel Gutes in Joshs CSS-Reset, aber ich bin entschieden gegen die Verwendung von
display: blockaufimgundsvgElementen, da dies das erwartete Verhalten im Grunde zerstört. Soweit ich weiß, macht Tailwind das auch, und es kann zu erheblichen Irritationen führen, sobald man Inline-Bilder wirklich braucht. Ich hatte damit in mehreren Projekten Probleme, bei denen SVG-Icons inline mit Text angezeigt werden mussten, und in einem anderen Projekt, bei dem handgezeichnete PNG-Grafiken zur Verbesserung des Erscheinungsbildes eines Textblocks verwendet wurden.Mein eigener Reset fügt nur
vertical-align: bottomzu den Bildelementen hinzu, da dies auch das Problem mit dem unteren Abstand löst, aber meiner Meinung nach weniger Nebenwirkungen hat.Welche Ebene meinst du? Meine Vermutung ist, dass bei SPAs diese Ebene mehr oder weniger ein direkter Nachkomme des
htmlTags ist, aber bei Micro Frontends kann sie so verschachtelt sein, wie du möchtest.Diese
height: 100%auf den html- und body-Elementen hat Probleme/Fallstricke…Mit diesem CSS werden die html/body-Elemente nicht richtig erweitert, wenn ihr Inhalt überläuft. Mehr Details hier
https://stackoverflow.com/a/38908284/852382
Du schlägst vor, „rem“ zu verwenden, so wie hier
=> line-height: calc(1.0em + 0.5rem);
Aber ich denke, wir müssen stattdessen „pixel“ verwenden
=> line-height: calc(1.0em + 8px);
Denn wenn der Benutzer die Browser-Schriftgröße ändert (z. B. von 16px auf 32px), wollen wir weiterhin „nur“ 8 Pixel hinzufügen und nicht plötzlich 16 Pixel.
IN BEIDEN FÄLLEN
Wenn die Browser-Schriftgröße 16px beträgt
• Eine CSS-Schrift von 1,25 rem (auch 20px) hat eine Zeilenhöhe von 28px (auch Zeilenhöhe von 1,4). • Eine CSS-Schrift von 2,5 rem (auch 40px) hat eine Zeilenhöhe von 48px (auch Zeilenhöhe von 1,2).
=> Der Trick funktioniert.
ABER
Mit „rem“, wenn die Browser-Schrift auf 32px geändert wird
• Die erste CSS-Schrift wird zu 40px und ihre Zeilenhöhe zu 56px (auch Zeilenhöhe von 1,4). Plötzlich fügen wir „16px“ hinzu, und nicht nur „8px“.
=> Der Trick funktioniert nicht mehr.
Mit „pixel“, wenn die Browser-Schrift auf 32px geändert wird
• Die erste CSS-Schrift wird zu 1,25 rem = 40px und die Zeilenhöhe zu „nur“ 48px (auch Zeilenhöhe von 1,2)
=> Der Trick funktioniert weiterhin.
Ich hoffe, ich habe keinen Fehler gemacht. Die von mir durchgeführten Tests scheinen meinen Punkt zu bestätigen, aber ich bin weit davon entfernt, ein Experte auf diesem Gebiet zu sein. Vielen Dank für all deine sehr nützlichen Artikel!