Wikipedia Diskussion:Technik/Skin/GUI/Seitenindikatoren

Neues Spielzeug

Folgende Fragen wären zu klären:

1. Kategorie für Vorlagen mit indicator
2. Welche sollen dort überhaupt angeordnet werden?
   • Kann man nicht ISSN anders regeln?
3. Soll es bei der Ecke neben der Überschrift bleiben?
4. Sollten nicht einige Altlasten anders gelöst werden?
5. Standardisierte Reihenfolge, wenn in einigen Konstellationen mehrere zusammentreffen:
   • Artikel mit Bewertung und Geokoordinaten
   • Projektseite mit Shortcut und Geokoordinaten
   • …

--PerfektesChaos 23:06, 5. Nov. 2014 (CET)

Ich würde alles aus Kategorie:Vorlage:mit absoluter Positionierung umstellen (ja, natürlich kann man sich bei einigen Vorlagen fragen, ob das wirklich notwendig ist, aber wir sind hier in de.wikipedia, Veränderung ist grundsätzlich böse, was "schon immer" oben rechts war, muss immer oben rechts bleiben).

Was wir brauchen, ist eine Namenskonvention für das name-Attribut, da dieses für die Reihenfolge verwendet wird. Ich halte es für sinnvoll, wenn die Symbole als letztes kommen, sodass ich einfach mal sprechende Namen für Textschnippsel vorschlage (coordinates, editcount, shortcut) und ein Präfix z- für Symbole (z-lesenswert, z-exzellent, z-informativ, …) Da es bisher keine Seiten mit sowohl Shortcut als auch Geokoordinaten geben sollte (da sie sich sonst überlagern), ist es letztlich egal, in welcher Reihenfolge diese kommen, ich bin zu 51 % der Ansicht, dass die Koordinate zuerst kommen sollte, und bei meinem Vorschlag passiert das zufälligerweise auch.

--Schnark 09:28, 6. Nov. 2014 (CET)

• Kritische Revision:
  • Nun bin ich bekannt dafür, dass ich nicht sklavisch jede Schnapsidee, die irgendwer vor zehn Jahren mal hatte, in alle Ewigkeit nachbete.
  • Das ISSN-Link ist eine verkappte Mini-Infobox.
  • Eine Variante könnte sein, nicht ausnahmslos alle bisher absolut positionierten auf indicator-Tags umzustellen, sondern nur diejenigen von themenunabhängigem und gar projektweitem Anwendungsgebiet.
    • Die indicator-Tags stehen derzeit über der Überschriften-Grundlinie neben der Überschrift.
    • Die bisherigen stehen unterhalb der Überschriften-Grundlinie.
    • Wir können also themenbezogene Extras in alter Tradition „rechts oben“ belassen, aber auch in alter Technik. Da die Themenfelder sich nicht überschneiden, ergeben sich zwei Gruppen.
    • Das gilt auch für neuartige Begehrlichkeiten nach PD.
    • Die Benutzerspielerei mit dem Editcount kann bleiben, wo sie ist.
• Design-Studien
  • Unterseiten dieser Disku sollten dafür genutzt werden, bei jeweils einem Drei-Zeilen-„Artikel“ die auftretenden Konstellationen und ihre Wirkung zu simulieren.
  • Dazu wäre der Nutztext aus der Vorlage direkt in die Seite zu schreiben.
• Koordinaten
  • Die scheinen mir ein Problem mit indicator-Tag zu werden.
  • Das Element zielt auf schmale Kleckse ab, eben Icons.
  • Rechts neben dem Überschriftentext kann nicht von großem Platzangebot ausgegangen werden.
  • Koordinaten benötigen eine langgestreckte Zeile unterhalb der Überschrift.
• style-Definitionen
  • Beim Aufräumen sollten die verbleibenden style für absolute Positionierung inline in die jeweilige Vorlage wandern.
  • Die Klassendefinitionen können dann global eliminiert werden.

LG --PerfektesChaos 10:33, 6. Nov. 2014 (CET) (multi-edit)

Sowohl die Position von indicator-Tags als auch von unseren liebevoll von Hand positionierten Elementen ist skin-abhängig. Ob und was sich beim Parallelbetrieb überschneidet, muss daher sorgfältig in jedem Skin einzeln geprüft werden. Auch aus diesem Grund haben die absoluten Positionierungen überhaupt gar nichts in den inline-Stilen zu suchen. --Schnark 12:14, 6. Nov. 2014 (CET)

Ich hatte mich auch daran gestoßen, dass jede Einzelverwendung ihre eigene Klasse bekam, aber dann alle denselben Stil zugewiesen bekamen.

Alle Verwendungen, die weiterhin mit absoluter Positionierung arbeiten oder arbeiten müssen, sollten in eine Vorlage eingebunden werden (die dann auch gleich kategorisieren kann); der gemeinschaftliche Teil inline und nur etwaige Skin-spezifische Attribute über einen einzigen Klassenbezeichner für alle, der dann im MW-NR reflektiert wird.

LG --PerfektesChaos 13:15, 6. Nov. 2014 (CET)

Nachtrag:

• Müsste ergeben: Common.css und Vector.css können wegfallen, die Nicht-Vector-Skins modifizieren.
• Mal schauen, wenn wir ins Detail gehen.

LG --PerfektesChaos 13:18, 6. Nov. 2014 (CET)

Ein (extremes) Beispiel, das die Vorteile von indicator gegenüber unseren Bastellösungen zeigt, ist Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch im Monobook-Skin (in Vector ist die Anzeige gut). Bei einer Fenstergröße, die gerade breit genug ist, um den Titel ganz zu zeigen, überlappen sowohl die Koordinaten als auch das Symbol für die gesprochene Version den Titel. Ersetzt man beides probeweise in der Vorschau durch <indicator>, so scheinen keine Überlappungen aufzutreten. --Schnark 12:03, 17. Nov. 2014 (CET)

Ich habe heute die „Bapperlecke“ in allen „maßgeblichen“ Skins (d. h. außer Cologneblue) in einen meiner Meinung nach halbwegs akzeptablen Zustand gebracht und diesen auf der Seite Kategorie:Vorlage:mit absoluter Positionierung dokumentiert.

Momentan sieht es folgendermaßen aus: Alle Icons sind mit dem neuen <indicator>-Tag implementiert, alle Textelemente sind bei dem alten System mit absoluter Positionierung geblieben, das ich aber leicht verbessert habe.

An den Umbau der Textelemente traue ich mich – vor allem wegen der Koordinatenvorlage – momentan nicht heran. Falls jemand sich da herantraut, wäre mir das durchaus recht, ich hätte nur die Bitte, dann entweder alle Textelemente umzustellen oder gar keine. Sonst müssten wir wahrscheinlich wieder mehr unterschiedliche Dinge parallel pflegen als jetzt. --Entlinkt (Diskussion) 20:20, 6. Mär. 2016 (CET)

Fein, fein.

Ich habe gerade eben eine Tabelle auf der Projektseite angelegt; die scheint mir dienlicher als die Kategorie.

Aus den Bezeichnern würde ich gern demnächst das Vorlage_ rauswerfen. Es ist redundant und bläht nur. Für die indicator-Tags kommen nur Vorlagen in Frage, und es gibt schlussendlich auch nur zwei Dutzend Bezeichner. Das ist anders als bei CSS-Klassen und IDs, von denen es Hunderte und Tausende in allen NR geben mag.

Weiterhin werde ich gelegentlich eine neue Kat anlegen und die indicator-Vorlagen dort einsortieren, so dass die Altfälle in der bisherigen Kat verbleiben.

Unter den Altfällen sind einige obsolete, die aussterben werden und nicht mehr umgestellt werden sollten.

LG --PerfektesChaos 00:12, 7. Mär. 2016 (CET)

Vorlage_ … bzw. es ist völlig egal und sogar hinderlich, ob in Vorlage oder Systemnachricht definiert ist. Die Bezeichner müssen unterschiedliche Zwecke eindeutig und konfliktfrei kennzeichnen; in welchem Moment welche Seite die Implementierung verursacht, ist nachrangig. Wechselt der Ort der Definition, bleibt der Zweck identisch. --PerfektesChaos 00:19, 7. Mär. 2016 (CET)

Nach Drüberschlafen (die Aktion kam gestern Abend nach mehr als einem Jahr Schlummerzustand etwas überraschend):

• Die „Gesprochene“ kommt momentan rechts von „Exzellent“, aber links von „Informativ“ und „Lesenswert“.
  • Das ist nicht so gut. Es sollte den Lesern eine einheitliche Systematik geboten werden.
  • Beispielsweise kann man sagen, dass „Gesprochene“ für Leser, die Leseschwierigkeiten haben, einen besonderen Mehrwert bieten und immer außen am Rand stehen sollen.
    • Also: zzz-Gesprochen, aber zz-Exzellent, zz-Lesenswert usw.
  • Die Auszeichnungen und Kandidaturen dafür können immer nur einmal pro Seite vorkommen; falls mehrmals, is eh wurscht.
• Die Bezeichner müssen nur innerhalb eines Namensraums ein nachvollziehbares konfliktfreies Schema liefern. Sie haben global für das Projekt keine Bedeutung, und letztlich können eigentlich nur drei oder vier gleichzeitig vorhanden sein.
• Die Vergabe der Bezeichner nach dem Seitennamen der implementierenden Stelle ist dafür nicht hilfreich.
• Mir sieht es momentan eher aus nach:
  • z-Schreibwettbewerb – temporär, für Leser nachrangig
  • z-Wartungsbausteinwettbewerb – temporär, für Leser nachrangig; bei Teilnehmern am Schreibwettbewerb mit Wartungsbausteinproblem ist sowieso alles verloren
  • zz-Exzellent – Qualitätsinfo für Leser
  • zz-Lesenswert – wie eben, nur 1 möglich, usw.
  • zzz-Gesprochen – Maximale Aufmerksamkeit, wo vorhanden
• Altlasten mit vorhersehbar endlicher Lebensdauer und historische Experimente werden nicht in die Systematik einbezogen.
• Alle Geoinfos scheinen mir eigentlich besser am historischen Platz unter der Überschrift in einer langen Zeile aufgehoben; mit Alleinstellungsanspruch dort. Mobil??
  • Alle dauerhaft unterstützenswerten Konkurrenten können wohl nach oben.

LG --PerfektesChaos 11:51, 7. Mär. 2016 (CET)

1. Die Reihenfolge der Icons zueinander ist mir persönlich völlig egal und kann von jedem angemeldeten Benutzer geändert werden. Dasselbe gilt für die Nomenklatur der name-Attribute. Solange die Icons alle nebeneinander und etwaige zukünftige Nicht-Icons entweder alle links oder alle rechts der Icons stehen, ist es mir recht. Ich habe einfach nur irgendeine Nomenklatur und Reihenfolge implementiert, weil die Erstimplementierung Adminrechte erforderte (zum Verschieben anderer Elemente, die im Weg stehen, in jedem einzelnen Skin) und man mit langen Absprachen nicht weiterkommt.
2. Ich bin immer noch der Meinung, dass alle Textelemente auf dieselbe Art und Weise implementiert sein sollten. Im jetzigen Zustand pflegen wir zwei Systeme parallel, nämlich das neue System für die Icons (für Textelemente im jetzigen Zustand wenig geeignet, da bspw. die Schrift zu groß ist) und einen kleinen Teil des alten Systems für die Textelemente. Wenn wir nur einen Teil der Textelemente auf das neue System portieren, müssen wir mehr als jetzt pflegen.
3. Ich weiß nicht, warum du immer von Geokoordinaten unter der Überschrift schreibst. Die Koordinaten stehen schon seit vielen Jahren in Monobook und Vector über der Überschrift. Unter der Überschrift haben sie auf keinen Fall Platz, weil dort bereits Weiterleitungshinweise, Bedienelemente für gesichtete Versionen etc. stehen. In Vector wurde zeitweise mit einer Position unter der Überschrift experimentiert, das hat sich aber wegen Platzmangel (und zu großem Platzanspruch der Koordinaten in der Breite wie auch in der Höhe) nicht bewährt. Man beachte auch Konstrukte wie in Kategorie:Tempel der Kirche Jesu Christi der Heiligen der Letzten Tage.
4. Alleinstellungsansprüche für Koordinaten werden meiner Meinung nach nicht funktionieren. Wenn wir die Koordinaten irgendwie anders implementieren als andere Textelemente, werden „schlaue“ Leute wieder auf die Idee kommen, dass man durch Missbrauch der Koordinaten-ID besondere Effekte erzielen kann (z. B. zwei Textelemente pro Seite und ähnliche Begehrlichkeiten), so dass der Wartungsaufwand weiter steigt. Der ganze Wildwuchs ist überhaupt erst aus einem Alleinstellungsanspruch der Koordinaten entstanden.

Gruß --Entlinkt (Diskussion) 07:59, 8. Mär. 2016 (CET)

Ein bisschen Informationsflut:

• Es gäbe die Möglichkeit, die Textelemente wie jetzt absolut positioniert zu belassen (Variante 1) oder sie auf <indicator> umzustellen und auch so anzuzeigen (Variante 3). „Dazwischen“ gäbe es aber auch noch die Möglichkeit, sie auf <indicator> umzustellen und zusätzlich auch die abolute Positionierung beizubehalten (Variante 2). Letzteres hätte den Vorteil, dass sich am Aussehen im Vergleich zu jetzt nichts ändert, die Textelemente aber zumindest an einer sinnvolleren Stelle im HTML-Code stehen. Falls Variante 3 implementiert werden soll, wäre es wahrscheinlich sinnvoll, übergangsweise zuerst Variante 2 zu implementieren.
• Die Vorlage MediaWiki:Specialpage-helplink steht momentan an der Koordinatenposition. Falls Variante 2 oder 3 implementiert wird, müsste dafür eine andere Lösung gefunden werden, weil <indicator> nicht auf allen Spezialseiten funktioniert.
• Bei Variante 3 erscheinen die <indicator>-Fragmente oben rechts in einer inline-Darstellung, d. h. unmittelbar nebeneinander und mit nur einem Leerzeichen dazwischen. Solange es pro Seite immer nur entweder Icons und keinen Text, oder aber nur ein Textelement und keine Icons gibt, ist das wunderbar. Sobald wir aber mehrere Textelemente oder eine Mischung aus Text und Icons erlauben, wären meiner Meinung nach geeignete Trennzeichen erforderlich, die irgendwie per CSS eingefügt werden müssten. Das Ganze müsste so gestaltet sein, dass es mit der Vorlage:Coordinate und den beiden daran hängenden Gadgets vernünftig aussieht (man beachte, dass die Gadgets jetzt schon „|“ als Trennzeichen einfügen).
• Bei Variante 3 sind weitere CSS-Anpassungen für Textelemente erforderlich, insbesondere muss die Schrift – vor allem wegen Vorlage:All Coordinates – leider so klein sein wie jetzt (siehe als Beispiel Kategorie:Tempel der Kirche Jesu Christi der Heiligen der Letzten Tage und beachte, dass „Koordinaten“-Konstrukt und Hilfe-Link dann nebeneinander stehen würden). Andernfalls werden die Konstrukte zu lang. Damit es noch zur kleinen Schrift passt, müsste somit wahrscheinlich auch das Hilfe-Icon verkleinert werden.
• In der Mobil-Version werden <indicator>-Fragmente momentan überhaupt nicht ausgegeben, d. h. bei Variante 2 oder 3 gäbe es im Gegensatz zu jetzt nicht einmal mehr die theoretische Möglichkeit, sie durch einen CSS-Hack anzuzeigen, es sei denn, der Mobil-Skin wird entsprechend geändert.
• Vor Jahren war es so, dass die Koordinaten für Zwecke der Nachnutzung aus der Datenbank externer Links extrahiert wurden (Auswertung der Hyperlinks auf den Geohack). Es wäre zu prüfen, ob das immer noch der Fall ist und falls ja, ob die entsprechenden Werkzeuge noch zurechtkommen, wenn die Links in einem <indicator>-Tag stehen.
• In Artikelquelltexten sind die betroffenen Vorlagen sehr oft mit Leerzeilen davor und danach eingebunden. Bei Variante 2 oder 3 wäre strikt darauf zu achten, dass durch den Umbau keine unerwünschten „Löcher“ (<p><br></p>) in Artikeln erscheinen. Das kann man zum Beispiel durch geschickt platzierte <nowiki/>-Tags erreichen.
• Momentan ist es so, dass mehrere Textelemente sich zwangsläufig überlappen, was effektiv bewirkt, dass nur eines pro Seite existieren kann. Bei Variante 3 wären mehrere Textelemente pro Seite möglich. Wir sollten unbedingt darauf gefasst sein, dass das dann auch ausgenutzt wird, d. h. es gibt dann kein Zurück mehr. Außerdem würde sich die Situation zum Beispiel dann ändern, wenn eine Seite mehrere Artikelkoordinaten hat. Momentan überlappen sich diese, fallen dadurch auf und können korrigiert werden. Bei Variante 2 oder 3 würde der Parser nur noch die letzte Artikelkoordinate ausgeben, so dass mehrfache Artikelkoordinaten nicht mehr auffallen.

Viele Grüße --Entlinkt (Diskussion) 16:35, 20. Mär. 2016 (CET)

Danke für deine Arbeit.

Es ist über ein Jahr her, dass ich mich zuletzt intensiv mit der Thematik befasst hatte, und ich bin in diese plötzlich aktuell gewordene Geschichte nicht mehr so ganz eingearbeitet.

• Dass ich Geos über oder unter irgendwelchen Überschriftenlinien durcheinanderbrachte, hat genau diesen Grund; man nimmt die Gestaltung da rechts oben irgendwann nicht mehr wahr.
• Meine Erinnerung, die ich kürzlich bereits angedeutet hatte, geht dahin, dass wir wohl Variante 2) bräuchten, wenn ich das richtig verstehe, dass bestimmte Elemente bei absoluter Positionierung bleiben und andere auf <indicator> umgestellt würden. Die Indicator-Ecke und die absPos-Region dürfen sich dann nicht überlappen.
• Mir ist so, dass die Koordinaten etwas waren, das sich nicht vernünftig automatisch mit <indicator> unterbringen ließ, während jene Tags hervorragend geeignet sind, um die Bapperl-Symbole (meinte ursprünglich mal „Exzellent“ und „Lesenswert“) einzufädeln, und wurde dann vergewaltigt. Dass von irrtümlich mehreren Artikel-Koordinaten nur eine dargestellt würde, spräche ebenfalls dafür. Von Nachnutzung weiß ich nichts, aber die freuen sich ggf. auch, wenn sie nicht alle paar Wochen unseren wechselnden Design-Experimenten folgen müssten.
• Es kann immer gleichzeitig „Gesprochen“ und eine Auszeichnung geben.
• Spezial:In der Nähe kann möglicherweise einmal gleichzeitig von uns konfiguriertes Koordinaten-Link und Specialpage-helplink enthalten, und Kategorien haben ja auch ein helplink, sakra!
• Mehrere Textdinger sollten wir nicht zusätzlich unterstützen und fördern; schon das olle ISSN-Gemurkse (das zum enzyklopädischen Inhalt des Artikels gehört und nicht wie sonst alle anderen zusätzliches Service-Link im Sinne von Meta-Information ist) gehört nach und nach abgeschafft. Keine neuen Texte; es ist auch eine Zumutung, wesentliche Infos des Seiteninhalts winzig in irgendwelchen Ecken zu verstecken.
• Weitere künftige Text-Elemente gehören in normalgroßer Schrift als Box in den inhaltlichen Bereich unterhalb der Überschrift; ggf. in Infoboxen etc. integriert oder darunter. Schluss mit diesem Gepfriemel unentzifferbarer Miniatur-Informationstexte zwischen kryptischen Symbolen.
• Koordinaten und Shortcuts kann es als Text-Elemente beide geben; WP:Lokal K. Wenn Koordinaten etc. ihre absPos behalten und die Shortcuts in die Tag-Ecke kommen, wäre beides entflochten.
• Koordinaten, endend mit einem OSM-Globus, und dahinter ein exzellenter gesprochener Artikel geben eine bescheuerte Symbol-Kette. In den USA findet man sowas vermutlich schau; die betrachten das als Verdienstmedaillen für die Uniform, und die enWP berauscht sich daran.
• Mobil wird das schon irgendwann global unterstützen.
• Text-Teile müssten übrigens wohl ein nowrap in die Common.css bekommen, falls die sich ausbreiten. Wenn es nur bei den Shortcuts bleibt, können die selbst für geeignete Trennstellen sorgen.

LG --PerfektesChaos 17:37, 20. Mär. 2016 (CET)

Mit dem meisten bin ich einverstanden, aber mit zwei Dingen nicht:

• Unter „Variante 2“ verstehe ich oben, dass alle Textelemente jeweils in ein <indicator-Tag gepackt werden, dadurch im HTML-Code nach oben wandern, anschließend aber trotzdem wie bisher absolut positioniert werden, und zwar weiterhin alle an ein und derselben Stelle. Das wäre optisch identisch mit dem jetzigen Zustand und würde nur den HTML-Code leicht verbessern, was sich u. a. bei der Tastaturnavigation bemerkbar machen würde (z. B. kein Springen mehr aus der Infobox in die Bapperlecke und wieder zurück in die Infobox beim Artikel Berlin) und kleine CSS-Bugs mit vererbten Eigenschaften vermeiden würde (die aber wahrscheinlich eh nur selten auffallen).
• Gar nicht angetan bin ich nach wie vor von der Idee, in Zukunft manche Textelemente technisch anders in die Bapperlecke einzufügen als andere. Für mich riecht das nach massivem Ärger (Benutzer, die Vorlagen zwischen beiden Möglichkeiten hin- und herbugsieren, um Platz für noch mehr Text oben rechts herauszukitzeln).

Ich sag’s mal ganz undiplomatisch ohne Blatt vor dem Mund (ist im Zweifelsfall immer besser so): Von den Textelementen halte ich ausschließlich die Vorlage:Coordinate für enzyklopädierelevant, weil sie in knapp einer halben Million Artikeln für einen Zweck verwendet wird, der vielen Wikipedianern sehr wichtig ist und es realistisch gesehen so gut wie unmöglich ist, davon wegzukommen.

Alle anderen Textelemente sind ausnahmslos daraus entstanden, dass jemand die Implementierung der Koordinaten kopiert und eine neue ID vergeben hat. Difflinks für #issnlink, #shortcut und #editcount. In Monobook und Vector hat es das niemals gegeben, dass die Teile nicht an derselben Stelle standen. Auch wenn das damals nicht vernünftig ausdiskutiert wurde, ist die Intention meiner Meinung nach relativ klar gewesen, dass es für all diese Dinge nur eine Implementierung geben sollte. Wenn wir nach über 10 Jahren jetzt davon abgehen, wird der Wartungsaufwand nicht kleiner, sondern größer werden.

Speziell zu den Shortcuts ist zu sagen, dass die ursprüngliche Vorlage offenbar eine Kopie aus der englischen Wikipedia war (erkennt man leicht am Layout), dass aber die englische Vorlage schon immer „normal“ positioniert war (also mit float und nicht in der Bapperlecke). Meiner Meinung nach belegt das, dass die Shortcuts die Position in der Bapperlecke eigentlich gar nicht brauchen. Ziemlich sicher brauchen sie aber nichts, was man zusätzlich zur Koordinatenposition pflegen und vor Missbrauch schützen müsste.

Meiner ganz persönlichen Meinung nach gibt es jetzt zwei grundsätzliche Möglichkeiten: Entweder, man hält den Aufwand gering, belässt es dabei, dass die Textelemente in der Bapperlecke alle gleich implementiert sind und begnügt sich mit Detailverbesserungen. Oder aber man nimmt die Herausforderung an, das System grundsätzlich umzugestalten. Dann aber wäre es sinnvoll, es gleich richtig zu machen und so viel wie möglich (idealerweise alle Textelemente außer Vorlage:Coordinate) aus der Bapperlecke zu entfernen. Machbar wäre das auf jeden Fall (die englische und die französische Wikipedia haben in der Bapperlecke nur Koordinaten, Icons und den Hilfelink von Mediawiki). --Entlinkt (Diskussion) 19:22, 20. Mär. 2016 (CET)

Mir ist auch sehr danach, Textelemente aus der Ecke zu entfernen.

• editcount kann eine normale Box werden. Müssen die Benutzer ihre Seiten halt mal aufräumen, oder sie integrieren sich das in eine Babel-Schublade. Wer immer sich das ausgedacht hatte – es war kein Schwerintellektueller.
• issn gehört als „veraltet“ sowieso durch Infobox ersetzt und geschrottet. Sollte sich irgendwann von selbst lösen.
• Steckengebliebene Experimente und privater Schrott in der absPos-Kat gehört seiner CSS-Eigenschaften beraubt und entkategorisiert. Nix Neues mehr.
• Mit den Shortcuts habe ich ein Problem. Die Projekt-, Hilfe- und Portalseiten, die von der eigentlichen Vorlage Gebrauch machen, haben fast alle gleichzeitig eine Linkbox rechts oben. Diese würde sich optisch mit einer normalgroßen Box wie in der enWP beißen, die dafür in en:WP:WEB einen völlig anderen Seitenaufbau hat als WP:WEB. Weil ich eine Weile intensiv an den Shortcuts gearbeitet hatte, weiß ich, dass durch verschachtelte Intro-Seiten usw. da viele Probleme auftauchen würden. Hingegen träfen Shortcuts in wenigen Fällen mal mit WP-Lokalitäten und deren Koordinaten zusammen (heutzutage unmöglich) und sind ansonsten Solisten.

Ich hatte mal unten eine Spielwiese für Tag-Einbindungen vorbereitet; mach doch bitte mal ein paar Mock-Ups zu den Koordinaten, damit man bei allerlei Seitentiteln, Kombination mit gesprochenen lesenswerten OSM mal einen Eindruck bekommt, wie sich das mit verschiedenen Fensterbreiten in diversen Skins verhält, oder gleich in BETA einfallen.

LG --PerfektesChaos 20:29, 20. Mär. 2016 (CET)

Ich habe im β-dewiki einen Muckup für das gebaut, was ich oben „Variante 3“ genannt habe (also die Maximalvariante). Die entsprechenden Seiten sind (leider alle mit kurzem Lemma, aber das kann man ja beheben):

• http://de.wikipedia.beta.wmflabs.org/wiki/Berlin
• http://de.wikipedia.beta.wmflabs.org/wiki/Schweiz
• http://de.wikipedia.beta.wmflabs.org/wiki/Die_Zeit
• http://de.wikipedia.beta.wmflabs.org/wiki/Datei:Radial_engine.gif
• http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Spielwiese
• http://de.wikipedia.beta.wmflabs.org/wiki/Kategorie:Ort_in_Deutschland

Die Schrift oben rechts muss klein sein, ist sie das nicht, wurde das CSS nicht geladen.

Ich muss ganz ehrlich sagen, dass ich es selbst recht gewöhnungsbedürftig finde. Es ist auch in keinster Weise auf Grenzfälle getestet und sicherlich in zigfacher Hinsicht verbesserbar. Gruß --Entlinkt (Diskussion) 23:25, 20. Mär. 2016 (CET)

Für Analysezwecke habe ich zwei CatScan-Abfragen für diejenigen Seiten erstellt, die momentan sowohl mindestens ein Textelement als auch mindestens ein Icon enthalten, da diese layoutmäßig am stärksten vom Umbau betroffen wären (Text und Icons in einer Zeile nebeneinander statt untereinander). Die Abfragen werden nicht hundertprozentig genau, aber ziemlich genau sein.

• CatScan-Abfrage (nur Artikelnamensraum) → 1764 Artikel
• CatScan-Abfrage (nur andere Namensräume) → 63 Seiten

Wie man sieht, betrifft dies ca. ein Promille des Artikelbestands und eine absolut überschaubare Zahl anderer Seiten. --Entlinkt (Diskussion) 00:23, 22. Mär. 2016 (CET)

„Vorlage“ für Experimente

Ich habe eine Art Mini-Vorlage zur Unterstützung der Design-Studien bereitgestellt.

VG --PerfektesChaos 11:15, 6. Nov. 2014 (CET)

Technische Umsetzung

Ich muss mich von meinen Aussagen im Abschnitt #Neues Spielzeug oben wegen neuer (äh, eigentlich gar nicht so neuer, eher „wiederentdeckter“) Informationen teilweise distanzieren. Es gibt mit phab:T40848 ein klitzekleines Problemchen (das ich übrigens sogar schon 2010 als phab:T26667 gemeldet, aber dann wieder aus den Augen verloren hatte). Dieses Problem besteht im Grundsatz in allen Wikis und ist bisher nur teilweise gelöst.

Es war wohl zuletzt die Rede davon, dies auf eine Art zu lösen, die alle absolut positionierten Vorlagen in allen Wikis komplett brechen würde. (Die Vorlagen funktionieren ja nur deshalb, weil sie den Bug ausnutzen.) Solange nicht klar ist, was passiert, haben weitere „Verkomplizierungen“ unserer Vorlagen/Skins meiner Meinung nach keinen Sinn, weil sie die Lage im Zweifelsfall nur verschlimmern (und in eine Lage führen, aus der man noch schwerer wieder herauskommt als aus der jetzigen).

Ich habe deshalb unter http://de.wikipedia.beta.wmflabs.org/wiki/Vorlage:Text_oben_rechts eine Vorlage angelegt, die im Fall der Fälle als „Auffangbecken“ dienen kann. Sie genießt allerdings von mir keinerlei Unterstützung (und wäre deshalb von irgendwem nach dewiki zu kopieren, oder in ähnlicher Form neu zu machen). Sie sieht überhaupt nicht schön aus, funktioniert aber zumindest und ist höchstwahrscheinlich nicht gefährlich. Anschließend sollte meiner Meinung nach alles Weitere ausschließlich durch Vorlagenprogrammierung und Inline-CSS gelöst werden (und was damit nicht geht, geht halt nicht).

Die CSS-Änderungen von heute bzw. gestern (zusätzlicher Selektor #mw-content-text vor allen betroffenen Selektoren) dienen übrigens der Sicherheit und führen dazu, dass für alles Weitere nur noch die Vorlagen bearbeitet werden müssten (d. h. es ist kein Admin erforderlich, da meines Wissens alle betroffenen Vorlagen ohne Vollschutz sind). Gruß --Entlinkt (Diskussion) 03:07, 2. Apr. 2016 (CEST)

PS: Mit „Verkomplizierungen“ unserer Vorlagen meine ich jede Lösung, die manche Textelemente auf <indicator> umstellt und andere nicht. Das scheidet meiner Meinung nach auf jeden Fall aus, weil es einen Zustand herstellen würde, der nicht auf Dauer so bestehen bleiben kann. Auch das, was ich im Abschnitt #Neues Spielzeug oben als „Variante 2“ bezeichnet hatte, scheidet aus. Gruß --Entlinkt (Diskussion) 03:16, 2. Apr. 2016 (CEST)

• Ich darf weder phab:T40848 noch phab:T26667 lesen.
• Ich sehe nicht, dass es angesichts der angedeuteten Probleme zurzeit überhaupt eine zukunftsfähige und dauerhafte Marschrichtung gibt; zumindest was über kleine Icons hinausgehende Texte angeht.
• Es war eine Schnapsidee unserer Vorfahren, Texte mitten in das Layout von in verschiedenen Skins angebotenen Portal-Designs hineinzuquetschen, wobei die erst recht nicht an etwas wie Smartphones und Mobil-Skin gedacht hatten. Das kann nicht sinnvoll funktionieren, und es dürfen keine neuen hinzukommen. Mit den beiden Erben „Koordinaten im Himmel und auf Erden“ und „Shortcuts“ müssen wir irgendwie zurechtkommen; alle Experimente und sonstigen Altlasten können nur abgebaut und aufgelöst werden.
• Shortcuts können hier nicht mal eben in float und innertextliche Boxen umgewandelt werden, wie in der englischsprachigen Wikipedia.
  • Es wird in bald 2500 Seiten sowohl im Projekt-, Portal und Hilfebereich wie auch auf den jeweils zugehörigen Diskussionsseiten eingebunden. Deren Layout wie WP:LP, WD:WWNI oder PD:GRA und jede Seite mit einer Linkbox oben rechts verlässt sich darauf, dass der Shortcut irgendwie woanders steht.
  • Es ist auch grade der Charme der Lösung, dass unabhängig vom individuellen Design der Seite diese Zusatz-Info immer am selben Ort zu finden ist.
  • Man könte es noch einkürzen, indem man das verlinkte vorangestellte „Abkürzung:“ vorneweg weglässt, und statt dessen den Shortcut selbst für seine Erklärung verlinkt. Da er immer eine Weiterleitung auf die momentane Seite ergeben muss, kann es bisher niemals ein Link sein, und diesen unverlinkten Text könnte man ausnutzen, um ihn auf Icon-Format zu bringen.
• Für die Koordinaten habe ich bislang keine überzeugende, zukunftsfähige und kombinierbare Lösung gesehen.
  • Ich hatte aber nur wenig Zeit für tiefergehende Analysen und Experimente, und habe aber eigentlich in diesen Wochen andere Prioritäten, und insofern müssen wir außer vorbereitenden Überlegungen und Abbau von Altlasten nichts unter Zeitdruck unternehmen.
• Insofern: Status quo, Vorbereitungen, Rückbauten wo immer möglich.

LG --PerfektesChaos 17:59, 2. Apr. 2016 (CEST)

Vielleicht können wir diesen Abschnitt für eine Diskussion über die konkrete technische Umsetzung bzw. Umsetzbarkeit nutzen. Im Abschnitt #Neues Spielzeug oben ging es ja in weiten Teilen eher darum, was man sich wünscht, ohne zu sagen, wie das gehen soll.

Ich habe mich jetzt nochmal ziemlich lange mit dem Thema beschäftigt und im β-dewiki die folgenden Demonstrationsseiten gebaut:

	Vector	Monobook	Modern	Cologneblue
Berlin	beta/echt	beta/echt	beta/echt	beta/echt
Lausanne	beta/echt	beta/echt	beta/echt	beta/echt
LinuxUser	beta/echt	beta/echt	beta/echt	beta/echt
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch	beta/echt	beta/echt	beta/echt	beta/echt
Kategorie:Ort in Deutschland	beta/echt	beta/echt	beta/echt	beta/echt
Kategorie:Tempel der Kirche Jesu Christi der Heiligen der Letzten Tage	beta/echt	beta/echt	beta/echt	beta/echt
Naturschutzgebiet Dünenkiefernwald am Langhagensee	beta/echt	beta/echt	beta/echt	beta/echt
Portal:Frankreich	beta/echt	beta/echt	beta/echt	beta/echt
Volkskunde- und Freilichtmuseum Roscheider Hof	beta/echt	beta/echt	beta/echt	beta/echt
Vorlage:All Coordinates	beta	beta	beta	beta
Vorlage:Coordinate	beta	beta	beta	beta
Vorlage:Coordinate Schweiz	beta	beta	beta	beta
Vorlage:Editcount	beta	beta	beta	beta
Vorlage:ISSN-Link	beta	beta	beta	beta
Vorlage:Lagewunsch	beta	beta	beta	beta
Vorlage:Linked Coordinates	beta	beta	beta	beta
Vorlage:Shortcut	beta	beta	beta	beta
Dreimal Lorem ipsum (absolut positioniert)	beta	beta	beta	beta
Dreimal Lorem ipsum (indicator)	beta	beta	beta	beta
Dreimal Lorem ipsum (kombiniert)	beta	beta	beta	beta
Mit den letzten drei Testseiten soll nur demonstriert werden, dass es eine Scheiß-Idee ist, große Textmengen außerhalb des normal beschreibbaren Bereichs unterzubringen, egal mit welcher Technik. Ausnahmen bleiben nur dann halbwegs handhabbar, wenn sie klein sind. Das Positionieren außerhalb des normal beschreibbaren Bereichs ist und bleibt eine Spielerei, die nur deshalb leidlich „unterstützt“ wird, weil sie nicht rechtzeitig verhindert wurde.

Ich bitte zu beachten, dass das Site-CSS und auch das JS dort beinahe identisch zu dem aktuell in der Produktivumgebung hier vorhandenen sind. Es gibt lediglich einen ganz kleinen zusätzlichen Hack in Gadget-betaStyle.css (dessen Effekt man natürlich auch anders und besser erreichen kann).

Etwas sehr viel besseres als dies ist meiner Meinung nach nicht zu erwarten. Auf Nachfrage kann ich das gern näher begründen, an sich kann das aber auch jeder in einer 2-stündigen Firebug-Sitzung selbst herausbekommen. Insbesondere gehe ich ganz stark davon aus, dass die oben bemängelte „bescheuerte Symbol-Kette“ bei georeferenzierten ausgezeichneten Artikeln leider nicht vermeidbar ist, da für mehr als eine Zeile leider auch beim besten Willen weit und breit kein Platz vorhanden ist.

Jedem, der gern herumprobieren möchte, würde ich stark empfehlen, mit der folgenden Regel eine CentralNotice zu simulieren:

#siteNotice {
    background: yellow;
    min-height: 100px;
}

Das Ganze muss auch in diesem Szenario 100%-ig funktionieren, da unsere unangemeldeten Leser sehr oft Banner an dieser Stelle angezeigt bekommen. Es sollte hoffentlich sofort klar werden, warum mehr als eine Zeile nicht geht. Der „Platz“ über der SiteNotice (= das padding des #content-Bereichs) steht für <indicator>-Tags nicht mehr zur Verfügung, weil sie im Markup darunter stehen.

Der Zustand aus dem β-dewiki könnte jederzeit mit nur wenigen Handgriffen hier bei uns hergestellt werden. Meine ganz konkrete Frage wäre daher, ob irgendjemand eine Meinung dazu hat, auch an dem Thema arbeitet oder vielleicht sogar Ideen hat, wie es besser geht. Ich nämlich leider nicht.

Ach so, und nochmal die Klarstellung: Mir geht es absolut nicht darum, Dinge zu ermöglichen, die bisher nicht möglich waren (wie zum Beispiel Koordinaten + Shortcut auf einer Seite); daran müssten diejenigen arbeiten, die solches wünschen. Ich arbeite selber nur daran, den idiotischen Hack loszuwerden, den wir derzeit haben, und dabei die bereits vorhandenen Vorlagen zu erhalten.

Gruß --Entlinkt (Diskussion) 08:00, 30. Apr. 2016 (CEST)

Erstmal danke ich für deine Mühen.

• Es ist gut, das griffbereit für den Tag X auf Beta in erprobter Form zu haben.

Ich würde jetzt im Moment nichts machen außer Rückbau von Vorlagen im produktiven Bereich, und Ersatz durch andere Lösungen wo immer möglich, und Reduktion der absPosKat soweit wie möglich; bis auf die langfristig notwendigerweise Überlebenden in der umseitigen Tabelle.

Sollte der Tag X kommen, können wir sofort ausrollen.

Sollte der Tag X auf sich warten lassen, ergeben sich vielleicht anderswo Entwicklungen, vielleicht Mobil, vielleicht eine neuartige Universal-Skin wie Winter oder Athena, und es ergibt sich von außen Handlungs- und Überzeugungsdruck, dass irgendeine liebgewordene optische Gewohnheit jetzt dahin ist, und von Anfang an ein kurzsichtiges Rumgewurstel für momentane Skin auf momentanen Geräten mit momentaner Dokumentstruktur war.

Ich selbst habe eigentlich eine andere Agenda, oder viele andere Agendas, und kann nur kursorisch deinen Resultaten folgen. Alternative Lösungen habe ich unter den Bedingungen des Tages X auch nicht.

LG --PerfektesChaos 18:39, 30. Apr. 2016 (CEST)

Hm, also ehrlich gesagt reift bei mir momentan gerade schon so nach und nach die Überzeugung, dass man in wirklich absehbarer Zeit etwas tun sollte.

Begründung: Hier in der Vorlagenwerkstatt läuft gerade in diesem Moment (wirklich brandaktuell) eine Diskussion, ob eine „Allgemeine Vorlage für zwei Koordinaten“ erschaffen werden sollte. Ich halte das für eine saumäßig blöde Idee, aber leider wäre es momentan tatsächlich möglich, das zu realisieren, indem man für eine der beiden Koordinaten die absolut positionierte ID coordinates verwendet und für die andere das <indicator>-Tag. In den Skins Vector und Monobook sieht das Ergebnis sogar halbwegs vernünftig aus, aber zum Beispiel im Modern-Skin wären die beiden Zeilen vertauscht.

Ich weiß nicht, ob unsere Vorlagenprogrammierer diese backdoor schon kennen, aber es ist eigentlich nur eine Frage der Zeit, bis sie darauf kommen und anfangen, sie auszunutzen. Wenn das erstmal passiert ist, ist eine einfache Umstellung nicht mehr möglich.

So, wie ich den typischen Wikipedianer einschätze, wird er irgendwann eine idiotische Vorlage bauen und dann verlangen, dass sie von anderen am Laufen gehalten wird, weil sie ja irgendwann einmal funktioniert hat und deshalb für immer funktionieren muss (typisches Wikipedianer-Argumentationsmuster).

Die Forderung nach zwei Zeilen übereinander ist übrigens auch gar nicht neu, siehe etwa hier die Forderung von 2014.

Ich spiele deshalb, muss ich ganz ehrlich sagen, schon insgeheim mit dem Gedanken, die Umstellung einfach so vorzunehmen und unseren CSS-Hack zu entfernen, da das Thema eh kaum jemanden wirklich zu interessieren scheint und sich schon seit Jahren faktisch kein anderer Admin um den CSS-Hack kümmert. Der hauptsächliche Blocker im Moment ist Modul:Vorlage:Defekter Weblink, da dies dazu führen würde, dass auf zigtausend Diskussionsseiten die Koordinaten erscheinen.

Gruß --Entlinkt (Diskussion) 19:30, 30. Apr. 2016 (CEST)

Naja, dann bräuchte es einen schlauen Schlachtplan; und dann würde ich jetzt mit ausschließlich den Koordinaten anfangen und mal gucken, was dann so auf FZW passiert.

• Die Vorlage:Defekter Weblink kann zwar alle bekannten Vorlageneinbindungen im durchsuchten Artikelquelltext ausixen, aber gegen in Infobox eingebundene Koordinatenvorlagen bin ich machtlos.
• Aber gibt es da nicht was von Ratzefahm? Artikel-Diskussionsseiten haben keinerlei Anpruch auf sichtbare Koordinaten. Ergo gibt es den Selektor .ns-1 und dazu irgendwas spezifisches, das in allen Koordinaten-indicator vorkommt. Shortcuts gibt es für Artikel-Diskussionsseiten nicht, und lesenswert wären auch nur die wenigsten. So auf Anhieb wüsste ich nicht, dass bei Artikel-Disku überhaupt ein indicator auftreten kann, während WD:TEC durchaus geht.
• Diese Infos über Defekte Weblinks auf 300.000 Artikel-Disku zu verwalten, zu löschen, leer gewordene Artikel-Disku schließlich wieder zum redlink zu machen, und dann einmal jährlich in einem vier Monate dauernden Botlauf durch neue Analysen zu ersetzen ist auch ein antikes und nur aus der Not geborenes Konzept, weil die labstools noch nicht robust gewesen waren. In Zukunft sollte Zukunftsmusik gespielt werden, und dann wird die Brückentechnologie mit diesem Modul obsolet und kann lieber heute als morgen getonnt werden. Von daher wäre gegen ein winzig kleines temporäres display:none nichts einzuwenden, auch wenn es einige Jahre drinbliebe.

Der aktuelle Wünschdirwas in der VWS hat ganze 33 ANR-Edits und wird sicher nicht sofort in die Vorlagenprogrammierung einsteigen, obwohl er sich für einen Newbie erstaunlich gut mit technischen Interna auskennt.

Es war schon eine ziemlich dusslige Idee gewesen, eine recht lange Textzeile zwischen die Zeilen eines sich ändernden Layouts zu quetschen; aber für Vorschläge, das mit zwei Zeilen zu machen, habe ich nur noch Trostpreise in der Schublade.

LG --PerfektesChaos 20:58, 30. Apr. 2016 (CEST)

Das Problem mit diesen Wünschen in der Vorlagenwerkstatt ist einfach, dass sie sich ständig wiederholen und jedes Mal die Gefahr besteht, dass irgendwer sie umsetzt. An sich müsste man ständig die Vorlagenwerkstatt beobachten und immer einschreiten.

Und trotzdem kann es passieren, dass irgendetwas durchrutscht. Beispielsweise ist mir die hier gegenständliche Vorlage:Infobox Radfernweg erst seit wenigen Wochen bekannt, obwohl die dortigen Spielereien (Kombination mehrerer Text-Teile) schon seit über 2 Jahren bestehen. Beim Entdecken dieses „Leckerbissens“ hatte ich sofort die Befürchtung, dass die Frage nach einem weiteren Ausbau nur eine Frage der Zeit ist. Weniger als 2 Monate später bewahrheitet sich tatsächlich, dass jemand das zumindest wünscht und vorschlägt. (Auch wenn es diesmal vielleicht noch nicht umgesetzt wird.)

Ich denke daher, dass die Befürchtungen nicht völlig übertrieben sind und der CSS-Hack in wirklich absehbarer Zeit vollständig beseitigt werden sollte (evtl. mit der Ausnahme von Spezialseiten, wegen dem Problembären MediaWiki:Specialpage-helplink; dies ist zumindest nur Admins zugänglich).

Ein Ausblenden der <indicator>-Tags im Namensraum 1 würde ich auch als verschmerzbaren Verlust ansehen. Gruß --Entlinkt (Diskussion) 23:36, 30. Apr. 2016 (CEST)

Dann mach es halt innerhalb der nächsten Wochen erstmal nur für die Koordinaten. Sie sind der Hauptkackpunkt und die Stelle, wo das am meisten auffallen wird. Wenn es da halbwegs ruhig bleibt, kann der Rest später unauffällig nachgezogen werden.

• Die Gefahr, dass jemand aus der VWS anfängt, in die Koordinatenvorlagen reinzuprogrammieren, sehe ich als gering.
• Sie sind wohl erstmal alle vollgeschützt.
• Sie sind ohne maintainer, ohne jemanden, der sich damit auskennt. Bergi hatte das System mal komplett überarbeitet und ist leider hier inaktiv; seitdem ist unser KnowHow weg. Wenn da mal dringend was anzupassen wäre, stünden wir ganz schön auf dem Schlauch.
• Der einzige Nicht-Stratege, der für unüberlegte Handlungen in Frage käme, hat Zoff mit den Geo-Leuten.

Unser regelmäßiger Testfall für ein Lemma aus einem Wort wäre

• Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch und aus mehreren Wörtern
• Naturschutzgebiet Dünenkiefernwald am Langhagensee (einzeln)
• Volkskunde- und Freilichtmuseum Roscheider Hof (all exzellent)

Innerhalb der Vorlage kein globales nowrap, sondern eine semantische Gliederung einzelner Blöcke, die umbrochen werden können. Vor allem bei AllCoordinates.

• Ggf. zentralisiert in einer gemeinsamen Untervorlage von Vorlage:Coordinate nur für die schlussendliche Darstellung von Koordinaten.
• Hier muss zunächst ein ansehnliches Design her. Die Negation der Optik kann nur Strukturalisten und geschmähte Theoretiker überzeugen.

Mach deine Absichten anschließend besser auf einer zentralen Geo-Fanpage bekannt.

• Nicht fragen, ob; sondern vorher die allgemeinzuträglichen Notwendigkeiten und technischen Gründe darlegen, und Beta-Beispiele präsentieren. Die vollständige Offenlegung könnte die Bevölkerung beunruhigen.
• Multi-post Hinweis auf diese zentrale Disk auf diversen anderen interessierten Vorlagen-Doku und sonstigen Projektseiten.

LG --PerfektesChaos 14:05, 1. Mai 2016 (CEST)

Ich habe oben noch vier Testfälle für lange Lemmata ergänzt, allerdings ist Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch nicht wirklich ein langes Wort, weil da jede Menge <wbr> mittels {{DISPLAYTITLE:...}} eingebaut wurden. Außerdem kann man sich das Meiste auch klarmachen, indem man einfach in den Code schaut und sieht, dass in allen Skins im Wesentlichen das Folgende gilt:

.mw-indicators {
	float: right;
}
.mw-indicator {
	display: inline-block;
}

Umbruchverhalten, Zusammenspiel mit langen Lemmata und alles andere folgen daraus. Und solchen Schwachsinn wie nowrap baue ich sowieso fast nie irgendwo ein, das ist fast immer falsch. --Entlinkt (Diskussion) 18:21, 1. Mai 2016 (CEST)

Ich glaub’, ich geb’s für den Moment mal wieder auf, da es mir zu frustrierend ist. Damit die bisher gewonnenen Erkenntnisse nicht verloren gehen, fasse ich sie zusammen:

Vielleicht wissenswerte Fakten über absolut positionierte Vorlagen und <indicator>-Tags (→ Entscheidungshilfe)

Fakt	Konsequenzen, falls die absolut positionierten Vorlagen auf <indicator> umgestellt werden
Absolut positionierte Elemente sind dem normalen Fluss vollständig entzogen und überlappen alles andere; <indicator>-Tags sind Inline-Blöcke in einem Float-Container und nehmen teilweise am normalen Fluss teil. Vereinfacht gesagt werden sie von anderen Inhalten (insbesondere vom Lemma) „umflossen“.	Es ergeben sich unvermeidbare Änderungen des Aussehens, die teilweise erwünscht sind (keine Überlappungen mehr), teilweise aber auch evtl. nicht jedem gefallen. Potenziell besonders störend sind Flacker-Effekte durch die Icons der beiden Gadgets MediaWiki:Gadget-osm.js und MediaWiki:Gadget-WikiMiniAtlas.js, die erst während des Ladevorgangs nachträglich eingefügt werden. Dadurch kann es dazu kommen, dass bei geringer Fensterbreite und langer Seitenüberschrift Teile der Seitenüberschrift herumhüpfen (Beispiel).
Vereinfachend nur für Vector und Monobook: <indicator>-Tags stehen im Markup zwischen der SiteNotice und dem Lemma.	Der Bereich über der SiteNotice (genauer: das padding-top des #content-Bereichs) steht für <indicator>-Tags nicht zur Verfügung, und darunter ist kein Platz für mehr als eine Zeile vorhanden. Also müssen alle Elemente mit einer Zeile auskommen (Stichwort „bescheuerte Symbol-Kette“ bei Artikeln, die georeferenziert, ausgezeichnet und gesprochen sind). Andererseits hat dies aber auch Vorteile (Koordinaten „kleben“ nicht mehr am oberen Rand, sondern haben vernünftige Abstände um sich herum). Plänen für einen massiven Ausbau des Oben-Rechts-Spielkrams („beliebig viele Textelemente oben rechts“) sind enge Grenzen gesetzt: Dies wäre zwar im Prinzip möglich und würde in Vector und Monobook auch keine Überlappungen geben, aber trotzdem scheiße aussehen (Beispiel); im Modern-Skin wäre die Darstellung jedoch völlig kaputt (Beispiel).
<indicator>-Tags stehen nicht irgendwo im #mw-content-text-Bereich, sondern an einer kontrollierten Stelle außerhalb dieses Bereichs.	Dies hat klare Vorteile, insbesondere für jeden Client, der kein Browser auf einem Desktop-Computer ist (Stichwort Suchmaschinen: Elemente stehen nicht mehr an Stellen, an denen sie semantisch definitiv nichts zu suchen haben). Es könnte allerdings auch sein, dass manche Anwendungen die Elemente an den unsinnigen Stellen erwarten und gefixt werden müssten. Allerdings sind die beiden Gadgets MediaWiki:Gadget-osm.js und MediaWiki:Gadget-WikiMiniAtlas.js von diesem potenziellen Problem nicht betroffen, dort funktioniert alles. Relativiert wird das Ganze dadurch, dass ein Großteil der Wikipedianer sich ausschließlich für das Aussehen auf dem eigenen Desktop-Computer interessiert.
Wenn in einem Artikel ein <indicator>-Tag vorhanden ist und auf der zugehörigen Diskussionsseite die Vorlage:Defekter Weblink eingebunden ist, erscheint das <indicator>-Tag auch auf der Diskussionsseite.	Es müsste hingenommen werden, dass entweder unerwünschte Objekte auf Artikel-Diskussionsseiten erscheinen oder die Anzeige von <indicator>-Tags im Namensraum 1 generell abgeschaltet wird.
MediaWiki:Specialpage-helplink kann nicht auf <indicator>-Tags umgestellt werden, da dies nicht auf allen Spezialseiten funktioniert.	Für diese Systemnachricht müsste eine andere Lösung gefunden werden, zum Beispiel: Wegfall Ersatz durch MediaWiki-eigene Hilfe-Links Positionierung im normalen Fluss (bereits der Fall auf Special:Changeemail, weil unser ach-so-tolles CSS/JS dort völlig unwirksam ist) Behalten der absoluten Positionierung nur für Spezialseiten
MediaWiki-eigene Hilfelinks, die insbesondere auch auf jeder Kategorieseite vorkommen, verhalten sich in jeder Hinsicht wie <indicator>-Tags mit dem Bezeichner name="mw-helplink", der nicht geändert werden kann.	Die Wahl der Bezeichner für Vorlagenkonstrukte ist nicht völlig frei. Es ist nicht völlig auszuschließen, dass weitere <indicator>-ähnliche Konstrukte in MediaWiki aufgenommen werden.

Gruß --Entlinkt (Diskussion) 07:43, 2. Mai 2016 (CEST)

Mal ins Unreine gedacht:

• Es gibt nur noch einen Globus-Icon oben rechts, der ein innerer Link auf den Seitenfuß ist.
• Dort stehen innerhalb des content area, also oberhalb der Kats, die Koordinaten in normaler Schriftgröße.

Wenn ich in Atom auf das blaue Dingens klicke, komme ich auf den Player am Seitenfuß. Das grüne Sternchen bringt mich ebenfalls zum Ende und sagt Näheres über die Version.

AllCoordinates steht vermutlich schon meist an einem richtigen Ort im Artikel.

• Ein Bot könnte mehr als 100.000 Artikel binnen eines Vierteljahres mit einer geeigneten Auffangvorlage (zunächst ohne Parameter) ausstatten, die noch keinen geeigneten Container haben.
  • Nebenbei könnten auch ein paar eindeutige prettytable aufgemotzt werden.

Vielleicht geht aber ein absolutes Quetsch-Konstrukt bei den Standard-Skins oberhalb der Kats (unterhalb ist nicht mehr page content und Clipping-bedroht).

• absPos vom bottom des #mw-content-text aus [oder beim oft ausgeblendeten printfooter – der lässt sich zumindest erstmal anspringen]?
• Ganz unten auf der Seite ist Ruckeln nicht mehr schlimm, und Benutzer mit JavaScript können situationsabhängig weitere Verfeinerungen vornehmen; etwa erkennen, dass der Zielcontainer noch nicht vorhanden ist, und dynamisch einen hübschen einfügen; also einen gequetschten CSS-Fallback-absPos-Kleinschrift am Seitenfuß in ein echtes Box-div in augenfreundlicher Normalschrift mit margin und padding und bunten Rahmen und so umwandeln.

Die Analyse der Pros und Cons muss ich nicht ausdifferenzieren.

LG --PerfektesChaos 12:05, 2. Mai 2016 (CEST)

Äh, @Entlinkt: LG --PerfektesChaos 18:45, 4. Mai 2016 (CEST)

Ich habe das schon zur Kenntnis genommen, aber (wie etwas weiter oben schon angedeutet) vorerst die Beschäftigung mit dem gesamten Thema aufgegeben, da es mir zu zeitintensiv wird und es sich letztlich ja um Vorlagenkonstrukte dreht, die ich in der vorliegenden Form niemals befürwortet habe (ganz im Gegenteil).

Ich persönlich ziehe als Alternativen zum status quo nur Lösungen in Betracht, die die Software in der „offiziell vorgesehenen“ Art und Weise benutzen, also

• nichts mit absoluten Positionierungen bezogen auf #mw-content-text, auch wenn dies technisch möglich wäre (wobei ich selbst das nicht sehe, da die vorhandenen Abstände zu klein sind, um dort etwas reinzuquetschen und es mit dem „Reinquetschen“ in der Vergangenheit schon schlechte Erfahrungen gab, weil die Vorlagenkonstrukte mit der Zeit tendenziell wachsen, der angeblich verfügbare Raum aber nicht);
• nichts mit JavaScript, da ich es für einen grundsätzlichen Fehler halte, Abhängigkeiten zwischen Artikelinhalten und site-spezifischem JavaScript zu erzeugen; site-spezifisches JavaScript eignet sich wunderbar für allerhand nützliche Werkzeuge und meinetwegen auch für Spielereien in Navigationsbereichen, aber nicht für Artikelinhalte.

Bei allen Vorschlägen, die grundsätzlich die Platzierung von Geo-Gedöns oben rechts (auch nur teilweise) in Frage stellen, sehe ich darüber hinaus das Problem, dass man dies auch erstmal dem WP:GEO-Projekt verklickern müsste, was ich mir eher schwierig vorstelle, weil man dort dazu tendiert, die Ecke oben rechts als „Markenzeichen“ anzusehen und auch allgemein ziemlich merkbefreit ist. Ich verweise als Beispiel nur mal auf diese Diskussion, die zu diesem Edit geführt hat. (Kurz zusammengefasst: Es ging in der Diskussion um hausgemachte Kollisionsprobleme mit {{All Coordinates}} und man hätte die Chance gehabt, das Scheißteil aus der Bapperlecke zu entfernen, stattdessen hat man aber dafür gesorgt, dass es auf Kategorieseiten nur in der Bapperlecke stehen kann, weil zu dem Zeitpunkt ja nichts anderes auf Kategorieseiten in der Bapperlecke stand; mittlerweile gibt es aber auf jeder Kategorieseite einen Hilfelink, so dass die Bapperlecke dort besonders beschissen aussieht, da auf engstem Raum mehrere verschieden große Icons und Texte in verschiedenen Schriftgrößen zusammenkommen.)

Ach so, vielleicht sollte man nochmal klarstellen, worum es in den letzten Beiträgen konkret geht. Es steht im Raum, folgendes in MediaWiki umzusetzen:

1. Hinzufügen der Regel

   #mw-content-text {
   	overflow: hidden;
   	position: relative;
   }
   

   zu allen Skins.
2. Blockieren von position: fixed im Inline-CSS.

Punkt 1 verhindert Elemente mit position: absolute außerhalb des regulär beschreibbaren Bereichs, aber nicht solche mit position: fixed, weshalb letzteres durch Punkt 2 explizit verboten werden müsste. Erklärtes Ziel dieser Maßnahme ist es, dass von Benutzern eingebrachte Inhalte wegen Sicherheitsbedenken nicht mehr außerhalb der offiziell dafür vorgesehenen Bereiche erscheinen können.

Momentan weiß ich wirklich nicht, was man diesbezüglich tun sollte. Ich tue jedenfalls erstmal nichts, da ein Umbau auf <indicator> auch erhebliche Nachteile hätte (siehe #Fakten) und warte ab, ob irgendwann unmittelbarer Handlungszwang entsteht. In dem Fall würden sich wahrscheinlich viele der Nachteile ganz plötzlich in Luft auflösen, wenn man nur noch die Wahl hat, ob die Konstrukte überhaupt noch sichtbar sind oder gar nicht. --Entlinkt (Diskussion) 19:48, 4. Mai 2016 (CEST)

Falls sich überhaupt noch jemand für das Thema interessiert:

Wenn man den Inhalt dieses Threads und die Kommentare zu gerrit:186768 (insbesondere den ersten Kommentar vom 15. Februar 2015) aufmerksam liest, kann man sich einiges zum Thema „Clipping“ erschließen. Damals war der Plan allerdings noch, nur .mw-body zu clippen, mittlerweile will man wohl evtl. stattdessen .mw-body-content oder sogar #mw-content-text clippen. Auch bemerkenswert ist, dass die absolut positionierten Elemente dort als „legacy indicators“ bezeichnet werden.

Erst gestern ist an anderer Stelle bekräftigt worden, dass die Clipping-Pläne nach wie vor aktuell sind, dass man die meisten Vorarbeiten in der Software (die selbst auch an manchen Stellen betroffen ist) bereits erledigt habe, und dass die Communities ihre „legacy indicators“ migrieren sollen. Man wartet ab, dass sie dies möglichst selbst tun, und will wohl irgendwann dazu übergehen, ihnen bei der Migration zu „helfen“, was auch immer das heißen mag.

PS: Die polnische Wikipedia hat ihre Koordinatenvorlage (pl:Szablon:Koordynaty) schon im Dezember 2014 auf <indicator> umgestellt. Gruß --Entlinkt (Diskussion) 18:30, 26. Mai 2016 (CEST)

Gadget zum Testen

Hallo,

ich bin mittlerweile zu der Überzeugung gelangt, dass das Erstellen von #Mockups im β-dewiki (siehe hierzu auch die zugehörige Kategorie) wenig zielführend ist, da es

• wahnsinnig zeitaufwendig ist,
• wenig Beachtung findet,
• die Simulation anhand einer begrenzten Anzahl willkürlich erstellter Seiten ohnehin nur unzureichend realistisch ist.

Ich habe daher ein Gadget vorbereitet, das hier in diesem Wiki benutzt werden kann und „meinen“ Vorschlag für alle Skins realistisch illustriert.

Gadget zur Demonstration der Umstellung absolut positionierter Vorlagen auf <indicator>-Tags
JavaScript-Komponente
/* * Dieses Gadget simuliert, wie es aussehen würde, wenn die in der „Bapperlecke“ * stehenden Vorlagen statt der absoluten Positionierung das <indicator>-Tag * verwenden würden. Es ist nur ein Testlauf und kann jederzeit entfernt werden. */ /* * Workaround für das Kompatibilitätsproblem mit [[Vorlage:Defekter Weblink]]: * Pauschale <indicator>-Unterdrückung auf Artikeldiskussionsseiten */ if (mw.config.get( 'wgNamespaceNumber' ) !== 1) { mw.hook( 'wikipage.content' ).add( function ( $content ) { $content .find( '#coordinates, #editcount, #issnlink, #shortcut' ) .filter( ':last' ) .prependTo( '.mw-indicators' ) .wrap( '<div class="mw-indicator" style="font-size: x-small;"></div>' ); } ); }
CSS-Komponente
/* * Dieses Gadget simuliert, wie es aussehen würde, wenn die in der „Bapperlecke“ * stehenden Vorlagen statt der absoluten Positionierung das <indicator>-Tag * verwenden würden. Es ist nur ein Testlauf und kann jederzeit entfernt werden. */ /* Geruckel beim Seitenaufbau reduzieren */ .client-js #mw-content-text #coordinates, .client-js #mw-content-text #editcount, .client-js #mw-content-text #issnlink, .client-js #mw-content-text #shortcut { display: none; } /* * Schadcode aus [[MediaWiki:Vector.css]] zurücksetzen. Dadurch ist die * vertikale Ausrichtung der mw.notify-Nachrichten wieder so, wie sie sein soll. * Spezialseiten sind wegen [[MediaWiki:Specialpage-helplink]] ausgenommen. */ .client-js .skin-vector:not(.ns-special) .mw-body { position: static; } .client-js .skin-vector:not(.ns-special) .mw-body-content { position: relative; } /* * Schadcode aus [[MediaWiki:Monobook.css]] zurücksetzen. Dadurch ist die * vertikale Ausrichtung der <indicator>-Elemente wieder so, wie sie sein soll. */ .client-js .skin-monobook .mw-indicators { margin-top: 0; } /* * Workaround für hellgelben Hintergrund in [[Vorlage:CoordinateNO]], der im * Modern-Skin zur Unlesbarkeit führt, da die Schrift weiß ist. */ .client-js .mw-indicators #coordinates[style*="background"] { background: rgba(255, 255, 0, .2) !important; } /* Simulation der Regel zur Linkformatierung aus [[MediaWiki:Common.css]] */ .client-js .mw-indicators a.external[href^="//de.wikipedia.org"], .client-js .mw-indicators a.external[href^="http://de.wikipedia.org"], .client-js .mw-indicators a.external[href^="https://de.wikipedia.org"], .client-js .mw-indicators a.external[href^="//www.wikidata.org"], .client-js .mw-indicators a.external[href^="http://www.wikidata.org"], .client-js .mw-indicators a.external[href^="https://www.wikidata.org"], .client-js .mw-indicators a.external[href^="//tools.wmflabs.org"], .client-js .mw-indicators a.external[href^="http://tools.wmflabs.org"], .client-js .mw-indicators a.external[href^="https://tools.wmflabs.org"] { background-image: none; padding-right: 0; }

Nochmal zur Erinnerung: „Mein“ Vorschlag war derjenige mit den folgenden Eigenschaften:

• Gleichzeitige Umstellung aller verbliebenen absolut positionierten Vorlagen;
• Entfernen aller zugehörigen CSS-Hacks zwecks Aufhebens ihrer Schadwirkung;
• Vorläufiges Beibehalten der Einschränkung, dass jede Wikiseite nur ein Textelement in der „Bapperlecke“ enthalten kann, aber gleichzeitiges Schaffen der Voraussetzungen, so dass jeder Sichter dies eigenverantwortlich und ohne Mithilfe eines Admins ändern kann (da die gesamte Infrastruktur aus dem MediaWiki-Namensraum herausgedrängt und in Vorlagen abgedrängt wird, die bereits jetzt nur 3/4-geschützt sind).

Ich benutze den Code selbst und würde mich freuen, wenn die eine oder andere Person das auch mal ausprobiert und Rückmeldungen gibt.

Sicherlich gibt es zu diesem Vorschlag auch Alternativen, zum Beispiel solche, die die Anzahl dauerhaft zu behaltender Hacks im MediaWiki-Namensraum und somit auch die Anzahl lokal erzeugter Bugs dramatisch erhöhen.

Viele Grüße --Entlinkt (Diskussion) 20:21, 5. Jun. 2016 (CEST)

Beim Testen des Gadgets beobachtete Besonderheiten, Bugs usw.

1. Beobachtung: Auf der Seite Wikipedia:WikiProjekt Vorlagen/Unbenutzte Vorlagen sind ohne das Gadget keine Koordinaten sichtbar. Mit dem Gadget sind Koordinaten sichtbar, diese haben manchmal keine OpenStreetMap/WikiMiniAtlas-Icons, manchmal haben sie aber auch welche und manchmal sogar sehr viele.
   Deutung: Dass die Koordinaten überhaupt sichtbar werden, ist normal und wäre auch im Echtbetrieb so, weil <indicator>-Elemente vom Parser aus dem <div style="display: none;"> herausgezogen werden. Die Probleme mit der Anzahl der Icons sind wohl durch mehrfaches Vorkommen der ID #coordinates und Race Conditions verursacht und wären im Echtbetrieb nicht zu erwarten. --Entlinkt (Diskussion) 20:29, 6. Jun. 2016 (CEST)

Mobilversion

Gemeldet in Phabricator
Task T75299

Tja, @PerfektesChaos: Du schriebst 2016 „Mobil wird das schon irgendwann global unterstützen“. Leider 2020 immer noch Fehlanzeige, auch die App weiß nichts damit anzufangen.

1. Gibt es dazu überhaupt schon irgendwo einen Bugreport/Featurerequest auf Phabricator?
2. Wäre es denkbar, nun doch eine CSS-Übergangslösung nur für die Mobilversion zu basteln? Habe noch keine konkrete Idee, aber irgendein mobileonly-Element über TemplateStyles ließe sich sicher basteln.

Gruß–XanonymusX (Diskussion) 21:13, 9. Mai 2020 (CEST)

Es wird sicher schon Dutzende von Phab-Erwähnungen der Angelegenheit geben.

Die Mobilversion war der aktuelle Grund für die Entwicklung der Seitenindikatoren.

Bei Mobil wird aller Seiteninhalt außerhalb des Content-Rahmens abgeschnitten, also alles was außerhalb des grauen Bereichs steht.

Bei Desktop wird das früher oder später auch kommen.

Der um 2004/2005 in der enWP entstandene Hack, den unsere Herzchen übernommen hatten, hatte mittels position:relative Elemente von irgendwoher über irgendwelche vermuteten Lücken und zwischen die Zeilen der damaligen Desktop-Skins dargestellt. Deshalb wurden die Seitenindikatoren programmiert, um die enWP-Icons zu unterstützen und sichtbar zu machen.

position:relative ist kein float, das drübergemalte Element nimmt keinerlei Rücksicht darauf, ob und was an der Stelle bereits steht. Deshalb kommt es zwangsläufig irgendwann zu Überlappungen, wenn längere Seitenüberschriften oder unerwartete Meldungen und Boxen bereits auf dem fertigen HTML-Dokument stehen.

Dein Plan mit TemplateStyles würde schon mal daran scheitern, dass du versuchst, aus dem content-Bereich heraus vermutlich nach außerhalb des grauen content zu malen; das wird jedoch abgeschnitten.

Weiterhin bräuchtest du eine große Stelle auf dem Bildschirm, wo garantiert niemals was stehen könnte, und Platz genug wäre, um gleich mehrere Icons anzuzeigen. Da das immer nur mit position:relative drübergemalt wird und keine vorhandenen Elemente beiseiteschiebt, müsstest du also zuallererst nachweisen, wo du denn zuverlässig den verschenkten freien Platz auf dem Bildschirm der Mobilgeräte siehst?

Die Seitenindikatoren sind float, sie verschaffen sich den benötigten Platz und schieben die nachfolgenden Elemente entsprechend weiter.

Von „Übergangslösung“ und Gehacktem habe ich gründlich die Nase voll; ich bin seit etlichen Jahren zu einem wesentlichen Teil damit beschäftigt, die Bastelarbeiten der frühen Jahre durch solide und robuste Strukturen zu ersetzen.

Ach ja, wir konnten noch nie Koordinaten von Artikelgegenständen auf Mobilgeräten darstellen. Aus demselben Grund: Unser Hack würde versuchen, Inhalte außerhalb des erlaubten grauen Bereichs anzuzeigen. Was natürlich schlau ist, wenn ich in Venezia auf der Piazza San Marco stehe, den Artikel über den Drogenpalast auf dem Handy habe und nun auf der Landkarte nachgucken will, wie ich zu dieser Sehenswürdigkeit käme. Das kann ich dann hinterher im Hotelzimmer auf dem Desktop des Hotels nachlesen. Unsere Geo-Leute kennen dieses Problem auch schon seit vielen Jahren, machen aber auch nichts.

VG --PerfektesChaos 14:14, 10. Mai 2020 (CEST)

Hab den Task gefunden, dümpelt seit 2014 uninspiriert herum. Wenig motivierend, wie leider so vieles auf Phabricator.

Hm, ja, ich müsste wohl irgendwie brachial eine zusätzliche Leerzeile am Anfang erzeugen; Überlagerungen zwischen mehreren Elementen wären damit aber auch kaum zu vermeiden, gefällt mir natürlich nicht. Sehr ärgerlich. Gruß—XanonymusX (Diskussion) 14:57, 10. Mai 2020 (CEST)