Neuer alter Skin für das Selfhtml-Wiki

[dedlfix]

Geehrte Forumsgemeinde und Wiki-Besucher!

Die MediaWiki-Software wird irgendwann demnächst in der neuen Version 1.16 erscheinen. Dabei gibt es Inkompatibilitäten bei den Skins, so dass ich das zum Anlass nahm, für das SELFHTML-Wiki den jetzigen SELFHTML-Skin darauf anzupassen. Das heißt eigentlich, dass ich nicht den vorhandenen Skin umgeschrieben habe[*], sondern mir den 1.16er Default-Skin (Monobook) nahm und bei nur geringen Änderungen am HTML-Unterbau das CSS so geschrieben habe, dass das Ergebnis wie der SELFHTML-Skin aussieht[**]. Zumindest in modernen Browsern und hier kommt meine Bitte: Im IE7 sind mehr oder weniger Kleinigkeiten nicht richtig, der IE6 verhaut den Kopfbereich ziemlich derb. Wer hat Zeit/Lust/Erfahrung und/oder noch nicht genug graue Haare, zumindest für den IE6 Korrekturen zu erarbeiten, so dass die Seite mindestens bedienbar wird? Das sollte nach Möglichkeit nur per CSS passieren, denn das HTML umzuschreiben zieht vermutlich wieder Anpassungen für andere Browser nach sich. Die IEs bekommen über Conditional Comments ihre Korrekturen verpasst, andere Browser (konkret Opera 6, 7, 9 und Firefox 2) bekommen sie per Javascript geladen, wobei ich diese genannten anderen Browser-Versionen nicht betrachtet habe. (Sind die überhaupt noch nennenswert vertreten?)

Zu finden ist die neue Version über den Link in den Kopfdaten dieses Postings. Es ist ein statischer Abzug einer Test-Installation, der geringfügig angepasst wurde (z.B. alle Links sind Dummys).

Bisher aufgekommene allgemeine Kritikpunkte am SELFHTML-Skin:

molily merkte in Verbesserungsvorschläge#Linkformatierung noch leerer Artikel an, dass Links auf nicht existierende Seiten mit dem dunklen Rot und unterpunktet zu prägnant und verwirrend seien. Dem kann ich mich nicht so ganz anschließen, wenn ich von der Lernfähigkeit des Menschen ausgehe. Einmal geklickt sollte man nun eigentlich wissen, was diese Farbgebung bedeutet. Andererseits sollte es auch etwas Anregendes sein, damit man sich der Baustelle annimmt. Zudem hat die auch die Wikipedia mit rot im Gegensatz zu blau eine prominentere Farbe für nicht vorhandenes gewählt. Was ist eure Meinung?

Jemand weiteres (ich kann mich grad nicht erinnern, wer und wo das war) beklagte sich darüber, dass die Farbe nicht besuchter Links zu hell sei. Auch hier bitte ich um Meinungen und Vorschläge.

Besten Dank,
dedlfix

[*] Der jetzige Skin hat einen Verschachtlungsfehler bei den Menüs und fehlerhafte Script-Einbindungen. Zudem war im HTML-Code die Navigation vor dem Inhalt angesiedelt. Monobook hat es umgekehrt und positioniert die Navigationselemente über CSS vor den Inhalt.

[**] Da sind einige semantisch fragwürdige h5/h6-Verwendungen drin, da ich aber das HTML möglichst unverändert lassen wollte, ließ ich sie so drin. Funktional und optisch gibt es ja keine Not damit.

[Kai345]

[latex]Mae  govannen![/latex]

Bisher aufgekommene allgemeine Kritikpunkte am SELFHTML-Skin:

molily merkte in Verbesserungsvorschläge#Linkformatierung noch leerer Artikel an, dass Links auf nicht existierende Seiten mit dem dunklen Rot und unterpunktet zu prägnant und verwirrend seien. Dem kann ich mich nicht so ganz anschließen,

Ich schon. Das Rot ist wesentlich dominanter als die normale Linkfarbe (die quasi nicht erkennbar ist, dazu mehr weiter unten), daher wird die Standard-Aktion eines unbedarften Nutzers mit sehr hoher Wahrscheinlichkeit ein Klick auf genau diese Links sein.

wenn ich von der Lernfähigkeit des Menschen ausgehe. Einmal geklickt sollte man nun eigentlich wissen, was diese Farbgebung bedeutet.

Sollte. Wie war das noch gleich mit den zwei Dingen, die lt. Herrn Einstein unendlich sind? Zumal ich einen schweren Usability-Verstoß sehe, wenn Nicht-Seiten prominenter hervorgehoben sind als Seiten.

Andererseits sollte es auch etwas Anregendes sein, damit man sich der Baustelle annimmt. Zudem hat die auch die Wikipedia mit rot im Gegensatz zu blau eine prominentere Farbe für nicht vorhandenes gewählt. Was ist eure Meinung?

Eben. Im Gegensatz zum sowohl gewohnten (da Browser-Default) wie auch wesentlich dominaterem Blau. Genau da sehe ich den Unterschied.

Jemand weiteres (ich kann mich grad nicht erinnern, wer und wo das war) beklagte sich darüber, dass die Farbe nicht besuchter Links zu hell sei. Auch hier bitte ich um Meinungen und Vorschläge.

Für _mich_ sind die ungelesenen Links schwer- bis unlesbar, sowohl generell [1] wie auch insbesondere in der "Fortschritts-Anzeige" (Baustelle im Zustand...) für den Status einer Artikelseite[2]. Hier ist laut Color-Contrast-Analyzer die Ratio nicht annähernd ausreichend. Zusammen mit der _viel_ zu geringen Schriftgröße (12px) ergibt das für eine Referenz, die von  vielen Personen gelesen werden will, eine unbrauchbare Kombination.

Cü,

Kai

[1]
Foreground:#FF8040  Background:#FFFFFF
The contrast ratio is: 2,5:1
Text failed at Level AA

1.4.2 Contrast (Minimum):  Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration.  Larger scale text (at least 18 point or 14 point bold) or images of text can have a contrast ratio of 3:1. (Level AA)

[2]
Foreground:#FF8040  Background:#CCCCCC
The contrast ratio is: 1,6:1
Text failed at Level AA

1.4.2 Contrast (Minimum) (s.o.)

[WiMu]

Moin,

hab' das Wiki gestern erst entdeckt und finde es erstmal Klasse, dass es hier in Sachen Dokumentation überhaubt mal weiter geht. Wenn ich trotzdem mal ein paar Kleinigkeiten senfen darf ...

Wieso das monobook? Mit 1.16 kommt doch auch der vector-skin, und der wird über kurz oder lang das monobook als Standard ersetzen (so z.B. bereits auf den commons). Wenn ich mich recht erinnere setzt auch das usability-Gedöhnse den vector-skin vorraus. Früher oder später könnte das Probleme geben.

Zur link-Formatierung:

ich persönlich finde das rot bei nicht existierenden Seiten OK, nicht aber den gepunktelten Rahmen; der beißt sich schonmal mit aktivierten links, passt nicht zu den anderen und sieht z.B. bei #p-personal ziemlich daneben aus (sorry).

Da unbesuchte gegenüber besuchten Seiten hervorgehoben werden sollten statt umgekehrt, würde ich die Farben gegeneinander austauschen ...

Das sollte farblich angepasst werden, außerdem sollten externe links, die in Wahrheit gar nicht extern sind (z.B. wenn die Bearbeiten-Seite oder die History oder irgendwas per {{fullurl:blah}} verlinkt wird) als interne links dargestellt werden:

  
a.external[href^="http://wiki.selfhtml.org"] {  
     color: #ff8040 !important;  
     background-image: none !important;  
     padding:0px !important;  
 }  

Namensräume:

Gehört nicht wirklich hierher, aber trotzdem. Mich wundert und stört dieser komische Namensraum "Doku" sehr. Ähm ... Aufgabe des Wikis sollte doch sein, eine möglichst lückenlose Dokumentation der gängigsten web-Technologien zu erstellen (oder?). Wieso dann überhaubt einen gesonderten Namensraum für das, worum es eigentlich geht, und nicht die Dokumentation in den Hauptnamensraum verfrachten?

Oder noch besser: einen Namensraum HTML, einen CSS, einen JS ... usw. Das wäre auch für die DPL-Extension von erheblichem Vorteil, da sich dann (z.B.) dynamisch Referenzen zu anderen Technologien mit gleicher Thematik erstellen ließen.

Code-Beispiele:

Gehört auch nicht hier her und hab' auch gelesen, dass derzeit diverse Lösungen diskutiert werden. Trotzdem mal meine Gedanken dazu: zum einen wäre es schön, wenn jeder Nutzer beispielhafte Code-Schnipsel (so ungefähr wie bei php.net) beitragen könnte und man diese Schnipsel auch direkt per Klick ausprobieren könnte. Klaro, dass das wegen cross-site-scripting  nicht ohne erhebliches Sicherheitsrisiko machbar ist (äh ... nebenbei: ihr habt doch GeShi installiert ... wieso die Beispiele dann nicht mit Syntax-Highlight anzeigen lassen?).

Falls ihr zufällig vorhaben solltet, etwas in der Richtung secureHTML zu installieren, kann ich davon nur dringlichst abraten; alle Extensions, die angeblich sichere HTML-integration versprechen sind entweder alles andere als sicher (secureHTML zudem völlig verbugt), oder leisten nur einen Bruchteil dessen, was man machen könnte, wenn man $wgRawHtml auf true setzen würde.

Für meine eigenen Wikis habe ich lange herumüberlegt, wie man das Problem lösen könnte, und die meiner Meinung nach sicherste und zugleich leistungsfähigste Lösung wäre, HTML ausschließlich im MediaWiki-Namensraum zu gestatten, vobei dieser zunächst durch den WikiParser gejagt und wie eine Vorlage benutzt werden können müsste. Will heißen, man müsste innerhalb von <html>-tags (die nur im MediaWiki-Namensraum funktionieren dürfen), Wiki-Syntax benutzen können (oder halt zusätzlich {{html: ...}}). Wenn man dann die MediaWiki-Seiten als Vorlagen verwendet, müssten dabei die Übergabe-Parameter vor dem Rendern geprüft werden, also sowas wie htmlspecialchars(), oder so.

In der Praxis könnte das dann so aussehen, dass ein Nutzer seinen Code beiträgt, und ain Administrator nach eingehender Prüfung den dann in den MediaWiki-Namensraum verfrachtet. Müsste doch eigentlich machbar sein (hab's aber selbst noch nicht zustande gebracht, weil MediaWiki nicht gerade Benutzerfreundlich dokumentiert ist ...).

So, ich hoffe, das war jetzt alles nicht zu verschwurbelt und alles in allem: Klasse ...

Grüße,

WiMu

[Beat]

ich persönlich finde das rot bei nicht existierenden Seiten OK, nicht aber den gepunktelten Rahmen; der beißt sich schonmal mit aktivierten links, passt nicht zu den anderen und sieht z.B. bei #p-personal ziemlich daneben aus (sorry).

Nicht existierende Seiten werden im title-Attribut nochmals speziell beschriftet.
Tatsächlich stellt die gepunktete Linie einen Konflikt mit dem focus dar.
Da die gepunktete Linie hier visuell ist, gilt es eine andere Lösung zu finden.
Ich würde ein Ikon vorschlagen, symbolisch einem Stoppschild ähnlich.

Praktisch sollten solche Seiten nur für User mit Schreibrechten überhaupt verlinkt werden. Ich kann das leider nicht testen, da ja momentan jeder Schreibrechte hat.

Namensräume:

Gehört nicht wirklich hierher, aber trotzdem. Mich wundert und stört dieser komische Namensraum "Doku" sehr. Ähm ... Aufgabe des Wikis sollte doch sein, eine möglichst lückenlose Dokumentation der gängigsten web-Technologien zu erstellen (oder?).

Nein. Aufgabe des WIKI ist es, mit den verfügbaren Manpower (der nimmt drastisch ab, sobald ich nicht einen Tag aktiv bin) so etwas wie eine runde Sache zum Kern des Pudels abzüglich Accessoires zu liefern. Das ist immer noch fern von lückenlos.

Doku ist der Raum, auf welchen wir uns konzentrieren, der auch prioritäten geniesst.

Aber wenn du schon nach einem Namen fragst:
Mir würde nur das Wort Core: einfallen.

Wieso dann überhaubt einen gesonderten Namensraum für das, worum es eigentlich geht, und nicht die Dokumentation in den Hauptnamensraum verfrachten?

Namensräume sind sinnvoll. Wie kannst du den Kern erfassen, wenn er nicht als Kern abgeschieden ist?

mfg Beat

[WiMu]

Ich würde ein Ikon vorschlagen, symbolisch einem Stoppschild ähnlich.

Hm ... auch nicht schlecht, aber mir würde sowas in der Richtung: (von famfamfam) besser gefallen

Praktisch sollten solche Seiten nur für User mit Schreibrechten überhaupt verlinkt werden. Ich kann das leider nicht testen, da ja momentan jeder Schreibrechte hat.

Äh ... wie sieht's denn überhaupt aus? Sollen denn Seiten anonym bearbeitet werden können? Wenn nicht, wäre es in der Tat sinnvoll, links zu nicht existierenden Seiten gar nicht erst als links darzustellen. Um aber aus <a> ein <span> zu machen (oder nur den Text anzuzeigen), falls der User nicht eingelogt ist und die Zielseite nicht existiert; dazu müsste man eine eigene Extension schreiben, oder am PHP des skins rumschrauben (beides ziemlich server-belastend, da für jeden Link die Datenbank durchsucht werden müsste ... und die parser-Funktion {{#ifexist: ...}} ist nicht umsonst als "expensive parser function" deklariert). Per CSS oder JS ging's zwar auch, wäre aber nur gewurschtelt.

Namensräume sind sinnvoll. Wie kannst du den Kern erfassen, wenn er nicht als Kern abgeschieden ist?

Auch der Hauptnamensraum ist ein Namensraum (drum heißt der ja so ;) ). Und eben weil's der Kern ist, gehört da der Kern auch hin (oder man teilt es eben auf) ...

Grüße,

WiMu

[dedlfix]

Hi!

Praktisch sollten solche Seiten nur für User mit Schreibrechten überhaupt verlinkt werden. Ich kann das leider nicht testen, da ja momentan jeder Schreibrechte hat.
Äh ... wie sieht's denn überhaupt aus? Sollen denn Seiten anonym bearbeitet werden können?

Jein. Anmelden muss sein. Unangemeldet sind keine Bearbeitungen möglich. Da bei einer Anmeldung aber keine Person überprüft wird, ist das quasi anonym.

Lo!

[dedlfix]

Hi!

Wieso das monobook? Mit 1.16 kommt doch auch der vector-skin, und der wird über kurz oder lang das monobook als Standard ersetzen (so z.B. bereits auf den commons). Wenn ich mich recht erinnere setzt auch das usability-Gedöhnse den vector-skin vorraus. Früher oder später könnte das Probleme geben.

Vector als Unterbau und die Usability-Erweiterung brauchen eine größere Anpassung des Skins. Das würde auch neue grafische Elemente für die aufklappbaren Elemente bedeuten. Wenn sich daran jemand versuchen will, nur zu.

Da unbesuchte gegenüber besuchten Seiten hervorgehoben werden sollten statt umgekehrt, würde ich die Farben gegeneinander austauschen ...

Das ändert nicht viel daran, dass das orange zu hell ist. Mir persönlich ist auch eher die Unterscheidung zwischen vorhanden und nicht vorhanden wichtiger als zwischen besucht und nicht besucht.

Das sollte farblich angepasst werden,

Bitte konkrete Vorschläge, ich bin Techniker, kein Designer :-)

außerdem sollten externe links, die in Wahrheit gar nicht extern sind (z.B. wenn die Bearbeiten-Seite oder die History oder irgendwas per {{fullurl:blah}} verlinkt wird) als interne links dargestellt werden:

Die Idee finde ich gut und bau sie mit ein.

Oder noch besser: einen Namensraum HTML, einen CSS, einen JS ... usw. Das wäre auch für die DPL-Extension von erheblichem Vorteil, da sich dann (z.B.) dynamisch Referenzen zu anderen Technologien mit gleicher Thematik erstellen ließen.

Die DPL begnügt sich auch mit Kategorien. Die Namensräume orientieren sich nicht am Inhalt sondern an der Art der Darbietung. Es ist in der Hinsicht egal, was konkret besprochen wird. Eine Artikelserie über Injection-Lücken wäre bei Namensräumen à la HTML, CSS, JS keine Artikelserie mehr sondern überall verteilt. Und wenn es jeweils nur Abschnitte einer einzelnen Seite wären, wo sollten sie dann einsortiert werden? Kategorisieren sieht mir nach der besseren Lösung aus, denn davon kann man mehrere zuordnen. Deine Erklärung ("da sich dann ...") erschließt sich mir nicht.

Gehört auch nicht hier her und hab' auch gelesen, dass derzeit diverse Lösungen diskutiert werden. Trotzdem mal meine Gedanken dazu: zum einen wäre es schön, wenn jeder Nutzer beispielhafte Code-Schnipsel (so ungefähr wie bei php.net) beitragen könnte und man diese Schnipsel auch direkt per Klick ausprobieren könnte. Klaro, dass das wegen cross-site-scripting  nicht ohne erhebliches Sicherheitsrisiko machbar ist

Eben, weswegen der Teil "direkt per Klick ausprobieren" in der Form nicht in Frage kommt. Spätestens bei PHP hört da das Vertrauen auf die Gutmütigkeit der Anwender auf. Da braucht es eine vorgeschaltete Intelligenz, die die Harmlosigkeit feststellt und anschließend eine Freigabe erteilt oder auch nicht.

(äh ... nebenbei: ihr habt doch GeShi installiert ... wieso die Beispiele dann nicht mit Syntax-Highlight anzeigen lassen?).

Weil, nicht nur nach meiner Auffassung, ein generelles "Bunt" in vielen Fällen mehr vom eigentlich Erläuterten ablenkt als es nützt. "Bunt" ist ok für Artikel, bei denen der Code als Ganzes eine Rolle spielt (beispielswiese bei einem Artikel über das Affenformular) und nicht nur einzelne Elemente erkläutert werden sollen. Deswegen hatte ich damit angefangen, nur die jeweiligen besprochenen Elemente durch Fettschrift hervorzuheben, statt den gesamten Code zu GeShi-sieren.

Falls ihr zufällig vorhaben solltet, etwas in der Richtung secureHTML zu installieren, kann ich davon nur dringlichst abraten; [...]

Wir™ haben derzeit noch keine konkreten Pläne. Ich beispielsweise trage den Gedanken schon eine Weile im Kopf herum, aber er will nicht von allein reifen. Was wohl daran liegt, dass der generelle Lösungsweg schon absehbar ist, nur eine konkrete Umsetzung angefangen und probiert werden müsste.

Lo!

[WiMu]

Vector als Unterbau und die Usability-Erweiterung brauchen eine größere Anpassung des Skins. Das würde auch neue grafische Elemente für die aufklappbaren Elemente bedeuten. Wenn sich daran jemand versuchen will, nur zu.

Hab' ich schonmal gemacht ... nö, Danke ;)

Das ändert nicht viel daran, dass das orange zu hell ist.

Äh ... offenbar sind sich doch alle einig, dass das Orange zu hell ist. Warum dann nicht einfach dunkler machen? Das hübsche braun von der statischen Seite (##aa5522) böte sich doch an ...

Bitte konkrete Vorschläge, ich bin Techniker, kein Designer :-)

Ich lad's dir drüben gleich mal hoch (mit dem derzeitigen rot)

Die DPL begnügt sich auch mit Kategorien.

Nicht aber die Suche. Wenn mich im Moment CSS interessiert, wäre es schon hilfreich, entsprechenden Namensraum per checkbox auszuwählen

Eine Artikelserie über Injection-Lücken wäre bei Namensräumen à la HTML, CSS, JS keine Artikelserie mehr sondern überall verteilt.

Wenn man das nach CSS, JS usw. aufteilte, wäre da ja immer noch der Hauptnamensraum ...

Deine Erklärung ("da sich dann ...") erschließt sich mir nicht.

Na ungefähr so:

{{#dpl:
| titlematch= = ²{PAGENAME}²
}}

und schwupps hat man links zu allen Seiten, die genau so heißen (und vermutlich das gleiche Thema behandeln), wie die gerade angezeigte ... nur in anderen Namensräumen (also wenn's nach mir ginge CSS/JS/HTML usw.).

Da braucht es eine vorgeschaltete Intelligenz, die die Harmlosigkeit feststellt und anschließend eine Freigabe erteilt oder auch nicht.

Na genau das mein' ich doch ... ein admin verschiebt den Code (wenn er sauber ist) in den MediaWiki-Namensraum, und dieser wird als "echtes" HTML interpretiert (also das Ding wird nur dann per Klick ausgeführt, oder so)

Deswegen hatte ich damit angefangen, nur die jeweiligen besprochenen Elemente durch Fettschrift hervorzuheben, statt den gesamten Code zu GeShi-sieren.

Man könnte ja per Javascript/Ajax den Code an die API senden ... und dann je nach Lust und Laune bunt anzeigen lassen (ich hab' GeShi lieb)

Grüße,

WiMu

[dedlfix]

Hi!

Ich lad's dir drüben gleich mal hoch (mit dem derzeitigen rot)

Ich hab einen zweiten Link mit rotem Icon hinzugefügt.

Die DPL begnügt sich auch mit Kategorien.
Nicht aber die Suche. Wenn mich im Moment CSS interessiert, wäre es schon hilfreich, entsprechenden Namensraum per checkbox auszuwählen

Da gibt es noch x Anwendungsfälle, für die entweder das eine oder das andere Prinzip von Vorteil/Nachteil wäre. Ich hab mir ja die Namensräume nicht ausgedacht, aber ich verteidige sie schon aus technischen und organisatorischen Gesichtspunkten, weil mich bisher noch kein anderes Konzept dahingehend überzeugt hat, dass es den nicht unerheblichen Aufwand einer Umgestaltung lohnt. Da erscheint mit das Erstellen von zusätzlichen, für andere Verwendungszwecke sortieren/aufbereiteten Portalseiten als eine einfachere Lösung, um Ordnung und Überblick zu erzeugen.

{{#dpl:
| titlematch= = ²{PAGENAME}²
}}

und schwupps hat man links zu allen Seiten, die genau so heißen (und vermutlich das gleiche Thema behandeln), wie die gerade angezeigte ... nur in anderen Namensräumen (also wenn's nach mir ginge CSS/JS/HTML usw.).

Du stellst dir das zu einfach vor, fürchte ich. Denn das setzt voraus, dass die Seitenbenennung konsistent erfolgen kann und erfolgt sowie dass jeder das Benennungsprinzip versteht und umsetzt. Das Hinzufügen einer Kategorie geht hingegen bei jedem Namensraum und Seitentitel problemlos und man braucht zum Auflisten aller Seiten einer Kategorie noch nicht mal die DPL.

Da braucht es eine vorgeschaltete Intelligenz, die die Harmlosigkeit feststellt und anschließend eine Freigabe erteilt oder auch nicht.
Na genau das mein' ich doch ... ein admin verschiebt den Code (wenn er sauber ist) in den MediaWiki-Namensraum, und dieser wird als "echtes" HTML interpretiert (also das Ding wird nur dann per Klick ausgeführt, oder so)

Dieses Konzept ist ja auch schon als Kandidat grob skizziert worden.

Muss es MediaWiki sein? Dieser Namensraum hat doch schon eine Aufgabe. Mir wäre lieber, einen eigenen zu ertellen, wenn "abgegrenzter Namensraum" ein wesentlicher Baustein zu einer Lösung ist.

Deswegen hatte ich damit angefangen, nur die jeweiligen besprochenen Elemente durch Fettschrift hervorzuheben, statt den gesamten Code zu GeShi-sieren.
Man könnte ja per Javascript/Ajax den Code an die API senden ... und dann je nach Lust und Laune bunt anzeigen lassen (ich hab' GeShi lieb)

Ich bitte darum, zwischen den Anwendungsfällen zu unterscheiden und dabei die jeweiligen Zielgruppen zu berücksichtigen. Du bist Fortgeschrittener und kennst alle wesentlichen Code-Elemente. Für dich stellt GeSHi (irgendwann lern ich noch, wie sich das richtig schreibt) eine Hilfe in mehr oder weniger komplexen Codebeispielen dar. Aber ist es das auch für Texte der Fall, in denen Anfängern einzelne Code-Elemente in eher kleinen Beispielen erläutert werden sollen? Die Lösung wird sicher irgendwo in der Mitte liegen. Das beste Ergebnis erzielt man meiner Meinung nach immer noch, wenn man Effekte sparsam verwendet.

Apropos Lust und Laune: Es besteht ja immer noch die Möglichekeit, sich den Code in einen Editor seiner Wahl zu kopieren und dort die einem am besten gefallende Syntaxfärbung einzustellen. Außerdem kann man nun gleich auch noch Experimente mit dem Code anstellen, um so Erfahrungen im Umgang zu sammeln.

Lo!

[WiMu]

Muss es MediaWiki sein? Dieser Namensraum hat doch schon eine Aufgabe. Mir wäre lieber, einen eigenen zu ertellen, wenn "abgegrenzter Namensraum" ein wesentlicher Baustein zu einer Lösung ist.

'ne andere Alternative wäre irgendwas per Spezialseite; aber das wurde sicher auch schon genannt ... das wird schon noch.

Grüße,

WiMu

[Kai345]

[latex]Mae  govannen![/latex]

(äh ... nebenbei: ihr habt doch GeShi installiert ... wieso die Beispiele dann nicht mit Syntax-Highlight anzeigen lassen?).

Weil, nicht nur nach meiner Auffassung, ein generelles "Bunt" in vielen Fällen mehr vom eigentlich Erläuterten ablenkt als es nützt.

GeSHi läßt sich in der "Normalform" dahingehend konfigurieren, daß nur bestimmte Kategorien hervorgehoben werden, das müßte doch dann auch bei der Wiki-Einbindung funktionieren? Man könnte das Highlighting z.b. auf Kommentare und Keywords oder nur Kommentare oder $andere_Kombination beschränken und die besprochenen Elemente weiterhin durch Fettschrift gesondert auszeichnen. Gegebenenfalls noch unaufdringliche Farben wählen. Ich kann üblicherweise durch eine dezente(!) Hervorhebung die Syntax schneller/besser erfassen als bei komplett einfarbigem Text. Bei zu intensiver Syntax-Hervorhebung tritt der gegenteilige Effekt ein, da stimme ich durchaus zu.

Cü,

Kai

[dedlfix]

Hi!

Weil, nicht nur nach meiner Auffassung, ein generelles "Bunt" in vielen Fällen mehr vom eigentlich Erläuterten ablenkt als es nützt.
GeSHi läßt sich in der "Normalform" dahingehend konfigurieren, daß nur bestimmte Kategorien hervorgehoben werden, das müßte doch dann auch bei der Wiki-Einbindung funktionieren?

Schon, dabei bleibt aber das Problem, dass es ein Automatismus ist, der nicht weiß, worauf der Autor eines Beitrages das Augenmerk des Lesers gelenkt haben möchte.

Man könnte das Highlighting z.b. auf Kommentare und Keywords oder nur Kommentare oder $andere_Kombination beschränken und die besprochenen Elemente weiterhin durch Fettschrift gesondert auszeichnen.

Das geht nicht, weil meines Wissens innerhalb von <source> keine Wikisyntax zugelassen ist. Da geht also gar nichts individuelles.

Gegebenenfalls noch unaufdringliche Farben wählen. Ich kann üblicherweise durch eine dezente(!) Hervorhebung die Syntax schneller/besser erfassen als bei komplett einfarbigem Text. Bei zu intensiver Syntax-Hervorhebung tritt der gegenteilige Effekt ein, da stimme ich durchaus zu.

Die Frage ist, geht es denn bei den Stellen, wo auf "gezieltes Hervorheben" statt "allgemeines Bunt" gesetzt wird darum, den gesamten Code darzustellen? Ich denke nicht. Diese Stellen sind Erläuterungen einzelner Elemente und nicht kompletter Seiten/Programme. Wir sprechen hier über solche Dinge, wie: Erklärung des HTML-Elements X - da kommt es drauf an, die X im umgebenden Code zu sehen. Oder CSS-Selektor Y und die Auswirkungen auf HTML-Elemente - da will man sehen, welcher Selektor auf welche Elemente wirkt, was mit gezieltem Einsatz von Farbe/Formatierung verdeutlicht werden kann.

Für diese Fälle stört GenSHi mehr als es nützt. Es spielt jedoch da seine Stärken aus, wo nicht Elemente des Code als solche erklärt werden sollen, sondern der Code zum Erreichen eines Ziel dient. In einem Artikel wie dem zum Terminkalender kann eine Unterstützung durch GenSHi sehr wohl von Vorteil sein.

Lo!

[Bernhard]

Hi!

Jemand weiteres (ich kann mich grad nicht erinnern, wer und wo das war) beklagte sich darüber, dass die Farbe nicht besuchter Links zu hell sei. Auch hier bitte ich um Meinungen und Vorschläge.

Das war wahrscheinlich ich. Ich hab zwar keine Farben ausprobiert, aber wie wär's, wenn man den internen Links die gleiche Farbe wie den externen verpasst? Die externen haben zur Unterscheidung sowieso das dabei.

Grüße
Bernhard

[Bernhard]

Ich hab zwar keine Farben ausprobiert, aber wie wär's, wenn man den internen Links die gleiche Farbe wie den externen verpasst? Die externen haben zur Unterscheidung sowieso das dabei.

Mir fällt außerdem gerade auf, dass das bei den internen Links in der Navileiste auf der linken Seite auch schon so gehandhabt wird. Wenn man die anderen Links auch so einfärbt, dann hat man sozusagen als Bonus Konsistenz geschaffen - was sicher auch nicht schadet.

Grüße
Bernhard

[dedlfix]

Hi!

Ich hab zwar keine Farben ausprobiert, aber wie wär's, wenn man den internen Links die gleiche Farbe wie den externen verpasst? Die externen haben zur Unterscheidung sowieso das dabei.
Mir fällt außerdem gerade auf, dass das bei den internen Links in der Navileiste auf der linken Seite auch schon so gehandhabt wird. Wenn man die anderen Links auch so einfärbt, dann hat man sozusagen als Bonus Konsistenz geschaffen - was sicher auch nicht schadet.

Das ist ein Vorschlag, dem ich zustimmen kann. Also intern = extern, aber extern + Icon. Gegenstimmen?
(Die externen Links links sind ja quasi auch nur intern, nur eben nicht Wiki-intern.)

Bleibt noch, wie man nicht vorhandene Seiten kennzeichnet. Ein NEW-Icon fände ich unpassend, denn was noch nicht da ist, kann nicht neu sein. Ein Symbol für Nichtexistenz fällt mir auch grad nicht ein. Und Stopp- oder Verbotsschilder könnten das falsche Signal setzen.

Wie wäre es mit einer Blaufärbung? Dann hätten wir rötlich/bräunlich für normale Links und verwirren mit dem Blau die Anwender, die das als übliche Linkfarbe kennen ... :-)

Lo!

[Beat]

Bleibt noch, wie man nicht vorhandene Seiten kennzeichnet. Ein NEW-Icon fände ich unpassend, denn was noch nicht da ist, kann nicht neu sein. Ein Symbol für Nichtexistenz fällt mir auch grad nicht ein. Und Stopp- oder Verbotsschilder könnten das falsche Signal setzen.

Wie wäre es mit einer Blaufärbung? Dann hätten wir rötlich/bräunlich für normale Links und verwirren mit dem Blau die Anwender, die das als übliche Linkfarbe kennen ... :-)

Also ich finde die Farbkennzeichnung ungenügend.

mal über ein Symbol nachgedacht... Es ist fraglos, dass es hier keine starke Konvention gibt, auf die man aufbauen könnte.
Der title ist nicht genug (Verzögerung). Eine verbale Hover-Information wäre hier deutlicher.

Wenn ich eine alternative zur Punktierung vorschlagen müsste, käme mir die rote Wellenlinie aus der Rechtschreibung in den Sinn (etwas ist mit dem Link nicht in Ordnung).

mfg Beat

[dedlfix]

Hi!

Wenn ich eine alternative zur Punktierung vorschlagen müsste, käme mir die rote Wellenlinie aus der Rechtschreibung in den Sinn (etwas ist mit dem Link nicht in Ordnung).

Diesen und den Vorschlag der Navigationsleistenfarben von Bernhard habe ich nun mal eingebaut.

Meine Meinung dazu: Unterwellen ist optisch noch stärker als unterpunkten. Das wäre also kontraproduktiv, wenn man die Auffälligkeit reduzieren möchte.

Die Navigationsfarben sind mir im Fließtext zu unauffällig. Für den besuchten Link mag das vielleicht noch angehen, jedenfalls wenn man mal eventuelle Sehschwächen außer Acht lässt. Aber für den unbesuchten muss ich mich schon etwas anstrengen, um ihn zu erkennen.

Lo!

[Bernhard]

Hi!

Bleibt noch, wie man nicht vorhandene Seiten kennzeichnet. Ein NEW-Icon fände ich unpassend, denn was noch nicht da ist, kann nicht neu sein. Ein Symbol für Nichtexistenz fällt mir auch grad nicht ein. Und Stopp- oder Verbotsschilder könnten das falsche Signal setzen.

Die rote Farbe für nichtexistierende Links passt mMn (ein Tick rötlicher wäre vielleicht fein, evtl. sogar (255,0,0)). Ein Icon o.ä. würde ich weglassen; ich meine, Icons sollten nur für externe Links reserviert bleiben.

Wenn man das rot knalliger macht, dann kann man evtl. auch auf die Unterstreichung verzichten, was auch nicht schlecht wäre. Von Haus aus unterstrichene Links finde ich immer irgendwie unpassend.

Grüße
Bernhard

[Bernhard]

Hi!

Wenn man das rot knalliger macht, dann kann man evtl. auch auf die Unterstreichung verzichten, was auch nicht schlecht wäre. Von Haus aus unterstrichene Links finde ich immer irgendwie unpassend.

Ich hab das jetzt mal mit Firebug ausprobiert und muss sagen knallrot (255,0,0) und ohne jegliche Unterstreichung gefällt mir gar nicht schlecht. Hat jemand Einwände gegen diese Darstellung?

Grüße
Bernhard

[dedlfix]

Hi!

Wenn man das rot knalliger macht, dann kann man evtl. auch auf die Unterstreichung verzichten, was auch nicht schlecht wäre. Von Haus aus unterstrichene Links finde ich immer irgendwie unpassend.

Ich hab das jetzt mal mit Firebug ausprobiert und muss sagen knallrot (255,0,0) und ohne jegliche Unterstreichung gefällt mir gar nicht schlecht. Hat jemand Einwände gegen diese Darstellung?

Mit knallrot hätte man eine Lösung für das kleine Problem der Nicht-vorhanden-Links. Wenn es noch/stattdessen ein Symbol sein soll, fiel mir ein + ein.

Bleibt noch, dass die Menüleisten-Farben im Fließtext nicht besonders geeignet sind.

Und was auch noch offen ist, wäre das #header-Problem im IE6. Da hab ich mittlerweile als Workaround probiert, #header und #p-personal aus dem umschließenden #column-one herauszunehmen. Das geht, wenn man um die beiden auch noch ein eigenes div setzt. Das braucht auch gar kein CSS, nur vorhanden sein muss es, sonst ist #header und #p-personal überhaupt nicht sichtbar. Kennt noch jemand eine rein CSS-basierende Lösung?

Lo!

[Bernhard]

Hi!

Mit knallrot hätte man eine Lösung für das kleine Problem der Nicht-vorhanden-Links. Wenn es noch/stattdessen ein Symbol sein soll, fiel mir ein + ein.

Ich halte ein Icon bei internen Links (egal ob besucht, nicht besucht oder mit nicht existierendem Ziel) für schlecht. Icons sollten auf externe Links beschränkt sein.

Bleibt noch, dass die Menüleisten-Farben im Fließtext nicht besonders geeignet sind.

Stimmt leider. Als Lösung bleibt wohl nur, die Farbe irgendwie aufzuhellen - womit wir uns wieder in Richtung des ursprünglichen Problems bewegen.

Und was auch noch offen ist, wäre das #header-Problem im IE6.

Müssen wir denn wirklich noch auf den IE6 Rücksicht nehmen? Von dem sagt Microsoft selber schon, dass er ein Risiko darstellt.

Grüße
Bernhard

[dedlfix]

Hi!

Und was auch noch offen ist, wäre das #header-Problem im IE6.
Müssen wir denn wirklich noch auf den IE6 Rücksicht nehmen? Von dem sagt Microsoft selber schon, dass er ein Risiko darstellt.

Ich habe nicht vor, sämtliche Kleinigkeiten für ihn anzupassen, aber wenigstens grundlegend bedienbar sollte die Seite mit ihm sein. Sicherheitsrisiko hin oder her, er ist nun mal noch zu häufig vertreten. Und außerdem: https://forum.selfhtml.org/?t=197351&m=1323641.

Lo!

[Bernhard]

Hi!

Und außerdem: https://forum.selfhtml.org/?t=197351&m=1323641.

Diese Tatsache ist mir nur allzu gut bekannt; ich verwende selber noch Windows 2000. Firefox (vermutlich Opera und Chrome genauso) läuft aber problemlos unter W2k, auch in der aktuellsten Version.

Grüße
Bernhard

[dedlfix]

Hi!

Bleibt noch, dass die Menüleisten-Farben im Fließtext nicht besonders geeignet sind.

Nächster Versuch, einmal „Neu laden“ bitte. Ich hab mal das gesamte Dokument mit den Linkfarben aus Vorschlag 2 versehen (linkes Menü ist aber unverändert). Das Symbol an der nicht vorhandenen Seite passt optisch nicht so ganz, oder?

Lo!

[Bernhard]

Hi!

Nächster Versuch, einmal „Neu laden“ bitte. Ich hab mal das gesamte Dokument mit den Linkfarben aus Vorschlag 2 versehen (linkes Menü ist aber unverändert).

Die unbesuchten internen Links sind und bleiben so viel zu hell. Auch wenn Vorschlag 1 im Fließtext nicht so gut passt, ist er immer noch besser als Vorschlag 2.

Das Symbol an der nicht vorhandenen Seite passt optisch nicht so ganz, oder?

Halte ich für kontraproduktiv; Symbole sollten auf externe Links beschränkt bleiben.

Grüße
Bernhard