AFANDI Docs / Custom CSS / SCSS Governance
← Back to overview Getting Started

Custom CSS / SCSS Governance

rules for Custom CSS: scope, Kommentare, Testpfade and review.

Moodle AFANDI standard Handover-ready documentation reviewed on a regular cycle

Quick overview

This page describes the working standard for Custom CSS / SCSS Governance – with a focus on concrete decisions rather than general guidance.

The main focus here is which anpassungen in the theme erlaubt are and such as ui-abweichungen freigegeben be so that teams apply the same standard.

The standard only becomes traceable through linked evidence such as design-decisions and through documented edge cases/exceptions.

Practical focusTopic-specificVerifiable

When this page helps

Typical situations in which this page adds value as a working document, and where another document is more appropriate.

Typical use cases

  • when Custom CSS / SCSS Governance as a reusable Moodle standard with clear requirements for theme-standards, tokens and designregeln should serve
  • when authors or trainers work inconsistently on which anpassungen in the theme erlaubt are
  • when Quality assurance and approvals with design-decisions should be documented in a traceable way
  • when Support- or course feedback points to a typical pitfall (e.g. einzelfall-css without governance grows an)

Less suitable when

  • when Custom CSS / SCSS Governance only about a one-off individual case without need for standardization applies
  • when a detailed project ticket or a technical step-by-step guide is the better fit

Recommended process

A pragmatic sequence that works in practice, from scope to review.

  1. Briefly describe the use case and target audience for Custom CSS / SCSS Governance briefly describe; from that scope and expected learning outcome derive the scope and expected learning outcome.
  2. standard setup/configuration define, especially which anpassungen in the theme erlaubt are and such as ui-abweichungen freigegeben be.
  3. Use test users or a reference course to check whether theme-standards, tokens and designregeln work in practice.
  4. Quality assurance/approval carry out and link evidence such as design-decisions link.
  5. After Livegang feedback auswerten and error patterns such as „individual case-CSS without Governance grows an“ as pitfall add.

Decision rules

Note: The general documentation rules remain central. On this Page dokumentierst du only decisions, the Custom CSS / SCSS Governance clearly steuern. Central guideline.

Custom CSS / SCSS Governance is well documented, when rules, Edge cases and Evidence so clearly are, dass teams so that without additional coordination work can.

scope & Wirkung

For Custom CSS / SCSS Governance first define the scope clearly: Theme-Standards, Tokens and Designregeln.

approvalregel

decisions about which anpassungen in the theme erlaubt are and such as ui-abweichungen freigegeben be not implizit lassen, sondern roles and approvals explicitly benennen.

Exceptions cleanly halten

Allow exceptions only if they do not dilute the standard; especially relevant here are custom css/js and maintenance boundaries.

Verifiablekeit

Verifiable is the rule only, when design-decisions and screenshots / review-evidence cleanly verlinkt are.

What should be documented

Here only the spezifischen Inhalte about Custom CSS / SCSS Governance maintain; general documentation rules remain in the centraln guideline. Central guideline.

The page is good when a substitute can apply or review the standard without first collecting tribal knowledge.

scope

terms, scope and boundaries about Custom CSS / SCSS Governance specify in concrete terms, including theme-standards, tokens and designregeln.

Concrete Parameter/rules

Den standard so record, dass which anpassungen in the theme erlaubt are and where branding vs. standard priorisiert becomes eindeutig entschieden are.

evidence

Name and link evidence directly: Design-decisions, Screenshots / review-Evidence, changeshistorie Theme/CSS.

Versionierung

Aktive Exceptions, the latest change and the next review belong on the page—especially for topics with custom css/js and maintenance boundaries.

Common pitfalls

This section captures real-world pitfalls from Custom CSS / SCSS Governance; general guidance belongs in the central guideline. Central guideline.

  • scope driftet: individual case-CSS without Governance grows an.
  • the rule is too abstract: Branding overwrites Usability-rules.
  • evidence is missing: Theme-adaptations brechen after Upgrade.
  • the exception gets out of control: Coursestruktur becomes aus Altcourse kopiert without Bereinigung.
Tip: It is better to document three concrete observations from real cases than to keep a long generic list.

Moodle reference (official docs 5.1)

Kurze Verweise on the offizielle Moodle documentation for Custom CSS / SCSS Governance. So remains this Page AFANDI-spezifisch and vermeidet doppelte Grundlagen.

Official references

Documentation focus

  • Custom CSS with scope, Owner and Regressionstest after Theme-/Moodle-Updates document.
  • UI path, role and test case record explicitly (not only the desired target state).
  • Mark deviations from AFANDI standards separatelyely so that updates remain easier to review.
Note: Moodle interfaces, paths, and options can vary depending on the version, theme, and enabled plugins. Therefore always include the version, role, and test context on the page.

Review & maintenance

Check this Page gegen reale processes about Custom CSS / SCSS Governance – not only gegen the Wortlaut. Entscheidend is, ob standard, Exceptions and Evidence in the Alltag contribute.

  • Are Customizations still upgrade-ready?
  • Passen UI-Elemente to the standard?
  • Were Sonderlösungen reduziert?
  • Passt the Structure to the aktuellen Use case?

Review focus for „Custom CSS / SCSS Governance“: Theme / UI; check especially theme-standards, tokens and designregeln.

Useful metrics

A few metrics are enough – what matters is that they trigger decisions or improvements.

For „Custom CSS / SCSS Governance“ Kennzahlen directly an which anpassungen in the theme erlaubt are and the most frequent Praxisrisiken koppeln.

UI-deviations

Anzahl freigegebener Theme-Exceptions

Interval: monthly

Upgrade-Afterarbeit Theme

Aufwand after Moodle-Upgrade for Theme-Fixes

Interval: pro Release

Design-review-Quote

Anteil UI-changes with review-evidence

Interval: monthly

Next steps

Add jetzt the concrete Entscheidung about which anpassungen in the theme erlaubt are incl. Verantwortlichen, Datum and Verweis on design-decisions.

On „Custom CSS / SCSS Governance“ make especially clear as the next step: which theme-standards, tokens and designregeln apply in the standard case and which exceptions are time-limited.