Ich bin mir immer noch nicht sicher, ob ich Monospace für notwendig halte oder nicht, aber die aktualisierte Schriftart ist eine deutliche Verbesserung gegenüber der vorherigen (im Gegensatz zur vorherigen Situation, würde ich sagen, jetzt könnte sie wieder etwas größer sein).\n\nAber auf jeden Fall ist es schön, dass die gute alte ASCII-Art jetzt wieder Einzug halten kann
\n\n\n\n|-----------|\n| LONG LIVE |\n| THE BUNNY |\n|-----------|\n(\\__/) ||\n(•ㅅ•) ||\n/ づ\n
Ich habe dies bereits früher im Thema erwähnt. Wir müssen der Änderung etwas Zeit zum Atmen geben. Geben wir ihr mindestens noch eine Woche.
Die Antwort hier ist absolut vielleicht. Geben Sie uns weiterhin Feedback, ob gut oder schlecht, wir lesen alles.
Ein Problem, mit dem ich intern kämpfe, ist die Ausrichtung auf verschiedene „Personas“/„Zielgruppen“
- Öffentliche allgemeine Nutzer → verwenden Sie zu 99 % einfach den „Rich Composer“, keines dieser Probleme ist ein Problem
- Hochtechnische Nutzer → verwenden Sie einfach „Raw Markdown“ – generell an diese Art von Ansicht gewöhnt und viele sind mit der Änderung zufrieden
- Nicht-technische Nutzer, die den Rich Editor nicht verwenden möchten → Monospace stört sie – z. B. @Jagster – bevorzugen eine andere Schriftart
Es ist ein kniffliges Problem. Wir sind immer zurückhaltend, weitere Benutzereinstellungen hinzuzufügen, aber ich erkenne an, dass hier etwas dran ist. Ich möchte nur sehen, wie wir uns in einer Woche fühlen.
Ich habe versucht, verschiedene unaufdringliche visuelle Hinweise zu finden, aber es ist schwierig. ![]()
Die einzige, die akzeptabel zu sein scheint, ist eine Beschriftung irgendwo, wie zum Beispiel:

Und vielleicht mit einer Farbänderung, um das visuelle Gedächtnis zu verbessern:

Es ist ziemlich sichtbar, ohne aufdringlich zu sein. Es hat sicherlich seine Nachteile. Es nimmt etwas Platz ein, aber im Kontext eines vorübergehenden Übergangs ist es in Ordnung. Ich bin nicht zu 100 % überzeugt, aber es scheint eine interessante Alternative zu sein. Ich wollte die Idee nur teilen. (Sie können die GIFs gerne in einem neuen Tab öffnen, um sie in voller Größe zu sehen; ein Vollbild-Button fehlt)
Das ist aus irgendeinem Grund eines der besten Argumente dagegen, die ich bisher gehört habe. Ich musste gerade die Schriftart in meinem VS-Code-Editor überprüfen, also sehen Sie, ich bin ein Coder. Ich hatte einen Code-Editor auf meinem Desktop geöffnet, und siehe da, es ist eine Monospace-Schriftart. Das ist mir nie aufgefallen. Aber aus irgendeinem Grund fühlt es sich hier und in meiner eigenen Instanz seltsam an. Ich werde es eine Woche lang versuchen, wie Sam es verlangt, Veränderung ist schockierend, vielleicht merke ich es in einer Woche gar nicht mehr.
Ich stimme zu. Ich habe gerade einen wirklich langen Beitrag geschrieben, und ehrlich gesagt bekomme ich von der Monospace-Schrift Kopfschmerzen. Ich Korrektur lese meine Beiträge sehr gründlich und neige dazu, hin und her zu wechseln zwischen dem Lesen des rohen Markdown und dem Lesen des formatierten Beitrags, während ich das tue. Jetzt ist es im Editor-Bereich sehr schwierig.
Ich mag auch generell kein WYSIWYG. Meiner Erfahrung nach sind sie sehr wackelig und ich habe nicht die Absicht, sie zu benutzen. Für mich muss der Markdown-Editor, der schon immer existiert hat, weiterhin eine reibungslose Benutzererfahrung bieten.
Ich stimme @schneeland zu. Ich bin Softwareentwickler und benutze regelmäßig IDEs, die natürlich eine Monospace-Schrift verwenden, aber das ist einfach ein anderer Kontext. Es wäre tatsächlich sehr störend, wenn Jira anfangen würde, eine Monospace-Schrift zu verwenden.
Ich bin mir nicht sicher, ob ich jemals Probleme mit Tabellen in Markdown hatte. Und außerdem richten sich selbst in Monospace die vertikalen Striche zwischen den Spalten nicht aus, da jede Zelle wahrscheinlich eine unterschiedliche Anzahl von Zeichen enthält.
Auf jeden Fall weiß ich, dass Sie der Änderung etwas Zeit geben wollen, aber hoffentlich hilft dieses Feedback. Beachten Sie, dass meine Kommentare auf der neuesten Monospace-Schrift basieren und ich die vorherige Version nicht gesehen habe. Ich vergleiche also nur meine Erfahrung mit der, die seit Jahren besteht, nicht mit der ersten Monospace-Schrift, die vor ein paar Tagen verwendet wurde.
Wie viele Leute werden tatsächlich Tabellen in einer Forenantwort verwenden, die das rechtfertigt? Außerdem verwendet Obsidian Markdown und Tabellen mit Monospace darin, während der Text außerhalb serifenlos ist:
Ich sehe nicht, warum der gesamte Composer auf Monospace geändert werden muss, wenn sie nebeneinander existieren könnten?
Ich würde sagen, 99 % dessen, was wir schreiben, ist „normaler“ Text, kein Markdown.
Meine ehrliche Meinung ist, dass dies keine großartige Funktion ist, die Benutzern „aufgezwungen“ wird, selbst wenn wir sie etwas atmen lassen. Es ist keine Änderung, über die sich Benutzer erleichtert fühlen, und das zeigt sich in den meisten Kommentaren. Es sollte eine Benutzereinstellung sein.
Ich sehe kein wirkliches Problem damit, wenn der Composer die gleiche Schriftart wie die Vorschau hat. Es ist ziemlich einfach zu verstehen, was passiert. Das ist doch schon seit vielen Jahren so, oder? „Wenn es nicht kaputt ist, repariere es nicht“, sagen sie. Und das gilt meiner Meinung nach auch hier.
Für Leute, die mit dieser Änderung zu kämpfen haben, habe ich eine Empfehlung:
Probieren Sie es ein paar Tage lang mit deaktivierter Vorschau aus
Sobald die Vorschau deaktiviert ist, fühlt sich die Schriftänderung deutlich natürlicher an.
- Der Wechsel von Rich zu Quellcode fühlt sich viel natürlicher an
- Es ist äußerst klar, in welchem Modus Sie sich befinden
Wir nehmen weiterhin Feedback entgegen, nichts ist zu 100 % in Stein gemeißelt, wir fügen hier möglicherweise weitere Benutzerschalter hinzu, ich weiß es nicht.
Diese Schriftart sollte unter https://\\u003csite\\u003e/admin/config/fonts konfigurierbar sein, ist es aber derzeit nicht.
Ich mochte die Monospace-Schriftart nicht (sie ist gut zum Programmieren, aber nicht zum Tippen in einem Forum), also habe ich sie zurückgeändert, indem ich dieses CSS zu meinem Theme hinzugefügt habe (lasst mich bitte wissen, ob es dafür eine bessere Methode gibt!)
.d-editor-container--rich-editor-enabled .d-editor-textarea-wrapper textarea.d-editor-input {
font-family: var(--font-family) !important;
font-size: var(--base-font-size) !important;
line-height: var(--line-height-large) !important;
}
Ich finde wirklich, dass dies eine Benutzereinstellung sein sollte. Ich sollte nicht gezwungen werden, die WYSIWYG-Ansicht zu verwenden, um eine lesbare Schriftart zu nutzen. Monospace-Schriftarten sind für mich bei normalem (Nicht-Code-)Text praktisch unlesbar. Das ist besonders auf Mobilgeräten auffällig, wo man keine Vorschau gleichzeitig nebeneinander sehen kann, aber auch auf dem Desktop ist es nicht gerade gut. Ich glaube nicht, dass eine Website-Einstellung oder eine CSS-Überschreibung ausreicht, da nicht alle Website-Administratoren auf Benutzerfeedback für so etwas reagieren werden.
Absolut (und ich stimme so stark zu, dass ich ein Konto erstellt habe, um meine Zustimmung zu posten!)
Markdown bricht Zeilen automatisch um und hat andere Eigenschaften, die die Grenze zwischen „Textverarbeitung“ und „Code“ verwischen. In einem Diskussionsforum ist es sicherlich viel mehr eine Textverarbeitung … und ich war mit dem bisherigen Verhalten ziemlich zufrieden. Ich habe es geschätzt, frei und ohne Mehrdeutigkeit kopieren und einfügen zu können. Ich mag es, dass ich Enter drücken und eine neue Zeile erhalten kann, anstatt irgendeine WYSIWYG-Vorstellung davon, was ich gemeint haben könnte.
Markdown-Bearbeitung wird durch die Verwendung einer Schriftart mit fester Breite nicht funktionaler oder angenehmer. Sie wird schlechter … und ich denke, jeder, der sie tatsächlich benutzt, würde zustimmen.
Markdown wird also zu einem Bürger zweiter Klasse gemacht, um den visuellen Hinweis darauf zu verstärken, in welchem Modus Sie sich befinden.
Ich möchte die UX-Designer unter Ihnen fragen, ob es einen besseren Weg gibt, den Modus hervorzuheben … der Sie nicht bittet, den fast nie guten Kompromiss einzugehen, eine Schriftart mit fester Breite zu verwenden, um Text zu bearbeiten, der größtenteils kein Code ist.
Wenn dafür eine gute Antwort gefunden würde, gäbe es keine Notwendigkeit für eine Option, feste Breite vs. nicht feste Breite umzuschalten, da es immer eine proportionale Schriftart wäre.
[quote=„seanblue, post:31, topic:359936”]
Ich sollte nicht gezwungen werden, die WYSIWYG-Ansicht zu verwenden, um eine lesbare Schriftart zu nutzen.
[/quote]
[quote=„seanblue, post:31, topic:359936”]
Dies ist besonders auf Mobilgeräten auffällig, wo man keine Vorschau gleichzeitig nebeneinander sehen kann.
[/quote]
2 gültige Punkte!
Seit uns gesagt wurde, wir sollen es „atmen lassen“, ist viel Zeit vergangen. Wie wir sehen, ist diese Änderung nichts, bei dem wir alle gesagt hätten: „Tolle Änderung!“
Wie jemand anderes sagte, gab es dafür eine enorme Nachfrage? Ich weiß es nicht … Ich bezweifle es, aber vielleicht irre ich mich.
Ich denke, Markdown als „Codierungs“-Sprache zu betrachten, um das Monospace zu rechtfertigen, ergibt für mich nicht viel Sinn. Ich sehe Markdown als eine Möglichkeit, Text zu formatieren, nicht unbedingt als eine „Codierungs“-Sprache. Ich muss kein Entwickler sein, um Markdown zu verwenden, im Gegensatz zur Verwendung von z. B. VS Code, Cursor usw., wo Monospace angebracht ist.
Wenn wir neue Themen oder Antworten in einem Forum erstellen, „codieren“ wir nicht, wir „texten“, und Text sollte lesbar sein. Monospace ist einfach nicht so gut lesbar. Ich kann einen 150-Absatz in einem Markdown-Editor schreiben, ohne jemals eine Markdown-„Syntax“ zu verwenden (wenn es so genannt wird?). Daher sehe ich Markdown als etwas Zusätzliches, das wir zur Textformatierung verwenden können, nicht unbedingt als ein „Format“, auf dem alles sitzen muss, wenn das Sinn macht?
Füge dies in dein CSS ein, @seanblue und @alltiagocom. Es wird den Composer auf die Standardeinstellungen deiner Website zurücksetzen.
/* Ändert die Schriftart im Composer von Monospace zurück zur Standard-Sans-Serif-Schriftart */
.d-editor-container .d-editor-textarea-wrapper textarea.d-editor-input {
font-family: var(--font-family);
font-size: 1rem; /* oder verwende 16px oder deine spezifische Standardgröße */
}
Ich glaube daran, den Benutzern eine Wahl zu geben. Vielleicht wollen manche Benutzer eine nichtproportionale Schriftart. Ich weiß es nicht. Ich habe einige verrückte VS Code-Themes gesehen (grüner Hintergrund mit schwarzem Text oder schlimmer), und ich würde das nie benutzen, aber jeder Mensch ist anders.
Ich werde meine definitiv auf serifenlos umstellen, aber mein Punkt hier ist, dass wir unseren Benutzern die Optionen anbieten könnten. Das ist alles.
Ich bin voreingenommen als Discourse-Mitarbeiter, aber ich bevorzuge die neue Monospace-Schriftart sehr sehr stark. Es besteht also eine gute Chance, dass die Leute, die sagen: „Ah ja, nett“ oder sogar „Hm, nie bemerkt“, sich nicht äußern.
Es muss mindestens Dutzende von uns geben ![]()
Sicher. Es gibt viele Coder und Entwickler ![]()
(Aber unter normalen Leuten wird Monospace nicht als gut lesbare Schriftart gezählt. Für mich und meine Benutzer hat der CSS-Trick funktioniert, daher ist dies für mich als Administrator eher eine akademische Frage. Aber hören wir auf zu sagen, dass diese Änderung für die Mehrheit vorgenommen wurde und weit verbreitet ist, denn das stimmt nicht.)
Ich glaube, Sie treffen Annahmen über mich, die nicht wahr sind ![]()
Ich stimme zu – die Monospace-Schrift ist unerwartet und hässlich. Auch unnötig. Es gibt bereits einen Schieberegler in der Symbolleiste, der uns anzeigt, in welchem Modus wir uns befinden.
Nun, das habe ich nicht, weil sich nicht alles um dich drehte oder von dir stammte.
Wie auch immer. Zwei Optionen als Komponist beizubehalten war eine wunderbare Lösung. Monospace nicht so sehr, aber solange die CSS-Änderung funktioniert, bin ich glücklich. Aber ich verstehe den Punkt, eine Benutzereinstellung dafür zu haben – aber ich mag sie nicht, weil es schon ziemlich viel einzurichten gibt. Aber ich bin mir nicht so sicher, wie viele normale Benutzer überhaupt jemals Einstellungen ändern… und dann spielt es keine Rolle, wie überfüllt es ist ![]()

