News im Wiki

[Rolf B]

Hallo,

aus gegebenem Anlass habe ich im Wiki in der common.js eine kleine Ergänzung durchgeführt, die Links auf Überschriften erleichtern kann.

Problem sind

• Überschriften, die lang sind
• Überschriften mit Zeichen, die in URLs nicht gestattet sind
• Überschriften, die sich ändern 😲

Das Wiki kennt bereits die Vorlage {{anchor|id}}, mit der ein Dummy-Span erzeugt werden kann, der eine ID trägt. Aber unser Permalink-Feature kennt solche Anker nicht.

Jetzt schon:

=={{anchor|foo}} Eine langatmige (und weitschweifige) Überschrift ==

bekommt jetzt auf dem Permalink-Icon #foo als Link, und nicht mehr dem Bandwurm, in dem Klammern und Ü maskiert werden müssen.

De facto hat die Überschrift jetzt zwei IDs. Ich kann und will es Mediawiki nicht abgewöhnen, den Überschriftentext als id des Überschriftenelements zu generieren. Ähhh - ok, das auch nicht. Mediawiki generiert ohne die {{anchor}}-Vorlage sowas:

<h3>
  <span class="mw-heading"
        id="Eine langatmige .28und weitschweifige .29 .C3.9Cberschrift">
  Eine langatmige (und weitschweifige) Überschrift
  </span>
  <span class="mw-editsection">...</span>
</h3>

In .mw-editsection ist der Link auf die "Section bearbeiten" Funktion.

Die {{anchor}}-Vorlage fügt ein `<span id="foo"></span> am Anfang des .mw-heading Span ein.

Im common.js suche ich innerhalb von .mw-heading nach span[id], und wenn's da ist, verwende ich diese ID für den Permalink statt der .mw-heading id.

Jetzt weiß ich nur eins nicht. Der Permalink-Generator erzeugt außer dem Link-Symbol auch einen visuell versteckten Text, der der verlinkten URL entspricht. Hier sieht das z.B. jetzt so aus:

<h3>
  <span class="mw-headline" id="String.prototype.anchor.28name.29">
    <span id="string.anchor"></span>
    String.prototype.anchor(name)
  </span>
  <a href="/wiki/JavaScript/Deprecated#string.anchor" class="locale-anchor"> 
    <span>/wiki/JavaScript/Deprecated#string.anchor</span>
  </a>
  <span class="mw-editsection">...</span>
</h3>

Der Span in der siebten Zeile ist visuell versteckt und enthält die Permalink-URL - damit ein Screenreader "Link: /wiki/bla/fasel" vorliest, nehme ich an. Das war auch ohne meine Änderung so, nur entsprach die Permalink-URL da noch dem Überschriften-Inhalt.

Was enthält dieser Span richtigerweise? Die Permalink-URL oder die URL für die Heading-ID? Oder etwas ganz anderes, das auf die Permalink-Eigenschaft dieses Links hinweist? Also vielleicht "<span>Permalink auf diesen Abschnitt</span>"?

Rolf

[Matthias Scharwies]

Servus!

Hallo,

aus gegebenem Anlass habe ich im Wiki in der common.js eine kleine Ergänzung durchgeführt, die Links auf Überschriften erleichtern kann.

Problem sind

• Überschriften, die lang sind
• Überschriften mit Zeichen, die in URLs nicht gestattet sind
• Überschriften, die sich ändern 😲

Das Wiki kennt bereits die Vorlage {{anchor|id}}, mit der ein Dummy-Span erzeugt werden kann, der eine ID trägt. Aber unser Permalink-Feature kennt solche Anker nicht.

Jetzt schon:

=={{anchor|foo}} Eine langatmige (und weitschweifige) Überschrift ==

bekommt jetzt auf dem Permalink-Icon #foo als Link, und nicht mehr dem Bandwurm, in dem Klammern und Ü maskiert werden müssen.

De facto hat die Überschrift jetzt zwei IDs. Ich kann und will es Mediawiki nicht abgewöhnen, den Überschriftentext als id des Überschriftenelements zu generieren. Ähhh - ok, das auch nicht. Mediawiki generiert ohne die {{anchor}}-Vorlage sowas:

<h3>
  <span class="mw-heading"
        id="Eine langatmige .28und weitschweifige .29 .C3.9Cberschrift">
  Eine langatmige (und weitschweifige) Überschrift
  </span>
  <span class="mw-editsection">...</span>
</h3>

In .mw-editsection ist der Link auf die "Section bearbeiten" Funktion.

Die {{anchor}}-Vorlage fügt ein `<span id="foo"></span> am Anfang des .mw-heading Span ein.

Im common.js suche ich innerhalb von .mw-heading nach span[id], und wenn's da ist, verwende ich diese ID für den Permalink statt der .mw-heading id.

Jetzt weiß ich nur eins nicht. Der Permalink-Generator erzeugt außer dem Link-Symbol auch einen visuell versteckten Text, der der verlinkten URL entspricht. Hier sieht das z.B. jetzt so aus:

<h3>
  <span class="mw-headline" id="String.prototype.anchor.28name.29">
    <span id="string.anchor"></span>
    String.prototype.anchor(name)
  </span>
  <a href="/wiki/JavaScript/Deprecated#string.anchor" class="locale-anchor"> 
    <span>/wiki/JavaScript/Deprecated#string.anchor</span>
  </a>
  <span class="mw-editsection">...</span>
</h3>

Der Span in der siebten Zeile ist visuell versteckt und enthält die Permalink-URL - damit ein Screenreader "Link: /wiki/bla/fasel" vorliest, nehme ich an. Das war auch ohne meine Änderung so, nur entsprach die Permalink-URL da noch dem Überschriften-Inhalt.

Was enthält dieser Span richtigerweise? Die Permalink-URL oder die URL für die Heading-ID? Oder etwas ganz anderes, das auf die Permalink-Eigenschaft dieses Links hinweist? Also vielleicht "<span>Permalink auf diesen Abschnitt</span>"?

ja, das wäre imho ok. Ich würde da die Mediawiki-Konventionen nicht zu weit ändern.

Wir sollten aber weiter oben ansetzen und die Überschriften kürzen und um Umlaute, Doppelpunkte, etc säubern.

Die überlangen Seitentitel kommen aus unserer virtuellen Hierarchie. Ich habe ja schon begonnen, Seiten wie

• CSS/Tutorials/Print-CSS
• CSS/Tutorials/Transforms

direkt in den HNR auf die erste Ebene zu verschieben. Das sollten wir eventuell sukzessive bei Bearbeitungen gleich miterledigen. Gerade bei Transforms, die sowohl zu CSS als auch SVG gehören, ist das imho besser.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

das sind zwei Baustellen. Links auf Artikel werden von meiner Änderung nicht beeinflusst. Es geht nur um den Hash-Teil, um auf interne Überschriften zu verlinken.

Ob es aber tatsächlich gut ist, den Artikelraum flachzukloppen? Gut, die Wikipedia macht das auch, aber bislang fand ich es immer eine gute Orientierung, wenn ein Artikel in einer Namenshierarchie stand. Natürlich führt das immer zu Unsicherheiten, wie nun die richtige Hierarchie ist, und für die Findbarkeit gibt's die Weiterleitungsseiten auf dem Top-Level, aber man hat dann vermutlich auch das Thema der Wikipedia, Artikel mit einem Themenhinweis zu ergänzen, wie z.B. class (JavaScript) und class (HTML Attribut). Das könnte in Arbeit ausarten…

Bei Methoden wie querySelector, die es für Dokumente und Elemente gibt, könnte man dann natürlich die Artikel zusammenlegen. Auch das könnte in Arbeit ausarten 😉

Rolf

[Der Martin]

n'Abend ihr beiden,

ich will mal gar nicht so sehr auf Wiki-spezifische Themen eingehen - mangels Know-How. Aber Datenorganisation ist ja durchaus ein allgemeines Thema.

Ob es aber tatsächlich gut ist, den Artikelraum flachzukloppen?

Nein, nicht um jeden Preis. Es ist wie so oft ein Balanceakt: Übertreibt man es mit der Verästelung, muss man tatsächlich dauernd überlegen, in welchen Zweig ein neuer Beitrag nun am besten passt. Vielleicht nicht nur in einen. Das andere Extrem, alles in eine Hierarchieebene zu walzen, wirkt dann eventuell wie Kraut und Rüben.

Ich bin durchaus ein Fan der Strukturierung von Informationen, aber die muss maßvoll und sinnvoll sein. Als Negativ-Beispiel sehe ich da fast täglich Verzeichnishierarchien auf unseren Fileservern, wo nach fünf bis sechs Verzeichnisebenen dann auf der letzten Ebene noch genau ein Dokument liegt, das genauso heißt, wie das Verzeichnis, in dem es liegt. Das ist weder nützlich noch technisch sinnvoll - zumal wir damit schon ab und zu an das 1024-Zeichen-Limit für Pfadnamen unter Windows kommen.

Gut, die Wikipedia macht das auch, aber bislang fand ich es immer eine gute Orientierung, wenn ein Artikel in einer Namenshierarchie stand.

Ja, bin ich dabei - solange die Einordnung eindeutig ist.

Natürlich führt das immer zu Unsicherheiten, wie nun die richtige Hierarchie ist

Genau, deswegen dürfen die Kategorien nicht zu speziell gewählt werden.

Bei Methoden wie querySelector, die es für Dokumente und Elemente gibt

Hä??

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

Hä??

Ja gut. Es ist das ParentNode Mixin, das bei Document, Element und DocumentFragment eingesteuert wird und Methoden wie querySelector mitbringt. Und wir haben sie im Wiki auch nur unter ParentNode dokumentiert. War ein schlechtes Beispiel.

Dann halt Array.prototype.indexOf und TypedArray.prototype.indexOf…

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

das sind zwei Baustellen. Links auf Artikel werden von meiner Änderung nicht beeinflusst. Es geht nur um den Hash-Teil, um auf interne Überschriften zu verlinken.

Da hab ich lang' mit mir gerungen, wie

• Print-CSS#einen_Seitenumbruch_erzeugen_oder_verhindern

heißen soll. Vorher war es "Seitenumbrüche" und das "ü" wurde eben zu "Print-CSS#Seitenumbr.C3.BCche" - evtl könnte man den unbestimmten Artikel entfernen (#Seitenumbruch_erzeugen_oder_verhindern).

Ob es aber tatsächlich gut ist, den Artikelraum flachzukloppen?

Nicht alles, aber

• HTML/Tutorials/Listen/Gestaltung mit CSS
• HTML/Tutorials/Formulare/Radio-Buttons und Checkboxen (nimmt bei mir den ganzen Viewport ein)

könnte man schon anders nennen

...aber man hat dann vermutlich auch das Thema der Wikipedia, Artikel mit einem Themenhinweis zu ergänzen, wie z.B. class (JavaScript) und class (HTML Attribut).

• HTML/Attribute/class

find ich gut und das soll so bleiben.

Bei Methoden wie querySelector, die es für Dokumente und Elemente gibt, könnte man dann natürlich die Artikel zusammenlegen. Auch das könnte in Arbeit ausarten 😉

Da würde ich am Liebsten nur noch Tutorials haben und die Einzelmethoden bei der MDN verlinken. Andererseits haben wir bei den meisten Methoden ja schon eigene Artikel mit Beispielen.

Herzliche Grüße

Matthias Scharwies