Wikipedia:Projektdiskussion/Verschlimmbesserung der Differenz-Darstellung

Dies ist eine archivierte Unterseite der Seite Wikipedia:Projektdiskussion. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen. Um auf diese Diskussion zu verlinken, kopiere den Seitennamen aus der Adresszeile deines Browsers.

Die neue Differenz-Darstellung mit den Rollfenstern

1. verbrät Seitenfläche für die vielen Rollbalken, je einen pro Text-Abschnitt, deren Textfenster bei mir bisher immer, bis auf allenfalls so eine halbe Zeile am Ende, auf Volldarstellung aufgezogen waren. Die Rollbalken sind also offenbar funktionslos. Wenn es anders wäre und man damit rollen könnte/müsste, wäre man glücklich auf dem Stand des Bearbeitungsfensters, wo ich mich auch beständig ärgere, wenn ich den falschen Rollbalken erwische – Browser-Rollbalken statt den der Editierfläche und umgekehrt. Rollbalken innerhalb einer mit Rollbalken bewegten Fläche sind nur ein Ärgernis! Was soll das also?

2. hat in diesen Subfensters jetzt zu kleine und unleserliche Schrift

3. deren Zeilen sich zudem oft halb überlappen, gerade bei farblich hervorgehobenem Text. Damit sind man dann gerade das gar nicht mehr, was eigentlich verändert worden ist.

Macht ruhig Eure Basteleien, Ihr „innovativen“ Interface-Designer, aber lasst doch anderen wenigstens die Möglichkeit, hier möglichst davon unbehindert mit leidlich tauglichem Werkzeug zu arbeiten.

Wenn etwas zu wünschen wäre, dann dass man endlich eine Darstellung bekäme, in der man wirklich den gesamten Umfang der Änderungen sähe, Steuerzeichen-Eumel usw. inklusive.

--Silvicola ⇨⇦ 10:23, 26. Jun. 2012 (CEST)

Mir ist nicht klar, welche Änderung Du meinst. Ich arbeite hier an einem recht kleinen Monitor, trotzdem gibt es keine Rollbalken. -- Perrak (Disk) 12:21, 26. Jun. 2012 (CEST)

• Was die Rollbalken angeht, so ist vermutlich der IE gemeint. IE (<9?) reagiert anscheinend (möglicherweise auch unangemessen) auf neuere CSS-Elemente in der Diff-Darstellung. Das ließe sich abstellen, nachdem man die Ursache identifiziert hat.
• Traditionell wird standardmäßig die zeilenorientierte Diff-Darstellung gewählt. Sie wird einerseits als einfacher angesehen, bringt aber je nach Art der Änderung auch Nachteile mit sich.
• Eine Alternative ist die integrierte Diff-Darstellung. Sie wird aber nicht von allen Benutzern goutiert und kann je nach Art der Änderung auch irritieren. Mit Benutzer:Schnark/js/diff gibt es die Möglichkeit, zwischen verschiedenen Formen zu schalten und bei bestimmten Änderungen auch Parameter zu justieren.
• Es handelt sich nicht um „Eure Basteleien“, sondern um Versuche, die mitunter schwer nachvollziehbaren Veränderungen für möglichst viele Benutzer erkennbar zu machen.

VG --PerfektesChaos 12:51, 26. Jun. 2012 (CEST)

Spezial:Einstellungen#mw-prefsection-gadgets → Lesehilfen → Stellt Versionsunterschiede in den bisherigen Farben dar.--the artist formerly known as 141.84.69.20 13:07, 26. Jun. 2012 (CEST)

Ich nutze den Firefox 13.0.1 unter Linux; es kann also nicht am IE liegen. JavaScript habe ich regelmäßig nicht an, weil es alles so träge macht, dass ich beim Editieren deutlich mehr Fehler mache; ein Skript wäre also gewiss keine Verbesserung.

Das Problem scheint nicht bei den gewöhnlichen, etwa aus der Versionsgeschichte aufgerufenen Diffs aufzutreten, sondern nur bei dem Diff, das ungesichteten Seiten vorgestellt wird. In derzeitiger Darstellung kann ich damit nicht entscheiden, ob ich sichten sollte. Sagt mir jemand, wie ich dieses Vorstellen unterbinden kann? Dann sollen halt andere sichten. --Silvicola ⇨⇦ 17:36, 26. Jun. 2012 (CEST)

Das von "the 141" verlinkte Helferlein funktioniert auch ohne JavaScript, da eine reine CSS-Lösung. Der Umherirrende 20:40, 26. Jun. 2012 (CEST)

Jaja, nur leider greift es vermutlich nicht bei den maßgeblichen Stil-Informationen; es sei denn, es erwischt zufällig border-Eigenschaften, die sich auf die Abmessungsberechnung auswirken würden. --PerfektesChaos 20:45, 26. Jun. 2012 (CEST)

Bei den oben erwähnten Eumeln dachte ich insbesondere an das tückische byte order mark, das mir einmal, ich weiß nicht wie (Kopie aus zu Sicherungszwecken angelegter Textdatei?), in eine Bearbeitung geriet, ohne dass ich das die Struktur störende Ding nachher per Diff zu fassen bekommen hätte. Ebenso gibt es manchmal Nachbearbeitungen von Formalisten, die nach ihrem Edit-Kommentar überschüssige Zeilen gelöscht haben, ohne dass im zugehörigen Diff das dann irgendwie zu erkennen wäre. Vermutlich unterdrückt das unterliegende Diff-Tool stillschweigend redundante Zeilenumbrüche, aber leider eben auch Ernsteres wie das BOM und andere Zeichen. --Silvicola ⇨⇦ 17:36, 26. Jun. 2012 (CEST)

Ich kann das Verhalten ausschließlich in einem IE8 reproduzieren; meine FF (vorwiegend Windows) machen die Zicken nicht.

Ich habe einen Browserversions-abhängigen Verdächtigen ausgemacht, der anscheinend aus der allgemeinen Programmierung des Browsers die für scrollbars verantwortliche Einstellung erbt.

Bau doch bitte mal in deine common.css die folgenden Zeilen (ohne „syntaxhighlight“) ein:

TABLE.diff TD DIV {
   overflow: visible;
}

Dann verrate mal, ob die Biester dann noch da sind.

Du kannst auch gleich in der Skin-Werkstatt Bescheid geben.

Schönen Abend --PerfektesChaos 18:52, 26. Jun. 2012 (CEST)

Eben ausprobiert: …/common.css angelegt, nur die obige Stildefinition hineingeschrieben, FF beendet und neu gestartet, Ergebnis: Immer noch überlappernde Zeilen. Das war's also nicht. Ich probiere dann gleich noch mal genauso, ob vielleicht eine zusätzliches mit

font-height:200%;

hochgeschraubte Zeichenhöhe sichtbar was bringt. Nach Vollzug Rückmeldung. Gruß --Silvicola ⇨⇦ 20:52, 26. Jun. 2012 (CEST)

Um das mal wikipedianisch-benutzerkommentatorisch-euphemistisch zu sagen: "Keine Verbesserung". Ich habe allerdings keine Ahnung, was da so an CSS-Eigenschaften von woher so alles zusammengeerbt wird; vielleicht kann ja eine Änderung hier gar nichts bewirken. Vielleicht muss auch ein Minimalrahmen an weiteren Definitionen in …/common.css stehen? Ich lasse jedenfalls die common.css erst mal stehen. Wenn Du andere Vorschläge hast. magst Du sie da gleich explizit eintragen, im Falle eine Reihe von Alternativen alle bis auf die erste mit

/* CSS-Kommentaren */

ausgeknipst, ich kann dann ja alle sukzessive durchprobieren. Gruß --Silvicola ⇨⇦ 21:12, 26. Jun. 2012 (CEST)

Die Einladung ist sehr ehrenwert, aber: Ich kann und darf deine common.css nicht verändern.

Gleichwohl habe ich noch Plan B: Bisherigen Inhalt bitte löschen; stattdessen:

TD.diff-context {
   white-space: normal
}

Wir haben schon ganz andere Kindchen geschaukelt. Liebe Grüße --PerfektesChaos 21:56, 26. Jun. 2012 (CEST)

Schafft auch keine Abhilfe. --Silvicola ⇨⇦ 22:32, 26. Jun. 2012 (CEST)

finis latinum meam indipisci – Ich habe das Ende meines Lateins erreicht.

Gleichwohl habe ich schlaue Kollegen in der Werkstatt, die das sicher noch geknackt bekommen. Nur Mut. Es wird einen weltweiten Fortschritt bringen (falls das nicht schon woanders auf dem Globus gelöst wurde).

Eine neue Spur könnte sich ergeben aus deiner obigen Bemerkung „nicht bei den gewöhnlichen, etwa aus der Versionsgeschichte aufgerufenen Diffs aufzutreten, sondern nur bei dem Diff, das ungesichteten Seiten vorgestellt wird.“ – Das dürften die per Ajax geladenen Geschichten sein? Ich hatte bislang nur die normalen Diffs am Wickel, diese im IE, und bei denen die scrollbars wegbekommen. Dass die Sichtungs-Diffs irgendwie anders wären, wüsste ich jetzt nicht; aber man wird dem nachgehen.

Bis in Kürze --PerfektesChaos 23:00, 26. Jun. 2012 (CEST)

Bei den gesichteten Versionen wird nichts mehr per AJAX nachgeladen und wenn, war es nicht der Diff, sondern der Seiteninhalt.

Ich denke mal, er meint den Versionsunterschied der einem angezeigt wird, wenn man eine Seite mit ungesichteten Versionen bearbeitet (also wo noch Sichtungen ausstehen, dann sieht man über den Bearbeitungsfenster die Änderungen zur letzten gesichteten Version und kann mit einer Checkbox unter der Zusammenfassung, die Änderungen und seine Änderungen in einem Rutsch sichten. Der Umherirrende 18:39, 27. Jun. 2012 (CEST)

Genau den meine ich, den Sichte-mal-das-da-hier-Vorspann, bei dem ich zwar hier sehe, aber das da überhaupt nicht erkennen kann. --Silvicola ⇨⇦ 21:38, 27. Jun. 2012 (CEST)

@Silvicola: Das hat nur teilweise etwas mit deiner Beschwerde zu tun (vor allem hat es nichts mit den Scrollbalken zu tun), aber probier doch mal mein cleanDiff-Skript aus. Dort versuche ich, die schlimmsten Unzulänglichkeiten des Diff-Algorithmus zu beheben. Ich würde mich über Rückmeldungen dazu sehr freuen. --TMg 00:34, 27. Jun. 2012 (CEST)

Hallo TMg,

ich glaube, ich wäre ein untauglicher Beta-Tester, weil ich nämlich immer JavaScript aus habe; sonst gerne. Siehe oben dazu, wieso. --Silvicola ⇨⇦ 21:38, 27. Jun. 2012 (CEST)

Vielleicht mag es auch von der speziellen Seite abhängen? Ich bemerke das Problem hier. Bitte auch deshalb erst mal dort nicht zu sichten! --Silvicola ⇨⇦ 11:23, 28. Jun. 2012 (CEST)

• Ich habe die Seitenstruktur und benutzten CSS der „Diff für Sichtung“ analysiert und kann keinen signifikanten Unterschied zu sonstigen Diffpages finden.
• Rückfragen:

1. Trifft es zu, dass der „Handgriff“ des Verschiebereglers praktisch die gleiche Breite hat wie der Bereich, sich also überhaupt nicht verschieben ließe?
   • Wenn ein Bild dreimal so breit ist wie der verfügbare Platz, dann nimmt der „Handgriff“ ein Drittel ein und zwei Drittel sind Freiraum für Bewegungen.
   • Hier geht es vermutlich nur um ein einziges Pixel. Verfügbar sind beispielsweise 250 Pixel Spaltenbreite; zuvor wurde vom Browser berechnet, dass dort 47 Buchstaben der momentanen Zeile hineinpassen würden; beim Versuch der Darstellung bemerkt der Browser, dass diese 47 Buchstaben aber 251 Pixel breit sind (Rundungsfehler vorher oder nachher); damit du nun das 251. Pixel auch noch sehen kannst, ist er so lieb und malt dir den Scrollbar hin.
2. Sind ausschließlich die geänderten (farbig umrahmten) Elemente betroffen, oder auch der Kontext (also die unveränderten beiden Absätze davor und danach)?
3. Sind immer alle Elemente betroffen, oder bei vielen geänderten Absätzen einige mit, einige ohne Scrollbar?
4. Wenn es nicht immer alle sind und du schrittweise die Breite des Gesamt-Fensters schmaler oder breiter machst: Verschwinden dann einige Scrollbars vorübergehend und tauchen danach wieder auf?
5. Wie verhält es sich eigentlich mit den vertikalen Scrollbars?
6. Wiki-Seiten sollen immer in der benutzer-konfigurierbaren Standard-Schriftart des Browsers dargestellt werden (sans-serif). Wenn du dort (FF:Extras->Einstellungen->Inhalt->erweitert) andere Grundschriften auswählst: Tut sich was?

• Neue Experimente für dein common.css – einfach zusätzlich zu den obigen Beeinflussungsversuchen:
  • Ich habe bei genauerer Durchsicht oben gelesen 2. hat in diesen Subfensters jetzt zu kleine und unleserliche Schrift
  • Ich fand eine andere, aber eigentlich nicht relevante mögliche Auslösung für die scrollbars.

TABLE.diff TD DIV {
   overflow: visible;
}
/* mediawiki.action.history.diff */
table.diff td div {
   overflow-x: visible;
   overflow-y: visible;
}
td.diff-addedline, td.diff-deletedline, td.diff-context {
   font-size: 125%;
   white-space: normal;
}
td.diff-addedline, td.diff-deletedline {
    border-bottom-left-radius: 0;
    border-bottom-right-radius: 0;
    border-top-left-radius: 0;
    border-top-right-radius: 0;
}

• Mit bestimmten Seiten hätte das Phänomen eher nichts zu tun; eher damit, ob beim Vergleich bestimmter Textstellen bei bestimmter Gesamt-Fensterbreite mit bestimmten Fonts bei manchen Browser-Versionen sich ein Berechnungsfehler ergibt.

Immer munter voran --PerfektesChaos 17:20, 28. Jun. 2012 (CEST)

Beantwortung der Rückfragen:

ad 1. Es geht immer nur um vertikale Scrollbars. Horizontakle habe ich nie gesehen. Bei fünf eben betrachteten Beispielen haben sie Bar-Höhe minus 2-3 Pixel; meine schon anderes gesehen zu haben, nämlich nur Bruchteilshöhe des Bars, bin mir da aber nicht mehr sicher.

ad 2. Die mit blassfarbenem Hintergund hervorgehobenen Änderungsstellen verdecken jeweils Unterlängen und Füße der drüberstehenden Zeilen, ob die selbst zu den Änderungsstellen gehören oder zum Vorkontext. Nichttransparente Überdeckung bis knapp zum Querstrich des kleinen Es hoch. Eine ganze unveränderte Zeile im Nachkontext hatte ich nie. Die allerletzte geänderte Zeile ist aber immer voll lesbar, in der "Schindeldeckung" scheint also die Folgezeile ganz vor die Vorgängerzeile gemalt zu werden.

ad 3. Auch in den schmal solid gerahmten, scrollbarlosen Panes tritt das Verdeckungsphänomen auf.

ad 4. Breite verkleinern macht einzelne vorher scrollbarlose Panes zu Scrollpanes. Manchmal scheinen auch beim schnellem Verkleinern manche Scrollpanes kurz ihre Scrollbars zu verliere. Vermutlich ist nur der Update des Browsers zu langsam, da können ja nicht schon gerenderte Rechtecke kopiert werden, sondern sie müssen neu aufgebaut werden.

ad 5. Siehe ad 1.

Danke erst mal und später mehr. --Silvicola ⇨⇦ 20:36, 28. Jun. 2012 (CEST)

ad 6. Ganz verrücktes Ergebnis. Mit den Defaultschriften des Browsers serif/sans-serif bleibt das Problem. Ich habe versuchshalber DingBats (!!) für die Serifen-Schriften im Browser eingestellt. (Offenbar derselbe Parameter wie die außerhalb der spezifischeren Einstellungen allein zu wählende Schrift.) Daraufhin war das ärgerliche Phänomen weg, allerdings wurde vom Browser ganz sicher nicht Dingbats genommen, kein einziges Icon war zu sehen, sondern nur gewöhnliche lateinische Buchstaben in einer recht kleinen Schriftgröße bzw. einer mit viel Luft oben und unten – vielleicht deshalb kein Überschreiben? Womöglich gibt's vom Browser ein "fürsorgliches" Nichtbeachten verrückter Einstellungen, die ihn dekonfigurieren würden, und dann kommt eine zweite Ebene eines Defaults für Schriften nach vorn? Ich rätsle jedenfalls.

--Silvicola ⇨⇦ 22:39, 28. Jun. 2012 (CEST)
Das vielleicht doch Wichtigste habe ich dann doch noch vergessen zu schreiben: Ich erlaube FF nicht, die geladenen Seiten in den von ihnen gewünschten Fonts darzustellen. Geklappt hat es damit aber nur, wenn noch Dingbats eingestellt war. Gruß --Silvicola ⇨⇦ 23:58, 28. Jun. 2012 (CEST)

Bei mir (FF,aktuelle Version) treten die Rollbalken konsistent ausschließlich bei den von dir, Silvicola, signierten Beiträgen auf. Daher gehe ich davon aus, dass es mit einem Sonderzeichen in deiner Sig zu tun hat. Grüße --h-stt !? 14:49, 29. Jun. 2012 (CEST)

Dann tausche ich die Pfeile gegen simplen Text raus, nur die kommen in dem Fall wohl ernstlich als Übeltäter infrage. Sans espoir. --Silvicola ^Disk 19:26, 29. Jun. 2012 (CEST)

Aber das kann es wohl ohnehin nicht sein, bin ich doch automatischer Sichter. Ich kann also gar keine ungesichteten Edits machen. --Silvicola ^Disk 19:35, 29. Jun. 2012 (CEST)

Ein Patient, der Läuse hat, kann auch Flöhe haben. Es gibt hier offenkundig zwei völlig unabhängige Problemstellungen:

1. scrollbars, bei dir oder auch im IE8, und bei h-stt
2. Font, Schriftgröße, überlappende Zeilen

Zur Problematik 1 (scrollbars):

• Es kann sein, dass deren Erscheinen irgendwann extra eingeführt wurde, weil bei manchen Benutzern das wrap, also das Zerteilen des Textes notfalls mitten im Wort nicht funktioniert. Bei ihnen könnte ein Wort (wie eine URL), das länger ist als die Spalte breit wäre, sonst vielleicht nicht gezeigt werden? Hmm. Seltsam. Mal analysieren. (Werkstatt-Kollegen???? Hilfäää!)
• Wer ein solches Problem nicht hat, kann dann lästige scrollbars unterdrücken, wenn sie nur in seinen Browsern entstehen, weil durch Rundungsfehler 1 oder 3 Pixel arithmetisch zu fehlen scheinen; was optisch noch nicht einmal der Fall sein muss. In allen Sprachvrianten und Situationen sollte aber greifen:

table.diff td div {
   overflow-x: visible;
   overflow-y: visible;
   overflow: visible;
}

@h-stt: Das kann gut sein, dass die beiden Dingbats-Pfeile (oder was immer das sein mag) ebenfalls auslösend für eine Fehlberechnung sind; in meinem FF13@WinXP grad kommt Silvicolas Sig Rollbalken-frei rüber.

Was das Thema Schriftgröße, überlappende Zeilen, Font angeht: Das scheint mir ein persönliches Einzelschicksal zu sein; offensichtlich haben ungeeignete Kombinationen in der Konfiguration dazu beigetragen.

• Die Schriftgröße in den diff-Abschnitten ist jetzt in den Wiki-Projekten auf 88 % reduziert worden.
  • Eine Reduktion hatte es schon immer gegeben; ob das nun 88 % waren oder vielleicht nur 90 % zur rot-gelb-grün-Zeit, weiß ich jetzt nicht.
  • Die CSS- und HTML-Vorgaben sind absolut standardkonform.
  • Mein Eindruck ist, dass deine Kombination Linux+FF13 die Schriftverkleinerung nicht richtig bewerkstelligt. Soweit ich das überblicke, erbt FF das Schrift-Rendering vom Betriebssystem.
• Wikis definieren selbst keinen eigenen Font für die Seitendarstellung, sondern erben pauschal die (benutzerkonfigurierbare) Standardvorgabe des Browsers (sans-serif).
  • Die Geschichte mit „in den von ihnen gewünschten Fonts“ nicht zulassen kannst du im Prinzip rausnehmen; zumindest für Wikis geschieht das allenfalls auf einzelnen Abschnitten: Um Altgriechisch, Hebräisch oder Thai einheitlich darstellen zu können, werden ggf. Tipps gegeben.
• Es kann sein, dass in den in deinem Font enthaltenen geometrischen Daten bezüglich Schrifthöhe, Oberlänge, Zeilenhöhe usw. Angaben nicht konsistent sind, oder Algorithmen sie nicht verstehen oder nicht sachgerecht umsetzen.
• Du schreibst, dass dein System erlahmt, wenn du JS zulassen würdest; Linux ist aber eigentlich recht flott. Mit Verlaub, ich gewinne den Eindruck, dass dein Maschinchen etwas älter ist, die Linux-Distribution vielleicht auch, und dies mit dem brandneuen FF13 zusammentrifft. Das mag Inkompatibilitäten begründen.
  • Es könnte sein, dass es ein zufälliges zeitliches Zusammentreffen gibt von „neues Diff-Layout“ und „Upgrade auf neuen FF10,11,12,13“ .
• Für dich persönlich können wir mit einigen Anweisungen entgegenzuwirken versuchen; für den Anfang sollte die Schriftverkleinerung unterbunden werden mit:

td.diff-addedline, td.diff-deletedline, td.diff-context {
   font-size: 100%;
   white-space: normal;
}

Schönes Wochenende --PerfektesChaos 22:15, 29. Jun. 2012 (CEST)

Nur zur Firefox/Linux-Situation: Bei mir läuft auf einem alten Notebook (Linux, Pentium M 1.6 GHz) der aktuelle Firefox 13 schneller als Firefox 3.6. Irgendwelche Scrollbars habe ich in den Diffs auch manchmal - bin ich aber zu faul das nun genau herauszusuchen, wie es bei mir ist (hilft ja wohl sowieso nicht). Viel Spaß noch beim Herumraten und viele Grüße --Saibo (Δ∇) 00:08, 3. Jul. 2012 (CEST)

Danke Dir für Deine Bemühungen. Ich werde wohl in absehbarer Zeit das Gerät wechseln. Aber es hätte ja auch sein können, dass andere das Problem ganz genauso haben und nur nichts davon verlauten lassen. Gar nicht zu sichten scheint verbreitet zu sein, da müsste das Problem ja gar nicht stören.

Mir scheint, dass schon die Browser in viel zu vielen Fitzelchen konfigurierbar sind, das führt dann sicher zu einer Zersplitterung der Nutzergemeinschaft, die die Wartung zu einer Mühsal macht. Und wenn hier auf Wikipedia noch hundert Benutzereinstellungen sich dem überlagern, wird es für Deinereins nicht gerade einfacher. Gegen vernünftige verbindliche Festlegungen ist gar nichts zu sagen. Make it as simple as possible!

Gruß --Silvicola ^Disk 03:41, 3. Jul. 2012 (CEST)

Ich habe gerade Bug 39036 gefunden, wo sich auch darüber beschwert wird, vielleicht möchte jemand noch Infos dort ergänzen. Der Umherirrende 19:59, 6. Aug. 2012 (CEST)

---

Zusammengefasst auf Wikipedia:Technik/Skin/Werkstatt/Baustellen/Diffpage mit Scrollbars

Letzter Beitrag 7. August 2012