Willkommen
Vision
Wir machen gemeinsam HTML mittels wiederverwendbaren Web Components semantisch barrierefrei, um die Usability und Zugänglichkeit sicherzustellen.
Mission
Der
Kollaboration und Kooperation
Der Fokus von
Bei diesen atomaren Komponenten sollten wir kollaborieren und kooperieren, um unsere Fähigkeiten und unser Wissen zu bündeln. Durch die Synergieeffekte an den Basis-Komponenten kann der eigene Fokus mehr auf fachspezifische Inhalte gelegt werden.
Lasst uns dazu gemeinsam
Lizenz
Zugänglichmachung: Die Artefakte und der Quellcode können von jedem frei und kostenlos wiederverwendet werden. Hierdurch leistet der ITZBund einen Beitrag im Sinne von
. Gewährleistungs- und Haftungsausschluss: Mit der Wiederverwendung gehen keinerlei Gewährleistung und Haftungsansprüche einher.
„Copyleft“-Klausel: Copyleft besagt, dass jede Kopie von
KoliBri (Fork) wieder unter derselben oder einer kompatiblen Open-Source-Lizenz veröffentlicht werden muss.
Abgrenzung
Um
Styling
Je mehr relevante Komponenten gefunden und umsetzten werden, desto wertschöpfender wird der Nutzen für alle webbasierten Projekte.
Rendering
Web Components können technologisch sowohl Client-seitig (CSR), prerendered (SSG), als auch Server-seitig (SSR) gerendert werden. Das Rendering ist dabei von den jeweils technischen Rahmenbedingungen abhängig (
💡 Es ist zu beachten, dass Web Components ein auf JavaScript basierender Webstandard ist. Das Server-Side-Rendering ermöglicht das Prerendern der Web Component für eine optimale Anzeigegeschwindigkeit auf dem Client. Wenn Client-seitiges JavaScript erlaubt ist, steht die vollständige Dynamik der Web Component auch Client-seitig zur Verfügung. Möchte man jedoch Client-seitig kein JavaScript einsetzen, wird die Web Component geprerendert angezeigt, aber die Dynamik geht dadurch verloren. 🧪 Das Server-Side-Rendering von Web Components ist eine neue spannende Funktionalität, wo noch Anpassungen an den Prerenderer notwendig sein werden und wird daher unsererseits als experimentell eingestuft (
Versionierung
Aufbau einer Version:
Sie besteht in der Regel aus 3 Teilen (z. B. 1.0.2)
Major, hier die 1
Minor, hier die 0
Patch, hier die 2
Für die Releasephase einer Version kann man zusätzlich Labels verwenden (z. B. 1.0.3-rc.2)
Label, hier die rc.2
Folgende Hauptprinzipien kommen dabei zur Anwendung:
Patch: Beinhaltet Änderungen, die den aktuellen Funktionsumfang verbessern und in seiner Verwendung nicht ändern.
Minor: Beinhaltet Änderungen, die den Funktionsumfang erweitern und den bestehenden Funktionsumfang in seiner Verwendung nicht ändern.
Major: Beinhaltet Änderungen, die eine architektonische Neuausrichtung ermöglichen und den bestehenden Funktionsumfang in seiner Verwendung ändern dürfen.
Die komplette Beschreibung der SemVer finden Sie hier:
Qualitätsziele
In der folgenden Tabelle werden die priorisierten Qualitäten von
Geräte-, Betriebssystem-, Browser- und Screenreader-Anforderungen
Der Microsoft Internet Explorer wird explizit nicht unterstützt, um das Projekt und die Entwicklung nicht durch Altlasten zu schwächen.