テーブルの折返しをさせないようにするために、styleのタグを入れたい

[standard-software]

下記の記事を見ていて、
数値が折り返されるのが非常に見にくいと感じ、直そうと思ったのですが、修正方法がわかりませんでした。

Qiitaで見る技術トレンド推移- Qiita
https://qiita.com/kaku3/items/7865bcab9c24aa134e5f

普通のMarkdownでも表セルの折返し不可能は設定できないみたいで、
styleタグで指定するようですが、Qiitaのmarkdownではstyleタグ埋め込みできないようでしたので
できるようになったらいいのにな、と思って書かせていただきました。

[wataru86]

@standard-software

ご意見ありがとうございます！
直近の開発優先度などから考えると先になってしまうかもしれませんが、折り返しを指定する方法を検討したいと思います！

[Phroneris]

HTML的には <nobr>～</nobr> というタグがあったりはしますが、標準化の予定が無い非推奨要素ですし、あとどのみちQiitaのMarkdownでは無効なタグと見なされて消える（私が今試した限りではそう）ので使えませんしね…。

HTMLの表組みにおいて、左の列が貪欲に幅を確保しすぎて右の列が割を食うというのはまぁ、あるあるですよね。
Markdownを書く側としての防衛策は「長すぎる文字のあるセルは適宜 <br> で手動改行しておく」になるかと思います。
Markdownの改行というと行末にスペースを2つ入れるとかなので、セル内改行は不可能と思われがちですが、今の所QiitaでもGitHubでも <br> のHTML改行タグを直接書けば普通に改行してくれます。

| 1 | 2 | 3 |
|:-:|:-:|:-:|
| 短い文字 | - | - |
| あまりにも<br>長すぎる<br>文字列です | - | - |

1	2	3
短い文字	-	-
あまりにも 長すぎる 文字列です	-	-

ただ当該の記事に限っては、例えば「プロンプトエンジニアリング」の項目を プロンプト<br>エンジニアリング にするとまるで「プロンプト」と「エンジニアリング」の2項目についての行みたいに見えそうですし、かといって プロンプトエン<br>ジニアリング みたいなキリの悪い改行をするのもかなりアレですから、悩ましいですね…。
幸い各項目はQiitaのタグそのものなので、[プロンプト<br>エンジニアリング](https://qiita.com/tags/プロンプトエンジニアリング) のようにキリの良い改行をしつつ全体を一つのタグへのリンクにしてあげると、少なくともマウスを乗せれば単一の項目であることがわかるので多少マシになるかもしれない、と思いました。

でもまぁ、やっぱりこれはどうしても強制改行なので、自然さという点で自動行送りよりは遥かに見劣りしちゃいますね。
style 属性程の自由度は無くとも、今よりもうちょい柔軟に何とかできたら嬉しく思います。

[wataru86]

@Phroneris

ありがとうございます🙏
参考にさせていただきます！

[tanaka-asami415]

@standard-software @Phroneris
長らくお待たせして申し訳ございません。

折り返しを指定する仕様について調査および検討を行いましたが、現時点での実装は難しいという結論に至りました。

styleタグは、過去にユーザーが故意に表示崩れを起こした事があり、現在は制限をしているため
代替案としてテーブルセル内のテキストが折り返さないように
テキストの分だけテーブルを広げスクロールをさせることも検討いたしました。

しかしながら、Qiitaでは多種多様なテーブルの使い方がされており、
すべてのテーブルに対して最適なスクロールとセルの折返しなどを実装することは、現時点では難しいと判断いたしました。
お待たせしたにもかかわらず、今回はご希望に添えず申し訳ありません🙇

引き続きサービス改善に努めますので、ご意見ご要望をお寄せいただけると幸いです🙏

[Phroneris]

@tanaka-asami415 ありがとうございます。うーん残念。
<th> や <td> の直下でのみ <nobr> が使える、みたいにせめて手動で指定できたら嬉しいのですが…

[tanaka-asami415]

@Phroneris
こちらこそいつもありがとうございます。今回はご要望にお応えすることができず申し訳ありません🙏

<th> や <td> の直下でのみ <nobr> が使える、みたいにせめて手動で指定できたら嬉しいのですが…

こちらも検討したのですが、非推奨なタグのため
アクセシビリティ上の問題を引き起こす可能性があり、今回は見送りとさせていただくこととなりました🙇

[Phroneris]

@tanaka-asami415

テーブル記法の直前にプロパティを記述できるようにするというのはどうでしょうか？

例として、次のように書くと：

ここは普通の本文

---
- break:
  - never: R3, C4
  - word: H, C1, R2C4
- align:
  - center: H
---
| cw | cw | cw | cw | cw | cw |
|----|----|----|----|:--:|----|
| w  | .  | .  | n  | c  | .  |
| w  | .  | .  | w  | c  | .  |
| w  | n  | n  | n  | cn | n  |
| w  | .  | .  | n  | c  | .  |

ここは普通の本文

次のような結果になる：

• 2ヶ所ある「ここは普通の本文」の部分は当然普通の本文としてレンダリングされる
• --- ～ --- の数行は直後のテーブルのプロパティとなり、それ自体はレンダリングされない
  • 親属性（break とか）→子属性（never とか）→範囲指定値（R3 とか）という構造を取る
  • 範囲指定値は H[n] でヘッダー（の $n$ 列目）、Rn で $n$ 行目、Cn で $n$ 列目、RnCm で $n$ 行 $m$ 列目を表す
  • 同じセルの中で同じ親属性に属する複数の子属性が競合した場合、後に書いた方で上書きされる（H4、R3C1、R2C4がそう）
  • 異なる親属性は同じセルで共存できる（cw や cn のセルがそう）
• テーブル記法部分はテーブルとしてレンダリングされ、特定の列の行揃えがヘッダー記法部分（:--: とか）の指定に従うだけでなく、更に特定のヘッダー、行、列、セルのスタイルが直前のプロパティに従う
  • n のセルは行送りが white-space: nowrap;（<nobr> 相当）
  • w のセルは行送りが overflow-wrap: break-word;
  • c のセルは行揃えが text-align: center;
  • cw や cn のセルはそれらの組み合わせ
  • . のセルはデフォルトのまま

…みたいな感じです。
これをそのままでとは思っていませんが、概念として伝わればと。

HTMLの <style> タグや style 属性を許す程のフリースタイル遊園地にはさせず、純粋な文字でないリソース（文字画像や数式内文字）や廃止済みのタグによってみだりにアクセシビリティを損なわせることも避け、運営にとってもユーザーにとっても必要なスタイルだけをピックアップできるようにすることを目指せるのではないかと思いました。

align は今回の議題と全く無関係な属性ですみませんが…。
ヘッダーだけ中央揃えにしたいというのは非常に需要のあるスタイルパターンですし、競合の説明としても都合が良いので、ついでに入れちゃいました。
他にも色々な属性が考えられますから、実現すればMarkdown記述サービスではなく記事執筆サービスとして夢が広がると思います。

[tanaka-asami415]

@Phroneris

ご提案ありがとうございます🙏

社内で話し合ったところ、実装工数は多くなりそうですが、不可能ではなさそうです。
実施するかどうかは、今後のメンテナンス負荷や他機能への影響も調査して検討したいと思います。

[debiru]

.it-MdContent {
  font-size: 17px;
  line-height: 1.7;
  overflow-wrap: anywhere;
}

@tanaka-asami415

overflow-wrap: anywhere を指定しているのが悪いのではないですか？

overflow-wrap: break-word に変更した方がよいと思います。anywhere である必要がありますか？

検証用の記事を書きましたが、anywhere をやめるだけでこのスレッドで提示された当該記事のテーブルは見易くなるはずです。

https://qiita.com/debiru/items/8bf93eb48e268dd3d9ab

[tanaka-asami415]

@debiru
ご提案ありがとうございます！

社内で検証してみました。いただいた方法を実装した場合、英単語は改行されにくくなりますが、代わりに日本語の行が狭くなってしまい読みづらくなってしまいます。
そのため、日本語と英語を両方使用しているテーブルが読みづらくなってしまうため、今回ご提案いただいた内容を採用することは難しそうです🙏

[debiru]

@tanaka-asami415

いただいた方法を実装した場合、英単語は改行されにくくなりますが、代わりに日本語の行が狭くなってしまい読みづらくなってしまいます。

それは overflow-wrap: anywhere で解決することなのですか？

そのため、日本語と英語を両方使用しているテーブルが読みづらくなってしまうため、今回ご提案いただいた内容を採用することは難しそうです🙏

overflow-wrap: anywhere を指定しているがためにテーブルが読みづらくなっている現状に対して、break-word の方がマシではないかと提案しているのですが、なぜ anywhere の方が良いと判断されているのでしょうか。どのような議論をされているのかお聞かせ願えませんか。

[tanaka-asami415]

@debiru
ご確認ありがとうございます。以下回答させていただきます🙏

それは overflow-wrap: anywhere で解決することなのですか？

まず前回の返信内容の訂正をさせてください。
「英単語」よりも「分割できない文字列（長い単語やURL）」と表現する方が適切でした。
分かりにくくなってしまい申し訳ありません🙇

以下は、anywhere と break-word の仕様上の違いです。

• anywhere → 分割できない文字列（長い単語やURL）もいい感じに改行してくれる
• break-word → 分割できない文字列（長い単語やURL）は改行されない

そのため、分割できない文字列（長い単語やURL）がテーブルにある場合に、他のセルが狭くなってしまい読みづらくなってしまう事は防ぐことが可能です。

overflow-wrap: anywhere を指定しているがためにテーブルが読みづらくなっている現状に対して、break-word の方がマシではないかと提案しているのですが、なぜ anywhere の方が良いと判断されているのでしょうか。どのような議論をされているのかお聞かせ願えませんか。

以下は、anywhere と break-word の見た目上の違いです。

• anywhere → 列ごとを比べて、セル内の要素に合わせて、セルの横幅を決めている
• break-word → 分割できない文字列があるセルの横幅が広くなる

分割できる文字列（英文 , 日本語）だけでテーブルが作られている時は、anywhere と break-word はほぼ同じ見た目になりますが、分割できない文字列（長い単語やURL）がテーブルにある時は、テーブルが縦に長くなります。

詳細はこちらの画像でご確認いただけると幸いです🙏

英数字のみで作られるテーブル	日本語のみで作られるテーブル	英数字と日本語で作られるテーブル	数式が入るテーブル

Qiitaの記事では分割できない文字列（長い単語やURL）が挿入されることを考慮し、こちらの画像のようなテーブルをもとに議論しています。
その結果、記事全体の読みやすさを考えると、テーブルが縦に長くなるより、適切なところで折り返される方がいいと判断しました。

以上のことが anywhere の方が良いと判断した背景となります🙇

[debiru]

@tanaka-asami415

詳細に検討内容を開示くださりありがとうございます。

Qiita さんが本件についてどのように判断されているのかが分かりました。これは他のサービスでも同様の問題に対処する際に参考になる貴重な情報だと思います。私にとっても参考になりました。

本ディスカッションで最初に提示されているようなページのテーブルが見づらくなっている問題について、Qiita さんの検討内容を踏まえた上で改善する方法を提示することができず恐縮です。この問題はそもそも table-layout: auto であるテーブル要素というもののレンダリングがどうされるべきかというブラウザ側の問題でもあるとは思います。そのため CSS でこの値を指定すれば解決できるという代物ではないものでもあります（少なくとも現状では）。

anywhere 指定によって改善される部分を残したまま anywhere によって生じる問題を回避する方法を提示することができれば良いのですが、残念ながら現時点では方法を思い付きませんでした。

このコメントは更なる提案や指摘をするものではありませんが、Qiita さんの判断を尊重している（検討されたのであれば現状のままでよいと考えている）ということを示しておきます。

[tanaka-asami415]

@debiru
ご確認とご理解をいただき、ありがとうございます。
詳細をお伝えすることで、他の方からも新たなご提案を頂けるのではないかと考えております。

引き続き何かあれば、教えていただけるとありがたいです🙇

[tsubolabo]

下記の投稿の方法で解決できそうですが、運営殿としてはどのようにお考えですか？

Qiitaでテーブルの内容を折り返さずにスクロール表示する方法

[tsubolabo]

tanaka-asami415

お伝えの仕方により、御気分を害してしまい申し訳ないです。

貴方の回答の仕方が原因ではありません。ご心配なく。
正体不明・意味不明の意見表明もないマークが引き金です。貴方はお気の毒な巻き添えです。

多くの表示環境、将来への持続性などを考慮すれば、今回のような回答になることはやむを得ないこととは思っておりました。しかし、不自然な折り返しテーブルの見難さを我慢することにした訳ではありません。

[tanaka-asami415]

@tsubolabo

多くの表示環境、将来への持続性などを考慮すれば、今回のような回答になることはやむを得ないこととは思っておりました。

ご理解いただきありがとうございます🙇

また、リアクション（マーク）での反応は、インターネット全般、あるいはGitHub上においては、普及しているコミュニケーション方法です。
リアクションだけの反応に関して、他の方への苦情等を表現することはお控えいただけると幸いです。

[tsubolabo]

不可解なリアクションに対し、真意を問うのは当然の行為です。

[Phroneris]

@tsubolabo

投稿記事が1件以上あるユーザーとして口を出させていただきますが、ご提示なさった方法は私はかなり良くないと思います。
LaTeX芸・Markdown芸みたいなネタとしては興味深いので私はあちらで協力的なコメントを書き込みましたが、さすがにシラフで選択肢に入れるべき代物にはなり得ません…。
まぁ、その辺りは多少なり既にご理解されているようですけど。

ところで、「ハック」に対して「ハッカー」と反応なさっていますが、ハックという言葉についてちょっと誤解なさっていませんか？
こういう場合のハックというのは「用途外のツールや意外な方法で目的を達成する」みたいな意味でしょう。
「ライフハック」とか聞いたことありませんか？ 別の表現で「ワークアラウンド」とか「裏技」とか言ったら通じるでしょうか。
要するに正道とするにははばかられる抜け道に過ぎないということであって、決して犯罪者や不届き者のように扱っている訳ではないと思いますよ。
後者のような連中のことはハッカーよりクラッカーという方が当てはまりますしね。

最後に、このツリーが長引くきっかけとなったらしいリアクションの機能や文化についてですが、

この種の回答に thumb up マークが付けば、提言者・質問者としては、「拒否されていい気味だ！」というメッセージとしか受けとれません。

この考えはマジでやめた方が良いですよ…。
👍 等の肯定的な絵文字リアクションは、1次的な意味としては単に「その投稿（の少なくとも一部）は良いね」だけです。
「メンション先の対立意見は悪いね」のような解釈はあくまで2次的な類推、ましてや「拒否されていい気味だ！」なんて悪意を見出すのは妄想にも似た邪推の域です。
まぁもし自分の投稿に軒並み 👎 が付けられたり、逆に相手方に100個ぐらい 👍 が付いて自分にはゼロだったりしたらさすがに悪意も紛れている気はしてきますが、今回のケースのように相手方が1個 👍 されただけで大騒ぎというのは行動力がありすぎます。
@tsubolabo さんが常にそういうメッセージとしてしか受け取れないなら、たとえそれがコミュニティのためを思ってのことだとしても既にコミュニティの相場感からは乖離してしまっており、お気の毒です。
どうかもう少し善意を期待する、というか悪意を前提とはしないニュートラルめの視点で取り組まれることをお勧めします。

[tsubolabo]

@Phroneris

貴重なコメントをありがとうございました。一つのご意見として拝読しましたが、私の前言を取り消したり修正したりするような意識の変化はありませんでした。また、妄想や邪推とも思っておりません。単刀直入な物言いがお気に召さなかったかもしれませんが、美辞麗句ばかりでは十分な Discussion にはなりません。素直でなくて申し訳ありません。

ご提示なさった方法は私はかなり良くないと思います。・・・中略・・・　さすがにシラフで選択肢に入れるべき代物にはなり得ません…。

あなたの解釈は分かりました。しかし、「いいね」が７個、「ストック」が６個と、かなりの支持を得ています。

ハックという言葉についてちょっと誤解なさっていませんか？

二つの受け取り方があります。否定的な文脈の中で使われた場合には私のような解釈が自然でしょう。