Hilfe:TemplateStyles

This page is a translated version of the page Help:TemplateStyles and the translation is 75% complete.

Outdated translations are marked like this.

Hinweis: Wenn Du diese Seite bearbeitest, stimmst Du zu, dass Dein Beitrag unter der [CC0] veröffentlicht wird. Mehr Informationen findest du auf der Public Domain Hilfeseite.

TemplateStyles enables the complex behavioral and aesthetic styling of templates through the use of referenced external CSS files that are wiki pages themselves. Notably, the ability to create/modify the CSS files is included in the default permissions for autoconfirmed users and so doesn't require involving someone with interface administrator privileges.

Wie funktioniert es?

Bearbeiter können <templatestyles src="[beliebige Seite]" /> zu einer Seite hinzufügen und die Inhalte der referenzierten Seite werden als CSS geparst, bereinigt (englisch „sanitized“) und auf Seiten geladen, auf denen das ‎<templatestyles>-Tag verwendet wird (direkt oder indirekt durch eine Vorlage, die auf der Seite verwendet wird).

[Beliebige Seite] muss das Seiten-Inhaltsmodell (englisch „content model“) sanitized-css (Bereinigtes CSS) haben, welches die Vorgabe für Unterseiten im Vorlagennamensraum ist, die auf .css enden. Empfohlen wird eine Namenskonvention, bei der die Stile für Vorlage:Foo auf einer Unterseite wie Vorlage:Foo/styles.css gespeichert sind. The recommended usage pattern is to store the styles for Template:Foo in a subpage of the template they're most impactful upon, such as Template:Foo/styles.css. Wenn [beliebige Seite] keinen Namensraumpräfix hat, wird der Vorlagennamensraum angenommen. Das heißt, <templatestyles src="Foo/styles.css" /> laden.

Das ‎<templatestyles>-Tag sollte vor dem Inhalt stehen, auf den es wirkt, z. B. ganz oben im Vorlagenquelltext. Das vermeidet potentiell kurzzeitig aufblitzende Inhalte ohne Stil, wenn die Seite bereits teilweise dargestellt wird, während sie noch geladen wird.

Welche Probleme werden gelöst?

TemplateStyles erlaubt es Bearbeitern, Stildefinitionen zu einer spezifischen Seite hinzuzufügen, während gefährliche Konstrukte gefiltert werden. Das funktioniert auch mit Vorschau-/Debug-Tools (wie der TemplateSandbox ) wie vorhergesehen.

Die Hindernisse zu verringern wird hoffentlich zu mehr Innovation in der Art, wie Vorlagen gestaltet sind, und zu geringerem Wartungsaufwand führen sowie eine bessere Anpassung an die Bildschirmauflösung ermöglichen (vor allem an mobile Geräte, die mittlerweile die Hälfte der Seitenaufrufe der Wikipedia verursachen).

Traditionell gibt es zwei Wege, Vorlagen (oder irgendeinen anderen Inhalt) mit Stilen zu versehen: mittels Inline-Definition (durch Benutzen von HTML-Elementen und Anwendung von Attributen wie style="margin: 10px" auf diese) oder durch Benutzen von Seiten im MediaWiki-Namensraum, wie $1. Keine von diesen Möglichkeiten ist in jeder Hinsicht zufriedenstellend.

Using inline styles (that is, raw HTML code with added attributes like style="margin: 10px;")
Using certain special system messages such as MediaWiki:Common.css

In Bezug auf Inline-Styling:

Es gibt keine Trennung von Stilen und Inhalt. In Fällen, wo der Inhalt nicht von einer Vorlage kommt (wie Tabellen in Artikeln), wird der Wikitext zu unübersichtlich für die meisten Bearbeiter.
Da Stilangaben in den Wikitext eingestreut sind, sind Syntaxhervorhebung und andere Arten von Unterstützung bei der CSS-Quelltextbearbeitung schwierig oder nicht möglich.
Stilangaben müssen für jedes HTML-Element wiederholt werden, auf das sie wirken sollen. Die daraus resultierenden zahlreichen Wiederholungen machen den Quelltext schwierig lesbar und wartbar.
Style-Attribute sind auf eine Untermenge von CSS beschränkt. Insbesondere funktionieren @media-Regeln nicht, die für responsives Webdesign benötigt werden. So ist es nicht möglich, Vorlagen zu erstellen, die gut mit einer großen Bandbreite von Bildschirmgrößen funktionieren. Weiterhin haben Inline-Stile Vorrang vor CSS-Stylesheets, so dass Benutzer-, Skin- oder Geräte-abhängige Anpassungen schwieriger werden.

In Bezug auf MediaWiki:*.css-Seiten:

Die Bearbeitung kann nur von Interface-Administratoren vorgenommen werden, was die Beteiligung massiv erschwert.
Bearbeitungs-Beschränkungen können nicht aufgehoben werden da keine Beschränkung der CSS-Regeln möglich ist, die benutzt werden können. Bestimmte Regeln könnten missbraucht werden, um die IP-Adressen von Lesenden mitzuschreiben, oder in einigen älteren Browsern sogar Skripte auszuführen.
Änderungen können nur getestet werden, nachdem sie gespeichert wurden. T112474
Alle Stilangaben müssen auf allen Seiten geladen werden (egal ob sie tatsächlich benutzt werden oder nicht). Das verschwendet Bandbreite und erschwert die Fehlersuche innerhalb der Stilangaben.

Ist es sicher?

Ja! TemplateStyles enthält einen CSS-Parser , der den CSS-Quelltext liest, serialisiert, allen Code escapet und CSS-Regeln entfernt, die er nicht erkennt. Der Parser wird insbesondere externe Ressourcen (wie Hintergrundbilder) entfernen, dabei aber lokale erlauben. Weiterhin werden die CSS-Selektoren umgeschrieben, so dass sie nur innerhalb des Artikeltextes wirksam werden. (Visuelle Änderungen wie das Ändern der Position mit dem Position-Attribut und andere, bereits vorher mit Inline-Definitionen mögliche Definitionen funktionieren wie gehabt.)

Allowed CSS properties and rules

As of 5. März 2025, TemplateStyles accepts no fewer than 331 CSS properties and aliases, including the vast majority of those most often used on the modern internet with official support by one or more major web browser. Beyond simple rules, @media, @page, @supports, @keyframe, @font-face/@font-feature-values at-rules are also supported (with font-face restricted to fonts whose name starts with TemplateStyles, for security reasons).

CSS property declarations permitted by css-sanitizer ^[a]^[b]^[c]

Note: Each property is linked to a source of documentation on its usage, however the typical external link icons have been suppressed to prevent the obscuring of any links to footnotes that similarly appear in superscript.

Hinweise:

↑ This list is current as of changeset ffe10a21512f to the css-sanitizer source code repository, authored at 20:34, 5. Mär. 2025.
↑ The authoritative reference for these properties will always be the source code for the css-sanitizer library, specifically the src/Sanitizer/StylePropertySanitizer.php file. When reviewing it, a simple method for bringing them into greater focus is to perform a full text search of the contents for the string $props.
↑ Non-standard properties—including those with vendor prefixes, except for the vendor-prefixed -*-user-select group—have never been recognized by this extension and continue to be automatically rejected, as of Januar 2024; see T162379: Decide which non-standard CSS properties to support in TemplateStyles for notice of any progress on a resolution to this issue.
↑ The modern block-ellipsis property is present in the extension source code only by its original name, block-overflow (Line 676 at changeset ffe10a21512f). Though the property was renamed during drafting by the W3C-CSSWG in August 2018 and is now only a legacy alias, until the extension is updated only the original property name is accepted as valid.
↑ ^5.0 ^5.1 ^5.2 ^5.3 ^5.4 ^5.5 ^5.6 ^5.7 The page-break-* properties from CSS2 were deprecated by the W3C-CSSWG in September 2018 and persist only as legacy shorthands for the break-* replacement properties from the CSS3 Fragmentation module. They are subject to removal in the future and users are strenuously encouraged to replace all uses of the older properties explicitly, paying attention to the fact that not all values have a 1:1 equivalent mapping with the replacements' values. Several popular user agents have already demonstrated flawed and inconsistent behavior when the legacy shorthands are present on a page.
↑ The clip property was deprecated by the W3C-CSSWG in Juli 2018, and official guidance was added to use the clip-path property in its place; it is subject to removal at any time due to definition conflicts with other properties.
↑ The legacy name alias grid-column-gap is also accepted as valid by this extension and is evaluated exactly as if its modern replacement property name, column-gap, had been used.
↑ The modern continue property, which is accepted by this extension, must always be used in place of the older region-fragment property, which it never accepted as valid. The W3C-CSSWG describes 'continue' as generalizing the older property ahead of replacing it altogether, but care must be taken during the conversion as different values must be defined to achieve identical behaviors between the two.
↑ The modern font-width property is present in the extension source code only by its original name, font-stretch (Line 543 at changeset ffe10a21512f). Though the original name was deprecated by the W3C-CSSWG in Januar 2024 and remains only as a legacy alias, until the extension is updated only the original property name is accepted as valid.
↑ The legacy name alias grid-gap is also accepted as valid by this extension and is evaluated exactly as if its modern replacement property name, gap, had been used.
↑ The non-standard property, word-wrap, is also accepted as valid by this extension and is directly aliased to the official property overflow-wrap.
↑ The legacy name alias grid-row-gap is also accepted as valid by this extension and is evaluated exactly as if its modern replacement property name, row-gap, had been used.
↑ ^13.0 ^13.1 Though the creation of the text-align-all property as a constituent value of the text-align shorthand by the W3C-CSSWG took place in Dezember 2018, supporting implementations did not begin appearing until 2025 and, as of the most recent official guidance on März 24, 2025, the recommendation to eschew the new property and continue to use the shorthand remains in effect.

Wie kann ich mobile und Desktop-Auflösungen berücksichtigen?

Medienabfragen (englisch „media queries“) erlauben es, gezielt Elemente in Auflösungen für Mobil- und Desktopgeräte zu beeinflussen. Manche Leute empfehlen, Stile mobilfreundlich zu gestalten und Desktopstile in die Medienabfrage zu integrieren. Beachte, dass MediaWiki standardidisierte Umbruchsbreiten bei 640px and 1120px besitzt (Umbruchsbreite: englisch „breakpoint“) für die Darstellung in Tablet- und Desktop-Auflösungen.

Wie kann ich spezifische Benutzeroberflächen berücksichtigen?

MediaWiki bietet stellt verschiedene Klassen in den html- und body-Elementen bereit, darunter eine, die anzeigt, welche Benutzeroberfläche (englisch „skin“) in Verwendung ist. So kann die Beeinflussung dadurch erfolgen, dass ein simpler Selektor an das html- oder body-Element angehängt wird bestehend aus der benötigten Klasse, gefolgt von einem Leerzeichen (oder in CSS-Begriffen vom Nachfahrenkombinator, englisch „descendant combinator“).

Im Allgemeinen sollte diese Technik nur für die Konsistenz des Designs verwendet werden, anstatt Mobil- und Desktopauflösungen zu beeinflussen, da alle Skins für diese Auflösungen verwendet werden können. Siehe auch Wie kann ich mobile und Desktop-Auflösungen berücksichtigen?

/* Elements with class 'foo' will have red text in all skins. */
.foo { color: red; }

/* Override that element's color to green for the Vector skin only. */
body.skin-vector .foo { color: green; }

/* Add a red border if the browser doesn't have JavaScript enabled. */
html.client-nojs .foo { border: 1px solid red; }

/* Declare that same border as green for the Vector skin. */
html.client-nojs body.skin-vector .foo { border-color: green; }

/* This does not work; the 'body' element must be selected! */
.skin-vector .foo { background: orange; }

/* These do not work, either; the descendant combinator must be used. */
body.skin-vector > .foo { background: orange; }
body.skin-vector ~ .foo { background: orange; }
html.client-nojs > body.skin-vector .foo { background: orange; }

Wie verwende ich Stile in MediaWiki-Nachrichten?

Um zu verhindern, dass böswillige Akteure Teile des Dokuments außerhalb des Inhaltsbereiches beeinflussen können, wird allen CSS-Regeln automatisch die CSS-Klasse mw-parser-output vorangestellt. Wenn TemplateStyles-basierte Vorlagen außerhalb des Inhaltsbereichs verwendet werden (z. B. in den Seitenhinweisen ), dann muss diese Klasse gesondert bereitgestellt werden, indem die Vorlage in <div class="mw-parser-output">…</div> oder ähnlich eingefasst wird.

In welcher Reihenfolge übersteuern CSS-Stile einander?

Welche CSS-Regel aktiv ist, wird beeinflusst von der Spezifität (grob gesagt der Komplexität des Selektoren – beispielsweise ist div.foo { margin: 10px } spezifischer als .foo { margin: 5px }). Wenn die Spezifität gleich ist, übersteuern CSS-Stile, die später im Dokument vorkommen, frühere Stile.

MediaWiki:Common.css, andere projektweite Skripte, Benutzerskripte und Helferlein werden im ‎<head>-Bereich der Seite geladen. TemplateStyles-Stile werden im ‎<body> geladen, so dass sie Regeln aus Projekt-/Benutzskripten und Helferlein übersteuern, wenn die Spezifität identisch ist, und im Falle zweier TemplateStyles-Regeln übersteuert die zweite die erste. (Beachte aber, dass in TemplateStyles ein Dublettenabgleich erfolgt: Wenn dieselbe Regel auf einer Seite mehrfach referenziert wird, wird sie nur beim ersten Mal eingefügt.

Beachte auch, dass „später“ sich auf die Position im Dokument bezieht, nicht auf die Reihenfolge des Ladens. Helferlein fügen ihr CSS hinzu, nachdem die Seite geladen ist, indem sie mittels JavaScript manipuliert wird; manche fügen es auch erst auf Anforderung durch den Benutzer ein, wenn er eine Aktion auslöst, etwa durch Drücken eines Schalters. Trotzdem fügen sie es in den Kopfbereich ein, also in <head>, so dass CSS-Regeln mit gleicher Spezifität aus dem <body> Vorrang vor ihnen erhalten.)

Wie können Lua-Module mit Stilen interagieren?

TemplateStyles kann aus einem Lua-Modul heraus aufgerufen werden mit Hilfe von frame:extensionTag.

Vergleiche folgenden Beispielcode:

local p = {};

function p.templateStyle( frame, src )
    return frame:extensionTag( 'templatestyles', '', { src = src } );
end

return p;

Welche Anti-Missbrauch-Funktionen werden bereitgestellt?

Die Designentscheidung, CSS auf separaten Seiten zu speichern, erfolgte zum Teil aus dem Grund, die Integration in das Standard-Antimissbrauchs-Toolset leicht zu machen. TemplateStyles-CSS-Seiten besitzen ihr eigenes Inhaltsmodell (sanitized-css), so dass Änderungen an ihnen mit Erweiterung:Missbrauchsfilter verfolgt ud kontrolliert werden können (mit der Variable new_content_model).

Die CSS-Einbindung wird auf die gleiche Weise wie die Transklusion von Vorlagen verfolgt, sodassDu über die Option "Links auf diese Seite" sehen kannst, wo ein Stylesheet verwendet wird und welche Stylesheets auf einer Seite unter "Seiteninformationen" (und möglicherweise auf dem Bearbeitungsbildschirm) verwendet werden Klicke auf den von Dir verwendeten Editor, und überprüfe mithilfe von "Änderungen an verlinkten Seiten", welche Änderungen sich auf eine Seite auswirken können.

TemplateStyles hinterlässt auch im HTML-Code identifizierbare Informationen; um herauszufinden, woher eine spezifische Regel stammt, sieh im Seitenquelltext nach – das einschließende ‎<style>-Tag wird ein Attribut wie data-mw-deduplicate="TemplateStyles:r123456" besitzen, wo 123456 die Revisions-ID des Stils ist (beispielsweise sichtbar mit Special:Diff).

Wie wurden die Entscheidungen in Bezug auf TemplateStyles getroffen?

Die Idee, CSS mit Vorlagen einzubinden, wurde in einem Request for Comments vorgeschlagen und akzeptiert. Technische Details wurden in einem zweiten RfC festgehalten und Workflow-Details in einer Benutzerbefragung.

Wer arbeitet an TemplateStyles?

TemplateStyles war ursprünglich ein Projekt der Wikimedia Reading Infrastructure team (vorausgegangen waren Untersuchungen durch Coren als Freiwilliger) und setzte sich damals aus Brad Jorsch (Entwickler), Bryan Davis (Manager) und Gergő Tisza (Entwickler) zusammen. Die Personen und Verantwortlichkeiten haben seitdem gewechselt. Siehe die Maintainer-Seite für die aktuellen Zuständigkeiten.

Wo melde ich Fehler/frage ich nach Features?

Wende dich dazu bitte an den Bereich File Tasks im TemplateStyles-Teil von Phabricator.

Wo kann ich es in Aktion sehen?

Du kannst dir einige Beispiele ansehen.

Die TemplateStyles-Erweiterung ist in allen Wikimedia-Projekten aktiviert.

Siehe auch

Erweiterung:TemplateStyles – speziell den Abschnitt Caveats.
Wikipedia:TemplateStyles – Empfehlungen für die Verwendung in der englischsprachigen Wikipedia.

[current-asof-1] This list is current as of changeset ffe10a21512f to the css-sanitizer source code repository, authored at 20:34, 5. Mär. 2025.

[truth-source-2] The authoritative reference for these properties will always be the source code for the css-sanitizer library, specifically the src/Sanitizer/StylePropertySanitizer.php file. When reviewing it, a simple method for bringing them into greater focus is to perform a full text search of the contents for the string $props.

[vendor-prefixes-3] Non-standard properties—including those with vendor prefixes, except for the vendor-prefixed -*-user-select group—have never been recognized by this extension and continue to be automatically rejected, as of Januar 2024; see T162379: Decide which non-standard CSS properties to support in TemplateStyles for notice of any progress on a resolution to this issue.

[block-ellipsis-4] The modern block-ellipsis property is present in the extension source code only by its original name, block-overflow (Line 676 at changeset ffe10a21512f). Though the property was renamed during drafting by the W3C-CSSWG in August 2018 and is now only a legacy alias, until the extension is updated only the original property name is accepted as valid.

[page-break-5] 5.0 ^5.1 ^5.2 ^5.3 ^5.4 ^5.5 ^5.6 ^5.7 The page-break-* properties from CSS2 were deprecated by the W3C-CSSWG in September 2018 and persist only as legacy shorthands for the break-* replacement properties from the CSS3 Fragmentation module. They are subject to removal in the future and users are strenuously encouraged to replace all uses of the older properties explicitly, paying attention to the fact that not all values have a 1:1 equivalent mapping with the replacements' values. Several popular user agents have already demonstrated flawed and inconsistent behavior when the legacy shorthands are present on a page.

[clip-6] The clip property was deprecated by the W3C-CSSWG in Juli 2018, and official guidance was added to use the clip-path property in its place; it is subject to removal at any time due to definition conflicts with other properties.

[grid-column-gap-7] The legacy name alias grid-column-gap is also accepted as valid by this extension and is evaluated exactly as if its modern replacement property name, column-gap, had been used.

[region-fragment-8] The modern continue property, which is accepted by this extension, must always be used in place of the older region-fragment property, which it never accepted as valid. The W3C-CSSWG describes 'continue' as generalizing the older property ahead of replacing it altogether, but care must be taken during the conversion as different values must be defined to achieve identical behaviors between the two.

[font-width-9] The modern font-width property is present in the extension source code only by its original name, font-stretch (Line 543 at changeset ffe10a21512f). Though the original name was deprecated by the W3C-CSSWG in Januar 2024 and remains only as a legacy alias, until the extension is updated only the original property name is accepted as valid.

[grid-gap-10] The legacy name alias grid-gap is also accepted as valid by this extension and is evaluated exactly as if its modern replacement property name, gap, had been used.

[word-wrap-11] The non-standard property, word-wrap, is also accepted as valid by this extension and is directly aliased to the official property overflow-wrap.

[grid-row-gap-12] The legacy name alias grid-row-gap is also accepted as valid by this extension and is evaluated exactly as if its modern replacement property name, row-gap, had been used.

[text-align-all-13] 13.0 ^13.1 Though the creation of the text-align-all property as a constituent value of the text-align shorthand by the W3C-CSSWG took place in Dezember 2018, supporting implementations did not begin appearing until 2025 and, as of the most recent official guidance on März 24, 2025, the recommendation to eschew the new property and continue to use the shorthand remains in effect.

[a]

[b]

[c]

[d]

[e]

[f]

[g]

[h]

[i]

[j]

[k]

[l]

[m]