Skip to content
This repository has been archived by the owner on Jun 24, 2019. It is now read-only.

Feature Request: Textformatierung (einfach) #49

Closed
Netsurfer24 opened this issue Jan 14, 2013 · 36 comments
Closed

Feature Request: Textformatierung (einfach) #49

Netsurfer24 opened this issue Jan 14, 2013 · 36 comments

Comments

@Netsurfer24
Copy link

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.

@RaoulSchaffranek
Copy link
Contributor

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.

@ckruse
Copy link
Owner

ckruse commented Jan 14, 2013

Markdown hat den Nachteil, dass es recht komplex zu parsen ist. Hm, mal sehen…

@ckruse
Copy link
Owner

ckruse commented Jan 14, 2013

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…

@RaoulSchaffranek
Copy link
Contributor

Aber ich bin auch der Meinung, irgendetwas muss her.
Was eigenes wäre Quatsch, niemand hat Lust noch eine Auszeichnungssprache zu lernen.
Was haltet ihr von GitHubs Flavored Markdown? Dann ist zumindest der Umstand mit der Einrückung behoben.
Vielleicht findet sich ja sogar ein fertiger Parser, den man verwenden kann.

@ckruse
Copy link
Owner

ckruse commented Jan 14, 2013

Hu? aus der Hilfe-Seite: „To create a code block, indent the entire block by at least 4 spaces or one tab.“

@jeena
Copy link
Contributor

jeena commented Jan 14, 2013

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:

Screen Shot 2013-01-14 at 20 15 30

Was dann so aussieht:

function fancyAlert(arg) {
  if(arg) {
    $.facebox({div:'#foo'})
  }
}

@MatthiasApsel
Copy link
Contributor

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.

@ckruse
Copy link
Owner

ckruse commented Jan 14, 2013

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.

@dedlfix
Copy link

dedlfix commented Jan 14, 2013

@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.
(Und sooo toll ist MediaWiki-Syntax mit seinem Mischmasch aus Zeichen und Tags auch nicht.)

@MatthiasApsel
Copy link
Contributor

Ich hatte eine Rückübersetzung nicht vorgesehen. g

@schuer
Copy link

schuer commented Jan 14, 2013

Textile.

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

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.

@jeena
Copy link
Contributor

jeena commented Jan 18, 2013

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 ;)

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

Die Quoting-Chars musst du ja nicht lernen – die sind wie bei E-Mails auch…

Liste:

  • Wählbare Zitat-Zeichen
  • Link-Templates (ändert das HTML, dass bei Links generiert wird, so dass z. B. „Text (url)“ da steht statt nur „Text“)
  • Link-Icons
  • Syntax-Highlighting
  • Links in neuen Fenstern öffnen
  • Tabulatoren durch Leerzeichen ersetzen
  • Eingebundene Bilder als Verweise anzeigen
  • Signaturen
  • Signaturen ausblenden

Ich glaube, das sind aktuell alle…

@jeena
Copy link
Contributor

jeena commented Jan 18, 2013

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.

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

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.

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

Was ich damit sagen will: wir sollten uns auf EIN Format einigen. Das reicht, das ist Arbeit genug…

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

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?

@dedlfix
Copy link

dedlfix commented Jan 18, 2013

Muss es denn ein Zitatzeichen sein? Ich sähe lieber, wenn Zitate als Block dastehen und dann per CSS formatiert werden könnten.
Ansonsten reicht ein Format für den Anfang sicher erst einmal aus. Verbau dir aber nicht den Weg für weitere. Welches dieses eine Format ist, ist nicht ganz so wichtig, solange Buttons für die Funktionen bereitstehen.

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

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 :)

@dedlfix
Copy link

dedlfix commented Jan 18, 2013

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.

@ckruse
Copy link
Owner

ckruse commented Jan 18, 2013

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.

@dedlfix
Copy link

dedlfix commented Jan 18, 2013

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.

@RaoulSchaffranek
Copy link
Contributor

Ich bin nicht unbedingt gegen BBCode, aber meine Präferenz liegt eben bei Markdown/Whatever.
Es ist schneller geschrieben und ungeparst noch gut lesbar. Das sind meine Argumente. Dagegen spricht momentan, dass Markdown einen erheblich größeren Aufwand bedeuten würde.

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.

@jeena
Copy link
Contributor

jeena commented Jan 18, 2013

Ich habe zu dem ganzen mal eine Umfrage erstellt und hoffe auf rege beteiligung:

https://docs.google.com/spreadsheet/viewform?formkey=dE9WLVIzTVY3OFA2bkpmdlgxR3hzc0E6MQ

@johanneszeller
Copy link

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:

  1. BBCode ist bei anderen Board- und Forensoftwaren weit verbreitet, was es wahrscheinlich macht, dass neue Benutzer bereits mit der grundsätzlichen Funktionalität vertraut sind.
  2. Markdown liest sich zwar ungeparst schöner, dafür ist BBCode meiner Meinung nach selbsterklärender. Es ist in jedem Fall klar erkennbar, was Teil der Auszeichnungssyntax ist. Bei Markdown sehe ich die Gefahr, dass Benutzer, die mit Markdown nicht vertraut sind, unintendierte Effekte erzeugen, weil sie ohne es zu wissen Formatierungen benutzt haben, die von Markdown mit einer bestimmten Funktion belegt sind.

@RaoulSchaffranek
Copy link
Contributor

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.

@ckruse
Copy link
Owner

ckruse commented Jan 28, 2013

So, ich betrachte die Umfrage als abgeschlossen. Damit wird es wohl Markdown (mit spezifischen Erweiterungen im zweiten Schritt)

@MatthiasApsel
Copy link
Contributor

Hallo Christian,

ich habe nichts dagegen. Wie ich es beurteile, ist es wohl eher der
persönliche Geschmack der Leute gewesen. Ich habe jedenfalls kein
Argument gelesen, warum es die oder jene Sprache sein soll. Ausnahme:
Wikisyntax ist ein Gemisch aus Tags und Markierungen.

Spricht eigentlich etwas gegen HTML-Syntax? Das hat noch keiner ins
Spiel gebracht.

LG
Matthias

@jeena
Copy link
Contributor

jeena commented Jan 28, 2013

Markdown beinhaltet auch HTML, man kann also pures HTML statt Markdown schreiben und der parser bereinigt es dann auch.

@ckruse
Copy link
Owner

ckruse commented Jan 28, 2013

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.

@MatthiasApsel
Copy link
Contributor

Gegen HTML spricht die Tatsache, dass das ein Forum über Webtechniken
ist und da durchaus auch einiges an HTML gepostet wird ;-)

Mit einem Knopf "Code" könnte man das auch umgehen. Aber wie gesagt,
ich habe nichts gegen Markdown.

Matthias

@ckruse
Copy link
Owner

ckruse commented Jan 28, 2013

Mit einem Knopf "Code" könnte man das auch umgehen.

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 <script> wegen XSS) und man muss darauf achten, dass alle User alle Tags auch korrekt wieder schliessen.

Ne, HTML als Eingabe-Medium für die Postings halte ich für absolut ungeeignet.

@MatthiasApsel
Copy link
Contributor

Am 2013-01-28 10:47, schrieb Christian Kruse:

Mit einem Knopf "Code" könnte man das auch umgehen.

Naja, dazu müsste man annehmen, dass die Benutzer das immer korrekt
benutzen;

Dass das aufwändig sein kann, will ich nicht bestreiten.

Meine Vorstellung dazu:

Um BeispielCode einzugeben, muss man den Button drücken, dann öffnet
sich an der entsprechenden Stelle, quasi ein Textfeld im Textfeld.

Technisch muss man natürlich natürlich das erste Textfeld schließen.

Matthias

@dedlfix
Copy link

dedlfix commented Jan 28, 2013

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.

@ckruse
Copy link
Owner

ckruse commented Feb 15, 2013

So. Markdown ist implementiert.

@ckruse ckruse closed this as completed Feb 15, 2013
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants