クイックPSA：
ここで、またはご自身のサイトで新しいコンポーザーをテストしている方へ。Markdown（ソースコード）フォントを等幅フォントに変更しました。
これにより、ユーザーは「Markdown」モードと「リッチ」モードを区別しやすくなります。
この変更は、業界で一般的に受け入れられているフォント選択（Reddit / Stack Exchange）に準拠しています。
この変更はリッチエディターが有効になっているサイトにのみ適用され、約20〜40分でここに反映されるはずです。
「いいね！」 13
私はどちらも使用していないため、全く異なる業界の分野です。その場合、もっと…良いフォントを使うように戻すにはどうすればいいですか？自ホストのインスタンスで、もちろんです。
「いいね！」 3
サイトにテーマやコンポーネントを導入して、このフォント選択を上書きできます。CSS 3 行で可能です。
より見やすいフォントは新しいコンポーザーでもそのまま使用され、そこでは等幅フォントに切り替わりません。
「いいね！」 4
私は通常、より長い投稿を書きますし、WYSIWYGは必要ありませんが、ユーザーは必要としているので、マークダウンを使用します。しかし、等幅フォントは非常に読みにくく、業界の大多数がエディタで等幅フォントを使用しないのには理由があります。
ちょっと興味本位で聞きたいのですが、この変更の意図は何でしたか？今、使いやすさが損なわれています。
でも、はい、iPadのようなよりユーザーフレンドリーなデバイスで作業するときにクラスを調べ始めます😂
「いいね！」 2
それは必ずしも真実ではありません。すべてのコーディングエディタは等幅フォントを使用しており、それが業界標準です。
とはいえ、ここではこの変更を受け入れてください。もしこれが本当にメタであなたを悩ませるなら、これを試すことをお勧めします。
リッチエディタはここで非常にうまく機能します。フォントに関するフィードバックをお待ちしています。
「いいね！」 6
コーディングエディタは使用していません。テキストとコンテンツを作成しています。
機能します。
本当に本当に迷惑ですが、ここではあまり書かないので我慢できます。しかし、あなたのヒントで私のフォーラムでこれを修正する方法を見つけ、うまくいきました。ありがとうございます。
しかし、答えは得られましたが、その変更の意味と目的はまだ理解していませんが、理解する必要もありません。MetaはMetaがやっていることをやっており、私はそれを自分の側で変更できます。ほとんどの人は満足しています。
「いいね！」 2
それは本当ですが、ここでこの比喩が適切かどうか疑問に思っています。DiscourseでMarkdownを含む投稿を書くことを考えると、私は精神的に「コーディングスペース」ではなく、「ウェブ編集スペース」にいます。そして、DiscordやJIRAのように、Markdown形式の投稿を書く場所でも、どちらも等幅フォントを使用していません。
今では、新しいエディタ（行ブロックを完了するとフォーマットされる、一種の「セミWYSIWYGモード」で使用できるため）にはほとんど満足しており、ロールアウトされたら古いエディタの使用頻度は減ると思いますが、それでも等幅フォントを使用することに決定した場合、フォントの太さを減らして、レンダリングされたテキストの太さに近づけるのが良いと思います。現在、テキストが少し太すぎると感じます。
「いいね！」 8
これは興味深い変更ですね！今日、これを使っていくつかの長い投稿を書きましたが、慣れるのに苦労している主な点は、左側が右側よりも多くのスペースを占めるため、両側がすぐにずれてしまうことです。
プレビューを見ながら書くことに慣れすぎて、何年も経った今でも、マークダウン側ではなくプレビュー側をクリックしてしまうことがあります！
この変更により、それはもちろん問題ではなくなります。どこに入力すべきかが非常に明確になります。
慣れるには少し時間がかかると思いますが、@schneeland が言っているように、マークダウンのフォントサイズを小さくできるという点には同意します。
「いいね！」 6
視覚的な手がかりがある意図は理解できます。この文脈では理にかなっています！時々、リッチエディターを使っているかどうか疑問に思うことがあります。
全体的に目覚ましいパフォーマンスを発揮しているリッチエディターを支持するヒントを出すことも重要です。
リッチエディターのバグのため、私はまだマークダウンエディターを頻繁に使用しています。
現時点では、読むのが簡単ではありません。
Schneelandが言ったように、マークダウンエディターをコーディングエディターとは考えていません。慣れるには時間がかかります。プレビューフォントにより近いフォントサイズに調整できると素晴らしいでしょう。
「いいね！」 8
FirefoxおよびChromiumブラウザ用のStylusというブラウザ拡張機能をダウンロードすると、他のウェブサイトのCSSを上書きできます。
Safariはあまり使わないので試していませんが、詳細設定 → _スタイルシート_の下にカスタムスタイルシートを追加する設定があります。
このCSSが機能すると思います。
.d-editor-input {
font-family: var(--font-family) !important;
}
（別のフォントにしたい場合は、var(--font-family)を別のフォント名に置き換えてください。）
「いいね！」 2
これは繰り返しのフィードバックです。jetbrains mono を取り入れて、サイズを少し調整して、よりうまく揃えられるか試してみます。
これが明らかにするのに役立った大きな点は、私たち全員が等幅フォントを少しずつ異なって体験しているということです。一貫した体験を作ることが、ここで役立つかもしれません。
「いいね！」 3
JetBrains Mono を 14px に設定すると、以下のようになります。
直接比較：
JetBrains Mono は私にとって素晴らしく見えます。間違いなく読みやすく、プレビューフォントともよく合っています。
さらに、コンテンツがコードとして扱われるようになったので、ハイライトすると理にかなっています。トピックはありますが、コンテンツを思い出せません。例：
「いいね！」 6
モノスペースフォントの外観を損なっている可能性が高いのは、デフォルトのベースフォントである Inter とは異なり、--d-font-family--monospace にシステムデフォルトが使用されていることです。コードブロックのフォントサイズである14pxでは問題ありませんが、テキストエディタのフォントサイズでは、Interの隣で違和感があります。
Firefox - Windows
Firefox - MacOS
Safari - MacOS
システムデフォルトへのフォールバックというこの動作は、GitHubやStackOverflowのような他のコーディング中心のサイトとも一致しますが、デフォルトの Inter ボディフォントとよく合う特定のモノスペースフォントを見つける方が良いでしょう。
「いいね！」 6
これはすぐに公開されるはずです。PRのレビューを終えたところです。
スクリーンショットは解決されます @Alteras
これは難しいですね。反対ではありませんが、かなり大きな変更になります。
現在、MarkdownはTEXTAREAでレンダリングしています。この派手なハイライトを行うには、Ace（当社が出荷しているもの）またはCodeMirror（当社が出荷していないもの）、あるいはカスタムProseMirrorセットアップ（非常に複雑になる）に切り替える必要があります。
個人的にはシンタックスハイライトされたMarkdownが好きですが、この分野でのサイドクエストは、リッチエディタで進められている進捗から私たち全員を大きくそらしてしまうと思います。
「いいね！」 7
まだ、monospace をまったく使用しないのが最も明白な解決策ではないかと思っています。monospace が必要な場合は、単純なコンポーネントを使用します。
しかし、ここでのポリシーの違いが見えます。
- markdown は開発者とコーディング用です。
- リッチエディターはそれ以外の人用です。
- それ以外の人であり、markdown を使用するのが好きなら、選択する必要があります。
コンテンツ作成のために monospace を提供する必要がある本当の理由と需要が、まったく異なるフォントで表示されることを、私は本当に理解できません。
開発者と一般の人々との間に境界線が引かれているような感覚が再びあることが、私を非常に悩ませています。おそらく開発者は世界的に多数派かもしれませんが、このトピックの他の誰もが完全に満足している（フォントサイズの質問が修正できれば）ので、その感覚はおそらく私の問題にすぎません。
まあ、私にとっては非常に学術的なトピックです。私のフォーラムではその CSS トリックが機能し、ユーザーはどちらの markdown またはリッチエディターを使用しているかを伝えるためにこの大きさのポインターを必要としません。そして、なぜ と 何を与えるか というメタ情報が望まれていない、または必要とされていないと感じているので、私が降りるのがみんなにとって最善です。結局のところ、私は開発者ではなく、コーディング/コードエディターは必要ありませんが、コンテンツ用の markdown エディターは必要です。
「いいね！」 5
少し息抜きが必要な変更です。変更はすべて、行う際に不快なものです。今日の調整により、変更は著しく不快でなくなりました。
等幅フォントには、Markdownに関して他の利点もあります。テーブルははるかに簡単に扱え、整形済みテキストもはるかに簡単に扱えます。
私はここにいて、コメントを聞いています。もし最終的に、圧倒的なフィードバックのためにこれが多すぎると感じた段階に達した場合、決定を改訂または微調整する可能性があります。
今日の変更には、Discourseにとって素晴らしい副作用もあります。等幅フォントは、OSごとに解釈が異なるため、人によって意味が異なっていました。リッチエディタが有効になっているユーザーは、製品全体で一貫した等幅フォント体験を得られるようになりました。
昨日のフィードバックは完全に理解できますが、今日は調整されたフォントにずっと快適さを感じています。それは良いことで、これにより次のようなものを書くことができます。
\（^ - ^）/
|
/ \
そして、それはコンポーザーでプレビューと同じように見えます。
「いいね！」 7
はい、デフォルトとしては完全に理にかなっています。
テーマコンポーネントがより柔軟性を提供する機会でもあります（固定フォントドロップダウンなど）。
「いいね！」 2
アップデートありがとうございます！自然に見えますし、今はとても快適です。
この小さな変更で大きな違いが生まれ、もう慣れていく自分が目に浮かびます。
「いいね！」 5
あまり好きではありません。等幅フォントを使用すると、1つのウィンドウで入力していることと、実際のテキストが別のウィンドウでレンダリングされていることに過度に意識してしまいます。LaTeXの思い出が蘇ります…
もしこれが長期的に実装されるのであれば、--d-font-family-monospace のデフォルトの等幅フォントではなく、--d-font-md-composer のような専用のフォント変数を持つべきだと思います。そうすれば、等幅フォントに影響を与えることなく、サイトごとに簡単に変更できます。
「いいね！」 8
フォーラムのコンポーザーのフォントが変わったことに気づきました。
意図的なものかどうかわかりません。
もし意図的なものであれば、すべてのDiscourseユーザーに適用されるアップデートではないことを願っています。私は通常の「Arial/Helvetica/sans serif」フォントを気に入っています。少なくとも、管理者パネルで自分で変更できることを願っています。
編集：私の投稿はトピックから分割されたものだったので、このトピックでは少し奇妙に感じます。気にしないでください。意図的なことだとわかっています…
私の意見ですが、2つの異なるエディターで異なるフォントを使用することが理にかなっていることは理解できます。しかし、例えばObsidianはマークダウンツールであり、デフォルトでモノスペースを使用していません。そして、誰かが言ったように、リッチテキストエディターを使用できるものがあるとしても、このスペースを「コーディング」とは見なしていません。
わかりませんが、普段（あるいは全く）テキスト/メッセージを入力する際に使用しないフォントなので、奇妙に感じます。私はDiscourseとObsidianの両方を「古い」方法で使用することに慣れていたので、モノスペースで入力するか、リッチテキストエディターを使用するのは少し奇妙です。
これは各ユーザーが変更できる機能にできないでしょうか？