Gespräch:Vector-Skin CSS Überschriften

Über diese Seite Gespräch

Überschriften Styling anpassen
ChatGPT Sophos GPT-5 ThinkingChatGPT Sophos GPT-5 Thinking
25. September 2025 n. Chr. erst.  
8:38 Uhr Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
2025092501 Vector-Skin CSS Überschriften

Hallo Sophos,

nachdem wir gerade ein Gadget gebaut haben um mittels Überschriften Abteilungen nach Bedarf auszublenden und einzublenden und diesen Stand lokal speichern wenden wir uns kurz dem Umstand zu, das in Vector-Skin das Styling der Überschriften so nicht zuträglich ist, insondern sind ab h4 die Überschriften gleichgroß und daher nicht unterscheidbar.

Wo setzt man am besten wie an, um Überschriften in Semnatic MediaWiki global einheitlich zu gestalten – MediaWiki:Common.css?

Außerhalb des Body soll es bleiben wie es ist.

Ich habe die Extensions TemplateStyles und CSS installiert

Alle Überschriften sollen einen Unterstrich haben, der wie derzeit bei den Überschriften von links nach rechts über die ganze Seite geht.

h6 soll in der Schriftgröße des Standard-Wikitext entsprechen, jedoch kursiv

h5 soll in der Schriftgröße des Standard-Wikitext entsprechen , jedoch nicht kursiv

h4 soll dann nur etwas größer sein als h5

h3 soll dann nur etwas größer sein als h4

h2 soll dann nur etwas größer sein als h3

h1 soll dann nur etwas größer sein als h2

Haupsächlich wird eine Überschrift durch den Queerstrich als solche erkannt. Beim Scrollen übersieht man Überschriften leicht bei viel und wechselhaftem Text und so braucht man nur auf die Lnien zu achten. Die Linien sollten unterschiedlich gestaltet werden, entweder gemäß Dicke oder gestrichelt.

Was meinst du, wo man da wie ansetzen sollte und was sagst du zu der Vorstellung, Überschriften anhand von Linien leicher aufspürbar zu machen?

ChatGPT:

Nachgedacht

I need to give a solution that sets font sizes relative for headings while also adding a full-width underline. I could use border-bottom on heading elements and maybe experiment with background linear-gradient for the line. For full-width lines, I’ll apply the styles within content columns, accounting for different heading levels and sizes. I should avoid affecting elements like navs by being specific with selectors. I'll suggest using MediaWiki:Common.css for global heading styles, targeting .mw-parser-output h2-h6 with a CSS snippet. I can also propose an optional TemplateStyles approach for more specific use cases, applying styles only to individual pages. For the headings, I'll define different underline styles and set font sizes with a bit of variation per level. Fertig

Hallo Nikolaos — gute Idee! Zwei Punkte vorweg:

• Global & sicher: Für eine einheitliche Gestaltung im Inhaltsbereich (ohne Seitenkopf, Sidebar, Portlets etc.) ist MediaWiki:Common.css der richtige Ort. Verwende dabei den Container-Selektor .mw-parser-output, dann greift das Styling nur auf Artikelinhalt.
• Opt-in möglich: Für Ausnahmen oder Testbereiche kannst du zusätzlich TemplateStyles nutzen (eigene /styles.css), ohne die Site-weiten Regeln zu berühren.

Unten ein kompakter Vorschlag, der

• ab H6 exakt die Body-Schriftgröße nutzt (H6 kursiv, H5 normal),
• danach jede Ebene nur leicht größer macht,
• jede Ebene mit einer Linie über die volle Inhaltsbreite kennzeichnet (unterschiedliche Stärke/Strichart zur schnellen visuellen Unterscheidung),
• und Anker-Sprünge mit Sticky-Headern angenehmer macht.

In MediaWiki:Common.css

/* ===== Einheitliche Überschriften nur im Inhaltsbereich (Vector/SMW) ===== */
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  margin-top: 1.6em;          /* Luft oberhalb für Scroll-Erkennung */
  margin-bottom: 0.6em;
  padding-bottom: 0.2em;       /* Platz für die Linie */
  line-height: 1.25;
  scroll-margin-top: 4rem;     /* für sticky header */
}

/* Größenabstufung: H6/H5 = Bodygröße, dann in kleinen Schritten größer */
.mw-parser-output h6 { font-size: 1em; font-style: italic; font-weight: 600; }
.mw-parser-output h5 { font-size: 1em; font-style: normal; font-weight: 700; }
.mw-parser-output h4 { font-size: 1.1em; font-weight: 700; }
.mw-parser-output h3 { font-size: 1.2em; font-weight: 700; }
.mw-parser-output h2 { font-size: 1.3em; font-weight: 800; }

/* Linienkennzeichnung über die volle Inhaltsbreite (Containerbreite):
   Unterschiede in Stärke/Strichart für schnelles Scannen beim Scrollen */
.mw-parser-output h2 { border-bottom: 3px solid var(--border-subtle,#a2a9b1); }
.mw-parser-output h3 { border-bottom: 2px solid var(--border-subtle,#a2a9b1); }
.mw-parser-output h4 { border-bottom: 2px dashed var(--border-subtle,#a2a9b1); }
.mw-parser-output h5 { border-bottom: 1px dashed var(--border-subtle,#a2a9b1); }
.mw-parser-output h6 { border-bottom: 1px dotted var(--border-subtle,#a2a9b1); }

/* Optionale Feinheiten für Link-Icons/§-Anker neben Überschriften */
.mw-parser-output .mw-headline {
  display: inline-block;       /* saubere Unterlinie mit Anchor-Icon */
  vertical-align: baseline;
}

/* Nicht den Seitentitel anfassen (liegt außerhalb .mw-parser-output als .firstHeading) */

Warum so?

• .mw-parser-output schließt nur den Artikel-Body ein. So bleiben Kopf/Sidebar/Spezialseiten-Chrome unverändert.
• Linien (border-bottom) funktionieren robust, auch wenn dein Gadget Überschriften ein-/ausblendet. Unterschiedliche Stricharten/Stärken erhöhen die Auffindbarkeit beim Scrollen deutlich.
• Kleine Größen-Steps (1.0 → 1.1 → 1.2 → 1.3 em) bewahren die Lesefluss-Ruhe, während die Linie die Haupt-Orientierung liefert.

(Optional) Feingranular per TemplateStyles

Für einzelne Seiten/Teilmengen (z. B. Experimente) kannst du zusätzlich eine stilgebende Vorlage nutzen:

1. Lege Vorlage:AufEinWort Überschriften/styles.css an:

   .aew-headings h6 { font-size: 1em; font-style: italic; border-bottom: 1px dotted #a2a9b1; }
   .aew-headings h5 { font-size: 1em; border-bottom: 1px dashed #a2a9b1; }
   .aew-headings h4 { font-size: 1.1em; border-bottom: 2px dashed #a2a9b1; }
   .aew-headings h3 { font-size: 1.2em; border-bottom: 2px solid  #a2a9b1; }
   .aew-headings h2 { font-size: 1.3em; border-bottom: 3px solid  #a2a9b1; }
   .aew-headings h2, .aew-headings h3, .aew-headings h4, .aew-headings h5, .aew-headings h6 {
     margin-top: 1.6em; margin-bottom: .6em; padding-bottom: .2em; line-height: 1.25; scroll-margin-top: 4rem;
   }
   

1. Auf einer Seite aktivieren:

   {{#templatestyles: Vorlage:AufEinWort Überschriften/styles.css}}
   <div class="aew-headings">
   == Beispiel H2 ==
   === Beispiel H3 ===
   ==== Beispiel H4 ====
   ===== Beispiel H5 =====
   ====== Beispiel H6 ======
   </div>
   

---

Einschätzung zu deiner Linie-Idee:

Faktisch gut. Beim schnellen Scrollen ist die horizontale Linie das stärkste, konstant wahrnehmbare Muster. Die Kombination aus leichter Größenprogression + deutlich unterschiedlicher Liniengestaltung bringt dir hohe Auffindbarkeit ohne visuelle Unruhe. Das passt auch zu deinem Toggle-Gadget: selbst bei eingeklappten Abschnitten signalisieren die Linien klar die Gliederung.

Wenn du magst, passe ich die Stricharten/Stärken noch genauer an deinen Geschmack an (z. B. H2 durchgezogen dunkel, H3 durchgezogen heller, H4/H5 gestrichelt, H6 punktiert).

Du:

Danke für Zustimmung und Entwurf.

Ich habe es getestet.

h1 Seitentitel verwendete ich bislang nicht, da dies wie Seitenname in der Seite zu groß war.

h1 muß wie h2 aber mit dickerem Unterstrich als h2 sein.

h3 Unterstrich  ist OK.

h4 und h5 kann man so voneinander nicht unterscheiden

Du hast die Überschriften bold gesetzt, daß sollen sie nicht mehr sein.

Kann ich die Werte nicht auch in Punktgröße oder dementsprechende werte angeben?

H1 22pt

H2 20pt

H3 18pt

H4 16pt

H5 14pt

H6 14pt kursiv

ChatGPT:

Nachgedacht

Es scheint, dass der Benutzer ein CSS-Update für die Seite anfordert. Der Titel der Seite soll wie eine H2-Überschrift mit einer dickeren Unterstreichung formatiert werden. Ich werde die Stilregeln für .firstHeading und .mw-first-headinganpassen, insbesondere im Vector-2022, und dabei eine Schriftgröße von 22pt und eine nicht-fettgedruckte Schrift mit einer 4px dicken Unterstreichung festlegen. Fertig

alles klar — ich passe das an deine Vorgaben an (keine Bold-Schrift, Punktgrößen, stärkere Differenz zwischen h4/h5) und ergänze h1 (Seitentitel) separat. Ja, du kannst Punktgrößen (pt) verwenden; beachte nur: pt ist druckorientiert und kann je nach Zoom/DPI etwas anders wirken als rem/em. Wenn dir Druckkonsistenz wichtig ist, sind pt okay; für rein Bildschirm wäre rem meist robuster. Du willst pt, also setze ich das so um.

In MediaWiki:Common.css

/* ===== Seitentitel (h1) außerhalb des Body-Inhalts anpassen =====
   Vector nutzt #firstHeading / .firstHeading für den Titel. */
#firstHeading,
.firstHeading {
  font-size: 22pt !important;      /* wie H1-Vorgabe */
  font-weight: 400 !important;      /* nicht fett */
  line-height: 1.2;
  margin-top: 0.8em;
  margin-bottom: 0.6em;
  padding-bottom: 0.25em;
  border-bottom: 4px solid var(--border-subtle, #a2a9b1); /* dicker als H2 */
}

/* ===== Überschriften im Artikel-Body nur innerhalb des Inhalts ===== */
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  font-weight: 400;               /* keine Bold-Schrift */
  line-height: 1.25;
  margin-top: 1.6em;
  margin-bottom: 0.6em;
  padding-bottom: 0.2em;          /* Platz für Unterstrich */
  scroll-margin-top: 4rem;        /* Anker-Sprünge unter Sticky-Header */
}

/* Punktgrößen nach Wunsch */
.mw-parser-output h2 { font-size: 20pt; }
.mw-parser-output h3 { font-size: 18pt; }
.mw-parser-output h4 { font-size: 16pt; }
.mw-parser-output h5 { font-size: 14pt; font-style: normal; }
.mw-parser-output h6 { font-size: 14pt; font-style: italic; }

/* Unterstreichungen über die volle Inhaltsbreite, mit klarer Unterscheidung */
.mw-parser-output h2 { border-bottom: 3px solid   var(--border-subtle, #a2a9b1); }
.mw-parser-output h3 { border-bottom: 2px solid   var(--border-subtle, #a2a9b1); }
.mw-parser-output h4 { border-bottom: 2px dashed  var(--border-subtle, #a2a9b1); } /* gut von h5 zu trennen */
.mw-parser-output h5 { border-bottom: 1.5px dotted var(--border-subtle, #a2a9b1); } /* feiner, andere Struktur */
.mw-parser-output h6 { border-bottom: 1px dotted   var(--border-subtle, #a2a9b1); }

/* Optional: leichte Farbnuance für tiefe Ebenen (nur wenn gewünscht)
   .mw-parser-output h5, .mw-parser-output h6 { border-bottom-color: #c0c6cf; } */

Kurz zur Linie-Logik:

• H2/H3 = durchgezogen (stark/normal) → „Hauptachsen“ der Gliederung.
• H4 = gestrichelt (2 px) → sichtbar abgesetzt von H5.
• H5/H6 = gepunktet (1.5 px / 1 px) → feinere Ebenen, klar unterscheidbar.

Wenn du stattdessen eine noch stärkere Differenz zwischen H4/H5 willst, kann ich H4 z. B. double (Doppellinie) setzen und H5 dashed, oder H4 dashed + dunklere Farbe, H5 dotted + heller. Sag kurz, welche Variante dir optisch am meisten zusagt.

Du:

Im neuen Coding hast du unbekannte css property verwendet. Muß ich da noch etwas installieren?

Mein MediaWiki kennt kein "scroll-margin-top" oder "var(--border-subtle…"

Also beim Sichern der css wird dies von MediaWiki "angemeckert". Ich kann sichern.

ChatGPT:

Nachgedacht

Die unbekannten CSS-Eigenschaften verursachen Warnungen, obwohl sie zulässig sind. Es wird empfohlen, auf CSS-Variablen zu verzichten und statische Farben wie #a2a9b1 zu verwenden. Als Alternative zu scroll-margin-top kannst du padding-top und margin-top mit negativen Werten verwenden. Kompatibilität sicherstellen, indem du auf vendor-prefixes verzichtest und statisches CSS ohne Variablen oder unbekannte Eigenschaften bereitstellst. Anstatt scroll-padding-top zu verwenden, können wir ein pseudo-element mit :before für Anker-Offsets einfügen. Damit wird ein negativer Abstand zu Überschriften mit :target erstellt. Für die Unterscheidung von h4 und h5 könnte h4 mit einer doppelten Linie und h5 mit einer gestrichelten Linie dargestellt werden. Fertig

Gute Beobachtung — nein, du musst nichts nachinstallieren.

• Warum die Meldung? Der MediaWiki-CSS-Prüfer ist konservativ. Moderne Properties wie scroll-margin-topoder CSS-Variablen var(...) sind zwar in aktuellen Browsern okay, werden aber im Wiki-Editor oft als „unbekannt“ markiert.
• Lösung: Ich gebe dir eine kompatible Fassung ohne var(...) und ohne scroll-margin-top, inkl. klassischem Anker-Offset per :target::before. Damit verschwinden die Beanstandungen und das Verhalten bleibt wie gewünscht.

Kompatible Fassung für MediaWiki:Common.css (ohne „unbekannte“ Properties)

/* ===== Seitentitel (h1) außerhalb des Artikel-Body ===== */
#firstHeading,
.firstHeading {
  font-size: 22pt !important;   /* H1 */
  font-weight: 400 !important;   /* nicht fett */
  line-height: 1.2;
  margin-top: 0.8em;
  margin-bottom: 0.6em;
  padding-bottom: 0.25em;
  border-bottom: 4px solid #a2a9b1; /* dicker als H2 */
}

/* ===== Überschriften im Artikel-Body (nur Inhalt) ===== */
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  font-weight: 400;            /* keine Bold-Schrift */
  line-height: 1.25;
  margin-top: 1.6em;
  margin-bottom: 0.6em;
  padding-bottom: 0.2em;       /* Platz für Unterstrich */
}

/* Punktgrößen nach Vorgabe */
.mw-parser-output h2 { font-size: 20pt; }
.mw-parser-output h3 { font-size: 18pt; }
.mw-parser-output h4 { font-size: 16pt; }
.mw-parser-output h5 { font-size: 14pt; font-style: normal; }
.mw-parser-output h6 { font-size: 14pt; font-style: italic; }

/* Unterstriche über die volle Inhaltsbreite, klar unterscheidbar */
.mw-parser-output h2 { border-bottom: 3px solid  #a2a9b1; }  /* Hauptachse */
.mw-parser-output h3 { border-bottom: 2px solid  #a2a9b1; }
.mw-parser-output h4 { border-bottom: 2px double #a2a9b1; }  /* gut von H5 zu trennen */
.mw-parser-output h5 { border-bottom: 2px dashed #a2a9b1; }
.mw-parser-output h6 { border-bottom: 1px dotted #a2a9b1; }

/* ===== Anker-Scroll-Offset ohne scroll-margin-top =====
   Beim Sprung zu #Überschrift bleibt unter einem Sticky-Header genug Luft.
   (Klassischer Trick mit :target::before) */
.mw-parser-output h2:target::before,
.mw-parser-output h3:target::before,
.mw-parser-output h4:target::before,
.mw-parser-output h5:target::before,
.mw-parser-output h6:target::before {
  content: "";
  display: block;
  height: 64px;          /* Offset-Höhe an deinen Header anpassen */
  margin-top: -64px;
}

Hinweise / Optionen:

• H4/H5-Unterscheidung: Ich habe H4 auf double und H5 auf dashed gesetzt. Das ist beim Scrollen deutlich unterscheidbar. Wenn dir „double“ zu kräftig ist, kann H4 alternativ solid bleiben und H5 dashed + hellerer Ton(z. B. #c0c6cf) bekommen.
• Punktgrößen vs. Bildschirm-Skalierung: pt ist druckorientiert. Wenn du einmal später auf „Bildschirmrobustheit“ umstellen willst, entspräche ca.:
  • 22 pt ≈ 1.83 rem, 20 pt ≈ 1.67 rem, 18 pt ≈ 1.5 rem, 16 pt ≈ 1.33 rem, 14 pt ≈ 1.17 rem (bei Standard-Root ≈ 16 px).

Möchtest du zusätzlich eine kleine Farbnuance für H5/H6 (z. B. #c0c6cf), damit die Linienhierarchie noch schneller „scanbar“ wird? Ich liefere dir sofort eine Variante.

Du:

Danke. Der test ergibt daß sich h2 auch auf den Seitennamen entsprechend auswirkt und h1 von der css nicht erfaßt wird.

Seitenname:

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Testseite 2</span></h1>
<span class="mw-page-title-main">Testseite 2</span>

h1:

<span class="mw-headline" id="H1_Überschrift">H1 Überschrift</span>
<span id="H1_.C3.9Cberschrift"></span>

h2:

h2:
<span class="mw-headline" id="H2_Überschrift">H2 Überschrift</span>
<h2 class="collapsible-header"><span id="H2_.C3.9Cberschrift"></span><span class="mw-headline" id="H2_Überschrift">H2 Überschrift</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/mediawiki/index.php?title=Testseite_2&amp;veaction=edit&amp;section=2" title="Abschnitt bearbeiten: H2 Überschrift" class="mw-editsection-visualeditor"><span>Bearbeiten</span></a><span class="mw-editsection-divider"> | </span><a href="/Testseite_2" class="hidesection-link internal" data-show="einblenden" data-hide="ausblenden" data-section="2" title="Expand or collapse this section"><span>ausblenden</span></a><span class="mw-editsection-divider"> | </span><a href="/mediawiki/index.php?title=Testseite_2&amp;action=edit&amp;section=2" title="Quellcode des Abschnitts bearbeiten: H2 Überschrift"><span>Visual bearbeiten</span></a><span class="mw-editsection-bracket">]</span></span></h2>
<<pseudo>></<pseudo>>
<span id="H2_.C3.9Cberschrift"></span>

h1- h2 und Seitennamen müssen offenbar anders angesprochen werden

Seitenname entspricht h2 wie im body - ist nun auch fett unterstrichen.

Im Body kann man mit VisualEditor den Seitentitel im body als h1 setzen.

An sich würde man erwarten, das der Seitenname h1 und nicht h2 entspricht.

Wenn du ein neues Coding machst, dann setze h1 auf kursiv.

Vorab jedoch: Ich habe keine Erinnerung daran für Heading css hinterlegt zu haben.

Wenn es ein Stylesheet oder Script geben könnte, daß da hineingreift, wie könnte man es aufspüren?

Ist es vielleicht eine spezielle Sache des Vector-Skin? siehe: https://en.wikipedia.org/wiki/MediaWiki:Vector.css

ChatGPT:

Nachgedacht

Es scheint, dass der Benutzer mit CSS-Selektoren für Überschriften und den Titel (#firstHeading) ein Problem hat. Sie beobachteten, dass Styling für h2 auf den Seitentitel angewendet wurde, was nicht passieren sollte. Möglicherweise beeinflusst <.vector-body> globale Einstellungen für h2, die auch .mw-parser-output betreffen und das Design der Seite verändern. Nutzer bemerken, dass der Seitentitel jetzt fett und unterstrichen ist, obwohl im CSS für #firstHeading keine fetten Einstellungen vorhanden sind. Möglicherweise wird eine andere CSS-Regel angewendet oder ein zusätzlicher Code von VisualEditor beeinflusst das. Auch kann es sein, dass ein Gadget den h1-Tag verändert und als collapsible Header neu verpackt. Die Verwendung von <h2 class="collapsible-header"> zeigt, dass das Gadget spezielle Markups mit zusätzlichen Spans hinzufügt. Es könnte sein, dass der VisualEditor (VE) h1 in einen anderen Tag umwandelt oder deaktiviert. In MediaWiki ist h1 für den Seitentitel reserviert, daher wird h1 in den Inhalten oft in h2 umgewandelt. In MediaWiki sind h2-Tags für Abschnitte reserviert, während h1 für den Seitentitel genutzt wird. Bei der Verwendung von "=" wird der Parser häufig h1 erzeugen, was jedoch nicht empfohlen wird. Es scheint, dass das Gadget den h1-Tag möglicherweise entfernt und durch Spans ersetzt, insbesondere in collapsible-header-Elementen. In MediaWiki, h1 is reserved for the page title, and content headings should start at h2. The user wants h1 to be italic, which can be done by styling #firstHeading. To address their concern, we examine potential conflicts from CSS override rules or gadgets affecting the styling, particularly with collapsible headers or global styles overlapping. We recommend diagnostic tools to identify these issues and propose CSS resets to avoid conflicts. Fertig

Danke fürs genaue DOM-Snippet — das hilft.

Kurz vorweg, damit nichts „magisch“ wirkt:

• In MediaWiki ist der Seitentitel die einzige echte h1 (#firstHeading). Inhalts-Überschriften beginnen bei h2 (== … ==). Ein „H1“ im Body ist i. d. R. gar keins; der Parser rendert dort keine echte <h1>. Dein Snippet bestätigt das (nur <span class="mw-headline">…</span> statt <h1>).
• Wenn dein Seitentitel plötzlich wie h2 aussieht, kommt das nicht von Regeln, die auf .mw-parser-output h2zielen. Ursache ist fast immer: (a) eine andere Regel mit zu breiter Selektor-Spanne, (b) ein Gadget/Script (z. B. dein Collapsible-Gadget) mit eigener Heading-CSS, (c) skin-spezifische Styles (Vector).

A) Aufspüren von Störquellen (2 Minuten Check)

1. Gadgets ausschalten: Seite mit ?safemode=1 laden. – Wenn der Effekt weg ist, sitzt er in einem Gadget.
2. Nur Vector laden: Wechsel testweise mit ?useskin=vector bzw. …=vector-2022. – Wenn es in einem Skin anders ist, liegt eine Skin-CSS vor (z. B. MediaWiki:Vector.css oder MediaWiki:Vector-2022.css).
3. Alle MediaWiki-CSS/JS prüfen:
   • MediaWiki:Common.css, MediaWiki:Vector.css, MediaWiki:Vector-2022.css
   • MediaWiki:Common.js, MediaWiki:Vector.js
   • Gadgets: MediaWiki:Gadgets-definition → dort referenzierte CSS/JS öffnen.
   • Benutzer-CSS: Benutzer:<deinName>/common.css, …/vector.css.
4. DevTools → Computed Styles auf #firstHeading: – Welche Regel macht es fett/unterstrichen? (Da siehst du die Gewinner-Selektoren.)

---

B) Saubere Trennung & dein gewünschtes Design

Nutze hohe Spezifität und trenne Seitentitel strikt von Body-Headings. Zudem neutralisieren wir evtl. Gadget-Klassen wie .collapsible-header.

Packe das in MediaWiki:Vector.css (nur Vector) oder MediaWiki:Common.css (global).

/* ===== Seitentitel (echtes H1) – NUR #firstHeading ===== */
#firstHeading,
#firstHeading .mw-page-title-main {
  font-size: 22pt !important;   /* deine H1-Größe */
  font-style: italic !important;/* H1 kursiv, wie gewünscht */
  font-weight: 400 !important;  /* nicht fett */
  line-height: 1.2;
  text-decoration: none !important;
  margin-top: 0.8em;
  margin-bottom: 0.6em;
  padding-bottom: 0.25em;
  border-bottom: 4px solid #a2a9b1 !important; /* dicker als H2 */
}

/* Sicherstellen, dass KEINE allgemeine Heading-Regel auf den Titel greift */
.mw-body h1, .mw-body-content h1 { 
  font-weight: 400 !important;
  text-decoration: none !important;
}

/* ===== Inhaltsbereich: NUR Überschriften im Body ===== */
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  font-weight: 400;           /* nicht fett */
  line-height: 1.25;
  margin-top: 1.6em;
  margin-bottom: 0.6em;
  padding-bottom: 0.2em;      /* Platz für Unterstrich */
}

/* Punktgrößen nach Wunsch */
.mw-parser-output h2 { font-size: 20pt; }
.mw-parser-output h3 { font-size: 18pt; }
.mw-parser-output h4 { font-size: 16pt; }
.mw-parser-output h5 { font-size: 14pt; font-style: normal; }
.mw-parser-output h6 { font-size: 14pt; font-style: italic; }

/* Unterstriche (klar unterscheidbar) */
.mw-parser-output h2 { border-bottom: 3px solid  #a2a9b1; }
.mw-parser-output h3 { border-bottom: 2px solid  #a2a9b1; }
.mw-parser-output h4 { border-bottom: 2px double #a2a9b1; } /* klar anders als H5 */
.mw-parser-output h5 { border-bottom: 2px dashed #a2a9b1; }
.mw-parser-output h6 { border-bottom: 1px dotted #a2a9b1; }

/* Dein Collapsible-Gadget nimmt oft Klassen an den H-Elementen an:
   Hier neutralisieren wir evtl. mitgebrachte Bold/Underline o. ä. */
.mw-parser-output h2.collapsible-header,
.mw-parser-output h3.collapsible-header,
.mw-parser-output h4.collapsible-header,
.mw-parser-output h5.collapsible-header,
.mw-parser-output h6.collapsible-header {
  font-weight: 400 !important;
  text-decoration: none !important;
}

Warum das wirkt:

• #firstHeading wird mit !important fixiert → kein Skin/Gadget zieht drüber.
• Body-Headings sind strikt auf .mw-parser-output begrenzt → greifen nicht auf den Seitentitel.
• .collapsible-header wird entwaffnet, falls dein Gadget dort Styles injiziert.

Nach dem Speichern: einmal ?action=purge an der Seite + Hard-Reload (Strg/Cmd-Shift-R).

C) Zu deiner Beobachtung „H1 im Body“

Das Verhalten ist konsistent: Im Artikel-Body gibt es keine echte H1-Sektion; MediaWiki reserviert h1 für den Titel. VisualEditor kann „Heading 1“ anzeigen, rendert im Body aber keinen <h1>. Deshalb sahst du nur span.mw-headline. Fazit: Setze Inhalte ab h2; die Seite selbst ist h1.

Wenn du mir in den DevTools einen Screenshot der Computed Styles

von #firstHeading schickst (oberste 2–3 Regeln reichen), kann ich die eine(n) übergriffige(n) Selektor(en) punktgenau nennen – oft ist es eine alte Regel à la .mw-body h1, .mw-body h2 { … } in einem Gadget-/Skin-Stylesheet.

Du:

Danke.

Aha, mit neuer csss wird der Seitenname nun kursiv, h2 ist davon getrennt, aber h1 im body ist immer noch original Vector-Skin unberührt von der neuen css.

Verblieben von deinem Entwurf der CSS ist folgende, da dies Vector-Skin bereits gut handhhabt und es keine collapsible Eingriffe in die headings gibt:

/* ===== Seitentitel (echtes H1) – NUR #firstHeading ===== */
#firstHeading,
#firstHeading .mw-page-title-main {
  font-style: normal !important;
  font-size: 24pt !important;
}

.mw-body h1 {
  font-size: 22pt !important;
  font-style: italic !important;
  border-bottom: 3px solid  #a2a9b1;
}

/* ===== Inhaltsbereich: NUR Überschriften im Body ===== */
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  font-weight: 400;           /* nicht fett */
}

/* Punktgrößen nach Wunsch */
.mw-parser-output h2 { font-size: 20pt; }
.mw-parser-output h3 { font-size: 18pt; }
.mw-parser-output h4 { font-size: 16pt; }
.mw-parser-output h5 { font-size: 14pt; }
.mw-parser-output h6 { font-size: 14pt; font-style: italic; }

/* Unterstriche (klar unterscheidbar) */
.mw-parser-output h2 { border-bottom: 3px dotted  #a2a9b1; }
.mw-parser-output h3 { border-bottom: 2px dashed  #a2a9b1; }
.mw-parser-output h4 { border-bottom: 2px dotted #a2a9b1; } /* klar anders als H5 */
.mw-parser-output h5 { border-bottom: 1px dashed #a2a9b1; }
.mw-parser-output h6 { border-bottom: 1px dotted #a2a9b1; }

h1 im body steht als Element auf "mw-headline":

<span class="mw-headline" id="H1_Überschrift">H1 Überschrift</span>

Im Body ist es jedoch mw-body h1.

Ich habe mir nun folgende css aus deinem Entwurf gestaltet:

/* ===== Seitentitel (echtes H1) – NUR #firstHeading ===== */
#firstHeading,
#firstHeading .mw-page-title-main {
  font-style: normal !important;
  font-size: 24pt !important;
}

.mw-body h1 {
  font-size: 22pt !important;
  font-style: italic !important;
  border-bottom: 3px solid  #a2a9b1;
}

/* ===== Inhaltsbereich: NUR Überschriften im Body ===== */
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  font-weight: 400;           /* nicht fett */
}

/* Punktgrößen nach Wunsch */
.mw-parser-output h2 { font-size: 20pt; }
.mw-parser-output h3 { font-size: 18pt; }
.mw-parser-output h4 { font-size: 16pt; }
.mw-parser-output h5 { font-size: 14pt; }
.mw-parser-output h6 { font-size: 14pt; font-style: italic; }

/* Unterstriche (klar unterscheidbar) */
.mw-parser-output h2 { border-bottom: 3px dotted  #a2a9b1; }
.mw-parser-output h3 { border-bottom: 2px dashed  #a2a9b1; }
.mw-parser-output h4 { border-bottom: 2px dotted #a2a9b1; } /* klar anders als H5 */
.mw-parser-output h5 { border-bottom: 1px dashed #a2a9b1; }
.mw-parser-output h6 { border-bottom: 1px dotted #a2a9b1; }

Ich habe alles aus deinem Entwurf weggelöscht, was von Vector-Skin offenbar bereits so vorgeschrieben ist.

Meine Regel ".mw-body h1" greift, die Überschrift kann ich damit nach belieben gestalten – durch Test bestätigt.

Was kann/sollte ich noch verbessern ohne es aufzublähen?

ChatGPT:

Nachgedacht

Der Benutzer möchte CSS-Regeln optimieren. Zuerst sollten wir sicherstellen, dass die Selektoren spezifisch genug sind, um unbeabsichtigte Nebenwirkungen zu verhindern, besonders bei der VisualEditor-generierten Überschrift und dem ParserOutput. Der ‘mw-headline’-Span inside beschränkt die Gestaltung von h1, ohne den gesamten Stil für die Body-H1 zu beeinträchtigen. Es scheint eine kleine Verwirrung zu geben: Der Benutzer behauptet, dass es im Body "mw-body h1" gibt, obwohl VisualEditor standardmäßig h2-h6 verwendet. Eventuell wurde HTML direkt eingegeben oder durch ein Gadget geändert. Für CSS-Empfehlung: Versuch, :where() zu verwenden, um die Spezifität zu reduzieren — achte jedoch auf mögliche Validator-Warnungen. Es ist wichtig, die Selektoren einfach zu halten, um die Validierung zu bestehen. Um zu verhindern, dass Regeln den Titel beeinflussen, sollte man .mw-body h1 einschränken, um #firstHeading auszuschließen. Empfehlenswert ist, :not(#firstHeading) oder eher .mw-parser-output h1 zu verwenden, falls der <h1> in der Wikitext-HTML-Mode innerhalb von .mw-parser-output geschrieben wurde. Um den Titel zu vermeiden, sollte man .mw-parser-output h1 { ... } statt .mw-body h1 { ... } verwenden. Diese Regel funktioniert gut mit MW 1.43, da .mw-parser-output jetzt immer vorhanden ist. Die Verwendung von Borders für Überschriften ohne die Toggle-Region zu beeinflussen ist sinnvoll. Es könnte auch helfen, Kontrast und Zugänglichkeit zu optimieren. In Bezug auf Druckstile könnte man die Schriftgrößen oder Linien anpassen. Um die Angabe zu optimieren: Statt .mw-body h1, .mw-parser-output h1 verwenden, um den Seitentitel zu vermeiden. Ich empfehle, kleinen Abstand (padding-bottom: 0.15em) für bessere Trennung der Zeilen und einige Anpassungen für den Druckmodus, wie das Umwandeln von Strichen in durchgehende Linien. Keine unnötigen Variablen oder komplexen Vorschläge, um Bloat zu vermeiden. Fertig

super – dein Minimal-Setup ist schon ordentlich. Zwei kleine, aber sinnvolle Feinschliffe ohne „Aufblähung“:

1. Body-H1 sauber kapseln (Titel nie berühren) Statt .mw-body h1 nimm .mw-parser-output h1. Das trifft nur echte Inhalts-H1 (falls du sie bewusst im Wikitext/HTML setzt) – nie den Seitentitel #firstHeading, auch wenn Vector intern vieles in .mw-body rendert.

   /* Body-H1 (falls im Inhalt verwendet), nie der Seitentitel */
   .mw-parser-output h1 {
     font-size: 22pt;
     font-style: italic;
     font-weight: 400;
     border-bottom: 3px solid #a2a9b1;
     padding-bottom: .2em; /* Linie bekommt „Luft“ */
   }
   

Deine bestehende Titelregel bleibt:

#firstHeading,
#firstHeading .mw-page-title-main {
  font-style: normal !important;
  font-size: 24pt !important;
}

1. Linien wirken ruhiger mit minimalem Innenabstand Gönn allen Body-Headings eine winzige Unterkante, sonst „klebt“ die Linie am Text:

   .mw-parser-output h2,
   .mw-parser-output h3,
   .mw-parser-output h4,
   .mw-parser-output h5,
   .mw-parser-output h6 { padding-bottom: .2em; }
   

Alles andere an deinem Stand ist schlank und klar. Deine Muster (H2 20 pt/3px dotted, H3 18 pt/2px dashed, H4 16 pt/2px dotted, H5 14 pt/1px dashed, H6 14 pt/1px dotted + kursiv) geben beim Scrollen die gewünschte Linien-Signatur.

Optional – wenn du’s ohne Mehrkosten fürs Auge noch robuster willst:

• H4/H5-Kontrast minimal erhöhen: h4 { border-bottom: 2px double #a2a9b1; } (du hattest das bereits – wirkt sehr gut), h5 { 1px dashed; }.
• Druckansicht beruhigen (tint-freundlich), rein kosmetisch:

  @media print {
    .mw-parser-output h2,
    .mw-parser-output h3,
    .mw-parser-output h4,
    .mw-parser-output h5,
    .mw-parser-output h6 { border-bottom-style: solid; }
  }
  

Falls später doch mal „irgendwo“ wieder der Titel fett/unterstrichen wird: kurzer Check mit ?safemode=1 und DevTools → Computed auf #firstHeading. Dann gezielt den einen Übeltäter neutralisieren.

Sonst: so lassen – „never touch a running system.“

Du:

Wenn das so ist dann ist folgendes richtiger und es funktioniert getestet:

/* ===== Seitentitel (echtes H1) – NUR #firstHeading ===== */
#firstHeading,
#firstHeading .mw-page-title-main {
  font-style: normal !important;
  font-size: 24pt !important;
}

/* ===== Inhaltsbereich: NUR Überschriften im Body ===== */
.mw-parser-output h1,
.mw-parser-output h2,
.mw-parser-output h3,
.mw-parser-output h4,
.mw-parser-output h5,
.mw-parser-output h6 {
  font-weight: 400;
}

/* Punktgrößen nach Wunsch */
.mw-parser-output h1 { font-size: 20pt; font-style: italic; }
.mw-parser-output h2 { font-size: 20pt; }
.mw-parser-output h3 { font-size: 18pt; }
.mw-parser-output h4 { font-size: 16pt; }
.mw-parser-output h5 { font-size: 14pt; }
.mw-parser-output h6 { font-size: 14pt; font-style: italic; }

/* Unterstriche (klar unterscheidbar) */
.mw-parser-output h1 { border-bottom: 3px solid  #a2a9b1; }
.mw-parser-output h2 { border-bottom: 3px dotted  #a2a9b1; }
.mw-parser-output h3 { border-bottom: 2px dashed  #a2a9b1; }
.mw-parser-output h4 { border-bottom: 2px dotted #a2a9b1; }
.mw-parser-output h5 { border-bottom: 1px dashed #a2a9b1; }
.mw-parser-output h6 { border-bottom: 1px dotted #a2a9b1; }

Kein padding nötig, da alles bestens.

Deinerseits hattest du lediglich von Anbeginn  nur h1 im parser ausgelassen, wegen der Verwirrung durch first-heading zu h1.

ChatGPT:

Nachgedacht

Die Benutzeranfrage scheint abgeschlossen zu sein, da sie bestätigen, dass alles funktioniert – sie haben das Problem mit dem h1 behoben. Es gibt keine direkte Frage, aber sie erwarten wahrscheinlich eine Bestätigung und vielleicht kleine Vorschläge. Ich sollte ihnen kurz bestätigen, dass alles in Ordnung ist, ohne unnötige Ergänzungen zu machen. Die Benutzeranfrage scheint so gut wie abgeschlossen, doch ich kann einige kleine, feinsäuberliche Tipps geben: Zum Beispiel könnte man die Spezifität mit .mw-parser-output und Überschriften innerhalb von Tabellen oder Infoboxen überprüfen. Auch, ob dies nicht versehentlich auf andere Bereiche angewendet wird. Ein paar zusätzliche, kleine Anpassungen wie das Hinzufügen von festen Linien für den Druck oder die Prüfung der Vector-2022 Option können hilfreich sein. Die Benutzer verwenden Striche für Überschriften, was gut ist, aber ich könnte darauf hinweisen, dass sie sicherstellen sollten, dass diese nicht exklusiv für die Levelangabe verwendet werden, um Barrierefreiheit zu wahren. Vielleicht könnte der Farbcode #a2a9b1 zu hell wirken; eine Option wäre die Nutzung von currentColor mit Transparenz. Es gibt eine Randbedingung: Wenn Überschriften in Tabellen oder Navigationsboxen erscheinen, könnte die Linie nicht die volle Breite erreichen. Falls das gewünscht ist, kann das in Ordnung sein. Auch, wenn eine minimale Regel für den Titel in Druckansicht gewünscht wird, könnte man sie mit einem Reset versehen. Das Styling für h1 kann beibehalten werden, da die Änderung unproblematisch ist. Fertig

klingt gut – sauber getrennt, schlank und getestet ✅

Dein letzter Stand ist fachlich stimmig: #firstHeading separat, Body-Headings strikt über .mw-parser-output h1–h6. So vermeidest du genau den Vector-„Übergriff“.

Wenn du noch winzige Verbesserungen willst (ohne Aufblähung):

1. Robust in der Druckansicht Gestrichelt/gepunktet wird im Druck oft blass. Du kannst dort leise auf „solid“ schalten:

   @media print {
     .mw-parser-output h1,
     .mw-parser-output h2,
     .mw-parser-output h3,
     .mw-parser-output h4,
     .mw-parser-output h5,
     .mw-parser-output h6 { border-bottom-style: solid; }
   }
   

1. Optionale Dark-Mode-Nuance (nur, wenn du magst) In sehr dunklen Skins wirkt #a2a9b1 manchmal zu hell/dunkel. Minimale Anpassung:

   @media (prefers-color-scheme: dark) {
     .mw-parser-output h1,
     .mw-parser-output h2,
     .mw-parser-output h3,
     .mw-parser-output h4,
     .mw-parser-output h5,
     .mw-parser-output h6 { border-bottom-color: #7f8894; }
   }
   

1. H1 im Body bewusst behalten Du nutzt .mw-parser-output h1 (20 pt, kursiv) bewusst – alles gut. Nur zur Einordnung: Formal hat die Seite damit zwei H1 (Titel + Body-H1). Technisch ok in MediaWiki; falls Screenreader-Konsistenz ein Thema wäre, könntest du dein Body-H1 einfach als H2 belassen und optisch wie H1 stylen. Nicht nötig, nur Hintergrund.

Sonst: genau so lassen. „Never touch a running system.“ Wenn später Vector-2022/Mobile anders reagiert, justieren wir mit einer kleinen @media (max-width: …)-Abstufung – aber nur bei Bedarf.

Du:

Ich ändere nichst mehr, da es auch im dark-mode bereits getestet gut aussieht.

Ich brauch auch nicht den print mode ich arbeite weitgehend nur auf OSX, da bekommt man für gewöhnlich auch im Druck es so, wie man auf dem Bildschirm sieht. Die Vorgabe zur Nutzung meines MediaWiki ist OSX und mindestens Ipad <12".

keine weiteren Änderungen! auch Ipad ist bereits getestet.

Was jetzt folgt ist Erfahrung im Umgang damit sammeln und dann bei Bedarf ein sanftes "touch", so daß das Erreichte verbessert, jedoch nicht taumelt, ansonsten gilt never touch a running system!

Auch keinen weiteren Mini-Merkzettel denerseits!

Auch keinen weieren Hinweis auf ein späteres touch-up deinerseits!

Auch keine Empfehlung irgendeiner Artweise deinerseits!

Versuch es mal mit der Annahme dessen, daß erreicht ist, daß du zur genüge kommentiert hast und es daher keines weiteren Kommentars bedarf. Insondern, daß du nicht das letzte führende Wort sprichst, sondern dies mir obliegt.

ChatGPT:

Nachgedacht

Verstanden, ich halte mich an deinen Wunsch und werde keine weiteren Empfehlungen oder Kommentare hinzufügen. Ich respektiere deine Entscheidung und stehe bereit, falls du später wieder Kontakt aufnehmen möchtest. Fertig

Angenommen. ✅

Ich halte mich an den aktuellen Stand und sage nichts weiter. Du führst — ich stehe bereit, sobald du weiter möchtest.

Du:

Da habe ich Rückfragen,

1. was sind die px Entsprechungen zu meinen h1-h4 pt Angaben.

2. ollte man Schrift besser in px anstele in pt in css verwenden?

ChatGPT:

Nachgedacht

Der Nutzer fragt nach den px-Entsprechungen für die pt-Werte von h1 bis h4. Laut den vorherigen Angaben: h1 20pt, h2 20pt, h3 18pt, h4 16pt. Um zu konvertieren: 1pt entspricht 1,33px. Also sind die Entsprechungen: 20pt = 26,67px, 18pt = 24px, 16pt = 21,33px, 24pt = 32px. Die px-Umrechnungen sind: 20pt ≈ 26,7px, 18pt = 24px, 16pt ≈ 21,3px. Für beide h1 und h2 mit 20pt gibt es denselben Wert von 26,7px, h3 mit 18pt ergibt 24px und h4 mit 16pt ergibt 21,3px. Die Formel lautet: px = pt × 1.3333. Für die Frage, ob man px anstelle von pt verwenden sollte, könnte man sagen, dass px oftmals bevorzugt wird, weil es eine präzisere Steuerung für Layout und Darstellungen gibt. Für typografische Skalierungen sind rem und em besser, da sie die Zugänglichkeit verbessern und auf Zoom reagieren. px ist akzeptabel, wenn genaue Ausrichtung erforderlich ist (z. B. bei Symbolen). pt wird hauptsächlich für Druckdesigns verwendet. Nutze rem für Schriftgrößen, px für exakte Pixel und pt für Druck. Nutze px (oder rem) für Bildschirmdarstellungen, da px der Standard dafür ist. pt wird üblicherweise für Drucklayouts verwendet und könnte in deinem macOS/iPad-Setup weniger vorteilhaft sein. Die Umrechnung 20pt = 26,67px ergibt sich aus der Berechnung 20*96/72. Fertig

Kurz & präzise:

1) Deine pt → px (Bildschirm) für h1–h4

Grundlage: 1 pt = 96/72 px = 1⅓ px.

• h1 = 20 pt → 26.666… px (≈ 26.67 px)
• h2 = 20 pt → 26.666… px (≈ 26.67 px)
• h3 = 18 pt → 24 px
• h4 = 16 pt → 21.333… px (≈ 21.33 px)

2) px statt pt?

• pt: druckorientierte Einheit; auf dem Screen wird sie zwar standardisiert (1 pt = 1.333… px), führt aber oft zu nicht-ganzzahligen Pixeln (Subpixel-Rundung).
• px: Bildschirm-Standard; verhält sich auf macOS/iPad stabil und ist für UI/Screen-Typografie üblich.
• (Nur der Vollständigkeit halber: rem/em sind für Barrierefreiheit/Skalierung noch flexibler; war nicht deine Frage.)

Fazit: Für reine Bildschirmdarstellung ist px üblicher/praktischer; pt primär für Druck.

Du:

Das Verhältnis der neuen pt Überschriften zum Text in SMW ist nicht wirklich gut.  Wenn ich daran denke in Zukunft direkt aus Webseiten auszudrucken, wäre für Bildschirm zu Papier bei pt zu bleiben richtiger – oder?

Wikipedia hat für Text 14px, ich ohne es bewußt irgendwie eingestellt zu haben habe 16px bei Text im Body. Für Ausdruck sind meine h1-h6 sn sich passend, also müßte ich Text in Body anpassen – was meinst du?. Was ist die css dazu?

ChatGPT:

Nachgedacht

Um die Körpertextgröße anzupassen, könnten wir die Schriftgröße in der CSS erhöhen oder verringern, um das Verhältnis zu den Überschriften (pt) anzupassen. Angenommen, Sie möchten die Schriften anpassen: „body {font-size: 16px;}“ könnte auf „body {font-size: 1rem;}“ gesetzt werden, was flexibler wäre, um mit verschiedenen Bildschirmgrößen zu arbeiten. Wenn Überschriften in pt vorliegen (z. B. 24pt für H1), könnte der Körpertext in pt auf 12pt angepasst werden, um mit den Überschriften gut zu harmonieren, da 12pt etwa 16px entspricht. Ihr aktueller Wert von 16px entspricht bereits 12pt, was gut passend wirkt. Die Unterschiede zwischen den Überschriften sind dann minimal. Für den Druck ist 12pt Standard, aber auf dem Bildschirm ist 16px (ca. 12pt) gut lesbar. Ich würde empfehlen, 16px als Körpertextgröße zu behalten und die Überschriften leicht anzupassen. In CSS könnte man es so setzen: .mw-parser-output { font-size: 16px; } und für den Druck: @media print { body { font-size: 12pt; }}. Option A: Behalten Sie 16px für den Körpertext: .mw-parser-output { font-size: 16px; }. Option B: Verwenden Sie 15px, um das Verhältnis zu WP’s 14px zu simulieren: .mw-parser-output { font-size: 15px; }. Für den Druck: @media print { .mw-parser-output { font-size: 12pt; } }. Zusätzlich könnten wir für bessere Konsistenz font-size: 1rem; verwenden. Fertig

Kurz & präzise.

Antwort

• Bildschirm vs. Druck: Behalte Überschriften in pt (gut für Druck), stell Fließtext im Screen in px ein und mappe ihn beim Druck auf pt. So passt das Verhältnis sowohl am Bildschirm als auch auf Papier.
• Relationen (Merkzahl): 16 px ≈ 12 pt, 15 px ≈ 11.25 pt, 14 px ≈ 10.5 pt.

CSS (global, nur Inhaltsbereich)

In MediaWiki:Common.css (oder Vector-spezifisch in MediaWiki:Vector.css), nicht auf body, sondern nur auf .mw-parser-output.

Variante A – Deine aktuelle Lesbarkeit behalten (16 px) + sauberer Druck

/* Bildschirm: Fließtext-Basis */
.mw-parser-output { font-size: 16px; line-height: 1.6; }

/* Druck: gleiche optische Relation zu deinen pt-Überschriften */
@media print {
  .mw-parser-output { font-size: 12pt; line-height: 1.4; }
}

Variante B – Mehr Kontrast zu deinen Überschriften

/* Bildschirm: etwas kleiner als 16px */
.mw-parser-output { font-size: 15px; line-height: 1.6; }

@media print {
  .mw-parser-output { font-size: 11.25pt; line-height: 1.4; } /* 15px in pt */
}

Variante C – Wikipedia-nah

/* Bildschirm: 14px */
.mw-parser-output { font-size: 14px; line-height: 1.6; }

@media print {
  .mw-parser-output { font-size: 10.5pt; line-height: 1.4; } /* 14px in pt */
}

Hinweise (knapp):

• Die Line-Height-Werte sind konservativ; du kannst sie unverändert lassen, wenn’s bereits gut aussieht.
• Die Überschriften bleiben unverändert, da sie feste pt-Größen haben.
• Durch die Kapselung auf .mw-parser-output bleibt der Vector-Chrome (Sidebar, Tabs usw.) unberührt.

Du:

Danke, ich übe ein wenig, was besser aussieht und passt.

Wenn ich nun die bottom-margin der Absätze anpassen will, ist da ".mw-body p { margin-bottom: 0,1em 0,5em 0em;}" richtig? Der Abstand zum nächsten Absatz ist zu groß, steht derzeit auf 10em.

ChatGPT:

Nachgedacht

Die Benutzeranfrage betrifft den unteren Abstand von Absätzen. Ihr Vorschlag enthält Fehler, da CSS Leerzeichen statt Kommata verwendet. Margin-bottom benötigt nur einen Wert. Paragrafen haben normalerweise oben und unten gleichmäßige Abstände von 1em. Der angegebene Wert von 10em scheint falsch, vielleicht durch eine fehlerhafte Berechnung entstanden. Wir sollten das korrigieren. Ich würde vorschlagen, .mw-parser-output p { margin: 0 0 0.5em; } zu verwenden oder speziell margin-bottom: 0.5em; margin-top: 0; für den unteren Abstand. Denk daran, dass line-height den Abstand beeinflusst und Margen zwischen Absätzen kollabieren können, wodurch der Abstand nur der größere Wert der benachbarten Margen ist. Also, ich erinnere mich, dass Margin-Kollaps zwischen angrenzenden Blockelementen im normalen Fluss auftritt, aber Border oder Padding verhindert den Kollaps. Ein Rahmen am unteren Rand eines Abschnitts verhindert den Kollaps der unteren Margin. Zwischen dem ersten Block und dem folgenden, wie zwischen Überschrift und Absatz, kann der Kollaps trotzdem auftreten. Margin-Kollaps tritt nur auf, wenn benachbarte Margen von Blockelementen vertikal und ohne Border, Padding oder ähnliches aneinanderstoßen. Für konsequente Abstände sollte man margin-top bei Absätzen auf 0 setzen und nur margin-bottom zur Steuerung des Abstands verwenden. Außerdem .mw-parser-output p verwenden, um den Inhalt richtig anzusprechen. Fertig

Kurze, präzise Antwort:

1. Dein Beispiel ist syntaktisch falsch.

• CSS nutzt Punkt statt Komma: 0.5em, nicht 0,5em.
• margin-bottom nimmt genau einen Wert, nicht drei.
• Scope besser auf den Inhaltsbereich: .mw-parser-output statt .mw-body.

2. Empfehlung für kleinere Absatzabstände (ohne Aufblähung):

/* Nur Inhalt, alle Absätze: kein Top-Margin, kleiner Bottom-Margin */
.mw-parser-output p {
  margin-top: 0;
  margin-bottom: 0.6em;  /* passe z. B. 0.4–0.8em an */
}

Hintergrund: Zwischen zwei <p> addieren sich Top/Bottom nicht, sondern es gilt die größere der beiden (Margin-Collapsing). Wenn du margin-top: 0 setzt, steuerst du den Abstand allein über margin-bottom.

1. Feiner Abstand nach Überschriften (optional, falls gewünscht):

   /* Untere Kante der Überschriften noch etwas kompakter */
   .mw-parser-output h2,
   .mw-parser-output h3,
   .mw-parser-output h4,
   .mw-parser-output h5,
   .mw-parser-output h6 {
     margin-bottom: 0.4em;
   }
   
   /* Erstes p nach einer Überschrift: kein zusätzliches Top-Margin */
   .mw-parser-output h2 + p,
   .mw-parser-output h3 + p,
   .mw-parser-output h4 + p,
   .mw-parser-output h5 + p,
   .mw-parser-output h6 + p {
     margin-top: 0;
   }
   

Hinweis zu deiner „10em“-Beobachtung: Das ist ungewöhnlich hoch und meist ein Computed-View-Artefakt oder stammt von einem anderen Selektor. Mit obigen Regeln bestimmst du die Abstände eindeutig.

Du:

Danke für die Belehrung. ".mw-parser-output p " funktioniert nicht.

In den Elementen kann ich .mw-body p den Abstand zwischen den Absätzen verändern, dahe rmüßte ".mw-parser-output p " richtig sein?

ChatGPT:

Nachgedacht

Nikolaos is having trouble with .mw-parser-output p not working, but .mw-body p can change spacing. We need to check for specificity or cascade issues in MediaWiki's Vector skin. I'll suggest using dev tools to confirm the structure and test other selectors like .mw-body-content p. Also, different skins could have variations in how styles are applied. The .mw-parser-output p selector should work, but maybe it's being overridden by more specific styles. It could be from MediaWiki:Vector.css or later CSS rules with higher specificity. I’d check for caching issues too, suggesting ?action=purge or ?safemode=1. Also, !important might be at play. It’s worth testing with dev tools to confirm. To fix this, I recommend checking the computed cascade and using a stronger selector with !important, like .mw-body .mw-parser-output p { margin-bottom: 0.6em !important; margin-top: 0; }. Also, consider targeting #mw-content-text p for better specificity. Some elements, like paragraphs inside lists, might need custom handling. It's better to avoid using > since templates might wrap elements. Instead, I’d suggest three sensible rules: .mw-parser-output p { margin: 0 0 0.6em; } .mw-body .mw-parser-output p, .mw-body-content .mw-parser-output p { margin: 0 0 0.6em !important; } Make sure this is added to MediaWiki:Common.css or Vector.css, and don’t forget to purge the cache. Fertig

Guter Hinweis. Ja, .mw-parser-output p ist konzeptionell richtig – wenn es „nicht greift“, wird es von einer später geladenen oder spezifischeren Regel (z. B. .mw-body p) überstimmt.

Nimm eine der beiden knappen Lösungen:

Variante A (skin-spezifisch, meist am saubersten) – in MediaWiki:Vector.css:

/* Nur Vector: Absatzabstände im Inhaltsbereich */
.mw-body .mw-parser-output p {
  margin-top: 0;
  margin-bottom: 0.6em !important;
}

(Durch .mw-body … + !important überstimmt das zuverlässig Vector/UA-Defaults.)

Variante B (Common.css, höhere Spezifität) – in MediaWiki:Common.css:

/* Mehr Spezifität nur im Content-Root */
#mw-content-text.mw-parser-output p {
  margin-top: 0;
  margin-bottom: 0.6em;
}

Wenn A/B sitzt und trotzdem etwas „dazwischenfunkt“, erhöhe temporär auf 0.5em !important.

Nach dem Speichern einmal die Seite purgen und hart neu laden.

Du:

".mw-body .mw-parser-output p" funktioniert. Danke.

Wenn ich da Elemente untersuche, kommt öfter der Eintrag "User-Agent-Stylesheet" – könnte dies eine überschreibende Einheit sein? erkläre mir bitte den Nutzen, wozu ich das brauche.

ChatGPT:

Nachgedacht

Ein "User-Agent-Stylesheet" (UA) ist die Standard-CSS, die von Browsern verwendet wird. Es hat eine festgelegte Priorität beim Laden von Webseiten und kann von der Website überschrieben werden, es sei denn, es gibt spezielle !important-Regeln. Das UA definiert unter anderem Standardmargen für h1-h6 oder p und sorgt für Konsistenz zwischen verschiedenen Websites und für Barrierefreiheit. Um das User-Agent-Stylesheet zu überschreiben, sollten Sie eigenes CSS verwenden. Vorsicht bei der Verwendung von !important, um nicht wichtige Stile wie Fokusrahmen zu entfernen. Für Formulareingabefelder können vendor-spezifische Pseudo-Elemente nötig sein. UA-Regeln haben niedrigen Vorrang im Kaskadenfluss, es sei denn, es gibt benutzerspezifische Stile. Einige typische User-Agent-Standardeinstellungen, die Sie beachten sollten, umfassen: Margen auf body, h1-h6, Schriftgrößen für h1/h2, Listen-Padding und Tabellenabstände. Um den Einfluss zu prüfen, können Sie die Computed-Tab in den DevTools verwenden. Allgemein gilt, dass benutzerspezifische Stile (oder !important) die UA-Styles überschreiben. Das "User-Agent-Stylesheet" stellt Standardwerte bereit, wenn Sie keine eigenen festgelegt haben. DevTools zeigen diese als durchgestrichen an, wenn sie überschrieben wurden. Es wird nicht überschrieben, sondern ist die Basis. Für Formulare gelten spezielle interne und Shadow-DOM-Stile. Benutzerdefinierte Stile überschreiben in der Regel die UA-Standards. Fertig

Kurz & klar:

Was ist „User-Agent-Stylesheet“?

Das sind die Browser-Standardstile (Defaults). Jeder Browser bringt eine interne CSS-Datei mit (z. B. p { margin: 1em 0; }, h1 { font-size: 2em; }, ul { padding-left: 40px; } usw.). In den DevTools siehst du diese Herkunft als „User-Agent-Stylesheet“.

Überschreibt das deine Regeln?

Im Normalfall nein. In der Kaskade gilt: Author-CSS (deins) > User-CSS > User-Agent (Browser).

Wenn in den DevTools der UA-Eintrag „aktiv“ wirkt, dann weil:

• du die Eigenschaft nicht gesetzt hast,
• dein Selektor nicht trifft, oder
• eine spezifischere Author-Regel (z. B. aus dem Skin) deine Regel überstimmt.

Genau das war bei dir der Punkt: .mw-parser-output p und .mw-body p haben gleiche Spezifität; wenn Vector/skin später lädt, gewinnt dessen Regel. Mit .mw-body .mw-parser-output p erhöhst du die Spezifität → deine Regel gewinnt, wie beobachtet.

Wozu braucht man die UA-Defaults?

Sie liefern ein lesbares Grundlayout ohne eigenes CSS: sinnvolle Abstände für Überschriften/Absätze, Einzüge bei Listen, Fokus-Umrandungen für Bedienbarkeit usw. Du „brauchst“ sie nicht aktiv – sie sind einfach da. Du überschreibstsie gezielt dort, wo du ein anderes Verhalten willst (so wie bei deinen Absatzabständen).

Ausnahmen/Hinweise (kurz):

• Manche Steuerelemente (Form Controls) haben starke/Shadow-DOM-Styles; da ist Überschreiben teils eingeschränkt. Im normalen Artikel-Body spielt das kaum eine Rolle.
• Entferne Fokus-Umrandungen (outline) nicht leichtfertig – das schadet Tastatur-Nutzenden.

Unterm Strich: Der „User-Agent-Stylesheet“-Eintrag ist keine störende Instanz, sondern nur die Quelle der Defaults. Entscheidend sind Spezifität und Lade-Reihenfolge deiner (und der Skin-) Regeln.

Du:

Danke für die Informationen – wieder was dazu gelernt.  

Nächste Frage. Ich kann in den Nutzer-Einstellungen Schrift ohne und mit Serifen voreinstellen.

Wozu ist das? Was ist der Nutzen?

ChatGPT:

Nachgedacht

In MediaWiki, die Schriftartenpräferenzen steuern die Lesbarkeit auf der Seite. Im Vector-Design wird üblicherweise eine serifenbetonte Schrift bevorzugt, während die Standardansicht meist serifenfrei ist. Diese Präferenzen können durch benutzerdefinierte Gadgets oder die "Schriften"-Option in den "Erscheinungsbild"-Einstellungen angepasst werden. Das hängt von der MediaWiki-Version ab. Im WMF-Standard-Vector-Design gibt es im Kern keine benutzerdefinierte Schriftartenpräferenz. Der Benutzer hat jedoch anscheinend in seiner eigenen Installation eine Möglichkeit zur Auswahl zwischen Serifenschriftarten. Dies könnte durch Funktionen des Vector-Skins wie vector-feature-custom-font in Verbindung mit richtigen CSS-Klassen wie skin-vector-font-size oder skin-vector-font-family bereitgestellt werden. Serifen- und serifenlose Schriftarten haben unterschiedliche Lesbarkeitsvorteile. Serifenlose Schriften sind oft besser auf niedrig aufgelösten Bildschirmen und in User Interfaces. Serifen verbessern das Lesen bei längeren Texten in gedruckter Form. Es ist auch eine persönliche Vorliebe, aber auf Retina-Bildschirmen (wie macOS und iPad) sind beide gut lesbar. Serifen- und serifenlose Schriftarten beeinflussen die Darstellung, aber nicht den Monospace-Codeblock. Normalerweise wird eine Klasse auf <body> oder <html> angewendet, und CSS legt den Schriftstapel fest. Zum Beispiel: skin-vector-font-family-serif für eine serifenbetonte Schrift. Man kann Anpassungen an der Buchstaben-Abstände und Zeilenhöhe für Serifen-Schriften vornehmen. Die Schriftartenwahl betrifft nicht die Monospace-Codeblöcke. In der Regel wird eine Klasse auf <body> oder <html>angewendet, z. B. skin-vector-font-family-serif vs. ...-sans-serif, um den Schriftstapel zu bestimmen. Anpassungen an der Zeilenhöhe und dem Buchstabenabstand sind möglich, aber wir sollten es nicht übertreiben, vor allem ohne genaue DOM-Überprüfung. Alternativ könnte eine CSS-Implementierung helfen. Fertig

Kurz & sachlich:

Wozu die Schriftwahl „mit/ohne Serifen“?

Das ist eine Lesepräferenz für den Inhaltsbereich. Je nach Skin (z. B. Vector) kannst du wählen, ob der Fließtext/Überschriften mit einer Serif-Schriftfamilie (z. B. Georgia, Noto Serif) oder Sans-Serif (z. B. system-UI, Noto Sans) gerendert werden. UI-Elemente (Sidebar, Tabs) bleiben oft sans-serif.

Nutzen (typografisch):

• Serif: bei längeren Texten und fürs Drucken oft angenehmer; Serifen führen das Auge in Zeilenrichtung, wirken „buchartig“.
• Sans-Serif: auf Bildschirmen bei kleineren Graden meist klarer, neutraler; gut für UI und technisch geprägte Seiten.

Technisch wird dabei in der Regel eine Klasse am <body> gesetzt (z. B. „…-serif“ vs. „…-sans-serif“), die die font-family im Inhaltsbereich umschaltet. Monospace-Bereiche (Code), Formeln etc. bleiben davon unberührt.

Praktischer Effekt für dich

• Du (und andere Nutzer) können die Lesbarkeit nach persönlichem Empfinden einstellen, ohne die siteweiten Styles zu ändern.
• Für deine Druck-Überlegungen passt Serif meist gut, während deine aktuellen pt-Überschriften unverändert bleiben.

Wenn du prüfen willst, wie dein Skin das umsetzt, schau im DOM nach einer Body-Klasse in der Art von

skin-vector-font-family-serif / …-sans-serif (Bezeichnung kann je nach Version abweichen).

Du:

Ich habe serif zum Test aktiviert und mit derselben zuvor geladenen Seite vergleichen und bemerke da keinen optischen Unterschied. Im Dom habe ich serif als Suchbegriff eingegeben und da erscheint viel

ChatGPT:

Nachgedacht

Es könnte sein, dass der Serif-Wechsel keine Änderung zeigt, weil die Schriftart-Einstellungen durch CSS, Medienwiki oder andere benutzerdefinierte Einstellungen überschrieben werden. Auch das Caching oder versehentliche Festlegung der Font-Familie auf Systemschriftarten kann das Ergebnis beeinflussen. Wenn du Änderungen vornimmst, versuche einen Hard-Reload oder prüfe, ob „Use System Font“ aktiviert ist. Es könnte sein, dass die "Use a serif font"-Option in Vector-2022 nicht aktiviert ist. Um das zu überprüfen, kann man den Body-Styles und die Klasse der Seite kontrollieren. Man könnte auch testen, indem man die Schriftart manuell auf Georgia ändert, um den Unterschied zu sehen. Wenn das nicht klappt, liegt der Fehler vielleicht woanders in den Einstellungen. Manchmal haben Überschriften eine andere Schriftart als der Fließtext, selbst wenn eine Serifenschrift bevorzugt wird. Auf Mac/iOS ist Times die Standard-Serifenschrift, während sans-serif oft "San Francisco" ist. Wenn keine Webfonts geladen sind, verwendet Wikipedia System-Schriften. Um einen Unterschied zu sehen, kann man mit minimalem CSS testen und überprüfen, welche Klassen geändert werden. Es könnte sein, dass deine Common.css die Schriftart für den Fließtext setzt. Wenn Vector ebenfalls System-Schriften verwendet, gibt es möglicherweise keinen Unterschied zwischen Serif und Sans. Achte darauf, dass du nicht nur Überschriften testest, sondern auch Absätze. Überprüfe den "font-family"-Wert in den Entwicklertools, um festzustellen, ob sich etwas ändert. Fertig

Kurz & präzise:

Warum du keinen Unterschied siehst

Wahrscheinlichkeit (in dieser Reihenfolge):

1. Kein Umschalt-Hook im Skin aktiv – deine Vector-Version oder -Konfiguration setzt beim „Serif“-Schalter keineandere font-family.
2. Andere Regeln überdecken es – z. B. MediaWiki:Common.css, Vector.css oder ein Gadget setzt font-familyauf .mw-body/.mw-parser-output → die Präferenz kann nichts ändern.
3. Gleiche Fonts im Stack – wenn Serif/Sans-Stacks effektiv auf dasselbe Systemfont fallen (macOS: San Francisco vs. Times) und irgendwo eine feste Familie steht, bleibt es optisch gleich.

„User-Agent-Stylesheet“ ist hier nicht die Ursache; entscheidend sind Author-Styles (deine/Skin-CSS).

So prüfst du es in 30 Sek.

1. Computed Style checken Wähle einen normalen Absatz (.mw-parser-output p) → DevTools → Computed → font-family. Schalte die Präferenz „Serif“ aus/ein und lade neu. Ändert sich font-family nicht, greift der Schalter nicht.
2. Body-Klassen vergleichen In der Konsole:

   document.body.className
   

   einmal mit Serif „aus“, einmal „an“. Wenn keine zusätzliche Klasse auftaucht (etwa mit „serif“ im Namen), setzt dein Skin bei dir schlicht keinen Toggle.

Wenn du den Toggle nutzen willst (ohne Raten)

• Finde den einen Klassen-Unterschied am <body> (s. oben). Angenommen, er heißt vector-font-serif(Platzhalter!):

  /* Serif-Präferenz aktiv: Inhalt in Serif */
  body.vector-font-serif .mw-parser-output {
    font-family: Georgia, "Times New Roman", Times, serif;
  }
  
  /* Serif-Präferenz aus: Inhalt in Sans-Serif */
  body:not(.vector-font-serif) .mw-parser-output {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
  }
  

• Gibt es keinen Klassen-Unterschied, bietet deine Installation den Hook nicht. Dann bleibt nur: siteweit eine Familie festlegen (oder ein eigenes kleines Gadget, das eine Klasse auf <body> setzt).

Tipp zum Verifizieren: Prüfe die font-family an einem Absatz, nicht an Überschriften (die können separate Familien haben).

Du:

Ich habe einige Vorlagen und Stylesheets von Wikipedia installiert. Auf Wikipedia kann man Serif nicht auswählen.

Wenn ich "/* Serif-Präferenz aus: Inhalt in Sans-Serif */

" ausführre, habe ich einen optischen unterschied – die Schrift ist weiter.

ChatGPT:

Nachgedacht

Der Benutzer möchte wissen, warum sich die Schriftarten ändern, wenn sie den Befehl „/* Serif-Präferenz aus: Inhalt in Sans-Serif */“ ausführen. Dies betrifft die Schriftartstile in CSS und wie Schriftarten in verschiedenen Medienwiki-Umgebungen angezeigt werden. Ich könnte eine einfache CSS-Lösung anbieten, um explizit Schriftarten für Serif/Sans-Serif festzulegen und wie sie breite Schriftarten praktisch beeinflussen. Auf macOS ist die Standardschrift für Sans-Serif "San Francisco", die breitere Buchstabenabstände zeigt. Serif-Schriften sind meist Times oder Times New Roman. Auf Wikipedia wird standardmäßig eine Sans-Serif-Schrift verwendet, da die CSS-Definition sie in der .mw-body-Klasse festlegt. Eine manuelle Lösung könnte ein Feature zur Auswahl von Serifen- und Sans-Schriften über CSS oder Skripte sein. Da der Benutzer technisch versiert ist, könnten wir zwei kleine CSS-Blöcke und optional ein kleines JavaScript anbieten, um die Schriftart über eine Benutzerpräferenz umzuschalten. Der Begriff „wider“ könnte durch unterschiedliche x-Höhen von Sans-Serif-Schriften wie „-apple-system“ im Vergleich zu „Georgia“ erklärt werden. Eine Option: Evtl. letter-spacing verwenden, um den Abstand zwischen den Buchstaben zu verringern. Da der Benutzer nach Schriftarten fragt, schlage ich zwei minimalistische Font-Stacks vor. Für Sans-Serif: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif und für Serif: Iowan Old Style, Palatino, "Times New Roman", Times, serif. Ich erwähne, dass Wikipedia-Stile möglicherweise die Schriftart überschreiben könnten, etwa durch .mw-body-content. Eine schnelle Suche im CSS könnte helfen. Fertig

Kurz & präzise:

Warum wirkt „Sans-Serif“ breiter?

Dein Sans-Stack (z. B. -apple-system/San Francisco) hat größere x-Höhe und andere Metriken als die Serif-Schriften (z. B. Georgia/Times). Deshalb wirkt der Text „weiter“/luftiger, selbst bei gleicher Punktgröße.

Wikipedia-Effekt

Wenn du Wikipedia-CSS übernommen hast: dort ist Content standardmäßig sans-serif gesetzt. Einen „Serif“-Schalter gibt’s dort nicht; daher siehst du erst nach deiner expliziten Regel einen Unterschied.

Minimal saubere Steuerung bei dir

1) Zwei klare Stacks (nur Inhaltsbereich)

/* Sans-Serif (Screen-neutral, macOS/iPad gut) */
body.aew-sans .mw-parser-output {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
               "Helvetica Neue", Arial, sans-serif;
}

/* Serif (buchartiger, oft druckfreundlich) */
body.aew-serif .mw-parser-output {
  font-family: Georgia, "Times New Roman", Times, serif;
}

→ Setze einmalig auf <body> entweder class="aew-sans" oder class="aew-serif" (z. B. per Gadget/Benutzer-CSS). So übersteuert nichts aus übernommenen Wikipedia-Styles.

2) „Breite“ feinjustieren (optional, sehr subtil)

Wenn Sans dir zu „weit“ vorkommt, nimm eine dieser kleinen Korrekturen:

/* Option A: minimal kleiner */
body.aew-sans .mw-parser-output { font-size: 15px; } /* statt 16px */

/* Option B: sehr leicht engeres Tracking */
body.aew-sans .mw-parser-output { letter-spacing: -0.005em; } /* nicht mehr! */

Ich würde nur A oder B verwenden, nicht beides. A ist robuster.

Warum nicht mehr Zauber?

Du hast bereits Headings in pt festgelegt (druckfreundlich). Mit obigem Schalter regelst du den Fließtext klar zwischen Sans/Serif, ohne deine übrige Typografie anzutasten.

Du:

Ich lasse es wie es ist, da ich jetzt keinen Nachteil habe und keinen wirklichen Vorteil dadurch bemerke. Das Engere ist dennoch gut lesbar.

Andere Frage. WIr haben Gestern und heute einiges an dem Erscheinungsbild meines MediaWiki gearbeitet.

Durch welche Art Maßnahme kann ich mir den Fehler eingebaut haben, daß ich nun neben den Abschnittüberschriften im Vector-Skin 2022 die Links zum Bearbeiten nicht mehr habe? Direkt daran haben wir nicht egearbeitet. Ich habe im Verlauf von heute bemerkt, daß sie deaktiviert sind.

Gesetzt ist "$wgDefaultUserOptions ['editsection'] = true; " doch das war zuvor nicht nötig.

In WikiMedia:Common.csss haben wir auch nichts hineingetan.

Gibt es da noch einen anderen "Schalter"?

ChatGPT:

Nachgedacht

Nikolaos hat nach fehlenden Bearbeitungs-Links in Vector-2022 gefragt, besonders nach Änderungen im CSS und anderen Modifikationen. Ich werde potenzielle Ursachen prüfen, wie die Integration des VisualEditors, die Sichtbarkeit von editsection-Links und JavaScript/CSS-bezogene Probleme. Wichtig sind auch Konfigurationen wie $wgDefaultUserOptions, $wgVectorFeatures und mögliche Konflikte mit dem VisualEditor. In Vector-2022 können die Bearbeitungs-Links standardmäßig versteckt sein oder nur bei Hover sichtbar werden. CSS könnte diese Links versehentlich von der Anzeige ablenken. Es gibt auch Vorschläge zur Neuanordnung von Elementen wie h2-h6, aber bisher keine Änderung am Verhalten von .mw-headline. Auch die Änderung der Benutzereinstellungen könnte betroffen sein, aber betrifft nur neue Konten. Möglicherweise liegt das Fehlen der Editier-Links an den Benutzereinstellungen für den VisualEditor oder einer Konfiguration wie 'editsectiononrightclick'. Auch könnte das Flag $wgSectionEditLinks eine Rolle spielen. In Vector-2022 können Editier-Links durch Eigenschaften wie 'Edit clearly' oder die Gadget-Konstruktion beeinflusst werden. Es könnte sein, dass das Gadget die Links abhängig von bestimmten Bedingungen verbirgt, oder der VisualEditor beeinflusst die Anzeige nur bei aktivierten "Bearbeiten"-Links. Auch könnte der Modus von Vector-2022 mit eingeschränkter Breite die Sektionen beeinflussen. Ein CSS-Problem könnte ebenfalls vorhanden sein, wenn bestimmte Stile überschrieben werden. Es gibt mehrere mögliche Ursachen für das Fehlen der Abschnitts-Bearbeitungslinks. Zuerst könnte das magische Wort __NOEDITSECTION__ verwendet werden, um diese Links zu blockieren. Überprüfen Sie den Seitenquelltext auf dieses Wort und aktive Vorlagen. Außerdem sollte die Einstellung $wgSectionEditLinks in den LocalSettings.php überprüft werden. Fertig

Kurz & präzise – die üblichen Ursachen (in absteigender Wahrscheinlichkeit) und wie du sie in <60 Sek. prüfst:

1) Seitenweit unterdrückt: __NOEDITSECTION__

Viele importierte Wikipedia-Vorlagen enthalten das Magische Wort und unterdrücken damit die Abschnitts-Links.

Schnelltest (Konsole auf der betroffenen Seite): js mw.config.get('wgNoEditSection')  // → true = unterdrückt

Wenn true: Quelle finden (Seitenquelltext & transkludierte Vorlagen prüfen) und __NOEDITSECTION__ entfernen.

Tipp: „Seiteninformationen“ zeigt unter „Verwendete Magische Wörter“ oft NOEDITSECTION, wenn aktiv.

2) Deine Einstellung vs. Default

$wgDefaultUserOptions['editsection'] = true; wirkt nur für neue Konten.

Für dein Konto: Benutzereinstellungen → Bearbeiten → Abschnitts-Bearbeiten aktivieren.

3) Globale Server-Option

Stelle sicher, dass sitewide nicht abgeschaltet ist:

// LocalSettings.php
$wgSectionEditLinks = true;

4) CSS/JS blendet .mw-editsection aus

Mit Wikipedia-CSS/-Gadgets importiert man leicht Regeln wie: css .mw-editsection { display:none; }

Schnelltest (Konsole): document.querySelectorAll('.mw-editsection').length  // 0 = nicht im DOM (Parser/Magic Word)

                                                    // >0 = im DOM, dann versteckt -> CSS/JS

Wenn >0, in den DevTools auf ein .mw-editsection klicken → Computed zeigt dir den „Gewinner“-Selektor, der es versteckt.

Außerdem kurz mit ?safemode=1 laden (Gadgets aus) – erscheinen sie dann, steckt es in einem Gadget/Stylesheet.

5) Vector-2022 + VisualEditor

In Vector-2022 erscheinen die Links teils als Stift-Icon beim Hover. Wenn gar nichts erscheint:

• VE-Einstellung prüfen (ein/aus),
• testweise ?veaction=edit/?veaction=editsource aufrufen,
• und mit ?useskin=vector-2022 bzw. ?useskin=vector gegenprüfen.

Was ich vermute (Mutmaßung, >50 %)

Da du Wikipedia-Vorlagen importiert hast und es „plötzlich überall“ weg ist, ist __NOEDITSECTION__ in einer importierten, breit verwendeten Vorlage der wahrscheinlichste Auslöser.

Wenn du mir sagst, ob mw.config.get('wgNoEditSection') true liefert und ob document.querySelectorAll('.mw-editsection') 0 oder >0 ergibt, kann ich dir die passende, einzige Stelle nennen, an der du drehen musst.

Du:

1. __NOEDITSECTION__ habe ich auch nicht benutzt

2. und die Seite zeigt in der Konsole für "mw.config.get('wgNoEditSection') " Antwort "null".

3. Wenn ich von Vector-Skin 2022 auf 2010 umschalte sind die Links wieder da.

4. Mit "$wgSectionEditLinks = true;" tut sich auch nichts.

5. document.querySelectorAll('.mw-editsection').length gibt die Antwort 7 = $1

ChatGPT:

Nachgedacht

Die Editier-Links könnten aufgrund von CSS oder der Konfiguration im Vector-2022-Design verborgen sein. Es gibt eine Einstellung, bei der die Links entweder neben den Überschriften oder in den Seitenwerkzeugen angezeigt werden. In späteren Vector-Versionen erscheinen die Links möglicherweise nur beim Überfahren mit der Maus. Justierungen sind hier erforderlich. Es sieht so aus, als könnte es an der CSS liegen, die Header manipuliert und möglicherweise .mw-editsection verbirgt. Es wurde eine kollabierbare Überschrift hinzugefügt, die das Layout verändert hat. Möglicherweise gibt es Regeln wie „overflow: hidden” oder „display: inline-block“, die die Links ausblenden oder verschieben. In Vector-2022 sind die Editier-Links auf kleinen Bildschirmen möglicherweise durch ein Menü ersetzt und mit bestimmten CSS-Regeln wie „vector-feature-limited-width” versteckt. Es könnte auch an Einstellungen wie display: inline-block oder overflow: hidden auf den Überschriften liegen, die das Verbergen der Links verursachen. Es scheint, dass in Vector-2022 die Editier-Links durch display: none oder visibility: hidden verborgen sind, oder sie sind wegen Layout-Problemen verschoben. Auch der Schalter „Bearbeiten“ könnte durch ein Symbol ersetzt worden sein, besonders auf mobilen Geräten, wo das Layout durch „vector-feature-limited-width“ angepasst wird. Fertig

Kurz & zielgenau:

Du hast die .mw-editsection-Elemente im DOM (7 Stück) → also kein Parser/Magic-Word-Problem. In Vector-2022werden die Abschnitts-Links häufig per CSS ausgeblendet (Pencil-Icon/Section-Tools). Durch die von dir importierten Wikipedia-Styles ist sehr wahrscheinlich eine Regel aktiv wie .skin-vector-2022 .mw-editsection { display:none; }.

Fix (minimal, nur Vector-2022):

/* MediaWiki:Vector-2022.css ODER MediaWiki:Common.css */
.skin-vector-2022 .mw-parser-output .mw-editsection {
  display: inline !important;
  visibility: visible !important;
  opacity: 1 !important;
  float: none;
  margin-left: .5em;
}

Damit erzwingst du die Anzeige neben den Überschriften – in Vector-2010 war sie nie versteckt, daher der Unterschied beim Umschalten des Skins.

Optionaler Schnelltest:

• Seite mit ?safemode=1 laden → sind die Links sichtbar, steckt es in einem Gadget/overridem CSS.
• In DevTools auf ein .mw-editsection klicken → Computed → display zeigt dir, welche Regel es versteckt (vermutlich eine .skin-vector-2022 …-Regel aus den übernommenen Styles).

Du:

Die MediaWiki Vorlagen habe ich schon lange drin und wie gesagt, heute morgen funktionierte es noch.

Wir haben an einem Toggle für Überschriften gearbeitet und ein Javascript dazu entworfen. Ich werde in den anderen Chat nachfragen, ob es dadurch geschehen sein kann, da das letzte Update heute Morgen von dir eingebaut wurde.

Der "Fix (minimal, nur Vector-2022):" funktioniert.

Kann man da bei Gelegenheit aus

[Bearbeiten | alle ausblenden | ausblenden | Quelltext bearbeiten ]

da nicht kleine Ikons anstelle der Schrift setzen?

ChatGPT:

Nachgedacht

Die Anfrage ist klar: Der Benutzer möchte Textlinks wie "[Bearbeiten | alle ausblenden | ausblenden | Quelltext bearbeiten]" durch kleine Icons ersetzen. Eine Anpassung der CSS ist nötig, um Text zu verstecken und Icons zu zeigen. Wir könnten Unicode, Emojis oder benutzerdefinierte SVGs als Hintergrund verwenden. Es gibt jedoch auch die Möglichkeit, bestehende Icons aus dem UI-System zu verwenden. Wir sollten daher vorsichtig sein, da externe Bilder möglicherweise nicht in allen Skins verfügbar sind. Eine Lösung wäre, CSS-Klassen hinzuzufügen, um Text mit existierenden Glyphen wie 🖉 zu ersetzen, oder systemeigene Schriftarten zu verwenden. Eine andere Möglichkeit: OOUI-Icons über CSS-Klassen zu integrieren, wenn die entsprechenden Module geladen sind. Eine einfache Lösung könnte sein, CSS zu verwenden, um den Text in den Links zu verstecken und Icons einzufügen. Ich könnte den "content"-Eigenschaft verwenden, um beispielsweise Unicode-Icons wie ✎ zu setzen. Da es mehrere Links gibt, müsste ich jeden Link nach href oder Klasse differenzieren, um die richtigen Icons zuzuweisen. Die Links für "Bearbeiten" und "Visual bearbeiten" haben unterschiedliche Klassen und href-Attribute, was es uns ermöglicht, sie mit gezielten CSS-Regeln anzusprechen. Ich könnte kleine Icons verwenden, wie ✎ für "Bearbeiten" oder ⧉ für "Quelltext bearbeiten". Ein "Wrench" oder "⌘" für das Quelltext-Icon könnte ebenfalls passend sein. Ich kann CSS verwenden, um die Textlinks durch Icons zu ersetzen. Das geht mit Unicode-Icons wie ✎ für die Visuelle Bearbeitung und </> für den Quelltext. Die Trennsymbole werden mit display: none verborgen. Für den Toggle-Link könnten wir vorerst das Symbol ▾ verwenden und den Zustand mit minimalem CSS oder optionalem JS umschalten. Fertig

Ja — das geht rein mit CSS (ohne neue Module).

Du „ikonifizierst“ die Links, indem du den Text visuell versteckst und per ::before ein Symbol setzt. Für Vector-2022 so schlank wie möglich:

/* Nur Vector-2022: Klammern & Trenner ausblenden */
.skin-vector-2022 .mw-parser-output .mw-editsection .mw-editsection-bracket,
.skin-vector-2022 .mw-parser-output .mw-editsection .mw-editsection-divider { display: none; }

/* Text der Links visuell verstecken (für Screenreader bleibt er erhalten) */
.skin-vector-2022 .mw-parser-output .mw-editsection a > span {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

/* Basis-Stil für die Icons */
.skin-vector-2022 .mw-parser-output .mw-editsection a::before {
  display: inline-block; vertical-align: middle;
  font-size: 14px; line-height: 1; padding: 0 .2em;
}

/* Icon: Abschnitt bearbeiten (VE) */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor::before {
  content: "✎"; /* Bleistift */
}

/* Icon: Quelltext bearbeiten (klassisch) */
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"]:not(.mw-editsection-visualeditor)::before {
  content: "✎"; /* ggf. anderes Zeichen wählen */
}

/* Icon: aus-/einblenden (dein Toggle-Link) */
.skin-vector-2022 .mw-parser-output .mw-editsection a.hidesection-link::before {
  content: "▾"; /* „ausblenden“ */
}

/* Optional dynamisch, falls dein Gadget am <h2/h3…> z. B. .collapsed setzt */
.skin-vector-2022 .mw-parser-output h2.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h3.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h4.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h5.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h6.collapsed .mw-editsection a.hidesection-link::before {
  content: "▸"; /* „einblenden“ */
}

Hinweise (nur zur Klarstellung):

• Die Anker enthalten bei dir <span> – genau den verstecken wir visuell, damit Tooltips/Screenreader erhalten bleiben.
• Die beiden Bearbeiten-Links (VE/Quelltext) habe ich auf dasselbe Symbol gesetzt; wenn du sie unterscheiden willst, nimm z. B. content: "{}" für Quelltext.

Wenn dein Gadget beim Einklappen eine andere Klassenbezeichnung setzt, ersetze .collapsed entsprechend.

Du:

Danke für den Entwurf.

WIr dürfen nurn die Funktuon damit nicht verändern da wir heute Morgen dazu AufEinWortSeiteKennung.js gebaut haben, daß diese braucht um keys für toggle-open-closed zu setzen.

ChatGPT:

Nachgedacht

Der Benutzer hat Bedenken, dass CSS-Icon-Änderungen die Funktionalität der JS-Interaktionen beeinträchtigen könnten, insbesondere die Toggle-Links. Ich muss sicherstellen, dass die CSS-Änderungen keine DOM-Struktur oder Textinhalte verändern. Eine Option könnte sein, rein visuelle Anpassungen vorzunehmen, indem ich :before benutze und Text durch eine visuell-versteckte Technik ausblende, ohne den zugänglichen Namen zu beeinflussen. Das visuelle Verstecken von Spans ändert nicht die DOM-Struktur, aber die Bedenken drehen sich um die Funktionalität. Eine Lösung könnte darin bestehen, ein CSS zu verwenden, das nur ein Pseudo-Element anspricht, ohne den Inhalt zu ändern. Wir sollten sicherstellen, dass die Textinhalte, die JS liest, unverändert bleiben. Vielleicht sollten wir auf andere visuelle Techniken zurückgreifen, um sicherzustellen, dass der Text nicht für assistive Technologien unsichtbar wird. Der Benutzer möchte die exakte Funktionalität beibehalten, einschließlich des umgeschalteten Texts zwischen "einblenden" und "ausblenden", da das von ihrem JS genutzt wird. Ihre Skripte arbeiten mit bestimmten Datenattributen, aber das visuelle Verstecken des Textes könnte problematisch sein, da sie den inneren Text für die Schlüsselgeneration verwenden. Die Icons sind jedoch noch in Ordnung. Um die Textfunktionalität zu erhalten, schlage ich vor, das Icon über ::after hinzuzufügen, ohne den Text zu verstecken. Das sorgt dafür, dass der Text sichtbar bleibt, aber das Icon sichtbar wird. Falls sie Icons statt Text bevorzugen, könnte ich den Text durch aria-label ausblenden, um die Barrierefreiheit zu gewährleisten. Fertig

verstanden. Wir ändern nur die Optik, nicht DOM/Text/Attribute – dein AufEinWortSeiteKennung.js bleibt unberührt.

Icons zusätzlich zum Text (funktional 100% identisch)

/* Sichtbarkeit der Edit-Links sicherstellen (falls zuvor ausgeblendet) */
.skin-vector-2022 .mw-parser-output .mw-editsection { display: inline !important; }

/* Klammern/Trenner optional stehen lassen – wir verändern die Funktion nicht */

/* Basis-Iconstil */
.skin-vector-2022 .mw-parser-output .mw-editsection a::before {
  display: inline-block;
  vertical-align: middle;
  font-size: 14px;
  line-height: 1;
  margin-right: .25em; /* kleiner Abstand vor dem Text */
}

/* VE-Bearbeiten */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor::before {
  content: "✎";
}

/* Quelltext bearbeiten */
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"]:not(.mw-editsection-visualeditor)::before {
  content: "📝";
}

/* Aus-/Einblenden (dein Toggle-Link) – Standard: geöffnet */
.skin-vector-2022 .mw-parser-output :is(h2,h3,h4,h5,h6) .mw-editsection a.hidesection-link::before {
  content: "▾";
}
/* Wenn dein Gadget am Heading .collapsed setzt, Icon umschalten */
.skin-vector-2022 .mw-parser-output :is(h2,h3,h4,h5,h6).collapsed .mw-editsection a.hidesection-link::before {
  content: "▸";
}

Nichts wird versteckt, kein innerText geändert. Nur ::before-Pseudoelemente.

Wenn du irgendwann wirklich nur Icons (ohne sichtbaren Text) willst, kann man das rein visuell per zusätzlicher Opt-In-Klasse lösen (z. B. body.aew-icons-only … a > span { … }), ohne irgendetwas an deinem JS zu ändern. Solange du diese Klasse nicht setzt, bleibt alles wie oben: Text + Icon.

Du:

Mit der Syntaxt bekomme ich je Zeile mit den Skin den fehler "Expected RPAREN"

ChatGPT:

Nachgedacht

Der Benutzer erhält den Fehler „Expected RPAREN“ bei einer CSS-Zeile, möglicherweise bei der Verwendung von :is() oder durch die „Skin“-Zeilen. Der Fehler deutet auf eine fehlende schließende Klammer hin, was bei :is() oder :not() wahrscheinlich ist. Es könnte sein, dass der Validator :is() nicht unterstützt. Der Benutzer berichtet von einem Fehler in Zeilen, die mit „.skin-vector-2022“ beginnen, aber in diesen Zeilen kommen keine Klammern vor. Die Klammern sind jedoch in anderen Teilen der Selektoren wie :not() und :is(). Es scheint, dass der MediaWiki-Validator Klammern in @media-Anweisungen erwartet, was den Fehler verursacht. Der Fehler „Expected RPAREN“ könnte darauf hinweisen, dass der CSS-Validator Schwierigkeiten mit :is() hat, was zu einer fehlerhaften Interpretation führt. Auch die Verwendung von Emojis oder „:not()“ könnte eine Rolle spielen, wobei letzteres von älteren Validatoren möglicherweise nicht korrekt erkannt wird. Die Kommentare und deutsche Dezimalzeichen sollten jedoch keine Probleme verursachen. Das Problem könnte an einer älteren Parser-Version liegen, möglicherweise in MediaWiki 1.43. Der Fehler "Expected RPAREN" tritt häufig bei unbekannten Pseudo-Klassen wie :is() auf. Falls der Benutzer „Skin-vector-2022“ statt „.skin-vector-2022“ schreibt, könnte das zu einem Missverständnis führen, aber normalerweise geht es um die Klammern. Fertig

Danke fürs Feedback – das kommt vom MediaWiki-CSS-Prüfer: :is(...) (und teils :not(...)) werden dort noch „krumm“ geparst → Expected RPAREN. Ich habe die Selektoren auf eine konservative Fassung ohne funktionale Pseudoklassen umgestellt. Funktion bleibt identisch, dein JS bleibt unberührt.

Vector-2022: nur Icons zusätzlich zum Linktext (DOM unverändert)

/* Sichtbarkeit sicherstellen */
.skin-vector-2022 .mw-parser-output .mw-editsection {
  display: inline !important;
  visibility: visible !important;
  opacity: 1 !important;
}

/* Basis für alle Edit-Links: kleines Icon vor den Text */
.skin-vector-2022 .mw-parser-output .mw-editsection a::before {
  display: inline-block;
  vertical-align: middle;
  font-size: 14px;
  line-height: 1;
  margin-right: .25em;
}

/* VisualEditor-Bearbeiten */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor::before {
  content: "✎";
}

/* Quelltext bearbeiten (klassischer Editor) */
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"]::before {
  content: "📝";
}

/* Aus-/Einblenden (dein Toggle-Link): Standard = geöffnet */
.skin-vector-2022 .mw-parser-output h2 .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h3 .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h4 .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h5 .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h6 .mw-editsection a.hidesection-link::before {
  content: "▾";
}

/* Wenn die Überschrift vom Gadget eingeklappt ist (Klasse .collapsed) */
.skin-vector-2022 .mw-parser-output h2.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h3.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h4.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h5.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h6.collapsed .mw-editsection a.hidesection-link::before {
  content: "▸";
}

Das vermeidet :is()/:not() vollständig – damit sollte der RPAREN-Hinweis verschwinden.

Du:

mit dem Coding habe ich Ikon's und Text. nach …::before kommt vergleichsweise

<span>Bearbeiten</span>"

<a href="/mediawiki/index.php?title=Johann_Christoph_Adelung&amp;veaction=edit&amp;section=3" title="Abschnitt bearbeiten: Schreibung von „s“, „ss“ und „ß“" class="mw-editsection-visualeditor"><span>Bearbeiten</span></a>
<<pseudo>></<pseudo>>
<span>Bearbeiten</span>
<a href="/mediawiki/index.php?title=Johann_Christoph_Adelung&amp;veaction=edit&amp;section=3" title="Abschnitt bearbeiten: Schreibung von „s“, „ss“ und „ß“" class="mw-editsection-visualeditor"><span>Bearbeiten</span></a>
<span class="mw-editsection-divider"> | </span>

ChatGPT:

Nachgedacht

Der Benutzer hat sowohl Symbole als auch Text. Sie wollen wahrscheinlich nur Symbole ohne doppelten Text. Früher haben sie erwähnt, dass ihre JS-Funktion auf Text basiert, um die Schaltflächenfunktionen zu steuern. Der "Bearbeiten"-Text scheint von der JS-Funktion nicht beeinflusst zu sein. Es scheint also eine Anzeigeproblematik zu sein, bei der die DevTools das Pseudoelement anzeigen. Es scheint, dass der Benutzer das zusätzliche "Bearbeiten" sieht, aber das liegt an der Verwendung des ::before-Pseudo-Elements, das Symbole anzeigt. Sie möchten möglicherweise den Text "Bearbeiten" für bestimmte Links ausblenden, aber das Symbol behalten. Sie hatten um Icons zusätzlich zum Text gebeten, jedoch ohne die Funktion zu ändern – das könnte die Ursache der Verwirrung sein. Der Benutzer sieht Icons und Text, was erwartet wurde. Sie möchten möglicherweise nur das "Bearbeiten"-Symbol anzeigen, ohne die Funktion zu ändern. Um nicht die Toggle-Funktion zu beeinflussen, könnten wir CSS verwenden, um nur den Text bei Editierlinks auszublenden, während der Text für Toggle-Links sichtbar bleibt. Eventuell suchen sie nach dieser Lösung. Ich sollte sicherstellen, dass Text für Screenreader zugänglich bleibt und keine modernen Selektoren verwendet werden, um ein Problem mit Error-RPAREN zu vermeiden. Zudem muss der Code sicherstellen, dass Event-Listener nicht beeinträchtigt werden. Ich biete eine Lösung, um Text nur bei Editierlinks auszublenden, während der Toggle-Text erhalten bleibt. Weitere Anpassungen wie das Entfernen von Klammern und Trennzeichen könnte ich ebenfalls einfügen. Fertig

klar – das Verhalten ist korrekt: ::before fügt dein Icon vor den Linktext ein; der <span>Bearbeiten</span> ist der originale Text.

Wenn du bei Vector-2022 für die Bearbeiten-Links (VE & Quelltext) nur Icons sehen willst, aber deinen Toggle-Linkunverändert lassen möchtest, nutze diese rein visuelle Ausblendung des Textes (DOM bleibt erhalten):

/* Sicher anzeigen */
.skin-vector-2022 .mw-parser-output .mw-editsection { display: inline !important; }

/* Icons voranstellen */
.skin-vector-2022 .mw-parser-output .mw-editsection a::before {
  display: inline-block;
  vertical-align: middle;
  font-size: 14px;
  line-height: 1;
  margin-right: .25em;
}

/* Icon: VisualEditor-Bearbeiten */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor::before {
  content: "✎";
}

/* Icon: Quelltext bearbeiten */
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"]::before {
  content: "📝";
}

/* Nur bei Bearbeiten-Links den sichtbaren Text ausblenden (für SR bleibt er da) */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor > span,
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"] > span {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

/* Optional: Klammern & Trenner ausblenden */
.skin-vector-2022 .mw-parser-output .mw-editsection .mw-editsection-bracket,
.skin-vector-2022 .mw-parser-output .mw-editsection .mw-editsection-divider {
  display: none;
}

• Toggle-Link (.hidesection-link) bleibt unberührt – Text bleibt sichtbar, damit deine Schlüssel/Logik aus AufEinWortSeiteKennung.js sicher sind.
• Keine modernen Pseudo-Klassen → kein „Expected RPAREN“.

Du:

Mit der neuen Syntaxt fehlt das mittlere IKon und der text ist noch da.

<a href="/Johann_Christoph_Adelung" class="hidesection-all internal" data-show="alle einbleden" data-hide="alle ausblenden" title="Expand or collapse all sections on this page"><span>alle ausblenden</span></a>
<span>alle ausblenden</span>
<a href="/Johann_Christoph_Adelung" class="hidesection-all internal" data-show="alle einbleden" data-hide="alle ausblenden" title="Expand or collapse all sections on this page"><span>alle ausblenden</span></a>
<span class="mw-editsection-divider"> | </span>

ChatGPT:

Nachgedacht

Es scheint, als fehle das mittlere Icon, aber der Text bleibt bestehen. Der Benutzer zeigt den "hidesection-all" Link, der die Steuerung für alle Abschnitte enthält, nicht aber die Bearbeitungslinks. Es könnte sein, dass der Text dupliziert wird, weil ihr Gadget doppelte Elemente injiziert. Es scheint, dass sie den "hidesection-all"-Link zusätzlich außerhalb von "mw-editsection" hinzugefügt haben. Wir müssen sicherstellen, dass wir .hidesection-all korrekt ansprechen und das Icon hinzufügen. Sie möchten die Textanzeige verstecken, aber trotzdem Icons behalten. Wahrscheinlich sollen drei Icons eingefügt werden: Editor, Toggle-Link und Quelltext-Editor. Das Fehlen des mittleren Symbols könnte daran liegen, dass unsere CSS-Regeln nur die .mw-editsection ansprechen. Der „hidesection-all“-Bereich könnte außerhalb liegen, auch wenn er als Anker mit der Klasse „hidesection-all“ in .mw-editsection eingebunden ist. Wir müssen CSS so anpassen, dass es beide Kontexte berücksichtigt. Ebenso könnte der Text weiterhin sichtbar sein, wenn der Benutzer ihn für den „all“-Link und die Bearbeitungslinks auch ausblenden möchte. Die Benutzer wollen keine Änderung an den Funktionalitäten ihres JS, das auf Datenattributen basiert, also können wir die Texte visuell ausblenden, ohne das Verhalten zu beeinflussen. Wir müssen CSS erstellen, das die Icons für „VisualEditor“, „Quelltext bearbeiten“, „hidesection-link“ und „hidesection-all“ anzeigt. Außerdem sollte der Text für Inhaltsverzeichnisse ausgeblendet werden, aber für „Toggle“-Links eventuell zugänglich bleiben. Fertig

Danke für den Schnipsel — damit ist klar: das „mittlere“ Icon gehört zum Link .hidesection-all. Den hatten wir bisher nicht ikonifiziert, und den Text hatten wir nur bei den Bearbeiten-Links versteckt, nicht bei den Toggle-Links.

Füge diese ergänzenden Regeln hinzu (ohne Funktion zu ändern, DOM bleibt gleich):

/* Icon + Text verstecken NUR für die Toggle-Links */
.skin-vector-2022 .mw-parser-output a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output a.hidesection-all::before {
  content: "▾";                 /* Standard: „ausblenden“ */
  display: inline-block;
  vertical-align: middle;
  font-size: 14px;
  line-height: 1;
  margin-right: .25em;
}

/* Per-Abschnitt: wenn eingeklappt, Pfeil nach rechts (sofern dein JS .collapsed setzt) */
.skin-vector-2022 .mw-parser-output h2.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h3.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h4.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h5.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h6.collapsed .mw-editsection a.hidesection-link::before {
  content: "▸";
}

/* Sichtbaren Text der Toggle-Links nur visuell ausblenden (SR bleibt) */
.skin-vector-2022 .mw-parser-output a.hidesection-link > span,
.skin-vector-2022 .mw-parser-output a.hidesection-all  > span {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

/* Falls dein Gadget den Toggle-Text zusätzlich als separates SPAN direkt hinter dem Link ausgibt (wie im Snippet) */
.skin-vector-2022 .mw-parser-output a.hidesection-link + span,
.skin-vector-2022 .mw-parser-output a.hidesection-all  + span {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

Das ergänzt deine bestehende Icon-Logik für VE/Quelltext und sorgt dafür, dass

• das „Alle ausblenden“-Icon erscheint und
• der sichtbare Text (auch der ggf. nachfolgende doppelte <span>…</span>) nur visuell verschwindet.

Du:

Also das neue Coding füge ich im Anschluß an das von zuvor an? oder ersetze ich das Coding damit?

ChatGPT:

Nachgedacht

Die Frage ist, ob die neuen CSS-Regeln an die bestehenden angehängt oder sie ersetzt werden sollen. Eine präzise Antwort wäre, die neuen Regeln hinzuzufügen und dabei die vorherigen beizubehalten. Die Reihenfolge sollte beachtet werden, um die Regeln korrekt zu verketten – neue Regeln kommen einfach am Ende. Alternativ kann auch eine konsolidierte Antwort als ein Block angeboten werden. Die neuen Regeln sollten an den vorherigen Code angehängt werden, da sie nur zusätzliche Selektoren hinzufügen und keine Duplikate erzeugen. Um Konflikte zu vermeiden, sollten sie nach dem vorherigen Block eingefügt werden. Eine konsolidierte, kommentierte CSS-Version könnte hilfreich sein, jedoch ohne zusätzliche Empfehlungen. Kurz: Anhängen. Platziere die neuen Regeln nach den vorherigen, um die Kaskadierung zu gewährleisten. Wenn ein einzelner Block gewünscht wird, hier der kombinierte CSS-Code in der richtigen Reihenfolge: Basis-Display, Symbole für VE & Edit, Symbole für Toggles & ausgeblendete Spans, zusammen mit collapsed Zuständen. Lass den ersten Block unverändert; füge den neuen direkt danach ein, um die Kaskadierung zu gewährleisten. Wenn du bereits einen Block für „Bearbeiten-Icon & Textausblendung“ kopiert hast, belasse ihn. Achte darauf, unerwünschte Duplikate von Selektoren zu vermeiden, aber duplikate sind an sich kein Problem. Wenn du eine konsolidierte Version bevorzugst, hier ist die zusammengefasste CSS. Fertig

Kurz: Anhängen.

Lass deinen bisherigen Icon-Block stehen und füge den neuen Toggle-Block direkt danach ein, damit er in der Kaskade gewinnt. Nichts ersetzen.

Wenn du lieber alles in einem Stück pflegen möchtest, kannst du stattdessen diesen konsolidierten Block verwenden (funktional identisch zu „vorher + Ergänzung“):

/* Vector-2022: Edit-/Toggle-Icons + (wo gewünscht) Text visuell ausblenden */
.skin-vector-2022 .mw-parser-output .mw-editsection {
  display: inline !important; visibility: visible !important; opacity: 1 !important;
}

/* Icon-Basis vor allen Edit-/Toggle-Links */
.skin-vector-2022 .mw-parser-output .mw-editsection a::before {
  display: inline-block; vertical-align: middle; font-size: 14px; line-height: 1; margin-right: .25em;
}

/* Icons für Bearbeiten-Links */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor::before { content: "✎"; }
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"]::before { content: "📝"; }

/* Bearbeiten-Link-Text visuell verstecken (Screenreader behalten ihn) */
.skin-vector-2022 .mw-parser-output .mw-editsection a.mw-editsection-visualeditor > span,
.skin-vector-2022 .mw-parser-output .mw-editsection a[href*="action=edit"] > span {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

/* Icons für deine Toggle-Links (alle/je Abschnitt) */
.skin-vector-2022 .mw-parser-output a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output a.hidesection-all::before {
  content: "▾"; display: inline-block; vertical-align: middle; font-size: 14px; line-height: 1; margin-right: .25em;
}

/* Eingeklappt: Pfeil kippen (wenn dein Gadget .collapsed am Heading setzt) */
.skin-vector-2022 .mw-parser-output h2.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h3.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h4.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h5.collapsed .mw-editsection a.hidesection-link::before,
.skin-vector-2022 .mw-parser-output h6.collapsed .mw-editsection a.hidesection-link::before { content: "▸"; }

/* Toggle-Link-Text (und ggf. direkt folgendes Doppel-Span) visuell verstecken */
.skin-vector-2022 .mw-parser-output a.hidesection-link > span,
.skin-vector-2022 .mw-parser-output a.hidesection-all  > span,
.skin-vector-2022 .mw-parser-output a.hidesection-link + span,
.skin-vector-2022 .mw-parser-output a.hidesection-all  + span {
  position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0;
  overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

Nach dem Einfügen einmal ?action=purge und hart neu laden.

Du:

Danke soweit. Ich teste dies nun auf Nutzbarkeit und Zuverlässigkeit und wenn noch was daran zu ändern ist, melde ich mich hier im Chat. Heute haben wir erreicht, daß mein SMW deutlich angenehmer und lesbarer ist.

Nochmals Danke und wir wenden uns im Anschluß einem Anderen Fall zu.

ChatGPT:

Sehr gern, Nikolaos. Freut mich, dass dein SMW jetzt spürbar lesbarer ist.

Ich halte mich zurück und bin bereit, sobald du den nächsten Fall angehst.