Span vs &zwnj

[Rolf B]

Hallo alle,

unser Wiki hat teils recht tiefe Hierarchien für die Artikel, was zu Überschriften wie

JavaScript/DOM/‌Node/‌firstChild

oder

JavaScript/‌Tutorials/‌OOP/‌Objekte und ihre Eigenschaften

führt und, vor allem bei kleinen Viewports, dazu führt, dass die Überschrift aus den Viewport hinausragt.

Um das zu lösen, hatte ich im Makeover-Skin zwei Ansätze verfolgt:

1. <span>JavaScript/</span><span>DOM/</span><span>Node/</span><span>firstChild</span>, mit einem display:inline-block auf dem span. Dann bricht er zwischen den spans bedarfsweise um.
2. JavaScript/&zwnj;DOM/‌&zwnj;Node/‌&zwnj;firstChild
3. JavaScript/<wbr>DOM/‌<wbr>Node/‌<wbr>firstChild

Begonnen hatte ich mit (1), aber wie man hier sehen kann (Edit: dieser Link erzwingt den Makeover-Skin, nur für diese Seite), ist das unbefriedigend. Ohne Margin ist ist / und T zu dicht aneinander, mit einem margin-right am Span ist es an den anderen Stellen zu viel. Ob ich /</span><span> oder </span>/<span> nehme, ist dabei egal. Mit </span><span>/ passt zwar das /T, aber dafür t/ nicht mehr.

Deswegen hatte ich Variante mit dem Zero-Width Non-Joiner genommen. Visuell ist er komplett unauffällig und der Browser bricht an dieser Stelle um, wenn nicht genug Platz ist. Prima.

Aber jetzt kam Mattias und sagt: Der ZWNJ wird bei Copy+Paste mitkopiert und fällt dabei zunächst überhaupt nicht auf. Aber der Link, den man auf diese Weise generiert, ist kaputt. Das schlimme ist: Ein Zero-Width Space bemerke ich, wenn ich mit zeichenweise über einen String laufe, der Cursor bleibt dann kurz stehen. Beim ZWNJ ist das nicht der Fall.

Ich habe noch versucht, die ZWNJ durch ein <wbr> Element zu ersetzen, das hatte aber den gleichen Effekt wie die span-Lösung ohne Margins.

Ich bräuchte also eine Lösung, die beides vereint: Transparenz gegenüber Copy+Paste, visuell korrekte Zeichenabstände und Zeichenumbruch an vorgegebenen Stellen. Gibt's das?

Rolf

[Gunnar Bittersmann]

@@Rolf B

Begonnen hatte ich mit (1), aber wie man hier sehen kann, ist das unbefriedigend. Ohne Margin ist ist / und T zu dicht aneinander, mit einem margin-right am Span ist es an den anderen Stellen zu viel.

Nö, da sehe ich nichts, was zu deiner Beschreibung passt. Die Schrift sieht in allen 4 Fällen gleich aus und von margin-right: 2px ist selbst im Entwicklertool nichts zu sehen.

Aber jetzt kam Mattias und sagt: Der ZWNJ wird bei Copy+Paste mitkopiert und fällt dabei zunächst überhaupt nicht auf. Aber der Link, den man auf diese Weise generiert, ist kaputt.

?? Was hat ein URL mit dem Text der Überschrift zu tun? Was in der Überschrift ein Leerzeichen ist, ist im URL ein Unterstrich. Und warum sollte jemand den Text der Überschrift kopieren, wenn sie den URL kopieren will?

Aber das Problem sind nicht die Zeilenumbrüche, sondern:

unser Wiki hat teils recht tiefe Hierarchien für die Artikel, was zu Überschriften wie „JavaScript/DOM/‌Node/‌firstChild“ oder „JavaScript/‌Tutorials/‌OOP/‌Objekte und ihre Eigenschaften“ führt

Da liegt das Problem. Was sich leicht beheben lässt: Überschriften sind das Eine und Breadcrumbs sind etwas Anderes. Breadcrumbs gehören nicht in die Überschrift.

Jolan tru

[Rolf B]

Hallo Gunnar,

...Hierarchie...

Da liegt das Problem.

Ja, und Matthias will auch dran arbeiten

Was sich leicht beheben lässt

Gar nicht. Das sind halt die Titel im Wiki, und das Wiki zeigt das so an. Man muss alle Seiten in das "Root-Verzeichnis" verschieben und Redirects hinterlassen.

Was hat ein URL mit dem Text der Überschrift zu tun

Man merkt, dass Du kein Wiki-Autor bist. Wenn ich einen Artikel X schreibe und darin auf einen Artikel Y verweisen will, dann ist es relativ häufig so, dass man diesen Artikel auf einem zweiten Tab öffnet, dort die Überschrift von Y kopiert und in X ein [[Foo/Bar/Baz/Y|Y]] erstellt.

Wenn jetzt &zwnj hinter den / stehen, dann landen die unsichtbar mit in den [[ ]] und der Link ist fritte.

Ah, sag das doch gleich, dass man sich das in Googles Spion anstatt in einem vernünftigen Browser ansehen soll!

Ich hätte was anderes sagen müssen und editiere das gleich oben hinein: Bitte aktiviere den Makeover-Skin, wie im Vereinsforum erbeten. Oder hast Du den im FF aktiviert, warst in Chrome aber nicht angemeldet und hast den Selfhtml-Skin als Default bekommen? Füge im Zweifelsfall mal ?useskin=makeover an die URL an. Das editiere ich auch noch oben rein. Die Umbruch-Einfügung erfolgt nur in diesem Skin, und dann sollte das auch im Firefox passieren. Nunito hosten wir natürlich selbst. Sorry, da war ich unaufmerksam.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Was hat ein URL mit dem Text der Überschrift zu tun

Man merkt, dass Du kein Wiki-Autor bist.

Man merkt, dass du kein Designer bist. Wiki-Autoren sind hier ziemlich schnuppe. Die relevante Frage ist: Erwarten Nutzer des Wikis Breadcrumbs in Überschriften?

Ich hätte was anderes sagen müssen und editiere das gleich oben hinein: Bitte aktiviere den Makeover-Skin, wie im Vereinsforum erbeten. Die Umbruch-Einfügung erfolgt nur in diesem Skin, und dann sollte das auch im Firefox passieren. Nunito hosten wir natürlich selbst.

Du stellst die Frage hier im öffentlichen Forum. Da ist es nicht hilfreich zu sagen „aktiviere den Makeover-Skin, wie im Vereinsforum erbeten“. Das Problem sollte für alle ersichtlich sein, ohne dass man dazu irgendwas aktivieren müsste, noch dazu etwas, wo man gar nicht rankommt. („Problem“ bezieht sich auf das technische, nicht auf das eigentliche Problem.)

Jolan tru

[Rolf B]

Hallo Gunnar,

Die relevante Frage ist: Erwarten Nutzer des Wikis Breadcrumbs in Überschriften?

Diese Frage wird von Mediawiki ab Werk mit "Ja" beantwortet. Der Titel des Artikels ist Foo/Bar/Baz/Y, nicht Y.

Ob das die richtige Antwort ist, ist natürlich eine andere Frage. Kennst Du die richtige Antwort? Bist Du überhaupt ein Nutzer des Wiki? Oder fragst Du für einen Freund 😉?

Die eigentliche, ebenenweise klickbare Breadcrumb wird ohnehin nochmal unter der Überschrift angezeigt.

Ich kann sicherlich für die Anzeige ändern, dass nur der letzte Teil des Lemmas gezeigt wird. Aber ich kann nicht spontan sagen, ob das irgendwas anderes kaputtmacht.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Die relevante Frage ist: Erwarten Nutzer des Wikis Breadcrumbs in Überschriften?

Diese Frage wird von Mediawiki ab Werk mit "Ja" beantwortet. Der Titel des Artikels ist Foo/Bar/Baz/Y, nicht Y.

„Ab Werk“ heißt: das kann man anpassen?

Ob das die richtige Antwort ist, ist natürlich eine andere Frage. Kennst Du die richtige Antwort? Bist Du überhaupt ein Nutzer des Wiki? Oder fragst Du für einen Freund 😉?

Du möchtest einen Nutzer-Test durchführen.

Die eigentliche, ebenenweise klickbare Breadcrumb wird ohnehin nochmal unter der Überschrift angezeigt.

Ein ziemliches Indiz dafür, dass der Breadcrumb nicht in der Überschrift stehen sollte.

Jolan tru

[Matthias Scharwies]

Servus!

Hallo Gunnar,

...Hierarchie...

Da liegt das Problem.

Das Problem sind die über Jahre gewachsenen Strukturen, die hier beschrieben sind:

Hilfe:Wiki/Wikistruktur

Manches haben wir aus der Doku übernommen, wie @dedlfix hier kritisiert ^[1], anderes wie die Einteilung [[Portalseite/Hauptseite/Unterseite]] sorgt nur bedingt für Übersicht und erforderte z.B. den konsequenten Einsatz der Fortsetzungsvorlage und mehr Klicks für Personen, die unsere Artikel nutzen.

Ja, und Matthias will auch dran arbeiten

Was sich leicht beheben lässt

Gar nicht. Das sind halt die Titel im Wiki, und das Wiki zeigt das so an.

Wir hatten es ja schon öfter diskutiert, dass sich manches nicht sortenrein in HTML, CSS oder JavaScript einsortieren lässt. In diesen Fällen habe ich schon begonnen, die Tutorials direkt in den Hauptnamensraum zu verschieben.

Man muss alle Seiten in das "Root-Verzeichnis" verschieben und Redirects hinterlassen.

Genau! Häufig bestehen aber schon Links auf die ehemaligen WL, sodass es gar nicht zu viel Arbeit ist.

Bei einigen JavaScript APIs habe ich das gestern erledigt. Ich finde, dass das auch im Tab besser aussieht.

Problem ist die „vernünftige“ Wiki-Struktur mit Seiten wie …

• HTML/Attribute/abbr
• JavaScript/DOM/Node/firstChild

Hier wäre ein Umbruch, wie von dir vorgeschlagen, wirklich nützlich.

Alternativ könnte man nur den Text hinter dem letzten / anzeigen, da sich die Seitennamensbestandteile davor bereits in den Breadcrumbs finden.

Problem wären dann einzelne Seiten wie …

• JavaScript/Tutorials/Einstieg
• JavaScript/Tutorials/Einstieg/Programmieren und Debuggen

Während die Unterseite mit "Programmieren und Debuggen" einen aussagefähigen Titel hat, hätte das Tutorial nur den Seitennamen "Einstieg".

Hier könnte man mit {{DISPLAYTITLE}} arbeiten, was in unserer Hilfe zwar beschrieben, aber nicht eingerichtet ist.

→ Thema für den nächsten Workshop?

Herzliche Grüße

Matthias Scharwies

---

1. Umstellung_auf_die_neue_Struktur#weitere_Namensräume_abschaffen
   --dedlfix 11:57, 25. Jun. 2012 (CEST) ↩︎

[Rolf B]

Hallo Matthias,

darüber reden wir, wenn ich aus dem Urlaub zurück bin. Die nächsten 1,75 Wochen sitze ich in der Skihütte oder am Tablet und werde höchstens dummes Geschwätz beitragen, aber keine Wiki-Inhalte und schon gar nicht Wiki-Technik.

Rolf

[Matthias Scharwies]

Servus!

darüber reden wir, wenn ich aus dem Urlaub zurück bin. Die nächsten 1,75 Wochen sitze ich in der Skihütte oder am Tablet und werde höchstens dummes Geschwätz beitragen, aber keine Wiki-Inhalte und schon gar nicht Wiki-Technik.

Genieß die Zeit!

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Problem ist die „vernünftige“ Wiki-Struktur mit Seiten wie …

• HTML/Attribute/abbr
• JavaScript/DOM/Node/firstChild

Auch beim HTML-Attribut „abbr“ könnte die Artikelüberschrift einfach „abbr“ sein. Oder für User hübschere, menschenlesbare Prosa wie „Das HTML-Attribut abbr“.

Auch bei der Node-Eigenschaft „firstChild“ könnte die Artikelüberschrift einfach „firstChild“ sein. Oder sowas wie „Die firstChild-Eigenschaft von DOM-Nodes“.

Die aktuellen Titel spiegeln die Hierarchie wieder, die wäre aber von Breadcrumbs an sich ja schon erfasst - und die Hierarchie interessiert mich als User nur beim Navigieren, nicht beim Lesen.

Ich habe das Gefühl, dass die von @Gunnar Bittersmann vorgetragenen Argumente schon gewichtig sind und aus Benutzerperspektive Sinn ergeben.

Seitentitel wie „JavaScript/DOM/Node/firstChild“ entstehen aus einer sehr technischen Sicht, das ist Autorenperspektive und lässt die Bedürfnisse der User eher außer Acht.

Klar macht die Wiki-Struktur bzw. die Einordnung in dieser Form bei solchen Titeln Sinn - das heißt aber nicht gleichzeitig, dass die Überschrift des Artikels das widerspiegeln sollte. Was die Wiki-Software ermöglicht oder nicht und was da einstellbar ist, wie man das konkret realisieren könnte, das kann ich nicht beurteilen. Aber auch solche Argumente sind technischer Natur, aus Autorensicht, und eigentlich sollte es ja um die Benutzer gehen - meiner Ansicht nach jedenfalls.

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Aloha ;)

Problem ist die „vernünftige“ Wiki-Struktur mit Seiten wie …

• HTML/Attribute/abbr
• JavaScript/DOM/Node/firstChild

Auch beim HTML-Attribut „abbr“ könnte die Artikelüberschrift einfach „abbr“ sein. Oder für User hübschere, menschenlesbare Prosa wie „Das HTML-Attribut abbr“.

Jein, es gibt halt

• abbr (HTML-Element)
• abbr (HTML-Attribut)

Bei style sogar noch mehr. Eine automatische Seitenverschiebung von 100er-Blöcken geht so nicht mehr.

Deshalb kam am Mittwoch auf dem Workshop die JS- oder PHP-Lösung ins Spiel, die Seitentitel abzuschneiden.

Auch bei der Node-Eigenschaft „firstChild“ könnte die Artikelüberschrift einfach „firstChild“ sein. Oder sowas wie „Die firstChild-Eigenschaft von DOM-Nodes“.

Die aktuellen Titel spiegeln die Hierarchie wieder, die wäre aber von Breadcrumbs an sich ja schon erfasst - und die Hierarchie interessiert mich als User nur beim Navigieren, nicht beim Lesen.

Genau!

Und …

• JavaScript/DOM/ParentNode/firstElementChild

verwirrt dann eher.

Ich habe das Gefühl, dass die von @Gunnar Bittersmann vorgetragenen Argumente schon gewichtig sind und aus Benutzerperspektive Sinn ergeben.

Seitentitel wie „JavaScript/DOM/Node/firstChild“ entstehen aus einer sehr technischen Sicht, das ist Autorenperspektive und lässt die Bedürfnisse der User eher außer Acht.

Klar macht die Wiki-Struktur bzw. die Einordnung in dieser Form bei solchen Titeln Sinn - das heißt aber nicht gleichzeitig, dass die Überschrift des Artikels das widerspiegeln sollte. Was die Wiki-Software ermöglicht oder nicht und was da einstellbar ist, wie man das konkret realisieren könnte, das kann ich nicht beurteilen. Aber auch solche Argumente sind technischer Natur, aus Autorensicht, und eigentlich sollte es ja um die Benutzer gehen - meiner Ansicht nach jedenfalls.

Ja, Problem ist halt nicht nur, was gut und richtig wäre, sondern eben auch, wie wir das mit unserer man power dann umsetzen können.

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Ja, Problem ist halt nicht nur, was gut und richtig wäre, sondern eben auch, wie wir das mit unserer man power dann umsetzen können.

Klar - und die Priorität des Problems ist sicherlich nicht so groß, dass es sich lohnt, da viel Manpower draufzuwerfen wenn man eh wenig hat.

Trotzdem empfand ich die von Rolf vorgeschlagene Minimallösung, nur in der Anzeige ausschließlich den letzten Teil des Lemmas anzuzeigen, recht charmant - das verbessert den Status Quo und hört sich, ohne dass ich das recht beurteilen kann, nach wenig Aufwand an.

Die Bedenken, dass dabei was kaputt geht, erschließen sich mir nicht ganz - solange nur die Anzeige im Artikel verändert würde bleibt ja sonst alles beim Alten...?

Die Frage nach den doofen Umbrüchen wäre damit jedenfalls sinnvoll umgangen.

Grüße,

RIDER

[Matthias Scharwies]

Guten Abend!

Trotzdem empfand ich die von Rolf vorgeschlagene Minimallösung, nur in der Anzeige ausschließlich den letzten Teil des Lemmas anzuzeigen, recht charmant - das verbessert den Status Quo und hört sich, ohne dass ich das recht beurteilen kann, nach wenig Aufwand an.

Ja! Bei den meisten Seiten wäre es ein Gewinn, nur den letzten Teil des Seitennamens zu sehen.

Die Bedenken, dass dabei was kaputt geht, erschließen sich mir nicht ganz - solange nur die Anzeige im Artikel verändert würde bleibt ja sonst alles beim Alten...?

Problem wären dann einzelne Seiten wie …

• JavaScript/Tutorials/Einstieg
• JavaScript/Tutorials/Einstieg/Programmieren und Debuggen

Während die Unterseite mit "Programmieren und Debuggen" einen aussagefähigen Titel hat, hätte das Tutorial nur den Seitennamen "Einstieg".

Diese h1 "Einstieg" wäre für das Tutorial "Einstieg in JS" zu wenig aussagekräftig.

Da müsste man vorher mal schauen, welche Tutorials das betrifft.

Mögliche Lösungen kann man im Nachbar-Tutorial sehen: Hier wurde aus "JavaScript/Tutorials/DOM" der aussagekräftigere Titel "JavaScript und das DOM". Der Titel ist von Felix - aus heutiger Sicht würde ich überlegen, das "das" herauszukürzen.

Ein solch griffigerer Seitenname würde auch ohne Behandlung durch ein Script sowohl in der h1 als auch in der Tab-Info im Browser (title-Element) besser aussehen.

---

Für solche Fleißarbeiten bin ich gerne bereit ein wenig Lebenszeit zur Verfügung zu stellen

Vielen Dank für Deine Bereitschaft! Jetzt ist erst mal Rolf weg, dann ich und dann machen wir weiter:

Der nächste Stammtisch ist am Mittwoch, den 12.03. um 20:15 auf Discord.

Du bist jederzeit willkommen!

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Problem wären dann einzelne Seiten wie …

• JavaScript/Tutorials/Einstieg
• JavaScript/Tutorials/Einstieg/Programmieren und Debuggen

Während die Unterseite mit "Programmieren und Debuggen" einen aussagefähigen Titel hat, hätte das Tutorial nur den Seitennamen "Einstieg".

Diese h1 "Einstieg" wäre für das Tutorial "Einstieg in JS" zu wenig aussagekräftig.

Jein. Ja, ich verstehe das Problem, aber ich glaube es ist überschaubar. Ich hab das mal simuliert:

Wie man sieht sind in allen Versionen außer bei den extrem schmalen Bildschirmen die Breadcrumbs direkt unter der Überschrift sehr deutlich präsent. Ich glaube kaum, dass da ein Problem mit der Identifizierung des Kontexts besteht.

Vielleicht kann man ja die Breadcrumbs auch in der extrem schmalen Version einblenden? Dann ist das Problem des nicht erkennbaren Kontexts damit eigentlich vollständig vom Tisch. Klar, die Breadcrumbs müssen auch umbrechen, aber das sind einzelne a-Elemente mit kleinerer Schriftgröße, da ist das Problem weniger dramatisch.

Du hast natürlich trotzdem recht: Ein prägnanterer Titel als „Einstieg“ wäre gut, und das kann man dann auch peu a peu umsetzen, aber wegen der Breadcrumbs ist es eigentlich unkritisch, wenn man nicht gleich alle Stellen mit unzureichendem Kontext identifiziert.

Ein solch griffigerer Seitenname würde auch ohne Behandlung durch ein Script sowohl in der h1 als auch in der Tab-Info im Browser (title-Element) besser aussehen.

Auf jeden Fall!

Für solche Fleißarbeiten bin ich gerne bereit ein wenig Lebenszeit zur Verfügung zu stellen

Vielen Dank für Deine Bereitschaft! Jetzt ist erst mal Rolf weg, dann ich und dann machen wir weiter:

Der nächste Stammtisch ist am Mittwoch, den 12.03. um 20:15 auf Discord.

Du bist jederzeit willkommen!

Danke, ich schau mal. Ich bin aber eher pessimistisch, weil ich an diesem Abend Kinderdienst habe und deshalb um 20:15 eventuell noch nicht verfügbar bin. Könnte also sein, dass ich es nicht schaffe.

Grüße,

RIDER

[Rolf B]

Hallo Camping_RIDER,

Seitentitel wie „JavaScript/DOM/Node/firstChild“ entstehen aus einer sehr technischen Sicht, das ist Autorenperspektive und lässt die Bedürfnisse der User eher außer Acht.

Stimmt. Deswegen ist das Wiki ja auch voll mit Redirects. BEISPIELSWEISE /FirstChild.

Aber das ist nicht vollständig, insofern gibt es Handlungsbedarf.

Seitentitel wie „Die firstChild-Eigenschaft von DOM-Nodes“ finde ich eher unzugänglich. Es ist ein Wiki, kein Buch, und ein solcher Seitentitel braucht wieder einen Redirect-Artikel, damit die inkrementelle Suche nach firstChild funktioniert. Wenn man verflacht, würde ich das bei Mehrdeutigkeiten eher wie die Wikipedia machen (und ich sage nicht, dass ich verflachen will!):

Fall 1: Eine der Bedeutungen dominiert -> Mach daraus das Lemma und bau dort eine Linkliste für die Nebenbedeutungen ein.

Fall 2: Mehrere Bedeutungen dominieren (oder keine) -> Das Lemma wird zur reinen Begriffsklärungsseite.

Für die Bedeutungen, die vom Lemma nicht erfasst werden, werden Seiten nach dem Schema lemma (kontext) angelegt. Beispielsweise for (Attribut) und for (JavaScript). Solche Seiten enthalten am Anfang einen Link auf die Begriffsklärungsseite des Lemmas.

Das ist natürlich wieder eine höllische Fleißarbeit. Und es ist meine Meinung und kein Beschluss.

Man muss vor allem an die Linkstabilität denken. Im Forum gibt's viele Links auf Wiki-Seiten. Wenn wir die Hierarchie auflösen, gehen die kaputt. D.h. wir müssen die Hierarchie an sich beibehalten, für hunderte von Redirects.

Damit stellt sich die Frage nach dem Verhältnis Nutzen/Aufwand einer Hierarchieverflachung. Angesichts der existierenden Limits für Aufwand ist das für mich das wichtigste Kriterium.

Matthias möchte gerne kurze URLs. Ich persönlich halte das für unnötig. Ein kurzes Seitenheading ist viel relevanter. Der Kontext muss natürlich sichtbar sein, und hier wäre die Frage, ob dafür die Breadcrumb-Leiste hinreicht. Aus Autorenperspektive denke ich: ja. Mein Ansatz wäre, die Hierarchie bei Themenseiten zu verflachen, die ohnehin angefasst werden, und den Referenzteil hierarchisch zu belassen. Die Erreichbarkeit der Referenzseiten kann man durch Redirects im Root-Namensraum verbessern, da ist kein Neubau nötig, nur eine Ergänzung.

Wenn sich genug Freiwillige für ein großes Aufräumen des Wikis melden, kann man natürlich auch aufwändigere Lösungen anstreben. Bisher sind bei "Freiwillige vor" aber fast alle nur einen Schritt zurückgetreten.

Rolf

[Camping_RIDER]

Aloha ;)

Seitentitel wie „Die firstChild-Eigenschaft von DOM-Nodes“ finde ich eher unzugänglich. Es ist ein Wiki, kein Buch, und ein solcher Seitentitel braucht wieder einen Redirect-Artikel, damit die inkrementelle Suche nach firstChild funktioniert.

Richtig. Das sind Argumente gegen Prosa-Titel. Klar, auch die sind technischer Natur, aber ich denke auch aus Benutzersicht gibt es Argumente gegen Prosa-Titel.

Der Vorschlag entwuchs nur folgendem Gedanken: Würde ich auf einer x-beliebigen Seite einen Artikel zu „attr“ veröffentlichen, würde ich wahrscheinlich ein wenig Prosa drumrumbauen, weil mir das irgendwie ansprechender erscheint. Aber wie gesagt - es gibt genug Argumente die auch dagegen sprechen, im Wiki-Kontext sowieso.

Für die Bedeutungen, die vom Lemma nicht erfasst werden, werden Seiten nach dem Schema lemma (kontext) angelegt. Beispielsweise for (Attribut) und for (JavaScript). Solche Seiten enthalten am Anfang einen Link auf die Begriffsklärungsseite des Lemmas.

Das halte ich für einen sinnvollen Vorschlag.

Matthias möchte gerne kurze URLs. Ich persönlich halte das für unnötig. Ein kurzes Seitenheading ist viel relevanter.

Das würde ich so unterschreiben.

Der Kontext muss natürlich sichtbar sein, und hier wäre die Frage, ob dafür die Breadcrumb-Leiste hinreicht. Aus Autorenperspektive denke ich: ja.

Ich denke auch aus Nutzersicht: ja. Schaut man sich den von Matthias gescreenshoteten Artikel an, ist es ja nicht nur so, dass die Breadcrumbs den Kontext klar benennen, sondern bereits der erste Satz des Artikels stellt den Kontext ganz klar dar. Man merkt sofort, wenn man irgendwo falsch gelandet ist. Das ist gut, und ich denke auch ausreichend.

Ein zweites Argument betrifft die Frage, wie man auf die Seite gelangt ist. Hat man sich durch die Wiki-Hierarchie bewegt, ist einem der Kontext eh klar. Hat man die Suche bemüht, so wird (abhängig von der Umsetzung, so wie ich es verstanden habe) der Kontext ja mit angezeigt bzw. ich sehe die verschiedenen Suchergebnisse. Kam man via Google & Co. werten diese Suchmaschinen ja nicht nur den Titel sondern auch den Text aus, verarbeiten also den Kontext bei der Suche auch mit.

Wenn sich genug Freiwillige für ein großes Aufräumen des Wikis melden, kann man natürlich auch aufwändigere Lösungen anstreben. Bisher sind bei "Freiwillige vor" aber fast alle nur einen Schritt zurückgetreten.

Für solche Fleißarbeiten bin ich gerne bereit ein wenig Lebenszeit zur Verfügung zu stellen^[1]. Wie der Umgang damit letztlich aussehen soll muss der Verein entscheiden, da zählt meine Meinung nicht, aber bei der Umsetzung kann ich unterstützen. Ich halte es in jedem Fall für sinnvoll, wenn die /-lastigen Artikeltitel verschwinden.

Grüße,

RIDER

---

1. ...vorausgesetzt ich bekomme die dafür notwendigen Rechte im Wiki zurück, sonst wirds wohl ein wenig schwierig. ↩︎

[Rolf B]

Hallo Janosch,

danke für das Angebot.

Zum Verschieben von Artikeln brauchst Du Adminrechte, zum Anlegen von Redirects nicht - ich denke, wir klären in Mannheim das Vorgehen und entscheiden dann, wer welche Rechte braucht.

Falls es Dich treibt, Wiki-Artikel zu verfassen, kannst Du das jetzt schon tun (größere Gewerke bitte im User-Namespace vorbereiten und dann mit uns abstimmen). Wenn Du Beispiele erstellen willst, kannst Du gern den Beispiel-Admin haben. Große Verschiebeaktionen würde ich bis zur MV zurückstellen wollen, aber wenn Du was anderes tun willst, wofür Du den Admin brauchst, gib uns Bescheid.

Rolf

[Camping_RIDER]

Aloha ;)

Zum Verschieben von Artikeln brauchst Du Adminrechte, zum Anlegen von Redirects nicht - ich denke, wir klären in Mannheim das Vorgehen und entscheiden dann, wer welche Rechte braucht.

Na klar.

Falls es Dich treibt, Wiki-Artikel zu verfassen, kannst Du das jetzt schon tun. Wenn Du Beispiele erstellen willst, kannst Du gern den Beispiel-Admin haben.

Joa, ich habe da aktuell kein Projekt im Hinterkopf. Das liegt auch daran, dass ich ja seit einiger Zeit mehr Backend als Frontend mache in meiner aktiven Tätigkeit. Der Leidensdruck, mich im Frontend so weit weiterzubilden um da überhaupt was auf brandaktuellem Level beitragen zu können ist aktuell nicht groß genug - und die Entwicklung von Frontend-Technologien ist seit ein paar Jahren sehr viel rasanter als früher, das erschwert mir die Sache weiter. Es bestünde die Gefahr, dass ich Artikel auf einer Wissensbasis schreibe, die schon ein paar Jahre angestaubt ist, und damit halte ich mich dann lieber zurück.

Falls mir was kommt und ich die Rechte dafür brauche, melde ich mich.

Ich möchte allerdings an der Stelle auch nicht verhehlen, dass meine Motivation, mir darüber Gedanken zu machen, was ich im Wiki selbständig beitragen könnte, unter dem grundlosen Entzug aller Rechte im Wiki deutlich gelitten hat; dass es dazu weder Kommunikation noch Begründung gab war auch kein feiner Zug - ich habs zufällig aus den "Letzten Änderungen" erfahren als ich im Wiki was editieren wollte und nicht konnte. Einen Teil kann ich mir zusammenreimen, Admin-Rechte wären bei mir als Nichtmitglied tatsächlich auch nicht notwendig, aber mit dem Entzug der Beispiel-Adminrechte so Knall auf Fall auf ein Level gesetzt zu werden, das noch unter dem von zig Leuten liegt, die sich mit nichts außer warmen Worten das Vertrauen dazu verdient haben, das ist schon eine verletzende und in meinen Augen auch unverdiente Art, Misstrauen auszudrücken. Das aber nur nebenbei, ich will das jetzt auch nicht großartig breittreten.

Große Verschiebeaktionen würde ich bis zur MV zurückstellen wollen, aber wenn Du was anderes tun willst, wofür Du den Admin brauchst, gib uns Bescheid.

Natürlich. Aktuell gibt es da nichts. Falls ich unterstützen soll, wie gesagt, gerne, sobald ihr entschieden habt wie das Vorgehen aussehen soll.

Grüße,

RIDER

[Rolf B]

Hallo Camping_RIDER,

unter dem grundlosen Entzug aller Rechte

Natürlich gab es einen Grund.

Du hast alles hingeschmissen und bist aus dem Verein ausgetreten. Deshalb wurden die Admin-Rechte (Wiki+Beispiel) zurückgenommen. Weil wir davon ausgingen, dass Du sie nicht mehr brauchst. Rechte vergibt man nach Bedarf. Hab ich so in 40 Berufsjahren gelernt.

Wenn der Bedarf wiederkommt, kommen auch die Rechte wieder. Deinen Beispiel-Admin hast Du zuletzt 2018 genutzt.

Der Hinweis mit den nutzlosen Beispiel-Admin Rechten ist etwas übertrieben, find ich. Da sind 5 Altlasten drin, die man aufräumen kann, richtig. Die sind aber nicht mit einem Krach gegangen, deswegen ist das unter dem Radar geblieben. Mit gutem Gewissen streichen kann ich dieses Recht aber nur bei Jeena und Tabellenkalk, die 2011 das Recht bekommen haben und seit 2011 kein Beispiel mehr bearbeitet haben.

Bei Bedarf kann dieses Recht natürlich zurückgegeben werden!

Rolf

[Camping_RIDER]

Aloha ;)

unter dem grundlosen Entzug aller Rechte

Natürlich gab es einen Grund.

Du hast alles hingeschmissen und bist aus dem Verein ausgetreten. Deshalb wurden die Admin-Rechte (Wiki+Beispiel) zurückgenommen. Weil wir davon ausgingen, dass Du sie nicht mehr brauchst.

Ich bin aus dem Verein ausgetreten. Von „hingeschmissen“ kann keine Rede sein. Ich habe nach wie vor im Forum mitgelesen, ich bin im Wiki unterwegs, und ich habe auch nichts anderes kommuniziert. Ich habe auch nicht kommuniziert, dass ich nichts mehr beitragen würde - im Gegenteil, ich schrieb mit dem Austritt ja sogar noch ausdrücklich: „Ich bleibe dem Projekt [...] gerne erhalten - aber nicht als Mitglied des Vereins.“

Bei den Admin-Rechten fürs Wiki verstehe ich das wie gesagt auch - aber die Beispiel-Admin-Rechte haben nunmal nichts mit einer Vereinsmitgliedschaft zu tun, die werden auch unabhängig davon an all jene vergeben, bei denen man darauf vertraut, dass da kein Schadcode injiziert wird.

Wenn der Bedarf wiederkommt, kommen auch die Rechte wieder. Deinen Beispiel-Admin hast Du zuletzt 2018 genutzt.

Der Bedarf war nie weg. Ich habe nicht angekündigt, nichts mehr im Wiki beitragen zu wollen, im Gegenteil - und ja, das Wissen darum, das jetzt substantiell nur zu können, wenn ich vorher um Rechte bitten muss, sorgt dafür, dass ich keinerlei Motivation verspüre, noch Inhalte beizutragen.

Es wäre ja auch möglich gewesen, einfach mal nachzufragen - „Hey, wir haben gesehen, du hast die Rechte noch, brauchst du die noch?“ - Ist aber nicht passiert.

Rechte vergibt man nach Bedarf.

Richtig. Bei wegfallendem Bedarf entzieht man sie... vielleicht, vielleicht auch nicht. Ganz sicher entzieht man sie bei Misstrauen. Da der Bedarf nie weg war, weil ich ja sogar angekündigt hatte, dem Projekt erhalten zu waren, bleibt da ja nur noch eine Interpretation übrig.

Der Hinweis mit den nutzlosen Beispiel-Admin Rechten ist etwas übertrieben, find ich. Da sind 5 Altlasten drin, die man aufräumen kann, richtig. Die sind aber nicht mit einem Krach gegangen, deswegen ist das unter dem Radar geblieben.

Ich bin aus dem Verein ausgetreten. An einen „Krach“ kann ich mich nicht erinnern, schon gar nicht an einen, der über persönliche Differenzen mit einzelnen Akteuren hinausgeht, und was das mit meiner Vertrauenswürdigkeit für Beispiel-Admin-Rechte zu tun haben sollte weiß ich auch nicht. Ist ja nicht so als hätte ich irgendwann, weder vor noch nach meinem Austritt, versucht, dem Verein zu schaden. Der Entzug der Rechte geschah übrigens ja auch nicht mit dem „Knall“ meines Austritts, sondern Wochen danach. Kommunikationslos.

Natürlich kann man mir beliebig Rechte entziehen. Bei den Admin-Rechten war ja auch tatsächlich kein Bedarf mehr da als Nichtmitglied. Bei den Beispiel-Admin-Rechten war das - in der Kommunikationslosigkeit in der das passiert ist - weder notwendig, noch in der Art angemessen, noch zwischenmenschlich fair.

Ich wiederhole mich aber gerne nochmal: Wegen mir müssen wir dieses Thema nicht austreten. Das heißt aber nicht, dass ich beliebig jedes Framing („hingeschmissen“) widerspruchslos akzeptieren muss.

Grüße,

RIDER

[Auge]

Hallo

Seitentitel wie „Die firstChild-Eigenschaft von DOM-Nodes“ finde ich eher unzugänglich. Es ist ein Wiki, kein Buch, und ein solcher Seitentitel braucht wieder einen Redirect-Artikel, damit die inkrementelle Suche nach firstChild funktioniert.

Richtig. Das sind Argumente gegen Prosa-Titel. Klar, auch die sind technischer Natur, aber ich denke auch aus Benutzersicht gibt es Argumente gegen Prosa-Titel.

Also ich bin ja für prosaische Überschriften zu haben, die mehr sind als nur das Lemma an sich. Das muss ja nicht ausarten, wie in frühen wissenschaftlichen Arbeiten, in denen gerne mal die Zusammenfassung des Themas mit im (Unter)-Titel stand. „Die firstChild-Eigenschaft von DOM-Nodes“ halte ich jedenfalls nicht für übertrieben. Hilfreich fände ich es bei mehrdeutigen Lemmata, auch wenn ich das Argument, dass man im Brotkrumenpfad oder spätestens in der Einleitung mitbekommt, was das Thema ist, verstehe.

Aber meine Überlegung steht und fällt schon bei der technischen Frage, ob sich die Überschrift eines Wiki-Artikels vom Lemma des Artikels unterscheiden darf oder nicht. Falls nicht, ist jede Idee zu prosaischen Seitenüberschriften sowieso obsolet.

Tschö, Auge

[Matthias Scharwies]

Servus!

Hallo

Seitentitel wie „Die firstChild-Eigenschaft von DOM-Nodes“ finde ich eher unzugänglich. Es ist ein Wiki, kein Buch, und ein solcher Seitentitel braucht wieder einen Redirect-Artikel, damit die inkrementelle Suche nach firstChild funktioniert.

Richtig. Das sind Argumente gegen Prosa-Titel. Klar, auch die sind technischer Natur, aber ich denke auch aus Benutzersicht gibt es Argumente gegen Prosa-Titel.

Also ich bin ja für prosaische Überschriften zu haben, die mehr sind als nur das Lemma an sich.

Das schließt sich ja nicht aus: Lemma für den Seitentitel; eine Erklärung und dann eine prosaische h2-Überschrift.

Das muss ja nicht ausarten, wie in frühen wissenschaftlichen Arbeiten, in denen gerne mal die Zusammenfassung des Themas mit im (Unter)-Titel stand. „Die firstChild-Eigenschaft von DOM-Nodes“ halte ich jedenfalls nicht für übertrieben. Hilfreich fände ich es bei mehrdeutigen Lemmata, auch wenn ich das Argument, dass man im Brotkrumenpfad oder spätestens in der Einleitung mitbekommt, was das Thema ist, verstehe.

Ich glaube, das man Romane mit Titeln wie "Der Hundertjährige, der aus dem Fenster stieg und verschwand" durchaus verwenden kann - im Wiki, das auch auf Mobilgeräten gelesen wird, sollte man so kurz wie möglich sein.

»Perfektion ist nicht dann erreicht, wenn man nichts mehr hinzufügen, sondern wenn man nichts mehr weglassen kann.«
Antoine de Saint-Exupéry

Herzliche Grüße

Matthias Scharwies

[Auge]

Hallo

Das muss ja nicht ausarten, wie in frühen wissenschaftlichen Arbeiten, in denen gerne mal die Zusammenfassung des Themas mit im (Unter)-Titel stand. „Die firstChild-Eigenschaft von DOM-Nodes“ halte ich jedenfalls nicht für übertrieben. Hilfreich fände ich es bei mehrdeutigen Lemmata, auch wenn ich das Argument, dass man im Brotkrumenpfad oder spätestens in der Einleitung mitbekommt, was das Thema ist, verstehe.

Ich glaube, das man Romane mit Titeln wie "Der Hundertjährige, der aus dem Fenster stieg und verschwand" durchaus verwenden kann

… ja, zum Beispiel, um es zu lesen. 😆😉

Der Titel „Der Hundertjährige, der aus dem Fenster stieg und verschwand“ ist aber noch nicht das, was mir vorschwob.

… raschel, such, Wikipedia durchstöber … ah ja, hier:

„Außzug auß der Vralten Meſſe Kunſt Archimedis Vnd deroſelben newlich in Latein auſzgangener Ergentzung / betreffend Rechnung der Cörperlichen Figuren / holen Gefeſſen vnd Weinfäſſer / ſonderlich deß Oeſterreichiſchen / ſo vnder allen anderen den artigiſten Schick hat. Erklärung vnnd beſtättigung der Oeſterreichiſchen Weinbiſier Ruthen / vnd deroſelben ſonderbaren gantz leichten vnd behenden Gebrauchs an den Landfäſſern: Erweitterung deſſen auff die außländiſche / ſo auch auff das Geſchütz vnnd Kugeln. Sampt einem ſehr nutzlichen Anhang Von vergleichung deß Landtgebräuchigen Gewichts / Elen / Klaffter / Schuch / Wein- vnd Traid Maaß / vnder einander / vnd mit andern außländiſchen / auch Alt Römiſchen.“ von Johannes Kepler, 1616^[1].

Das ist ein Titel! …

… im Wiki, das auch auf Mobilgeräten gelesen wird, sollte man so kurz wie möglich sein.

… wie man ihn im Wiki ganz bestimmt nicht haben wollen würde. 😅

»Perfektion ist nicht dann erreicht, wenn man nichts mehr hinzufügen, sondern wenn man nichts mehr weglassen kann.«
Antoine de Saint-Exupéry

Dem ist eigentlich nichts mehr hinzuzufügen oder hinwegzulassen.

Tschö, Auge

---

1. Auch im Volltext verfügbar. ↩︎

[MudGuard]

Hi,

Ohne Margin ist ist / und T zu dicht aneinander, mit einem margin-right am Span ist es an den anderen Stellen zu viel.

und von margin-right: 2px ist selbst im Entwicklertool nichts zu sehen.

IIRC darf auch nix davon zu sehen sein, solange das span ein inline-Element ist - für die ist meiner Erinnerung nach horizontaler Margin nicht möglich.

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

es ist auch inline-block. Ansonsten würde es den beabsichtigten Zweck nicht erfüllen.

Aber ich kann das mal umbauen und nur den letzten Teil des Lemmas ins firstHeading schreiben.

Rolf

[Matthias Scharwies]

Servus!

@@Rolf B

Aber jetzt kam Mattias und sagt: Der ZWNJ wird bei Copy+Paste mitkopiert und fällt dabei zunächst überhaupt nicht auf. Aber der Link, den man auf diese Weise generiert, ist kaputt.

?? Was hat ein URL mit dem Text der Überschrift zu tun? Was in der Überschrift ein Leerzeichen ist, ist im URL ein Unterstrich. Und warum sollte jemand den Text der Überschrift kopieren, wenn sie den URL kopieren will?

@Rolf B Ja, das hatte ich auch schon in einer PN geschrieben:

Ich habe nachgedacht und glaube nicht: wie viele Leute nehmen die Überschrift für einen internen Link her? Wir zwei! (Oder nur ich?)

Use Case für alle anderen ist die URL, die sie entweder aus dem anchor bei h2,h3,h4 kriegen oder aus der Browserleiste!

BTW: Wäre ein anchor auf der H1 eine Lösung?

Aber das Problem sind nicht die Zeilenumbrüche, sondern:

unser Wiki hat teils recht tiefe Hierarchien für die Artikel, was zu Überschriften wie „JavaScript/DOM/‌Node/‌firstChild“ oder „JavaScript/‌Tutorials/‌OOP/‌Objekte und ihre Eigenschaften“ führt

Da liegt das Problem.

Ich finde die Stelle nicht mehr, in der @dedlfix sagte, dass er 2010 mal 2 Tage weg gewesen wäre und dann diese Struktur festgelegt wurde.

Wir ändern das sukzessive; manche Sachen wie

• HTML/Elemente/body
• CSS/Eigenschaften/display

sollten aber bleiben. Das könnte man ja mal gemeinsam diskutieren.

Was sich leicht beheben lässt: Überschriften sind das Eine und Breadcrumbs sind etwas Anderes. Breadcrumbs gehören nicht in die Überschrift.

Zumindest die Umbrüche sind eine gute Zwischenlösung.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Nachtrag: Es scheint vor allem ein Problem der Nunito-Schrift zu sein. Verwende ich Arial 🤮 oder andere sans-Schriften auf meinem PC, passen die Abstände.

Das wär jetzt doof, wir haben lange überlegt, welche Titelschrift wir nehmen.

Ist das jetzt ein Nunito-Bug oder ein Chrome-Bug oder ein Windows-Bug?!

[Gunnar Bittersmann]

@@Rolf B

Ist das jetzt ein Nunito-Bug oder ein Chrome-Bug oder ein Windows-Bug?!

Ah, sag das doch gleich, dass man sich das in Googles Spion anstatt in einem vernünftigen Browser ansehen soll!

Firefox bricht nach den / um, Chrome nicht.

Jolan tru

[Rolf B]

Hallo Gunnar,

jo ei verbibscht, der FF bricht ohne Hilfestellung an den / um und der Chrome tut's nicht. Aber Chrome ist kein IE, den kann man nicht vernachlässigen.

Ist dieses Umbruchverhalten etwas, was man mit CSS beeinflussen kann?

Rolf

[Rolf B]

Es gibt aber auch Lemmata, bei denen nichts mehr hilft. Zumindest auf meinem Mobilchen nicht

Rolf

[Gunnar Bittersmann]

@@Rolf B

Nunito-Schrift

Für diese würde ich Ligaturen ausschalten: font-variant-ligatures: none.

Die fi-Ligatur macht hier überhaupt keinen Sinn (wie auch bei manch anderen serifenlosen Schriften nicht). Der Sinn der fi-Ligatur ist ja, dass der Bogen des f nicht mit dem i-Punkt kollidiert. (Meist dient der Tropfen des f auch als i-Punkt.)

Bei Nunito u.a. ist das aber gar nicht der Fall; f und i berühren sich gar nicht. Aber bei der Ligatur sitzen f und i näher zusammen, was keinen Sinn macht. Und dass der Querstrich des f bis zum i ran geht, auch nicht.

fi-Ligatur kann weg. Andere Ligaturen (fl, ffi, …) scheint’s in Nunito nicht zu geben. Also Ligaturen ausschalten.

Übrigens sind da etliche Subsets eingebunden, die man wohl niemals braucht.

Und sollte es bei variable fonts nicht format('woff2-variations') heißen?

Verwende ich Arial 🤮

Das tut man doch nicht. ☞ Was der Erik sagt.

Jolan tru

[Gunnar Bittersmann]

@@Rolf B

Begonnen hatte ich mit (1), aber wie man hier sehen kann (Edit: dieser Link erzwingt den Makeover-Skin, nur für diese Seite), ist das unbefriedigend.

Ja, jetzt sehe ich, was du meinst. Auch im Firefox.

Meine Vermutung wäre, dass ‚t‘–‚/‘ und ‚/‘–‚T‘ in dieser Schriftart Kerning-Paare sind. Wenn ‚t‘ und ‚/‘ bzw. ‚/‘ und ‚T‘ nicht im selben span sind, geht bei display: inline-block das Kerning verloren.

Ohne Margin ist ist / und T zu dicht aneinander, mit einem margin-right am Span ist es an den anderen Stellen zu viel.

Würde ich nicht sagen. Eher überall zu wenig; das ‚/‘ könnte etwas Luft auf beiden Seiten vertragen:

#firstHeading span:not(:first-child) { margin-inline-start: 0.1ch }
#firstHeading span:not(:last-child) { margin-inline-end: 0.1ch }

Die ‚/‘ müssen dann weder am Ende noch am Anfang in den spans stehen, sondern zwischen ihnen.

Jolan tru

[Rolf B]

Hallo Gunnar,

okay, danke dafür. Aber wir hatten ja gesagt, dass ich versuchen möchte, das Problem durch Entfernen des Pfades zu eliminieren 😀

Dies hier

Die ‚/‘ müssen dann weder am Ende noch am Anfang in den spans stehen, sondern zwischen ihnen.

ist leider nicht so gut, damit kann ein / allein in der Zeile landen. Ist mir beim Probieren schon passiert. Um die Darstellung lufiger zu machen, müsste ich mich entscheiden, ob ich die / eher am Ende eines Pfadteils oder an seinem Beginn sehen möchte, und für die "Ende-Version" <span>Name<span>/</span></span> generieren. Kein ::after, damit das / mitkopiert werden kann, wenn das jemand will… Brrr.

Rolf