Dirks Logbuch

Warum musst Du nach der Umstellung alle Artikel einmal „anfassen“?

Örks, okaaay … wobei das Faszinierende ja ist: Es sieht ganz manierlich aus, so lange man nicht in den Quelltext schaut. Was sich mir jetzt nicht auf Anhieb erschließt, ist, warum NL2BR da Absätze mit Klassen versieht und denen auch noch CSS mit auf den Weg gibt, aber es wird wohl mal wieder die leidige Abwärtskompatibilität sein.

Das ist ein Problem der Kaskade. Ein anständigesâ„¢ Template setzt für Absätze Abstände, und zwar direkt für das p-Element. Dessen Spezifität ist höher als die eines p-Elementes mit einer Klasse, zudem werden IIRC die Plugin-Styles vor denen des Templates gesetzt (was richtig ist, sonst könnte man sie nicht templateseitig überschreiben). Deswegen werden die Styles für die Klasse .break überschrieben und die entsprechenden Absätze wie „normale“ Absätze gestaltet.

Die schnellste und einfachste Lösung wäre es wohl, sich die Plugin-Styles für .break und .whitespace nochmal in die user.css zu schreiben. Die sauberste Lösung ist natürlich, das Markup von Hand anzupassen, also z.B. auch die Listen als Listen auszuzeichnen. Macht aber halt sackviel Arbeit …

Zu Geshi: Nö, kann man machen. user.css:

.geshi {
background: #eee;
border: 1px solid #aaa;
padding: .71428em;
}

Ja, klar – NL2P macht anscheinend (im Gegensatz zu etwa Textile) insofern keinen Unterschied zwischen einem Zeilenumbruch und einer Leerzeile, als dass es beides zum Anlass nimmt, einen Absatz in Form eines p-Elementes zu erzeugen bzw. „löst“ das, indem es den erzeugten p-Elementen unterschiedliche Klassen mit eigenem CSS zuweist, die aber von Templates extrem leicht zu überschreiben sind.

Ich werde mich mal in den entsprechenden Kram im Forum einlesen und es entsprechend kommentieren, aber es kann sein, dass es keine gut andere Lösung dafür gibt. Kann ich so nicht sagen, da ich das Plugin maximal für Kommentare verwende.

Ich sagte doch, es war ein Fehler im CSS von 2k11 – ich habe die von NL2P zugewiesenen CSS-Klassen vertauscht.

NL2P erzeugt im Grunde zwei Arten von Absätzen – p.whiteline für „echte Absätze“, also mit einem Abstand nach unten, und p.break für Zeilenumbrüche ohne Abstand nach unten. Das ist zwar semantisch falsch, sieht aber halt so aus, wie man es erwartet.

kein grund zum streiten, aber ich will das erwähnt haben: das entspricht der von mir intendierten semantik, in meinen augen ist da nichts falsch. Mirzufolge sind beide arten von absätzen echte absätze und gehören daher in p-tags.

>kein grund zum streiten, aber ich will das erwähnt haben:
Deutlicher konnte ich eigentlich nicht machen, dass das keine Diskussionsvorlage ist. Es steht auch nicht zur Diskussion, denn es ist das, was ich mir damals dabei dachte. Objektive Fakten, nicht ausdiskutierbar.

Dein Kommentar dazu war also ziemlich unnötig.

Eigentlich ist dieser Kommentar dadurch nicht nötiger, aber damit das klar ist: Es ist ein ziemlich mieser Kniff, anzudeuten wie beschissen man eine Lösung findet und sich gleichzeitig der Diskussion zu verweigern, die nie angeboten wurde. Ein Trick, um sich unangreifbar zu machen und die andere Position schlecht wirken zu lassen. Das hast du nicht nötig, und das hat nl2p genausowenig verdient. Und ich weiß auch gar nicht, woher das plötzlich kommt.

Ok und akzeptiert.

>Erstens kommt das nicht „plötzlich“ – ich habe schon mehrfach klar kommuniziert (hier, im Forum, im Podcast), dass ich das NL2BR-Plugin für sinnfrei ...

Das stimmt. Ich bezog mich mit dem plötzlich nur auf das wie. Verknappen ist böse

Es gibt aus meiner Sicht (auch das ist eine subjektive, persönliche Meinung) deutlich „bessere“ Alternativen für Einsteiger, auch wenn diese weder HTML von Hand schreiben noch einen WYSIWYG-Editor verwenden möchten, etwa Textile.

Ja, es ist mehr Aufwand, von Plain Text auf Textile umzustellen als von Plain Text auf NL2(BR|P), speziell wenn es um ein Blog wie dieses geht, dass aus Jahren „unformatierter“ Inhalte besteht – vermutlich zuviel Aufwand.

Ich finde es falsch, in s9y NL2(BR|P) als standardmäßige Alternative zum WYSIWYG-Editor einzusetzen, ich würde es durch Textile oder Markdown ersetzen, aber da sind scheinbar alle restlichen Kernentwickler anderer Meinung.

Ich weiß nicht, ob das klar ist: NL2(BR|P) macht genau eine Formatierung mit Plain Text – Umwandeln von Zeilenumbrüchen in zwei Sorten Absätze. Genau das leistet Textile auch, und zwar automagisch, ohne zusätzliche Formatierungszeichen, aber – aus meiner Sicht – mit einem „besseren“ Ergebnis. (Gleiches gilt übrigens für Markdown.)

Was daran für einen Einsteiger schwerer sein soll, verstehe ich nicht.

Ja, Textile ermöglich komplexere Auszeichnungen in einer Form, die eventuell komplizierter und ganz sicher fehleranfälliger, aber eben auch deutlich leistungsfähiger ist – aber das sind nicht die Dinge, die NL2(BR|P) leistet, das erledigt in einem normalen s9y-Setup das Plugin Markup: Serendipity.

Gleiches gilt auch hier für Markdown, das allerdings ein paar Dinge anders macht als Textile. Die Entscheidung zwischen Textile und Markdown ist sehr subjektiv, Markdown hat sicherlich den Vorteil, dass es (z.T. leicht abgewandelt) im Moment sehr populär ist, etwa auf GitHub oder in Jekyll/Octopress. Aber im Grunde ist es Jacke wie Hose, ob man Textile oder Markdown nimmt, weshalb nicht wenige Seiten beides anbieten.

Nichts zu entschuldigen.

Es ist ja nicht so, dass man bei Textile oder Markdown andere Formatierungen verwenden muss – man kann ganz normal Plain Text ins Eingabefeld tippen, den eventuell mit den typischen Serendipity-Markup-Zeichen (* und _) versehen und bekommt dennoch eine anständigâ„¢ formatierte Ausgabe.

Der einzige Unterschied ist der, dass Textile und Markdown den Underscore anders interpretieren als s9y-Markup – nicht als Unterstreichung, sondern als Betonung (em; doppelt verwendet als strong). Das ist meines Erachtens zu verschmerzen, zumal das u-Element ohnehin als veraltet eingestuft wird und Unterstreichung über CSS gelöst werden sollte.

Die Buttons im Plain-Text-Editor spucken (meine ich, ich hab's eben auch lokal getestet) immer HTML-Markup aus, das man in allen drei Varianten natürlich immer reinmischen kann – es würde mich auch wundern, wenn es anders wäre, denn so ist es ja die „günstigste“ Art, den PT-Editor flexibel zu halten.

Aber HTML-Markup innerhalb der Ausgabe welches Markup-Plugins auch immer ist doch immer passend.

Nun ist das bei den genannten nicht der Fall, aber nehmen wir mal an, es gäbe Auszeichnungskommandos, die von einem Markup-Plugin nicht interpretiert, aber von den Editor-Buttons erzeugt würden. Dann hättest Du, wenn Du mal wechselst, Markup in den Einträgen, das nicht interpretiert wird. Das wäre doch unschön.

Du erzeugst ja nicht nur über die Buttons Markup. Absätze etwa erzeugst Du in allen drei Varianten einfach nur durch Zeilenumbruch im Editor.

Die Buttons im PT-Editor leisten ja im Prinzip Folgendes: Sie ermöglichen es dem Laien, komplexes Markup einzugeben, ohne es von Hand tippen zu müssen, z.B. einen Link. Aber bei den meisten dieser Buttons unterscheidet sich die Auszeichnung der überlagernden Markup-Sprache deutlich.

Das kann ich jetzt hier schlecht demonstrieren, aber nimm mal als Beispiel ruhig den Link – das Markup von Textile und Markdown ist ein ganz anderes. NL2(BR|P) hingegen hat gar keine Kurzauszeichnung dafür, weil es „nur“ Absätze erzeugt. Unter diesen Umständen ist es der kleinste gemeinsame Nenner, wenn der Editor-Button HTML erzeugt, denn HTML ist ja das, wohin alle Markup-Plugins umwandeln.

Würden die Editor-Buttons etwas anderes erzeugen, wäre die erzeugte Auszeichnung so in der Datenbank gespeichert, also etwa „*fett*“, was ein schlechtes Beispiel ist, weil das von allen Markup-Plugins interpretiert würde – aber im Zweifelsfall steht dann eben etwas in der Datenbank, was von anderen Plugins nicht interpretiert wird. Ganz zu schweigen von Umgebungen, in denen gar kein Markup-Plugin läuft (ja, das gibt es leider auch).

Wäre es so, dass die Buttons spezifische Auszeichnung generieren, wäre die Markupwahl tatsächlich endgültig – so ist sie es (mit Einschränkungen zumindest) nicht.

Dirk, ich kann Dir leider nicht folgen.

Sobald man komplexere Auszeichnungen eines Markup-Plugins einsetzt, wird es schwierig, das stimmt. Verwende ich etwa die Auszeichnung von Textile für Links oder Blockzitate, wird Markdown damit nichts anfangen können. Auch ohne eine Markup-Plugin steht dann sehr merkwürdiger Text in der Datenbank. Aber genau deshalb ist es (aus meiner Sicht) sinnvoll, dass die Buttons HTML erzeugen – denn HTML funktioniert in jedem Fall, weil jedes Markup-Plugin letztlich HTML erzeugt.

Problematisch wäre eher, Plugin-spezifische Auszeichnungen in der Datenbank zu haben, die nicht von jedem Markup-Plugin interpretiert werden. Genau das ist bei den Auszeichnungen, die die Kombination aus Markup: Serendipity und NL2(BR|P) interpretiert (Absätze, * und ) aber der Fall, auch wenn die Interpretation von Textile und Markdown etwa anders ausfällt als bei Markup: Serendipity. Selbst ganz ohne Markup-Plugin wäre das noch halbwegs erträglich – es gäbe keine Absätze, aber die Markierungen fett und _unterstrichen sind ja auch in E-Mails gebräuchlich.

Schwierig wird es erst, wenn in der Datenbank Formatierungen stehen, die sehr spezifisch und damit nicht „übertragbar“ sind, und fast alle Buttons des PT-Editor erzeugen solche Formatierungen.

Ah, jetzt, ja.

Jetzt kommen wir in den Bereich, in dem ich nur noch mutmaßen kann, nämlich darüber, warum es so ist, wie es ist. Ich nehme an, dass der Schritt, dass erzeugte HTML in die Datenbank zu schreiben und ggf. zurück in das „Schicht-Markup“ umzuwandeln, arg auf die Performance drücken würde. Der Benutzer soll ja idealerweise nicht „merken“, dass da etwas konvertiert wird.

Grundsätzlich stimmt ich Dir zu, wenn es keinen guten Grund dagegen gibt (was ich nicht weiß), sollte in der Datenbank HTML landen.

Der Slash ist übrigens zumindest in HTML5 kein Problem, da HTML5 die XML-Syntax auch erlaubt, auch gemischt mit klassischer HTML-Syntax. Das wäre nur problematisch, wenn Du von XHTML auf HTML4.01 schalten würdest.

Naja – generell ist das schon suboptimal, aber vermutlich nicht schmerzfrei anders zu lösen. Im Prinzip erzeugt NL2P jetzt sogar Absätze, wo eigentlich keine hingehören – das, was jetzt p.break ist, müsste streng genommen eigentlich ein br-Element (Umbruch innerhalb eines Absatzes) sein.

Aber letztlich funktioniert es so ja, mehr als eine Krücke ist das ohnehin nicht. Ich kann mir gut vorstellen, dass es ekelhafter Code ist, insofern steck Deine Zeit lieber in was Sinnvolles.

Naja, das hört sich so knapp und technisch formuliert jetzt auch brutaler an, als es ist.

NL2BR bzw. NL2P jetzt noch so aufzubohren, dass es das leistet, was Textile oder Markdown leisten, hielte ich für falsch bzw. unsinnig eingesetzte Arbeitszeit, weil es bedeuten würde, ein kleines Plugin, das letztlich nur ein einfacher Textfilter ist, so zu erweitern, dass es „echten“ Markup-Plugins ebenbürtig würde – was noch dazu dem Prinzip widerspräche, möglichst wenig doppelte Funktionalität durch Plugins abzubilden.

Da würden mir andere Dinge einfallen, falls Malte Langeweile hätte.