フォーラムに投稿する前に投稿内容をプレビュー画面で確認したい

  1. Kuroさん、こんにちは。

    今回はHaijin Boys Onlineのフォーラムに関して要望があります。

    フォーラムに投稿するとき、名前と本文を入力して(新しく質問するときは件名も入力)、「投稿」ボタンをクリックすると投稿することができます。
    ですが、投稿後に投稿した内容を確認すると、文章の内容が誤っていたり、もっと分かりやすい書き方を発見したりと、色々気づくことがあります。

    しかし、下記URLを参照すると、投稿された内容は修正できないため、投稿後に気づいても後の祭りです。

    https://www.haijin-boys.com/discussion-guidelines#12

    こんなとき、とあるサービスのお問い合わせフォームやWikipediaみたいに、入力した内容をプレビュー画面で確認できれば、投稿する前に間違いに気づいて修正することができます。

    よって、Haijin Boys Onlineのフォーラムに投稿する前に投稿内容をプレビュー画面で確認ができるようにしてもらえないでしょうか?

     |  MSY-07  |  返信
  2. こんにちは、ご意見ありがとうございます。

    フォーラムの投稿画面にプレビュー機能がない件についてですが、このフォーラムシステムは私が趣味で開発したもので、以前にプレビュー機能の実装に挑戦したこともありましたが、難易度が高く挫折してしまいました。

    レンタルのフォーラムシステムを利用すれば、プレビュー機能も利用できるかもしれませんが、そのシステムの選定や構築、データ移行にはかなりの労力がかかると思います。

    お手数をおかけしますが、投稿内容は直接フォームに入力するのではなく、別のエディターなどで事前に記入し、内容に問題がないかをご確認の上でご投稿いただきますようご協力をお願いします。

    時間に余裕ができた際にはプレビュー機能の追加についても検討してみますが、現在は Mery の開発とサポートに追われており、ほとんど余暇がない状況ですので、今のところ対応が難しい状況です。

     |  Kuro  |  返信
  3. Kuroさん、ご返信ありがとうございます。

    > フォーラムの投稿画面にプレビュー機能がない件についてですが、このフォーラムシステムは私が趣味で開発したもので、以前にプレビュー機能の実装に挑戦したこともありましたが、難易度が高く挫折してしまいました。

    そうでしたか。

    簡単なことではないとは思っていましたが、それほど実装が難しいとは思っていませんでした。

    > レンタルのフォーラムシステムを利用すれば、プレビュー機能も利用できるかもしれませんが、そのシステムの選定や構築、データ移行にはかなりの労力がかかると思います。

    かなりの労力をかけてプレビュー機能は利用できるようにするのであれば、Meryの開発とサポートに時間を割いた方が良いですよね。

    > お手数をおかけしますが、投稿内容は直接フォームに入力するのではなく、別のエディターなどで事前に記入し、内容に問題がないかをご確認の上でご投稿いただきますようご協力をお願いします。

    実はフォーラムに投稿する文章は毎回Meryで書いています。

    ですが、Meryで文章を何度推敲しても、フォーラムに投稿した文章を見ると何か印象が変わるんですよね。

    それで今思ったのですが、普段Meryでフォーラムの文章を書くときは折り返し方法が「ウィンドウの右端で折り返し」を選択しています。

    しかし、これだとテキスト画面がフォーラムの画面よりかなり幅が広くなって文章の行数が増えるので、文章の読みやすさが変わってくるんですよね。

    今後は、折り返し方法の「指定文字数で折り返し」を選択して、行の文字数を指定してフォーラムの画面の幅になるべく合わせた上で、投稿前の文章を確認してみますね。

    ただ、Markdownで書いていると、他人の文章を引用するときに3行目以降に色がつかなくなって見づらくなるのが難点ですが、下記のURLに仕様と書いているので、そういうものだと思って割り切ります。

    https://www.haijin-boys.com/wiki/よくある質問#改行および折り返しをまたぐ検索で強調表示されません

    > 時間に余裕ができた際にはプレビュー機能の追加についても検討してみますが、現在は Mery の開発とサポートに追われており、ほとんど余暇がない状況ですので、今のところ対応が難しい状況です。

    Meryの開発とサポートだけでも相当忙しいのに、ご無理を言ってすいませんでした。

    プレビュー機能の追加については、時間に余裕ができたときに検討してもらえると嬉しいです。

     |  MSY-07  |  返信
  4. ご返信ありがとうございます。

    > 簡単なことではないとは思っていましたが、それほど実装が難しいとは思っていませんでした。

    以前に開発に挑戦したときは、Markdown 対応も考えていたので、その時は特に難しかったんですよね。仕様の面でもいくつか問題があったのを思い出しました。

    たとえば、よく使われる方法としては、PHP でプレビュー画面を作って、サーバー側で処理するやり方があります。

    この方法だと、今のフォーラムの画面をそのまま使えるので、シンプルなプレビュー画面を作るのはそこまで難しくないと思います。

    でも、このやり方にはいくつか問題があるんですよね。

    サーバーへの負担:

    サーバーでプレビュー処理をすると、リクエストが増えるたびにサーバーへの負荷も高くなります。

    特に、投稿前に何度もプレビューを表示するユーザーさんがいると、サーバーが重くなるかもしれません。

    スパムや悪意あるリクエストのリスク:

    プレビュー機能を誰でも使える状態にすると、スパムや悪意のあるリクエストが大量に送られるリスクもあります。

    これでサーバーがさらに負荷を受けることになります。

    レンタルのフォーラムを含め、多くのフォーラムでは、会員制にして特定のユーザーだけが使えるようにして、こういう問題を避けていますよね。

    でも、Mery は昔ながらのフリーソフトのスタイルでオープンなフォーラムを続けているので、こうした問題に対処するのがなかなか難しいんです。

    > それで今思ったのですが、普段Meryでフォーラムの文章を書くときは折り返し方法が「ウィンドウの右端で折り返し」を選択しています。

    フォーラムの折り返し位置はブラウザの幅に依存するので、そこまで気にしなくても良いかなとは思いますが…

    > ただ、Markdownで書いていると、他人の文章を引用するときに3行目以降に色がつかなくなって見づらくなるのが難点ですが、下記のURLに仕様と書いているので、そういうものだと思って割り切ります。

    そうなんですよね、これは仕様なんです。

    「重くなっても良いので、もっとたくさんの行をまたいで色分けできるようにしてほしい」というご要望もいただいたことがありますが、行数を増やすと本当に重くなってしまうので、あまりおすすめできないんです。

    > プレビュー機能の追加については、時間に余裕ができたときに検討してもらえると嬉しいです。

    最近は、JavaScript でもいろいろな処理ができるようになっているので、クライアントサイドでプレビュー機能を実装できれば、サーバーへの負担も軽く、セキュリティリスクも抑えられるかもしれませんね。

    さすがに、Markdown 対応はセキュリティ面でも難しいと思いますが、折り返し位置を確認できるくらいのシンプルなプレビュー機能なら、なんとか実装できるかもしれません。

    また時間ができたら、改めて挑戦してみたいと思います。

     |  Kuro  |  返信
  5. Kuroさん、ご返信ありがとうございます。

    > 以前に開発に挑戦したときは、Markdown 対応も考えていたので、その時は特に難しかったんですよね。仕様の面でもいくつか問題があったのを思い出しました。

    Markdown対応を考えていたのは気になりますね。

    > サーバーでプレビュー処理をすると、リクエストが増えるたびにサーバーへの負荷も高くなります。
    >
    > 特に、投稿前に何度もプレビューを表示するユーザーさんがいると、サーバーが重くなるかもしれません。

    私は他のサービスだと投稿前に何度もプレビューを確認して文章を修正しているので、この仕様だとサーバーを重くしてしまいますね。

    > プレビュー機能を誰でも使える状態にすると、スパムや悪意のあるリクエストが大量に送られるリスクもあります。
    >
    > これでサーバーがさらに負荷を受けることになります。

    これは問題ですよね。

    > 最近は、JavaScript でもいろいろな処理ができるようになっているので、クライアントサイドでプレビュー機能を実装できれば、サーバーへの負担も軽く、セキュリティリスクも抑えられるかもしれませんね。
    >
    > さすがに、Markdown 対応はセキュリティ面でも難しいと思いますが、折り返し位置を確認できるくらいのシンプルなプレビュー機能なら、なんとか実装できるかもしれません。

    折り返し位置を確認できれば十分です。
    できれば、引用マークがついた文章に色がついていると助かります。

    > また時間ができたら、改めて挑戦してみたいと思います。

    はい、よろしくお願いします。

     |  MSY-07  |  返信
  6. ご返信ありがとうございます。

    > Markdown対応を考えていたのは気になりますね。

    それについては、あまり気にしないでくださいね。

    > 私は他のサービスだと投稿前に何度もプレビューを確認して文章を修正しているので、この仕様だとサーバーを重くしてしまいますね。

    MeryWiki がときどき落ちてるのもご存じだと思いますし😅

    MeryWiki やフォーラムの場合、サーバーのスペックは普通のデスクトップ PC よりも少し低いくらいなので、大手企業のサービスとは違ってちょっと限界があります。

    (それでも、一番下のスペックよりは少し良いものを使っているんですよ。私のポケットマネーも限界です…)

    > 折り返し位置を確認できれば十分です。
    > できれば、引用マークがついた文章に色がついていると助かります。

    [投稿] ボタンの隣に [プレビュー] ボタンを追加してみました。

    Wiki のプレビュー機能を参考にして作ったつもりですが、急いで作ったので、使い勝手にはご理解いただけると嬉しいです。

    ちなみに、Chrome、Edge、Firefox での動作確認はしてありますが、古いブラウザーではうまく動かないかもしれません。

     |  Kuro  |  返信
  7. Kuroさん、ご返信ありがとうございます。

    > [投稿] ボタンの隣に [プレビュー] ボタンを追加してみました。
    >
    > Wiki のプレビュー機能を参考にして作ったつもりですが、急いで作ったので、使い勝手にはご理解いただけると嬉しいです。
    >
    > ちなみに、Chrome、Edge、Firefox での動作確認はしてありますが、古いブラウザーではうまく動かないかもしれません。

    素早いご対応ありがとうございます。

    まさにこの機能がほしかったんですよ。
    また、Wikiのプレビュー機能に準拠していて使いやすいです。

    Chrome、Edge、Firefoxで下記の動作確認を行いましたが、問題ありませんでした。

    ・行の右端での折り返し
    ・引用マーク「>」「>>」が先頭についた文章を色分けして表示
    ・URLをクリックするとリンク先に移動
    ・<pre>タグで囲んだソースコードを整形済みテキストとして表示

    これで投稿前にプレビューで投稿内容を確認して問題がないか確認することができます。

    それで、1つ気になったことがあります。
    投稿前にプレビューを表示をしたとき、<pre>タグで囲んだソースコードが色付けして表示されませんが、何か理由があるのでしょうか?

     |  MSY-07  |  返信
  8. ご確認いただきありがとうございます。

    > ・行の右端での折り返し
    > ・引用マーク「>」「>>」が先頭についた文章を色分けして表示
    > ・URLをクリックするとリンク先に移動
    > ・<pre>タグで囲んだソースコードを整形済みテキストとして表示

    このあたり、PHP で書いていた部分を JavaScript に書き直したので、正直自信はなかったのですが、うまく動いているようで安心しました。

    > 投稿前にプレビューを表示をしたとき、<pre>タグで囲んだソースコードが色付けして表示されませんが、何か理由があるのでしょうか?

    気付かれてしまいましたね。

    実は、最初は色分けするようにしてたのですが、今のフォーラムは言語を自動判別して色分けする仕様なんですよね。

    でも、短いコードだとうまく判別できなくて、変な色分けになることが多くて…。

    それが投稿前に見えると「ちゃんと判別させなきゃ!」と無駄に気を使わせちゃうかなと思って、プレビューではあえて色分けしないようにしました。

    投稿後に変な色分けがされても、「まぁ、仕方ないか~」って納得できるかと思って。

    もし、プレビューでも色分けが必要でしたら、そういう風にもできます。

     |  Kuro  |  返信
  9. Kuroさん、ご返信ありがとうございます。

    > 実は、最初は色分けするようにしてたのですが、今のフォーラムは言語を自動判別して色分けする仕様なんですよね。
    >
    > でも、短いコードだとうまく判別できなくて、変な色分けになることが多くて…。
    >
    > それが投稿前に見えると「ちゃんと判別させなきゃ!」と無駄に気を使わせちゃうかなと思って、プレビューではあえて色分けしないようにしました。
    >
    > 投稿後に変な色分けがされても、「まぁ、仕方ないか~」って納得できるかと思って。

    逆に、私はプレビューで色分けされてないと、投稿後のソースコードの色分けがどうなるかが心配になります。

    それで、実際に投稿してみたら、思っていた色分けと違っていて「やっちまった!!」と思う姿が見えます。

    > もし、プレビューでも色分けが必要でしたら、そういう風にもできます。

    個人的には、プレビューでも<pre>タグで囲んだソースコードが色分けされている方が分かりやすいです。

    というのも、プレビューと投稿後の画面の差異は可能な限り少ない方が投稿内容を修正しやすいからです。

     |  MSY-07  |  返信
  10. ご返信ありがとうございます。

    > 個人的には、プレビューでも<pre>タグで囲んだソースコードが色分けされている方が分かりやすいです。

    プレビューでもソースコードが色分けされるように対応しておきました。

    ただ、言語が自動判別だと、意図しない色分けになることもあるので、以下のように class 属性で言語を指定できる機能を追加してみました。

    <pre class="language-javascript">
    var x = 0;
    </pre>
    

    (従来どおり、class 属性を省略すると自動判別されます)

    対応している言語は以下のとおりです。

    • bash
    • c
    • cpp
    • csharp
    • css
    • delphi
    • diff
    • go
    • graphql
    • hsp
    • ini
    • java
    • javascript
    • json
    • kotlin
    • less
    • lua
    • makefile
    • markdown
    • objectivec
    • perl
    • php
    • php-template
    • plaintext
    • python
    • python-repl
    • r
    • ruby
    • rust
    • scss
    • shell
    • sql
    • swift
    • typescript
    • vbnet
    • wasm
    • xml
    • yaml

    さらに、Markdown にも対応してみました。

    [マークダウンを有効にする] をオンにすると、Markdown 記法が使えるようになります。

    Markdown の仕様は、markdown-it のデフォルトモード、その他、以下の機能にも対応しています。

    • 改行で <br>
    • 自動でリンク
    • タイポグラファー
    • ハイライト (==)
    • 絵文字
    • 脚注

    セキュリティの関係で、HTML タグや Markdown の画像埋め込みは使えません。

    ちなみに、Markdown を有効にしても、このフォーラム独自の記法「>> 名前」や「> 引用」はそのまま使えます。

    ただし、<pre> タグは使えなくなるので、Markdown のコードブロック (```) を使ってくださいね。

    なお、Markdown 記法の引用 (> や >>) は上記の記法が優先されるので、ネストされた引用などは使えません。

    Markdown 機能は試験的な運用ということで、実用性やセキュリティ面で問題が出たら、廃止するかもしれません。

     |  Kuro  |  返信
  11. Kuroさん、ご返信ありがとうございます。

    > プレビューでもソースコードが色分けされるように対応しておきました。
    >
    > ただ、言語が自動判別だと、意図しない色分けになることもあるので、以下のように class 属性で言語を指定できる機能を追加してみました。

    おおーー、ご対応ありがとうございます。
    これでプレビューでソースコードの確認がしやすくなります。

    あと、投稿後のフォーラムとプレビューでハイパーリンクをクリックすると、リンク色が青から紫に変わるようになったのは分かりやすくていいですね。

    > さらに、Markdown にも対応してみました。
    >
    > [マークダウンを有効にする] をオンにすると、Markdown 記法が使えるようになります。

    まさか、Markdownまで対応するとは予想していませんでした。

    いやー、Markdown記法でプレビューを表示できるのは便利ですね。
    特に、文章中にハイパーリンクを埋め込めるのは便利ですね。

    それで、Markdown記法で動作確認をしていたら、2つ気になったことがあります。

    1つ目は、「マークダウンを有効にする」をオン・オフの状態で、ハイパーリンクをクリックしたときの動作が変わります。

    ・「マークダウンを有効にする」をオフ:ハイパーリンクをクリックすると、別タブでリンク先のページが開く
    ・「マークダウンを有効にする」をオン:ハイパーリンクをクリックすると、同じタブ内でリンク先のページに移動する

    よって、「マークダウンを有効にする」をオンにした状態でハイパーリンクをクリックした場合も、別タブでリンク先のページが開く仕様に変更できないでしょうか?

    2つ目は、文章中に<br>タグを挿入しても、プレビューで文章中に<br>タグがそのまま表示されてしまい改行されません。

    https://imgur.com/gallery/markdown-br-zGErEJl

     |  MSY-07  |  返信
  12. Markdown対応!!ちょちょいと対応したの、すごすぎます!😮

    Markdownプレビュープラグインお馴染みの markdown-it ということで、もしかして ```bash のようにコードブロックの言語指定も対応かな?と思って試してみたところ、対応している様子… これは便利…!

     |  yuko  |  返信
  13. >> MSY-07 さん、yuko さん

    Markdown 対応、そう言ってもらえると嬉しいです😳

    > よって、「マークダウンを有効にする」をオンにした状態でハイパーリンクをクリックした場合も、別タブでリンク先のページが開く仕様に変更できないでしょうか?

    そうですね。これは markdown-it の仕様によるものですが、確かに別タブで開いた方が便利なので、無理やり対応しておきました。

    > 2つ目は、文章中に<br>タグを挿入しても、プレビューで文章中に<br>タグがそのまま表示されてしまい改行されません。

    HTML タグはセキュリティ上の理由で使用禁止にしています。

    Markdown 記法での改行、「\」を使っていただきたいのですが… <br> ぐらいなら使えても良いかなと思ったので、これも無理やり対応してみました。

    ただし、markdown-it にはこうした部分的な制限解除の機能がないので、他の HTML タグについては対応できません。その点はご容赦ください🙏

    > Markdown対応!!ちょちょいと対応したの、すごすぎます!😮

    いえいえ、実は数年前にフォーラムで「Markdown 書けないの?」という質問をもらったときに一度挑戦したのですが、知識不足で挫折してしまったんですよね😅

    > Markdownプレビュープラグインお馴染みの markdown-it ということで、もしかして ```bash のようにコードブロックの言語指定も対応かな?と思って試してみたところ、対応している様子… これは便利…!

    クライアント側では markdown-it の JS を使っているので、基本的には問題なく動作します。ただ、サーバー側がちょっと問題ですね。

    本来ならサーバー側で node.js などを使って markdown-it.js を動かすべきだと思うのですが、レンタルサーバーでは node.js が使えないんです…。

    さすがにクライアント側で Markdown → HTML 変換して投稿するのはセキュリティ的にリスクが大きすぎるので、従来どおり、プレーンテキストを投稿してサーバー側で Markdown を解析するかたちにしています。

    そのため、ローカルでのプレビューと投稿後の表示が異なる場合があるかもしれませんが、ご了承ください😱

     |  Kuro  |  返信
  14. Kuroさん、ご返信ありがとうございます。

    > そうですね。これは markdown-it の仕様によるものですが、確かに別タブで開いた方が便利なので、無理やり対応しておきました。

    ご対応ありがとうございます。
    おかげでリンクを開く動作が快適になりました。

    > HTML タグはセキュリティ上の理由で使用禁止にしています。
    >
    > Markdown 記法での改行、「\」を使っていただきたいのですが… <br> ぐらいなら使えても良いかなと思ったので、これも無理やり対応してみました。
    >
    > ただし、markdown-it にはこうした部分的な制限解除の機能がないので、他の HTML タグについては対応できません。その点はご容赦ください🙏

    Markdownの仕様に「改行で <br>」と書いてあったので、<br>タグを挿入することで改行することができるのかと勘違いしていました。
    すいませんでした。

    でも、<br>タグは使えた方が便利だと思うので、ご対応ありがとうございます。

    それで、動作確認をしていたら、「マークダウンを有効にする」をオフの状態でプレビューすると、引用マーク「>」「>>」が先頭についた文章が色分けして表示されないことがあります。

    https://imgur.com/gallery/F58hRuY
    https://imgur.com/gallery/0PwOhjv

    申し訳ないですが、ご確認をお願いします。

     |  MSY-07  |  返信
  15. ご報告ありがとうございます。

    > Markdownの仕様に「改行で <br>」と書いてあったので、<br>タグを挿入することで改行することができるのかと勘違いしていました。

    あぁ、なるほどです。「改行で <br>」というのは、Markdown では半角スペース 2 つや「\」で改行する必要があるのですが、それを通常の改行で自動的に <br> タグに変える機能ですね。

    > でも、<br>タグは使えた方が便利だと思うので、ご対応ありがとうございます。

    最近流行りの Zenn でも、<br> タグのみ、無理やり使えるようにしているみたいなので、そういうのもアリなんだなぁと思いまして。

    > それで、動作確認をしていたら、「マークダウンを有効にする」をオフの状態でプレビューすると、引用マーク「>」「>>」が先頭についた文章が色分けして表示されないことがあります。

    おっと、そこは気づいていませんでした。Markdown 対応で色々と調整していたときに、通常モードにも影響が出てたみたいです。さっそく修正しておきました。

     |  Kuro  |  返信
  16. Kuroさん、ご返信ありがとうございます。

    > おっと、そこは気づいていませんでした。Markdown 対応で色々と調整していたときに、通常モードにも影響が出てたみたいです。さっそく修正しておきました。

    ご対応ありがとうございます。

    動作確認を色々しましたが、今のところはこれ以上の要望や不具合はありません。
    これまでお付き合いいただきありがとうございました。

     |  MSY-07  |  返信
  17. Kuroさん、こんにちは。
    フォーラムのMarkdown機能で気になったことがあったので投稿しました。

    フォーラムのMeryで生成AIを使ってみる雑談部屋の更新内容を確認すると、箇条書きの3つ目の「例えば、(中略)返してくるようになりました。」でインデントされていますが、その文末と4つ目の箇条書きの行間が他の箇条書きの行間に比べて広いのが気になります。

    それで、タブまたは2か4つのスペースでインデントしたときに行間が広くなるようですが、行間が広くならないようにはできないでしょうか?

     |  MSY-07  |  返信
  18. > それで、タブまたは2か4つのスペースでインデントしたときに行間が広くなるようですが、行間が広くならないようにはできないでしょうか?

    原因は<ol><ul>margin-bottomが設定されていて入れ子の場合でも効いてるからですね。
    入れ子の方のマージンを消せばいいのでCSSに.blog-item-content :is(ol, ul) :is(ol, ul) {margin-bottom: 0;}とか追記するといいです。

     |  barrackdo  |  返信
  19. ご報告ありがとうございます。

    > 入れ子の方のマージンを消せばいいのでCSSに.blog-item-content :is(ol, ul) :is(ol, ul) {margin-bottom: 0;}とか追記するといいです。

    情報ありがとうございます。教えていただいた CSS を適用してみました。

    .blog-item-contentolulのスタイルシートは、たぶん Markdown 部分でしか使っていないので、他の部分への影響はないと思います。

    でも、もしブログ記事のほうに何か影響が出ていたら、教えてもらえるとすごく助かります。

     |  Kuro  |  返信
  20. >> Kuroさん、barrackdoさん

    早急なご対応ありがとうございます。

    おかげさまでインデント後の箇条書きの行間が他の行間と統一されて見やすくなりました😄

     |  MSY-07  |  返信
  21. Kuroさん、こんにちは。
    またフォーラムのMarkdown機能で気になったことがあったので投稿しました。

    下記のフォーラムを確認すると、フォーラム独自の記法である引用マーク「>」の後の文章ではMarkdownのマークアップが機能していません。

    一方、MeryのMarkdownプレビュープラグインやVS CodeのMarkdownプレビューで見ると引用マーク「>」の後のマークアップが正常に変換されています。

    それで、引用マーク「>」の後の文章でMarkdownのマークアップが機能するようにはできないでしょうか?

     |  MSY-07  |  返信
  22. すいません、上記のフォーラムの例ではそもそも「マークダウンを有効にする」をONにしていたかが不明なので、下記に例を提示します。

    下記の例を参照すると、引用マーク「>」の後に箇条書きのマークアップを記載してもマークアップが変換されません。

    • これはMarkdownが有効になっているかを確認するための文章です。

    > - これはMarkdownが有効になっているかを確認するための文章です。

    それで、引用マーク「>」の後の箇条書きでMarkdownのマークアップが機能するようにはできないでしょうか?

     |  MSY-07  |  返信
  23. こんばんは。

    > それで、引用マーク「>」の後の箇条書きでMarkdownのマークアップが機能するようにはできないでしょうか?

    この点については、Markdown 機能を追加した際にも注意事項として記載していますね。

    https://www.haijin-boys.com/discussions/8515#discussion-8549

    改めて説明しますと、当フォーラムでは引用マーク「>」を独自仕様として採用しています。

    Markdown のマークアップが適用されないというご意見も理解できますが、フォーラムの仕様として、Markdown のオン/オフに関係なく、返信時に引用の書き方とスタイルが統一されていた方が、フォーラムの利用者にとって分かりやすく、読みやすいと考えています。

    もともと当フォーラムでは、「>」を相手の文章を引用するための記法として採用していたため、Markdown と競合するからといって、今さら仕様を変更するのも難しいのが現状です。ご了承ください。

    ちなみに、2 行目以降なら、 > (行頭に半角スペース) を入れることで、Markdown の引用構文として認識されるようです。

    この部分は Markdown の引用構文です

    フォーラムの仕様で、文書全体にトリムをかけているため、「1 行目の先頭」には空白を入れられませんが、そもそも 1 行目から Markdown の引用を使うケースは少ないかと思います。

    どうしても Markdown の引用を使いたい場合は、この方法で回避ということでいかがでしょうか?

     |  Kuro  |  返信
  24. すいません、私の説明不足により要望が誤って伝わってしまったようですので、追加で説明をいたします😓

    今回の私の要望は、引用マーク「>」をMarkdownのマークアップとして変換してほしいというものではなく、フォーラムの仕様である引用マーク「>」の後に箇条書きのマークアップを記載しても変換されないので変換してほしいというものです。

    例として、下記の2つの文章を比べて見てください。

    • これはMarkdownが有効になっているかを確認するための文章です。

    > - これはMarkdownが有効になっているかを確認するための文章です。

    上記の1つ目の文章では、箇条書き、コード、強い強調のマークアップが変換されています。

    それに対して、2つ目の文章では、コード、強い強調のマークアップは変換されていますが、箇条書きのマークアップは変換されてなくて違和感を感じます。

    なお、フォーラムの仕様である引用マーク「>」自体に関しては現状の仕様で良いと思っていますので、「マークダウンを有効にする」をONにしたらMarkdownの引用に変化するということは特に希望していません。

    結論としては、フォーラムの仕様である引用マーク「>」の後に箇条書きのマークアップが記載されている場合、正しく変換することができないかという要望です。

    > ちなみに、2 行目以降なら、 > (行頭に半角スペース) を入れることで、Markdown の引用構文として認識されるようです。

    Markdownの引用を使用する場合はその方法を使ってみますね。

     |  MSY-07  |  返信
  25. ご意見はしっかり伝わっています。

    フォーラムの仕様上、「>」はフォーラム独自の記法と Markdown の「>」が競合するため、独自仕様を優先しています。

    また、Markdown の「>」はマークアップ時に <blockquote> タグへ変換されますが、これはブロック要素のため、フォーラムの独自仕様の引用文内では正しく機能しません。

    仕様上の制約となりますが、ご理解いただけると幸いです。

     |  Kuro  |  返信
  26. ご返信ありがとうございます。

    > ご意見はしっかり伝わっています。

    これは失礼しました。

    意見が伝わっているのであれば良かったです😊

    > フォーラムの仕様上、「>」はフォーラム独自の記法と Markdown の「>」が競合するため、独自仕様を優先しています。
    >
    > また、Markdown の「>」はマークアップ時に <blockquote> タグへ変換されますが、これはブロック要素のため、フォーラムの独自仕様の引用文内では正しく機能しません。
    >
    > 仕様上の制約となりますが、ご理解いただけると幸いです。

    制約については承知しました。

     |  MSY-07  |  返信
  27. ご返信ありがとうございます。

    いえいえ、こちらこそ、HTML の知識がある前提で説明してしまったので、不足していた部分があったかもしれません。

    念のため、少し補足させていただきますが、ご理解いただいている場合はスルーしてくださいね。

    当フォーラムの独自記法「>」は、相手の引用文を HTML の<span>タグに変換します。

    <span>タグはインライン要素というもので、他の要素と同じ行に配置される仕様です。

    一方、Markdown の「>」は<blockquote>タグに変換されます。

    <blockquote>タグはブロック要素というもので、単独で 1 つのブロックを作り、前後に改行が入る仕様です。

    HTML の仕様として、インライン要素 (<span>など) の中にブロック要素 (<blockquote>など) を含めることは禁止されています。

    ブロック要素は、Markdown で言うと、# (見出し)、> (引用)、- (リスト)、--- (水平線) などがあります。

    つまり、当フォーラムの独自記法「>」の場合、次のような記述は無効な HTML になります。

    <span>
        <blockquote>
            これは無効な HTML です。
        </blockquote>
    </span>
    
    <span>
        <ul>
            <li>これは無効な HTML です。</li>
        </ul>
    </span>
    

    一方、Markdown の「>」は<blockquote>タグなので、入れ子 (ネスト) が可能です。

    <blockquote>
        <blockquote>
            これは有効な HTML です。
        </blockquote>
    </blockquote>
    

    これが、当フォーラムでは使えないということで注意事項として言及していた「ネストされた引用」です。

    また、次のような記述も有効な HTML となります。

    <blockquote>
        <ul>
            <li>これは有効な HTML です。</li>
        </ul>
    </blockquote>
    

    これは、Markdown プレビュー プラグインで動作するとご指摘のあった「引用の中の箇条書き」です。

    そういうわけで、当フォーラムの独自記法「>」はインライン要素なので、その中に Markdown のブロック要素を含めることはできないため、仕様上の制約となります。

    ちなみに、Markdown の場合、行頭に記述するものがブロック要素(#>-など)だと思っていただけると、わかりやすいかもしれません。

     |  Kuro  |  返信
  28. ご返信ありがとうございます。

    > いえいえ、こちらこそ、HTML の知識がある前提で説明してしまったので、不足していた部分があったかもしれません。
    >
    > 念のため、少し補足させていただきますが、ご理解いただいている場合はスルーしてくださいね。

    私はHTMLが詳しいわけではないので、補足説明は助かります😊

    > そういうわけで、当フォーラムの独自記法「>」はインライン要素なので、その中に Markdown のブロック要素を含めることはできないため、仕様上の制約となります。

    なるほど、そういうことだったんですね。

    > ちなみに、Markdown の場合、行頭に記述するものがブロック要素(#>-など)だと思っていただけると、わかりやすいかもしれません。

    今後はブロック要素(#>-など)を使用するときは気を付けたいと思います。

     |  MSY-07  |  返信
  29. 現行のHTMLの解釈に関して誤りがあるので一応訂正しておきます。
    ※Web周りは巨大で複雑で流動的なので私の解釈にも間違いがある可能性に留意してください。

    HTML Living Standardまたは廃止済みのHTML 5.x系ではブロック要素、インライン要素から脱却し、すべてのHTML要素はいずれかのコンテンツカテゴリーのどれか一つ以上に属するように変更されています。

    変わった理由は旧来のままでは支障がある部分があったからですかね。
    分かりやすいところで言えば、ブロック要素全体をリンク化したいなどのニーズに対応できなかったためです。(<a>はHTML 4.01まではインライン要素)
    あとはHTMLとCSS共にブロック、インラインの用語があって紛らわしかったとか。

    適用されるコンテンツカテゴリーは条件によって変わることもあるので注意が必要です。
    要素ごとに許可されている内容コンテンツおよび許可されている親要素だとか閉じタグを省略出来るかなどが決められています。
    これらはMDNの各HTML要素のページにも技術的概要(英語版だとTechnical summary)に書かれています。

    翻って先の例示に関して見てみますと――

    • <span>
      • コンテンツカテゴリー:フローコンテンツ、記述コンテンツ
        • HTML Living Standardには知覚可能コンテンツも書いてある
      • 許可されている内容:記述コンテンツ
      • 許可されている親要素:記述コンテンツを受け入れるすべての要素、またはフローコンテンツを受け入れるすべての要素
    • <blockquote>
      • コンテンツカテゴリー:フローコンテンツ、区分化ルート、知覚可能コンテンツ
        • HTML Living Standardには区分化ルートが書かれていない
      • 許可されている内容:フローコンテンツ
      • 許可されている親要素:フローコンテンツを受け入れるすべての要素
    • <ul>
      • コンテンツカテゴリー:フローコンテンツ。また、<ul>要素の子に少なくとも1個<li>要素を包含する場合は、知覚可能コンテンツ。
      • 許可されている内容:0個以上の<li><script><template>要素
      • 許可されている親要素:フローコンテンツを受け入れるすべての要素

    ――というわけで<span>の子要素に<blockquote><ul>を配置するのはHTML Living Standardにおいても違反なのは変わってないですね。



    注意点としてHTML(やJS、CSS)のアップデートに伴ってコンテンツカテゴリーは増えたりする可能性があります。
    例えば、<style>は現状メタデータコンテンツだけですが、@scopeルール(Chromium系、Safariは対応済み)ではインラインの<style>要素中に記載する記法も許容されるようなので<script>のようにフローコンテンツ、記述コンテンツが追加されるかも知れません。


    ついでにブロックおよびインラインという用語はCSSの方に移譲されて生き残ってます。
    ボックスモデルにおけるブロックボックスとインラインボックスとしてが分かりやすいでしょうか。
    display: blockdisplay: inlineとかで用いられています。

    さらにmarginpaddingには論理プロパティとしてmargin-blockmargin-inlinepadding-blockpadding-inlineが追加されています。
    書字方向(左横書き、右横書き、右縦書き)が変わる可能性がある文書の記述などで特に便利です。(もちろん書字方向が変わらない文書でもオススメです)


    大枠ではブロック要素、インライン要素時代の書き方のままで問題ないです。
    可能であればLinterを通すようにしましょうってとこですね。

     |  barrackdo  |  返信
  30. 詳細なご説明をいただきありがとうございます。

    HTML の仕様に関して、ブロック要素とインライン要素の概念がどのように変わったのか、とても参考になりました。コンテンツカテゴリーという新しいアプローチを理解することができ、今後の Web 開発に役立てられると思います。

    また、<span><blockquote>の使用例についても、HTML Living Standard に基づく正しいルールを知ることができ、勉強になりました。特に、Linter を使ってコードの整合性を保つことの重要性も改めて感じました。

    もし今後、さらに深く掘り下げる必要が出てきた際には、またアドバイスをいただけると嬉しいです。

     |  Kuro  |  返信
  31. > もし今後、さらに深く掘り下げる必要が出てきた際には、またアドバイスをいただけると嬉しいです。
    👍️

     |  barrackdo  |  返信
  32. >> MSY-07 さん

    > おかげさまでインデント後の箇条書きの行間が他の行間と統一されて見やすくなりました😄

    やはり、箇条書きが入れ子になった場合は行間が詰まりすぎて読みづらくなってしまいますね。

    行間がそろっているほうが見やすいというのも分かるのですが、ちょっと窮屈に感じたので、ほどよく余白をとるように調整してみました。

     |  Kuro  |  返信
  33. >> Kuroさん

    > やはり、箇条書きが入れ子になった場合は行間が詰まりすぎて読みづらくなってしまいますね。

    確かに行間が詰まり過ぎて読みづらいかもしれませんね。

    > 行間がそろっているほうが見やすいというのも分かるのですが、ちょっと窮屈に感じたので、ほどよく余白をとるように調整してみました。

    修正前は行間が空き過ぎていて不自然でしたが、再修正後は行間が空き過ぎてなくて自然な感じなので良いと思います。

    また、修正前は行末だけ余白が入っていたので不自然でしたが、再修正後は行末だけでなく行頭も余白が入るようになったので、前後のバランスが取れていて良いと思います。

     |  MSY-07  |  返信
  34. ご返信ありがとうございます。

    > また、修正前は行末だけ余白が入っていたので不自然でしたが、再修正後は行末だけでなく行頭も余白が入るようになったので、前後のバランスが取れていて良いと思います。

    別のスレッドで、箇条書きの入れ子を多用してしまったもので、「余白ないときっつきつ!」と思いまして、試しに調整してみましたが、特に問題なさそうとのことで安心しました😮‍💨

     |  Kuro  |  返信
  35. ご返信ありがとうございます。

    > 別のスレッドで、箇条書きの入れ子を多用してしまったもので、「余白ないときっつきつ!」と思いまして、試しに調整してみましたが、特に問題なさそうとのことで安心しました😮‍💨

    別のスレッドとはQuickJSやDelphiに関するちょっとした雑談のことですね。

    私はMeryで生成AIを使ってみる雑談部屋で確認したので、上記のスレッドでも確認してみましたが特に問題ないと思います。

     |  MSY-07  |  返信
スポンサーリンク