Update 2024

[martinwolf]

Ich habe ein mal alles auf den neusten Stand gebracht im Zuge des Aufsetzen des Fischerei Tegernsee Projektes.

• Das ganze CSS nutzt jetzt @use und @forward.
• Ich habe normalize durch modern-normalize ersetzt
• Das ganze Thema Font Styles ist jetzt mit hier in der Frontend Base und muss nicht immer als Mixin manuell in jedes Projekt kopiert und dort angepasst werden
• Ich würde mir gerne das Thema Fluid Typo nochmal anschauen ob man nicht auf irgendwas mit clamp() wechselt, bzw würde ich gerne weniger CSS ausgeben, wenn z.b. nur XL und S unterschiedliche Schriftgrößen haben, aber dazwischen alles gleich ist und so. -> Update: Ist erledigt. Wir haben eine neue fluid function, die mit clamp() funktioniert und wir geben keinen unnötigen Code mehr aus, wenn die font-size sowieso gleich bleibt.
• Font Style .fs- Klassen können automatisch generiert werden, indem eine $font-styles map mit in die Frontend Base gegeben werden, siehe nächster Punkt für Variablen. @peckomingo und ich glauben aber, dass Font Style Klassen manuell anlegen eher mehr Flexibilität und weniger Code bringt. Kann man pro Projekt abwägen. Bei der Fischerei z.b. teste ich gerade manuell Klassen anlegen. Z.b. in einer globals/_font-styles.scss

@use '@node_modules/@niondigital/frontend-base/css/functions' as *;

.fs-headline {
	font-family: 'Maison Neue Extended', sans-serif;
	font-weight: 500;
	font-size: fluid(12px, 18px);
	line-height: 1.35;
	letter-spacing: 0.1em;
	text-transform: uppercase;
}

.fs-intro {
	font-family: 'Morion', serif;
	font-weight: 100;
	font-size: fluid(22px, 36px);
	line-height: 1.25;
}

• Die Frontend Base bringt ein paar default Variablen mit, die entsprechend in jedem Projekt überschrieben werden können, Beispiel:

@forward "@node_modules/@niondigital/frontend-base/css/vars" with (
	$breakpoints: $breakpoints,
	$show-breakpoints: $show-breakpoints
);

• Zu Variablen ein Gedanke: @peckomingo und ich würden gerne Sass Variablen nur noch nutzen wenn sie auch von Sass weiterverwendet werden und ansonsten in Projekten auf custom properties gehen im Zuge unserer "mehr native CSS Features nutzen" Offensive. 😄
• Mixins werden so in ein Projekt geholt:

@forward "@node_modules/@niondigital/frontend-base/css/mixins";

• Und grundsätzlich wird die frontend base so in ein Projekt geholt:

@use '@node_modules/@niondigital/frontend-base/css/main' as *;

• Ich habe einige alte Mixins und Defaults und so entfernt, die schon eine Weile nicht mehr aktuell sind. Sowas wie das CSS beim object-fit für den javascript polyfill als Beispiel. Oder das aspect-ratio Mixin, was mittlerweile nativ von CSS per aspect-ratio gelöst ist. usw.

Die Updates sind auf jeden fall breaking changes und können nur für neue Projekte so genutzt werden da der ganze Aufbau und Nutzung grundlegend verändert (werden musste). Entsprechend habe ich die Version in der package.json angepasst.

[peckomingo]

Danke @martinwolf Ich wäre auch dafür dass wir das mit den Fonts vereinfachen und flexibler halten.

Grundsätzlich finde ich das mit dem clamp super. Da habe ich schon mal geguckt und es ist dann doch eine Rechnerei um es in einem Range zu halten. Die Rechnerei haben aber bereits andere erledigt. Das schöne dabei, dass es am Ende nur eine Zeile CSS ist.

Hier 2 Artikel mit im Grunde dem selben Inhalt aber unterschiedlich erklärt:
https://www.smashingmagazine.com/2022/10/fluid-typography-clamp-sass-functions, der Artikel hat auch eine scss function was man verwenden könnte und darauf aufbauend die font classes anlegt.
https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp der Artikel erklärt die Mathematik dahinter ganz gut.

Eine font definition könnte daher wie folgt aussehen, das finde ich lesbarer als den fluid mixin den wir im Moment haben, weil es direkt an der property verwendet wird:

.font-headline-1 { font-size: fluid(16px, 31px, 320px, 960px); }

[martinwolf]

@peckomingo Ja, sehr cool! Aktuell definieren wir natürlich pro Breakpoint eine font size und skalieren immer dazwischen, was es sehr flexibel hält. Ist die Frage ob man das weiterhin braucht oder ob es reicht, wenn wir eine min und eine max size definieren und einfach dazwischen skalieren. Wir könnten es natürlich mal so vereinfachen und ich teste das direkt im nächsten Projekt was ich heute starte mal, was ich jetzt starte. Das ist nur ein kleines 3-Seiten Projekt, das würde sich ja anbieten.

[martinwolf]

@peckomingo Ich habe ein Update gepushed, ich finde das so viel besser und einfacher. Man kann weiterhin die Font Styles definieren und die Klassen werden automatisch generiert. Die font-size skaliert via clamp() von kleinster bis größter Größe über alle Breakpoints hinweg. Theoretisch könnte man manuell eingreifen und in einem bestimmten Viewport oder sogar nur zwischen speziellen Viewport Breiten und dort eine andere font-size definieren. Für den Fall, dass man fine tunen müsste.

Ich bin happy, du auch?

Edit: Ich würde es mal noch erweitern, so dass es gar keine fluid clamp function gibt, wenn font-size-min und font-size-max gleich sind.

[martinwolf]

@peckomingo So, nu aber. Jetzt sollte es alles passen. Kein clamp mehr, wenn min und max font size eh gleich sind. Insgesamt geben wir durch den ganzen Umbau jetzt viel weniger CSS aus und es ist viel aufgeräumter und simpler.

[peckomingo]

Finde ich weit besser und genau, wir bleiben mit der fluid function ohnehin flexibel das "on demand" zu überschreiben. Ob man bei jedem Projekt damit auskommt ist halt die Frage. Also ob es nicht manchmal doch notwendig ist das granularer je Breakpoint zu machen.

Ich würde es auch cool finden wenn man bei den definitionen zb. text-transform: none nicht zwingend angeben muss, weil ja lowercase ohnehin ein default ist, oder? 🤔

Längerfristig gedacht, war mein Gedanke war halt noch, wieso wir überhaupt die font-styles in eine tiefe sass map stecken und nicht einfach direkt die CSS selectoren anlegen und dort dann kleinteiligere scss functions (fluid, px-to-rem, etc.) und/oder custom-property variablen (token) verwenden. Ich kann mich nämlich nicht erinnern dass ich jemals direkt auf eine einzelne Variable innerhalb der Font Definitionen zugreifen musste/wollte.

[martinwolf]

@peckomingo

Ich würde es auch cool finden wenn man bei den definitionen zb. text-transform: none nicht zwingend angeben muss, weil ja lowercase ohnehin ein default ist, oder? 🤔

Ja, ist aber ja nur ein mal in der font-styles map, oder? Mein Gedanken da war einfach nur, dass man ein mal den vollen Überblick hat. 🤷‍♂️ In der Regel legt man diese map ja eh nur ein mal am Anfang an.

Längerfristig gedacht, war mein Gedanke war halt noch, wieso wir überhaupt die font-styles in eine tiefe sass map stecken und nicht einfach direkt die CSS selectoren anlegen und dort dann kleinteiligere scss functions (fluid, px-to-rem, etc.) und/oder custom-property variablen (token) verwenden. Ich kann mich nämlich nicht erinnern dass ich jemals direkt auf eine einzelne Variable innerhalb der Font Definitionen zugreifen musste/wollte.

Ja, verstehe ich und hätte ich persönlich auch gar nix gegen. Ich glaube die große Sass Map ist einfach so gewachsen mit dem Gedanken alles irgendwie ordentlich in Variablen abzulegen. Später drauf zugreifen hatte ich nur mal wenn ich irgendwie die line-height für etwas brauchte, aber auch ein sehr besonderer Fall gewesen. Der Zugriff passiert sonst nur beim Erstellen der font-style fs Klassen und irgendwie ist alles ganz nett und sauber und aufgeräumt und so eine config des Projektes.

Aber ich hänge da gar nicht dran und von mir aus könnte man auch die .fs- Klassen manuell anlegen und darin entsprechend kleinteiliger agieren und gar nichts automatisch immer generieren.

Vielleicht lassen wir das volle Programm drin und man kann pro Projekt einfach schauen wie man es macht?
Es könnte ja auch ein Mix sein. Man kann die $font-styles Map nutzen für Font Styles, bei denen man nichts besonderes machen muss und man kann aber auch manuell welche anlegen?
Oder ich lege es in der Frontend Base so an, dass die Klassen nur alle generiert werden, wenn die $font-styles` Map existiert, bzw nicht leer ist?

[peckomingo]

Mein Gedanken da war einfach nur, dass man ein mal den vollen Überblick hat. 🤷‍♂️ In der Regel legt man diese map ja eh nur ein mal am Anfang an.

Das stimmt, aber würden dann ich auch x mal je Font text-transform: none angelegt werden. Wenn 20 Fonts definiert sind, dann eigentlich 20 unnötige Zeilen?

Oder ich lege es in der Frontend Base so an, dass die Klassen nur alle generiert werden, wenn die $font-styles` Map existiert, bzw nicht leer ist?

Das ist super. Dann kann man es vorallem bei kleineren Projekten vielleicht wirklich manuell anlegen.

[martinwolf]

Das stimmt, aber würden dann ich auch x mal je Font text-transform: none angelegt werden. Wenn 20 Fonts definiert sind, dann eigentlich 20 unnötige Zeilen?

Ne, ich fange das alles in dem einen Mixin ab, so dass es bei none nicht ausgegeben wird. Gleiches für text-transform und so. https://github.com/niondigital/frontend-base/pull/4/files#diff-19985440c3a95242bb043755493df83600156e3a87b39d0accb87b68e55db0ebR26-R28