Feature Request: Textformatierung (einfach) #49
Comments
|
BBCode ist meiner Meinung überholt durch Markdown. Ein Vorteil von Markdown ist auch, dass es noch gut lesbar ist, falls es mal nicht geparst wird. |
|
Markdown hat den Nachteil, dass es recht komplex zu parsen ist. Hm, mal sehen… |
|
Ausserdem hat Markdown den Nachteil, dass man Sourcecode mit 4 Leerzeichen einrücken muss. Dafür ist BBCode verbose und schlecht lesbar. Irgendwie alles doof… |
|
Aber ich bin auch der Meinung, irgendetwas muss her. |
|
Hu? aus der Hilfe-Seite: „To create a code block, indent the entire block by at least 4 spaces or one tab.“ |
|
Markdown parser gibt es ja wirklich wie Sand am meer. Aber ehrlich gesagt wäre ich für ne lösung wie bei Github dass man sich auswählen kann was man denn jetzt nehmen will, die haben für ihr wiki auch AsciiDoc, Creole, Markdown, MediaWiki, Org-mode, Pod, RDoc, Textile und reStucturedText. Zumindest für den Betreiber sollte das auswählbar sein, am besten aber auch für den User. @ckruse die haben aber auch dass man drei back ticks schreibt und dann die Sprache also in etwa: Was dann so aussieht: function fancyAlert(arg) {
if(arg) {
$.facebox({div:'#foo'})
}
} |
|
Es sollten bei der Formulierung des Postings mehrere Syntaxen möglich sein, die vor dem endgültigen Speichern in eine Variante (mein Favorit: wikisyntax) konvertiert wird. Dann hat man den Vorteil, dass jeder das Schreiben kann, was er möchte, im Zitat aber nur eine Variante steht. Zusätzlich hat man die Flexibilität, neue Syntaxen einfach zu ergänzen, falls man als Programmierer lange Weile hat. |
|
Also, mehrere Syntaxes finde ich nun wirklich übertrieben. Eine reicht völlig. @jeena Klar gibt es Parser für Markdown, aber kein mir bekannter erlaubt ein eingreifen in die HTML-Generierung. Beispiel: Syntax-Highlighting. Wie willst du das mit BlueCloth umsetzen, ohne hinter das HTML zu parsen? Oder auch Links, wie willst du da ein rel="nofollow" dransetzen? Oder, oder, oder… nein ein fertiger Parser geht nicht, weil es meines Wissens nach keinen erweiterbaren/anpassebaren Parser gibt. |
|
@MatthiasApsel so einfach ist das mit dem Übersetzen nicht, denn die Sprachen haben zwar alle gemeinsame Elemente, aber dann auch wieder Unterschiede, selbst beim Attributumfang vergleichbarer Elementen. Das Übersetzen müsste ja dann beim Zitieren wieder rückwärts (zumindest in die bevorzugte Syntax des Antwortenden) erfolgen. Ich denke, es ist gescheiter, die original gewählte Syntax zu lassen und den Zitatblock mit einem Syntax-Attribut zu versehen. Das ist "nur" eine Herausforderung für den Posting-Parser, weil er immer umschalten muss und an die anderen Parser weiterdelegieren muss. Für den Antwortenden ist die andere Syntax vermutlich weniger ein Problem, man muss da ja nur größere Teile entfernen und nicht alles umformatieren. |
|
Ich hatte eine Rückübersetzung nicht vorgesehen. g |
|
Textile. |
|
Also, mein Problem mit den ganzen Formaten ist folgendes: ich müsste für jedes einen eigenen Parser schreiben. Kein mir bekannter Parser hat eine Plugin-Schnittstelle, in die ich mich einhängen könnte, zumindest nicht dokumentiert. Das würde entweder dazu führen, dass ich entweder alle Customizations über Board werfe oder dass ich den Parser selbst schreibe. Ich meine z. B. den Quoting-Char. Um zu gewährleisten, dass sich jeder einen eigenen aussuchen kann, wandle ich aktuell den Character beim entgegen nehmen des Postings um in U+ECF0. Bei der Ausgabe wandle ich ihn dann wieder um in den vom User gewählten Quoting-Char. Oder die Sache mit den Link-Templates. Oder den Icons nach links. Oder, oder, oder – im wesentlichen läuft es darauf hinaus, dass man nur noch plain textile/markdown/whatever eingeben kann. |
|
Gibt es irgendwo eine Liste von diesen customizations die da dazwischenfunken? Ich persönlich könnte auf all diese gerne verzichten was den Vorteil hätte dass ich mein können über plain-markdown/whatever gleich nutzen könnte ohne jetzt noch großartig ein neues system lernen zu müssen wie die quoting-chars. Die Icons nach Links könnte man auch relativ einfach mit JavaScript erst im client einbauen. Kommt jetzt noch drauf an was bei "Oder, oder, oder" drin ist und ob die Leute das wirklich nutzen möchten oder ob es sowieso fast allen egal ist und sie es lieber sehen würden dass stattdessen mehrere formate zur Eingabe zur Verfügung stehen so dass sie ohne was neues lernen zu müssen gleich losschreiben können. Wir bräuchten ne Liste oder zumindest ne Ahnung von den Möglichkeiten mit Customizations und einen Poll um daten darüber zu Sammeln wie denn der markt aussieht ;) |
|
Die Quoting-Chars musst du ja nicht lernen – die sind wie bei E-Mails auch… Liste:
Ich glaube, das sind aktuell alle… |
|
Naja ok, vor allem steht es schon zitiert in der Textarea so dass man das gleich sieht, bei Markdown ist es übrigens auch das gleiche Zeichen wie in E-Mails. Syntax-Highlighting wäre schon extrem wichtig, man sieht das viele auch mit JavaScript machen aber meist ist das relativ lahmarschig und fängt an zu flackern. Ich bin mir nicht ganz sicher welche Parser du dir schon angeschaut hast ich habe mal https://github.com/vmg/redcarpet angeschaut und da scheint schon einiges zu gehen, wenn auch evtl. nicht alles, man kann aber seine eigenen Renderer für schreiben, bin nur noch nicht ganz Sicher ob sachen wie Signaturen die ja ne eigene Syntax bräuchten funktionieren würden. |
|
Klar kann man Parser anpassen, aber – das muss man halt auch tun :-) Das ist es ja, warum ich ein Problem mit den ganzen Fancy neuen Formaten hab. |
|
Was ich damit sagen will: wir sollten uns auf EIN Format einigen. Das reicht, das ist Arbeit genug… |
|
Ich würde das gerne Abschliessen :-) Es wäre also toll, wenn sich ein paar Leute noch äussern würden. @MatthiasApsel Was ist z. B. deine Meinung, oder @dedlfix? Oder Niclas? |
|
Muss es denn ein Zitatzeichen sein? Ich sähe lieber, wenn Zitate als Block dastehen und dann per CSS formatiert werden könnten. |
|
Du meinst sowas wie [quote]…[/quote]? Das wurde rundweg abgelehnt als unpraktisch und nervig. Ansonsten sind Zitate aktuell doch bereits Blöcke, die du mit CSS formatieren kannst :) |
|
Sind die, die das abgelehnt haben, noch da? Ansonsten BBCode (oder irgendein anderes) ohne Ausnahme (höchstens Ergänzungen) wegen der Konsistenz. Keine zwei Syntaxen. Die Macht des Faktischen lässt auch die Meckerer irgendwann verstummen. |
|
Durchaus sind die noch da ;-) Das war sogar ziemlich einstimmig, dass die Leute das nicht wollten. Und wenn man mal über nachdenkt, ist das halt auch deutlich unpraktischer als vor die Zeile schnell ein > zu setzen. |
|
Na gut, ok, bei mehreren Zitatblöcken wird das mehr Arbeit als ein einzelnes >. Aber diese Situation gibt es doch bei Code auch, und da geben sich einige besonders viel Mühe, jedes Wort im Fließtext hervorzuheben. Geht ja auch einfach durch Knopfdruck. Wenn es das auch für Zitate gibt, dann ist das noch weniger Grund zu meckern. |
|
Ich bin nicht unbedingt gegen BBCode, aber meine Präferenz liegt eben bei Markdown/Whatever. Die Vorteile von Markdown, könnte man (bei Verwendung von BBCode) mit Keyboard-Shortcuts und Syntax-Highlighting und/oder einer Live-Vorschau auch wieder aufwiegen. |
|
Ich habe zu dem ganzen mal eine Umfrage erstellt und hoffe auf rege beteiligung: https://docs.google.com/spreadsheet/viewform?formkey=dE9WLVIzTVY3OFA2bkpmdlgxR3hzc0E6MQ |
|
Falls die Diskussion noch nicht abgeschlossen ist, würde ich gerne eine Lanze für die Beibehaltung von BBCode brechen. Und zwar aus zwei Gründen:
|
|
Dem ersten Punkt muss ich leider widersprechen. Es gibt in der Tat viele Foren, die irgend eine Form von BBCode anbieten, aber die Syntaxen sind oft sehr verschieden. Fetter oder kursiver Text ist kaum ein Problem, aber für Links und Bilder gibt es gefühlte 1000 verschiedene Schreibweisen. |
|
So, ich betrachte die Umfrage als abgeschlossen. Damit wird es wohl Markdown (mit spezifischen Erweiterungen im zweiten Schritt) |
|
Hallo Christian, ich habe nichts dagegen. Wie ich es beurteile, ist es wohl eher der Spricht eigentlich etwas gegen HTML-Syntax? Das hat noch keiner ins LG |
|
Markdown beinhaltet auch HTML, man kann also pures HTML statt Markdown schreiben und der parser bereinigt es dann auch. |
|
Das HTML würde ich streichen aus dem Markdown. Gegen HTML spricht die Tatsache, dass das ein Forum über Webtechniken ist und da durchaus auch einiges an HTML gepostet wird ;-) Das wäre dann doch etwas… lästig für die Stammuser und total kaputt für die neuen User. |
Mit einem Knopf "Code" könnte man das auch umgehen. Aber wie gesagt, Matthias |
Naja, dazu müsste man annehmen, dass die Benutzer das immer korrekt benutzen; dann müsste man implementieren, dass man nur bestimmte HTML-Tags zulässt (an will z. B. kein Ne, HTML als Eingabe-Medium für die Postings halte ich für absolut ungeeignet. |
|
Am 2013-01-28 10:47, schrieb Christian Kruse:
Dass das aufwändig sein kann, will ich nicht bestreiten. Meine Vorstellung dazu: Um BeispielCode einzugeben, muss man den Button drücken, dann öffnet Technisch muss man natürlich natürlich das erste Textfeld schließen. Matthias |
|
Zu aufwendig. Als Nutzer müsste man dann (mindestens) jedes < und & korrekt auszeichnen. Code kommt nicht nur in Blöcken sondern auch als Einzelwörter im Fließtext vor, die dann immer ge"block"t werden müssten. |
|
So. Markdown ist implementiert. |

Es wäre schön zumindest die Möglichkeit zu haben, Text fett und kursiv setzen zu können in Postings.
Vorschlag zur Umsetzung: BB Code (plus entsprechende Buttons beim Eingabefeld)
Siehe http://forumtest.selfhtml.org/cforum/2013/jan/14/secured-name/142 ff.
The text was updated successfully, but these errors were encountered: