Help‐ノート:セクション/過去ログ1

「＝＝＝」の見出しに向けてのリンク

「節リンク」についてですが、深さ２段目の「＝＝＝」の見出しに向けてページ内リンクを貼れますか？「＝＝」の見出しへは「〜＃〜｜〜」（もちろん記号は半角）といった書式があるのですが、試しに「〜＃〜＃〜｜〜」という書式を試したところ働かないようです。兎山帰郎 2006年7月16日 (日) 19:33 (UTC)

===＠＠＠===という見出しへのリンクは、「〜＃〜＃＠＠＠｜＠＠＠」では働きませんが、「〜＃＠＠＠｜＠＠＠」とするとうまくいきます。例えば、Wikipedia:中立的な観点の「2.3 フェアであることと、好意的な立場」へのリンクは、Wikipedia:中立的な観点#フェアであることと、好意的な立場となります。--Sloop25 2006年7月16日 (日) 20:32 (UTC)

節の名称の付け方について

現在、蒿里山という項目の節の名称が、

1. 蒿里山の場所について
2. 蒿里山の信仰の形成
3. 蒿里山の歴史と文化
4. 蒿里山にあった建物について
5. 蒿里山の破壊について
6. 現在の蒿里山
7. フィクションに登場する蒿里山

という風に付けられています。私は項目のタイトルが「蒿里山」という名称である以上節の名称にいちいち「蒿里山の」と付ける必要は無いと思うのですが、かつて別の項目で節の名前にいちいち「○○の」と付けられているのをとる編集をしたときに、

• ガイドラインには「○○の」と付けてはいけない。または「○○の」と付けない方がいいといった記述はどこにもない。
• 「○○の」といった記述を付けておいた方が読者に対して親切である。

という理由で差し戻されました。確かにWikipedia:節を見ても節の名称について決まり事らしいものは何も無いのですが、それ以外の文書にも節の名称の付け方についての決まり事は無いのでしょうか。--61.46.105.214 2006年11月18日 (土) 18:15 (UTC)

とりあえず外してしまいました。記事冒頭で記事についての定義を述べており節の名前にいちいち記事名を入れなくても何に対して述べているのかは自明です。また、他の記事では入れてませんし。たね 2006年11月18日 (土) 18:27 (UTC)

たね さん、各節名の「藁里山」を外す事には、私も賛成なのですが、いま議論が始まったばかりで、これからいろんな意見が出ようとする前に外してしまうのは如何なものかと存じます。度々やっておられるのでしょうか。度々やっていられるとしたら、独断と偏見を強くお持ちの方のように思われますよ。また、要約欄には何も書かれておりませんが、少しぐらいの説明があってもいいかと存じます。これは、私個人の意見ですので、お気に召さぬようでしたら、ここを消去して頂いてもかまいません。--Namuami 2006年11月19日 (日) 03:43 (UTC)

今まで読んできた本の百科事典（主に電気系）などでこういった項目名を節毎に記述をしているのは見たことが無いですね。これはWikipediaのガイドラインがどうこうという以前に一般的な記述法の問題ではないでしょうか?（一般的な記述法:私の主観ですが…）それに、「○○の」といった記述を付けておいた方が読者に対して親切である。 というのは、何かおかしい気がしますねぇ（当然主観ですが）。さすがに、「○○の」が付いていないと理解できない読者とはいないでしょうし…。唯一付けるとしたら、7.のような「フィクションにおける○○」程度では?--Takuan-Osyou 2006年11月19日 (日) 12:18 (UTC)

読者はそこまで馬鹿ではない。他国語版でも見かけないし外して良いんじゃないか。--Luilz 2006年11月20日 (月) 10:55 (UTC)

全部に書けとは言いませんが、節の名前だけでは内容が分かりにくい場合は、各節の出だしの文として「蒿里山の～について説明する」「～は以下の通りである」というような断り書きを書くという方法もあります。--草薙 2006年11月20日 (月) 14:46 (UTC)

蒿里山の事例を見る限り、確かに冗長だと思いますが、「蒿里山の」を外すと言う編集を早急に行うには3つの理由で躊躇します。

1. 他のページから、節に向かってリンクが張られている可能性がある。（ex. 蒿里山#蒿里山の歴史と文化）
2. 1. を 特別/whatlinkshere/云々 の様な形で簡単に検証できない。（検索を駆使すれば出来そうですが）
3. 1. を解消する（ページ名の移動に対するリダイレクトの様な）方法がない。

という観点から、この様なケースに限らず節の名前を変えるのは若干の慎重さが必要だと思います（こんな用途の　Bot があるかもしれませんが...）、もちろん新しく記事を書くときには、冗長でない名前を選ぶべきだという意見に賛成です。--Ef3 2006年11月21日 (火) 10:12 (UTC)

存在しない節にリンクが貼られた場合、その節がある項目が普通に表示されるだけ（蒿里山のページに移動するだけ）ですから、別に大きな問題はないと思います。それにリンク元のページを一つ一つ見ていけば、節まで指定してリンクしている箇所を探し出せます。リンク元を見てみると、標準名前空間のページは2つしかなかったので見てみたところ、どちらも節指定のリンクは使っていませんでした。--草薙 2006年11月21日 (火) 10:44 (UTC)

節の改名によるリンク切れの対策方法を考えてみました。<a name="旧節名" style="display:none;">旧節名</a> の要領で、改名した節の見出しの近くに見えない節アンカーを置けば概ね問題なさそうです。（頻出するなら　Template 化しますが、多分レアケースでしょう）

ところで、節指定のリンクは、マイナー and/or 推奨されない手法ですか？私は、結構使っているのですが（「本文参照」の様なローカルなリンクが多いですが）。 --Ef3 2006年11月21日 (火) 14:18 (UTC)

（追記）微妙だけど有意な節改名の弊害ありました。その項目の履歴の、編集された節へのリンク(/* 節 */で付く奴)がリンク切れしますね。大きな支障はないと思いますが、このケースも↑で救済できます。--Ef3 2006年11月21日 (火) 14:27 (UTC)

最初の節以前編集機能を

MediaWiki向きの要望かもしれませんが、よくわからないため、ひとまずこちらに投稿します。最初の節以前に節編集機能が利用できないのは歯痒いことです、何とかならないでしょうか。Imo758 2007年6月30日 (土) 22:51 (UTC)

機能はあります。リンクがないだけです。たとえば最初の節編集の URL は section=1 を含みますが、最初の節以前編集の URL は同様に section=0 を含みます。したがって、最初の節編集をクリックしてからブラウザの URL 欄末尾の 1 を 0 に書き換えて Enter キーを押せば最初の節以前を編集できます。あるいは、最初の節編集リンクの URL を「コピー」　（IE ならリンクを右クリックして "T"） してブラウザの URL 欄に「ペースト」しても OK です。 --Kanjy 2007年6月30日 (土) 23:06 (UTC)

とても参考になりました、ありがとうございます。Imo758 2007年6月30日 (土) 23:13 (UTC)

section=newによって生成される節とスタイルマニュアルの齟齬

スタイルマニュアルには、

==を用いる際は見出しの下に空行は必要ないことに注意して下さい。空行は取り除いて下さい。

と定められていますが、本Helpに従い、「&section=new」や、「+」タブ等を使って新しい節を生成すると、==と節の本文との間に空行が生じてしまいます。例(「+」タブを押して出てくるフォームのテキストエリア(id="wpTextbox1")の冒頭に「↑↑↑↑↑↑」の６文字だけをペーストして新しい節を生成したものです。)

本Helpに従って作られた節から、==下の空行を取り除く「細部の編集」をわざわざなさる方もおられるようです。この齟齬をどのように理解すればよろしいのでしょうか？ --鷹揚虚空 2007年11月8日 (木) 03:03 (UTC)

見出しに脚注をつけるスタイルについて

セクション全体に対して出典等の脚注をつける場合に、セクションの見出し部分に

== ○○○<ref>×××</ref> ==

のように脚注タグをつけている例がいくつか見られるのですが、こうすると目次が作成された際に

1 ○○○[1]

のように脚注まで表示されてしまい（誘導はされない）、見映えが悪くなっています。このような方法はあまり推奨されないかと思うのですが、どうでしょうか?--ウース（会話） 2017年3月18日 (土) 07:03 (UTC)

そのように使用されている例は見たことないのですが、どのような場合に使われるのでしょうか。できれば使用されているページをご教示ください。

• 見出しではなく節冒頭に見出しと同じ内容のことを書いて脚注で明示する

ぐらいしか解決法が思いつきませんでした。お力になれず申し訳ない--Yuukin0248（会話） 2017年5月24日 (水) 07:30 (UTC)

スタイルマニュアルはWikipedia:スタイルマニュアル (見出し)にあり、そのような方法は推奨されていません。ヘルプの冒頭でその文書への案内を行っておきました。--タバコはマーダー（会話） 2017年5月26日 (金) 03:27 (UTC)

コメント - Wikipedia:スタイルマニュアル (見出し)（Wikipedia‐ノート:スタイルマニュアル (見出し)#見出し内への<ref>使用禁止の提案）にある通り、標準名前空間では節に内部リンクや脚注を付けるのは避けるべきです（WP:MSH#NOLINK。問題の本質から言えば画像アイコンなども同様）。私は見かけ次第除去（脚注内容は本文に移設）しています。--ButuCC+Mtp 2017年5月26日 (金) 12:38 (UTC)

節名（見出し）に全角スペースを用いて表示位置調整をしてよいのか

本件、IP氏が武谷三男の編集（[1]、[2]）において、節名に全角スペースを用いているのに気がつきました。（おそらく目次の見栄えを狙っている？）

このような全角スペースの使い方は「Wikipedia:スタイルマニュアル (見出し)」、「Help:セクション」などのガイドライン、ヘルプには記載がありませんでした。（見落としているのかもしれません）

また、この点については「表記ガイド#空白」が適用されるのでは、と思いますが書き方が見出しを想定していないようです。

私は、表記ガイドが優先し、節名（見出し）もそれに適用されるという考えですが、それで構わないでしょうか。皆様のご意見をお伺いしたく。また、表記ガイドが優先するということであれば、ひと言「Wikipedia:スタイルマニュアル (見出し)」ないしは「Help:セクション」にも記載しておくべきではないでしょうか。

--みそがい（会話） 2018年6月5日 (火) 12:33 (UTC)

ご指摘の通り、表記ガイドが適用されるでしょう。自分の環境ではうまく再現できてもコンピュータは意味を読み取りませんし、小画面では大画面に比べて空白部分が大きな割合を占めるのでよくないと思いますね。取り去ればいいのでは。

スタイルマニュアル (見出し)への、記載の追加の提案を行ってみてください。--タバコはマーダー（会話） 2018年6月7日 (木) 00:28 (UTC)

コメントありがとうございます。よくよく記事を見てみると、節タイトル自体の表示位置を本文中で変更するための意図もあるようです。これでは他の記事との整合もとれませんので、記載追加の提案を行ってみます。--みそがい（会話） 2018年6月7日 (木) 10:47 (UTC)

目次について

目次の見出し数が多い記事を見ていてふと思ったのですが、目次を「コンパクトな目次」のように横へ並べるのではなく、脚注における{{reflist|2}}のように因数を指定することで、2列表示にすることはできないのでしょうか。目次の見出し数が多い記事をそれなりに広い横幅の環境で見る際には、役立ちそうな気がします。--220.213.90.71 2018年6月29日 (金) 04:38 (UTC)

目次に反映される見出しレベルを制限する書き方がどこかにありますよ。目次は非表示にできますし、執筆者の方で工夫するのは、統一性がなくなり、閲覧環境の違いによって例えば狭い環境でぐちゃぐちゃになるとか考えられますので、推奨できる方法ではないと思います。--タバコはマーダー（会話） 2018年6月29日 (金) 10:39 (UTC)

目次の左右寄せOK基準の追記改定

「英語版のHelp:Section」を読むと、一定の基準を守っていれば {{TOC right}} などを使って目次を右寄せ・左寄せするのはOKとなっています。現に英語版では {{TOC right}} が3万ページ以上で利用されています。ところが日本語版では「曖昧さ回避ページで使うと有用かも知れません。記事のページでの濫用は慎しまれます」({{TOC right}}の解説文より) と書かれてあり、標準名前空間で使用されているのは500ページ以下です。「濫用は慎め」との文言は、特にノートページでの合意形成はなく、2012年に追加されています (編集差分)。そこで、英語版のヘルプで規定されている基準を日本語版に移入した上で、TOC rightを正しく使って頂けるよう (つまり必要以上に慎むことがないよう)、改定したいのですがご意見お願いします。

• 参考1: 目次デフォルトバージョン と 目次右寄せバージョン の違い (「著作権法 (アメリカ合衆国)」の例)
• 参考2: 英語版ルールを適用してもなおTOC rightの使用が不適切であろうと思われるページ (「グレートオブザバトリー計画」の例)
• 参考3: TOC rightの使い方に関する2007年当時の議論1 (このテンプレートの使用について)
• 参考4: TOC rightの使い方に関する2007年当時の議論2 (このテンプレートの目的)

英語版ヘルプの7基準と日本語改定案の8基準

英語版ヘルプの抜粋 (at 19:19, 14 May 2019 (UTC) 継承)と翻訳案です。最終更新者・更新日: ProfessorPine（会話） 2019年6月16日 (日) 09:00 (UTC)。

Floating the TOC

目次の配置変更

The TOC can, in some instances, be floated either right or left using {{TOC right}} or {{TOC left}} when it is beneficial to the layout of the article, or when the default TOC gets in the way of other elements. Before changing the default TOC to a floated TOC, consider the following guidelines:

自動生成されるデフォルトの目次は、段組み表示や回り込みがされないことから、長い目次だと導入節とそれ以降の本文が大きく分断してしまい、文脈がつかみづらくなる恐れがあります。また、目次のそばに画像やInfoboxなどがあるとレイアウトが崩れることがあります。このような場合には、目次の右寄せ {{TOC right}} または左寄せ {{TOC left}} を使用することで目次配置の問題を回避できます。ただし、配置変更の前には以下の基準を必ず考慮して下さい。なお、モバイル版では目次配置の差異は起こりませんので、検証にはデスクトップビューを用いて下さい。

1. If floating the TOC, it should be placed at the end of the lead section of the text, before the first section heading. Users of screen readers do not expect any text between the TOC and the first heading, and having no text above the TOC is confusing. See the last line in the information about elements of the lead section. / 右寄せまたは左寄せを用いる場合であっても、導入節末尾の直後 (つまりデフォルトの目次表示と同じ場所) に置きます。これは、視覚障害者などを支援する画面読み上げソフトウェア (スクリーンリーダー) を配慮する必要があるためです。配置を誤ると、スクリーンリーダー利用者には文脈がつかめなくなり、混乱します。導入節に関する詳細は「Wikipedia:スタイルマニュアル (導入部)」も参照して下さい。
2. When floating a TOC, check whether the page layout will be harmed if the TOC is hidden by the user. / 読者が任意で目次を非表示にするケースも想定して、右寄せまたは左寄せの目次を非表示にしても画面レイアウトが崩れないか検証して下さい。
3. Long lists may create very long TOCs. The TOC should not be longer than necessary, whether it is floated or not. {{TOC limit}} can be used to reduce the length of the TOC by hiding nested subsections, rather than a floating TOC. / デフォルトであれ右寄せ・左寄せであれ、目次が不必要に長くなりすぎていないか注意して下さい。右寄せ・左寄せの代わりに{{TOC limit}}を使うことで、表示される目次の深さ (見出しレベル) をコントロールし、目次全体を短くする方法も比較検討して下さい。また、{{TOC right|limit=4}}のように記述すると、右寄せと目次の深さ指定を組み合わせて使用することもできます。
4. (英語版に無い新規箇条書き) / 目次が数項目と短いにもかかわらず、無理に目次を右寄せ・左寄せするとレイアウトが崩れることがあります。右寄せ・左寄せを使用している他言語版記事を基に日本語ページ作成しようとして、途中の節までしか翻訳せず書きかけのままにすると、このようなレイアウト崩れが発生することがあります。
5. The default TOC is placed before the first headline, but after any introductory text. If the introductory summary is long enough that a typical user has to scroll down to see the top of the TOC, you may float the TOC so it appears closer to the top of the article. However, the floating TOC should in most cases follow at least the first paragraph of article text. / 導入節と、それに続く概説などの節に連続性がある場合、長めの目次が中間に挿入されると文脈が分断されてしまいます。このような場合、{{TOC right}}または{{TOC left}}を用いて回り込みを効かせれば、可読性が上がることが期待されます。ただし目次の右寄せ・左寄せはデフォルトと同じく、導入節末尾の直後以外の場所に配置してはなりません。
6. Floating a wide TOC will produce a narrow column of readable text for users with low resolutions. If the TOC's width exceeds 30% of the user's visible screen (about twice the size of the Wikipedia navigation bar to the left), then it is not suitable for floating. (Percentages assume a typical user setup.) If text is trapped between a floating TOC and an image, floating can be cancelled at a certain text point, see Forcing a break. / 右寄せ・左寄せの目次はそのままでは自動改行されません。目次の横幅が長くなって導入節を圧迫する場合は、目次の横幅を30%以下に指定することができます。{{TOC right|width=30%}}のように記述できます。横幅指定には{{TOC right|width=20em}}のような記述方法もできますが (参考: 英語版での使用例)、ブラウザの文字サイズを閲覧者が拡大すると目次の横幅が広がるため注意が必要です。標準的なデスクトップビューの閲覧者の環境で、右寄せ・左寄せした目次が本文全体の1/3を越えないよう、確認しながら横幅を指定する必要があります。また導入節付近に画像が既にあり、目次を右寄せ・左寄せすることでレイアウト全体が崩れる場合、目次はデフォルトに戻さなければなりません。詳細は「Help:画像の表示#回り込みの解除」も参照して下さい。
7. If the TOC is placed in the general vicinity of other floated images or boxes, it can be floated as long as the flowing text column does not become narrower than 30% of the average user's visible screen width. / 逆にデフォルト表示の目次近辺に画像やInfoboxなどが配置され、導入節の可読性が損なわれている場合は、目次を横幅30%以下に調整した上で右寄せ・左寄せにすることができます。
8. A left-floated TOC may affect bulleted or numbered lists. / 左寄せの目次を使用すると、丸印または番号付きの箇条書きに影響することがあります。

Template:TOC right was proposed for deletion in early July 2005, but there was no consensus on the matter. The archive of the discussion and voting regarding this may be seen at Wikipedia:Templates for deletion/TOCright. The Manual of Style discussion can be found here.

英語版では {{TOC right}} の削除が2005年7月上旬に提案されましたが、否決されています。また日本語版でも右寄せの目的や利用シーンについて2007年に議論されています。過去の議論も参照して下さい (参考: 英語版議論、日本語版議論1、日本語版議論2)。

配置変更の例

• ロータス・セブンの英語版 - {{TOC left}}とInfoboxを併用している良い例 と デフォルト目次表示ではレイアウトが崩れてしまう悪い例。
• 著作権法 (アメリカ合衆国) の日本語版 - 目次が長いため、{{TOC right}}を用いている良い例 と デフォルト目次表示では文脈が分断してしまう悪い例。
• 欧州議会選挙区の日英版 - {{TOC left}}を用いるのに適切な文章量の良い例 (英語版) と 翻訳途中で不適切な悪い例 (日本語版)。日本語版でブラウザの文字サイズを拡大すると導入節が崩れます。

コメント記入欄

• 改定の提案者として賛成票。なお、この手のルール改定提案は初めてなので、不手際ありましたら忌憚なくご指摘下さい。これよりWikipedia:コメント依頼や関連連プレートのノートにも議論告知してみようと思います。--ProfessorPine（会話） 2019年5月27日 (月) 13:26 (UTC)

• これは「右寄せ」「左寄せ」というよりは、回り込みを認めるかどうか、というところが焦点になるような気がします。
• レイアウトは悩ましいですね。結局、各利用者の閲覧環境次第なので。--柒月例祭（会話） 2019年5月28日 (火) 02:45 (UTC)

柒月例祭さんから頂いたキーワード「回り込み」と「閲覧環境」で頭の中がスッキリしました。少し改定案の文面をいじった方が議論が前に進みそうなので、1～2日ほど修正作業の時間を下さい。--ProfessorPine（会話） 2019年5月28日 (火) 13:16 (UTC)

報告 加筆修正しましたので「差分」をご確認下さい。英語版にはない基準を1つ追加したので、日本語改定案は8基準に増えています。ご意見よろしくお願いします。--ProfessorPine（会話） 2019年5月31日 (金) 04:02 (UTC)

• 素朴にメリットがよくわからないのですが。
• (ア)「自動生成されるデフォルトの目次は、段組み表示や回り込みがされないことから、長い目次だと画面をスクロールしないと目次全体がつかめなかったり、目次のそばに画像などがあるとレイアウトが崩れることがあります。このような場合には、目次の右寄せ {{TOC right}} または左寄せ {{TOC left}} を使用することで目次配置の問題を回避できます。」とのことですが、右寄せしようが左寄せしようが、長い目次は長い目次のままなので、「長い目次だと画面をスクロールしないと目次全体がつかめない」デメリットが解消されるわけではないのでは？
• (イ)また、「目次のそばに画像などがあるとレイアウトが崩れる」パターンというのはどんなパターンのときなんでしょうか。
• (ウ)「導入節が長めのページの場合、画面をスクロールしないと目次が表示されなくなります。このような場合、{{TOC right}}または{{TOC left}}を用いて回り込みを効かせれば、可読性が上がることが期待されます。ただし目次の右寄せ・左寄せはデフォルトと同じく、導入節末尾の直後以外の場所に配置してはなりません。」とのことですが、導入節末尾に置くと決められているならば、{{TOC right}}または{{TOC left}}を使っても目次が現れるのは結局は導入節後であり、「導入節が長めのページの場合、画面をスクロールしないと目次が表示されない」デメリットはとくに解消されないのでは？--Yapparina（会話） 2019年6月5日 (水) 13:40 (UTC)、後続参照のため、(ア) (イ) (ウ) を挿入。--ProfessorPine（会話） 2019年6月16日 (日) 09:07 (UTC)

• @Yapparinaさん: コメント頂きありがとうございます。別件の処理と時期的に重複してしまい、お返事滞ってしまい申し訳ありません。日本時間で今週水曜中には回答できるよう善処いたします。--ProfessorPine（会話） 2019年6月10日 (月) 05:46 (UTC)

• Yapparinaさん、返信が遅くなってすみません。3点ご指摘ありがとうございます。ご指摘の通り、詰めが甘かったです。(ア) と (ウ) については以下のとおり文面を修正しました。(イ) は修正なしですが、メリットが分かりづらいとのことなので、具体的な良い例・悪い例を切り出して提示しました。ご確認のほどよろしくお願いします (編集差分)。--ProfessorPine（会話） 2019年6月16日 (日) 09:07 (UTC)

(ア) に対応して -- 8基準箇条書きの前文修正

• 旧: 「自動生成されるデフォルトの目次は、段組み表示や回り込みがされないことから、長い目次だと画面をスクロールしないと目次全体がつかめなかったり、目次のそばに画像などがあるとレイアウトが崩れることがあります。」
• 新: 「自動生成されるデフォルトの目次は、段組み表示や回り込みがされないことから、長い目次だと導入節とそれ以降の本文が大きく分断してしまい、文脈がつかみづらくなる恐れがあります。また、目次のそばに画像やInfoboxなどがあるとレイアウトが崩れることがあります。」

(ウ) に対応して -- 考慮点5点目を修正

• 旧: 「導入節が長めのページの場合、画面をスクロールしないと目次が表示されなくなります。このような場合、{{TOC right}}または{{TOC left}}を用いて回り込みを効かせれば、可読性が上がることが期待されます。」
• 新: 「導入節と、それに続く概説などの節に連続性がある場合、長めの目次が中間に挿入されると文脈が分断されてしまいます。このような場合、{{TOC right}}または{{TOC left}}を用いて回り込みを効かせれば、可読性が上がることが期待されます。」

意見の反映ありがとうございます。しかし、正直、デフォルト表示よりもメリットがデメリットを上回るとはあまり感じません。

良い例として挙げれているロータス・セブンですが、{{Clear}}を使ってるのがTOC leftを使わないと表示がおかしくなる原因なのではないでしょうか？　少なくともこの記事に限っていえば、別にClearを使う必要はそもそもないように思います。他の記事では、その箇所でどうしてもClearを使う必要がある状況はあるかもしれないので、このパターンでTOC leftを使うのは理解はできます。しかしその場合もテンプレートが長大過ぎないか画像を置き過ぎていないかなどの検討が先だと思います。

もう一つ良い例として挙げれている著作権法 (アメリカ合衆国)ですが、私にはTOC rightを使ったバージョンが特に優れているようには感じませんでした。導入部は全体をほわっとまとめる話をして、記事本体では各論がそれぞれ始まるので、目次による「文脈の分断」というものを感じていません。結局のところ、好みの問題のように思います。

私がTOC rightを使ったバージョンを好まない理由を言葉で説明してみると

1. 左側に記事本部、右側に目次というように、異なる内容の2つの文字情報が同時に画面に表示され、情報過多な表示になって、意識が分散しがちで記事が読みづらい。この点が、背景的に捉えることができ、意識の中で本文と分けることができる画像の掲示とは異なる。
2. 目次は記事全体の地図を示す極めて重要な部分なので、本文の隣に供え物的に示すようなものではないという考えが私の中にある。初めて記事を読む人は、自分が知りたい情報がどの辺にあるのか目次を見る（はず、少なくとも私は）。何回もその記事を訪れている人とか、目次をくどく思う人もいるかもしれないが、そういう人が居たとしてもお節介でも基本的に導入部と本体の間を割って目次をしっかり示さなくては駄目だ、と考えている。
3. 画像もそうだけど、回り込み表示は何かと記事レイアウトを壊しやすい。ある環境（モニターサイズ、ウィンドウサイズ、文字倍率）では良いバランスでも、少し違う環境だと見苦しい表示になりがち。回り込み表示の使用は極力避けたい。

長大な目次になった場合でも、TOC limitで===レベル表示までにするぐらいでまあまあのサイズに収まるとと思います。TOC rightで右寄せ・回り込みよりも、そっちの解決策の方が好ましいと私は考えます。あと、英語版でTOC right使用の3万ページというのはほとんど曖昧さ回避ページで、日本語版と使用実態はそんなに変わらないように思いますが……。--Yapparina（会話） 2019年6月23日 (日) 11:51 (UTC)

• 私の利用者ページのノートにて、（「著作権法 (アメリカ合衆国)」の編集に際し、私が素人の一読者から見ての可読性問題を軸足にコメントを数回付けた経緯から、）一読者として目次の置き場所の可読性をどう感じるか、というご趣旨の質問を@ProfessorPineさんから頂戴したので以下にコメントを書きます。
  (比較: 右寄せ前のデフォルト版 （左寄せ版）と 右寄せ後の版)を（詳細にではなく）一目で見た印象では個人的には右寄せが見やすい（個人の好みの問題）に思えました。それはウィキソースへの導線やその他の図版とレイアウト的な導線が揃っているからでしょう。
  さて、それでは…と、モバイル画面に切り替えてみてみましたら、目次が伸び縮みするような機能になっているのですね。これなら、左寄せだろうと、右寄せだろうと、さして変わりません。
  次にスクリーンリーダーへの対応などウェブアクセシビリティのこと。最新規格はISO規格と合致したJIS X 8341-3:2016でしょうが、これはhtmlのパージョンが上がるたびに＜ｎａｖ＞その他、色々なタグも定義されてきていますし、調査ツールも古くはIBM（後にApache財団に寄贈）のものや富士通が力を入れていた時期があって、各種ツールを公開していました。最近だとGPLのNVDA日本語版というツールあたりが便利かもしれません。しかしいずれにしてもwikipedia全体の問題だと思います。本件だけにスコープを絞れるような問題ではないのでこれ以上の言及は避けます。
  既に議論の当初より、回り込みができないという技術的制約が問題なんだ、というのは明らかにされているので「目次を左に置くのではなく右の置くのは可か？」という議論ではなく「目次を左に置いたときでも、文字列の回り込みをする追加オプションスイッチを増補して欲しい」というような技術に関する議論を（ここではなく）テクニカル関係のしかるべき所で立てた方が良かったのかもしれません。
  これも技術的制約の議題なので本筋からはずれますが、｛｛TOC limit｝｝でレベル3までに留めることにしたとして。本文中の各レベル3の直後にレベル4の目次を掲げる場合、冒頭の目次では「2.4 著作物の利用と著作権侵害」まで見えても「2.4.1 フェアユース (総論)」が存在しないので重要キーワードである「フェアユース」への見通しが付かなくなるのは痛し痒しですね。冒頭の目次でレベル3をクリックするとレベル4以下が伸張して見えるようにするハックとかあればいいのでしょうか（私はあれこれクリックせずともザッと全体を見渡せる方が好きですが）。
  結局、WikipediaのUIがレガシーに絡め取られてしまっているので仕方ないのでしょう。後発の中国のbaiduがやっている百度百科だと上部目次は横幅一杯の表示ですが2段階目までと階層が少なく、少し不満が残りそうです。しかし、右メニューでフロートし、項目の移動で今見ている章立てがどこかもビジュアルで確認できるように付いてきたり、ップに戻るボタンも右にフロート表示されるなど、UIが洗練されている部分もあります。SMAPの例：ttps://baike.baidu.com/item/SMAP/9502
  @Yapparinaさん が（斜体は私による）〈導入部は全体をほわっとまとめる話をして、記事本体では各論がそれぞれ始まるので、目次による「文脈の分断」というものを感じていません。結局のところ、好みの問題のように思います。〉とお書きになっていますが、これは私が@ProfessorPineさんに、編集には参加しないくせに素人ながら口うるさいほどにあれこれと注文を付け、それをProfessorPineさんが丁寧に受け止め、ご苦心にご苦心を重ねて実現して下さったからこそ、（Yapparinaさんを含めて）「著作権法 (アメリカ合衆国)」の編集経過には特段に参加していなかった方々に違和感を感じさせないように仕上がったのだと存じます。Yapparinaさんのご感想は、不自然に感じさせないように編集した編集者、すなわちProfessorPineさんの苦心が目的を果たし、狙い通りの効果をもたらしたことを逆照射しているということだと思います。
  最期に私の考えを書きます。「著作権法 (アメリカ合衆国)」単独で見た場合、目次の位置は、（私の好みは）右寄せなのですが、例えばそこから「ベルヌ条約」へジャンプしたら、多くの項目の目次は左寄せなので、視覚的導線があっちこっちに惑わされますね？ 全体で百科事典扱いになっている編集著作物では、こういうイリーガル処理は、なるべく避けたいと思われるかもしれないなぁと存じました。商業印刷出版物の編集者だったら、せっかく版面設計したのに！と、必ずツッコみを入れてくるかと…。また、今後、将来的に｛｛条約｝｝のような右に来るテンプレートができるかもしれませんから（今は［［:Category:アメリカ合衆国の著作権法］］のように最下段に横一列表示だけですが）右側は空けておいてもいいかもしれない。それこれ考えて、結論的には（私は単独記事としては右寄せ推しですが）複数の記事の融合体である百科事典として見た場合は左寄せが無難かと存じました。ダラダラと書きましたが以上が雑感です。
  蛇足：この力作の記事「著作権法 (アメリカ合衆国)」が Wikipedia:著作権 や ガイドブック、井戸端などからも参照されると、古くから習慣化していたルールの根拠が定まったり、現行法に合わせた見直しに役立ったりするかもしれません。単に一般の読者だけでなく、編集者側にとっても非常に大切な記事となるのだろうと存じます。 --灰は灰に（会話） 2019年7月2日 (火) 05:51 (UTC)
• @Yapparinaさん: しばらく英語版の過去議論などを読んだりして検討したのですが、やはり私にはYapparinaさんの主張がうまく飲み込めませんでした。私が挙げた例が不適切だったために議論がそれた面もあると思うので (反省しております)、ここで改めて仕切り直して、論点・現状の懸念点を明確化したいと思います。なお、@灰は灰にさんからコメントを寄せて頂いていますが、これは私の目が慣れてきてしまって、自分は良いと思い込んでいる執筆記事が、読者には読みづらくなっているのではないかとの自己懸念があり、第三者の率直な意見が頂きたかったからです。特に集票活動をしたかったわけではありませんので、誤解なきようお願いします。より多くの方からコメント頂けるよう、{{コメント依頼}}を表側に掲示しておきました。
  • 論点 (A): 2012年に合意形成なく、{{TOC right}}に「記事のページでの濫用は慎しまれます」の文言が足されてしまったが、これは手続き上問題ではないか？ (文言追加時の編集) なお、英語版では一段上のスタイルマニュアル (MOS)で慎重に議論がなされています。
  • 論点 (B): 仮に手続き不備で2012年の文言追加を削除すると、当テンプレート利用者はどんな時に使っていい/悪いのか、判断基準に困らないか？
  • 論点 (C): また、既に当テンプレートが使用されているが、デフォルト目次表示に戻したいと思った時、利用者間で編集合戦にならないか？
  • 論点 (D): A～Cの問題を解決する上で、判断基準8項目 (英語版7項目の移入 + 新規1項目) はHelp:セクションに掲載する価値があるか？
  • 論点 (E): いやいや、そもそも{{TOC right}}も{{TOC left}}もあまり価値がないので、廃止すべきではないか？ (または記事ページは全面禁止を原則とすべきではないか？)

私はA～Dが全てYESで、EはNOの立場です。そのためこの度、改定案を提出致しました。理由は以下の3点です。

• ベストではないかもしれないが、判断基準がないよりあった方がベターだと確信しているからです。例えば仮に、著作権法 (アメリカ合衆国) の現時点版で使用している右寄せが不適切だと思う方がいれば、判断基準8項目を論拠にデフォルトに戻す議論をしやすくなるからです。基準なしだと議論が平行線になりがちです。
• 回り込みによる2列段組みを支持します。特に概説が充実している記事の場合、その概説の文章がそのまま目次構成の説明につながっていることも多く、概説を読んでいる途中で右側に配置されている目次に目を通し、自分の読みたいセクションにスキップすることができるので便利だと思います (これがデフォルト目次表示の場合、画面スクロールが発生して面倒に感じます)。同様の理由で私は、概説を読んでいる最中に、全体像を頭の中で整理するために右側にあるInfoboxをチラ見することがあります。
• Yapparinaさんは「添え物」否定派のようですが、私は目次の表示はサブで、本文がメインだと序列をつけています。目次構成そのものは屋台骨なので重要ですが、目次の「表示」は別の話なので。少なくとも{{TOC right}}はInfobox系と同じ表示の仕組みだと捉えており、InfoboxがOKなのにTOC rightがNGなのはロジックがよく分からないからです。「添え物」であるからこそ、ブラウザのモバイルビューでは目次1階層目しか表示されませんし、モバイルアプリではデフォルトで目次は表示されない設計仕様になっています (ちなみにInfoboxもモバイルアプリではデフォルトで折り畳みされています)。仮に「好みの問題」なのであれば、全体的なUI/UXの設計思想に寄せるのが無難であり、Infoboxなどの取扱に準じて{{TOC right}}も基準が規定されるべきと思います。ただし、正直TOC leftは必要なのか？と疑問ではあるのですが。。。英語版でもTOC leftのみやや否定的な意見はありました。--ProfessorPine（会話） 2019年7月3日 (水) 04:48 (UTC)

• 論点 (A)：手続き上は問題あると思います。この点において、元の文面に戻すべきと考える人がいるならば、そうなさればよいと私は思います。
• 論点 (B)：わかりません。困る利用者もいるかもしれませんし、気にせずに使う利用者もいるかもしれません。
• 論点 (C)：編集合戦になる可能性はあると思います。
• 論点 (D)：私は、上で説明したようにTOC rightに長所よりも短所を多く感じているので、(B)と(C)のために基準を設けるならば、今の文面でいいと思っています。
• 論点 (E)：わかりません。
• 「特に概説が充実している記事の場合……」について、その利点自体の理屈は理解できます。それに限らずに、TOC rightの利点、あるいはその見た目を好む人の存在自体は理解しているつもりです。ただ、ウィキペディア全体としてどういう基準を設けるべきか決めようというのであれば、自分なりに長所と短所を比較衡量した上で、今の文面のように通常記事では使わない方向性で定めるべきだと私は考えます。
• 「Yapparinaさんは「添え物」否定派のようですが……」について、ProfessorPineさんの言葉を借りるなら、私は、本文がメインで目次もメインで、それぞれ質は違うが等価な重要性を持っていると考えています。だから、デフォルトのように、目次の表示は文章の回り込みなく空間を占有するべきだと思っています。--Yapparina（会話） 2019年7月5日 (金) 23:21 (UTC)

• コメント 著作権法 (アメリカ合衆国)は単にセクションを作り過ぎなだけですわ。WP:MSHで「たった1つや2つの段落には用いないでください。」ってあるのを無視して見境なく見出しを付けまくっておいて「目次が長い」ってアンタ... その前にガイドライン守った記事書けよって話しでしょ。お話しになりませんわ。--Namanaka（会話） 2019年7月3日 (水) 12:44 (UTC)
• コメント（位置を移動しました） @Yapparinaさん:論点 (A)～論点 (E)まで様々な従来の経緯の不手際は確かにあるでしょうが、それはそれとして、YapparinaProfessorPineさんのご意図は心情的にはわかりますが、「固執しない」のがよろしいのでは？ （許容されるかどうかは別として）左寄せで、その外側を空テーブルで囲って右側に文字の回り込みを許可するダーティーハック的な設定で逃げる手もあるかもしれません。いずれにせよ、私は他の関連記事に飛んだときに目次が右に行ったり左に行ったりというのは目があちこちに行くのでちょっと読みづらいかもな、と思っています。ガイドラインはほぼ守られていると思いますよ。Yapparinaさんの書く記事は密度が濃いので、和らげた場合は膨大な文字列になるでしょうし、改行が少ないので「斜め読み」には適していない読みづらい部分もあります。法律用語は一語一語に込められた意味の含蓄が深いので、単に行数だけでガイドラインに合致しないと言えるような種類の話題では内容に思えます。もっと改行入れれば良いのに、と。短くするなら「3 法改正の歴史」と「4 司法判断」を別記事に切り出して移設でしょうかね。--灰は灰に（会話） 2019年7月3日 (水) 17:20 (UTC) --灰は灰に（会話） 2019年7月6日 (土) 18:00 (UTC)

• （灰は灰にさんに宛て）2019年7月3日 (水) 17:20付けの上のコメントで、私の名に言及しておりますが、これは特に間違いなく私に対する意見なのでしょうか？--Yapparina（会話） 2019年7月5日 (金) 21:47 (UTC)

• （Yapparinaさん宛て）ごめんなさい。文頭でPing飛ばしたのは言及したことを通知する趣旨で、その部分はYapparinaさん宛です。しかし、いいたいことの肝心な点、文中の「ご意図は心情的にはわかりますが」云々の部分は問題提起者であるProfessorPineさん宛てです。ルールのためのルールを作るようなことに固執せず、現状がファジーな文言ならば黙ってファジーに対応し、物言いが付いたときに、ではどうしましょうか？そもそもそのルールの制定経緯からして…と議論を始めるようなのでもいいではないか、と。 --灰は灰に（会話） 2019年7月6日 (土) 18:00 (UTC)

• {コ}「良質な記事」に選出されている「ウィリアム・グラッドストン」は、現行の「著作権法 (アメリカ合衆国)」」よりも目次のネストが深いですが、デフォルトの左寄せで、各トピックの後に「【↑目次へ移動する】
  」を挿入して読者の迷子回避の工夫をしているようです。フロートメニューが導入されるまでは、この辺りで手を打つのが軋轢も少なく、いいのかなぁと思いました。アラビア語など、横書きで右から左に進む文字列が頻繁に日本語文中に入り込むような場合はメニュー右寄せもありなのかもしれませんが、現行の「著作権法 (アメリカ合衆国)」」に関しては、他の法律関連記事、例えば「ベルヌ条約」へジャンプしたら、多くの項目の目次は左寄せなので、視覚的導線があっちこっちに惑わされますから、右ではなく、デフォルトの左で良いような…。デフォルトの左での文字列回り込みをさせられるように（多少ダーティーハック気味の操作も許容される措置の追認を取り付けるのが）今般の場合は穏やかのように思いました。デフォルト左表示での文字列回り込みも不可ということであれば、「ウィリアム・グラッドストン」を模倣するので今回はよしとする。今、議論がなんだかすれ違いのようにになっているのは、「それではどうしても譲れない何か」（を心情面に訴える形で）示せていないというのがあるのでしょうか。おそらく皆さん「好みの問題」と（やんわりと）おっしゃっているのは煎じ詰めると「それではどうしても譲れない何かを示せ」を喧嘩にならないような言い方に留めているだけのように思います。ですので、従来の経緯が厳密な議論ルールに基づいて成立していないものであることを蒸し返しても（他の方は心情面で「それではどうしても譲れない何か」に納得しない限り）、既にデファクトになっているのをひっくり返すような試みは既存記事の立項数の膨大さや慣習的な馴れから見て、困難かと思います。「誰のための」ルールだったり、操作だったり、するのか？　そしてそれは慣習なり慣習法なりを乗り越えるだけのメリットがあるか、そこの部分の比較衡量の問題だと思います。--灰は灰に（会話） 2019年7月4日 (木) 01:31 INS付加(UTC)--灰は灰に（会話） 2019年7月4日 (木) 01:49 (UTC)

• コメント 私は回り込みについては特段の賛成も反対もありませんが、{{TOC right}}による右寄せは可能な限り避けていただきたいと考えています。Wikipediaにおける目次は大多数の頁で左上にあるものです。弱視の方などは画面拡大ソフト等を用いて頁を見ているかもしれず、レイアウト全体を見通すことは出来ません。なのでいざ目次を探そうとした場合は、ページの左上を探します。導入文の長さ次第では全くの左上ではないかもしれませんが、それでも頁の左端を上下にスクロールさせれば見つけることが出来ます。しかしここで目次が右寄せになっていると、左端をどんなに探しても目次を見つけることが出来ません。そのような頁はWCAG 2.0のガイドライン 3.2「ウェブページの表示や挙動を予測可能にすること。」内の達成基準3.2.3「一貫したナビゲーション」に反するものであり、提案中の文書とはいえWikipedia:アクセシビリティを考慮しない瑕疵があると考えます。--LudwigSK （Diskussion/Beiträge） 2019年7月5日 (金) 01:40 (UTC)
  • コメント極端な弱視者と、同じ部屋でコンピュータを用いてする仕事を1年ほどした経験がありますが、Windows VISTA以降、MS Office 2007以降の環境では、ブラウザの[CTRL]+[+]or[-]で表示全体を拡大するなどして見ているようです。Windows XPやMS Office 2003頃まではWindows標準添付の「拡大鏡」で見ざるを得なかったのですが…。ですので「今回の提案」に関しては、瑕疵とまでは言えないかもしれません。
    「理念」としては共有すべきことではあるけれども、今回の場合は、配慮しても実際上は特に意味はないかもしれません。実際に試してみていただきたいのですが、一定以上の大きさにブラウザの文字を拡大してご覧になると、目次が左でも右でも（結局は文字が極端に拡大されるので）中央揃えのように見えるという次第です。「達成基準」の表層的な達成と、当事者たる利用者にとっての実際の使用感とは時として異なる場合があります。
    また、今回の議論がある程度熟してきたときに、「目次そのものの行数が（中項目、小項目を含めて）何行以上になった場合、本文の可読性確保に寄与することを目的として右寄せにすることを許容する」というルールが（全体になるかもしれず、特定のカテゴリについてのみの局所的なルールになるかもしれませんが）できても良いのかもしれません（提案者である@ProfessorPineさんは、おそらく、今はヤキモキしながらも、敢えて介入を差し控えていらっしゃるのでしょう、まだそれを言い出してはいませんが）。
    もし、そうなった場合、弱視者自身で「そういうこともある」と得心しておいて、自己対応を図れば良いだけの話です。「弱視者は何についてでも弱者である。」というわけではありませんので…。「合理的配慮」の具体的な範囲というのは個別的なものなので、なかなか判断が難しいのですが、合理的配慮の注に掲げられている内閣府の資料のほか、厚労省の資料（PDF）では「過重な負担」についてもしっかり明示されている点なども参考になるかもしれません。私はまだ賛成反対を明示的に示すほど気持ちが固まっていないのですが、どちらかといえば右寄せ支持よりは、さしあたりは左寄せで回り込みするテクニックがあれば（多少、ダーティーな裏テクであっても）、それを採用して反応を見る（ルール化はしないで、よほど評判が悪ければ元に戻す）というあたりを落とし所にしてはどうか？という方に傾いています。 --灰は灰に（会話） 2019年7月5日 (金) 15:23 (UTC)
• コメント @ProfessorPineさん:、全くのデフォルト目次に戻したり、当該記事の冒頭

  {{Law|地域=[[アメリカ合衆国]]}}

  の直後に

{| style="float:left"
  |__TOC__
  |}

と入れてみたり、元記事で

{{TOC right|limit=4|width=25%}}

とある位置で

{{TOC left|limit=4|width=25%}}

としてみたり、幾つかの実験をしましたが、（私の感覚では）「デフォルト位置ではない。しかし左寄せとし、文字も回り込みにする。」でいいのではないかという印象を持ちましたので、書き換えしました。（どなたでも）revして下さっても構いません。--灰は灰に（会話） 2019年7月9日 (火) 10:18 (UTC)

皆さんの見解を読みながら考えました。私は「どちらかというと否定的」なコメントをします。

• まず、「目次」とはなんぞや、です。お手元の書籍を手にとっていただき、その目次ページを眺めてみてください。たいていは、目次ページの下部の空白部に本文が書かれているようなことはないはずです。つまり「目次」部は、文献における独立したセクションたるということです。（ただし、1冊の書籍の目次と、1記事のなかの節わけの目次を同一視するのか？というのはあります。たぶんふつう、百科事典の1記事にはいちいち目次なんかないです。）
• 技術的に可能だからといって、「目次とはなんぞや」を考えると、画像と同じようにレイアウトをいじったりするのはどうかなー、いう感じです。そこに広い白紙スペースがあっても、そのままにしておくしかない。
• まあ、レイアウトをいじりたくなる気持ちはわかると思います。なんでかな？と考えてみたのですが、書籍の目次の場合には、「第二六章　レンミンカイネンのポポヨラ婚礼旅行・・・・・・・・・33」みたいに、章番号やページ番号などがあったり、目次に用いられる文字列が長かったりします。だから、目次だけでページの左右いっぱいのスペースを埋めていても違和感がありません。
• Wikipediaではリンク機能のおかげで「ページ番号」は不要ですし、章番号なども「1.1.1」のように略記されていて、場所をとりません。そして一般的な傾向としてWikipediaの記事では目次になる見出しの文字列が短い。つまり、「概要」「地理」「歴史」「人物」・・・など簡素で短い単語が見出しとして用いられがちです。それらの帰結として「目次枠」の幅が小さくなります。そして脇に何も書かれていない白紙スペースがたっぷり残ります。なので、なんとなくそこを埋めたり活用したい誘惑に駆られるのです。書籍の場合、目次の見出しに短い単語が多い場合には、目次ページのレイアウトが二段になってたりしますね。
• 実際には、冒頭部に画像やテンプレートが用いられていて、左に目次、右にテンプレートが並んでいるような記事は多くあります。まあこれは、そうなっちゃった、という感じでしょうね。冒頭部は短い文章にする、という制約がある一方、テンプレートや画像は横幅の制限があって縦長になりがちということで。（一般の書籍では、表紙に近いページでは1ページいっぱいに大きな画像が使われていたりしますが、Wikipediaではそういうことはまずありません。ペラペラとページをめくることもなく、画面を下にスライドするだけです。そこらへんは書籍とWikipediaの違いです。）--柒月例祭（会話） 2019年7月9日 (火) 13:20 (UTC)

皆様へ: ここ数日、突発的な所用でWikipediaに携わる時間が取れませんでしたが、復活しましたので今後はもう少しスムーズにお返事できると思います。すみませんでした。

• 全体論として。8基準をお読み頂ければ分かると思いますが、規制「緩和」だけでなく、規制「強化・明確化」の目的もあります。8基準の内容を完全に廃案にしたり、または大幅ブラッシュアップすべきとのご意見があれば、(時間はかかっても構いませんので) ぜひ具体的な対案の提示をお願いできませんでしょうか。{{TOC left}}はいいけど{{TOC right}}はマズイという方や、{{TOC left}}も{{TOC right}}も回り込みは全てマズイという方で意見が分かれているようですが、いずれにしても対案なしに現状維持または反論だけでは、結局は編集合戦リスクを放置してしまい、建設的な方向に進められません。

• ここでの「編集合戦リスク」ですが、今後高まることはあっても減ることはありません。念のため当改定案の背景を申し上げると、英語版で{{TOC right}}を使用している記事複数をたまたま読む機会があり、私にとってはとても読みやすいと感じました。そのため、自分自身の執筆記事の一部にも流用しました。さらに、日本語版で{{TOC right}}を使用している他記事を確認したところ、英語版からの翻訳記事が比較的多いように見受けられました。つまり、翻訳者たちは何ら意識せず、{{TOC right}}や{{TOC left}}の記事を今後も作り続けることになります。だからこそ、(規制するか緩和するかは別として) 日本語版でも基準を明文化すべきと考え、たたき台として当提案を提出しました。

• 目次はどのような位置づけであるべきか？について。(主に@㭍月例祭さんと@Yapparinaさんの主張に関連しますが) モバイルでは目次の位置付けが低い設計思想について、どうお考えでしょうか？ 換言すると、なぜデスクトップ版だけ目次を重視して、規制をかけなければならないのでしょうか？ 後述のアクセシビリティとも関連しますが、上位となる設計思想や法的文書に沿って、下位の個別規定を整えるべきというのが私の基本アプローチです。

• 続いて、Wikipedia:アクセシビリティの観点について。この文書は方針でもガイドラインでもない草案の状態です。したがって、Help:セクションなどと同等の法的ステータスです。仮に様々な端末での互換性を担保すべきとお考えならば、まずはその根拠となるWikipedia:アクセシビリティの合意形成とガイドライン化が必要ではないでしょうか？ 私が調べた限りでは、多端末対応を視野に入れた個別規定をガイドライン化しているのは、Wikipedia:色の使用ぐらいしかなさそうです。つまり、(色を除いて) そもそもWikipediaで多端末の互換性を担保する必要はない、というのが現状の規定だということです。この規定を変更する議論はあってもいいと思いますが、その場合はこの場 (拘束力のないHelpのノートページ) で決めるのではなく、目次以外の観点も包括してコメント依頼で告知すべきでしょう。アクセシビリティも論点追加をご希望の方がいらっしゃれば、当Helpページ上での議論はいったん保留にし、Wikipedia:スタイルマニュアルあたりに議論を移そうと思いますが、皆様いかがですか (先述の通り、英語版でもMOSで議論してます)。

• 最後に、私自身はOS・ブラウザ互換性を検証する実務をイヤというほどやった経験があります。ですから、皆さまが言わんとしたい観点は重々承知の上です。しかし、どこまで互換性を担保すべきか線引きが曖昧なまま、とりあえず「互換性ガーー」「環境ガーー」と言い出すと、労多くして功少なしに陥ってしまい危険だ、というのが私の経験論です。たとえば@LudwigSKさん指摘の「画面拡大ソフト等を用いたら、右側が見えないかも」ですが、そのような低質ソフトを使っている方はWikipediaの本文を読む際に、1行1行横スクロールして読んでいるわけで、目次の右寄せ云々以前の悲惨な状態です。こういった非現実的なケースまで仮定すべきではないと考えます。LudwigSKさん個人を槍玉にあげたかったわけではないので、お気を害されませんように。ちなみに今回の提案にあたって、私はブラウザの文字サイズ拡大や、Windows 10でのデフォルト文字サイズの拡大なども実施の上、横幅が広がらないことは確認済です。--ProfessorPine（会話） 2019年7月16日 (火) 09:29 (UTC)

@灰は灰にさん: 論点がさらに脱線しているようで大変残念です。念のため申し上げますが、私は自身の執筆記事1本を通すために、この改定案を出しているわけではありません。記事1本の個別論評はこの場では不適切ですので、お控え頂けますか (必要なら記事ノートへ転記の上で継続をお願いします)。詳細はあとで会話ページにて補完させて頂きます。--ProfessorPine（会話） 2019年7月16日 (火) 09:29 (UTC)

@ProfessorPineさん: 私の気質として個別から抽象へという方向性でしか物事を考える能力をそもそも持ち合わせていない、というに過ぎません。付け加えると、ルール作りに労力を割くならば記事を増やす方が読者のためになるとも思います（のでルールのためルール作りのようなのは、どうも苦手です）。
それと、@㭍月例祭さんによる現状の総括にはいちいち頷くとともに、法律関係のようなミッチリと文字が詰まったものについては目次の右がスカスカで、本段に入るとミッチリというのにはどうにも違和感があります。さしあたり、法律関係（やそれに類する本文上のみっちり具合を持つ類の記事）については、慣例に従った左置きとはするものの、文字の回り込みについては認めては良いのではないか、というのが私が現時点でたどり着いた見解です。
このノートで今後、どのような議論やおとしどころになるか、他でも関連したルール作りの提案が広がってゆくのは、そのあたりはちょっとよくわかりませんが、そもそも論からのルール精密化については、不得手な分野なのでコミットできないかと存じます。本事例を範としたスコープで考える限りでは、「目次左寄せは維持、文字回り込みを許容を支持」が私の現時点での見解となったことだけ、強調しておきます。--灰は灰に（会話） 2019年7月16日 (火) 13:29 (UTC)

目次（TOC）の呼び出し方の説明について

• TOCの仕様についてちょっと調べて気づいたのですが、「見出しが4つ以上あるページには、基本的にセクション見出しから自動生成される目次が表示され、[[#toc]]と記述すると記事中の目次にリンクする（戻る）事が出来ます。ただし次の場合を除きます。」とありますが、PC版が吐き出すコードは<div id="toc" class="toc">で、モバイル版が吐き出すコードは<div class="toc-mobile view-border-box">となっており、id名やclass名が不一致のため、[[#toc]]ではモバイル環境ではリンクにジャンプできないようです。その点では、現行の[[#toc]]でジャンプできるという説明は不十分な点があるかもしれません。さしあたりの対応策としては<div id="mokuji" class="mokuji">{{TOC}}</div>のような感じでdivの内側に明示的にジャンプ先となる目次TOCを置いてから、リンクする側ではdivのidを[[#mokuji|↑目次]]のように指定すれば、正常に飛べるようです。今は、このようにいわゆるdiv厨の対応をせざるを得ませんが、モバイル版の出力時にid="toc"を付加すれば解決すると思われます。互換性維持は大変な労力だったと思います。 --灰は灰に（会話） 2019年7月16日 (火) 15:56 (UTC)