Dev Guide

Appearance

Return to top
On this page

Allgemeine Anforderungen

Barrierefreier Zugang

Das Frontend muss auch für Menschen mit Behinderung zugänglich sein und die W3C Richtlinien für barrierefreie Webinhalte erfüllen.

Architektur

Frameworks

Um die Komplexität zu verringern sollen Projekte möglichst mit modernen Frameworks umgesetzt werden. Falls nicht explizit anders festgelegt, soll das Frontend Server Side Rendered oder als Static Site Generator entwickelt werden.

Wir empfehlen folgende Frameworks:

Komponentenbasiert

Um unnötige Komplexität zu vermeiden und Source Code für die Zukunft einfach verständlich und erweiterbar zu gestalten, soll das Frontend komponentenbasiert aufgebaut werden. Komponenten können nach Funktion und/oder Seitenzugehörigkeit gegliedert werden.

Dependencies

Abhängigkeiten zusätzlich zum genutzen Framework sollten auf ein Minimum reduziert werden. Ausgewählte Plugins müssen von ihrem Autor oder der Open Source Community aktiv betreut werden: Git Commit History, weekly NPM downloads.

Struktur

Inkludierte Seiten

Alle Projekte beinhalten generell eine 404 Page, sowie Unterseiten für Impressum und Datenschutzerklärung.

Das Frontend wird mit einem Cookie Disclaimer versehen, der auf die Datenschutzerklärung verlinkt.

CSS

Modularität

Globale CSS Dateien gehören der Vergangenheit an. Stattdessen sollen die jeweiligen Styles den einzelnen Komponenten mit Hilfe von Single File Components oder einer jeweiligen ComponentName.css Datei zugeordnet werden. Lediglich globale Regeln und CSS Variablen können gesammelt geschrieben und global importiert werden.

Tooling

Generell ist ein simples PostCSS oder Scss Setup zu bevorzugen. Nach Rücksprache können Dependencies wie Tailwind, Windi CSS oder UnoCSS genutzt werden.

Naming

Elemente sollen nach Möglichkeit nur mit class , nicht mit id gekennzeichnet werden. Generell sollte das Naming aller Klassen der BEM Convention folgen, falls nicht mit Utility Classes gearbeitet wird.

Web Fonts

Web Fonts werden in den zwei gängigen Formaten woff2 und woff eingebunden. eot und ttf werden nur eingebunden wenn Support für ältere Browser notwendig ist.

Modern

css
@font-face {
  font-family: "FontName";
  src: url("fonts/filename.woff2") format("woff2"), url("fonts/filename.woff")
      format("woff");
}

Legacy

css
@font-face {
  font-family: "FontName";
  src: url("fonts/filename.eot");
  src: url("fonts/filename.eot?#iefix") format("embedded-opentype"), url("fonts/filename.woff2")
      format("woff2"), url("fonts/filename.woff") format("woff"), url("fonts/filename.ttf")
      format("truetype");
}


Um bestmögliches Rendering der eingebundenen Schriften zu garantieren, müssen eine Reihe an globalen CSS Regeln integriert werden.

css
body {
  font-feature-settings: "kern" 1;
  font-kerning: normal;
  -webkit-font-smoothing: antialiased; /* Chrome, Safari */
  -moz-osx-font-smoothing: grayscale; /* Firefox */
}

Weitere Opentype Features können in der CSS Sandbox getestet werden.

Performance

Page Speed

Insgesamt muss das Frontend schnell laden, flüßig navigieren und direkt auf Interaktionen reagieren. Der First Meaningful Paint sollte innerhalb von zwei Sekunden erfolgen. Die Time to Interactive sollte weniger als vier Sekunden betragen: RAIL Model.

Google Lighthouse Scores müssen im grünen Bereich liegen.

Animationen müssen flüßig ablaufen und mit 60 fps gerendert werden: Rendering Performance.

Optimierungen

Moderne Frameworks bieten eine Reihe an Performance Optimierungen. Falls nicht mit einem Framework gearbeitet wird, sollen folgende Optimierungen manuell hinzugefügt werden:

Icons & Logos

Sämtliche Icons und Logos müssen als <img src='path/filename.svg'> eingebunden und als inline svg kompiliert werden. Unter Umständen können nach Rücksprache auch Icon Fonts zum Einsatz kommen.

Sonstiges

SEO

Das Frontend enthält eine Sitemap.xml sowie eine für Google optimierte robots.txt. Notwendige Open Graph Tags müssen implementiert werden.