Kein moderner, richtig programmierter Browser benötigt noch ein LRM, wie man das im letzten Jahrhundert noch gemacht hatte.
Seit einem Jahrzehnt wird mit den <bdo> und <bdi> gearbeitet, sowie ggf. mit der einshlägigen CSS-Eigenschaft.
Die RLM (völlig überflüssig) und LRM, die du da soeben eingefügt hast, werden beim Kopieren von den Benutzern durch unsere Artikel verschleppt, und richten dort unsichtbar großen Schaden an unserer sonstigen Syntax an.
Im Übrigen ist deine Änderung zu dem Zweck, den du dir vorstellst und den ich dunkel erahne, absolut untauglich und ändert rein gar nichts.
Wenn du Experimente mit bestimmten Browsern machen möchtest, dann bitte nicht an unseren realen Artikeln und bei einer zigtausendfach eingebundenen Vorlage, sondern bemühe dich bitte nach WP:BETA. Dort wird das zunächst ausprobiert und mit den Browsern an Testbeispielen erprobt, und erst hinterher kommt das Endergebnis hierher in die produktive Vorlage.
Im Übrigen würde ich gern präzise dargelegt bekommen, was genau unter welchen Umständen mit welchem Browser nicht funktioniert, und welche andere Kombination der <bdo> und <bdi> für alle gegenwärtigen Browser geeignet wäre.
Die Experimente machen wir also vorher auf BETA, und bis dahin revertiere ich deine sprachlich wirkungslose und für den Artikelbestand schädliche Änderung.
Wenn ich im Browser Editor mit den CSS-Einstellungen spiele, dann scheint es an dem unicode-bidi zu liegen. Bei der derzeit verwendeten Variante embed wird es in meinem Browser(Chrome 53) falsch dargestellt. Aber bei normal und co. nicht. @PerfektesChaos: --Ar-ras (D) 16:52, 15. Okt. 2016 (CEST)Beantworten
Das ist doch eine Erkenntnis; du meinst also, von der CSS-Eigenschaft unicode-bidi:embed würde Chrome zuviel kriegen und abdrehen? Wenn die anderen Browser das nicht benötigen, dann wäre genau dies zu eliminieren. Damit murksen wir aber nicht hier rum, sondern auf BETA. VG --PerfektesChaos16:56, 15. Okt. 2016 (CEST)Beantworten
Ich bin selber Softwareentwickler und musste zu Ausbildungszeiten auch an Websiten schrauben. Ich bitte um bisschen mehr kollegialen Respekt.
Meine weiteren Recherchen haben ergeben, dass der Chrome-Browser hierbei mit dem bdo-Tag Probleme hat, weil dieser ja ein Inline-Element ist. Ändert man es explizit zu display:inline-block, dann rendert der Chrome-Browser auch den Inhalt korrekt. Die Lösung gefällt mir nicht, da es ja nicht gewünscht sein kann dies durch inline-block die Darstellung des Fließtextes zu korrigieren. Also habe ich als nächstes dem bdi-Tag den CSS-Style unicode-bidi: embed gegeben. Dadurch wird die Anzeige korrigiert.
Entfernt man aber gleichzeitig die unicode-bidi Anweisung vom bdo-Tag, dann führt das dazu dass es automatisch die unicode-bidi:bidi-override erbt. Es sieht aber in meinem Browser weiterhin korrekt aus. Aber um mögliche Fehler zu vermeiden, sollte es natürlich weiterhin dort bleiben.
Ich habe das Gefühl, dass du hier mit zweierlei Maß misst. Fakt ist, dass du bereits im "blinden" gestochert hast [3] und mir jetzt für die Änderung massive Steine auf den Weg legst. Ich muss mE keine Vorarbeiten dir vorlegen, damit du dann irgendwas am Wochenende rumbasteln kannst. Ich habe mE schon dir genug vorgelegt, in dem ich auf beta das bearbeitet habe und dir die Links bereitgestellt habe.
Also ich habe das Problem bereits abschließend analysiert und per Screenshot belegt. Ich wiederhole: Das Problem liegt darin, dass der Chrome 53 dem bdo-Element für den CSS-Befehl unicode-bidi den Standardwert-webkit-isolate vergibt. Andere Browser stellen keinen Default-Wert an, sodass man davon ausgehen muss, dass der Standardwert für unicode-bidi in den unproblematischen Browsern mit "normal" belegt ist. Also entweder setzt man für unicode-bidi im bdi-Tag den Wert "normal" oder "embed".
Schlussendlich: Dein Vorschlag das ganze auf beta zu verschieben ist mE auch nicht wikikonform.
Standardwert für das bdi-Element ist im IE 11 "embed", im FF 49 "-moz-isolate", im Opera 40 "isolate", im Chrome 49 "-webkit-isolate".
In diesen 4 Browsern habe ich dem bdi-Element den CSS-Befehl "unicode-bidi: embed" gesetzt. In diesen 4 Browsern wurde danach der Text korrekt dargestellt. --Ar-ras (D) 18:38, 15. Okt. 2016 (CEST)Beantworten
Nein, du hast noch nicht alles Erforderliche getan, da zwei wesentliche Nachweise bislang nicht erbracht wurden:
Der UBA wird auch weiterhin von Chrome und allen anderen Browsern gestoppt.
Alle anderen (greifbaren) Browser haben keine Probleme mit deiner Änderung.
Du hast bislang nur dargelegt, dass dieses Verbindeproblem dann bei Chrome nicht mehr auftreten würde; zu den Nebenwirkungen hingegen nichts.
Da ich die Schrift nicht lesen kann und sich die Arabisch sprechenden Herrschaften seit Monaten weigern, die Werte der UCS für fünf Buchstaben herauszurücken, bleibt es dann eben jetzt alles so wie es ist.
Was deine Darlegungen zum BETA-Wiki angeht, so bist du wohl kaum der Richtige, um dies zu beurteilen. Die Testwikis, und insbesondere das deutschsprachige Beta, sind exakt zu dem Zweck angelegt worden, um neue Software, einschließlich Vorlagen und Lua, zunächst auf einer deutschsprachigen Spielwiese zu erproben, die bei Bedarf die erforderliche Umgebung der deWP exakt simulieren kann.
Erst wenn alles störungsfrei funktioniert und keine Nebenwirkungen mehr beobachtet werden, geht es mit dem fertigen Code zurück in die produktive Wikipedia.
An 18870 weltöffentlichen Seiten der Enzyklopädie zu experimentieren und sie bei jeder Veränderung neu generieren zu lassen, so wie du das heute nachmittag versucht hattest, machte man vielleicht vor zehn Jahren mal; heutzutage jedoch nicht mehr.
Wie ich bereits dargelegt habe, kocht jeder Browser hier sein eigenes Süppchen, wobei der IE 11 den einzig richtigen Wert verwendet (embed) und die restlichen Browser keine standardisierten CSS-Werte verwenden (isolate/-webkit-isolate/-moz-isolate ist experimental und nicht standardisiert).
Wofür steht UBA und UCS? Use Case Szenario?
Wo ist eigentlich dein Test-Case als du im Mai die Änderungen durchgeführt hast? Wenn du das mir zeigst, dann kann ich gerne daran anknüpfen und den benötigten Text hinzufügen. --Ar-ras (D) 19:03, 15. Okt. 2016 (CEST)Beantworten
Jigal Naor, darin war vorher ein "lrm" und im editor wurde es dann falsch dargestellt, wenn man es entfernt hat. Liegt u.a. daran, dass als nächstes Zeichen ein Zeichen und kein Buchstabe kommt und er es nicht erkennen kann. Unabhängig hiervon geht durch die Einfügung von unicode-bidi:embed die Darstellung im gerenderten Artikel kaputt. Die wäre bei einem direkten Fokus nur auf die arabische Schrift untergegangen. Für hebräische Schrift scheint "unicode-bidi: isolate" zu passen. Es wäre jedoch ggf. sinnvoll die nbsp-Entität ggü. der rlm-Entität zu ersetzen und in den Vorlagen zu HeS etc. zu empfehlen diese nach den geschweiften Klammern zu setzen. Es wäre ggf. sinnvoller in den sprachspezifischen CSS-Klassen entsprechend den CSS-Code zu setzen (und nicht in den Style-Werten) und so selektiv die Darstellung zu korrigieren und auch ohne 50.000 Artikel beinflussen zu müssen. --Ar-ras (D)
„Liegt u.a. daran, dass als nächstes Zeichen ein Zeichen und kein Buchstabe kommt und er es nicht erkennen kann“
Den muss deine erprobte Lösung natürlich abgedeckt haben; genauer gesagt: Die noch zu erarbeitende mit allen Browsern kompatible Lösung.
Ich weise zum wiederholten Mal darauf hin, dass ich die arabischen Schriftzeichen nicht lesen kann.
Wenn ihr euch standhaft weigert, die fünf Unicode-Zeichenwerte in Schreibrichtung mitzuliefern, kann ich auch nicht weiter tätig werden, da ich die Zeichen nicht schreiben kann und noch nicht einmal nachvollziehen kann, wo im Quelltext links und rechts wäre.
Aus dem gleichen Grund kann ich auch nicht sehen, wann wo etwas falsch oder richtig wäre, wenn nicht unabhängig von der verschrifteten Textfolge eine Grafik mitgeliefert wird, bzw. zwei, auf denen zu erkennen ist, was richtig und was falsch ist, und zwar mit minimierter Extra-Kalligrafie.
Zu dieser Vorlage hier muss eine Testseite erstellt werden, auf der man mit einem Blick abgleichen kann, wie auf welchem Browser was dargestellt wird. RTL machen seit vielen Jahren Probleme, und seit vor ein paar Jahren die gängigen Browser UBA realisiert hatten, werden unsere alten Artikel geschrotet.
Es muss nur zu Weihnachten ein neues Samsung rauskommen, mit explosionsgeschütztem Browser, und dann geht das Theater von vorn los. Deshalb brauchen wir eine Testseite mit bekannter Codefolge und grafischer Referenz.
Wir bauen im Gegenteil den CSS-Code von unseren über 10 Millionen Seiten ab. Das heißt, wir werden sicher nicht für knapp 5.000 von 10.000.000 Seiten mit hebräischen Schriftzeichen, also für 0,05 % Trefferquote jede Seite mit CSS-Regeln belästigen; arabisch ist knapp dreimal so viel und kommt auch noch nicht mal an ein Prozent heran.
Achja, und UCS ist nach UCS nichts anderes als der nackte, nicht encodierte Zahlenwert von Unicode; also das, was in deren Welt “Codepoint” genannt wird. UCS=41 = U+0041 = A und UCS=620 ↔ ARABIC LETTER KASHMIRI YEH.
Datei:Khan rtl error comp.pngoben falsch gebunden, unten richtig gebundenEs nützt aber nix, wenn dein Browser den Fehler nicht darstellt. Dann kann ich dir auch die "fünf Unicode-Zeichenwerte" geben, und trotzdem wirst du den Fehler nicht sehen. Für arabisch خان kann ich jetzt nur folgendes خان geben.
Der Witz ist doch, dass bereits jetzt CSS-Klassen verwendet werden. Siehe screenshot. Wenn diese keinen Sinn haben, dann wäre es ja nach deiner Logik sinnvoll diese zu löschen. --Ar-ras (D) 01:41, 16. Okt. 2016 (CEST)Beantworten
Ich habe heute auf meinem Handy auch geprüft wie der arabische Text dargestellt wird. Im normalen Android-Browser und im Chrome wird es auch falsch dargestellt. Im Android Firefox-Browser wird es korrekt dargestellt Soviele Optionen haben wir eigentlich nicht wenn wir das per CSS korrigieren wollen. --Ar-ras (D) 14:19, 16. Okt. 2016 (CEST)Beantworten
Uff. Nach Monaten: 158210 157510 160610.
Wenn ich nach diesem ganzen Aufstand gelegentlich wieder Nerven habe, werde ich eine Testseite mit den Varianten bauen.
Nun bräuchte es nur noch fokussierte lateinertaugliche Grafik-Ausschnitte, wie es richtig dargestellt wird und wie es falsch sei. Optisch sehen kann ich ja was, ich weiß nur nicht was, geschweige denn ob falsch oder richtig.
Dass Chrome mit Zeichenketten Mist baut, ist nichts Ungewöhnliches:
Wenn sich Opera dem Problem anschließt, dann ist das nicht unerwartet; ich glaube Opera 12 war der letzte mit eigener Software, und in den höheren Nummern ist das nur noch ein Google-Chrome mit einem Kern an Chromium-Software, aber einem Opera-Aufkleber auf der Benutzeroberfläche. Für Benutzer, die Google nicht mögen.
Auf meinem Screenshot: oben falsch, unten richtig. Ich habe nochmal im IE11, FF und Chrome geprüft und ein display:inline-block in den bdi-Tag korrigiert das arabische ohne das hebräische zu zerschießen. Finde grad nicht den aktuellen Safari um das zu testen. Safari verwendet doch noch weiteren Webkit oder? Kann also gut sein, dass es auch den Darstellungsfehler hat. Ich würde offen gesagt empfehlen die CSS-Anweisungen in das Stylesheet zu übernehmen und die CSS-Style-Angaben in den Tags zu entfernen. Dann müssen auch nicht abertausende Artikel immer wieder bearbeitet werden. Weißt du wer CSS-Dateien bearbeiten kann?--Ar-ras (D) 15:21, 16. Okt. 2016 (CEST)Beantworten
Ich schrieb es bereits: Da die CSS-Stile ausschließlich auf die Stellen wirken würden, wo in vielleicht mal 20.000 Seiten diese Vorlage eingebunden ist, werden wir sicher nicht zehn Millionen Seiten damit belästigen.
Es ist völlig egal, ob der Stil über eine Klassen-Definition allen Elementen dieser Klasse aufgeprägt wird, oder ob dies dann inline in den fraglichen Elementen geschieht.
Ja, ich weiß, wer wo wie projektweite CSS-Definitionen bearbeitet, aber das wird man aus vorgenannten Gründen nicht machen.
Es werden nicht „abertausende Artikel immer wieder bearbeitet“. Es wird ein einziges Mal die erprobte Endfassung hierher von BETA übertragen, und das ist hier Tagesgeschäft. Ich werde wahrscheinlich heute eine derartige Änderung mit Wirkung auf 150.000 Artikel einspielen, und mache sowas laufend.
„Wir“ sind diejenigen, die sich um die Technik dieser Wikipedia und ihre Effizienz und Robustheit kümmern, und dabei bestimmte langjährige Strategien verfolgen, und ich bin ein kleines Lichtlein davon. --PerfektesChaos16:32, 16. Okt. 2016 (CEST)Beantworten
So, ich beginne mit einer kleinen Einführungsvorlesung in Sachen arabische Schrift: Die Buchstaben existieren in der Regel in vier Erscheinungsformen, die je nach Position im Wort verwendet werden. Es gibt eine isolierte (nicht verbundene) Form, eine initiale (nach links verbundene), eine mediale (nach beiden Seiten verbunden) und eine finale (von rechts verbunden). Bei manchen Zeichen gibt es nur finale und isolierte Formen, nach einem solchen Zeichen, das nicht am Wortende steht, kommt eine initiale oder finale Form, ohne "Leerzeichen" dazwischen. (Dies erklärt auch, warum der Bug nicht bei allen Worten auftritt: Bei solchen, die mit einem Buchstaben beginnen, der ohnehin nicht nach links verbunden werden kann, fällt es logischerweise nicht auf, wenn die nicht gemacht wird)
„Katar“ in arabischer Schrift: قطر. In der SVG-Grafik ohne Bug
Beim Beispielwort „Katar“ (قطر) haben wir es mit drei Zeichen zu tun, da die kurzen Vokale nicht gekennzeichnet sind. Wesentlich im Schriftbild: Der erste Buchstabe (rechts) lässt sich grob als "9" beschreiben mit zwei Punkten drüber, der untere Teil der "9" geht in die Grundlinie über, auf der eine Art Tropfen schräg liegt, aus dem nach oben ein Strich emporragt. Die Grundlinie geht noch ein Stückchen weiter, bis zu einem (zirka) Drittelkreisbogen, dessen oberster Teil leicht über der Grundlinie liegt. Der Bug bei Google Chrome liegt darin, dass die Grundlinie nicht alle drei Buchstaben verbindet, sondern nur die zwei hinteren. Da der erste Buchstabe aber einer derjenigen ist, die alle vier Erscheinungsformen haben, muss zwischen erstem und zweitem Buchstaben eine Verbindung über die Grundlinie hergestellt sein. Dieser Fehler ist den Screenshots unten zu entnehmen, tritt jedoch nur im Artikeltext auf und nicht in der Infobox. Dabei wird anstelle der initialen Form des ersten Buchstaben die isolierte genommen, anstelle der medialen (bei Wörtern mit nur zwei Buchstaben: die finale) des zweiten die initiale (bzw. isolierte). Der Bug scheint nur das erste Wort der in die Vorlage eingetragenen Zeichenkette zu betreffen, bei den folgenden Wörtern ist die Verbindung korrekt (so wird das Wort „Katar“ bei دولة قطر korrekt zusammengesetzt).
Chrome mit Bug
IE ohne Bug
Die Buchstaben des Wortes der Reihe nach, also von rechts nach links, stehen in der folgenden Tabelle. „Name“ führt zum Artikel zum jeweiligen Buchstaben, „Unicode-Punkt“ erklärt sich von selbst, unter „Zeichen“ folgt das Zeichen aus dem Unicodeblock Arabisch, das sich der Position im Wort anzupassen weiß, unter „Form“ habe ich noch die im Wort „Katar“ benötigte Erscheinungsform aus dem Unicodeblock Arabische Präsentationsformen-B ergänzt, in dem die einzelnen Erscheinungsformen separat kodiert sind, und die sich nicht von umgebenden Zeichen beeinflussen lassen.
Danke, jetzt habe ich optisch erstmals das Problem wahrnehmen können.
Ich werde mich zum nächstmöglichen Zeitpunkt an ein Testszenario machen.
Problem: Ich bin oft nur halbstundenweise und im Halbschlaf in der WP zugange.
Das reicht zum Diskutieren, Formatieren und für Routineprogrammierung.
Die Angelegenheit hier braucht aber mehr und wachere Zeiteinheiten. Und die sind knapp, und sehr viele Angelegenheiten prügeln sich darum.
Grundsätzich liegt offenkundig ein Bug in Google Chrome vor, der auch kausal beseitigt werden sollte.
Ich habe nicht den Eindruck, dass schon jemand dort eine Bugmeldung vorgenommen hatte, oder nach einem dort bereits bekannten Problem gesucht hätte.
Wir können hier nicht kausal tätig werden, sondern nur symptomatisch einen Workaround finden.
Ich werde mein Testszenario auf eine Meldung bei Google ausrichten.
Wir richten grundsätzlich die Wikipedia-Texte nicht darauf aus, mit bestimmten temporären Schwächen einzelner Browserversionen klarzukommen, die nach einem Jahr schon nicht mehr verwendet werden; unsere vermurksten Texte und Vorlagen schleppen wir dann aber über ein Jahrzehnt weiter mit uns herum.
Der Prorammierfehler dürfte vom häufigen Typ Zaunpfahlproblem sein.
Unter bestimmten, noch zu ermittelnden Umständen werden die Buchstaben einer Zeichenkette fälschlich ab 1 statt ab 0 gezählt, was zur Folge hat, dass bei bestimmten Betrachtungen der allererste Buchstabe nicht einbezogen wird. Damit kann die Ligatur dorthin nicht berücksichtigt werden.
Auf einer rein arabischen Website wird das Phänomen nicht auftreten, es hängt mit der Einbettung von arabischer Schrift in eine LTR-Seite zusammen. Das muss noch nicht so oft bemerkt worden sein.
Wenn du die bdo/bdi-Tags verwendest, dann gibt es den Fehler. Aber wenn du nicht die bdo/bdi-Tags verwendest, dann wird es auch ohne Fehler dargestellt. Wahrscheinlich ist die Lösung mit dem inline-block am besten, wenn wir das Problem nicht lösen in dem wir Browser spezifische Lösungen dort einbauen, wo es hingehört... nämlich in das CSS-Stylesheet. Denn falls in Zukunft die Darstellung im Browser korrigiert sein sollte, können wir die dann überflüssigen stylesheet Angaben löschen... ohne den Artikeltext nochmal anfassen zu müssen. Das ist nämlich der Sinn und Zweck von CSS. Das in den style-Attributen zu packen ist nämlich auch eine Lösung aus den 90ern. --Ar-ras (D) 21:14, 22. Okt. 2016 (CEST)Beantworten
Mein FF mag alle Varianten, mein Opera Mini scheitert an bdo>bdi + direction:rtl; unicode-bidi:isolate;. Die als favorisiert gekennzeichnete Lösung funktioniert bei allem, was mir zur Verfügung steht. … «« Man77 »»(A) wie Autor16:11, 31. Okt. 2016 (CET)Beantworten
Auf BETA heißt es offenbar bei allen Varianten: First Letter separated if editing with interactive Editor ("Bearbeiten")
Was mit „interactive Editor“ gemeint sein soll, bleibt unklar; es gibt zwei Modi, die beide mit der Linkbeschriftung „Bearbeiten“ zu starten sind, und die beide ein „interactive Editor“ wären:
Quelltext-Bearbeitung (klassisch); TEXTAREA, also großes Bearbeitungsfeld.
Aktivierung mit „Bearbeiten“ beschriftet, wenn momentaner Benutzer VisualEditor als Standard deaktiviert hat.
Es gibt dann sowohl das TEXTAREA mit dem Quelltext als auch unter „Vorschau“ die Voransicht, wie dieser Quelltext als Wiki-Markup aussehen würde.
Aktivierung mit „Bearbeiten“ beschriftet, wenn momentaner Benutzer VisualEditor als Standard aktiviert hat; dann zusätzlicher Aktivierungs-Link „Quelltext bearbeiten“ vorhanden.
Hier wird direkt in einer Live-Vorschau editiert.
In diesem Fall hätte aber beispielsweise diese Bearbeitung eine automatische Markierung tragen müssen, dass sie mittels VE vorgenommen wurde.
Ich unterstelle zunächst, diese Beobachtung bezieht sich auf das TEXTAREA, also das Quelltext-Bearbeitungsfeld, und nicht auf die Seitenvorschau beim Beabeiten.
Mit dem TEXTAREA haben wir nichts zu tun.
Was im Innenleben des TEXTAREA passiert, liegt allein in der Hand der Browser-Programmierer.
Im TEXTAREA hat unser Wiki-Markup keinerlei Wirkung und das Verhalten ist deshalb naturgemäß immer gleich, egal was da für HTML drumrumsteht.
Könnte aber auch im VisualEditor passieren; etwa weil dieser seinen momentan aktiven Bereich mit irgendwelchen Bidi-Attributen umschlossen hätte.
Wegen ungenügender Angaben nicht zu klären.
Jene Seite ist dazu da, um eurer Bugmeldung bei Chrome@Google beigefügt zu werden.
Es empfiehlt sich also, insbesondere den vorgenannten und bei sämtlichen Chrome-Einträgen gleichermaßen auftretenden Kommentar
kurz und prägnant zu halten, damit die Liste übersichtlich bleibt.
einen überall identischen längeren Kommentar nur ein einziges Mal im Seitenkopf zu benennen und nicht in jedem Abschnitt langatmig zu wiederholen,
ihn eindeutig zu formulieren, so dass wenigstens ein vertiefter Insider verstehen würde, welcher Modus genau damit gemeint sein soll,
ihn so verständlich zu formulieren, dass ein externer Entwickler von Google verstehen kann, welche Situation dies auslöst.
Wie weit ist denn die Bugmeldung bei Google? Wissen die überhaupt schon, dass dieses Problem auftritt?
Irgendwie finde ich deine Art und Weise ziemlich verstörend. Auf der einen Seite schreibst du mehrere Zeilen darüber, dass du es anders gehabt haben willst, auf der anderen Seite aber setzt du das um. Gerne kannst du das auf deine Liste von Errungenschaften setzen. Mir egal. Hauptsache ich lese nicht immer wieder falsch-gebundene arabische Schrift. Natürlich ist der Visual Editor von mir mit "Interaktiver Editor" beschrieben. Zu denken, dass das textarea-Feld gemeint sein könnte, zeugt von einer ziemlich verqueren Interpretation. Über deine belehrenden Hinweisen kann ich offen gesagt nur schmunzeln, wenn nicht sogar lachen. Wir haben die Übung nur für dich umgesetzt. Wobei ich der einzige war der sich mit deinem Beta-Krimskrams auch dort auseinandergesetzt hat. Ich möchte dich darauf hinweisen, dass mir irgendwelche Bugmeldungen an Chrome SchnurzPiepEgal sind. Schon deine umgesetzte Lösung ist offen gesagt bereits jetzt überholt. Einfach aus dem Grund, dass man als Webentwickler keine CSS-Anweisungen ins style-Attribut packt wenn eine massenhafte Anwendung dieser CSS-Anweisungen geplant ist. Es wäre also sinnvoll gewesen diese CSS-Anweisungen ins Style-Sheet zu packen. Ipso Facto hast du damit den Grundstein für zukünftige unnötige Bearbeitungen im Wiki-Vorlagen-Bereich gelegt, obwohl es vollkommen sinnfrei ist.
