Benutzer Diskussion:Dedlfix/DBedarf

Hinweis:

Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.

• Deshalb sollten Diskussionen über den Artikel zum Thema „DBedarf“ besser im SELFHTML-Forum geführt werden.
• Unter https://forum.selfhtml.org/self/new kannst du einen entsprechenden Beitrag erstellen.
• Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

Diskussionsbedarf

Hallo Dedlfix,

Wie ich es irgendwo anders schon mal vermerkt hatte, bin ich in den letzten vierzehn Tagen Arbeit am Wiki, hie und da, auf Probleme gestoßen.
Mein Import 8.1.2 von JavaScript ist jetzt weitgehend abgeschlossen.
(Die vier DHTML-Seiten sind in Wirklichkeit alle rein JavaScript basierend. Daher werde ich auch diese ins JS-Inhaltsverzeichnis integrieren und übertragen.
Sind die Autorenrechte der vielen namentlich signierten JavaScript-Artikel  eigentlich auch alle, samt und sonders, fürs SELFHTML-Wiki freigegeben?)

Nein, die haben zwar der Veröffentlichung als Artikel zugestimmt, nicht jedoch automatisch einer Wikifizierung, denn das war damals noch gar nicht bekannt. Die Autoren müssten um ihr Einverständnis gebeten werden.

Genau das habe ich mir auch so gedacht. Ich habe im Moment eh keine Zeit dazu, bzw. es gibt Vordringlicheres.

Wenn ein Artikel Wiki-geeignet erscheint, könnte man ja ggf. in einigen Wochen, den einen oder anderen Autor um sein Einverständnis fragen.

Nun habe ich begonnen, die kleineren Formatierungsfehler zu beheben, sowie die internen Links einzufügen. Auf zwei Seiten^{[1] [2]} ist das schon geschehen.

Bitte Links nicht generell in Fettschrift auszeichnen. Das war zwar in der alten Doku so, im Wiki haben wir das aber nicht übernommen. Für eine Gestaltung, die nicht aus inhaltlichen Gründen vorgenommen wird, sind außerdem CSS-Regeln besser geeignet.

Fettschrift:  Da hast du Recht. Ich wollte in der Formatierung zunächst nur möglichst nahe am alten Wiki bleiben. (Für die diesbezügliche Perfektion habe ich eh keine Zeit und würde auch nicht lohnen.)

Ich werde es jetzt vorerst fett lassen und sofort nach dem Übertrag, die Fettschrift im allerersten Edit wieder raus schmeißen.

... sind außerdem CSS-Regeln besser geeignet:  Hast du prinzipiell auch Recht. Aber um auf das Common.css Einfluss nehmen zu können, bräuchte man ja das entsprechende MediaWiki Edit Recht. Dieses beanspruche ich im Moment aber gar nicht. Ich bin ja erst seit zwei Wochen dabei. Allerdings gibt es hierzu, zu CSS (gleich später) ein, zwei Vorschläge meinerseits. Die entsprechenden CSS-Änderungen kannst ja du selbst, bei Einverständnis, vornehmen.

Aktualisieren will ich die JS-Seiten, bevor sie nicht vom Benutzernamensraum ins eigentliche Wiki zu überführt worden sind, bewusst nicht. (Auf Kladde habe ich aber damit schon angefangen.)
Bevor dieser Transfer in den nächsten Tagen beginnen könnte, will ich aber noch eine ganze Reihe von Punkten mit dir diskutieren. Auch Matthias A. und andere können sich da gerne einmischen.

Wenn du dazu Zeit hast, können wir das so machen?   Mit freundlichen Grüßen, Klaus 12:14, 4. Apr. 2011 (CEST)

Ich hab da auch einige Gedanken, die ich in der Hilfe:Artikel vorangestellt habe. Allerdings weiß ich auch, dass das eine ganze Menge Arbeit ist, die Texte so umzuformatieren/-formulieren, dass allgemeine Informationen nicht im Beispiel-Erläuterungstext oder (nicht unbedingt notwenigerweise) im Beachten-Sie-Abschnitt stehen. Allerdings kann ich eine solche Umarbeitung auch nur empfehlen/mir wünschen und sie nicht verlangen.

Wenn es dir beim Diskutieren um einen breiteren Publikumskreis geht, wäre im Forum mehr Potential. --dedlfix 13:17, 4. Apr. 2011 (CEST)

Ich hab da auch einige Gedanken, ...  Dass die „allgemeine Informationen nicht im Beispiel-Erläuterungstext [...] stehen“ etc. mag langfristig auch umgearbeitet werden können.

Das allerwichtigste erscheinen mir aber zuerst mal, die dringend notwendigen Aktualisierungen zu sein. Beispiele:  Unterstützende Browser Versionen, Layers in ein Archiv zu schieben, neue Informationen hinzufügen und vieles mehr...

Wenn es dir beim Diskutieren um einen breiteren Publikumskreis geht, wäre im Forum mehr Potential.

Gerade vorher habe ich mich im Forum ein bisschen näher umgeschaut und sah mit Anerkennung und Erstaunen, wie aktiv es da zugeht!

Da es mir aber spezifisch hier ums Wiki geht, glaube ich schon, dass wir das auch genau hier im Wiki diskutieren sollten. Auf welcher Seite ganz genau, das habe ich mir auch schon überlegt. Habe aber nichts bzw. keine völlig überzeugende gefunden. Ich werde, wohl heute noch, einfach mal hier auf deiner Diskussionsseite loslegen. Vielleicht können wir es später anders wo hin verschieben bzw. kopieren. (Nur eine Section verschieben geht wohl nicht.)

Aber gerne kannst du dann, morgen oder übermorgen (und wenn es dir angemessen erscheint,) einen Hinweis dazu im Forum posten. Was dann vielleicht den Vorteil eines breiteren Meinungsbildes hätte.

Bis später,  Klaus 15:27, 4. Apr. 2011 (CEST)

Items

Im Nachstehenden will ich dir einfach nur alles was mir aufgefallen ist und/oder wozu ich auch Anregungen habe, auflisten:

Zuerst zu Bitte:

Gut, wenn du es erst zu spät gesehen hast: „Zu spät, schon alles getippt.“ Hättest aber auch erst ganz lesen und dann erst anfangen zu antworten. Nachdem du Sections eingefügt, geht es ja halbwegs. Ich schreibe es deshalb am Anfang, um dich anhand des folgenden Abschnitts auf einen wichtigen Nachteil hinzuweisen. Du hast nicht datiert und nicht signiert.

Doch, aber nur ganz unten, sonst hätte ich konsequenterweise auch alle deine durch meine Antworten entstandenen Textstücke nachsignieren müssen. Hauptsache die Einrückungstiefen werden mit jeder Antwort angepasst, damit die eine unten stehende Signatur zugeordnet werden kann.

Jaja, stimmt. Meine hättest du „konsequenterweise auch [...] nachsignieren müssen“. Aber erst nachdem du sie selbst in Sections geteilt. Aber lassen wir das. Es geht ja jetzt einigermaßen.

Ich werde es in meiner Antwort jetzt auch nicht tun. Solange nur wir beide einige Replies austauschen, bleibt es (noch) lesbar. Stell dir aber vor, (was ja auch manchmal sein kann,) ein Dritter oder Vierter will, eventuell auch Tag später, noch was einfügen. Dann hat sich's mit der Lesbarkeit. Wer hat was und wann gesagt?

Ein Wiki ist eben kein Diskussionsforum. Deswegen schlage ich vor, Dinge, die jetzt noch nicht erledigt sind und weiteren großen Diskussionsbedarf versprechen, ins Forum zu verlagern.

Da stimme ich dir nicht zu. Ich war, bin und werde auch voraussichtlich nie ein aktiver Forumsbenutzer sein. Weder in SELF noch sonst wo. Ich bin höchstens nur ein Forums-„Profiteur“ vorausgesetzt, eine Suchmaschine führt mich da hin. Der Grund dazu ist wohl der, dass ich ungeduldig bin. Wenn ich was wissen will, dann will ich das „gleich“ wissen. Und nicht erst 24-36 Stunden später. In 99% aller Fälle schaffe ich das auch, und finde meine Lösung in 3-90 Minuten Online-Recherche. Natürlich kann ich mir vorstellen, dass mit Kollegen zu fachsimpeln auch ganz nett sein kann. Aber z.B. in einem Wiki könnte die genaue Lösung dann kurz, knapp und präzise auch dargestellt werden. Das wäre für mich ein gutes Resultat. Ohne die Irr- und Abwege und sonstiges Gerede. Aber ich respektiere die aktiven Foren-Liebhaber durchaus. Jeder wie er will. Nur die Wiki-Diskussion, umgekehrt, vermehrt hier ins Wiki.

Ebenfalls kontraproduktiv ist, wenn man grad am Antwortverfassen ist und zwischenzeitlich jemand anderes die Seite verändert. Das kann man nicht verhindern, aber es macht Mehrarbeit, das dann nochman nachzueditieren.

Naja.

„Find ich nicht gut, dann muss man immer hin- und her springen...“ Stimmt nur bedingt. Mein (recht langer) Post von gestern Nacht: Auf meinem Monitor dennoch nur 1⅔ Fensterseiten. N' kleiner Scroll. Nicht „nochmal zu wiederholen oder anderweitig zu referenzieren“, sondern nur ein kleines Stichwort und jeder aufmerksamer (Nach-)Leser weiß genau auf was der Antwortende sich bezieht.

Solange es nicht ausartet, mag das gehen. Aber wenn sich das System der Zwischenantworten nicht (wenigstens als Kompromiss zu einem echten Forum) in der Wikipedia bewehrt hätte, hätte man es dort sicher anders gelöst, denke ich.

Kurz und knapp, nochmals meine Meinung dazu. Bei einer einzelnen oder ganz wenigen Fragen: Dazwischen schreiben, ok. Sonst ein/zwei Replys en-block. Später wenn nötig einzelne Punkte extra in eigenen Abteilungen auslagern. Ansonsten auch viel „Unsitten“, auch in Wikipedia. Aber lassen wir das. Ist jetzt alles dazu gesagt.

Der dem die Antwort gilt, checkt das sowieso gleich. Bei der ersten Antwort n' bisschen Scrollen, ist immerhin noch leichter, als mühselige History-Vergleiche um als Leser überhaupt etwas zu verstehen. „Einschränkungen“ und Kompromisse sind nicht so ganz meine Stärke. Da bin ich zu sehr boolean. Höchstens, dass – ja das kenne ich – dass bei und im Verlauf einer Diskussion, scheinbar unversöhnliche Widersprüche in ihrem dreifachen Wortsinn „aufgehoben“ werden. Das ist auch das beste, was bei Diskussionen herauskommen kann. Dennoch, ich arbeite tausend mal lieber in einem Wiki. Diskutieren, nur wenn es sein muss.

Server-Probleme

Schon gleich in den ersten Tagen hatte ich Error 500 Probleme. Zuerst dachte ich es läge am Quelltext. Irgendwelchen Parsing-Probleme die den Server in die Knie zwingt. Nach Tests, vor allem durch Code-Wegnahme hatte ich es bald verstanden: Bei wohl 128 kB ist Schluss. Etwas knapp konfiguriert. Aber wäre es nur das, dann gerade noch erträglich.

128k Seitengröße? Naja, das ist ja auch arg viel, vor allem beim Lesen. Es kommt ja eigentlich schon bei 32k eine Warnung. Besser ist es, die Themen auf mehr (Unter-)Seiten aufzuteilen. Das lässt sich auch einfacher verlinken als über Anker in den Seiten und rückvervolgbar sind Links auf Seiten wesentlich besser als Links auf Anker in Seiten.

Das Wiki ist ja eigentlich eine Lexikon-Software und verfolgt deswegen grundsätzlich die Philosophie: 1 Thema === 1 Seite. Für Javascript könnte man es so machen, dass die Eigenschaften und Methoden jeweils eigene Unterseiten bekommen. Wenn für den Leser eine Gesamtseite bereitgestellt werden soll, kann man diese Unterseiten wie Vorlagen-Verwendungen in die Hauptseite einbinden.

Man liest ja fast nie alles. Meistens nur quer. Und dann nur einige, jetzt interessierende Abschnitte genauer und aufmerksam. Die Methoden und Eigenschaften stets auseinander reißen ist mir unvorstellbar. Manchmal gibt es nur eine Methode und zehn Eigenschaften. Zwei Seiten??

Eigentlich 12 Seiten. Genauer: eine Unterseite für die Methode, zehn Unterseiten für jeweils die Eigenschaften und noch eine Hauptseite für das Objekt/die Klasse an sich, die durch Vorlageneinbindung den Text der Methoden und Eigenschaften inkludiert. Es ginge auch bei wenig Text für die Methoden und die Eigenschaften, nur eine Methoden- und eine Eigenschaften-Seite nebst der Hauptseite anzulegen. Aber ich denke, man sollte das lieber gleich richtig vereinzeln, dann muss man das nicht später nachholen, wenn die Textmenge ansteigt, und es ist konsequent zu den sowieso schon durch viel Text stark vereinzelten Themen.

Nö. Sehe ich völlig anders. Was zusammengehört soll auch zusammen bleiben. Die Serverleistung soll da sein.

Servezeit-Probleme

Einen nur in Paragraphen gegliederten Lorum ipsum Text liefert mir der Server auch bei knapp 128 kB in (akzeptablen) 0.7 sec. Jedoch braucht es zum Anzeigen meiner beiden, schon in zwei Teile gesplitteten, jeweils ±75 kB großen HTML-Elementobjekte-Seiten^[1] [2] jeweils geschlagene acht Sekunden oder nur ganz unwesentlich darunter. Das kann doch nicht angehen, wie du mir sicher zustimmen kannst. Die Besucher würden schnell die Lust an unserem Wiki verlieren, wenn dies so bliebe. Auf die Schnelle weiß ich keine andere Lösung als die beiden schon geteilten Teile nochmals jeweils zu halbieren, obwohl eigentlich alles zusammen auf eine einzige Seite gehört. 150 kB ist zwar etwas viel, aber nicht „wahnsinnig viel“. Nur die Hälfte, ok. Wenn es denn nu' schnell geserved würde! Bei einem Blindtext ist genau das der Fall. Daher kann ich mir letztlich nur noch vorstellen, dass die jeweils knapp vier Dutzend mal verwendeten Beispiel-Vorlagen diesen unhaltbaren Zeitverlust bewirken. Oder hättest du sonst noch eine Idee?

Ist es die Render-Zeit? Die bekommt man nur durch Verkleinerung hin. Ist nur der erste Seitenaufruf langsam und sind die weiteren schneller, dann hat nur die Cache-Füllung etwas gebraucht. Ansonsten löst sich das Problem vielleicht auch durch die unter Punkt 1 vorgeschlagene Aufteilung.

Das ist die Zeit, die im Browser-Quellcode auf allen MediaWiki-Seiten stets vermerkt wird. Ganz unten: <‍!-- Served in 1.507 secs. --></body></html>. Wahrscheinlich identisch mit der Render-Zeit: PHP+SQL. „Die bekommt man nur durch Verkleinerung hin.“ Nein!  Genau das sagte ich doch. Auf anderen Wikis, auf anderen Servern, schmeiße ich zu Testzwecken mal locker 1 MB „Lorum ipsum“ rein: Geserved in 1.254 secs. Bei dann gleich 16 MB Wartezeit, aber kein Error 500. Hab nicht abgewartet, sondern abgebrochen. Bei SELFHTML-Wiki knapp 128 kB Blindtext (Lorum ipsum): 0.7 secs. Gut die Hälfte, aber mit Vorlagen, fast 12x so lang 8 secs. Da muss es doch an was anderem liegen. Von wegen: „Die bekommt man nur durch Verkleinerung hin.“ Das ist genau die Art der „Einschränkungen“, die ich nicht ab kann. Von einem kleinen, vermutlich nicht allzu schwer lösbaren technischem Problem sich inhaltliche, beziehungsweise gestalterische Unfreiheiten auferlegen zu lassen. Ich selbst bin leider kein ausgesprochener Vorlagen-Crack. Lerne noch und kenne auch ParserFunctions zu schlecht, an denen es vielleicht liegt. Das müssen wir doch hinkriegen!

Riesige Texte bereiten nicht nur solche beobachteten technischen Probleme - die man vielleicht mit mehr zur Verfügung gestellten Ressourcen lösen kann (wenn man das dem Server zumuten will/kann) - sie sind auch mit dem kleinen Textfensterchen unhandlich zu bearbeiten, besonders in der Phase des Kontrollesens, wo man das Rendering des Wiks benötigt und nicht in einem externen Editor einfach nur schreiben kann.

Und dann gibt es technische Dinge, die man nicht einfach so beheben kann, wie beispielsweise externe Verweise auf Anker. Es ist nicht besonders clever, gegen die Philosophie eines Systems zu arbeiten. Vielleicht ist das System dann nicht geeignet, aber wer hat die Kraft, ein besseres System zu suchen und in Betrieb zu nehmen?

Schlappe 120 kB sind nicht „riesig“. Vergleich's doch mal mit einem einzigen JPG-Image Gewicht. Leistungsfähige Server sind weder rar noch teuer. Außerdem glaube ich gar nicht, dass es am NTT-Server liegt. (Gut, Japon-Telecom. Die Server aber ist hoffentlich hier in Europa.) Eher an den Vorlagen. Bei Section-Edit ist die Gesamtgröße eh egal. Aber ich gebe praktisch immer gesamt aus. Keinerlei Probleme beim Korrekturlesen. Mediawiki ist supertop, relativ wenig Schwächen und Bugs. Ich kenne nichts besseres. Ich werd mal mit meinen geringen Vorlagen-Kenntnissen Tests machen und dir dann in 'ner Woche oder so, berichten, ob ich herausgefunden habe oder nicht, woran's liegt. Wollen wir dahingehend verbleiben?

Bilder werden vom Apachen direkt ausgeliefert, Wiki-Seiten müssen immer zusammengebaut werden. Cachen geht nur in Teilen, weil stets dynamische Informationen (wie im Seitenfuß oder benutzerspezifische Ergänzungen) hinzugefügt werden. Die Server gehören auch SELFHTML selbst - wurden vor vielen Jahren mal nach einer Spendenaktion angeschaft -, stehen nur bei NTT im Rechenzentrum und der Traffic ist frei.

Danke für die Info bzgl. Server. Bzgl. Bilder, Apache, ok. Nur es sind erwiesenermaßen die vielen Vorlagen schuld. Mein Test eben mit HTML-Elemente_1, vor und nach Herausnahme von nichts anderem als der (nicht wenigen) Brackets. Servezeit vorher: 8,5 s und nachher 0,5 Sekunden. Wir werden früher oder später eine gute Lösung finden.

Eureka! Es sind die Browser-Icons. Und nicht die Beispielsvorlagen wie ich zuerst vermutete. Nach deren Ersetzung durch ihre jeweiligen Original-Divs ergab sich keinerlei Ladezeitverkürzung. Wohl aber nach der Lahmlegung der 42 Iconset-Vorlagen meiner Testseite. Plong: Von 8,4 s, auf nur noch 1,2 Sekunden. Also wahrscheinlich nicht mal "Iconset", sondern es ist höchstwahrscheinlich "Icon" selbst, das den Hemmschuh betätigt.

Vorlagen

Apropos Vorlagen. Ich habe bisher noch keine gemacht. Wenn bald doch, mal die eine oder andere Neue, mir sinnvoll erscheinende; so bitte ich dich doch gleich mit einem Purge-Tab ausgestattet. Immer ausloggen, einloggen und dann noch die F5-Taste drücken. Das ist viel zu umständlich. Die Purge-Erweiterung hingegen ist einfach und effektiv. Da man einen solchen zusätzlichen Purge-Tab nicht jedem registrierten Benutzer zumuten kann (Nicht, dass es gefährlich wäre. Es löscht ja nur den jeweils eigenen Wiki-Cache. Aber wer keine Vorlagen macht, der kann damit nichts anfangen...) müsstest du mir schon eine neue Usergroup zuweisen. „Bürokrat? Nein Danke!“ Ich weiß nicht, was sich da die anglophonen Mediawiki-Macher so denken. Aber „Bürokrat“ will doch niemand sein, oder? Ich schlage dir da die neue Usergroup:Agent vor. Von lat. agere, handeln, tun. Also: der (etwas mehr) Handeln könnende. Gegenüber „Bürokrat“ ist „Agent“ doch viel attraktiver. (Wie auch nicht zuletzt, die jüngst in die Schlagzeilen geratene Agentin 00SEX es beweißt ;-) Als das bisher einzige zusätzliches Recht dieser neuen Benutzergruppe bitte ich dich um das oben genannte, praktische Purge-Tab.

Bitte die Seite mit ?action=purge aufrufen (Ich weiß nicht, ob das auch mit wiki.selfhtml.org/wiki/NS:Seite?action=purge geht oder nur mit wiki.selfhtml.org/mediawiki?title=NS:Seite&action=purge). Ansonsten kannst du auch ein benutzerdefiniertes Javascript erstellen, das dir solch einen Link in die Seite einfügt.

Ja guter Tipp. ?action=purge als Lesezeichen. Reicht auch. „Benutzerdefiniertes Javascript“ da muss ich leider passen. Kenne ich mich nicht aus. Weiß ich nicht wie's geht. Benutzerdefinertes CSS interessiert mich sowieso nicht, sowie ich auch bewusst nie an den default-Styles im Browser herum doktere. Plugins und andere Optionen, ja. Style-Änderungen, nein. Aber zum benutzerdefinierten Javascript werde ich mich bald mal kundig machen.

Unter Spezial:Einstellungen-Aussehen gibt es zu jedem Skin einen Verweis auf benutzerdefiniertes CSS und JS. Dort einfach JS und/oder CSS einkippen.

Danke für die konkrete Hinführung. Hab's schon mal irgendwann gesehen. Aber welchen sinnvollen Script-Code soll ich da reinschreiben. Fällt mir nicht viel dazu ein. Trotzdem nochmals Danke.

Erweiterungen

Um zwei weitere, allen Benutzern offenstehende Erweiterungen bitte ich ebenfalls:

TreeAndMenu

Die Erweiterung TreeAndMenu kann uns vor allem in Inhaltsverzeichnissen nützlich sein. Man kann da frei bestimmen welche Verzeichnis-Tiefe per default offen ist und welche nur (bis hin zu Unterabschnitten der einzelnen Seiten,) dann noch manuell auf- bzw. wieder zugeklickert werden können. Das fände ich sehr praktisch.

Schau ich mir an, kann ich aber nicht sofort.

Okay.

PageCSS

Die Erweiterung PageCSS erscheint wohl auf den ersten Blick bedenklich, wenn nicht gar suspekt zu sein. Vielleicht auch nur, weil sie in Wikis im allgemeinen (noch) nicht sehr verbreitet ist. Dennoch glaube ich, dass diese Erweiterung, gerade in unserem Wiki eine wirkliche Bereicherung wäre. Sicherheitsprobleme, da nur CSS, gibt ist bei dieser Extension natürlich gar keine. Die Missbrauchsgefahren wohl. Sie liegen anderswo. Erstens, könnte ein schlecht inspirierter Benutzer z.B. auf die Idee kommen, mit vielen farblichen Veränderungen das bestehende Design zu verhunzen. Zweitens, könnte ein Vandale z.B. mit <h1>-hidden, gar den Titel der Seite verbergen! Beide diese Gefahren, die des Missbrauchs und die des Vandalismus sind bei Lichte betrachtet, auch nicht größer als die jetzt schon. Mit einer durchgängigen <div> und style="background:..." kann auch jetzt, jeder sehr leicht, eine ganze Seite in z.B. Pastellblau oder in Rosa tauchen. Macht aber Gott sei Dank niemand. Die Gefahr eines solchen „h1-hidden“ ist auch nicht größer, als ein sonstiger Seiten-Leerungs-Vandalismus oder ähnliches... Auch will ich dich ausdrücklich darauf hinweisen, dass diese Erweiterung PageCSS heißt, also nicht Wiki-übergreifend ist, sondern nur auf der jeweiligen Seite im Quelltext mit <css>...</css>-Tags geparsed wird. Weitere, andere Gefahren sehe ich nicht. Die Vorteile sind dagegen, m.b.M.n. groß. Insbesondere in den nicht allzu seltenen Fällen spezifischer Tabellenformatierungen trägt diese Erweiterung, gut genutzt, erheblich zur Vereinfachung bei. Nicht zuletzt, was doch auch sehr wichtig ist, ebenfalls zur Lesbarkeit des Codes. Vorlagen helfen dabei im konkreten Fall nichts oder nicht viel. Eine pretty-table Vorlage, schön und gut. Aber welcher Aufwand und vor allem „Code-Wust“ muss dann doch für eine wirklich schöne Tabelle betrieben bzw. entsteht. Zwar ist in der Wiki-Syntax alles möglich. Jedoch muss da in den <td>s alles, Zeile für Zeile, unnütz kopiert werden. Wie elegant und einfach ist da CSS! Ich glaube du hast verstanden was ich meine. Überlege es dir mal. Mir wäre es wichtig und gerade auf unseren Seiten könnte ich mir durchaus vorstellen, dass es auch andere Autoren auf dem Wiki hier zu schätzen wüssten.

Der Vorschlag kam schon mal (ich find's grad nicht), wurde aber abgelehnt. Es gibt Vorlagen für wiedernutzbare Formatierungen.

Bleibt weiter offen. Versuch mal die damalige Beschlussseite zu finden. Vorschläge, auch wenn einmal abgelehnt, können ggf. erneut erörtert werden. Finde bitte die Seite mit den Argumenten. „Wiedernutzbare Formatierungen“? Zweifle ich. Höchstens classes, die du mir in's common schreibst. Das wäre vielleicht halbwegs (viertelwegs?) annehmbar. CSS ist einfach elegant und einfach. Missbrachsgefahren, besonders auf SELFHTML, quasi Null. Jeder Nachbearbeiter kann ja ebenfalls den betreffenden CSS-Wert ändern, der ihm nicht passt. Kein Unterschied zu Text.

Es ist schon richtig, Dinge später nochmal neu zu beleuchten und gegebenenfalls eine Meinung oder Entscheidung zu ändern. Aber speziell beim CSS sehe ich keinen Bedarf an derartiger Individualität pro Seite. Wiederbenutzbare Formatierungen sind beispielsweise die Vorlagen für Beachten Sie oder die Beispiel- und Info-Boxen.

Wenn du irgendwo konkreten Bedarf hast, dann schreib das auf die dortige Diskussionsseite. Vielleicht lässt sich eine bessere Lösung finden, als individuelles CSS.

Es geht nicht um „individuelles“ CSS, sondern um Vermeidung von ätzendem Wiki-Syntax Code-Wust durch modernes, elegantes CSS.

Konkretes Beispiel:  Eine Tabelle, vier Spalten, 40 Reihen. Wiki-Syntax: <colgroup> funzt nicht. <col> funzt nicht. Off, OK.

Dann: erste Spalte jeweils text-align:center, zweite Spalte jeweils text-align:left, dritte Spalte jeweils (warum nicht, manchmal bei Zahlenwerten) text-align:right.

Dann: Ein nettes padding:left bzw. right rein, von knapp einem em und nicht so barbarisch, wurschtig und stillos, so häßlich auf den Rand geklebt wie allzu oft zu beobachten.

PageCSS, kein Problem. Spalte 1, 2 3 und 4. Jeweils eine Klasse: .a, .b, .c und .d. Mit Wiki-Syntax copy-past, copy-past, copy-past, copy-past... 40x den selben Schmarrn: |style="padding-left:0.8em; text-align:left; height:2em;| vier Spalten, vierzig Reihen = 160 mal den selben unnützen Krust. Wie im Irrenhaus! Und wenn ich dann sehe: height:1.8em wär doch angemessener, dann, alles auswählen, kopieren, ab in mein npp++, alles ersetzen, testen. Nein 1.6em wär noch schöner Nochmals die gleiche Prozedur. So was vorsidflutliches. Oder aber wie meist beobachtet: „Ist doch egal.“ Resultat: Unschön, wurschtig, geschlammpt...  das Net ist voll davon. Auch die Wikis.

Die Schlacht ist bereits geschlagen und zuungunsten der Wiki-Syntax ausgegangen. Wiki-Syntax ist nun mal nicht das Gelbe vom Ei. Der vorherige Ansatz für SELFHTML 9, die Inhalte in einem eigenen XML-Dialekt zu strukturieren, fand angeblich auch wegen zu kompliziert(er Handhabung) keinen Anklang. Argumente gegen die Wikisyntax haben sich nicht durchgesetzt. Ein Wiki wäre viel besser für die Mitarbeit geeignet - nur liegt leider die Mitarbeit unter den euphorischen Erwartungen der damals hitzig geführten Diskussion.

Wie auch immer, dein Formatierwunsch in Ehren, ich hab ja auch bei den einzelnen Seiten der HTML-Referenz Ansprüche an die Tabellen gestellt (inklusive ausklappbarer Teile). Aber ich habe sie (media)wikikonform und mit vielen Vorlagen gelöst - auch und vor allem weil da themabedingt viele Wiederholungen vorkommen und man sie mit Änderung einer Vorlage alle beeinflussen kann. (Ich seh da auch keine Performance-Probleme). Das selbe Prinzip der Wiederholungsvermeidung versuchst du nun mit dem seitenindividuellen CSS hinzubekommen. Eine Vorlage hätte den selben Effekt, nur dass man sie auch noch auf anderen Seiten verwendet werden kann. Du sagtest ja, dass du dich nicht gern anpassen willst, aber die Entscheidung für dieses System ist nun mal da und deswegen sollten zunächst die Möglichkeiten des Systems ausgeschöpft werden, bevor etwas neues installiert wird, das auch wieder etwas mehr Wartungsaufwand bedeutet. Wenn du bei der Vorlagenerstellung Unterstützung brauchst, kann ich dir helfen. Zettle doch dazu eine Diskussion auf (einer) der betroffenen Seite(n) an (ggf. mit Hinweis auf meiner Diskussionsseite, wenn ich das nicht selbst entdecke - ich lese nicht immer alles). --dedlfix 10:13, 6. Apr. 2011 (CEST)

Danke auch hier für den Link. Vielleicht komm ich mal dazu näher rein zuschauen.

Die Einbindung einer Extension, welcher auch immer bedeutet ja nicht, dass man danach nicht mehr „(media)wikikonform“ sei. Wenn du zum Beispiel ein Modul in deinen Firefox einfügst, (wenn du diesen benutzt,) weil es dir praktisch und nützlich erscheint, so würdest du ja auch nicht sagen, dein Browser sei jetzt nicht meht „firefoxkonform“. Alle Erweiterungen haben ja den Sinn, je nach Bedarf, unter anderem z.B. auch den Komfort zu erhöhen. Zuvor, da gebe ich dir Recht, muss man immer auch das mögliche Missbrauchsrisiko erwägen. Stellen wir's mal zurück. Mit Vorlagen kann ich nie Nachfahrenelemente ansprechen. Zum Beispiel alle TDs in einer TABLE, geschweige denn spezifisch nur die TDs einer ganz bestimmten Spalte. Das ist der Unterschied.

Struktur

Ähnlich wichtig, ja noch wichtiger wäre mir eine recht radikale Strukturänderung, die jetzt noch möglich ist, im noch recht jungen SELFHTML-Wiki. Ich spreche nicht von Layout und Stil. Diesbezüglich habe ich rein gar nichts auszusetzen, sondern im Gegenteil viel Lob und Anerkennung auszusprechen, ob der geleisteten Arbeit. (Zwar hatte ich Eingewöhnungsschwierigkeiten mit den internen Linkfarben. Das war aber auch alles.) Nein, ich meine den Baum, genauer deine „tausend“ Namespaces, die meiner Meinung nach nichts bringen. Im Gegenteil führen diese nur zur Verwirrung und zu tragen zu einer gewissen, von mir festgestellten Unübersichtlichkeit viel bei. Verschiedene Namespaces sind doch nur dann vonnöten, wenn du diese auch, von den Userrights her, verschiedlich konfigurierst. Aber genau das wirst du ja nicht gemacht haben! Verschiedene Benutzerrechte zwischen dem Namensräumen: Referenzen, Themen und Glossar? Das würde ja rein gar nichts bringen. Wenn sie nicht verschieden konfiguriert werden, dann brauchen wir auch diese ganzen, vielen Namensräume nicht. Das fängt schon beim Wort „Doku“ an. Mich, und nicht nur mich anscheinend, hat das anfangs nur verwirrt. (Schon allein der Name... Klar, Doku ist kürzer als Dokumentation. Doch ist „Doku“ nicht schön. Mir fiel dazu nur noch DokuWiki ein.) Warum denn alles umständlich, wenn es auch einfach geht! Ich schlage dir vor: Die jeweiligen Grundverzeichnisse beinhalten jeweils und prinzipiell nichts anderes als ihr jeweiliges Inhaltsverzeichnis. Eventuell auch ein oder zwei einleitende Sätze oder Verweise. Aber auch das nur sehr sparsam. Je weniger desto besser. Dann ist doch die Navigation in unserem Wiki auf nahezu ideale Weise verwirklicht. Fehlt dann nur noch eines: Root; eben unser Wurzelverzeichnis mit seinem integralen SELFHTML-Wiki Gesamtinhaltsverzeichnis. Da die Verzeichnisnamen ja alle möglichst kurz sein sollen, schlage ich hier „SELFHTML“ vor. Es ist schon klar, dass da das Wiki gemeint ist. Einen kleinen, aber gut hervorgehobenen Link zu de.selfhtml.org kann es dann dort in der ersten Zeile auch geben. Wenn sich ein Benutzer dann „weit oben in den Zweigen“ befindet, kann er, von jeder Seite aus, mit einem Klick zu allen Parent-Verzeichnissen und auch direkt zum Root kommen. Was will man denn mehr? Vielleicht eines noch: Ein paar wenige „Kategorie“-Inhaltsverzeichnisse, wo zum Beispiel: SELFHTML/HTML/Referenz, SELFHTML/CSS/Referenz, SELFHTML/JavaScript/Referenz etc. gemeinsam gelistet werden. Was meinst du zu diesem meinem Vorschlag?

Es sind nicht „meine“ Namespaces. Die waren leider schon da, als das Wiki online ging, und ich kam erst danach hinzu. Ansonsten, ja, Ja, JA!!! die Namespaces sind nicht gut. Schon die Suche klappt nicht wie vorgesehen, weil die versucht - lexikongleich - relevante Seiten sofort anzuspringen, was sie aber nur im Hauptnamensraum macht.

Das Thema ist schon eine Weile im „ja, müsste man mal anfangen“-Zustand in meinem Hinterkopf … Da das sehr umfangreich ist, wird man wohl nicht um einen ausführlichen Test in einem Paralleluniversum herumkommen und außerdem sich der Hilfe eines Bots beim Umschreiben der Seiten (inklusive Weiterleitungen) bedienen. wiki-test2.selfhtml.org existiert für allgemeine Tests. Für den Umbau werden wir aber sicherlich mehrmals Kopien von wiki.selfhtml.org ziehen müssen und daran üben. Dafür kann das vorgesehene wiki-test1.selfhtml.org verwendet werden, muss aber noch vorbereitet werden.

Ach. Da fällt mir aber ein Stein vom Herzen. T'schuldigung für fälschlich „dein“. War nicht nach-recherchiert. Hättest du mit hier eine strikt ablehnende Antwort gegeben, so wäre es wohl mein Knackpunkt gewesen. (Sicherlich der einzig mögliche.) Danke für deine Testseiten-Links. Schau ich mir mal an. Den tatsächlichen Arbeitsaufwand kannst du natürlich viel besser beurteilen als ich. Einfach deshalb weil du das SELFHTML-Wiki und seinen tatsächlichen Umfang viel besser kennst. Für den JavaScript-Teil, da bin ich mir sicher, wäre es sehr einfach. Da gibt es so ein verkapptes Inhaltsverzeichnis in [Referenz:JavaScript] Eine einzige Seite mit weiter unten von dir ein ToDo in [Kurse:JavaScript]. Und der ganze Content von [Doku:JavaScript] strotzt auch nicht gerade in einer „unübersehbaren Fülle“. Außer meiner noch aussehenden „fmt & links“-Bearbeitungen auf den noch allermeisten Seiten, warte ich dann praktisch nur noch auf dein grünes Licht zu seiner Überführung in den Mainspace. Dannach würde ich aufmerksam nachschauen, was aus den schon vorhandenen Doku:-Seiten an konstruktiven, wichtigem noch heraus geangelt werden muss.

Du kannst das alles erstmal in den Doku-Namensraum bringen. Für die generelle Namensraum- und Strukturkorrektur muss man das mal alles insgesamt sehen, denke ich. Jetzt schon einen Teil anzufangen bringt nur Verwirrung wegen der Inkonsistenz zum Rest, denn ich befürchte, dass das auch wieder ewig so bestehen bleibt, bis sich jemand dessen annimmt.

Ne. Da kannst du 100 Jahre warten. Ich verbringe die Seiten nie von meinem Benutzernamensraum in den Doku-Namensraum. Wenn du schon prinzipiell einverstanden bist, dann warte ich halt noch so lange. Zwei Wochen, vier Wochen, zwei Monate, länger...  Bis du deinerseits zur Strukturänderung bereit bist. Ist zwar schade, weil ich schon bald fertig bin mit der Wikifizierung von 8.1.2 JavaScript. Aber Pech! Ich transferiere nur und ausschließlich in den Hauptnamensraum, nie in Doku. Solange ich lebe nicht! Es steht dir natürlich frei, es selbst zu tun. Aber dann, ist ja klar, hat mich das SELF-Wiki gesehen. Das ist keine Erpressung, sondern nur meine Auffassung von meiner Deontologie. Ich arbeite nur und ausschließlich in einem Wiki mit, das Ansprûche hat, diese auch umsetzt und nicht in zweitklassigen Provisorien vor sich hin wurschtelt.

Alles andere

Weil mein Post hier inzwischen schon recht lang geworden ist: Nun, nur stichwortartig weitere Punkte.

Klickbare Beispiele

Auch hierzu habe ich konkrete Vorschläge. Selbst Alert-Boxen müssen ja „echt“ klickbar sein. Die Entwicklung dieser Vorschläge will ich aber auf später verschieben.

NEU hierzu:  Wie sieht denn ein klickbares Beispiel hier konkret aus? Ich sah dazu nur verschiedene (ältere) Vorschläge auf mindestens zwei verschiedenen Seiten. Hat irgend ein Beispiel-Administrator schon ein funktionierendes klickbares geschaffen? Mit einer Prompt oder Alert-Box zum Beispiel, das ich mal sehen könnte.

Auf alle Fälle sind auf der Dokumentationsseite zur Vorlage:Beispiel Beispiele anklickbar gestaltet. Und wenn du Apsels Änderungen verfolgst/anschaust, solltest du auch jede Menge Seiten mit anklickbaren Beispielen finden. --dedlfix 19:15, 5. Apr. 2011 (CEST)

Gut werde ich suchen.

Die Code-Color

Ich bin zwar selbst noch nicht ganz sicher... Ich fand aber diese Blau-Hervorhebung auf 8.1.2 gar nicht so schlecht. Mir ist zwar das Risiko eines unschönen, zu bunten „Papageien-Stiles“ durchaus bewusst. Doch <code> in blau: Würde dies letzteres wirklich hervorrufen? Was meinst du?

Bei Vorschlägen bitte ein möglichst konkretes Beispiel ausarbeiten und das zur allgemeinen Diskussion stellen (am besten im Forum - da gibt es auch eine Kategorie SELFHTML-WIKI).

Kategorie SELFHTML-WIKI im Forum?!  Hatte ich bisher auch noch übersehen. Werd's mal suchen und wohl auch finden. Danke für den Hinweis.

Gut, komme gerade von da. Zuerst hielt ich es für einen Scherz, weil ich da nix anderes als einen Post von einer Laura fand, die da was über „Musik in HTML“ wissen wollte und sich mit ihrem allerersten Post wohl eher in die Wiki-„Kategorie“ verirrt hatte.

Nach tieferer suche fand ich immerhin gut 500 Einträge im Archiv 2010 und etwa 90 im Archiv 2010:  Zum Beispiel was zu Kurzanleitung anklickbare Beispiele  mit vier Autoren: Matthias, dedlfix, Beat und einem Daniel S. Werde es mal lesen.

Aber im Prinzip eher umgekehrt:  Wiki-Diskussionen vermehrt ins Wiki verlagern. „Alte Forums-Hasen“ sollten, wenn sie sich wirklich (und hoffentlich zunehmend) auch für's Wiki interessieren: Wäre gut wenn sie auch öfters hier vorbei kommen. Nur „eingefleischte Gewohnheiten“?  Nein, meiner Meinung nach nicht nur. Hängt auch viel davon ab, wie Schnell wir hier das Wiki „auf Zack“ bringen und echt interessant machen. Dann werden einige auch (wieder) hier her kommen.

Im Prinzip gehören Wiki-Diskussionen ins Wiki, aber da gibt es leider einige Dinge, die dem entgegenstehen. Zum einen die Ungeeignetheit für längere Wortwechsel, und zum anderen dass anscheinend die wenigsten aktiven Forumsmitglieder dazu zu bewegen sind, dauerhaft und von selbst ins Wiki zu schauen. Man muss es ihnen immer mal wieder in Erinnerung rufen, was aber nach meiner bisherigen Erfahrung leider nur sehr mäßig erfolgreich ist.

Verstehe ich:  Ein wirklich gutes Wiki hat aber mittefristig Chancen das zu ändern.

Als ich selbst mit HTML/JS etc. am Anfang stand:  Da war mir das SELF, mindestens viele Monate lang eine wichtige Hilfe. Das war so in den ersten Jahren des Jahrtausends. Die damalige Performance  – und vielleicht sogar auch eine gewisse Hegemonie, zumindest im deutschen Sprachbereich, –  die hat das SELFHTML inzwischen aber sicher verloren. Zu obsolete Informationen, keine High-End Infos. Vielleicht im Forum. Doch das hilft nur einigen hundert sich dort austauschenden Cracks und hie und da einigen, wenigen sich einen Mut fassenden Neophyten.

Ohne ein gutes, aktuelles, breit vermitteltes Basiswissen, wird auch das Forum schnell zur Insider-Nische. Drum volle Kraft ins Wiki. Die Resultate der Forums-Diskussionen dann möglichst auch hier her. Dazu vielleicht ab Herbst auch eine Internationalisierung des Wikis. In zwei, drei Sprachen kann ich auch selbst (im Rahmen meiner Kräfte) dazu beitragen.

Erzähl das den anderen im Forum. Die Diskussion(en) würde ich aber ungern kopieren wollen, zumal dazu im Prinzip jeder für seine Beiträge zustimmen müsste, sie unter Wiki-Lizenzbedingungen zu stellen. Verweise tun es auch, denke ich.

Vielleicht mache ich mich in den nächsten Wochen auch Schritt für Schritt mit dem Forum vertraut.

Gibt es nicht jemand, der PHP hier auf SELF initialisieren könnte. Ich nicht. Kann zwar PHP lesen und modifizieren, aber nicht selbst Code schreiben oder es unterrichten. Die offiziellen PHP-Referenz-Seiten sind zwar einigermaßen lesbar. Die Benutzer-Adds, gleich drunter, sind aber recht „Kraut und Rüben“. Wie nicht richtig gesichtetet. Ein PHP-Teil wäre imho auch interessant für uns.

Du meinst eine PHP-Dokumentation/-Tutorial/-whatever hier im Wiki? Nun, wenn es jemand will, dann kann er gern auch über PHP schreiben. Aber das ist nicht das Hauptanliegen von SELFHTML. Es müssten jedoch eher mehr Mitstreiter für die bisherigen Themen gefunden werden. --dedlfix 19:15, 5. Apr. 2011 (CEST)

War auch nur so was wie Brainstorming bzw. eine nur sehr lanfristig umzusetende Idee. Nicht Hauptanliegen, aber auch nicht unwichtiger wie z.B. JavaScript.

So long, Klaus 18:12, 5. Apr. 2011 (CEST)

Schrittweise aufs Wiki

Ich kenne ja de.selfhtml.org nicht in Gänze. Dass zum Beispiel das gut funktionierende Forum dauerhaft auch dort verbleibt: Das ist für mich klar und ist auch gut so. Aber die wirklich integral hierher importierten Teile und die dann hier auch laufend aktualisiert werden, sollten wir dort auch durch manuelle, also explizite und nicht etwa automatische Redirect-Links stilllegen. Einfach um unsere Leserschaft nicht zu „verzetteln“. Die dabei zu beachtenden Einzelheiten können wir ja zu gegebener Zeit noch besprechen...

Ja, auch das hat die besten Chanchen umgesetzt zu werden, wenn es konkret ausgearbeitet ist. Die Doku sind statische Seiten, also würde eine Auflistung genügen, in welche Seite welches HTML-Schnipsel einzufügen ist.

Okay.

de.selfhtml.org als InterWiki

Manche, vielleicht auch kleine de.selfhtml.org Seiten müssen wir ja aus Tempo-Gründen noch auf absehbare Zeit noch weiter, von "wiki"- auf die "de"-SubDomain verlinken, z.B. Kleine Helferlein. Ich weiß nicht, ob mir da eine Syntax entgeht, aber wenn es keine andere Möglichkeit gibt, wäre eine (Pseudo-)InterWiki Einbindung von de.selfhtml.org mehr als wünschenswert. Einfach um die Extern-Icon zum Verschwinden zu bringen. Es ist ja kein „Extern-Link“. Für dieses InterWiki, entweder direkt die SQL-File editieren oder eine entsprechende Extension. Es gibt da mehrere, welche du willst. Aber Links von hier zur anderen Unterdomäne de. Bitte ohne Extern-Icon. Bei der Wahl entsprechenden InterWiki-Codes müsstest du die mögliche, hoffentlich nicht allzu ferne Internationalisierung unseres Wikis beachten. Aber das weißt du ja eh selbst.

Mit Interwiki hatte ich noch nicht zu tun, außer dass jemand schon mal Wikipedia-Links so gekennzeichnet hat und das dann wie interne Links aussah, was aber nicht gewünscht ist. Nun werden auch Interwiki-Links als external gekennzeichnet, was deinem Vorschlag entgegenläuft. Aber das lässt sich irgendwie regeln.

Ja gut.

Zeitzonze

Ein kleines, eher nicht so dringliches Detail-Problem ist unser derzeitiger Zeitzonen-Bug. In der signierten Unterschrift ist alles okay. Da gilt derzeit CEST, jedoch nicht in den Änderungen. Da ich weder auf Island noch in Liberia lebe, bringt mich das ein wenig (moderat) durcheinander. Mittelfristig müsste das „entkäfert“ werden. Auch im Sinne und Interesse aller zukünftigen aktiven Benutzer. Um sie nicht all zu sehr „in den Westen zu verstoßen“. In den Preferences hast du ja die persönliche Zeitzoneneinstellung raus geschmissen. OK. Auch ein ggf. auf anderen Längen lebendender Deutschsprachiger hat sich mit CEST abzufinden. Aber bitte nicht mit UTC! Bei persönlichen Einstellungen der Zeitzone kann man ja für die Browser-Einstellung optieren. Das beste. Ist das inhibiert, dann bleiben nur die entsprechenden Linien in den LocalSettings. Diese aber setzen aber eine korrekte Server-Einstellung des Providers voraus: „Schau m'r mal.“

Ich hab da nichts verboten. Der Server läuft auf UTC, soweit richtig, aber $wgLocaltimezone steht auf "Europe/Berlin". Ich dachte, das reicht. Aber jetzt wo du es sagst, fällt es mir auf, dass ich nach Ablauf der „dauerhaften Anmeldung“ immer UTC vorgesetzt bekomme. → ToDo-Liste

Was Klaus meint, ist, dass meine Unterschrift hier ca. 13:35 Uhr erscheinen wird, in den letzten Änderungen aber ca. 11:35 stehen wird. -- Matthias 13:35, 5. Apr. 2011 (CEST) --

Nicht wenn ich angemeldet bin, dann wird die in den letzten Änderungen stehende Zeit in die in meinen Einstellungen eingestellte Zeitzone umgerechnet. Man müsste also die Zeitzone für die unangemeldeten User noch irgendwie konfigurieren. --dedlfix 15:29, 5. Apr. 2011 (CEST)

Und zwar "aus dem Browser übernehmen" -- Matthias 17:07, 5. Apr. 2011 (CEST) --

Richtig Matthias. Aber erstens, selbst wenn gut in LocalSettings konfiguriert: Nur effektiv für die (zukünfigen) Neuen.

Und zweitens, manchmal verhindert auch ein schlecht voreingestelltes PHP seitens des Providers diese gute Inkraftsetzung.

-- Klaus 18:20, 5. Apr. 2011 (CEST)

Du hast es genau erfasst. Alle Alten müssen das ggf. selbst einstellen. Für die Neuen kann das auch richtig voreingestellt werden. Ich kenne das Problem, ist aber leicht verhext. Man kriegt's aber hin. -- Klaus 16:15, 5. Apr. 2011 (CEST)

Ich hab da nichts verboten.  Merke jetzt erst: War nur der Skin. In MonoBook und Vector, den beiden Skins die ich am besten kenne, gibt's da jeweils Tabs. Ich sehe die nicht, denke reduziert auf nur eines. Übersehe aber das Menü links. Muss mal meine Brille besser putzen...  Nur für die Neuen, hast du's ja jetzt auf deiner ToDo.

Nun, dies ist in möglichster Kürze vorerst alles. Es mag einige Punkte geben, wo du problemlos einverstanden bist, andere wo wir die Diskussion vertiefen müssen, wieder andere wo du dir das noch etwas überlegen willst und vielleicht auch ein oder zwei Punkte wo du gerne noch einige andere Standpunkte bzw. Argumente von anderen hören willst, bevor du dich als Admin so oder so entscheidest. All das werden wir ja gemeinsam sehen. Ich warte geduldig auf deine Antwort.

Bitte

Eine letzte Bitte: Respektiere doch meinen längeren Post-Block hier. Will heißen: Schreibe bitte nicht dazwischen. Das bereitet mir bei kürzeren Interventionen, wie oben, keine Probleme. Wenn ja nur eine Reply zu erwarten steht, dann ist das recht praktische dazwischen schreiben auch für mich annehmbar. Wenn sich aber zu dem einen oder anderen Punkt die Diskussion dann ausweitet, so ist es mir, zumindest als Leser, dann stets unmöglich eine solche Diskussion überhaupt auch nur zu lesen, oder eben, erzwungenermaßen, ein Graus.

Zu spät, schon alles getippt. Außerdem finde ich es übersichtlicher, auf genau das zu antworten, was ich beantworten möchte, ohne das nochmal zu wiederholen oder anderweitig zu referenzieren. So bleibt Thema und Antwort zusammen. Und das hat auch nichts damit zu tun, dass ich deine Ausführungen nicht respektierte - im Gegenteil. Das Wiki ist nun aber kein Diskussionsforum und wenn man es dafür verwendet, muss man mit Einschränkungen leben.

s.o.

Also, bitte deine Antwort, eingerückt, einfach en-block darunter. Bezug nehmen kannst du jeweils mit Stichwort-Nummern und/oder Erinnerungsstichworten bzw. durch kurze Zitate. Das erscheint mir die klarste, nachlesbarste Vorgehensweise zu sein.

Find ich nicht gut, dann muss man immer hin- und her springen – beim Lesen und auch beim Antworten. --dedlfix 12:27, 5. Apr. 2011 (CEST)

s.o.

Bis bald, best regards, Klaus 00:16, 5. Apr. 2011 (CEST)

Nachbemerkung zu meiner Antwort:  Habe noch einige zusätzliche Punkte gefunden. Lasse die aber vorerst. Etwa drei Viertel der Punkte sind jetzt wohl entweder schon geklärt, oder zurückgestellt oder auf ToDo-Listen. Auf einige Punkte wirst du mir wohl noch mal antworten wollen.

-- Klaus 16:15, 5. Apr. 2011 (CEST)

---

"Sicherheitsprobleme, da nur CSS, gibt ist bei dieser Extension natürlich gar keine."

"Die Kaspersky-Experten haben im Februar eine relativ neue Methode beobachtet, mit der schädlicher Code in Web-Seiten vor Antivirus-Software versteckt wird. Die Mehrzahl der Drive-by Angriffe im Web nutzt die an sich für das Layout der Seiten vorgesehenen CSS-Daten, um darin Code für Download-Scripte zu verbergen. Damit wird dann wie gehabt Exploit-Code geladen, der Sicherheitslücken auf den Rechnern der Anwender ausnutzen soll."

Gelesen in der PC-Welt 04/11 und kopiert von ng-online --Matthias 09:44, 5. Apr. 2011 (CEST)--

Guten Tag Matthias und Danke für deine neue, recht interessante Information.

Habe die verlinkte Seite gelesen. Wenn ich richtig verstanden: „Schwachstelle [...] im Hilfecenter von Windows XP sowie eine relativ neue Java-Lücke“ ausgenutzt, um mit in normalen CSS-Dateien verstecken Scripten diese anzugreifen. Ja, dann betrifft uns das ja nicht. Scripte in Mediawiki-Edit Quelltexten können ja ganz und gar nicht ausgeführt werden. Ganz gleich ob sie innerhalb oder außerhalb von PageCSS-Tags stehen.

Trotzdem Danke für deine Info. Erfreut von unserer ersten Begegnung, Klaus 11:17, 5. Apr. 2011 (CEST)

---

Neuer Vorschlag

Nach meiner letzten Antwort von vorher, habe ich einen neuen Vorschlag.

Lass uns doch bitte, Dedlfix, unsere Diskussion hier mal unterbrechen.
Ich will dir da weder ein sickiges EOD rein knallen, noch dir sonst irgendwie das Wort abschneiden.

Im Gegenteil: Ich danke dir für unseren ersten Gedankenaustausch hier.
Wenn du noch was wichtiges zu anzumerken hast: Nur zu...

Mein Anliegen ist nur: Gleichzeitig arbeiten und viel diskutieren geht schlecht.
Machen wir doch mal 10-14 Tage beiderseitige Denkpause. Ich werde versuchen,
bis dahin den JavaScript-Import zu Ende zu bringen. Du gehst deinen Beschäftigungen nach.
Wir haben uns jetzt ein bisschen kennen gelernt. In knapp zwei Wochen nehmen wir manches ausstehende,
jetzt noch nicht geklärte, wieder auf, und werden dann sehen, wie wir weiter verfahren.

Das hätte den Vorteil, dass so die Arbeit weiterginge.  Klaus 22:46, 5. Apr. 2011 (CEST)