Hilfe Diskussion:CSS/TemplateStyles
Absicht
[Quelltext bearbeiten]Ist das mit dem durchgestrichenen Text im ersten Satz Absicht? Falls ja, verstehe ich es nicht. --mfb (Diskussion) 16:54, 21. Aug. 2017 (CEST)
- Ist Absicht, weil das Feature nicht freigeschaltet ist, aber auf BETA bereits erprobt werden kann.
- Umseitig ist bislang nur über trickreiche Experten-Umwege erreichbar.
- LG --PerfektesChaos 17:04, 21. Aug. 2017 (CEST)
style vs. styles?
[Quelltext bearbeiten]Ich bin gerade bei den ersten TemplateStlyes-Anwendungen darüber gestolpert, dass hier bei der Benennung der CSS-Datei der Name style.css
verwendet wird, während meiner Erfahrung nach im übrigen Web sonst eher die Plural (also styles.css
) üblich ist. MMn wäre der Plural hier logischer, weil in einem CSS-Dokument ja nicht nur ein einzelner Style (also die Formatierung eines einzelnen Elements) sondern viel Selektoren gefolgt von vielen Style-Anweisungen stehen. Ich würde daher vorschlagen umseitig auch die Benennung styles.css
zu empfehlen.
P.S.: Die MediaWiki-Doku ist das auch nicht ganz durchgängig und verwendet style genauso wie styles. // Martin K. (Diskussion) 10:14, 5. Apr. 2018 (CEST)
- Ich kam von mw:Help:TemplateStyles#How does it work? als erstem Einstieg, und da niemand weiß, ob da nur einer oder mehrere drin sind und die Frage recht banal ist, würde ich auch dabei bleiben wollen und es mit diesem Status Quo synchronisiert einheitlich dauerhaft festlegen.
- HTML kennt den
style="color:blue; width: 2em;"
für mehrere Stil-Attribute in einem Singular. - „Der Stil“ einer Seite kann im Deutschen komponiert sein aus vielen Elementen. Ein Stilmischmasch gilt dann eher als Verhunzung.
- VG --PerfektesChaos 13:35, 5. Apr. 2018 (CEST)
- Dass das bei InlineStlyes nötige HTML-Attribute
style
heißt, ist in sofern logisch, als dass sie sich ja nur auf je ein HTML-Element beziehen und eben den Stil (=Aussehen) definieren. Cascading Stylesheets hingegen beziehen sich ja praktisch immer auf mehrere verschiedene Elemente für die sie auch verschiedene Stile definieren (die Elemente sehen ja nicht identisch aus). - Hinzu kommt, dass die Erweiterung selbst ja TempalteStyles heißt und mit
<templatestyles>
(also mit Plural-s) eingebunden wird. Wenn also schon im Einbinde-Tag vom Plural die Rede ist, wäre es doch widersprüchlich auf eine Dokument im Singular zu verlinken, oder? // Martin K. (Diskussion) 14:27, 5. Apr. 2018 (CEST)
- Dass das bei InlineStlyes nötige HTML-Attribute
- Unsere analoge Vorlagen-Unterseite heißt auch
/Test
, und das seit einem Jahrzehnt, obwohl zu mutmaßen wäre, dass dort mehr als nur ein einziger Test vorkäme. - Die unserer Hilfeseite direkt zugeordnete mw:Help:TemplateStyles#How does it work? verwendet diesen Unterseitennamen
/style
. - Unseren Wikipedianern ist
style
aus den Quelltexten der Seiten vertraut. - Es geht auch um den einen einzigen Stil im Bereich der betreffenden Vorlage.
- Das HTML-Element, das die Gesamtheit aller Stildefinitionen einer Seite lädt, formuliert sich, na?
<link rel="stylesheet" href="default.css">
- Es heißt, wie du eigentlich wissen müsstest, Cascading Style Sheets – deiner Theorie nach dürfte Cascading Styles Sheets kein Rotlink sein.
- Es gibt keinerlei triftigen Grund, hier nachträglich alles umzuändern. Wenn zwei Varianten mindestens gleichwertig sind, dann gilt die vorhandene. Wobei noch nicht einmal gesichert ist, dass jeder begreift, warum das Aussehen einer Vorlage mehrere Stile darstellen solle, und dass es überhaupt ein Plural sein solle.
- Es ist irgendwie nicht zu fassen. Wo du neu hinkommst, musst du als allererstes alles ummodeln wollen und deine Duftmarke möglichst hoch an den Baum setzen. Du hattest Monate Zeit gehabt, dich mit der Angelegenheit zu befassen. Jetzt, hinterher, nachdem alles eingetütet ist und die Sache längst rollt, kommst du an und fängst das Rumdiskutieren an, das hätte man ja auch alles ganz anders machen können.
- --PerfektesChaos 15:15, 5. Apr. 2018 (CEST)
- Unsere analoge Vorlagen-Unterseite heißt auch
- Oh, Mann PerfektesChaos Wieso muss eigentlich mit Dir jeder sachliche Vorschlag in einer Endlosdiskussion inkl. persönlicher Angriffe ausarten? An der Haaren herbeigezogen Pseudoargumente inkl.:
Angesichts der Tatsache, dass TemplateStyles hierzuwiki (u.a. dank meiner Initiative) seit nicht mal 2 Tage aktiviert ist, ist z.B. der Vorwurf ich wolle hier „nachträglich alles umändern“ schlicht absurd.
Eingetütet ist hier noch garnichts! Und es wäre schön, wenn Du mal damit aufhören könntest Dich hier wie der Technik-Oberboss der Wikipedia aufzuführen! So einen Boss gibt es in unserem Wiki nämlich nicht! Und Dein grundkonfrontatives Verhalten geht nicht nur mir mittlerweile gehörige auf den Geist. // Martin K. (Diskussion) 17:12, 5. Apr. 2018 (CEST)
- Oh, Mann PerfektesChaos Wieso muss eigentlich mit Dir jeder sachliche Vorschlag in einer Endlosdiskussion inkl. persönlicher Angriffe ausarten? An der Haaren herbeigezogen Pseudoargumente inkl.:
I updated the mw.org documentation to use styles.css (as most wikis seem to have opted for that). FWIW both choices are reasonably common - e.g. Wordpress and Drupal call their main stylesheet style.css, Angular uses styles.css. Once multi-content revisions are stable, we expect styles to live on the same page as the main template anyway. --Tgr (WMF) (Diskussion) 14:26, 6. Apr. 2018 (CEST)
Kompromissvorschlag: stil(e).ksb, Meinungsbild
[Quelltext bearbeiten]Als Kompromiss schlage ich vor: stil.ksb
oder stile.ksb
(.ksb
= kaskadierende Stil-Blätter). Immerhin sind wir ja hier im deutschsprachigen Bereich.
Ich denke mal, da muss ein Meinungsbild her, oder allermindestens ne Umfrage. --2.247.242.145 10:50, 6. Apr. 2018 (CEST)
clwn.fr.brkfst?
// Martin K. (Diskussion) 21:57, 6. Apr. 2018 (CEST)
Workaround .mw-parser-output
[Quelltext bearbeiten]Ich habe gerade umseitig den folgenden Vorschlag entfernt:
„Falls einmal Bereiche des Portalrahmens, der durch Systemnachrichten konfiguriert ist, ebenfalls aus dem Inhaltsbereich dekoriert werden sollten, müsste dies in
<div class="mw-parser-output">...</div>
eingeschlossen werden.“
Ich halte es nämlich nicht für klug, die Klasse .mw-parser-output
zweckzuentfremden, um den Wirkungsbereich von TemplateStyles auszudehnen - zumindest halte ich es nicht für klug das zu empfehlen. Schließlich ist .mw-parser-output
ein ganz grundlegendes Element des MediaWiki-DOM und dürfte von etlichen Tools und Scripten verarbeitet werden. Es ist gut möglich, dass diese kaputt gehen, wenn diese Klasse an Stellen vorkommt, wo sie nicht hingehört. // Martin K. (Diskussion) 21:56, 6. Apr. 2018 (CEST)
Probleme mit .mw-parser-output
[Quelltext bearbeiten]Unabhängig davon, wäre es natürlich gut, wenn es eine Möglichkeit gäbe über .mw-parser-output
hinausgreifende Selektoren zu definieren. U.a. weil es nur so möglich ist, direkt den aktuellen Skin einzubeziehen. So etws wie body.skin-minerva .mw-parser-output .something
sollte irgendwie ermöglicht werden. // Martin K. (Diskussion) 21:56, 6. Apr. 2018 (CEST)
Interaktivität
[Quelltext bearbeiten]Ist mit der neuen Funtionalität sowas wie interaktive Schachbretter möglich? 88.67.115.124 17:51, 5. Mai 2018 (CEST)
- Jein. Mann kann damit einfache Interaktivite Dinge bauen, aber die Grenzen sind schnell erreicht, insbesondere da wir noch diverse alte Browserversionen unterstützen müssen die viele Möglichkeiten noch nicht können (insb. Internet Explorer). Vor allem ist es dafür auch weniger gedacht. -- Michi 14:30, 6. Mai 2018 (CEST)
- Wobei man diese Schachbrettgeschichte, eigentlich browserübergreifend hinbekommen sollte.
- Wenn da Bedarf besteht, könnte man eine entsprechende Vorlage schreiben. // Martin K. (Diskussion) 14:52, 6. Mai 2018 (CEST)
- Klingt gut, könntest du das vielleicht umsetzen? 92.75.192.88 17:04, 6. Mai 2018 (CEST)
- Kann ich machen, wird aber etwas dauern, weil ich z.Z. einfach zu viel um die Ohren habe.
- Es wäre hilfreich, wenn ihr einfach mal als Text runterschreibt, was genau ihr braucht. // Martin K. (Diskussion) 00:35, 7. Mai 2018 (CEST)
- Ok, ich fange mal an die Eckdaten aufzulisten. Es gibt dazu auf en:wp schon einige archivierte Diskussionen, die sich vermutlich auch mit den technischen Aspekten beschäftigen, bei Bedarf kann ich die raussuchen.
- Klingt gut, könntest du das vielleicht umsetzen? 92.75.192.88 17:04, 6. Mai 2018 (CEST)
- Schachbrett, auf Basis von Vorlage:Schachbrett oder zumindest optisch ähnlich
- Die Vorlage soll eine PGN-Datei "schlucken" (siehe obiges Beispiel), also Name der Spieler, sonstige Spielrahmendaten und natürlich die Züge.
- Für den Anfang reichen zwei interaktive Knöpfe, nämlich "Zug vorwärts" und "Zug zurück", die dann jeweils den nächsten Zug ausführen oder den ausgeführten Zug zurücknehmen. Die oben verlinkte Beispielseite ist schon recht umfangreich, das ist ein schönes Ziel für den Endausbau, aber klein anfangen wäre wohl sinnvoller.
- Das wärs eigentlich schon an (Mindest-)Anforderungen. 188.99.183.52 20:02, 7. Mai 2018 (CEST)
- @Martin Kraft: Liest du hier noch mit? 129.206.247.17 12:49, 27. Mai 2018 (CEST)
- Ja schon, aber leider komm ich gerade nicht dazu. Hab einfach zu viel um die Ohren und angesichts der Anforderungen ist das leider nichts, was man mal eben in ein paar Minuten macht.
- Es wird also noch etwas dauern, bis ich Zeit dafür finde. Falls sich vorher jemand anderes dieser Aufgabe annehmen will: Nur zu! // Martin K. (Diskussion) 21:29, 27. Mai 2018 (CEST)
- @Martin Kraft:: Wie sieht es mittlerweile aus? Es ist leider schon mehr als ein Jahr vergangen... 178.10.54.238 11:17, 24. Aug. 2019 (CEST)
- Leider haben sich bei mir die ehrenamtlichen Tätigkeiten in den letzten Monaten etwas umgeschichtet, so dass ich hier on-wiki wirklich nur noch zum nötigsten komme. Und da da andere Dinge (z.B. WLM deutlich dringender sind) befürchte ich, dass ich auf absehbare Zeit nicht dazu kommen werde, mich intensiver mit einer Vorlagenumsetzung Deines Vorschlags zu beschäftigen. Tut mir leid.
- Wenn Sie irgendjemand anderes daran versuchen will: Nur zu! // Martin K. (Diskussion) 11:55, 25. Aug. 2019 (CEST)
- @Martin Kraft:: Wie sieht es mittlerweile aus? Es ist leider schon mehr als ein Jahr vergangen... 178.10.54.238 11:17, 24. Aug. 2019 (CEST)
Hie fehlt scheinbar überall etwas mit der Endung .css
Zumindest ist überall eine rote Vorlage angegeben
Dort ist eine Meldung – Die Seite … muss das Inhaltsmodell „Bereinigtes CSS“ für TemplateStyles haben. Das aktuelle Modell ist „CSS“.
Kann das jemand reparieren? --Liebe Grüße, Lómelinde Diskussion 13:11, 22. Mär. 2019 (CET)
- Rätselhaft. Vorlage:Person/styles.css wäre diejenige, die einzubinden wäre, das klappt auch. Warum dieser Seitenname Vorlage:Person.css und wodurch ausgelöst, sehe ich momentan nicht. Wenn die /Doku schuld sein sollte, müsste das Dutzende von Seiten auslösen. Ich denke. LG --PerfektesChaos 13:22, 22. Mär. 2019 (CET)
- Dankeschön. --Liebe Grüße, Lómelinde Diskussion 14:59, 22. Mär. 2019 (CET)
- Oh, wie banal! Danke fürs Bescheidgeben --PerfektesChaos 15:14, 22. Mär. 2019 (CET)
Ab wann sinnvoll
[Quelltext bearbeiten]Ab welcher "Menge" von css-Anweisungen ist es sinnvoll, eine separate css-Unterseite anzulegen? Z. B. für die Vorlage:Infobox Schachspieler könnte man unter anderem die Anweisungen style="border: 1px solid #000000; font-size: 85%; max-width: 310px; line-height: 1.5;"
auslagern. Wäre das performance-technisch besser? 147.142.70.122 14:50, 4. Nov. 2019 (CET)
- Wenn es nur um einen einzigen Inline-Style für ein einzelnes Element geht, lohnt sich das nicht wirklich. Allerdings können TemplateStyles ja viel mehr als Inline-Styles. Wenn man die InfoBox also mal grundsätzlich gestalterisch überarbeiten würde, könnte das schon Sinn machen. // Martin K. (Diskussion) 15:00, 4. Nov. 2019 (CET)
- Die Anzahl oder der Umfang der Deklarationen spielt keine Rolle, sofern diese wirklich sinnvoll sind.
- Sinnvoll und notwendig sind sie immer dann, wenn die CSS-Syntax etwa Pseudoklassen oder Abhängigkeit von den Eigenschaften des Gerätes beim momentanen Leser betreffen soll, und derartige CSS-Syntax nicht inline als
style=
realisiert werden kann. - Auslagerung von statischen Inline-Styles, die erfolgreich nur einem einzigen bekannten Element zugewiesen sind, wie in dem beschriebenen Fall, ist praktisch niemals sinnvoll.
- Statische Inline-Styles auszulagern wäre nur sinnvoll, wenn diejenigen Elemente, die etwa eine Klasse als Selektor erhalten würden, vorher nicht bekannt sind oder aber in einer sehr großen Zahl auftreten würden, und/oder auch als realistisch anzunehmen wäre, dass Benutzer diese Eigenschaften individuell konfigurieren würden.
- Nichts von alledem trifft auf die beschriebene Infobox zu. Sie ist das einzige Element auf der Seite mit diesen Eigenschaften, alle Eigenschaften sind wie schon seit langer Zeit diesem Element per
style=
zugeordnet, und sie von dort wegzunehmen und umständlich über den TemplateStyles-Mechanismus wieder auf dasselbe einsame Element zurückwirken zu lassen stiftet nur Verwirrung, hindert die anderen Bearbeiter an der nachvollziehbaren Pflege, kostet Performance und hat absolut null Vorteile.
- VG --PerfektesChaos 17:33, 4. Nov. 2019 (CET)
Dokuseite in Modul-Namensraum
[Quelltext bearbeiten]Nachdem mit phab:T200914 die TemplateStyles auch explizit für den Modul-Namensraum vorgesehen wurden, würde ich aus organisatorischen Gründen die Vorlage:Charttabelle/styles.css zum Jahreswechsel gerne nach Modul:Musikcharts/styles.css verlagern (habe ich auch Testwiki schon gemacht). Ich bin mir jetzt aber unsicher, was das für die Dokuseite bedeutet; als Modul-Unterseite kann ich die ja vom ContentModel her schlecht speichern. Soll sie dann sinnvollerweise nach Wikipedia:Lua/Modul/Musikcharts/styles? Gruß–XanonymusX (Diskussion) 01:08, 27. Nov. 2019 (CET)
- „explizit für den Modul-Namensraum“ beträfe andere Wikis, bei denen Seiten aller Art im Modul-Namensraum liegen dürfen.
- Bei uns wurde 2013 festgelegt, dass sich ausschließlich Lua-Quellcode dort zu befinden habe, plus je eine einzige (vorzugsweise WL-) Seite in Wikitext.
- Sonst würden alle Testseiten, Hintergrundinfos usw. da auch rumfliegen.
- Etwa alle diese usw., gemischt mit jenen.
- Da es keine Endung
.lua
wie.js
,.css
,.json
gibt, lässt sich bei Auflistungen auch nicht erschließen, was jetzt was wäre.
- Deshalb: Variante 2.), Wikipedia:Lua/Modul/Musikcharts/styles usw. wie sonst auch.
- Wenn nicht Vorlage, dann darf der TemplateStyles-Kram genauso in einem Portal oder unterhalb eines WikiProjektes unter Wikipedia: liegen; braucht nur einmal kurz WP:A/A.
- Da es kein Autor in einen Artikel zu tippen hat, sondern es nur einmalig in eine Programmierung per C&P eingefügt wird, stört auch ein längerer Seitenname nicht.
- „explizit für den Modul-Namensraum“ beträfe andere Wikis, bei denen Seiten aller Art im Modul-Namensraum liegen dürfen.
- Da du mir grad unter die Augen kommst, hätte ich gern italienische Revanche:
- commons:Data:I18n/01.tab
- Würde man im Italienischen
Ja
als Vorlagenparameterwert auch mit s abkürzen? Dann bitte nach Pipe ergänzen. - Sonstige Sprachen geläufig?
- Würde man im Italienischen
- Hier hätte ich gern einen Einleitungsabschnitt.
- Wenn du in Modul:WikidataScheme/demo die
???
noch ersetzen würdest, sähe die vorstehend angegebene Seite noch schicker aus.
- Wenn du in Modul:WikidataScheme/demo die
- commons:Data:I18n/01.tab
- LG --PerfektesChaos 14:54, 27. Nov. 2019 (CET)
- Verstehe, dann werde ich also künftig wohl Wikipedia:Lua/Modul/Musikcharts/styles.css und Wikipedia:Lua/Modul/Musikcharts/styles pflegen.
- Die Übersetzungen muss ich mir noch überlegen, die idealen technischen Formulierungen fallen mir grad nicht ein.
- Gruß–XanonymusX (Diskussion) 15:52, 27. Nov. 2019 (CET)
Verschachtelung – Frage
[Quelltext bearbeiten]Moin zusammen, ich habe fürs Lokal K einen Style erstellt:
Dieser soll zunächst für Selektoren, die ich in Wikipedia:Lokal K/Tab verwende, gelten. Mein Verständnis der umseitigen Doku ist, dass es genügen würde, wenn ich die Einbindung nun in der umgebenden Elternvorlage Wikipedia:Lokal K/Oben vornehmen würde, so dass sie nur einmal eingebunden wird, aber für jede Einbindung von Wikipedia:Lokal K/Tab gilt. Leider scheint dies nicht zu glücken, so dass ich die Anweisung
<templatestyles src="Wikipedia:Lokal K/styles.css" />
jetzt wieder in Wikipedia:Lokal K/Tab eingebunden habe - was natürlich zu sehr unschönem, redundanten Markup führt. Gepurged habe ich natürlich, bis die Finger bluten ;-) Habe ich die Funktionsweise falsch verstanden oder einen Denkfehler bei der Umsetzung? Danke für einen Hinweis. --elya (Diskussion) 11:48, 30. Nov. 2019 (CET)
- Soweit ich das überblicken kann, hast du seitens TemplateStyles alles richtig gemacht.
- Insbesondere hast du dir das Content Model geändert, was der typische Anfängerfehler gewesen wäre.
- In jeder eingebundenen Seite, die von den Klassen Gebrauch machen möchte, sollte oben das
<templatestyles />
eingebunden werden; egal wie oft insgesamt pro Seite, es wird ohnehin zurzeit nur ein einziges Mal inhaltlich wirksam. - Dann fluppt das auch. So wie du es halt definiert hast.
- Ich hätte gern, dass der charakteristische Code
LocalK-
lautet, damit auch ich ihn verstehe. Für mich sähe das zurzeit nach low-kalk aus oder so. Es ist mir völlig wurscht, ob der Rest des Planeten alle Bezeichner klein schreibt; dies ist irrelevant. Jedoch lässt sich an den Großbuchstaben sofort ablesen, dass dies hiesiges Zeugs ist und nicht von MediaWiki kommen kann. - Es fehlt noch die Doku-Seite; siehe Portal:Rudern/styles als eines der vorbildlichen Beispiele, damit auch deine Nachfolger noch durchsteigen, was das alles werden sollte.
- Rein dekorative
style=
die nur an einem einzigen Element dranhängen und nicht systematisch modifiziert werden, würde ich übrigens belassen; diese können von jedem Bearbeiter weiterhin wie gewohnt angepasst werden, ohne dass erst eine Werkstattanfrage erforderlich würde. - Ob alle deine kürzlichen Umformulierungen auf den Meta-Seiten die sachliche Richtigkeit beibehielten überschaue ich grad nicht.
- LG --PerfektesChaos 15:57, 30. Nov. 2019 (CET)
- Hi PerfektesChaos, danke erst mal für die Hinweise. Hab inzwischen auch gesehen, dass es so wirkt, wie ich es mir vorstelle. Doku habe ich angelegt. Beste Grüße --elya (Diskussion) 13:55, 1. Dez. 2019 (CET)
Kategorisierung und Sichtung
[Quelltext bearbeiten]Hallo! Zwei organisatorische Fragen:
- Es gibt Kategorie:Vorlage:TemplateStyles. Sollen TemplateStyles-Dokuseiten in anderen Namensräumen überhaupt nicht kategorisiert werden oder gibt es dazu was eigenes? Außerdem ist es etwas irritierend, dass Stylesheets im VNR von HotCat offenbar ignoriert werden, solche in anderen Namensräumen hingegen nicht; ist das so gewollt?
- Seit ich mein Charts-Stylesheet unter Wikipedia:Lua/Modul/Musikcharts/styles.css liegen habe, scheint sich etwas im Zusammenhang mit dem Sichten geändert zu haben; nach jeder Änderung bekomme ich jetzt von sämtlichen betroffenen Seiten (und das sind nicht wenige) die Mitteilung „Vorlagen- und Dateiänderungen dieser Version sind noch nicht markiert.“ Habe ich das vorher nur aus unerfindlichen Gründen nicht mitbekommen oder ist das ein Effekt, der so nur in dieser Konstellation vorkommt?
Gruß–XanonymusX (Diskussion) 23:37, 9. Jan. 2020 (CET)
- Generell ist zu organisatorischen Angelegenheiten der deWP eher der WP-NR zuständig.
- Zu Kategorie:
- Die Angelegenheit ist vorrangig für Vorlagen gedacht, deshalb heißt sie TemplateStyles.
- Dementsprechend gibt es auch nur eine Vorlagen-Kat.
- Es gibt 43 Styles für Vorlagen sowie 10 in anderen Namensräumen.
- Ich kenne nur eine Vorlagen-Kat und fühle mich nur dafür zuständig. Wie das restliche Projekt in Portalen usw. sein CSS zu managen wünscht und welche Kats dafür greifen würden, weiß ich nicht.
- Die Software heißt halt nicht FreeStyles oder AllStyles.
- Zu Sichtung:
- Vorlagen-NR ist einer der Sichtungsnamensräume und sichten sich dort selbst nach Bearbeitung.
- In den Modul-Namensraum gehört ausschließlich Lua-Code, mit je einer Seite Wikisyntax zur Generierung von Verlinkungen auf den Rest an sonstigen Seiten.
- Meines Wissens reicht es, wenn du zu WPNR-TemplateStyles die in Sichtungsnamensräumen automatisch vorgenommene Sichtung ein einziges Mal dann diese Sichtung auf irgendeiner einbindenden Seite nachholst.
- Weil WPNR kein Sichtungsnamensraum ist, bietet die reguläre Software dort keine derartigen Möglichkeiten an. Könnte vermutlich per Gadget als Automatismus beim Speichern eines solchen Content Model vollautomatisch veranlasst werden, falls abspeichernder User Sichterrechte hätte. Wird aber wohl niemand Lust dazu haben.
- Gedacht ist es so, dass du nach gründlicher Erprobung auf BETA alle paar Wochen oder Monate mal ein neues Feature einbaust; die meisten TemplateStyles sind nach initialer Erstellung niemals wieder verändert worden. Insofern ist dann eine nachgeholte manuelle Sichtung zu überleben.
- Du kannst es natürlich an Vorlage:Charts anbamseln; es braucht halt eine thematisch passende Hauptvorlage, und beliebig viele andere Vorlagen können sich die Styles dann ausborgen. Geht halt organisatorisch nicht anders, wenn ein und dieselbe TemplateStyles-Definition sich auf mehr als genau eine Vorlage auswirken sollen.
- Zu Kategorie:
- LG --PerfektesChaos 01:50, 10. Jan. 2020 (CET)
- Ach ja, Sichtungsnamensräume … Alles, was mit Sichten zu tun hat, wurde von der Softwareabteilung schon viel zu lange schleifen gelassen, da wird erst mal nichts kommen, auch wenn die Priorität von phab:T185664 immerhin auf high gesetzt wurde. Werde ich hoffentlich auch so in den Griff bekommen. Hab jetzt einfach mal die Kategorie:Wikipedia:TemplateStyles angelegt und manuell reingesetzt, die paar Fälle im PNR bleiben freilich immer noch unkategorisiert. Könnte man natürlich auch über die Vorlage automatisieren, muss aber nicht sein. Gruß–XanonymusX (Diskussion) 12:50, 10. Jan. 2020 (CET)
- Die Vorlagen dienen mehr oder weniger projektweiten Zwecken und erhalten eine Grundbetreuung durch die Vorlagenwerkstatt.
- Aus diesem Grund sind sie nach diversen Eigenschaften und Einschränkungen kategorisiert, um Anpassungen der Programmierung sowie die ordnungsgemäße Verwendung zu überwachen und die Pflege durch die VWS zu organisieren.
- Was irgendwelche Lokale, Portale und WikiProjekte auf ihren Projektseiten anstellen, interessiert die VWS nicht und will damit auch nichts weiter zu tun haben, und es auch nicht im projektweiten Vorlagen-Namensraum pflegen müssen.
- Die zentrale Stelle zur Überwachung der TemplateStyles ist Wikipedia:Technik/Skin/CSS/TemplateStyles #Liste vergebener Bezeichner, um die Kollisionsfreiheit zu organisieren.
- Ansonsten gibt es keine Wartung und Pflege dazu.
- Über Spezial:Linkliste/Vorlage:Dokumentation/styleSeite werden alle ordnungsgemäßen Seiten aufgelistet; lassen sich notfalls per Cirrus-Suche nach
contentmodel:sanitized-css
aufspüren. - Meta-Seiten wurden bisher noch nie nach ihren technischen Besonderheiten kategorisiert.
- LG --PerfektesChaos 14:03, 10. Jan. 2020 (CET)
Eingrenzung auf die Vorlage
[Quelltext bearbeiten]Meines Erachtens gäbe es schon eine Möglichkeit, die Wirkung außerhalb der Vorlageneinbindung zu verhindern: Alle Stildefinitionen von Vorlage:Dingens/styles.css
bekommen neben der Klasse .mw-parser-output
zusätzlich noch .mw-template-dingens
und die expandierte Vorlage enthält für alle Elemente diese Klasse. Damit würde standardmäßig nur innerhalb der expandierten Vorlage der Selektor passen. Kann doch nicht so schwer sein, das einzubauen. Die damit noch vorhandene Option, die CSS-Klasse gezielt außerhalb zu verwenden, ist m. E. kein großes Risiko. ÅñŧóñŜûŝî (Ð) 22:20, 27. Jul. 2022 (CEST)
- Schlichtweg: Nein.
- „die expandierte Vorlage enthält für alle Elemente diese Klasse“ – „expandierte Vorlage“ ist ein Konstrukt der Wikisyntax, und keine Einheit des HTML-Dokuments.
- „expandierte Vorlage“ kann jedes beliebige Stückchen Wikitext sein.
- Nirgendwo ist in der MediaWiki-Syntax verlangt, dass die Grenzen einer „expandierte Vorlage“ identisch mit genau einem HTML-Element <div> oder <span> oder sonstwas sein müssen.
- „expandierte Vorlage“ kann auch nur Bestandteile eines Elements oder auch nur eines Tags liefern.
- Die entstehenden Selektoren wären auch kein Geheimnis, und jeder kann sie nach Belieben auch auf andere Elemente anwenden, und sofort ist dein niedlicher Begrenzungsplan am Ende.
- Außerdem ist deine Idee absolut nicht wünschenswert, denn die TemplateStyles werden längst nicht nur auf den Inhalt von „expandierte Vorlage“ angewendet, sondern sie ermöglichen eine Spezifikation von CSS-Klassen und nicht-inline-style-fähigen Deklarationen, die nicht mehr wie bisher auf alle Dutzende von Millionen unterschiedlicher Seiten und Spezialseiten einwirken müssen, sondern nur auf einige hundert oder tausend Seiten, in denen genau diese Spezifikationen tatsächlich verwendet werden. Und zwar auch außerhalb einer „expandierte Vorlage“.
- Es bleibt der jeweiligen Konzeption überlassen, welche Selektoren wie treffsicher definiert werden und welche Elemente damit ausgestattet würden, egal wo.
- Wenn diese Selektoren außerhalb von „expandierte Vorlage“ zugewiesen werden, dann lässt es sich HTML-technisch schlicht nicht verhindern, dass auch darauf eingewirkt werden würde.
- „Kann doch nicht so schwer sein, das einzubauen.“ – Das geht schlicht und einfach nicht.
- VG --PerfektesChaos 23:18, 27. Jul. 2022 (CEST)
- Jede Nutzung von TemplateStyles kann logischerweise nicht bei einem reinen Text als Rückgabe wirken, sondern nur bei (erzeugten) HTML-Elementen. Das ist also kein Argument.
- Es gibt überhaupt keinen Grund, aus den Selektoren ein Geheimnis zu machen. Wer das gezielt außerhalb nutzt, der macht nichts, was er nicht auch bisher schon kann.
- ÅñŧóñŜûŝî (Ð) 23:45, 27. Jul. 2022 (CEST)