Template‐ノート:Reflist

message: 私の環境だと、このテンプレートを  や  の形で使っているページを表示した際の見え方にやや問題があるのに気づきましたのでご報告を。
* ブラウザがIEの場合ちゃんと二列や三列にならない。
* Mozilla Firefoxの場合はちゃんと列を改めて表示されるが、左の列に自動改行されない文字列があると表示が右の列の領域にまで及んでしまう（例：ルーシー・リュー 2008年7月7日 (月) 21:40の版）。
以上です。あくまで私の環境での話で、同じブラウザのバージョン違いや他のマシンで表示した場合にどう見えるかは試しておりません。--Kurokani 2008年7月9日 (水) 07:41 (UTC)
replies: text: 後者に関してはバージョン2系列および以前での改行に関する問題に起因すると思われます。Gecko:Line Breaking(日本語による説明)を参照してください。今後Firefox 3以降への移行が進んでいくと思われますので、この問題は気にしなくてもよいかと思います。--ayucat 2008年10月2日 (木) 09:19 (UTC)
（インデントを戻します）ガジェットの脚注部分をスクロール化するを入れていると、が2段どころか、縦の幅が固定で段数がえんえん増えてしまって横スクロールとなってしまい、かえって読みづらくなっています（[ 体験用リンク]）。--Jkr2255 2012年2月3日 (金) 01:54 (UTC)
thread_title:  見え方の報告 

message: Help‐ノート:脚注にて、脚注スクロール廃止の提案をしております。ご意見をお待ちしております。Yassie 2009年4月19日 (日) 13:18 (UTC)
replies: text: Reflistテンプレートから脚注スクロール機能を廃止し、脚注スクロール機能はガジェットで提供することで合意が形成されました。それに伴いを更新することになります。更新内容については、現在、Help‐ノート:脚注#審議終了提案と実務面の詰めで話し合っています。--iwaim 2009年5月8日 (金) 15:26 (UTC)
 「特別:リンク元/MediaWiki:Gadget-ScrolledReflist」を見れば、scrollパラメータを使用していて、廃止を告知する警告文が表示されてしまっている記事を探し出すことができます。私の方でも気がついた範囲で修正を行っているものの、保護中となっている「日本教職員組合」「日本における2009年新型インフルエンザ」、および利用者ページなどには手を出せませんでした。一応報告しておきます。--Kanohara 2009年7月20日 (月) 15:09 (UTC)
thread_title:  脚注スクロール廃止を提案中 

message: WebKit においても、-webkit-column-count, -webkit-column-width が用意されています。これらをテンプレートに追加しようと思うのですが、何か問題はあるでしょうか。--Frozen-mikan 2010年7月29日 (木) 09:16 (UTC)
replies: text: 問題ないと思いますので追加しました。--矢口 2010年9月19日 (日) 13:57 (UTC)
replies: text: : ありがとうございます。何か問題が見つかりましたら、情報を付けるようにします。--Frozen-mikan 2010年9月19日 (日) 18:06 (UTC)
thread_title:  WebKit への対応について 

message: は、PCでは可読性向上に有用ですが、
私の環境では、スマホでも2行に分けて表示されるため、かえって読みづらいです。皆さんのスマホでも同じでしょうか？
スマホの場合、もしくは横解像度が一定値以下のスマホの場合は、
やなどを無効化してはどうでしょうか？そのようなことは可能でしょうか？
私の環境はAndroid4.1、Sleipnir Mobileおよび標準ブラウザです。--Mytrajectory22（会話） 2014年3月13日 (木) 22:11 (UTC)
replies: text: 実は2年ほど前に提案され、却下されています。当たり前の事を言いますが、2段の方が見やすい環境と、1段の方が見やすい環境があります。仮に環境が同じであったとしても、好みと言うものがあります。その辺りを加味すれば、各執筆者に「強制」する必要は無いのではないかと思います。3列、4列は流石に無いでしょうが、1と2なら「どちらでもいい」とするのがまあ、落としどころなんじゃないでしょうかね。

text: 私は技術的にそこまで細かい事はわかりませんが、mediaWikiとテンプレートの方で「端末がそれをスマホだと検知した場合、表示を変える」と言うコーディングが可能かもしれません。また逆に、スマホのブラウザの拡張機能で「wikipediaの脚注の二列表示を無効にする」ものが作れるかもしれませんね(こちらは私でも作れそうです)。--Hman（会話） 2014年8月6日 (水) 09:35 (UTC)

text: 気になって英語版を調べてみたところ、モバイル版は :en:MediaWiki:Mobile.css にてスタイルを上書きし、（本テンプレートの更新も必要ですが）1段で固定するようになっていました。ご質問の時点では無かった機能ですが、いかがでしょうか。英語版の例としては、デスクトップ版とモバイル版にて。--Frozen-mikan（会話） 2014年8月6日 (水) 17:21 (UTC)
早急に導入してもらいたいです。切実に。--61.46.104.165 2016年9月11日 (日) 18:16 (UTC)
当時の議論で列幅指定についての意見が出ていないのにびっくりですよ．ちなみに英語版で非推奨になったのはこの辺ですかね（ノート）．新規作成 (利用者名) （会話） 2016年11月16日 (水) 12:37 (UTC)
thread_title:  <nowiki>{{Reflist|2}}</nowiki>のスマホでの見難さ 

message: refs引数を使って列挙した場合、<nowiki>
本文
<ref name="denkisha198401-25">電気車研究会『電気車の科学』1984年1月号、p.25</ref>
脚注
{{Reflist|refs=
（中略）
<ref name="denkisha198211-30">[[#denkisha198211-22-30|『電気車の科学』通巻415号、p.30]]</ref>
<ref name="denkisha198401-25">[[#denkisha198401-25-28|『電気車の科学』通巻429号、p.25]]</ref>
<ref name="pic200604-21">[[#pic200604-10-33|『鉄道ピクトリアル』通巻774号、p.21]]</ref>
（中略）
}}</nowiki>
例：https://ja.wikipedia.org/w/index.php?title=%E5%9B%BD%E9%89%84203%E7%B3%BB%E9%9B%BB%E8%BB%8A&oldid=57613249
（修正済み）のようになっていた場合でも、name属性の重複エラーが出ています（編集後に「Category:参照エラーのあるページ」に現れる）。
現在注記されている「ここで定義された脚注が本文中で一度も使われなかった場合には、エラーが発生します」というのは、編集時のプレビューでもエラーとして出るため分かり易いのですが、こちらは編集段階で参照エラーが表示されないため気付き辛いと思います。つきまして、この点を注意事項として追加してはと思うのですが、いかがでしょうか。特に、上記の例のように列挙したものが溜まってしまったものを後から修正する場合、手間と時間がかかってしまいますので、提案させていただきました。--Mercurius（会話） 2015年12月5日 (土) 06:02 (UTC)
thread_title:  エラーについて注記の追加の提案 

message: 列数を指定した  や  といった使い方を非推奨とすることを提案します。列数を指定するとスマートフォンなど画面幅の小さいデバイスからの閲覧時に著しく可読性を損ねます。列数の指定はせず、代わりに列幅を指定して  といった使い方をするように doc に記述しましょう。--61.46.104.165 2016年10月15日 (土) 18:07 (UTC)
（追記）英語版は列数が指定されていてもモバイルビューでカラムが解除されるようになっていますが、日本語版は残念ながらそうなっていません。また、英語版の本テンプレートの doc では既に列数指定は非推奨とされています。--61.46.104.165 2016年10月15日 (土) 18:25 (UTC)
* 賛成します。--Waiesu（会話） 2016年10月16日 (日) 03:10 (UTC)
** scroll廃止のお知らせを列数指定非推奨化のお知らせに変更するのはどうでしょうか。--Waiesu（会話） 2016年10月16日 (日) 03:19 (UTC)
* ついでにボットに→のような置換をしてもらうことも提案します．新規作成 (利用者名) （会話） 2016年10月16日 (日) 07:13 (UTC)
replies: text: ご賛同ありがとうございます。

text: 「お知らせ」とはテンプレート本体のエラーメッセージでしょうか、それとも doc の説明文でしょうか。全文検索してみると  の移行は済んでいるようですので、テンプレート本体のエラーメッセージは変更してもよいかと思います。一方 doc の説明文は残しておいたほうが事情がわかりやすいと思います。

text: テンプレートがテンプレートだけに対象が膨大になりますが、ボットによる置換をしていただけるのであれば、無理してテンプレート本体に列数指定非推奨化のエラーメッセージを組み込む必要もなくなりますね。--61.46.104.165 2016年10月16日 (日) 15:43 (UTC)
replies: text: : エラーメッセージのことです。（サンドボックスに下書きを書いています。下書きではプレビュー時のみエラーメッセージを表示するようにしています。処理速度についてはこちらで比較しています。）botで置換する場合は

text: :*→

text: :*→

text: :*→

text: :*→

text: :*→

text: :みたいな感じですかね（7以上は標準名前空間にはないみたいなので6まで）。botで置換しても、慣習で列数指定する人はいると思うので、なにかしらのメッセージはあったほうがいいかなと私は思います。もしくはテンプレート側で上の処理をしてしまうというのもありだと思います。--Waiesu（会話） 2016年10月16日 (日) 16:27 (UTC)
replies: text: :: なるほど、確かにその通りです。メッセージはあったほうがよいですね。--61.46.104.165 2016年10月16日 (日) 17:55 (UTC)
*  botによる処理もやってもらいましょう。人力でやるのは無理。--Mirinano（会話） 2016年10月16日 (日) 15:52 (UTC)
* スマートフォン対応が目的なら、上記「#のスマホでの見難さ」節にあるMediaWiki:Mobile.cssとテンプレートの改定の方が多様性があり、手間も掛かりません。--Vigorous action （Ｔａｌｋ/History） 2016年10月16日 (日) 23:00 (UTC)
* 日本語版でもカラムが解除されるようにすればいいのでは？botを使うにせよ、かなり大規模な作業になってしまいます。--Kyoyaku（会話） 2016年10月17日 (月) 00:05 (UTC)

text: ご意見ありがとうございます。私の提案に付随して皆様から様々なご提案をいただきましたので、整理させていただきたいと思います。

text: # 本テンプレートの列数指定を非推奨とし、列幅指定を推奨すること（doc の記述の変更）

text: # 列数を指定している本テンプレートに列幅を指定するよう促すメッセージを表示すること（テンプレート本体の改定）

text: # 列数を指定している本テンプレート使用記事をボットにより列幅の指定に変更すること

text: # MediaWiki:Mobile.cssと本テンプレートを改定し、モバイルビューではカラムが解除されるようにすること

text: 私の本来の提案は 1. の部分です。スマートフォンはもちろんですが、様々なデバイスから様々なブラウザ幅で閲覧される昨今、もはや列数固定で一概に見やすいとは言えなくなっており、提案させていただきました。

text: 次いで Waiesu さんから 2. のご提案がありました。これは列数指定から列幅指定へ移行させていくのに有用であり、私も賛同しております。

text: さらに 新規作成 さんから 3. のご提案がありました。これは対象記事が大量になるため、可能ならということですが、残念ながら Wikipedia では多くの記事が対象になる大規模な編集は敬遠される傾向にあります。私の本来の提案とも少し離れますので、別個に議論されるべきかと思います。

text: それに対して Vigorous action さんから 4. のご提案がありました。これについては早急に日本語版でも導入されるべきと考えておりますが、こちらも私の本来の提案とは少し離れます。しかし、2年前にこのお話が出て以降そのままになっており、今回の提案に至りますことご理解いただきたいと思います。

text: 反対のご意見をくださった方には、私の本来の提案そのものに反対なのか、ボットによる大量編集を伴う変更に反対なのか、明確にしていただけるとありがたく思います。--61.46.104.165 2016年10月17日 (月) 05:06 (UTC)--61.46.104.165 2016年10月17日 (月) 05:21 (UTC)（お名前を修正、大変失礼いたしました）
replies: text: :  4.の提案をしたのはMirinanoではなくVigorous actionさんです。念のため。

text: : 私はMediaWiki空間に詳しくないし触れないので触れるor詳しい方にお聞きしたいのですが、 のスマホでの見難さ で提案されているような仕様変更は何とかすれば可能でしょうか？--Mirinano（会話） 2016年10月17日 (月) 05:17 (UTC)
* 別にPCでも横幅が少ない環境くらいあるでしょう．botを使わずにをなどに解釈するようテンプレートを改変してもいいでしょうけど，いずれにしても列数指定を今のまま残すことには強く反対します．新規作成 (利用者名) （会話） 2016年10月17日 (月) 08:32 (UTC)
* モバイルビューに限る話ではありませんので、の改訂が望ましいと思います。--Waiesu（会話） 2016年10月17日 (月) 08:44 (UTC)
*  ipさんの提案に賛成いたします。どうも論点がずれているように感じますが、ipさんが提案しているのはセクション名の通り「列数指定の非推奨化」そのものであって、「列数指定になっているものを如何するか」はそのあとの問題ではないでしょうか。もちろん不可分な問題ではありますが、議論する順序がありましょう。--Na's sky 2016年10月18日 (火) 10:03 (UTC)
（報告）提案から一週間となりますが、賛成してくださった方が多いこと、反対のご意見をくださった方からも明確なご回答がないことから、doc の記述を改定し、列数指定を非推奨といたしました。現在列数指定となっているものをどうするかについては、引き続きご議論いただければと思います。--61.46.104.165 2016年10月22日 (土) 18:25 (UTC)
=== 列数指定をどうするか ===
*（報告）反対はないようですので，Waiesuさんの提案にもとづいて，テンプレートの仕様を，列数指定が自動的に列幅指定になるように修正しました．ただし，
**→
**→
**→

text: としました．（5や6にまで個別に対応する必要はないと思います．）新規作成 (利用者名) （会話） 2016年10月25日 (火) 03:11 (UTC)
Wikipedia:お知らせどころかWikipedia:コメント依頼への掲載がされていないにも関わらず、reflistの変更という、100万の記事にも影響しかねない変更が行われているので驚きました。もちろん、docで非推奨を宣言することはきちんと議論されていると思いますが、reflistの変更自体はそれに付随して意見が述べられたに過ぎず、私には十分な議論が行われているようには思えませんでした。列幅指定の置換については2016年10月16日 (日) 07:13 (UTC)において新規作成さんから提案がされていますが、その後の2016年10月17日 (月) 05:06 (UTC)における61.46.104.165さんの仕切り直しの際には「列数を指定している本テンプレート使用記事をボットにより列幅の指定に変更すること」について「別個に議論されるべき」との意見が出ています。その後は2016年10月17日 (月) 08:33 (UTC)にて新規作成さんより「botを使わずにをなどに解釈するようテンプレートを改変してもいい」との意見や、2016年10月17日 (月) 08:44 (UTC)にてWaiesuさんより「の改訂が望ましい」との意見が確かに出てはいます。しかし、2016年10月18日 (火) 10:05 (UTC)ではNa's skyさんより「「列数指定になっているものを如何するか」はそのあとの問題ではないでしょうか」との意見が、2016年10月22日 (土) 18:25 (UTC)では61.46.104.165さんより「現在列数指定となっているものをどうするかについては、引き続きご議論いただければと思います」という意見が出ています。流石にこの状況で多くの記事に影響が生じるテンプレートを変更するのは無理があるのではないでしょうか。別途節を設けてコメント依頼やお知らせなどに告知してから変更した方がいいと思いますが。--Kinketu（会話） 2016年10月25日 (火) 10:54 (UTC)
（追記）自分の環境（解像度：1920×1080）で以前に書いた茨城電気 (1931-1942)という記事を見てみたら、出典が横に7列並ぶという恐ろしいことになっていました（笑）。技術的にももう少し話し合った方がいいのでは。表示に不具合が出ているという報告にたいし差し戻しで対応したりせずに。--Kinketu（会話） 2016年10月25日 (火) 11:00 (UTC)
*Waiesuさんの 2016年10月16日 (日) 16:27 (UTC) の発言（最後の一文）を無視しているのはなぜですか？

text: ＞出典が横に7列並ぶという恐ろしいことになっていました

text: 逆に言えば， はそれくらいふざけた指定だということです（私の環境では4列です）．3以上を20emでもいいのかもしれませんね．

text: 不具合は確かに私のミスでしたがその時点では既に解消されており，会話ページで対応しています．新規作成 (利用者名) （会話） 2016年10月25日 (火) 13:21 (UTC)
replies: text: : 「Waiesuさんの 2016年10月16日 (日) 16:27 (UTC) の発言（最後の一文）」については見逃していました。申し訳ありません。あえて無視した訳ではありませんのでご容赦下さい。どうやら私のコメントの後にコメント依頼を提出されたようですね。お手数をおかけします。本題に入りますが、コメント依頼の提出がなされたということは、「列数指定の非推奨化」の提案は新たに仕切り直し、このコメント依頼提出時点から起算するという認識でよいでしょうか? そうであるのならばこの後の質問は意味を成しませんが、そうでないのならば新規作成さん以外の方に質問したいことがあります。新規作成さん以外の方には、「誰々のどの発言が（docの改定に付随する単なる意見ではなく）テンプレートを変更する明白な提案であり、その発言から一週間以内に反対意見がなければ変更を反映する」という認識は共有されていたのでしょうか。jawp全体の編集者の数からしたらこの議論に参加している編集者の数は極少数ですが、その極少数の編集者間でもテンプレート変更提案が認識されていなかったとしたら、やはり仕切り直した方が無難だと感じます。認識がきちんと共有された上での提案ならば、列数X以上をY emとした方がいいといった有用な意見も他人から頂けるかもしれませんし。--Kinketu（会話） 2016年10月25日 (火) 14:29 (UTC)
replies: text: ::これは不具合でしょうか？

text: ::*2014年の鉄道#脚注、を使用。注釈・出典ともに番号が表示されていません。

text: ::*2016年の野球#出典、を使用。出典の番号が表示されていません。

text: ::*2015年の野球#出典、を使用。出典の番号が表示されていません。

text: ::*2014年の野球#出典、を使用。出典の番号が表示されていません。

text: ::出典の番号が表示されていないものが他に多数の記事にある一方で、通常に出典の番号表示がなされているものもあるようです。上記リンク先の記事を確認をして頂きたいのですが、私の閲覧環境だけでなのでしょうか？--Sonchou（会話） 2016年10月25日 (火) 14:34 (UTC)

text: ::上記コメントのあとに変更の差し戻しが行われたのでしばらく様子を見ていましたが、出典の番号表示は復帰したようです。--Sonchou（会話） 2016年10月25日 (火) 21:18 (UTC)
replies: text: :::ですからキャッシュを破棄してください（今言っても無駄ですが）．サンドボックス（テンプレート）では問題を確認できませんでした．キャッシュを破棄して不具合が出ていたのならおそらくサーバー側の問題です．私の編集にミスがあるのならそれを指摘してください．新規作成 (利用者名) （会話） 2016年10月26日 (水) 02:04 (UTC)
*まず，今回のテンプレートの編集は早計でした．ご迷惑をおかけしたことをお詫びします．
*改めて，テンプレートの第一引数を列幅指定にすることを提案します．
*具体例から入りますが，私のパソコンでは（解像度は 1200 × 800 のようです），30em, 20em, 15em でそれぞれちょうど2列，3列，4列になります．左半分でページを見るような状況では，15em では1列ですし，Kinketuさんのように，15em で7列になる環境もあります．
*逆に列数指定を強制したときに，横幅の狭い環境でいかに可読性を損なうかは説明するまでもないと思います．そのための列幅指定なわけですが，ボットで置換するには対象があまりに多いですし，また今後の利便性も考えると，今までは2列指定だった  で幅を 30em にする，といった仕様の変更の方がよいと思います．
*おそらく，4列とかそういうのを指定している方は，横幅の広い環境の方がほとんどだと思います．テンプレートの例が30emで，それだと私の環境ではちょうど2列なので，適当に60の約数で考えて編集したこともありますが，Kinketuさんのおっしゃるように7列になってしまうのでは多すぎると思うので，2で30em，3以上で20emというのを一つの案としておきます．
*列数指定を（別の引数で）残しておく必要があるのかは分かりませんが，これについては他の方にお任せします．新規作成 (利用者名) （会話） 2016年10月26日 (水) 02:04 (UTC)
*colcountは（記事には使われていませんが）正常に動作していなかったようです（ソースを見れば明らかですが無意味な引数です）．新規作成 (利用者名) （会話） 2016年10月26日 (水) 02:21 (UTC)
*ちゃんと作るとこうなります（テンプレ，2で30em，3以上で20em，colcountあり）．新規作成 (利用者名) （会話） 2016年10月26日 (水) 08:50 (UTC)

text: 一応提案者ですが、ご無沙汰していてすみません。今話題に上がっている私の提案は、botで列数→列幅の置換しなくてもテンプレート側の処理で済ませればそれでもいいですよね、程度の軽い感じの意見ですので、あまり気にしないでください。どちらかといえば、前にも述べていますが、列数を指定してプレビューした際に警告文を出す、という処理のほうがより多くの利用者への広告になりますから、こちらの処理を推したいです。も影響が大きいテンプレートですから全保護にすべきなのでしょうか…。--Waiesu（会話） 2016年10月26日 (水) 10:54 (UTC)
replies: text: : 別にそれは仕様を変更してもできることではないでしょうか？ つまり， 等でプレビューしたときに警告文（列数指定が非推奨であることと仕様変更のお知らせ）を出せばいいと思うのですが．新規作成 (利用者名) （会話） 2016年10月26日 (水) 12:15 (UTC)
replies: text: :: そうなんですが、結果が同じなら直す必要なしってなりそう（警告文の重要性が下がりそう）なんで。その記事にあった適切な幅もあるかもしれないですしね。--Waiesu（会話） 2016年10月26日 (水) 13:10 (UTC)
replies: text: ::: 直す必要をなくすための仕様変更のつもりですが．「適切な幅」を探すような人ならどっちにしても同じでしょう．逆に仕様変更せず非推奨の警告だけだとそのままにする人もいるでしょうし，幅の設定で戸惑う人もいると思います．新規作成 (利用者名) （会話） 2016年10月27日 (木) 06:38 (UTC)

text: えー、ご意見だけ。emの直接してい推奨はそれこそ意味が分からなくなります。ナンセンスでしょう。かといって、1では可読性を損なう場合もあり（PC画面では右側に余白だらけで、恐ろしく縦長になります）、3以上もスマホの隆盛著しい現状は好ましくなく、せいぜい「通常は、1（無指定）または2が推奨されます。」、程度でよろしい。技術的に可能であれば、モバイル端末であることを察知すれば、内部で1に変換。でなければ原文のまま(あるいは2に変換）、などと言うことはできませんか。これが一番楽そうなんですけど。「可読性に考慮する」事は勿論大切ですが、「執筆者に対する指示を肥大化させない」事もまた大切です。締めるべき所は締めるべきですが、指示の肥大化は足かせです。私が執筆をやめたのも、肥大化した指示を持ち込んで会話ページにカチコミをかけ鼻高々、と言う自警に嫌気が差したからと言う意味もあります。この点に対する配慮が真剣に検討されたのか、甚だ疑問と思っております。以上です。--Hman（会話） 2016年10月27日 (木) 06:54 (UTC)

text: あーすいませんもう一言。別に日本語版でガラパゴス進化する必要などなく、可能な範囲でen丸パクりでいいんじゃないですか。こういうのは。単に桁数の問題でしょ？そこのコードだけ持ってくると。議論やコーディングに要するリソースがもったいないです。その点、技術的に可能や否やは確認されているのでしょうか。--Hman（会話） 2016年10月27日 (木) 06:59 (UTC)
replies: text: : 2→30em、3→20emのように一律に置き換えるのは反対です。それでは2と指定しているのに表示環境によって1列だったり3列だったりということが起こりえるので、編集者に混乱をもたらします。

text: : 一方で、列幅を直接指定することは有用です。ただし、すべての記事で一律30emや20emにしては意味がありません。それぞれの記事で脚注の中身は異なるのですから「適切な幅」は探さなければなりません。Aさんのパソコンでは3列、Bさんのパソコンでは7列、Cさんのスマホでは1列で表示されるなんていうのは言ってしまえばどうでもよいことです。その記事の脚注の中身に合わせて、列幅を設定すればよいのです。ハーバード方式が採用されていて最も長い脚注が「山田　2016　p.54」（12文字）なら15emとか、脚注内で書誌情報がしっかり書かれていて最も長い脚注が「山田太郎『脚注の付け方』田中出版　2016　p.54」（26文字）なら30emとか指定すれば、どなたの環境でも無駄な改行なく表示されるのですから。--Na's sky 2016年11月3日 (木) 04:30 (UTC)
replies: text: :: 1段落目後半，それに対しては警告文を出すことで対応します．サンドボックスを更新しました．テストケースでプレヴューしてご確認ください．2段落目，問題なのは今大量の記事で列数指定がされていることです．それに対していちいち適切な幅を人力で探していたのでは時間がかかりすぎます．bot でできるならすればいいですが，bot による置換後もまた別の記事とかで列数指定される可能性があります．そもそも現状の列数指定ではもともと適切な幅ではないのですから，それを列幅指定にしようが同じでしょう（というかむしろこっちのほうが適切な幅に近くなると思いますが）．別に私の案のように変えた後でも列幅指定ができなくなるわけではないのですよ？ さらに，以前のように列数指定をしようとしても勝手に列幅指定になってくれるというメリットもあるわけです．蛇足ですが出典テンプレートを使えば「山田　2016　p.54」ではなく「山田 2016, p. 54.」となりますから15文字ですよ．新規作成 (利用者名) （会話） 2016年11月3日 (木) 07:18 (UTC)
replies: text: ::: 列数から列幅指定への変更過程において、一律に置き換えるという案に反対している方も多いわけですし、無理にそうする必要はないんじゃないですかね。私はプレビュー時に案内文で移行を促せばそれで十分だと思います。あとscrollの案内はもはや不要でしょう。--Waiesu（会話） 2016年11月4日 (金) 09:53 (UTC)
replies: text: :::: Na's sky さんと Waiesu さんだけでしょう．Hman さんから執筆者の負担になるという意見も出ています．それに今列数指定になっているものはどうするつもりですか？ 3列指定と20em指定のどちらが適切か冷静に考えてください．新規作成 (利用者名) （会話） 2016年11月5日 (土) 02:31 (UTC)
replies: text: ::::: Hmanさんがおっしゃる「執筆者の負担になる」というは、新規作成さんの案でテンプレート側で一律に列幅指定に変換しても、結局その記事にあった列幅を指定し直さなければいけないという事態になるのですから、同じはずです。また、Hmanさんの案で英語版に合わせるとすれば、column-countもそのまま放っておくことになるでしょう。--Waiesu（会話） 2016年11月5日 (土) 10:56 (UTC)
replies: text: :::::: つまり，列数指定では適切な幅を考えなくてもよいが列幅指定では適切な幅を考えなくてはならない，というお考えなんですね？新規作成 (利用者名) （会話） 2016年11月5日 (土) 23:24 (UTC)

text: ::::::私にはあなたが考えていることが分かりません．私はテンプレートの仕様を変更した方が効率的に列幅指定に移行できると思っているのですが（「列幅を指定し直さ」なくていいものもあるでしょう），あなたは違うのですよね？新規作成 (利用者名) （会話） 2016年11月6日 (日) 04:05 (UTC)
replies: text: ::::::: 執筆者に列数→列幅指定を促すのと、テンプレート側で一方的に列数→列幅指定をしてしまって後で執筆者に調整させるのでは、どちらも執筆者の負担になる可能性があるという点で言えば同じです。ただ、テンプレート側で一方的に変更すれば、執筆者はより混乱しますし、おそらく「見やすいようにした脚注を勝手に変えられた」と気分を害する方もいるでしょう。効率的に列幅指定に移行できるかもしれませんが、私は別に効率性を求めていませんし、より多くの皆さんから理解が得られるように温和に移行すべきだと思っています。（実際に反対している方もいますし。）--Waiesu（会話） 2016年11月6日 (日) 04:30 (UTC)
その「見やすいように」が見やすくないから問題なんでしょう．効率だけでなく今まで通りの使い方（書き方）で問題なく使えるということも重要だと思います．一つ聞きたいのですが，2→30em，3→20em等々で「後で調整が必要」になる記事って実際にあるのですか？もちろん，より適切な幅がある可能性はありますが，少なくとも不適切な幅になることはないと思うのですが．新規作成 (利用者名) （会話） 2016年11月6日 (日) 08:38 (UTC)

text: いや、おそらく一般的なセンスをお持ちの方が同じ解像度・ウィンドウ幅で編集すれば、似たような感じになるでしょうから、見やすくないっていうことはないと思いますよ。ただ、普通の状態で見やすくても、他のウィンドウ幅であれば見にくいこともあるでしょう。その差異をなくしていくのが列幅指定であって、列数→列幅の一律変換は列数指定を非推奨とする意味がありません。今まで通りの使い方が問題なく使えるという面を重視するのならば、一律変換でなくて列数指定をそのまま残すほうがいいと思いますよ。と書いてから下の案を思いついたのでそちらもご検討下さい。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC) 誤字修正。意味が真逆ですねすみません。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)
replies: text: : ええ，「他のウィンドウ幅であれば」ということを言っているつもりです．新案ありがとうございます．新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)
「列数指定が勝手に列幅指定になる」「列数指定ができなくなる」ことが問題です。これまでのお話し合いのなかで、「列数指定を廃止する」「列数指定をできなくする」ことは合意されておりませんでしょう。仮にそれを無視してテンプレートを変更したとしても、表示環境によって指定と異なる列数で表示されるということが多くの記事で発生して、テンプレートの変更は差し戻されることになります。ほぼ間違いなく。Waiesuさんのおっしゃるようにテンプレートの変更はプレビュー時に警告文を出すようにすることにとどめ、徐々に移行を促していくのが現時点で現実的かつ確実です。その方法でもある程度のスピードで移行は進むと思いますよ。--Na's sky 2016年11月4日 (金) 22:23 (UTC)

text: 「列数指定ができなくなる」なんてことにはしていません．（私は別になくしてもいいとは思っていますが．）そんなことさえ分からずに議論に参加されるのは迷惑でしかないのでご遠慮ください．新規作成 (利用者名) （会話） 2016年11月5日 (土) 02:31 (UTC)
replies: text: : 非推奨にするって書いちゃうってことは、列数指定を行うたびに自警が飛んできて会話ページで絡んできたりするわけですよ。jawpってそういう所なんです。ですから、事実上できなくなります。そして、非推奨ってことは列数指定はどんどん列幅指定に直していかなけりゃならないんだなと言う自称草取り係が大量発生します。jawpが列幅指定で埋まっちゃいます。jawpってそういう所なんです。そして、列幅指定されたものを列数指定に戻すフィルタを作る事は、かなり面倒なはずです。事実上列数指定の排除に向けて舵を取られていると言うことにご自覚が無いのですか。

text: : 列数指定されているのもは、モバイルなら1、モバイルでないならそのまま、もしくは2に置換する程度の緩い改善を検討するくらいでよし。列幅指定を推奨するようなあらゆる文言に反対します。しかしスマホの隆盛、という事情を考えますと、「3以上の列幅は推奨されません」、程度の記述を行っておく事は、実情としてやむを得ないでしょう。執筆者に一々最適な列幅まで考えさせるなんてナンセンスもいい所です。バカげてます。そこらへんを何も考えずとも適当・適切にやってくれるから、テンプレートも便利なんですよ。どちらかと言えば列幅指定こそ、非推奨と言うか、せめて「非推奨と言うわけではありませんが、必用となる場面はほぼないでしょう」くらい書いて置いて頂きたいもの。執筆者への指示を肥大化させず（列幅を適切に考えろなんて、まさにどうでもいい指示の肥大）、むしろ楽ができるように改善していってください。列数指定の非推奨文言の追加には強く反対します。除去を求めます。大体、defaultが列数指定なのに、defaultが非推奨ってなんですかそれ。拙速すぎでしょう。1週間2週間を争って改変する問題ですか。また、enに準拠じゃいけないんですか。どうなんですか。どうなんですか。どうなんですか。--Hman（会話） 2016年11月5日 (土) 16:44 (UTC)

text: : 追加質問です。reflist、このテンプレートは何万の記事からリンクされていますか？もし事実万単位の記事からリンクされているのであれば、ここの数人でどうこう決めていい問題ではありません。10/15以前の文書・コードにロールバックした植えで、仕様・運用の変更については「Wikipedia:お知らせ」およびコメント依頼で多くの人を募り、総合的にご意見を伺うべきです。これは「ウィキペディア全体に大きな影響を及ぼしかねない大規模な変更」と考えます。理屈の上ではjawpには100万の記事があり、そのほとんどに出典が貼付されています。うち半分がreflistを使っているとすれば、50万記事に影響を及ぼすことになります。実際にいくつなのか、私はすぐに実測できる方法を知りません（個人的にはしっかりした、本格的な記事ほどreflistが多くなると考えて居ます。refが多くなればなるほどreflistの各種機能が有益になりますから。私は大きな記事を書くことが多かったので、ほぼreflistばかり使っていました）。ですからまず、実際にどの程度の数の記事でreflistが使われて居るのか、お教え頂けませんか。--Hman（会話） 2016年11月5日 (土) 17:07 (UTC)
*  61.46.104.165 2016年10月22日 (土) 18:25 (UTC) による Template:Reflist/doc の改変は、1.お知らせどころかコメント依頼(提出されたのは10/25です)すら出されていない状態で、影響の大きなテンプレートの運用方法変更や仕様の変更について、周知が不徹底のままわずか数名の議論で行われたこと。2.かようなテンプレートであるにもかかわらずわずか一週間程度で拙速に変更が行われたこと。3.わずか数名の中でも賛否両論であり、合意とは見なせないこと。以上の理由により、非推奨の文言を除去するかたちで、事実上の原状復帰を行いました。ただし列幅指定については除去する必要が無いため、そのまま残してあります。列数指定→列幅指定と言う順序で記述してあるのは、単にdefaultが列数指定だからです。特に重要なテンプレートやその説明、方針・ガイドライン等につきましては、今後は十分な広報と意見聴取、および慎重な議論の上で改変頂きたく思います。--Hman（会話） 2016年11月5日 (土) 17:48 (UTC)

text: :Hmanさんももう少し議論とテンプレートの現仕様・仕様案を理解してからコメントしてください．列数指定は環境によって可読性が落ちます．スマホだけじゃないんですよ？ 私の案のように変更すれば今まで通りの書き方でも問題なく使えるということもご理解ください．何も考えず  や  とだけ書いときゃいいんです．en準拠なら列数指定は非推奨ですね．それから現仕様のdefaultは列数指定ではなく列数指定および列幅指定です．新規作成 (利用者名) （会話） 2016年11月5日 (土) 23:24 (UTC)
replies: text: :: 一つ一つ片付けていきましょうか。このテンプレート、何万記事で使われて居るのか、調査されましたか。まずはここからお答え願えますか。私に対してだけではないのですよ。コメント依頼から来られる方もいる。現時点ではROMっていらっしゃる方もいる。将来過去ログとして残りもする。--Hman（会話） 2016年11月6日 (日) 05:52 (UTC)
replies: text: :::こういう風に聞いてもらえれば答えられるんですけどね．Template:Reflistからすぐにわかるんですけど今日の18:15 (JST) 時点で391003件だそうです．新規作成 (利用者名) （会話） 2016年11月6日 (日) 09:16 (UTC)
replies: text: :::: はは、どうもすいません。1年半ほど全く休んでおりましたもので、mediaWikiも色々変わっており戸惑っております次第です。全体で約100万記事ですから、ざっくり言えば約4割の記事で用いられていると言う認識でOKですか？--Hman（会話） 2016年11月6日 (日) 14:14 (UTC)
replies: text: ::::: そういうことになりますね．そのうち列数指定や列幅指定がどのくらいあるかは下にWaiesuさんがコメントをくださっています．新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)

text: Hmanさんの懸念は非常によくわかります。それについてお答えになっていませんが、どのようにお考えでしょうか。過去にはTemplate:和暦にかかわる編集合戦が多発していましたよね。それに似たようなことがあるのではないですか。あと「何も考えず 何も考えず  や   とだけ書いときゃいいんです．」ってさすがにひどくないですか。画面の向こうにいるのは人間ですよ。--多摩に暇人（会話） 2016年11月5日 (土) 23:46 (UTC)
replies: text: : 答えてるつもりですが具体的にどれに答えてないとお考えなのですか？和暦については知らないので何とも言えません．くだらない揚げ足取りはご遠慮ください．新規作成 (利用者名) （会話） 2016年11月6日 (日) 00:23 (UTC)
replies: text: ::2016年11月5日 (土) 16:44 (UTC)と2016年11月5日 (土) 17:07 (UTC)の質問にはほぼ答えていないですよね？あと暴言を撤回する気がないことはよくわかりました。--多摩に暇人（会話） 2016年11月6日 (日) 00:33 (UTC)
replies: text: :::ですから具体的に書いてください．（同じようなことを3人にいうのもあれですが）議論をろくに読みもせずにおかしなコメントを残すのはやめてください．私が意図していないことを勝手に解釈して暴言と言われても困ります．議論妨害・個人攻撃はおやめください．新規作成 (利用者名) （会話） 2016年11月6日 (日) 04:05 (UTC)
replies: text: ::::全部答えていないのだから時間を指定していますよね？意図的にわからないと言ってませんか。また私のコメントが議論妨害、個人攻撃と主張されるのではあればしかるべき場所にご報告いただければと思います。--多摩に暇人（会話） 2016年11月6日 (日) 04:42 (UTC)
replies: text: ::::: 「何も考えず  や  とだけ書いときゃいいんです」といいますが、私が直すまで列数指定は非推奨になっていたじゃないですか。一体何を言っているんですか？？本気で意味がわかりません。何度でも、強く申し上げます。執筆者に列幅を指定させるようなバカな企てはただちに停止されるべきです。テンプレートなどの作成者は、言わば裏方です。花形である執筆者を助ける為の作業であるべきで、足を引っ張るようなことがあってはなりません。可読性に配慮する余り、執筆者に不利益を与えないで下さい。こんなもの混乱が発生するに決まっています。「和暦」については調べてきて下さい。和暦問題すらよく解らないなら、お願いですから、触らないでください。本当にお願いします。コミュニティの強い合意が無い限り、このテンプレートの仕様や運用法は、大きく変更されるべきではありません。繰り返し指摘しますが、最低限お知らせくらいは打つべきものでしょう、これ。--Hman（会話） 2016年11月6日 (日) 05:52 (UTC)

text: ::::: 今ひとつ申し上げます、「何も考えず・・・」に「その言い様は酷い」と諫められ、何故その行為が「くだらない揚げ足取り」となるのか、これもわかりません。どういうロジックであるのか、ご説明頂けますか。具体的にお願いします。また、諫められても暴言を撤回されない人に「暴言を撤回しない旨了解」と申し上げる事は、個人攻撃とは言えないですよ。また、多摩に暇人氏が議論を妨害した様子は、私には見付けられませんでした。--Hman（会話） 2016年11月6日 (日) 06:37 (UTC)
replies: text: :::::: 私の案ではは列幅指定なんですからちゃんと読んでたらそんなおかしな疑問は出ないんですよねえ．あなたが「そこらへんを何も考えずとも適当・適切にやってくれるから、テンプレートも便利なんですよ。」って書いたからそれに返事したんじゃないですか．つまり最初に暴言を吐いたのは他でもないHmanさんということになるわけですね．新規作成 (利用者名) （会話） 2016年11月6日 (日) 08:38 (UTC)
replies: text: ::::::: すいません、ちょっと意味がわかりません。私の案ではとかどうとか言い出すのもわかりませんし（他人にものを伝えるべき時、何かを省略するのであればそれは特記無き限り一般論でなければ混乱するだけだと言うのは、分別のある社会人であれば誰でもわかっていることです。頼みますよ）、先に暴言を言ったとかもわかりませんし、先に暴言を言われたから暴言を返してもいいんだと言う理論？も理解できません。いやその、中学生の喧嘩じゃないんで、そこは一旦落ち着いて下さい。とかく、一旦仕切り直しのつもりでかかることです。また、大々的な告知が行われない限り、あなたがどのような演説をされようとも、全体合意が得られることは物理的に難しく、当該テンプレートのような重要なテンプレートの基本的な機能および運用法は従来のまま固定となります。一度深呼吸が必要な局面です。--Hman（会話） 2016年11月6日 (日) 14:22 (UTC)
replies: text: :::::::: 直前に「私の案のように……」って書いてて分からないわけないでしょう．おちょくってるんですか？ お願いですからちゃんと読んでください．後半は私は暴言を言ったつもりはない，私のが暴言ならHmanさんのも暴言だ，ということです．新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)
(質問) Waiesuさんにお伺いします。貴殿は列幅の直接指定推奨に前向きなお考えをお持ちのようですが、何故賛成であるのか、えーぶっちゃけ新規作成氏はいないものと考えて(笑)、ご自身が、何故列幅直接指定が好ましいとお考えなのか、大いにプレゼンして頂けませんか。なお私が列数指定、ただしやむを得ないのでモバイルでは解除、と言う考えを持っているのは、「執筆者にいちいち最適な列幅なんか数えさせんな、それを自動化するのがテンプレートやろが！大体絶対自警のさばるし！」と言う点と、「数値の直接指定は邪悪、これがコーディングの基本。全体合意も無い中強引に直接指定推奨とし、それが多発すれば、列数指定に戻すのは非常に困難」と言う点です。テンプレートをいじられるレベルの方であれば、当然の心得と存じます。そしてもう一点。何にしましてもお知らせ通しての広報や強力な全体合意の無い中、この重要なテンプレートの拙速な仕様・運用の変更は絶対に行われるべきではない。これについては問題無くご同意頂けると思っておりますが、その様な認識でよろしいですか。--Hman（会話） 2016年11月6日 (日) 07:07 (UTC)

text: まず1点目、列幅の直接指定が好ましいという理由ですが、ここらへんは個人の好みの範疇になると思うのですが、数値の絶対指定は柔軟性がない（アクセス環境の多様化についていけない）と考えるからです。例えばと指定すれば、横幅が30×n em以上あればn列になりますし、30emに足りない満たないときは1列、というように柔軟性を確保できるわけです。脚注の見やすさは文字の数・密度（＝1列の幅）に依存しますから。一方、にすれば、何があろうと横幅が3emだろうと3列になるわけで。MediaWiki:Mobile.cssでモバイルビューのときは強制的に1列にしよう！というのもありっちゃありですけど、それじゃあ、PCで古い画素数の少ないディスプレイや、画面分割したときはどうなるの、ということになります。MediaWiki:Common.cssでウィンドウ幅を検知して割り振ろうというのも一時は考えましたが、まだCSSが開発段階で確定していないですし、小さい画面でも2K/4Kが出てきて文字の大きさとピクセル数の関係が他のディスプレイとは違うということもあります。

text: 「自警がのさばる」という懸念についてはいまいちピンと来ないのですが、その自警という方々が列幅を調整してくだされば、執筆する方の負担は減るのではないでしょうか？ 私が考えている案内文というのは「負担にならない程度に移行してください」程度のもので、別に「こいつ案内を無視してやがる！バシバシ！」とかいうことは思いません。みたいなのがあれば一番いいんですが、JSを駆使しないとできないので、あまり現実的ではないでしょう。（全ての脚注の文字数を数えて平均？偏差？を取って列幅を決めるみたいな感じですかね？ 正直、脚注をまじまじと見る方がどれくらいいるのか謎ですが。）

text: 2点目については、特にテンプレート本体の編集については、拙速も何も、え？自分そんな提案したっけ？みたいな感じです。それで不具合をいろんな方から指摘を受けたみたいですが。私もコメント依頼などでは告知すべきだったと思います。（390997ページで使用）も（418780ページで使用）と同様に全保護していもいいと思います。新規作成さんへの質問を先に答えてしまってすみません。--Waiesu（会話） 2016年11月6日 (日) 08:27 (UTC) 誤字修正。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC)
replies: text: : 一点目について。好みの範疇とお考えの旨、了承致しました。私も同感です。ですから、列数指定を推奨にしろとは申し上げておりません。さて、列幅直接指定にした場合の問題は、「最適の列幅」を誰かが逐一考えなければいけないことになります。そして、最適解が非常に見付けづらく、変な押し付け合いになる可能性がある、コミュニティが混乱する可能性があると思うんです（自警がのさばると言うのは、今回のケースではemNNでは見にくいからemMMにしろや！と、会話ページに自警が凸ってくることです。何度も見ていますし、何度かやられてもいますｗ 指示を肥大化させルールを細かくすると、執筆者は自警におびえながら活動しなければならなくなり、私のように嫌気が差して放り投げてしまう、そういう可能性もあります。和暦問題については、なんでしたら私にメールで送って下されば、説明致しましょう。ちょっと古い利用者であれば、結構知っているネタです。しかしなんですか、最適な列幅、いちいち算出するのってばからしくありません？もっとも、列数指定にした場合も、最適の列数を考えなければならないのですが、ほぼ1か2の二択ですから(笑)、特に問題とはならないでしょう。柔軟性がないと言えばそうですが。仰るとおり、|auto こうできればこれが一番です。まあ、autoではき出される書式がどの程度見やすいのか、適切なのかは別途検討が必要ですが。ただモバイルかどうかはともかく、解像度までは察知・・・できます？できないなら、やはりモバイルなら1決め打ち、でなければそのまま（1か2。現状を考えれば3以上はないでしょう）。こういった感じが適切でないかと。

text: : 二点目につきまして、当テンプレートやその運用法の拙速な変更について、慎重な姿勢である旨、了承致しました。もしまた暴走する方が現れましたら、できるだけ早くロールバックし、必要なら管理者伝言板への通報もお願い致します。話に聞いて覗いてみて、あまりにも拙速に過ぎて、びっくりしましたよ。信じられない杜撰さです。

text: : 細かな画面分割の可能性は考えていませんでしたね。これは日時をかけてこちらでも考えてみます。確かにそう言った運用法を・・・どの程度の人が行われているかはわかりませんが・・・少数派と全く無視すると言うのも問題です。しかし極めて特殊と強く想定されるのであれば、jawp側で合わせる必要もなく。ブラウザのレンダリングにまで責任が持てない、と言う意味もありますから、jawp側で配慮できるのは一定の所までだ、と言うのはございますでしょうね。そして、reflistは約40万ページ、全体の4割ほどものページで使われていましたか。勉強になりました。個人的な感覚として、行っても半々くらいかなー。でかい記事はreflistが便利だけど、小さい記事はそうでもないし、過半数はないだろうと思っていましたので、大体想定どおりですｗ 当面はdocも含めて、実際に物理的に保護をかけるかはともかく、「編集禁止」にすると言う根本的なところのご提案に、強く同意致します。

text: : ・・・・・・docの最終更新、私なんですが、おかしなところはありませんよね？^^; まあ、推敲レベルなら問題ないでしょう。

text: : さて、質問ばかりで申し訳ないのですが、私、1年半ほど休眠していました。が、それより以前は、emなんて使っている人、見た記憶がないんですよ。この1年半でem使う人が増えたと言う事実でもあるのでしょうか？これについては具体的な数字を出すのは大変ですから、Waiesu様個人の印象で結構です。一線級の現役執筆者の方のご意見は、参考になります。特に、もし最近のGA/新記事賞/強化記事賞などで用いられているものをご存じでしたら、是非ご紹介頂きたいです。やはりそういうもので見てみるのが、一番参考になりますので。--Hman（会話） 2016年11月6日 (日) 13:46 (UTC)
replies: text: :: 凸ってくる利用者が個人的にはいるとは思えないのですが、実際にいるならば残念ですね。日本語版の勢いがなくなっているのもそれが原因なのでしょうか。CSSのメディアクエリを使えば解像度も察知できるはずです。申し訳ないのですが、いろいろすっ飛ばして情報だけ載せます。group指定、refs指定していないもので検索すると、は33,891件、には1,620件マッチするので（少し変動あり）、かなり列数指定が多いようです。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC) 誤字修正。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)
=== 列数指定時の列幅に下限を設定する提案 ===
ここまで書いておいてなんですが、他に案が思いついたので列数非推奨の提案への賛成を取り消します。代わりにMediaWiki:Common.cssで標準の列幅列数の指定（列数指定時の列幅に下限を設定する）を提案します。具体的には
.reflist {
	-weblit-columns: 1 15em;
	-moz-columns: 1 15em;
	/* ベンダープレフィックスはなくてもいいかも */
	columns: 1 15em;
}などの指定を現時点で検討しています。これは標準の列数を1、最低列幅を15em（例）にしています。例えばと指定すれば、各列の幅を15em以上確保できれば5列、確保できなければ15emを確保できる最大列で表示されます。と指定すれば、上書き最低列幅に上書きされます（これだと列数が1のままなので、テンプレートを変更してcolumn-count: autoを指定させればいいはず）。
この提案について、みなさまのご意見をお聞かせください。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC) 誤字修正。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC) 下線部追記。--Waiesu（会話） 2016年11月7日 (月) 05:40 (UTC)

text: まずは長い余談から・・・。実際に会話ページに凸られた事も、メールで凸られたことも、凸られたのをお助けしたことも、山ほどあります（苦笑）。まあ本件の本論ではあまりない訳ですが、スタイルマニュアルなど、執筆者にとっては「大体」の努力目標でいいんですね。彼らの仕事はお持ちの知識を元に、文献を調べ、記事に反映することです。乱暴に申し上げれば、それ以外の所は適当でいい。そこを口かやかましく言うと逃げちゃいますよ。私みたいに。逃げちゃった人も沢山見てきましたよ。伊達に2005年から10年、一応やってはおりませんｗ 本格的なそれは2011年頃からですが。

text: さてそれはそうとしまして。20:1とはまた離れたものですが、むしろ1/21近くもem派がいることにびっくりしました。もっと少ないのではないかと。何千という記事のソースを見ましたが、実際にお目にかかった記憶が本当にゼロなのです。検索ワードの悪戯で簡単に数倍、数分の一、になるものだとは思いますが・・・。いずれにしましても、この情勢では、emを推奨にしよう、と言う動きには、なりようはないでしょう^^;。ただし熱心なロビー活動により、数年後に情勢を変える事は可能かとは思います。

text: 新たなご提案については・・・うん、値を適当に取れれば、感触はいいです。ですが、適当なFA/GA記事を引っ張ってきて、スクリーンショットの比較でプレゼンするのが解りやすいのではないでしょうか。執筆者の殆どは特にテンプレートに詳しくありません(作成や改造などを行える人は極僅かです)。よって、ご提示の文書だけでどのようになるか明確にイメージできる方は、非常に限られています。ですが、使用するのは執筆者ですので、ほとんどの執筆者に理解できるプレゼンでなくてはと^^;。また、具体的な変更には、「各refの9割は、n文字に収まっているようだ」と言うデータが欲しい所ですね(ただ、1行に収まらんと話にならん！とか、例外的に2行なんて生じるのはそもそも当たり前なんだから2行前提でよし！とか、スマホの縦画面でみにくいのなんか、画面が小せえんだからそもそもしょーがねえだろうが！とか、色々お考えはあるもので、簡単ではないでしょう)。全記事サンプリングなど無理ですので、FA/GAに絞ってでもできませんかねぇ・・・。

text: で、仮にまあ、多少の調整はあれど、それでいけるとなりまして。

text: これ「お知らせ」に載せなくていいんですかね・・・。ここで合意が得られたとしても「数人」です。ちゃんとした告知と強力な合意の無いまま事を推し進めますと、今まさに私が行っているように後で異義が入ります。私なら、お知らせと同時に井戸端にもネタを放り込みますよ。私が言うのも変ですが、後で異義が噴出するほど面倒なことはありません。それまでの作業が台無しになります。まずは広い告知、これをお勧めしたいです。とかく相手は100万分の40万記事です。

text: なおテンプレート屋の暴走として一番思い出深い(というか個人的に深刻だった)のは「Template‐ノート:複数の問題」です。多少記憶がぶれている部分もあるかもしれませんが、おおよその流れとしましては、yyyy-mm/yyyy-m/yyyy年m月、など、自由な形式で年月が表記可能だった各種テンプレートを、ある人物がyyyy年mm月(明らかに一番タイプ数が多い！)、でしか通らなくするようにしました。その後、botで各記事を絨毯爆撃で置換しようと企みました。これといった合意もなく。本人の供述によれば、まあ早く言えば、「その方が鯖負荷軽いし」とのことで・・・。この時は私が出張って、全体合意のないまま影響の大きな変更を勝手に行わないように、なんとか取り纏めました。reflistもほぼこの案件に匹敵する規模で、執筆者に影響を及ぼすでしょう。合意も無いまま拙速に行うと、私より怖い人が飛んでくるかもしれません(私は怖くなんてないですよ！)。この様な事態に陥らないように、慎重に慎重を期して、検討しましょう。--Hman（会話） 2016年11月6日 (日) 19:38 (UTC)
replies: text: : （何でも執筆者さんに求めるのは間違いですね。）一番多いのは指定無しのっぽいですね（69,860ページくらい）。スクリーンショットで見てもらえばいいかもしれませんが、比較するとなるとそれはそれはものすごい量になりそうなので、保留とさせてください。代わりにHelp:WithJS withCSSを使用して、皆さんに好きなページで体験してもらう、という感じにしたいと思います。現状では体験できるjs/cssはMediaWiki名前空間に限られているので、利用者名前空間でも適用できるようにこちらで提案しています。（MediaWiki名前空間にテストcssを作ってもいいかもしれませんが、汚したくないし突っ込まれたくないので。）FA/GAの脚注の文字数についてはデータをとってみようかなと思います（今週末になるかもしれません）。

text: : 新案を提示しましたので、それについてのお知らせも含めて、お知らせに載せてきます。（前レスで言及するのを忘れていましたが、docについては問題ないと思います。）--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC) 一部取り消し。--Waiesu（会話） 2016年11月18日 (金) 14:56 (UTC)
replies: text: :: そうですね、そちらのサンプル提示の方式については、お任せします（リンク先を拝見しましたが、通るにしても時間を要しそうですね）。Waiesu様ならまずもって間違いはない、でしょう。こう言った影響の大きな変更、reflistなどについては「システム自体の変更」にも準じるものなのですから、とにかく焦りは禁物です(mediaWikiを翻訳不如意なままアップデートして大混乱に陥った事件もありましたね・・・)。もし、これ以上ほとんど人が来ない、議論が進展しない、と言う状況なのであれば、「ほとんどの人が現状で問題がないと考えている」、つまり変更は不要だと言うのが結論と解するよりありません。何事も、充分なベテラン執筆者が20名程度集まり、喧々諤々の議論の結果、仕様変更が妥当だと言うことに落ち着いた時に、変更すればいいのです。変更の可能性から論じられるべきで、最初に変更ありきではいけません（なお、お知らせだけでなく井戸端にも放り込むのも効果的です）。大体皆さん、日々の生活もありますし、執筆の方もお忙しい。一連の作業については数ヶ月は見てかかられるのがよろしいでしょう。かつ、お知らせ（や井戸端）を見ていらした、テンプレート（やプログラミング）など何もわからない方が、一目見て従来の形とどう違うのかがわかるかたちで（SSなどで）提示されていれば、話は早くなります。「わかんねーからしらんわ」と言う人が多くなることは、改変を望む側に不利になると思います。改変については積極的な推進意見が必要なところですからね。コメント依頼による議論の解決を求める時に、これまでにぐっちゃぐちゃになってしまったお話を一旦まとめて、論点の整理をしてから、リセットのつもりでコメント依頼を行う事はよくみられることです。何せ、コメント依頼（今回はお知らせも）をご覧になっていらっしゃる方は、ここまでの議論はよくわからない。よくわからない事を言っている人もいる。コードで書かれても表示がどう変化するのかがわからない。テンプレートのソースなんて見たことすらない（恐らくですが、95%の利用者はこれでしょう）。これを当たり前と考えるべきです。なお、明らかなバグフィクスについては特に問題はありませんが、基本的にシステムに関わるテンプレート制作者は、enにあるものの移植の他は、執筆者側からのリクエスト待ちくらいでよく、そういう事がない限りは普通に記事を書いていればいいんじゃないかなー、と思います。--Hman（会話） 2016年11月7日 (月) 05:58 (UTC)
replies: text: ::: バグといっても過言ではないこんな明らかな不具合は，私のやり方はまずかったですが，さっさと直すべきです．参考に，茨城電気 (1931-1942)の表示例を貼っておきます．Waiesuさんによれば5列や6列もあるんですよ．新規作成 (利用者名) （会話） 2016年11月8日 (火) 03:11 (UTC)

text: （Waiesuさんあて）私としては改行されまくって可読性が著しく損なわれるような状況さえなくなればいいです．Template:Div colなんかもそうです（英語版では列数指定は廃止されてます）．30emと指定すれば～がよく分からないのですが，テンプレートを変更すれば30em (≥ 15em) でこれまでと同じように働くという理解でよいのでしょうか？新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)
replies: text: : すみません言葉足らずでしたね、列幅（15em以上でも以下でも）と指定していてもこれまで通りということです。ですから、列数指定に対して、列幅の下限を設定するという認識でいいと思います。についても同様の懸念があるならば別途提案したほうがいいかもしれません。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)
replies: text: :: なるほど，分かりました．ありがとうございます． と  でも状況は同じなので，まとめてやればいいでしょう．新規作成 (利用者名) （会話） 2016年11月8日 (火) 03:11 (UTC)
一連の議論に新参ではありませんが、現状で問題がないとは考えておりませんので、Waiesuさんのご提案に賛意を示しておきます。
前節で脚注の内容に合わせて列幅を設定すればよいと申し上げましたが、列幅を設定したときにその幅が適用されるのは、脚注の内容に加えて1.や2.などの脚注番号の部分を含めた幅ですので、列幅は脚注の内容よりやや大きめに設定する必要があります（ひとつの脚注を一行で表示させようとする場合）。
Hmanさんのおっしゃるように、ひとつの脚注を一行で収める、ひとつの脚注が二行以上にまたがるのを容認する、両方の考えがあると思いますが、ほとんど短い脚注だけれどもひとつだけ長い脚注があるという場合（最長の脚注に合わせると空白が大きくなってしまう）も考えられますので、そこは記事に合わせてある程度柔軟でよいと思います。
前節での記述は少々不明確だと思いましたので、訂正のうえ、一意見として提示いたします。新たなご提案と通じる部分もあると思いますので。--Na's sky 2016年11月7日 (月) 12:53 (UTC)
（どこにインデントすればいいか悩む）えっと、閲覧者の環境は各々異なりますし好みもそれそれですから、ほぼ同一と考えれるMobileはMediaWiki:Mobile.cssで強制的に段組なしにして、その他の利用者は各自のcssで設定できるようにヘルプページへの案内リンクなどでサンプル提供するなんて方法ではだめなのかな？それが一番もめなくって、各自自由に出来る方法だと思うのですが。--Vigorous action （Ｔａｌｋ/History） 2016年11月7日 (月) 13:59 (UTC)

text: そもそもが、スマホ環境での過度な改行が問題だー、から始まっていますので、Mobile.cssのそれは、技術的に問題なく可能な変更なのであれば、落としどころじゃないかなと思います。後段のご案内の充実、についても、適切な文言を提供できれば効果はございますでしょう。唯一問題があるとすれば、「流れのただの閲覧者諸兄」対応としては完璧ではないと言う点なのでしょうが、どこまで対応すべきかと言う点すら、いや変更が必要なのかと言う点すらまだ全体合意が得られていませんので、今後、別にそれで全然いいんじゃね？となる可能性も当然ございますでしょうね。そもそも元々が、Mobileでない環境であれば、それほど躍起になる必要のないネタという気もします。結局は好みであると言う点につきまして、強く同意させて頂きます。

text: まあまだ、お知らせを打った直後です。今回このようなご提案を頂けましたように、多くの方に見て頂ければ新しいアイディアも出てくるものです（まあ、変える必要ない！と言うご意見が多数出てきたりする可能性もありますけど）。のんびり参りましょう。--Hman（会話） 2016年11月7日 (月) 16:40 (UTC)
  および  でも状況は同じだと思いますので，こちらに誘導しました．これらを含めて3つのテンプレートに対し，Waiesuさんの案を適用することに賛成します．著しく可読性が落ちるものを「好み」で済ますわけにはいきません．モバイルでの1列強制には反対します．必ずしも2列（以上）で表示に問題があるわけではないからです．パソコンでの表示でも列数指定では問題がありますし，スマホから必ずモバイルビューで見るわけでもないし，全く解決になっていません．新規作成 (利用者名) （会話） 2016年11月8日 (火) 03:11 (UTC)

text: Vigorous actionさんのご意見に対して、新規作成さんと全く同意見です。私も例をあげておきます（いつでも消せるように外部サイトですが→「ヘリコバクター・ピロリ」のスクリーンショット）。1366x768のディスプレイで2分割したときの画像です。左側はオリジナル、右側は提案通りreflistにcolumns:1 15emを設定した場合です。なお、columns:1 20emにすると1列になるようでした。--Waiesu（会話） 2016年11月9日 (水) 09:49 (UTC)

text: * WCAG 2.0（W3C勧告）ではカラム幅には相対サイズを使用することが推奨されています。--Waiesu（会話） 2016年11月9日 (水) 10:21 (UTC)
replies: text: :* Waiesuさんがあげられたヘリコバクター・ピロリですが当方で複数の閲覧環境で確認してみましたが、ガラケーのような特殊な端末以外では右の写真より文字数の多いもので左のような写真の状態になる事はありませんでしたので、あんまり共感できないんですね。
replies: text: :: Wikipediaへのアクセス種別では細かな数字は失念しましたが「移動体端末によるアクセスがかなりある。」という事実は明らかであり、そういった方に向けて財団はモバイルビューとモバイルアプリを公式に提供しています。なので、Mobile.cssの変更なら積極的に賛成します。

text: :: ただ閲覧環境は基本的に閲覧者の責の下に選択されますから、モニターが小さい・モニターを2分割とか、モバイル端末でモバイルビューを使用しないなどの場合「見難さを許容する」か「各自で対策する」かだとおもいます。

text: :: ただのリンク先のHelp:脚注/読者向けなどに、個人cssの作成手引きなど対策に向けての手引き文章を作成するのまでは否定しないということです。

text: :: もっと根本的な解決方法としてを廃止してに統一するといった解決方法もありますよ。--Vigorous action （Ｔａｌｋ/History） 2016年11月12日 (土) 02:02 (UTC)
replies: text: ::: まあ、閲覧の環境は人それぞれですからね。今回の提案は、特に今までの指定方法・記述を否定・変更するわけでなく、執筆者に負担をかけませんので、デメリットはないかと思います。逆に、Vigorous actionさんがおっしゃる「モニターが小さい・モニターを2分割」にも配慮され、以下に新幹線さんが述べているような編集合戦も防ぐことができ、大きなメリットがあると思っていますが、Vigorous actionさんはどうお考えでしょうか。（廃止は…マジレスしなくていいですよね）--Waiesu（会話） 2016年11月12日 (土) 02:22 (UTC)
replies: text: :::: 一番簡単な解決方法である廃止について検討をもしないってのに強く違和感を感じる。そうすれば、モニターの大きさや、使用方法。さらにはモバイルでのアクセスなど皆さんが問題視されてることが解決でき、カラムの数などをめぐっての編集合戦なんかも発生しない。を廃止してにしても、Wikipediaの記事品質に変わりはないんじゃないかな？

text: :::: さて、こういうのって個人の使用環境・感覚によって適正値だと思うものが異なるので、時間かけて不満が残る人出すより「各自の責任において好きにしてよ。やり方は教えるから。」が不満もでずみんなが納得する方法で、合意形成しなくってもいいわけだし時間が短縮できるってのもあるから一番メリット有るんじゃ無いですか？--Vigorous action （Ｔａｌｋ/History） 2016年11月12日 (土) 03:13 (UTC)
replies: text: ::::: 本心でおっしゃっていたのであれば、申し訳ありませんでした。40万以上の記事に使用されていて、非常に多くの他言語版でも使用されている実績から、廃止は非現実的で、コミュニティの賛同を得られないと思っております。もしVigorous actionが廃止したいとお考えならば、別途提案をお願いします。

text: :::::閲覧者それぞれに任せるとすると、ログイン（アカウント作成）させてカスタムCSSを作らせるか、ブラウザの拡張機能なりでカスタムするか、になると思うんですが、それでは結局そういうことができない方の不満は解消されないと思います。

text: :::::私の提案は、「編集者の意図したスタイル」「閲覧者が望むスタイル」を折衷したもので、双方にとって1番不満の少ないものだと考えています。--Waiesu（会話） 2016年11月12日 (土) 04:23 (UTC)
replies: text: :::::: 40万以上の記事に使用されていて、非常に多くの他言語版でも使用されている実績があろうと、閲覧に大きな問題が発生しているのなら、廃止するというのも検討の余地に含めるべきです。さらにそれが記事品質に影響を及ぼさないのであればなおさらです。ただ、廃止しろといってるのではなく、廃止を検討する事が一切論点に入ってこないのは違うんじゃないのか？ってことです。

text: :::::: wikipedia日本語版は百科事典を編纂するプロジェクトですが、それが属するWikimedia projectは非営利の教育projectなんですよね。営利目的なら利用者を増やさないとすぐに経営的に成り立たないということで閲覧者に媚びる必要があるとは思いますが、幸いなことに財団は、資金的に余裕がある訳でもないかもしれませんが切羽詰まった状況ではないとおもいます。なのでMediawiki:common.cssといった閲覧者の目に届かないところで不満が残るかも知れない形で設定するより、

text: :::::: 表示の変更を希望する閲覧者は、ログイン（アカウント作成）してカスタムCSSを作るか、ブラウザの拡張機能なりでカスタムすると表示を変更出来ます。するかしないかは、あなたの判断です。ただし、サンプル提供が有りますのでご自身にあったものを使用することもそれを変更することも出来ます。であれば等しく選択肢がありそれを選択するのかどうかは閲覧側の問題ですし、cssって何？というような人の興味を引き新たな知識取得の対象になるかもしれません。

text: :::::: 記事内容に関して閲覧者を戸惑わせてはいけません。ただ、表示方法について万人が納得する正解って多分ない。なら、自分の正解だと思うもので表示してもらうのが次善の策だと思うんですよ。--Vigorous action （Ｔａｌｋ/History） 2016年11月12日 (土) 06:15 (UTC)
replies: text: ::::::: 単にスクリーン幅に対して段組みが多くなると見栄えが悪くなるという話なだけで、閲覧に大きな問題が発生しているわけではありません。編集合戦が発生するかもしれないから廃止しようというのは、それこそ「和暦の悲劇」の再来ではないですか？ 簡単に廃止を検討するのは些か乱暴ではないでしょうか。--新幹線（会話） 2016年11月12日 (土) 08:47 (UTC)
replies: text: ::::::::: 個人的に対応できる事であるので好みに合わせて設定できる事を提案したが、それでは対応出来ないほどの閲覧に大きな問題が発生（『著しく可読性が落ちる』・『「好み」で済ますわけにはいかない』）との意見が提案者・新規作成（利用者名）さんの2名からあります。大きな問題があると言っているのは私ではなく、提案者・新規作成（利用者名）さんの2名なんですね。
replies: text: ::::::::: 私はで用を足すと思ってますから、は有ってもなくても構わないともおもいますし、スクロールがデフォルトだった時代にで一つの脚注でカラム3つぐらい書いてたものをみた記憶があります。読みにくいから勘弁してくれとおもいましたよ。

text: ::::::::: 過去にカラムの数で「1-2が見やすいが3以上に設定してあるのは見難くて・・・。」なんて事言ってた出典ガチガチ主義の元管理者もいます。

text: ::::::::: 閲覧者の環境が異なりそれによる適正値も変わってくるので設定値に総ての利用者が満足できないのであれば、個人的に対応するか廃止するのが妥当で早いんじゃないかと思います。一旦個人設定案内してしばらくたってから統計をとってデフォルトで設定する。なんかですと、そのスタイルが気に入らないひとでも個人cssで対応もできますから大きな反対はしませんけど。--Vigorous action （Ｔａｌｋ/History） 2016年11月13日 (日) 01:18 (UTC)
replies: text: :::::::::: 好みがどうこう以前に，閲覧に支障の出る状況を改善しましょうという話です．4文字ごとに改行されて閲覧に支障がないとお考えでしょうか？ Waiesuさんの案を使えば，（非常識な列幅指定をしない限り）そういう問題はおこらなくなるわけです．それと記事によって適切な幅は異なるのに「個人的に対応」ってどうやるんですか．新規作成 (利用者名) （会話） 2016年11月16日 (水) 12:37 (UTC)
replies: text: ::::::::::: 見えない・読めないではないので大きな支障はない。好みの問題だと言ってますが？--Vigorous action （Ｔａｌｋ/History） 2016年11月20日 (日) 05:53 (UTC)
replies: text: :::::::::::: 限りなく「読めない」に近い環境があるのですから、それは好みの問題とは異なると思います。--Waiesu（会話） 2016年11月21日 (月) 04:59 (UTC)

text: 最小のwidthを設定することで列数指定時における問題は解決されると考えられるので、賛成します。ところで、スマホ環境における改行の話ですが、モバイルビューに限って1列強制というのはできないのでしょうか？--新幹線（会話） 2016年11月11日 (金) 18:37 (UTC)
replies: text: :  ちょっと話が脱線しますが、以前の議論では列数指定を非推奨にすると「執筆者の負担（自警問題）」や「和暦問題」が起こるとの話が出ていましたが、そうした問題は列数指定の推奨/非推奨に関係なく、現時点でも起こりうる問題ではないでしょうか。「和暦問題」とは大規模な編集合戦のことを指しているのでしょうが、実際過去に（どこの記事かは忘れましたが）、「脚注の列数」を巡って編集合戦が起き、議論になったこともあります。同じ記事でも閲覧環境によって何列が適切かは変わりますから。むしろ列幅指定を推奨にし列数を可変にすれば、そうした編集合戦の抑制につながるのではないかとも考えられます（なお、widthの下限が設定されればこの問題はかなり解決されると考えているので、その場合は列数指定はそのままでよいと考えています）。執筆者の負担についても、そもそも段組みを使い慣れている人なら列数の指定方式が変わるだけでそこまで負担は増えないだろうし、段組みを使わない人には関係ないので、そこまで配慮する必要があるのかな…？ と思います。--新幹線（会話） 2016年11月12日 (土) 01:43 (UTC)
replies: text: :: 賛成ありがとうございます。モバイルビューに限って1列強制というのも可能です。しかし多くの場合は、スマートフォンの縦画面で閲覧すると、列幅の下限を15emとするだけで、1列になりそうです（スクリーンショット比較（1920x1080縦画面/横画面））。--Waiesu（会話） 2016年11月12日 (土) 01:58 (UTC)
replies: text: ::: なるほど、でしたらあえてモバイルビューで1列強制にする必要はないかもしれませんね。タブレットだと2列ぐらいあっても良さそうなので。--新幹線（会話） 2016年11月12日 (土) 08:47 (UTC)

text: 体験用にMediaWiki:Test/common.cssを作成しました。任意のページのURL末尾に?withCSS=MediaWiki:Test/common.cssを追加していただければ、提案中のCSSを体験できます。ウィンドウ幅を伸縮していただければ動作がわかりやすいかと思います。--Waiesu（会話） 2016年11月18日 (金) 14:56 (UTC)
replies: text: :ありがとうございます．いくつかリンクを書いておきます．和田アキコ（4列指定，幅が小さいと3列以下になる）（一方CSSなしでスマホ），2013年（30em，今まで通り）．私の下書きページだと全部一列になってしまいます．手塚賞もだめです．新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:34 (UTC)

text: :失礼，2013年はURLが間違ってます，やはり1列になります（直すのめんどうなのでそのまま……）．新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:40 (UTC)

text: :すみません，いろいろぼけてますね．私の下書きは列数のソースが違ってます．列数指定に対し体験するということでしたか．新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:42 (UTC)
replies: text: :: すみません説明不足でしたね。列幅指定されているものは、別途テンプレートを変更する必要があります。また、モバイルビューは、withJS withCSSをサポートしていないので、体験できません。体験できるのは、列数指定されているデスクトップ環境のみです。--Waiesu（会話） 2016年11月21日 (月) 04:59 (UTC)
*結局新たに反対は出ていませんし，列数指定の非推奨化およびWaiesuさんの案の適用ということで合意は得られたのではないかと思いますがいかがでしょうか．新規作成 (利用者名) （会話） 2016年12月2日 (金) 09:00 (UTC)
====下限 (2)====
 私が見る限り、賛成3、反対1、コメントのみ1、といったところのようで、また賛成者による反対者の主張への反駁に対する否定的なコメントも見られませんので、さらに1週間ほど待って反対がなければ、合意が得られたと解釈し、MediaWiki:Common.cssとTemplate:Reflistの編集を行いたいと思います。なお、テンプレートの編集については、
#列幅指定時にcolumn-count: autoを指定する（css指定に合わせて必要）
#廃止のお知らせを除去する（他の節でも指摘されているように現在全く使用されておらず、不要な処理を増やしているだけ）
を予定しています。（下書きをTemplate:Reflist/sandboxに書いていますのでご確認ください。）--Waiesu（会話） 2016年12月3日 (土) 15:05 (UTC)
 私の提案は列数指定の非推奨化を代替するものであって、私は非推奨化に賛成しません。（提案の意味がなくなってしまう…）--Waiesu（会話） 2016年12月3日 (土) 15:11 (UTC)
*いやWaiesuさんの案を適用したところで列幅指定の方が推奨されることに変わりはないでしょう．列数指定に対して表示がひどいことにならないようにするだけであって，ある人は40emくらいのつもりで指定したが別の人にとっては15emだったみたいなことはおこるわけで．私は代替だなどとは思っていませんでしたが，そのつもりなら（いやそのつもりでなくても）もうちょっと大きめの20emとか25emの方がいいのではないですか？ 15emでは小さいです．また，列数指定に対してはお知らせを出した方がいいかもしれません．使用数を見た感じ，20emなら指定列数と表示が変わることはほとんどなさそうですが．（ちなみに私のパソコン（小さい方だと思いますが）では18emで4列，19--24emで3列，25emで2列となるようです．）scrollのお知らせは別に今すぐ消してもいいんじゃないかと思いますが．新規作成 (利用者名) （会話） 2016年12月4日 (日) 03:34 (UTC)
**  ＞ある人は40emくらいのつもりで指定したが別の人にとっては15emだったそれで何か問題ありますか？元々スマホ等で列幅が小さくなりすぎるという話から始まったわけで、最低限の幅が確保されれば問題は解決すると思いますが。また、15emでは小さいと思ったらユーザーCSSで変更可能です。--新幹線（会話） 2016年12月5日 (月) 05:53 (UTC)
（1つ目）？？ だから列幅指定の方が推奨されますねという話ですが．(2) 新幹線さんは15emが最低限の幅だとお考えなのでしょうか？ (3) 20emでは大きいと思ったらユーザーCSSで変更可能です．（参考に）
<--15em
<--20em
<--25em
<--30em
幅はだいたいこんな感じです．新規作成 (利用者名) （会話） 2016年12月5日 (月) 10:34 (UTC)

text: : 幅が大きくなる分には幾ら大きくなっても閲覧に支障をきたしません。また列幅指定だとかなり前にKinketuさんが仰っていたように「ある人にとっては4列だが別の人にとっては7列」みたいなことも起こりうるわけですが、その点はどのようにお考えでしょうか。最低限の幅には拘っていないので20emの方が良いという意見が多ければ従います。---新幹線（会話） 2016年12月6日 (火) 00:53 (UTC)
replies: text: ::それぞれの環境に応じて列数が変わるのが列幅指定のメリットです．ある環境で7列だろうが10列だろうが，指定した幅が適切であれば，何の問題もないと思います．新規作成 (利用者名) （会話） 2016年12月6日 (火) 13:09 (UTC)
replies: text: ::: ＞それぞれの環境に応じて列数が変わるのが列幅指定のメリットです．必ずしもそうとは言い切れないと思います。1920×1080などといった高解像度の画面でウィキペディアを見る場合、本文自体がかなり横長に表示されると思いますので、それに合わせて脚注も横長になるのが自然な表示だと思います。もちろん、短い脚注がたくさんある場合は列幅固定の方が良いですが。--新幹線（会話） 2016年12月6日 (火) 14:43 (UTC)
replies: text: :::: 一文目と二文目のつながりがよく分からないのですが，短くない脚注がたくさんあるのに横幅が短く設定されるというのは想定していません．新規作成 (利用者名) （会話） 2016年12月7日 (水) 09:45 (UTC)
 scroll は消しておきました．最低列幅の値について他に意見はないでしょうか？ Waiesuさんの考えもお聞きしたいですが．列数指定により列幅が狭くなることがなくなれば確かに列数指定を積極的に排除すべき理由はなくなりますが，しかし列幅指定の方がそれぞれの環境に合わせられることに変わりはないので，列数指定の非推奨まではしなくても，列幅指定の推奨はするべきだと思います．列数を固定しなければならないなんてことはないでしょうし，列数指定を用いるべきという意見は一人も出していません．（div col については col-begin があります（推奨はされないでしょうが）．）時間のある時に指定列数の多い方から列幅に変えていってますが，3列を（個人で）排除するのは難しそう……大きいパソコンだと35em以上になりますし20emだと微妙……．新規作成 (利用者名) （会話） 2016年12月12日 (月) 08:30 (UTC)

text: 時間がとれなくてすみません。具体的な列幅については、15emでも20emでも「極端に見づらい状況が改善されれば」個人的にはどちらでも構わないと思っています。表示幅がちょうど15emの倍数の場合は1列が15emになりますが、それ以外の場合は（多くの場合はこちらになると思いますが）実際は15emより大きくなるわけで、最大29.9…emまであり得ますから、そこまで気にしないというわけです。推奨/非推奨については、この議題と直接関係するわけではないので、別の節で議論したほうがいいと思います。（テンプレートの更新と同時に行う必要はないですから。）

text: なお、MediaWiki:Common.css・テンプレートの更新は最適な列幅について合意が得られ次第、行いたいと思います。--Waiesu（会話） 2016年12月13日 (火) 16:18 (UTC)
replies: text: : 私ももっと早く指摘してればよかったんですけどね．15emでも29emになりえますが29emになるのは表示幅が29em（以上30em未満）の場合しかなく，実際問題15emに近い方が多いでしょう．繰り返しますが15emには反対です．20emならまあいいかとも思いますが，もうちょっと大きくてもいいと思います．大きい画面だと100em以上ありますからそれで4列指定した場合を考えれば妥当な制限でしょう．新規作成 (利用者名) （会話） 2016年12月14日 (水) 11:32 (UTC)
replies: text: :: そうですね。私は特にこだわりがありませんので、20emでもいいかと思います。それより大きいと「閲覧者の利便を確保しながら編集者の意図を再現する」という趣旨からかなり外れてしまいますので（編集者は密にするつもりだったが実際はスカスカに…なんてこともあったり）、私は気が進みません。一応、画面解像度シェアとその場合の列幅についてまとめましたので、よろしければご覧ください（表, 編集可能ですので列幅指定を変更して検討できます）。--Waiesu（会話） 2016年12月18日 (日) 05:02 (UTC)
replies: text: :::もうちょっとというのは25とか30とかじゃなくて22とか23とかのつもりなんですが．表はなかなかの労作ですね，ありがとうございます．新規作成 (利用者名) （会話） 2016年12月18日 (日) 12:58 (UTC)

text: :::そういう細かい部分のせいで今の状態が続くのもどうかと思いますので他に意見がないようなら20emから23emくらいの間でWaiesuさんの方で適当に設定していただけませんか．

text: :::また，まだ案の出ていないrefbeginには30em，div colには18emを提案します．新規作成 (利用者名) （会話） 2016年12月19日 (月) 11:45 (UTC)
replies: text: :::: 概ね5の倍数で指定されている場合が多いようですし、シェア1-3位の解像度において20-23emでは差異がないようですので、20emにしたいと思っています。

text: :::: refbegin, div colについては、どういった理由でそのような提案をされているのでしょうか。私は、全て20emでいいと思うんですが…。--Waiesu（会話） 2016年12月19日 (月) 14:47 (UTC)
用途がそれぞれ違うのですからそれに合わせて設定すべきでしょう．div colの中身は短いことが多いですし，逆にrefbeginは参考文献節（脚注ではなく）に使う（したがって長くなる）ことが多いと思います．新規作成 (利用者名) （会話） 2016年12月20日 (火) 11:14 (UTC)

text: refbeginに関していえばreflistと全く同じではないですか？ 参考文献はreferenceタグの有無に限らず脚注として記載されるはずです。div colは確かに短いかもしれません。それならば15emはどうでしょうか？（div colなんかは短い箇条書きが多そうなのでそもそも列数非推奨にしてもいいと思うんですがね…）--Waiesu（会話） 2016年12月24日 (土) 02:32 (UTC)
replies: text: : それは本気で言っているのでしょうか？ See e.g. ．新規作成 (利用者名) （会話） 2016年12月24日 (土) 08:00 (UTC)
replies: text: :: 期間が空いてしまって申し訳ありません。私が述べた「脚注」は辞書的な意味です。その例を見ても「参考文献」は脚注として記載されていますし、reflistとrefbeginの違いはreferenceタグを用いているかウィキ文法の箇条書きを用いているかの差異です。出典と参考文献は内容的に近いはずですから、同じ列幅で全く問題ないと思います。div colについてはどうお考えでしょうか。--Waiesu（会話） 2017年1月2日 (月) 01:46 (UTC)
replies: text: ::: あなたが脚注をどういう意味で用いているのかいまいち分かりませんが，もう少し各テンプレートがどのように使われているか見てからコメントした方がよいのではないでしょうか．「refbeginは参考文献節（脚注ではなく）に使う（したがって長くなる）ことが多いと思います」という私の以前の発言についてどのようにお考えでしょうか．そもそもrefbeginは3列以上が使われていません（この書き込みの直前に4列を5つと5列を1つ消しましたが（そもそも使い方が間違っているのもあるし））．

text: :::div colについてはそこまで小さくする必要はないのではないかと思います．列数非推奨については初めからそう言っています．

text: :::また「非推奨化に賛成し」ない理由を述べるべきだと思います．下に節も作ってます．新規作成 (利用者名) （会話） 2017年1月2日 (月) 08:22 (UTC)
replies: text: :::: 「脚注」の意味をお調べいただいたでしょうか。申し訳ありませんが、言葉が通じなければ議論を進められません。

text: ::::（reflist, refbeginについて）「列数指定の非推奨化」に賛成しない理由は、上記の通り大きな反発があること、「自警」が蔓延る原因になりかねないことです。「列幅指定の推奨化」ならば賛成します。--Waiesu（会話） 2017年1月3日 (火) 12:01 (UTC)
replies: text: :::::新規作成さんが例示されている（参考文献節）は本文の一部なので、普通は「脚注」とは言いません。私もrefbeginに関しては最低幅を長めに取ってもいいと思います。「列数指定の非推奨化」については、以前述べたように最低幅の確保だけで十分だと思うので反対します。むしろ手軽に段組みを設定できるメリットが失われることの方が大きいと思います。--新幹線（会話） 2017年1月3日 (火) 12:53 (UTC)
replies: text: :::::: 私には脚注節の下にある時点で脚注に見えますし、主従関係も本文主と脚注従という意味で参考文献節は脚注（後注）だと思います。仮にそうでなくてもrefbeginのdocを見る限り、「脚注」のためのテンプレートであることは明らかです。reflistとrefbeginの使う場所が全く異なるならばdocを改訂しなければならないでしょう。どちらにせよ、書籍情報をreference内に書くこともよくありますし、ウェブ出典と区別するにしても著者 (年). 書名. 出版社名.と著者. タイトル. 公開元 (年). アクセス日.の文字数の差異はそんなにないと思います。--Waiesu（会話） 2017年1月4日 (水) 03:25 (UTC)
replies: text: ::::::: Refbeginの解説文はおそらく英語版の「References」節と日本語版の「脚注」節を混同したことによる誤訳ではないかと思います。「References」に「脚注」という意味はありません（「脚注」は「footnotes」）。英語版の解説文を見るとRefbeginでは「footnotes」という文字は出てきませんが、Reflistの方では「footnotes」のためのテンプレートとはっきり書いてあります。--新幹線（会話） 2017年1月4日 (水) 04:35 (UTC)
replies: text: :::::::: 日本語版のdocは時期的に英語版 21:59, 26 December 2008‎の版を参考にしていると思うんですが、そちらにも「footnotes」の語は出てきませんがUsageを見ると脚注としてreflistと同じように用いているんですよ。ですから誤訳とは言えないんじゃないですかね。英語版の記事を見ても“References”節＝「脚注」節になっている記事が多くあります。（本質にはあまり関係ない話ですが。）--Waiesu（会話） 2017年1月4日 (水) 14:23 (UTC)
（インデント戻す）（Waiesuさん）「脚注」の意味は調べましたが分かりませんでした．あなたが思っている意味を書けば済む話ではないのですか？　それともう一度言いますがテンプレートの使用実態をご覧になった方がいいでしょう．「書籍情報をreference内に書くこともよくあ」るのならreflistもrefbeginも30emでいいのでは？
私には（コミュニティからの）大きな反発があるようには見えません．自警云々は真に受ける方がどうかしています．仮にそのようなことがあったとして，包丁は殺人に使われるから一般家庭での使用を禁止しましょうというのと同じくらい馬鹿げた話です．
「列数指定の非推奨化」は“目的”ではなく，あまりそこに強くこだわるつもりはないので，「列幅指定の推奨化」でみなさんの合意が得られればそれでもいいと思います．
（新幹線さん）では，reflistは20emで「最低幅の確保」ができるとお考えでしょうか？新規作成 (利用者名) （会話） 2017年1月4日 (水) 12:14 (UTC)

text: 辞書の引き方をご存じないならば大変気の毒ですが、幸いなことにインターネットさえ使えればコトバンクという便利な辞書サイトも参考になります。そちらによればページの下部、本文の枠外に表記される短文。フットノートとも呼ぶ。用語の注釈や、補足説明などを記述する。とのことです。（ウィキペディアにおいては）枠外かどうかはさておきページの下部で補足説明に近いもの（注釈・出典/参考文献など）は脚注といえるでしょう。

text: なぜ30emにこだわるのですか？ 最低限であれば20emが妥当でしょう。最低限を大きい値にするのは列数指定を否定するのと変わらないと思います（新規作成さんはそれを望んでいるのでしょうけど）。--Waiesu（会話） 2017年1月4日 (水) 14:23 (UTC)
replies: text: :「Usageを見ると脚注としてreflistと同じように用いている」って正気ですか．<ref> と対応しているか否かという大きな違いがあるのですが．

text: :あなたは脚注と思う．私や新幹線さんは思わない．辞書の引き方の問題ではありません．

text: :文献情報をフルで書いて20emじゃ短い場合が多いからです．新規作成 (利用者名) （会話） 2017年1月4日 (水) 14:35 (UTC)
replies: text: :: すでにreferenceタグの有無に限らずと言っています。そのタグが列幅にどう関係するのか私にはわかりませんのでご教示願います。辞書が引けないと読み違えまして失礼しました。20emが何に対して短いのですか？ 20emあっても読めないのですか？--Waiesu（会話） 2017年1月4日 (水) 14:48 (UTC)
replies: text: ::: 確かに英語版では "References" 節を脚注形式で書いているものが多く見られますが、だからといって "References" = 「脚注」とはなりません。Refbeginテンプレートは  general references 形式で出典を挙げるときに使うテンプレートですが、性質としては関連項目や外部リンクのリストと近く、それ単体で情報が成立するので「用語の注釈や、補足説明」とは言えません。

text: ::: 短い注釈が混入する可能性のある Reflist と異なり、 Refbegin は専ら書誌情報を示すために使われるテンプレートなので、短い文が混入する可能性は非常に少ないです。そのため最低幅を長めに取るのは合理的だと思います。--新幹線（会話） 2017年1月5日 (木) 01:18 (UTC)

text: ::: 既に新幹線さんからのご説明があるので，私から同じ説明は不要かと思いますが，補足すれば，refbeginはreflistやrefタグと組み合わせて用いられることもありますが，数はかなり少ないです．……だとどっちの設定が適用されるのか分かりませんが，いずれにしてもrefbeginは30emで問題ないと思います．また，reflistは20emでも妥協すると既に言っています（し今でも変わりません）．新規作成 (利用者名) （会話） 2017年1月5日 (木) 04:54 (UTC)

text: （逸れた話題を元に戻します）すでに決定したreflistとは別にrefbeginの最低列幅を決定することは非常に議論が煩雑になります（すでに）。cssも汚くなります。また20emであれば最低限度の幅を確保できますので、これ以上最適な幅を追い求める必要はないと考えています。新規作成さんによればrefbeginは3列以上では組まれていないようですし、モバイル環境から閲覧することを考えても20emを超える列幅の確保は不要でしょう。--Waiesu（会話） 2017年1月6日 (金) 10:28 (UTC)
replies: text: :あなたが煩雑にしているだけではないですか．新幹線さんや私は「最低幅を長めに取るのは合理的」だと考えています．わざわざ短くするメリットは乏しいと思います．div col はどうしますか．新規作成 (利用者名) （会話） 2017年1月7日 (土) 10:10 (UTC)
replies: text: :: わざわざ短くするという表現は気に入りませんが、2人だけで話を進めても問題なので、新幹線さんのご意見（具体的な列幅など）を待ちましょう。--Waiesu（会話） 2017年1月10日 (火) 14:20 (UTC)
 しばらく経っていますがどうしますか．reflistは20em, ref beginは30em, divcolは18emでいいですか．新規作成 (利用者名) （会話） 2017年1月20日 (金) 10:14 (UTC)
 さらにしばらく経ちましたが特に意見はないようですので合意は得られたと見なして編集を依頼しました．新規作成 (利用者名) （会話） 2017年1月30日 (月) 05:36 (UTC)
（おくればせながら報告）列数指定時の列幅の下限を，上述の通りは20em, は30em，は18emにそれぞれ設定しました．ただし，もとの提案にあるMediaWiki:Common.cssではなく，テンプレート本体で実装しています．（commonでやると各自で設定を上書きできる（はず）なのでそのほうがいい気もしますが，私にはどうにもできないので．）新規作成 (利用者名) （会話） 2017年2月22日 (水) 03:17 (UTC)
===列数指定の非推奨化あるいは列幅指定の推奨化（続き）===
こちらに新たに提起しました．reflistに限らない一般的な議論はそちらに．新規作成 (利用者名) （会話） 2016年12月18日 (日) 12:58 (UTC)
何の対策もされていない現時点では非推奨化の合意は取れていると言ってもよさそうですが，3つのうちのみ列数指定を非推奨化して，とについてはもうしばらく（とくにWaiesuさんの）反応を待ってみようと思います．新規作成 (利用者名) （会話） 2017年1月3日 (火) 08:55 (UTC)
thread_title:  提案: 列数指定の非推奨化 

message: *（報告）反対はないようですので，Waiesuさんの提案にもとづいて，テンプレートの仕様を，列数指定が自動的に列幅指定になるように修正しました．ただし，
**→
**→
**→
replies: text: としました．（5や6にまで個別に対応する必要はないと思います．）新規作成 (利用者名) （会話） 2016年10月25日 (火) 03:11 (UTC)
Wikipedia:お知らせどころかWikipedia:コメント依頼への掲載がされていないにも関わらず、reflistの変更という、100万の記事にも影響しかねない変更が行われているので驚きました。もちろん、docで非推奨を宣言することはきちんと議論されていると思いますが、reflistの変更自体はそれに付随して意見が述べられたに過ぎず、私には十分な議論が行われているようには思えませんでした。列幅指定の置換については2016年10月16日 (日) 07:13 (UTC)において新規作成さんから提案がされていますが、その後の2016年10月17日 (月) 05:06 (UTC)における61.46.104.165さんの仕切り直しの際には「列数を指定している本テンプレート使用記事をボットにより列幅の指定に変更すること」について「別個に議論されるべき」との意見が出ています。その後は2016年10月17日 (月) 08:33 (UTC)にて新規作成さんより「botを使わずにをなどに解釈するようテンプレートを改変してもいい」との意見や、2016年10月17日 (月) 08:44 (UTC)にてWaiesuさんより「の改訂が望ましい」との意見が確かに出てはいます。しかし、2016年10月18日 (火) 10:05 (UTC)ではNa's skyさんより「「列数指定になっているものを如何するか」はそのあとの問題ではないでしょうか」との意見が、2016年10月22日 (土) 18:25 (UTC)では61.46.104.165さんより「現在列数指定となっているものをどうするかについては、引き続きご議論いただければと思います」という意見が出ています。流石にこの状況で多くの記事に影響が生じるテンプレートを変更するのは無理があるのではないでしょうか。別途節を設けてコメント依頼やお知らせなどに告知してから変更した方がいいと思いますが。--Kinketu（会話） 2016年10月25日 (火) 10:54 (UTC)
（追記）自分の環境（解像度：1920×1080）で以前に書いた茨城電気 (1931-1942)という記事を見てみたら、出典が横に7列並ぶという恐ろしいことになっていました（笑）。技術的にももう少し話し合った方がいいのでは。表示に不具合が出ているという報告にたいし差し戻しで対応したりせずに。--Kinketu（会話） 2016年10月25日 (火) 11:00 (UTC)
*Waiesuさんの 2016年10月16日 (日) 16:27 (UTC) の発言（最後の一文）を無視しているのはなぜですか？

text: ＞出典が横に7列並ぶという恐ろしいことになっていました

text: 逆に言えば， はそれくらいふざけた指定だということです（私の環境では4列です）．3以上を20emでもいいのかもしれませんね．

text: 不具合は確かに私のミスでしたがその時点では既に解消されており，会話ページで対応しています．新規作成 (利用者名) （会話） 2016年10月25日 (火) 13:21 (UTC)
replies: text: : 「Waiesuさんの 2016年10月16日 (日) 16:27 (UTC) の発言（最後の一文）」については見逃していました。申し訳ありません。あえて無視した訳ではありませんのでご容赦下さい。どうやら私のコメントの後にコメント依頼を提出されたようですね。お手数をおかけします。本題に入りますが、コメント依頼の提出がなされたということは、「列数指定の非推奨化」の提案は新たに仕切り直し、このコメント依頼提出時点から起算するという認識でよいでしょうか? そうであるのならばこの後の質問は意味を成しませんが、そうでないのならば新規作成さん以外の方に質問したいことがあります。新規作成さん以外の方には、「誰々のどの発言が（docの改定に付随する単なる意見ではなく）テンプレートを変更する明白な提案であり、その発言から一週間以内に反対意見がなければ変更を反映する」という認識は共有されていたのでしょうか。jawp全体の編集者の数からしたらこの議論に参加している編集者の数は極少数ですが、その極少数の編集者間でもテンプレート変更提案が認識されていなかったとしたら、やはり仕切り直した方が無難だと感じます。認識がきちんと共有された上での提案ならば、列数X以上をY emとした方がいいといった有用な意見も他人から頂けるかもしれませんし。--Kinketu（会話） 2016年10月25日 (火) 14:29 (UTC)
replies: text: ::これは不具合でしょうか？

text: ::*2014年の鉄道#脚注、を使用。注釈・出典ともに番号が表示されていません。

text: ::*2016年の野球#出典、を使用。出典の番号が表示されていません。

text: ::*2015年の野球#出典、を使用。出典の番号が表示されていません。

text: ::*2014年の野球#出典、を使用。出典の番号が表示されていません。

text: ::出典の番号が表示されていないものが他に多数の記事にある一方で、通常に出典の番号表示がなされているものもあるようです。上記リンク先の記事を確認をして頂きたいのですが、私の閲覧環境だけでなのでしょうか？--Sonchou（会話） 2016年10月25日 (火) 14:34 (UTC)

text: ::上記コメントのあとに変更の差し戻しが行われたのでしばらく様子を見ていましたが、出典の番号表示は復帰したようです。--Sonchou（会話） 2016年10月25日 (火) 21:18 (UTC)
replies: text: :::ですからキャッシュを破棄してください（今言っても無駄ですが）．サンドボックス（テンプレート）では問題を確認できませんでした．キャッシュを破棄して不具合が出ていたのならおそらくサーバー側の問題です．私の編集にミスがあるのならそれを指摘してください．新規作成 (利用者名) （会話） 2016年10月26日 (水) 02:04 (UTC)
*まず，今回のテンプレートの編集は早計でした．ご迷惑をおかけしたことをお詫びします．
*改めて，テンプレートの第一引数を列幅指定にすることを提案します．
*具体例から入りますが，私のパソコンでは（解像度は 1200 × 800 のようです），30em, 20em, 15em でそれぞれちょうど2列，3列，4列になります．左半分でページを見るような状況では，15em では1列ですし，Kinketuさんのように，15em で7列になる環境もあります．
*逆に列数指定を強制したときに，横幅の狭い環境でいかに可読性を損なうかは説明するまでもないと思います．そのための列幅指定なわけですが，ボットで置換するには対象があまりに多いですし，また今後の利便性も考えると，今までは2列指定だった  で幅を 30em にする，といった仕様の変更の方がよいと思います．
*おそらく，4列とかそういうのを指定している方は，横幅の広い環境の方がほとんどだと思います．テンプレートの例が30emで，それだと私の環境ではちょうど2列なので，適当に60の約数で考えて編集したこともありますが，Kinketuさんのおっしゃるように7列になってしまうのでは多すぎると思うので，2で30em，3以上で20emというのを一つの案としておきます．
*列数指定を（別の引数で）残しておく必要があるのかは分かりませんが，これについては他の方にお任せします．新規作成 (利用者名) （会話） 2016年10月26日 (水) 02:04 (UTC)
*colcountは（記事には使われていませんが）正常に動作していなかったようです（ソースを見れば明らかですが無意味な引数です）．新規作成 (利用者名) （会話） 2016年10月26日 (水) 02:21 (UTC)
*ちゃんと作るとこうなります（テンプレ，2で30em，3以上で20em，colcountあり）．新規作成 (利用者名) （会話） 2016年10月26日 (水) 08:50 (UTC)

text: 一応提案者ですが、ご無沙汰していてすみません。今話題に上がっている私の提案は、botで列数→列幅の置換しなくてもテンプレート側の処理で済ませればそれでもいいですよね、程度の軽い感じの意見ですので、あまり気にしないでください。どちらかといえば、前にも述べていますが、列数を指定してプレビューした際に警告文を出す、という処理のほうがより多くの利用者への広告になりますから、こちらの処理を推したいです。も影響が大きいテンプレートですから全保護にすべきなのでしょうか…。--Waiesu（会話） 2016年10月26日 (水) 10:54 (UTC)
replies: text: : 別にそれは仕様を変更してもできることではないでしょうか？ つまり， 等でプレビューしたときに警告文（列数指定が非推奨であることと仕様変更のお知らせ）を出せばいいと思うのですが．新規作成 (利用者名) （会話） 2016年10月26日 (水) 12:15 (UTC)
replies: text: :: そうなんですが、結果が同じなら直す必要なしってなりそう（警告文の重要性が下がりそう）なんで。その記事にあった適切な幅もあるかもしれないですしね。--Waiesu（会話） 2016年10月26日 (水) 13:10 (UTC)
replies: text: ::: 直す必要をなくすための仕様変更のつもりですが．「適切な幅」を探すような人ならどっちにしても同じでしょう．逆に仕様変更せず非推奨の警告だけだとそのままにする人もいるでしょうし，幅の設定で戸惑う人もいると思います．新規作成 (利用者名) （会話） 2016年10月27日 (木) 06:38 (UTC)

text: えー、ご意見だけ。emの直接してい推奨はそれこそ意味が分からなくなります。ナンセンスでしょう。かといって、1では可読性を損なう場合もあり（PC画面では右側に余白だらけで、恐ろしく縦長になります）、3以上もスマホの隆盛著しい現状は好ましくなく、せいぜい「通常は、1（無指定）または2が推奨されます。」、程度でよろしい。技術的に可能であれば、モバイル端末であることを察知すれば、内部で1に変換。でなければ原文のまま(あるいは2に変換）、などと言うことはできませんか。これが一番楽そうなんですけど。「可読性に考慮する」事は勿論大切ですが、「執筆者に対する指示を肥大化させない」事もまた大切です。締めるべき所は締めるべきですが、指示の肥大化は足かせです。私が執筆をやめたのも、肥大化した指示を持ち込んで会話ページにカチコミをかけ鼻高々、と言う自警に嫌気が差したからと言う意味もあります。この点に対する配慮が真剣に検討されたのか、甚だ疑問と思っております。以上です。--Hman（会話） 2016年10月27日 (木) 06:54 (UTC)

text: あーすいませんもう一言。別に日本語版でガラパゴス進化する必要などなく、可能な範囲でen丸パクりでいいんじゃないですか。こういうのは。単に桁数の問題でしょ？そこのコードだけ持ってくると。議論やコーディングに要するリソースがもったいないです。その点、技術的に可能や否やは確認されているのでしょうか。--Hman（会話） 2016年10月27日 (木) 06:59 (UTC)
replies: text: : 2→30em、3→20emのように一律に置き換えるのは反対です。それでは2と指定しているのに表示環境によって1列だったり3列だったりということが起こりえるので、編集者に混乱をもたらします。

text: : 一方で、列幅を直接指定することは有用です。ただし、すべての記事で一律30emや20emにしては意味がありません。それぞれの記事で脚注の中身は異なるのですから「適切な幅」は探さなければなりません。Aさんのパソコンでは3列、Bさんのパソコンでは7列、Cさんのスマホでは1列で表示されるなんていうのは言ってしまえばどうでもよいことです。その記事の脚注の中身に合わせて、列幅を設定すればよいのです。ハーバード方式が採用されていて最も長い脚注が「山田　2016　p.54」（12文字）なら15emとか、脚注内で書誌情報がしっかり書かれていて最も長い脚注が「山田太郎『脚注の付け方』田中出版　2016　p.54」（26文字）なら30emとか指定すれば、どなたの環境でも無駄な改行なく表示されるのですから。--Na's sky 2016年11月3日 (木) 04:30 (UTC)
replies: text: :: 1段落目後半，それに対しては警告文を出すことで対応します．サンドボックスを更新しました．テストケースでプレヴューしてご確認ください．2段落目，問題なのは今大量の記事で列数指定がされていることです．それに対していちいち適切な幅を人力で探していたのでは時間がかかりすぎます．bot でできるならすればいいですが，bot による置換後もまた別の記事とかで列数指定される可能性があります．そもそも現状の列数指定ではもともと適切な幅ではないのですから，それを列幅指定にしようが同じでしょう（というかむしろこっちのほうが適切な幅に近くなると思いますが）．別に私の案のように変えた後でも列幅指定ができなくなるわけではないのですよ？ さらに，以前のように列数指定をしようとしても勝手に列幅指定になってくれるというメリットもあるわけです．蛇足ですが出典テンプレートを使えば「山田　2016　p.54」ではなく「山田 2016, p. 54.」となりますから15文字ですよ．新規作成 (利用者名) （会話） 2016年11月3日 (木) 07:18 (UTC)
replies: text: ::: 列数から列幅指定への変更過程において、一律に置き換えるという案に反対している方も多いわけですし、無理にそうする必要はないんじゃないですかね。私はプレビュー時に案内文で移行を促せばそれで十分だと思います。あとscrollの案内はもはや不要でしょう。--Waiesu（会話） 2016年11月4日 (金) 09:53 (UTC)
replies: text: :::: Na's sky さんと Waiesu さんだけでしょう．Hman さんから執筆者の負担になるという意見も出ています．それに今列数指定になっているものはどうするつもりですか？ 3列指定と20em指定のどちらが適切か冷静に考えてください．新規作成 (利用者名) （会話） 2016年11月5日 (土) 02:31 (UTC)
replies: text: ::::: Hmanさんがおっしゃる「執筆者の負担になる」というは、新規作成さんの案でテンプレート側で一律に列幅指定に変換しても、結局その記事にあった列幅を指定し直さなければいけないという事態になるのですから、同じはずです。また、Hmanさんの案で英語版に合わせるとすれば、column-countもそのまま放っておくことになるでしょう。--Waiesu（会話） 2016年11月5日 (土) 10:56 (UTC)
replies: text: :::::: つまり，列数指定では適切な幅を考えなくてもよいが列幅指定では適切な幅を考えなくてはならない，というお考えなんですね？新規作成 (利用者名) （会話） 2016年11月5日 (土) 23:24 (UTC)

text: ::::::私にはあなたが考えていることが分かりません．私はテンプレートの仕様を変更した方が効率的に列幅指定に移行できると思っているのですが（「列幅を指定し直さ」なくていいものもあるでしょう），あなたは違うのですよね？新規作成 (利用者名) （会話） 2016年11月6日 (日) 04:05 (UTC)
replies: text: ::::::: 執筆者に列数→列幅指定を促すのと、テンプレート側で一方的に列数→列幅指定をしてしまって後で執筆者に調整させるのでは、どちらも執筆者の負担になる可能性があるという点で言えば同じです。ただ、テンプレート側で一方的に変更すれば、執筆者はより混乱しますし、おそらく「見やすいようにした脚注を勝手に変えられた」と気分を害する方もいるでしょう。効率的に列幅指定に移行できるかもしれませんが、私は別に効率性を求めていませんし、より多くの皆さんから理解が得られるように温和に移行すべきだと思っています。（実際に反対している方もいますし。）--Waiesu（会話） 2016年11月6日 (日) 04:30 (UTC)
その「見やすいように」が見やすくないから問題なんでしょう．効率だけでなく今まで通りの使い方（書き方）で問題なく使えるということも重要だと思います．一つ聞きたいのですが，2→30em，3→20em等々で「後で調整が必要」になる記事って実際にあるのですか？もちろん，より適切な幅がある可能性はありますが，少なくとも不適切な幅になることはないと思うのですが．新規作成 (利用者名) （会話） 2016年11月6日 (日) 08:38 (UTC)

text: いや、おそらく一般的なセンスをお持ちの方が同じ解像度・ウィンドウ幅で編集すれば、似たような感じになるでしょうから、見やすくないっていうことはないと思いますよ。ただ、普通の状態で見やすくても、他のウィンドウ幅であれば見にくいこともあるでしょう。その差異をなくしていくのが列幅指定であって、列数→列幅の一律変換は列数指定を非推奨とする意味がありません。今まで通りの使い方が問題なく使えるという面を重視するのならば、一律変換でなくて列数指定をそのまま残すほうがいいと思いますよ。と書いてから下の案を思いついたのでそちらもご検討下さい。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC) 誤字修正。意味が真逆ですねすみません。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)
replies: text: : ええ，「他のウィンドウ幅であれば」ということを言っているつもりです．新案ありがとうございます．新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)
「列数指定が勝手に列幅指定になる」「列数指定ができなくなる」ことが問題です。これまでのお話し合いのなかで、「列数指定を廃止する」「列数指定をできなくする」ことは合意されておりませんでしょう。仮にそれを無視してテンプレートを変更したとしても、表示環境によって指定と異なる列数で表示されるということが多くの記事で発生して、テンプレートの変更は差し戻されることになります。ほぼ間違いなく。Waiesuさんのおっしゃるようにテンプレートの変更はプレビュー時に警告文を出すようにすることにとどめ、徐々に移行を促していくのが現時点で現実的かつ確実です。その方法でもある程度のスピードで移行は進むと思いますよ。--Na's sky 2016年11月4日 (金) 22:23 (UTC)

text: 「列数指定ができなくなる」なんてことにはしていません．（私は別になくしてもいいとは思っていますが．）そんなことさえ分からずに議論に参加されるのは迷惑でしかないのでご遠慮ください．新規作成 (利用者名) （会話） 2016年11月5日 (土) 02:31 (UTC)
replies: text: : 非推奨にするって書いちゃうってことは、列数指定を行うたびに自警が飛んできて会話ページで絡んできたりするわけですよ。jawpってそういう所なんです。ですから、事実上できなくなります。そして、非推奨ってことは列数指定はどんどん列幅指定に直していかなけりゃならないんだなと言う自称草取り係が大量発生します。jawpが列幅指定で埋まっちゃいます。jawpってそういう所なんです。そして、列幅指定されたものを列数指定に戻すフィルタを作る事は、かなり面倒なはずです。事実上列数指定の排除に向けて舵を取られていると言うことにご自覚が無いのですか。

text: : 列数指定されているのもは、モバイルなら1、モバイルでないならそのまま、もしくは2に置換する程度の緩い改善を検討するくらいでよし。列幅指定を推奨するようなあらゆる文言に反対します。しかしスマホの隆盛、という事情を考えますと、「3以上の列幅は推奨されません」、程度の記述を行っておく事は、実情としてやむを得ないでしょう。執筆者に一々最適な列幅まで考えさせるなんてナンセンスもいい所です。バカげてます。そこらへんを何も考えずとも適当・適切にやってくれるから、テンプレートも便利なんですよ。どちらかと言えば列幅指定こそ、非推奨と言うか、せめて「非推奨と言うわけではありませんが、必用となる場面はほぼないでしょう」くらい書いて置いて頂きたいもの。執筆者への指示を肥大化させず（列幅を適切に考えろなんて、まさにどうでもいい指示の肥大）、むしろ楽ができるように改善していってください。列数指定の非推奨文言の追加には強く反対します。除去を求めます。大体、defaultが列数指定なのに、defaultが非推奨ってなんですかそれ。拙速すぎでしょう。1週間2週間を争って改変する問題ですか。また、enに準拠じゃいけないんですか。どうなんですか。どうなんですか。どうなんですか。--Hman（会話） 2016年11月5日 (土) 16:44 (UTC)

text: : 追加質問です。reflist、このテンプレートは何万の記事からリンクされていますか？もし事実万単位の記事からリンクされているのであれば、ここの数人でどうこう決めていい問題ではありません。10/15以前の文書・コードにロールバックした植えで、仕様・運用の変更については「Wikipedia:お知らせ」およびコメント依頼で多くの人を募り、総合的にご意見を伺うべきです。これは「ウィキペディア全体に大きな影響を及ぼしかねない大規模な変更」と考えます。理屈の上ではjawpには100万の記事があり、そのほとんどに出典が貼付されています。うち半分がreflistを使っているとすれば、50万記事に影響を及ぼすことになります。実際にいくつなのか、私はすぐに実測できる方法を知りません（個人的にはしっかりした、本格的な記事ほどreflistが多くなると考えて居ます。refが多くなればなるほどreflistの各種機能が有益になりますから。私は大きな記事を書くことが多かったので、ほぼreflistばかり使っていました）。ですからまず、実際にどの程度の数の記事でreflistが使われて居るのか、お教え頂けませんか。--Hman（会話） 2016年11月5日 (土) 17:07 (UTC)
*  61.46.104.165 2016年10月22日 (土) 18:25 (UTC) による Template:Reflist/doc の改変は、1.お知らせどころかコメント依頼(提出されたのは10/25です)すら出されていない状態で、影響の大きなテンプレートの運用方法変更や仕様の変更について、周知が不徹底のままわずか数名の議論で行われたこと。2.かようなテンプレートであるにもかかわらずわずか一週間程度で拙速に変更が行われたこと。3.わずか数名の中でも賛否両論であり、合意とは見なせないこと。以上の理由により、非推奨の文言を除去するかたちで、事実上の原状復帰を行いました。ただし列幅指定については除去する必要が無いため、そのまま残してあります。列数指定→列幅指定と言う順序で記述してあるのは、単にdefaultが列数指定だからです。特に重要なテンプレートやその説明、方針・ガイドライン等につきましては、今後は十分な広報と意見聴取、および慎重な議論の上で改変頂きたく思います。--Hman（会話） 2016年11月5日 (土) 17:48 (UTC)

text: :Hmanさんももう少し議論とテンプレートの現仕様・仕様案を理解してからコメントしてください．列数指定は環境によって可読性が落ちます．スマホだけじゃないんですよ？ 私の案のように変更すれば今まで通りの書き方でも問題なく使えるということもご理解ください．何も考えず  や  とだけ書いときゃいいんです．en準拠なら列数指定は非推奨ですね．それから現仕様のdefaultは列数指定ではなく列数指定および列幅指定です．新規作成 (利用者名) （会話） 2016年11月5日 (土) 23:24 (UTC)
replies: text: :: 一つ一つ片付けていきましょうか。このテンプレート、何万記事で使われて居るのか、調査されましたか。まずはここからお答え願えますか。私に対してだけではないのですよ。コメント依頼から来られる方もいる。現時点ではROMっていらっしゃる方もいる。将来過去ログとして残りもする。--Hman（会話） 2016年11月6日 (日) 05:52 (UTC)
replies: text: :::こういう風に聞いてもらえれば答えられるんですけどね．Template:Reflistからすぐにわかるんですけど今日の18:15 (JST) 時点で391003件だそうです．新規作成 (利用者名) （会話） 2016年11月6日 (日) 09:16 (UTC)
replies: text: :::: はは、どうもすいません。1年半ほど全く休んでおりましたもので、mediaWikiも色々変わっており戸惑っております次第です。全体で約100万記事ですから、ざっくり言えば約4割の記事で用いられていると言う認識でOKですか？--Hman（会話） 2016年11月6日 (日) 14:14 (UTC)
replies: text: ::::: そういうことになりますね．そのうち列数指定や列幅指定がどのくらいあるかは下にWaiesuさんがコメントをくださっています．新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)

text: Hmanさんの懸念は非常によくわかります。それについてお答えになっていませんが、どのようにお考えでしょうか。過去にはTemplate:和暦にかかわる編集合戦が多発していましたよね。それに似たようなことがあるのではないですか。あと「何も考えず 何も考えず  や   とだけ書いときゃいいんです．」ってさすがにひどくないですか。画面の向こうにいるのは人間ですよ。--多摩に暇人（会話） 2016年11月5日 (土) 23:46 (UTC)
replies: text: : 答えてるつもりですが具体的にどれに答えてないとお考えなのですか？和暦については知らないので何とも言えません．くだらない揚げ足取りはご遠慮ください．新規作成 (利用者名) （会話） 2016年11月6日 (日) 00:23 (UTC)
replies: text: ::2016年11月5日 (土) 16:44 (UTC)と2016年11月5日 (土) 17:07 (UTC)の質問にはほぼ答えていないですよね？あと暴言を撤回する気がないことはよくわかりました。--多摩に暇人（会話） 2016年11月6日 (日) 00:33 (UTC)
replies: text: :::ですから具体的に書いてください．（同じようなことを3人にいうのもあれですが）議論をろくに読みもせずにおかしなコメントを残すのはやめてください．私が意図していないことを勝手に解釈して暴言と言われても困ります．議論妨害・個人攻撃はおやめください．新規作成 (利用者名) （会話） 2016年11月6日 (日) 04:05 (UTC)
replies: text: ::::全部答えていないのだから時間を指定していますよね？意図的にわからないと言ってませんか。また私のコメントが議論妨害、個人攻撃と主張されるのではあればしかるべき場所にご報告いただければと思います。--多摩に暇人（会話） 2016年11月6日 (日) 04:42 (UTC)
replies: text: ::::: 「何も考えず  や  とだけ書いときゃいいんです」といいますが、私が直すまで列数指定は非推奨になっていたじゃないですか。一体何を言っているんですか？？本気で意味がわかりません。何度でも、強く申し上げます。執筆者に列幅を指定させるようなバカな企てはただちに停止されるべきです。テンプレートなどの作成者は、言わば裏方です。花形である執筆者を助ける為の作業であるべきで、足を引っ張るようなことがあってはなりません。可読性に配慮する余り、執筆者に不利益を与えないで下さい。こんなもの混乱が発生するに決まっています。「和暦」については調べてきて下さい。和暦問題すらよく解らないなら、お願いですから、触らないでください。本当にお願いします。コミュニティの強い合意が無い限り、このテンプレートの仕様や運用法は、大きく変更されるべきではありません。繰り返し指摘しますが、最低限お知らせくらいは打つべきものでしょう、これ。--Hman（会話） 2016年11月6日 (日) 05:52 (UTC)

text: ::::: 今ひとつ申し上げます、「何も考えず・・・」に「その言い様は酷い」と諫められ、何故その行為が「くだらない揚げ足取り」となるのか、これもわかりません。どういうロジックであるのか、ご説明頂けますか。具体的にお願いします。また、諫められても暴言を撤回されない人に「暴言を撤回しない旨了解」と申し上げる事は、個人攻撃とは言えないですよ。また、多摩に暇人氏が議論を妨害した様子は、私には見付けられませんでした。--Hman（会話） 2016年11月6日 (日) 06:37 (UTC)
replies: text: :::::: 私の案ではは列幅指定なんですからちゃんと読んでたらそんなおかしな疑問は出ないんですよねえ．あなたが「そこらへんを何も考えずとも適当・適切にやってくれるから、テンプレートも便利なんですよ。」って書いたからそれに返事したんじゃないですか．つまり最初に暴言を吐いたのは他でもないHmanさんということになるわけですね．新規作成 (利用者名) （会話） 2016年11月6日 (日) 08:38 (UTC)
replies: text: ::::::: すいません、ちょっと意味がわかりません。私の案ではとかどうとか言い出すのもわかりませんし（他人にものを伝えるべき時、何かを省略するのであればそれは特記無き限り一般論でなければ混乱するだけだと言うのは、分別のある社会人であれば誰でもわかっていることです。頼みますよ）、先に暴言を言ったとかもわかりませんし、先に暴言を言われたから暴言を返してもいいんだと言う理論？も理解できません。いやその、中学生の喧嘩じゃないんで、そこは一旦落ち着いて下さい。とかく、一旦仕切り直しのつもりでかかることです。また、大々的な告知が行われない限り、あなたがどのような演説をされようとも、全体合意が得られることは物理的に難しく、当該テンプレートのような重要なテンプレートの基本的な機能および運用法は従来のまま固定となります。一度深呼吸が必要な局面です。--Hman（会話） 2016年11月6日 (日) 14:22 (UTC)
replies: text: :::::::: 直前に「私の案のように……」って書いてて分からないわけないでしょう．おちょくってるんですか？ お願いですからちゃんと読んでください．後半は私は暴言を言ったつもりはない，私のが暴言ならHmanさんのも暴言だ，ということです．新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)
(質問) Waiesuさんにお伺いします。貴殿は列幅の直接指定推奨に前向きなお考えをお持ちのようですが、何故賛成であるのか、えーぶっちゃけ新規作成氏はいないものと考えて(笑)、ご自身が、何故列幅直接指定が好ましいとお考えなのか、大いにプレゼンして頂けませんか。なお私が列数指定、ただしやむを得ないのでモバイルでは解除、と言う考えを持っているのは、「執筆者にいちいち最適な列幅なんか数えさせんな、それを自動化するのがテンプレートやろが！大体絶対自警のさばるし！」と言う点と、「数値の直接指定は邪悪、これがコーディングの基本。全体合意も無い中強引に直接指定推奨とし、それが多発すれば、列数指定に戻すのは非常に困難」と言う点です。テンプレートをいじられるレベルの方であれば、当然の心得と存じます。そしてもう一点。何にしましてもお知らせ通しての広報や強力な全体合意の無い中、この重要なテンプレートの拙速な仕様・運用の変更は絶対に行われるべきではない。これについては問題無くご同意頂けると思っておりますが、その様な認識でよろしいですか。--Hman（会話） 2016年11月6日 (日) 07:07 (UTC)

text: まず1点目、列幅の直接指定が好ましいという理由ですが、ここらへんは個人の好みの範疇になると思うのですが、数値の絶対指定は柔軟性がない（アクセス環境の多様化についていけない）と考えるからです。例えばと指定すれば、横幅が30×n em以上あればn列になりますし、30emに足りない満たないときは1列、というように柔軟性を確保できるわけです。脚注の見やすさは文字の数・密度（＝1列の幅）に依存しますから。一方、にすれば、何があろうと横幅が3emだろうと3列になるわけで。MediaWiki:Mobile.cssでモバイルビューのときは強制的に1列にしよう！というのもありっちゃありですけど、それじゃあ、PCで古い画素数の少ないディスプレイや、画面分割したときはどうなるの、ということになります。MediaWiki:Common.cssでウィンドウ幅を検知して割り振ろうというのも一時は考えましたが、まだCSSが開発段階で確定していないですし、小さい画面でも2K/4Kが出てきて文字の大きさとピクセル数の関係が他のディスプレイとは違うということもあります。

text: 「自警がのさばる」という懸念についてはいまいちピンと来ないのですが、その自警という方々が列幅を調整してくだされば、執筆する方の負担は減るのではないでしょうか？ 私が考えている案内文というのは「負担にならない程度に移行してください」程度のもので、別に「こいつ案内を無視してやがる！バシバシ！」とかいうことは思いません。みたいなのがあれば一番いいんですが、JSを駆使しないとできないので、あまり現実的ではないでしょう。（全ての脚注の文字数を数えて平均？偏差？を取って列幅を決めるみたいな感じですかね？ 正直、脚注をまじまじと見る方がどれくらいいるのか謎ですが。）

text: 2点目については、特にテンプレート本体の編集については、拙速も何も、え？自分そんな提案したっけ？みたいな感じです。それで不具合をいろんな方から指摘を受けたみたいですが。私もコメント依頼などでは告知すべきだったと思います。（390997ページで使用）も（418780ページで使用）と同様に全保護していもいいと思います。新規作成さんへの質問を先に答えてしまってすみません。--Waiesu（会話） 2016年11月6日 (日) 08:27 (UTC) 誤字修正。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC)
replies: text: : 一点目について。好みの範疇とお考えの旨、了承致しました。私も同感です。ですから、列数指定を推奨にしろとは申し上げておりません。さて、列幅直接指定にした場合の問題は、「最適の列幅」を誰かが逐一考えなければいけないことになります。そして、最適解が非常に見付けづらく、変な押し付け合いになる可能性がある、コミュニティが混乱する可能性があると思うんです（自警がのさばると言うのは、今回のケースではemNNでは見にくいからemMMにしろや！と、会話ページに自警が凸ってくることです。何度も見ていますし、何度かやられてもいますｗ 指示を肥大化させルールを細かくすると、執筆者は自警におびえながら活動しなければならなくなり、私のように嫌気が差して放り投げてしまう、そういう可能性もあります。和暦問題については、なんでしたら私にメールで送って下されば、説明致しましょう。ちょっと古い利用者であれば、結構知っているネタです。しかしなんですか、最適な列幅、いちいち算出するのってばからしくありません？もっとも、列数指定にした場合も、最適の列数を考えなければならないのですが、ほぼ1か2の二択ですから(笑)、特に問題とはならないでしょう。柔軟性がないと言えばそうですが。仰るとおり、|auto こうできればこれが一番です。まあ、autoではき出される書式がどの程度見やすいのか、適切なのかは別途検討が必要ですが。ただモバイルかどうかはともかく、解像度までは察知・・・できます？できないなら、やはりモバイルなら1決め打ち、でなければそのまま（1か2。現状を考えれば3以上はないでしょう）。こういった感じが適切でないかと。

text: : 二点目につきまして、当テンプレートやその運用法の拙速な変更について、慎重な姿勢である旨、了承致しました。もしまた暴走する方が現れましたら、できるだけ早くロールバックし、必要なら管理者伝言板への通報もお願い致します。話に聞いて覗いてみて、あまりにも拙速に過ぎて、びっくりしましたよ。信じられない杜撰さです。

text: : 細かな画面分割の可能性は考えていませんでしたね。これは日時をかけてこちらでも考えてみます。確かにそう言った運用法を・・・どの程度の人が行われているかはわかりませんが・・・少数派と全く無視すると言うのも問題です。しかし極めて特殊と強く想定されるのであれば、jawp側で合わせる必要もなく。ブラウザのレンダリングにまで責任が持てない、と言う意味もありますから、jawp側で配慮できるのは一定の所までだ、と言うのはございますでしょうね。そして、reflistは約40万ページ、全体の4割ほどものページで使われていましたか。勉強になりました。個人的な感覚として、行っても半々くらいかなー。でかい記事はreflistが便利だけど、小さい記事はそうでもないし、過半数はないだろうと思っていましたので、大体想定どおりですｗ 当面はdocも含めて、実際に物理的に保護をかけるかはともかく、「編集禁止」にすると言う根本的なところのご提案に、強く同意致します。

text: : ・・・・・・docの最終更新、私なんですが、おかしなところはありませんよね？^^; まあ、推敲レベルなら問題ないでしょう。

text: : さて、質問ばかりで申し訳ないのですが、私、1年半ほど休眠していました。が、それより以前は、emなんて使っている人、見た記憶がないんですよ。この1年半でem使う人が増えたと言う事実でもあるのでしょうか？これについては具体的な数字を出すのは大変ですから、Waiesu様個人の印象で結構です。一線級の現役執筆者の方のご意見は、参考になります。特に、もし最近のGA/新記事賞/強化記事賞などで用いられているものをご存じでしたら、是非ご紹介頂きたいです。やはりそういうもので見てみるのが、一番参考になりますので。--Hman（会話） 2016年11月6日 (日) 13:46 (UTC)
replies: text: :: 凸ってくる利用者が個人的にはいるとは思えないのですが、実際にいるならば残念ですね。日本語版の勢いがなくなっているのもそれが原因なのでしょうか。CSSのメディアクエリを使えば解像度も察知できるはずです。申し訳ないのですが、いろいろすっ飛ばして情報だけ載せます。group指定、refs指定していないもので検索すると、は33,891件、には1,620件マッチするので（少し変動あり）、かなり列数指定が多いようです。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC) 誤字修正。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)
thread_title:  列数指定をどうするか 

message: ここまで書いておいてなんですが、他に案が思いついたので列数非推奨の提案への賛成を取り消します。代わりにMediaWiki:Common.cssで標準の列幅列数の指定（列数指定時の列幅に下限を設定する）を提案します。具体的には
.reflist {
	-weblit-columns: 1 15em;
	-moz-columns: 1 15em;
	/* ベンダープレフィックスはなくてもいいかも */
	columns: 1 15em;
}などの指定を現時点で検討しています。これは標準の列数を1、最低列幅を15em（例）にしています。例えばと指定すれば、各列の幅を15em以上確保できれば5列、確保できなければ15emを確保できる最大列で表示されます。と指定すれば、上書き最低列幅に上書きされます（これだと列数が1のままなので、テンプレートを変更してcolumn-count: autoを指定させればいいはず）。
この提案について、みなさまのご意見をお聞かせください。--Waiesu（会話） 2016年11月6日 (日) 15:57 (UTC) 誤字修正。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC) 下線部追記。--Waiesu（会話） 2016年11月7日 (月) 05:40 (UTC)
replies: text: まずは長い余談から・・・。実際に会話ページに凸られた事も、メールで凸られたことも、凸られたのをお助けしたことも、山ほどあります（苦笑）。まあ本件の本論ではあまりない訳ですが、スタイルマニュアルなど、執筆者にとっては「大体」の努力目標でいいんですね。彼らの仕事はお持ちの知識を元に、文献を調べ、記事に反映することです。乱暴に申し上げれば、それ以外の所は適当でいい。そこを口かやかましく言うと逃げちゃいますよ。私みたいに。逃げちゃった人も沢山見てきましたよ。伊達に2005年から10年、一応やってはおりませんｗ 本格的なそれは2011年頃からですが。

text: さてそれはそうとしまして。20:1とはまた離れたものですが、むしろ1/21近くもem派がいることにびっくりしました。もっと少ないのではないかと。何千という記事のソースを見ましたが、実際にお目にかかった記憶が本当にゼロなのです。検索ワードの悪戯で簡単に数倍、数分の一、になるものだとは思いますが・・・。いずれにしましても、この情勢では、emを推奨にしよう、と言う動きには、なりようはないでしょう^^;。ただし熱心なロビー活動により、数年後に情勢を変える事は可能かとは思います。

text: 新たなご提案については・・・うん、値を適当に取れれば、感触はいいです。ですが、適当なFA/GA記事を引っ張ってきて、スクリーンショットの比較でプレゼンするのが解りやすいのではないでしょうか。執筆者の殆どは特にテンプレートに詳しくありません(作成や改造などを行える人は極僅かです)。よって、ご提示の文書だけでどのようになるか明確にイメージできる方は、非常に限られています。ですが、使用するのは執筆者ですので、ほとんどの執筆者に理解できるプレゼンでなくてはと^^;。また、具体的な変更には、「各refの9割は、n文字に収まっているようだ」と言うデータが欲しい所ですね(ただ、1行に収まらんと話にならん！とか、例外的に2行なんて生じるのはそもそも当たり前なんだから2行前提でよし！とか、スマホの縦画面でみにくいのなんか、画面が小せえんだからそもそもしょーがねえだろうが！とか、色々お考えはあるもので、簡単ではないでしょう)。全記事サンプリングなど無理ですので、FA/GAに絞ってでもできませんかねぇ・・・。

text: で、仮にまあ、多少の調整はあれど、それでいけるとなりまして。

text: これ「お知らせ」に載せなくていいんですかね・・・。ここで合意が得られたとしても「数人」です。ちゃんとした告知と強力な合意の無いまま事を推し進めますと、今まさに私が行っているように後で異義が入ります。私なら、お知らせと同時に井戸端にもネタを放り込みますよ。私が言うのも変ですが、後で異義が噴出するほど面倒なことはありません。それまでの作業が台無しになります。まずは広い告知、これをお勧めしたいです。とかく相手は100万分の40万記事です。

text: なおテンプレート屋の暴走として一番思い出深い(というか個人的に深刻だった)のは「Template‐ノート:複数の問題」です。多少記憶がぶれている部分もあるかもしれませんが、おおよその流れとしましては、yyyy-mm/yyyy-m/yyyy年m月、など、自由な形式で年月が表記可能だった各種テンプレートを、ある人物がyyyy年mm月(明らかに一番タイプ数が多い！)、でしか通らなくするようにしました。その後、botで各記事を絨毯爆撃で置換しようと企みました。これといった合意もなく。本人の供述によれば、まあ早く言えば、「その方が鯖負荷軽いし」とのことで・・・。この時は私が出張って、全体合意のないまま影響の大きな変更を勝手に行わないように、なんとか取り纏めました。reflistもほぼこの案件に匹敵する規模で、執筆者に影響を及ぼすでしょう。合意も無いまま拙速に行うと、私より怖い人が飛んでくるかもしれません(私は怖くなんてないですよ！)。この様な事態に陥らないように、慎重に慎重を期して、検討しましょう。--Hman（会話） 2016年11月6日 (日) 19:38 (UTC)
replies: text: : （何でも執筆者さんに求めるのは間違いですね。）一番多いのは指定無しのっぽいですね（69,860ページくらい）。スクリーンショットで見てもらえばいいかもしれませんが、比較するとなるとそれはそれはものすごい量になりそうなので、保留とさせてください。代わりにHelp:WithJS withCSSを使用して、皆さんに好きなページで体験してもらう、という感じにしたいと思います。現状では体験できるjs/cssはMediaWiki名前空間に限られているので、利用者名前空間でも適用できるようにこちらで提案しています。（MediaWiki名前空間にテストcssを作ってもいいかもしれませんが、汚したくないし突っ込まれたくないので。）FA/GAの脚注の文字数についてはデータをとってみようかなと思います（今週末になるかもしれません）。

text: : 新案を提示しましたので、それについてのお知らせも含めて、お知らせに載せてきます。（前レスで言及するのを忘れていましたが、docについては問題ないと思います。）--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC) 一部取り消し。--Waiesu（会話） 2016年11月18日 (金) 14:56 (UTC)
replies: text: :: そうですね、そちらのサンプル提示の方式については、お任せします（リンク先を拝見しましたが、通るにしても時間を要しそうですね）。Waiesu様ならまずもって間違いはない、でしょう。こう言った影響の大きな変更、reflistなどについては「システム自体の変更」にも準じるものなのですから、とにかく焦りは禁物です(mediaWikiを翻訳不如意なままアップデートして大混乱に陥った事件もありましたね・・・)。もし、これ以上ほとんど人が来ない、議論が進展しない、と言う状況なのであれば、「ほとんどの人が現状で問題がないと考えている」、つまり変更は不要だと言うのが結論と解するよりありません。何事も、充分なベテラン執筆者が20名程度集まり、喧々諤々の議論の結果、仕様変更が妥当だと言うことに落ち着いた時に、変更すればいいのです。変更の可能性から論じられるべきで、最初に変更ありきではいけません（なお、お知らせだけでなく井戸端にも放り込むのも効果的です）。大体皆さん、日々の生活もありますし、執筆の方もお忙しい。一連の作業については数ヶ月は見てかかられるのがよろしいでしょう。かつ、お知らせ（や井戸端）を見ていらした、テンプレート（やプログラミング）など何もわからない方が、一目見て従来の形とどう違うのかがわかるかたちで（SSなどで）提示されていれば、話は早くなります。「わかんねーからしらんわ」と言う人が多くなることは、改変を望む側に不利になると思います。改変については積極的な推進意見が必要なところですからね。コメント依頼による議論の解決を求める時に、これまでにぐっちゃぐちゃになってしまったお話を一旦まとめて、論点の整理をしてから、リセットのつもりでコメント依頼を行う事はよくみられることです。何せ、コメント依頼（今回はお知らせも）をご覧になっていらっしゃる方は、ここまでの議論はよくわからない。よくわからない事を言っている人もいる。コードで書かれても表示がどう変化するのかがわからない。テンプレートのソースなんて見たことすらない（恐らくですが、95%の利用者はこれでしょう）。これを当たり前と考えるべきです。なお、明らかなバグフィクスについては特に問題はありませんが、基本的にシステムに関わるテンプレート制作者は、enにあるものの移植の他は、執筆者側からのリクエスト待ちくらいでよく、そういう事がない限りは普通に記事を書いていればいいんじゃないかなー、と思います。--Hman（会話） 2016年11月7日 (月) 05:58 (UTC)
replies: text: ::: バグといっても過言ではないこんな明らかな不具合は，私のやり方はまずかったですが，さっさと直すべきです．参考に，茨城電気 (1931-1942)の表示例を貼っておきます．Waiesuさんによれば5列や6列もあるんですよ．新規作成 (利用者名) （会話） 2016年11月8日 (火) 03:11 (UTC)

text: （Waiesuさんあて）私としては改行されまくって可読性が著しく損なわれるような状況さえなくなればいいです．Template:Div colなんかもそうです（英語版では列数指定は廃止されてます）．30emと指定すれば～がよく分からないのですが，テンプレートを変更すれば30em (≥ 15em) でこれまでと同じように働くという理解でよいのでしょうか？新規作成 (利用者名) （会話） 2016年11月7日 (月) 03:27 (UTC)
replies: text: : すみません言葉足らずでしたね、列幅（15em以上でも以下でも）と指定していてもこれまで通りということです。ですから、列数指定に対して、列幅の下限を設定するという認識でいいと思います。についても同様の懸念があるならば別途提案したほうがいいかもしれません。--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)
replies: text: :: なるほど，分かりました．ありがとうございます． と  でも状況は同じなので，まとめてやればいいでしょう．新規作成 (利用者名) （会話） 2016年11月8日 (火) 03:11 (UTC)
一連の議論に新参ではありませんが、現状で問題がないとは考えておりませんので、Waiesuさんのご提案に賛意を示しておきます。
前節で脚注の内容に合わせて列幅を設定すればよいと申し上げましたが、列幅を設定したときにその幅が適用されるのは、脚注の内容に加えて1.や2.などの脚注番号の部分を含めた幅ですので、列幅は脚注の内容よりやや大きめに設定する必要があります（ひとつの脚注を一行で表示させようとする場合）。
Hmanさんのおっしゃるように、ひとつの脚注を一行で収める、ひとつの脚注が二行以上にまたがるのを容認する、両方の考えがあると思いますが、ほとんど短い脚注だけれどもひとつだけ長い脚注があるという場合（最長の脚注に合わせると空白が大きくなってしまう）も考えられますので、そこは記事に合わせてある程度柔軟でよいと思います。
前節での記述は少々不明確だと思いましたので、訂正のうえ、一意見として提示いたします。新たなご提案と通じる部分もあると思いますので。--Na's sky 2016年11月7日 (月) 12:53 (UTC)
（どこにインデントすればいいか悩む）えっと、閲覧者の環境は各々異なりますし好みもそれそれですから、ほぼ同一と考えれるMobileはMediaWiki:Mobile.cssで強制的に段組なしにして、その他の利用者は各自のcssで設定できるようにヘルプページへの案内リンクなどでサンプル提供するなんて方法ではだめなのかな？それが一番もめなくって、各自自由に出来る方法だと思うのですが。--Vigorous action （Ｔａｌｋ/History） 2016年11月7日 (月) 13:59 (UTC)

text: そもそもが、スマホ環境での過度な改行が問題だー、から始まっていますので、Mobile.cssのそれは、技術的に問題なく可能な変更なのであれば、落としどころじゃないかなと思います。後段のご案内の充実、についても、適切な文言を提供できれば効果はございますでしょう。唯一問題があるとすれば、「流れのただの閲覧者諸兄」対応としては完璧ではないと言う点なのでしょうが、どこまで対応すべきかと言う点すら、いや変更が必要なのかと言う点すらまだ全体合意が得られていませんので、今後、別にそれで全然いいんじゃね？となる可能性も当然ございますでしょうね。そもそも元々が、Mobileでない環境であれば、それほど躍起になる必要のないネタという気もします。結局は好みであると言う点につきまして、強く同意させて頂きます。

text: まあまだ、お知らせを打った直後です。今回このようなご提案を頂けましたように、多くの方に見て頂ければ新しいアイディアも出てくるものです（まあ、変える必要ない！と言うご意見が多数出てきたりする可能性もありますけど）。のんびり参りましょう。--Hman（会話） 2016年11月7日 (月) 16:40 (UTC)
  および  でも状況は同じだと思いますので，こちらに誘導しました．これらを含めて3つのテンプレートに対し，Waiesuさんの案を適用することに賛成します．著しく可読性が落ちるものを「好み」で済ますわけにはいきません．モバイルでの1列強制には反対します．必ずしも2列（以上）で表示に問題があるわけではないからです．パソコンでの表示でも列数指定では問題がありますし，スマホから必ずモバイルビューで見るわけでもないし，全く解決になっていません．新規作成 (利用者名) （会話） 2016年11月8日 (火) 03:11 (UTC)

text: Vigorous actionさんのご意見に対して、新規作成さんと全く同意見です。私も例をあげておきます（いつでも消せるように外部サイトですが→「ヘリコバクター・ピロリ」のスクリーンショット）。1366x768のディスプレイで2分割したときの画像です。左側はオリジナル、右側は提案通りreflistにcolumns:1 15emを設定した場合です。なお、columns:1 20emにすると1列になるようでした。--Waiesu（会話） 2016年11月9日 (水) 09:49 (UTC)

text: * WCAG 2.0（W3C勧告）ではカラム幅には相対サイズを使用することが推奨されています。--Waiesu（会話） 2016年11月9日 (水) 10:21 (UTC)
replies: text: :* Waiesuさんがあげられたヘリコバクター・ピロリですが当方で複数の閲覧環境で確認してみましたが、ガラケーのような特殊な端末以外では右の写真より文字数の多いもので左のような写真の状態になる事はありませんでしたので、あんまり共感できないんですね。
replies: text: :: Wikipediaへのアクセス種別では細かな数字は失念しましたが「移動体端末によるアクセスがかなりある。」という事実は明らかであり、そういった方に向けて財団はモバイルビューとモバイルアプリを公式に提供しています。なので、Mobile.cssの変更なら積極的に賛成します。

text: :: ただ閲覧環境は基本的に閲覧者の責の下に選択されますから、モニターが小さい・モニターを2分割とか、モバイル端末でモバイルビューを使用しないなどの場合「見難さを許容する」か「各自で対策する」かだとおもいます。

text: :: ただのリンク先のHelp:脚注/読者向けなどに、個人cssの作成手引きなど対策に向けての手引き文章を作成するのまでは否定しないということです。

text: :: もっと根本的な解決方法としてを廃止してに統一するといった解決方法もありますよ。--Vigorous action （Ｔａｌｋ/History） 2016年11月12日 (土) 02:02 (UTC)
replies: text: ::: まあ、閲覧の環境は人それぞれですからね。今回の提案は、特に今までの指定方法・記述を否定・変更するわけでなく、執筆者に負担をかけませんので、デメリットはないかと思います。逆に、Vigorous actionさんがおっしゃる「モニターが小さい・モニターを2分割」にも配慮され、以下に新幹線さんが述べているような編集合戦も防ぐことができ、大きなメリットがあると思っていますが、Vigorous actionさんはどうお考えでしょうか。（廃止は…マジレスしなくていいですよね）--Waiesu（会話） 2016年11月12日 (土) 02:22 (UTC)
replies: text: :::: 一番簡単な解決方法である廃止について検討をもしないってのに強く違和感を感じる。そうすれば、モニターの大きさや、使用方法。さらにはモバイルでのアクセスなど皆さんが問題視されてることが解決でき、カラムの数などをめぐっての編集合戦なんかも発生しない。を廃止してにしても、Wikipediaの記事品質に変わりはないんじゃないかな？

text: :::: さて、こういうのって個人の使用環境・感覚によって適正値だと思うものが異なるので、時間かけて不満が残る人出すより「各自の責任において好きにしてよ。やり方は教えるから。」が不満もでずみんなが納得する方法で、合意形成しなくってもいいわけだし時間が短縮できるってのもあるから一番メリット有るんじゃ無いですか？--Vigorous action （Ｔａｌｋ/History） 2016年11月12日 (土) 03:13 (UTC)
replies: text: ::::: 本心でおっしゃっていたのであれば、申し訳ありませんでした。40万以上の記事に使用されていて、非常に多くの他言語版でも使用されている実績から、廃止は非現実的で、コミュニティの賛同を得られないと思っております。もしVigorous actionが廃止したいとお考えならば、別途提案をお願いします。

text: :::::閲覧者それぞれに任せるとすると、ログイン（アカウント作成）させてカスタムCSSを作らせるか、ブラウザの拡張機能なりでカスタムするか、になると思うんですが、それでは結局そういうことができない方の不満は解消されないと思います。

text: :::::私の提案は、「編集者の意図したスタイル」「閲覧者が望むスタイル」を折衷したもので、双方にとって1番不満の少ないものだと考えています。--Waiesu（会話） 2016年11月12日 (土) 04:23 (UTC)
replies: text: :::::: 40万以上の記事に使用されていて、非常に多くの他言語版でも使用されている実績があろうと、閲覧に大きな問題が発生しているのなら、廃止するというのも検討の余地に含めるべきです。さらにそれが記事品質に影響を及ぼさないのであればなおさらです。ただ、廃止しろといってるのではなく、廃止を検討する事が一切論点に入ってこないのは違うんじゃないのか？ってことです。

text: :::::: wikipedia日本語版は百科事典を編纂するプロジェクトですが、それが属するWikimedia projectは非営利の教育projectなんですよね。営利目的なら利用者を増やさないとすぐに経営的に成り立たないということで閲覧者に媚びる必要があるとは思いますが、幸いなことに財団は、資金的に余裕がある訳でもないかもしれませんが切羽詰まった状況ではないとおもいます。なのでMediawiki:common.cssといった閲覧者の目に届かないところで不満が残るかも知れない形で設定するより、

text: :::::: 表示の変更を希望する閲覧者は、ログイン（アカウント作成）してカスタムCSSを作るか、ブラウザの拡張機能なりでカスタムすると表示を変更出来ます。するかしないかは、あなたの判断です。ただし、サンプル提供が有りますのでご自身にあったものを使用することもそれを変更することも出来ます。であれば等しく選択肢がありそれを選択するのかどうかは閲覧側の問題ですし、cssって何？というような人の興味を引き新たな知識取得の対象になるかもしれません。

text: :::::: 記事内容に関して閲覧者を戸惑わせてはいけません。ただ、表示方法について万人が納得する正解って多分ない。なら、自分の正解だと思うもので表示してもらうのが次善の策だと思うんですよ。--Vigorous action （Ｔａｌｋ/History） 2016年11月12日 (土) 06:15 (UTC)
replies: text: ::::::: 単にスクリーン幅に対して段組みが多くなると見栄えが悪くなるという話なだけで、閲覧に大きな問題が発生しているわけではありません。編集合戦が発生するかもしれないから廃止しようというのは、それこそ「和暦の悲劇」の再来ではないですか？ 簡単に廃止を検討するのは些か乱暴ではないでしょうか。--新幹線（会話） 2016年11月12日 (土) 08:47 (UTC)
replies: text: ::::::::: 個人的に対応できる事であるので好みに合わせて設定できる事を提案したが、それでは対応出来ないほどの閲覧に大きな問題が発生（『著しく可読性が落ちる』・『「好み」で済ますわけにはいかない』）との意見が提案者・新規作成（利用者名）さんの2名からあります。大きな問題があると言っているのは私ではなく、提案者・新規作成（利用者名）さんの2名なんですね。
replies: text: ::::::::: 私はで用を足すと思ってますから、は有ってもなくても構わないともおもいますし、スクロールがデフォルトだった時代にで一つの脚注でカラム3つぐらい書いてたものをみた記憶があります。読みにくいから勘弁してくれとおもいましたよ。

text: ::::::::: 過去にカラムの数で「1-2が見やすいが3以上に設定してあるのは見難くて・・・。」なんて事言ってた出典ガチガチ主義の元管理者もいます。

text: ::::::::: 閲覧者の環境が異なりそれによる適正値も変わってくるので設定値に総ての利用者が満足できないのであれば、個人的に対応するか廃止するのが妥当で早いんじゃないかと思います。一旦個人設定案内してしばらくたってから統計をとってデフォルトで設定する。なんかですと、そのスタイルが気に入らないひとでも個人cssで対応もできますから大きな反対はしませんけど。--Vigorous action （Ｔａｌｋ/History） 2016年11月13日 (日) 01:18 (UTC)
replies: text: :::::::::: 好みがどうこう以前に，閲覧に支障の出る状況を改善しましょうという話です．4文字ごとに改行されて閲覧に支障がないとお考えでしょうか？ Waiesuさんの案を使えば，（非常識な列幅指定をしない限り）そういう問題はおこらなくなるわけです．それと記事によって適切な幅は異なるのに「個人的に対応」ってどうやるんですか．新規作成 (利用者名) （会話） 2016年11月16日 (水) 12:37 (UTC)
replies: text: ::::::::::: 見えない・読めないではないので大きな支障はない。好みの問題だと言ってますが？--Vigorous action （Ｔａｌｋ/History） 2016年11月20日 (日) 05:53 (UTC)
replies: text: :::::::::::: 限りなく「読めない」に近い環境があるのですから、それは好みの問題とは異なると思います。--Waiesu（会話） 2016年11月21日 (月) 04:59 (UTC)

text: 最小のwidthを設定することで列数指定時における問題は解決されると考えられるので、賛成します。ところで、スマホ環境における改行の話ですが、モバイルビューに限って1列強制というのはできないのでしょうか？--新幹線（会話） 2016年11月11日 (金) 18:37 (UTC)
replies: text: :  ちょっと話が脱線しますが、以前の議論では列数指定を非推奨にすると「執筆者の負担（自警問題）」や「和暦問題」が起こるとの話が出ていましたが、そうした問題は列数指定の推奨/非推奨に関係なく、現時点でも起こりうる問題ではないでしょうか。「和暦問題」とは大規模な編集合戦のことを指しているのでしょうが、実際過去に（どこの記事かは忘れましたが）、「脚注の列数」を巡って編集合戦が起き、議論になったこともあります。同じ記事でも閲覧環境によって何列が適切かは変わりますから。むしろ列幅指定を推奨にし列数を可変にすれば、そうした編集合戦の抑制につながるのではないかとも考えられます（なお、widthの下限が設定されればこの問題はかなり解決されると考えているので、その場合は列数指定はそのままでよいと考えています）。執筆者の負担についても、そもそも段組みを使い慣れている人なら列数の指定方式が変わるだけでそこまで負担は増えないだろうし、段組みを使わない人には関係ないので、そこまで配慮する必要があるのかな…？ と思います。--新幹線（会話） 2016年11月12日 (土) 01:43 (UTC)
replies: text: :: 賛成ありがとうございます。モバイルビューに限って1列強制というのも可能です。しかし多くの場合は、スマートフォンの縦画面で閲覧すると、列幅の下限を15emとするだけで、1列になりそうです（スクリーンショット比較（1920x1080縦画面/横画面））。--Waiesu（会話） 2016年11月12日 (土) 01:58 (UTC)
replies: text: ::: なるほど、でしたらあえてモバイルビューで1列強制にする必要はないかもしれませんね。タブレットだと2列ぐらいあっても良さそうなので。--新幹線（会話） 2016年11月12日 (土) 08:47 (UTC)

text: 体験用にMediaWiki:Test/common.cssを作成しました。任意のページのURL末尾に?withCSS=MediaWiki:Test/common.cssを追加していただければ、提案中のCSSを体験できます。ウィンドウ幅を伸縮していただければ動作がわかりやすいかと思います。--Waiesu（会話） 2016年11月18日 (金) 14:56 (UTC)
replies: text: :ありがとうございます．いくつかリンクを書いておきます．和田アキコ（4列指定，幅が小さいと3列以下になる）（一方CSSなしでスマホ），2013年（30em，今まで通り）．私の下書きページだと全部一列になってしまいます．手塚賞もだめです．新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:34 (UTC)

text: :失礼，2013年はURLが間違ってます，やはり1列になります（直すのめんどうなのでそのまま……）．新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:40 (UTC)

text: :すみません，いろいろぼけてますね．私の下書きは列数のソースが違ってます．列数指定に対し体験するということでしたか．新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:42 (UTC)
replies: text: :: すみません説明不足でしたね。列幅指定されているものは、別途テンプレートを変更する必要があります。また、モバイルビューは、withJS withCSSをサポートしていないので、体験できません。体験できるのは、列数指定されているデスクトップ環境のみです。--Waiesu（会話） 2016年11月21日 (月) 04:59 (UTC)
*結局新たに反対は出ていませんし，列数指定の非推奨化およびWaiesuさんの案の適用ということで合意は得られたのではないかと思いますがいかがでしょうか．新規作成 (利用者名) （会話） 2016年12月2日 (金) 09:00 (UTC)
====下限 (2)====
 私が見る限り、賛成3、反対1、コメントのみ1、といったところのようで、また賛成者による反対者の主張への反駁に対する否定的なコメントも見られませんので、さらに1週間ほど待って反対がなければ、合意が得られたと解釈し、MediaWiki:Common.cssとTemplate:Reflistの編集を行いたいと思います。なお、テンプレートの編集については、
#列幅指定時にcolumn-count: autoを指定する（css指定に合わせて必要）
#廃止のお知らせを除去する（他の節でも指摘されているように現在全く使用されておらず、不要な処理を増やしているだけ）
を予定しています。（下書きをTemplate:Reflist/sandboxに書いていますのでご確認ください。）--Waiesu（会話） 2016年12月3日 (土) 15:05 (UTC)
 私の提案は列数指定の非推奨化を代替するものであって、私は非推奨化に賛成しません。（提案の意味がなくなってしまう…）--Waiesu（会話） 2016年12月3日 (土) 15:11 (UTC)
*いやWaiesuさんの案を適用したところで列幅指定の方が推奨されることに変わりはないでしょう．列数指定に対して表示がひどいことにならないようにするだけであって，ある人は40emくらいのつもりで指定したが別の人にとっては15emだったみたいなことはおこるわけで．私は代替だなどとは思っていませんでしたが，そのつもりなら（いやそのつもりでなくても）もうちょっと大きめの20emとか25emの方がいいのではないですか？ 15emでは小さいです．また，列数指定に対してはお知らせを出した方がいいかもしれません．使用数を見た感じ，20emなら指定列数と表示が変わることはほとんどなさそうですが．（ちなみに私のパソコン（小さい方だと思いますが）では18emで4列，19--24emで3列，25emで2列となるようです．）scrollのお知らせは別に今すぐ消してもいいんじゃないかと思いますが．新規作成 (利用者名) （会話） 2016年12月4日 (日) 03:34 (UTC)
**  ＞ある人は40emくらいのつもりで指定したが別の人にとっては15emだったそれで何か問題ありますか？元々スマホ等で列幅が小さくなりすぎるという話から始まったわけで、最低限の幅が確保されれば問題は解決すると思いますが。また、15emでは小さいと思ったらユーザーCSSで変更可能です。--新幹線（会話） 2016年12月5日 (月) 05:53 (UTC)
（1つ目）？？ だから列幅指定の方が推奨されますねという話ですが．(2) 新幹線さんは15emが最低限の幅だとお考えなのでしょうか？ (3) 20emでは大きいと思ったらユーザーCSSで変更可能です．（参考に）
<--15em
<--20em
<--25em
<--30em
幅はだいたいこんな感じです．新規作成 (利用者名) （会話） 2016年12月5日 (月) 10:34 (UTC)

text: : 幅が大きくなる分には幾ら大きくなっても閲覧に支障をきたしません。また列幅指定だとかなり前にKinketuさんが仰っていたように「ある人にとっては4列だが別の人にとっては7列」みたいなことも起こりうるわけですが、その点はどのようにお考えでしょうか。最低限の幅には拘っていないので20emの方が良いという意見が多ければ従います。---新幹線（会話） 2016年12月6日 (火) 00:53 (UTC)
replies: text: ::それぞれの環境に応じて列数が変わるのが列幅指定のメリットです．ある環境で7列だろうが10列だろうが，指定した幅が適切であれば，何の問題もないと思います．新規作成 (利用者名) （会話） 2016年12月6日 (火) 13:09 (UTC)
replies: text: ::: ＞それぞれの環境に応じて列数が変わるのが列幅指定のメリットです．必ずしもそうとは言い切れないと思います。1920×1080などといった高解像度の画面でウィキペディアを見る場合、本文自体がかなり横長に表示されると思いますので、それに合わせて脚注も横長になるのが自然な表示だと思います。もちろん、短い脚注がたくさんある場合は列幅固定の方が良いですが。--新幹線（会話） 2016年12月6日 (火) 14:43 (UTC)
replies: text: :::: 一文目と二文目のつながりがよく分からないのですが，短くない脚注がたくさんあるのに横幅が短く設定されるというのは想定していません．新規作成 (利用者名) （会話） 2016年12月7日 (水) 09:45 (UTC)
 scroll は消しておきました．最低列幅の値について他に意見はないでしょうか？ Waiesuさんの考えもお聞きしたいですが．列数指定により列幅が狭くなることがなくなれば確かに列数指定を積極的に排除すべき理由はなくなりますが，しかし列幅指定の方がそれぞれの環境に合わせられることに変わりはないので，列数指定の非推奨まではしなくても，列幅指定の推奨はするべきだと思います．列数を固定しなければならないなんてことはないでしょうし，列数指定を用いるべきという意見は一人も出していません．（div col については col-begin があります（推奨はされないでしょうが）．）時間のある時に指定列数の多い方から列幅に変えていってますが，3列を（個人で）排除するのは難しそう……大きいパソコンだと35em以上になりますし20emだと微妙……．新規作成 (利用者名) （会話） 2016年12月12日 (月) 08:30 (UTC)

text: 時間がとれなくてすみません。具体的な列幅については、15emでも20emでも「極端に見づらい状況が改善されれば」個人的にはどちらでも構わないと思っています。表示幅がちょうど15emの倍数の場合は1列が15emになりますが、それ以外の場合は（多くの場合はこちらになると思いますが）実際は15emより大きくなるわけで、最大29.9…emまであり得ますから、そこまで気にしないというわけです。推奨/非推奨については、この議題と直接関係するわけではないので、別の節で議論したほうがいいと思います。（テンプレートの更新と同時に行う必要はないですから。）

text: なお、MediaWiki:Common.css・テンプレートの更新は最適な列幅について合意が得られ次第、行いたいと思います。--Waiesu（会話） 2016年12月13日 (火) 16:18 (UTC)
replies: text: : 私ももっと早く指摘してればよかったんですけどね．15emでも29emになりえますが29emになるのは表示幅が29em（以上30em未満）の場合しかなく，実際問題15emに近い方が多いでしょう．繰り返しますが15emには反対です．20emならまあいいかとも思いますが，もうちょっと大きくてもいいと思います．大きい画面だと100em以上ありますからそれで4列指定した場合を考えれば妥当な制限でしょう．新規作成 (利用者名) （会話） 2016年12月14日 (水) 11:32 (UTC)
replies: text: :: そうですね。私は特にこだわりがありませんので、20emでもいいかと思います。それより大きいと「閲覧者の利便を確保しながら編集者の意図を再現する」という趣旨からかなり外れてしまいますので（編集者は密にするつもりだったが実際はスカスカに…なんてこともあったり）、私は気が進みません。一応、画面解像度シェアとその場合の列幅についてまとめましたので、よろしければご覧ください（表, 編集可能ですので列幅指定を変更して検討できます）。--Waiesu（会話） 2016年12月18日 (日) 05:02 (UTC)
replies: text: :::もうちょっとというのは25とか30とかじゃなくて22とか23とかのつもりなんですが．表はなかなかの労作ですね，ありがとうございます．新規作成 (利用者名) （会話） 2016年12月18日 (日) 12:58 (UTC)

text: :::そういう細かい部分のせいで今の状態が続くのもどうかと思いますので他に意見がないようなら20emから23emくらいの間でWaiesuさんの方で適当に設定していただけませんか．

text: :::また，まだ案の出ていないrefbeginには30em，div colには18emを提案します．新規作成 (利用者名) （会話） 2016年12月19日 (月) 11:45 (UTC)
replies: text: :::: 概ね5の倍数で指定されている場合が多いようですし、シェア1-3位の解像度において20-23emでは差異がないようですので、20emにしたいと思っています。

text: :::: refbegin, div colについては、どういった理由でそのような提案をされているのでしょうか。私は、全て20emでいいと思うんですが…。--Waiesu（会話） 2016年12月19日 (月) 14:47 (UTC)
用途がそれぞれ違うのですからそれに合わせて設定すべきでしょう．div colの中身は短いことが多いですし，逆にrefbeginは参考文献節（脚注ではなく）に使う（したがって長くなる）ことが多いと思います．新規作成 (利用者名) （会話） 2016年12月20日 (火) 11:14 (UTC)

text: refbeginに関していえばreflistと全く同じではないですか？ 参考文献はreferenceタグの有無に限らず脚注として記載されるはずです。div colは確かに短いかもしれません。それならば15emはどうでしょうか？（div colなんかは短い箇条書きが多そうなのでそもそも列数非推奨にしてもいいと思うんですがね…）--Waiesu（会話） 2016年12月24日 (土) 02:32 (UTC)
replies: text: : それは本気で言っているのでしょうか？ See e.g. ．新規作成 (利用者名) （会話） 2016年12月24日 (土) 08:00 (UTC)
replies: text: :: 期間が空いてしまって申し訳ありません。私が述べた「脚注」は辞書的な意味です。その例を見ても「参考文献」は脚注として記載されていますし、reflistとrefbeginの違いはreferenceタグを用いているかウィキ文法の箇条書きを用いているかの差異です。出典と参考文献は内容的に近いはずですから、同じ列幅で全く問題ないと思います。div colについてはどうお考えでしょうか。--Waiesu（会話） 2017年1月2日 (月) 01:46 (UTC)
replies: text: ::: あなたが脚注をどういう意味で用いているのかいまいち分かりませんが，もう少し各テンプレートがどのように使われているか見てからコメントした方がよいのではないでしょうか．「refbeginは参考文献節（脚注ではなく）に使う（したがって長くなる）ことが多いと思います」という私の以前の発言についてどのようにお考えでしょうか．そもそもrefbeginは3列以上が使われていません（この書き込みの直前に4列を5つと5列を1つ消しましたが（そもそも使い方が間違っているのもあるし））．

text: :::div colについてはそこまで小さくする必要はないのではないかと思います．列数非推奨については初めからそう言っています．

text: :::また「非推奨化に賛成し」ない理由を述べるべきだと思います．下に節も作ってます．新規作成 (利用者名) （会話） 2017年1月2日 (月) 08:22 (UTC)
replies: text: :::: 「脚注」の意味をお調べいただいたでしょうか。申し訳ありませんが、言葉が通じなければ議論を進められません。

text: ::::（reflist, refbeginについて）「列数指定の非推奨化」に賛成しない理由は、上記の通り大きな反発があること、「自警」が蔓延る原因になりかねないことです。「列幅指定の推奨化」ならば賛成します。--Waiesu（会話） 2017年1月3日 (火) 12:01 (UTC)
replies: text: :::::新規作成さんが例示されている（参考文献節）は本文の一部なので、普通は「脚注」とは言いません。私もrefbeginに関しては最低幅を長めに取ってもいいと思います。「列数指定の非推奨化」については、以前述べたように最低幅の確保だけで十分だと思うので反対します。むしろ手軽に段組みを設定できるメリットが失われることの方が大きいと思います。--新幹線（会話） 2017年1月3日 (火) 12:53 (UTC)
replies: text: :::::: 私には脚注節の下にある時点で脚注に見えますし、主従関係も本文主と脚注従という意味で参考文献節は脚注（後注）だと思います。仮にそうでなくてもrefbeginのdocを見る限り、「脚注」のためのテンプレートであることは明らかです。reflistとrefbeginの使う場所が全く異なるならばdocを改訂しなければならないでしょう。どちらにせよ、書籍情報をreference内に書くこともよくありますし、ウェブ出典と区別するにしても著者 (年). 書名. 出版社名.と著者. タイトル. 公開元 (年). アクセス日.の文字数の差異はそんなにないと思います。--Waiesu（会話） 2017年1月4日 (水) 03:25 (UTC)
replies: text: ::::::: Refbeginの解説文はおそらく英語版の「References」節と日本語版の「脚注」節を混同したことによる誤訳ではないかと思います。「References」に「脚注」という意味はありません（「脚注」は「footnotes」）。英語版の解説文を見るとRefbeginでは「footnotes」という文字は出てきませんが、Reflistの方では「footnotes」のためのテンプレートとはっきり書いてあります。--新幹線（会話） 2017年1月4日 (水) 04:35 (UTC)
replies: text: :::::::: 日本語版のdocは時期的に英語版 21:59, 26 December 2008‎の版を参考にしていると思うんですが、そちらにも「footnotes」の語は出てきませんがUsageを見ると脚注としてreflistと同じように用いているんですよ。ですから誤訳とは言えないんじゃないですかね。英語版の記事を見ても“References”節＝「脚注」節になっている記事が多くあります。（本質にはあまり関係ない話ですが。）--Waiesu（会話） 2017年1月4日 (水) 14:23 (UTC)
（インデント戻す）（Waiesuさん）「脚注」の意味は調べましたが分かりませんでした．あなたが思っている意味を書けば済む話ではないのですか？　それともう一度言いますがテンプレートの使用実態をご覧になった方がいいでしょう．「書籍情報をreference内に書くこともよくあ」るのならreflistもrefbeginも30emでいいのでは？
私には（コミュニティからの）大きな反発があるようには見えません．自警云々は真に受ける方がどうかしています．仮にそのようなことがあったとして，包丁は殺人に使われるから一般家庭での使用を禁止しましょうというのと同じくらい馬鹿げた話です．
「列数指定の非推奨化」は“目的”ではなく，あまりそこに強くこだわるつもりはないので，「列幅指定の推奨化」でみなさんの合意が得られればそれでもいいと思います．
（新幹線さん）では，reflistは20emで「最低幅の確保」ができるとお考えでしょうか？新規作成 (利用者名) （会話） 2017年1月4日 (水) 12:14 (UTC)

text: 辞書の引き方をご存じないならば大変気の毒ですが、幸いなことにインターネットさえ使えればコトバンクという便利な辞書サイトも参考になります。そちらによればページの下部、本文の枠外に表記される短文。フットノートとも呼ぶ。用語の注釈や、補足説明などを記述する。とのことです。（ウィキペディアにおいては）枠外かどうかはさておきページの下部で補足説明に近いもの（注釈・出典/参考文献など）は脚注といえるでしょう。

text: なぜ30emにこだわるのですか？ 最低限であれば20emが妥当でしょう。最低限を大きい値にするのは列数指定を否定するのと変わらないと思います（新規作成さんはそれを望んでいるのでしょうけど）。--Waiesu（会話） 2017年1月4日 (水) 14:23 (UTC)
replies: text: :「Usageを見ると脚注としてreflistと同じように用いている」って正気ですか．<ref> と対応しているか否かという大きな違いがあるのですが．

text: :あなたは脚注と思う．私や新幹線さんは思わない．辞書の引き方の問題ではありません．

text: :文献情報をフルで書いて20emじゃ短い場合が多いからです．新規作成 (利用者名) （会話） 2017年1月4日 (水) 14:35 (UTC)
replies: text: :: すでにreferenceタグの有無に限らずと言っています。そのタグが列幅にどう関係するのか私にはわかりませんのでご教示願います。辞書が引けないと読み違えまして失礼しました。20emが何に対して短いのですか？ 20emあっても読めないのですか？--Waiesu（会話） 2017年1月4日 (水) 14:48 (UTC)
replies: text: ::: 確かに英語版では "References" 節を脚注形式で書いているものが多く見られますが、だからといって "References" = 「脚注」とはなりません。Refbeginテンプレートは  general references 形式で出典を挙げるときに使うテンプレートですが、性質としては関連項目や外部リンクのリストと近く、それ単体で情報が成立するので「用語の注釈や、補足説明」とは言えません。

text: ::: 短い注釈が混入する可能性のある Reflist と異なり、 Refbegin は専ら書誌情報を示すために使われるテンプレートなので、短い文が混入する可能性は非常に少ないです。そのため最低幅を長めに取るのは合理的だと思います。--新幹線（会話） 2017年1月5日 (木) 01:18 (UTC)

text: ::: 既に新幹線さんからのご説明があるので，私から同じ説明は不要かと思いますが，補足すれば，refbeginはreflistやrefタグと組み合わせて用いられることもありますが，数はかなり少ないです．……だとどっちの設定が適用されるのか分かりませんが，いずれにしてもrefbeginは30emで問題ないと思います．また，reflistは20emでも妥協すると既に言っています（し今でも変わりません）．新規作成 (利用者名) （会話） 2017年1月5日 (木) 04:54 (UTC)

text: （逸れた話題を元に戻します）すでに決定したreflistとは別にrefbeginの最低列幅を決定することは非常に議論が煩雑になります（すでに）。cssも汚くなります。また20emであれば最低限度の幅を確保できますので、これ以上最適な幅を追い求める必要はないと考えています。新規作成さんによればrefbeginは3列以上では組まれていないようですし、モバイル環境から閲覧することを考えても20emを超える列幅の確保は不要でしょう。--Waiesu（会話） 2017年1月6日 (金) 10:28 (UTC)
replies: text: :あなたが煩雑にしているだけではないですか．新幹線さんや私は「最低幅を長めに取るのは合理的」だと考えています．わざわざ短くするメリットは乏しいと思います．div col はどうしますか．新規作成 (利用者名) （会話） 2017年1月7日 (土) 10:10 (UTC)
replies: text: :: わざわざ短くするという表現は気に入りませんが、2人だけで話を進めても問題なので、新幹線さんのご意見（具体的な列幅など）を待ちましょう。--Waiesu（会話） 2017年1月10日 (火) 14:20 (UTC)
 しばらく経っていますがどうしますか．reflistは20em, ref beginは30em, divcolは18emでいいですか．新規作成 (利用者名) （会話） 2017年1月20日 (金) 10:14 (UTC)
 さらにしばらく経ちましたが特に意見はないようですので合意は得られたと見なして編集を依頼しました．新規作成 (利用者名) （会話） 2017年1月30日 (月) 05:36 (UTC)
（おくればせながら報告）列数指定時の列幅の下限を，上述の通りは20em, は30em，は18emにそれぞれ設定しました．ただし，もとの提案にあるMediaWiki:Common.cssではなく，テンプレート本体で実装しています．（commonでやると各自で設定を上書きできる（はず）なのでそのほうがいい気もしますが，私にはどうにもできないので．）新規作成 (利用者名) （会話） 2017年2月22日 (水) 03:17 (UTC)
thread_title:  列数指定時の列幅に下限を設定する提案 

message: 私が見る限り、賛成3、反対1、コメントのみ1、といったところのようで、また賛成者による反対者の主張への反駁に対する否定的なコメントも見られませんので、さらに1週間ほど待って反対がなければ、合意が得られたと解釈し、MediaWiki:Common.cssとTemplate:Reflistの編集を行いたいと思います。なお、テンプレートの編集については、
#列幅指定時にcolumn-count: autoを指定する（css指定に合わせて必要）
#廃止のお知らせを除去する（他の節でも指摘されているように現在全く使用されておらず、不要な処理を増やしているだけ）
を予定しています。（下書きをTemplate:Reflist/sandboxに書いていますのでご確認ください。）--Waiesu（会話） 2016年12月3日 (土) 15:05 (UTC)
 私の提案は列数指定の非推奨化を代替するものであって、私は非推奨化に賛成しません。（提案の意味がなくなってしまう…）--Waiesu（会話） 2016年12月3日 (土) 15:11 (UTC)
*いやWaiesuさんの案を適用したところで列幅指定の方が推奨されることに変わりはないでしょう．列数指定に対して表示がひどいことにならないようにするだけであって，ある人は40emくらいのつもりで指定したが別の人にとっては15emだったみたいなことはおこるわけで．私は代替だなどとは思っていませんでしたが，そのつもりなら（いやそのつもりでなくても）もうちょっと大きめの20emとか25emの方がいいのではないですか？ 15emでは小さいです．また，列数指定に対してはお知らせを出した方がいいかもしれません．使用数を見た感じ，20emなら指定列数と表示が変わることはほとんどなさそうですが．（ちなみに私のパソコン（小さい方だと思いますが）では18emで4列，19--24emで3列，25emで2列となるようです．）scrollのお知らせは別に今すぐ消してもいいんじゃないかと思いますが．新規作成 (利用者名) （会話） 2016年12月4日 (日) 03:34 (UTC)
**  ＞ある人は40emくらいのつもりで指定したが別の人にとっては15emだったそれで何か問題ありますか？元々スマホ等で列幅が小さくなりすぎるという話から始まったわけで、最低限の幅が確保されれば問題は解決すると思いますが。また、15emでは小さいと思ったらユーザーCSSで変更可能です。--新幹線（会話） 2016年12月5日 (月) 05:53 (UTC)
（1つ目）？？ だから列幅指定の方が推奨されますねという話ですが．(2) 新幹線さんは15emが最低限の幅だとお考えなのでしょうか？ (3) 20emでは大きいと思ったらユーザーCSSで変更可能です．（参考に）
<--15em
<--20em
<--25em
<--30em
幅はだいたいこんな感じです．新規作成 (利用者名) （会話） 2016年12月5日 (月) 10:34 (UTC)
replies: text: : 幅が大きくなる分には幾ら大きくなっても閲覧に支障をきたしません。また列幅指定だとかなり前にKinketuさんが仰っていたように「ある人にとっては4列だが別の人にとっては7列」みたいなことも起こりうるわけですが、その点はどのようにお考えでしょうか。最低限の幅には拘っていないので20emの方が良いという意見が多ければ従います。---新幹線（会話） 2016年12月6日 (火) 00:53 (UTC)
replies: text: ::それぞれの環境に応じて列数が変わるのが列幅指定のメリットです．ある環境で7列だろうが10列だろうが，指定した幅が適切であれば，何の問題もないと思います．新規作成 (利用者名) （会話） 2016年12月6日 (火) 13:09 (UTC)
replies: text: ::: ＞それぞれの環境に応じて列数が変わるのが列幅指定のメリットです．必ずしもそうとは言い切れないと思います。1920×1080などといった高解像度の画面でウィキペディアを見る場合、本文自体がかなり横長に表示されると思いますので、それに合わせて脚注も横長になるのが自然な表示だと思います。もちろん、短い脚注がたくさんある場合は列幅固定の方が良いですが。--新幹線（会話） 2016年12月6日 (火) 14:43 (UTC)
replies: text: :::: 一文目と二文目のつながりがよく分からないのですが，短くない脚注がたくさんあるのに横幅が短く設定されるというのは想定していません．新規作成 (利用者名) （会話） 2016年12月7日 (水) 09:45 (UTC)
 scroll は消しておきました．最低列幅の値について他に意見はないでしょうか？ Waiesuさんの考えもお聞きしたいですが．列数指定により列幅が狭くなることがなくなれば確かに列数指定を積極的に排除すべき理由はなくなりますが，しかし列幅指定の方がそれぞれの環境に合わせられることに変わりはないので，列数指定の非推奨まではしなくても，列幅指定の推奨はするべきだと思います．列数を固定しなければならないなんてことはないでしょうし，列数指定を用いるべきという意見は一人も出していません．（div col については col-begin があります（推奨はされないでしょうが）．）時間のある時に指定列数の多い方から列幅に変えていってますが，3列を（個人で）排除するのは難しそう……大きいパソコンだと35em以上になりますし20emだと微妙……．新規作成 (利用者名) （会話） 2016年12月12日 (月) 08:30 (UTC)

text: 時間がとれなくてすみません。具体的な列幅については、15emでも20emでも「極端に見づらい状況が改善されれば」個人的にはどちらでも構わないと思っています。表示幅がちょうど15emの倍数の場合は1列が15emになりますが、それ以外の場合は（多くの場合はこちらになると思いますが）実際は15emより大きくなるわけで、最大29.9…emまであり得ますから、そこまで気にしないというわけです。推奨/非推奨については、この議題と直接関係するわけではないので、別の節で議論したほうがいいと思います。（テンプレートの更新と同時に行う必要はないですから。）

text: なお、MediaWiki:Common.css・テンプレートの更新は最適な列幅について合意が得られ次第、行いたいと思います。--Waiesu（会話） 2016年12月13日 (火) 16:18 (UTC)
replies: text: : 私ももっと早く指摘してればよかったんですけどね．15emでも29emになりえますが29emになるのは表示幅が29em（以上30em未満）の場合しかなく，実際問題15emに近い方が多いでしょう．繰り返しますが15emには反対です．20emならまあいいかとも思いますが，もうちょっと大きくてもいいと思います．大きい画面だと100em以上ありますからそれで4列指定した場合を考えれば妥当な制限でしょう．新規作成 (利用者名) （会話） 2016年12月14日 (水) 11:32 (UTC)
replies: text: :: そうですね。私は特にこだわりがありませんので、20emでもいいかと思います。それより大きいと「閲覧者の利便を確保しながら編集者の意図を再現する」という趣旨からかなり外れてしまいますので（編集者は密にするつもりだったが実際はスカスカに…なんてこともあったり）、私は気が進みません。一応、画面解像度シェアとその場合の列幅についてまとめましたので、よろしければご覧ください（表, 編集可能ですので列幅指定を変更して検討できます）。--Waiesu（会話） 2016年12月18日 (日) 05:02 (UTC)
replies: text: :::もうちょっとというのは25とか30とかじゃなくて22とか23とかのつもりなんですが．表はなかなかの労作ですね，ありがとうございます．新規作成 (利用者名) （会話） 2016年12月18日 (日) 12:58 (UTC)

text: :::そういう細かい部分のせいで今の状態が続くのもどうかと思いますので他に意見がないようなら20emから23emくらいの間でWaiesuさんの方で適当に設定していただけませんか．

text: :::また，まだ案の出ていないrefbeginには30em，div colには18emを提案します．新規作成 (利用者名) （会話） 2016年12月19日 (月) 11:45 (UTC)
replies: text: :::: 概ね5の倍数で指定されている場合が多いようですし、シェア1-3位の解像度において20-23emでは差異がないようですので、20emにしたいと思っています。

text: :::: refbegin, div colについては、どういった理由でそのような提案をされているのでしょうか。私は、全て20emでいいと思うんですが…。--Waiesu（会話） 2016年12月19日 (月) 14:47 (UTC)
用途がそれぞれ違うのですからそれに合わせて設定すべきでしょう．div colの中身は短いことが多いですし，逆にrefbeginは参考文献節（脚注ではなく）に使う（したがって長くなる）ことが多いと思います．新規作成 (利用者名) （会話） 2016年12月20日 (火) 11:14 (UTC)

text: refbeginに関していえばreflistと全く同じではないですか？ 参考文献はreferenceタグの有無に限らず脚注として記載されるはずです。div colは確かに短いかもしれません。それならば15emはどうでしょうか？（div colなんかは短い箇条書きが多そうなのでそもそも列数非推奨にしてもいいと思うんですがね…）--Waiesu（会話） 2016年12月24日 (土) 02:32 (UTC)
replies: text: : それは本気で言っているのでしょうか？ See e.g. ．新規作成 (利用者名) （会話） 2016年12月24日 (土) 08:00 (UTC)
replies: text: :: 期間が空いてしまって申し訳ありません。私が述べた「脚注」は辞書的な意味です。その例を見ても「参考文献」は脚注として記載されていますし、reflistとrefbeginの違いはreferenceタグを用いているかウィキ文法の箇条書きを用いているかの差異です。出典と参考文献は内容的に近いはずですから、同じ列幅で全く問題ないと思います。div colについてはどうお考えでしょうか。--Waiesu（会話） 2017年1月2日 (月) 01:46 (UTC)
replies: text: ::: あなたが脚注をどういう意味で用いているのかいまいち分かりませんが，もう少し各テンプレートがどのように使われているか見てからコメントした方がよいのではないでしょうか．「refbeginは参考文献節（脚注ではなく）に使う（したがって長くなる）ことが多いと思います」という私の以前の発言についてどのようにお考えでしょうか．そもそもrefbeginは3列以上が使われていません（この書き込みの直前に4列を5つと5列を1つ消しましたが（そもそも使い方が間違っているのもあるし））．

text: :::div colについてはそこまで小さくする必要はないのではないかと思います．列数非推奨については初めからそう言っています．

text: :::また「非推奨化に賛成し」ない理由を述べるべきだと思います．下に節も作ってます．新規作成 (利用者名) （会話） 2017年1月2日 (月) 08:22 (UTC)
replies: text: :::: 「脚注」の意味をお調べいただいたでしょうか。申し訳ありませんが、言葉が通じなければ議論を進められません。

text: ::::（reflist, refbeginについて）「列数指定の非推奨化」に賛成しない理由は、上記の通り大きな反発があること、「自警」が蔓延る原因になりかねないことです。「列幅指定の推奨化」ならば賛成します。--Waiesu（会話） 2017年1月3日 (火) 12:01 (UTC)
replies: text: :::::新規作成さんが例示されている（参考文献節）は本文の一部なので、普通は「脚注」とは言いません。私もrefbeginに関しては最低幅を長めに取ってもいいと思います。「列数指定の非推奨化」については、以前述べたように最低幅の確保だけで十分だと思うので反対します。むしろ手軽に段組みを設定できるメリットが失われることの方が大きいと思います。--新幹線（会話） 2017年1月3日 (火) 12:53 (UTC)
replies: text: :::::: 私には脚注節の下にある時点で脚注に見えますし、主従関係も本文主と脚注従という意味で参考文献節は脚注（後注）だと思います。仮にそうでなくてもrefbeginのdocを見る限り、「脚注」のためのテンプレートであることは明らかです。reflistとrefbeginの使う場所が全く異なるならばdocを改訂しなければならないでしょう。どちらにせよ、書籍情報をreference内に書くこともよくありますし、ウェブ出典と区別するにしても著者 (年). 書名. 出版社名.と著者. タイトル. 公開元 (年). アクセス日.の文字数の差異はそんなにないと思います。--Waiesu（会話） 2017年1月4日 (水) 03:25 (UTC)
replies: text: ::::::: Refbeginの解説文はおそらく英語版の「References」節と日本語版の「脚注」節を混同したことによる誤訳ではないかと思います。「References」に「脚注」という意味はありません（「脚注」は「footnotes」）。英語版の解説文を見るとRefbeginでは「footnotes」という文字は出てきませんが、Reflistの方では「footnotes」のためのテンプレートとはっきり書いてあります。--新幹線（会話） 2017年1月4日 (水) 04:35 (UTC)
replies: text: :::::::: 日本語版のdocは時期的に英語版 21:59, 26 December 2008‎の版を参考にしていると思うんですが、そちらにも「footnotes」の語は出てきませんがUsageを見ると脚注としてreflistと同じように用いているんですよ。ですから誤訳とは言えないんじゃないですかね。英語版の記事を見ても“References”節＝「脚注」節になっている記事が多くあります。（本質にはあまり関係ない話ですが。）--Waiesu（会話） 2017年1月4日 (水) 14:23 (UTC)
（インデント戻す）（Waiesuさん）「脚注」の意味は調べましたが分かりませんでした．あなたが思っている意味を書けば済む話ではないのですか？　それともう一度言いますがテンプレートの使用実態をご覧になった方がいいでしょう．「書籍情報をreference内に書くこともよくあ」るのならreflistもrefbeginも30emでいいのでは？
私には（コミュニティからの）大きな反発があるようには見えません．自警云々は真に受ける方がどうかしています．仮にそのようなことがあったとして，包丁は殺人に使われるから一般家庭での使用を禁止しましょうというのと同じくらい馬鹿げた話です．
「列数指定の非推奨化」は“目的”ではなく，あまりそこに強くこだわるつもりはないので，「列幅指定の推奨化」でみなさんの合意が得られればそれでもいいと思います．
（新幹線さん）では，reflistは20emで「最低幅の確保」ができるとお考えでしょうか？新規作成 (利用者名) （会話） 2017年1月4日 (水) 12:14 (UTC)

text: 辞書の引き方をご存じないならば大変気の毒ですが、幸いなことにインターネットさえ使えればコトバンクという便利な辞書サイトも参考になります。そちらによればページの下部、本文の枠外に表記される短文。フットノートとも呼ぶ。用語の注釈や、補足説明などを記述する。とのことです。（ウィキペディアにおいては）枠外かどうかはさておきページの下部で補足説明に近いもの（注釈・出典/参考文献など）は脚注といえるでしょう。

text: なぜ30emにこだわるのですか？ 最低限であれば20emが妥当でしょう。最低限を大きい値にするのは列数指定を否定するのと変わらないと思います（新規作成さんはそれを望んでいるのでしょうけど）。--Waiesu（会話） 2017年1月4日 (水) 14:23 (UTC)
replies: text: :「Usageを見ると脚注としてreflistと同じように用いている」って正気ですか．<ref> と対応しているか否かという大きな違いがあるのですが．

text: :あなたは脚注と思う．私や新幹線さんは思わない．辞書の引き方の問題ではありません．

text: :文献情報をフルで書いて20emじゃ短い場合が多いからです．新規作成 (利用者名) （会話） 2017年1月4日 (水) 14:35 (UTC)
replies: text: :: すでにreferenceタグの有無に限らずと言っています。そのタグが列幅にどう関係するのか私にはわかりませんのでご教示願います。辞書が引けないと読み違えまして失礼しました。20emが何に対して短いのですか？ 20emあっても読めないのですか？--Waiesu（会話） 2017年1月4日 (水) 14:48 (UTC)
replies: text: ::: 確かに英語版では "References" 節を脚注形式で書いているものが多く見られますが、だからといって "References" = 「脚注」とはなりません。Refbeginテンプレートは  general references 形式で出典を挙げるときに使うテンプレートですが、性質としては関連項目や外部リンクのリストと近く、それ単体で情報が成立するので「用語の注釈や、補足説明」とは言えません。

text: ::: 短い注釈が混入する可能性のある Reflist と異なり、 Refbegin は専ら書誌情報を示すために使われるテンプレートなので、短い文が混入する可能性は非常に少ないです。そのため最低幅を長めに取るのは合理的だと思います。--新幹線（会話） 2017年1月5日 (木) 01:18 (UTC)

text: ::: 既に新幹線さんからのご説明があるので，私から同じ説明は不要かと思いますが，補足すれば，refbeginはreflistやrefタグと組み合わせて用いられることもありますが，数はかなり少ないです．……だとどっちの設定が適用されるのか分かりませんが，いずれにしてもrefbeginは30emで問題ないと思います．また，reflistは20emでも妥協すると既に言っています（し今でも変わりません）．新規作成 (利用者名) （会話） 2017年1月5日 (木) 04:54 (UTC)

text: （逸れた話題を元に戻します）すでに決定したreflistとは別にrefbeginの最低列幅を決定することは非常に議論が煩雑になります（すでに）。cssも汚くなります。また20emであれば最低限度の幅を確保できますので、これ以上最適な幅を追い求める必要はないと考えています。新規作成さんによればrefbeginは3列以上では組まれていないようですし、モバイル環境から閲覧することを考えても20emを超える列幅の確保は不要でしょう。--Waiesu（会話） 2017年1月6日 (金) 10:28 (UTC)
replies: text: :あなたが煩雑にしているだけではないですか．新幹線さんや私は「最低幅を長めに取るのは合理的」だと考えています．わざわざ短くするメリットは乏しいと思います．div col はどうしますか．新規作成 (利用者名) （会話） 2017年1月7日 (土) 10:10 (UTC)
replies: text: :: わざわざ短くするという表現は気に入りませんが、2人だけで話を進めても問題なので、新幹線さんのご意見（具体的な列幅など）を待ちましょう。--Waiesu（会話） 2017年1月10日 (火) 14:20 (UTC)
 しばらく経っていますがどうしますか．reflistは20em, ref beginは30em, divcolは18emでいいですか．新規作成 (利用者名) （会話） 2017年1月20日 (金) 10:14 (UTC)
 さらにしばらく経ちましたが特に意見はないようですので合意は得られたと見なして編集を依頼しました．新規作成 (利用者名) （会話） 2017年1月30日 (月) 05:36 (UTC)
（おくればせながら報告）列数指定時の列幅の下限を，上述の通りは20em, は30em，は18emにそれぞれ設定しました．ただし，もとの提案にあるMediaWiki:Common.cssではなく，テンプレート本体で実装しています．（commonでやると各自で設定を上書きできる（はず）なのでそのほうがいい気もしますが，私にはどうにもできないので．）新規作成 (利用者名) （会話） 2017年2月22日 (水) 03:17 (UTC)
thread_title: 下限 (2)

message: こちらに新たに提起しました．reflistに限らない一般的な議論はそちらに．新規作成 (利用者名) （会話） 2016年12月18日 (日) 12:58 (UTC)
何の対策もされていない現時点では非推奨化の合意は取れていると言ってもよさそうですが，3つのうちのみ列数指定を非推奨化して，とについてはもうしばらく（とくにWaiesuさんの）反応を待ってみようと思います．新規作成 (利用者名) （会話） 2017年1月3日 (火) 08:55 (UTC)
thread_title: 列数指定の非推奨化あるいは列幅指定の推奨化（続き）

message: このように修正して scroll 部分をこの版のものにしようと思いますがいかがでしょうか？（#複数の列 の奇妙は空白は除きます．）新規作成 (利用者名) （会話） 2016年11月8日 (火) 10:43 (UTC)
replies: text: えーと、それより先に。順番に参りましょう。「（前レスで言及するのを忘れていましたが、docについては問題ないと思います。）--Waiesu（会話） 2016年11月7日 (月) 05:20 (UTC)」と言うご意見があり、かつ、私はその状態が適切だと判断した事実があるんですよね。それはこの版。あなたはそれを勝手に改変されました。発見した私が戻しましたが、更に改変を行われましたね。私は腕ずくの編集合戦など好みませんのでこれ以上差し戻しなどは致しませんが、まずこの状況で事前に何ら相談なく腕ずくの編集を行われた理由を、誰もが納得できるように説明してください。そもそも何故相談なしに改変しようと言う結論に至り、即断実行してしまうのですか？他人の意見を聞こう、とは思わないのですか？--Hman（会話） 2016年11月8日 (火) 21:02 (UTC)
replies: text: :説明はもう書いてるわけですが，Hmanさんはなぜあのようなを事前に何ら相談なく行われたのでしょうか？ 新規作成 (利用者名) （会話） 2016年11月9日 (水) 12:14 (UTC)
「Help‐ノート:脚注での合意」よりは「Help‐ノート:脚注での合意」の方がいいですかね．新規作成 (利用者名) （会話） 2016年11月9日 (水) 12:14 (UTC)
* (報告)  アカウントは、各種方針の熟読が必要との理由、（特におそらく強行編集が目に余る）との理由でブロックされました。これでやっと腰を落としてお話ができます。というわけで、他の皆様方のご意見を伺いたいと思います。勝手に列幅指定、colwidthが推奨とされてしまったかつての版とは違い、現状俎上に登っております、docの二つの版は、結局のところ旧来の版と、列幅指定、colwidthについての説明も加えた版、どちらが好ましいかと言うお話になります。言い換えれば、列幅指定を隠し機能にするのか、普通に説明書に書いて置くのかの違いとなりますね。なお、jawpではreflistで列幅が指定されるケースは、大体1/21弱程度のレアケースであるそうです。私は実際に見たことがありません。なお英語版では、列幅指定、列数指定ともに説明があります。強い合意もなく列幅指定を推奨にしてしまうような運用に大きく関わる改変でもありませんし、また今回は既にお知らせ・コメント依頼共に提出し広く広報しておりますので、多くの方がご覧になられているでしょう。合意の形成期間は1週間で充分と思量致します。できましたら、旧来の「widthを隠し機能にしておく」のか「widthを公開する」のか、このどちらが適切であるとお考えなのか、この点がよくわかりますかたちでご意見を頂ければと思います。私感ですが、公開すればwidthを用いられる方は増えるでしょう。それが良いことなのか悪いことなのかはわかりません(列幅指定が非推奨と言う合意などはないようですし。現状では列数指定ががデファクトスタンダードとみなして良いとは言えそうですけど)。

text: なお、特にご意見が多く集まらない、合意に達したとまでは言えない、と言う場合、議論が始まる以前の旧来の版、すなわち「widthを隠し機能にしておく」版が選ばれるのが、恐らく慣例に倣ったものと思いますので、そのように処理されるべきと考えます。この点については、多くの方から支持が得られるものと思います。個人的は考え方の違いであり、どちらでもいい問題ですが、「従来列幅指定のみだったので表示が数種類に落ち着いていたものが、列幅指定が可能とわかるとやりたがりが妙なbot爆撃などを行い、閲覧者が戸惑う可能性」を考慮しながらも、「enで公開しているものをわざわざ隠しておくことも・・・」とも思います。「現在、日本語版では主流ではありません」との事実を申し添えた上で列幅指定の説明も付けておく、と言うのがよろしいと考えております。言い換えればdocはあくまでテンプレートの説明文ですから、現在のテンプレートの機能および運用法に追従するのみがよいとなります。--Hman（会話） 2016年11月9日 (水) 16:02 (UTC)

text: 列幅指定も列数指定も、テンプレートの機能として淡々と記述されていれば宜しいものと思量します。どちらの機能を選ぶか或は使用しないかについては、生成される脚注の長さや数に因ります。それは記事毎に異なり一意に決められることではありませんので、推奨する・しない等の指示の肥大化も、どちらが現状で偶々主流である等の分析も不要です。

text: 列数指定では低解像度環境において画面スクロールを強制される虞があること、列幅指定では孤立行が発生する虞があることについては記述されて然るべきであると存じます。これらを含めて全ては記事の体裁次第で、botで一律にどうにか出来ることではありません。やりたがりを考慮して運用法を詳述することも、不要であり不用であると思います。

text: あとついでに。冒頭部に混入している「だ・である」調は、「です・ます」調に直しておくべきでしょうね。--LudwigSK（Talk/History） 2016年11月10日 (木) 01:17 (UTC)
replies: text: : 本論について、「列幅指定についても書いて置くべき」と言う点は、了承致しました。

text: : しかし、ご提案の、注意点の加筆につきましては、本質的には強く賛同させて頂くものなのですが・・・新たに何かを加筆するとなりますと、その文章（訳文）について一定の検討が必要となります。まずは誰かが勝手にやってみるか（勿論、取り敢えずやってみて！との合意の上でとなります）、テストページや本ページで文章を提示されることが必用となり、これは場合によっては節を改めました方が、かえって話が早くなることもありそうです。この点につきましては、今の時点では流れに任せる感じがよろしいのではないかと思います（例えば明日にでも誰かが改訂用テストページを作成し、総員がＯＫ！となれば、列幅の説明も明記、で収まる前提下においてですが、提議から7日時点を以て合意形成となるでしょう。しかし誰も具体的な文案を出さないから自然消滅、などもあり得、現時点では判断できません）。

text: : なお、別に変更について合意が得られたからと言って、私が編集すると決まっている訳ではまったくありません。むしろ、現在仕切っているかたちである私（及び アカウントを使用している方）以外が編集される方が、共同作業を旨とするwikipediaでは、好ましいとも言えると考えます。文体の不一致についても了解致しました。他のページとの整合性もあり、doc関係でも事実上の標準である「です・ます」統一でよろしいでしょう。特に高い国語力が要求されるものでもありませんから、実際に編集される方に一任でよろしいでしょう。積極的なご参加をお待ち申し上げます（手が挙がらない場合は致し方無し、私がやりますｗ）。もちろん引き続き、ご意見も募集しております。--Hman（会話） 2016年11月10日 (木) 10:14 (UTC)
replies: text: ::こんばんは。とりあえず、「テンプレートの解説ではですます調がデファクトスタンダード」ということでいいようでしたので、現状のdocの内容を維持したままで、ですます調への修正のみ行いました。--Puntti ja (Talk) 2016年11月11日 (金) 09:00 (UTC)

text: :: 利用者:Puntti ja/sandbox/Template:Reflist/docにて、現在のdocと英語版のdocの一部を組み合わせた状態のものを作成してみました。この内容を翻訳すればよろしいでしょうか?--Puntti ja (Talk) 2016年11月11日 (金) 09:30 (UTC)
replies: text: ::: わざわざお時間を取って頂き、ありがとうございます。深く感謝致します。

text: ::: 1.ですます調への変更については、単純に語尾を統一するだけの話であり、内容自体は全く変わっていないとみてよいと思います。よって、今後細かい部分で指摘が入る可能性はありますが、私は差しあたりこの版を追認します。ただし他の方より異義があった場合には戻される可能性もございます点、予めご了承ください（何分、私個人が追認すれば通ると言う問題ではございませんので・・・）。

text: ::: 2.えー、その・・・見られている方が英語に堪能な方ばかりとは限りませんので、もしご負担でないのであれば、翻訳を行って頂いた上でご提示頂いた方が、一つの案の完成形が良く見えますため、好ましいと思います。お願いできますでしょうか？ --Hman（会話） 2016年11月11日 (金) 10:08 (UTC)
replies: text: ::::了解いたしました。もしかしたらある程度大雑把な内容説明になってしまうかもしれますが、やってみます。Lorem ipsum部について何かよさげなテスト文ありますか?--Puntti ja (Talk) 2016年11月11日 (金) 10:21 (UTC)
replies: text: ::::: え、えっと、日本語話者に馴染みのある感じで、翻訳されながら、ふと思い付いたもので、差しあたりはよいのではないでしょうか ^^;。太郎は花子に恋をしていた、とか・・・いや本当、なんでもいい所と思います。もしナイス・アイディアをお持ちの方がいらっしゃれば、後日提案されると思いますが、よほど変なモノ・長大なモノでない限り、特に問題とはされない部分でしょう。--Hman（会話） 2016年11月11日 (金) 10:38 (UTC)
replies: text: :::::: 都合良く思いつかなかったのでそのままにしましたが、大雑把に訳してみました。ご確認お願いします。手を入れていないので、:en:template:Sfnoteの記述があったり、列数指定の例が載っていなかったりしていますがお許しください。--Puntti ja (Talk) 2016年11月11日 (金) 12:17 (UTC)
replies: text: ::::::: 大変迅速にご対応頂き、驚いております。ありがとうございます。現在で更新版のイメージは十分、利用者各位に伝わる状態にあると思います。LudwigSK様、いかがでございましょうか。例文の訳文、Sfnoteにつきましては、急ぐ必要はないでしょう。列数指定の説明と合わせ、また気が向かれました時にでも進めて頂けましたら幸いに存じます。「それくらいはお前がやれよ！」と言う気も致しますが、サンドボックスとは言え他人様の利用者ページを編集するのは、あまり一般的なことではありません。申し訳ございません。また非常に細かい部分については、本番でdocに転記されてから、（時として独断であり、時として提案となるでしょうが）利用者各位による修正が入るものでございますので、あまりに細かい所までこだわられることはないと思料致します（個人的にはてにをは以上の修正はについては慎重であるべきと思うのですが、各種の説明文については慣例としてはかなりの部分が、独断専行での加筆や英語版からの輸入が許されてしまっているようです。ですが申し上げるまでもなく、独断であった場合は異義が生じればほぼ例外なくrvされるべきです）。なお、Puntti ja様は、詳しい使用法の掲載に賛同される方、と認識させて頂いて、よろしいのでございましょうか？--Hman（会話） 2016年11月12日 (土) 02:14 (UTC)
どちらかと言えばそうなります。むしろ、「泣き別れ」の恐れがあることを記載しないことは大きくはないですがリスクがあるものと考えていますので、個人的には現状の引数説明に加えて「泣き別れ」注意文があれば良いのかな…と思っております。--Puntti ja (Talk) 2016年11月12日 (土) 02:23 (UTC)

text: ご返答ありがとうございます。どの程度まで加筆が行われることになるのか、ほぼPuntti ja様に翻訳して頂いたものに準じることになるのかは今後の展開次第ですが、ある程度の加筆は必要とお考えの旨、了解致しました（細かいわうざったいわで大変申し訳ございませんが、こう言った場では皆さんのスタンスの確認が、最終的な合意の判断に強く影響致します。ご容赦を賜りたく存じます）。——以上の署名の無いコメントは、Hman（ノート・履歴）さんが 2016-11-12T02:33:01 (UTC) に投稿したものです（Puntti ja (Talk)による付記）。
*  やや遅れてしまいましたが、「Wikipedia:投稿ブロック依頼/新規作成 延長 20161111」を提出致しました事を、ご報告申し上げます。(この節に書くか迷いましたが、ここに書くのが将来的に一番混乱が少ないと判断しました)--Hman（会話） 2016年11月11日 (金) 10:26 (UTC)

text: *  報告。「Wikipedia:投稿ブロック依頼/新規作成 延長 20161111」は、議論の結果、終了（ブロックせず）に決定しました。--240D:0:F611:A500:E002:F3D1:C4AC:9EA7 2016年12月1日 (木) 13:54 (UTC)
「列幅指定、colwidthについての説明」は、簡略化されているだけで旧来の版にもありませんか？ 簡単に確認してみましたが、初版（つまり2007年の段階）からcolwidthパラメータの説明はあります。この点はHmanさんの誤解だと思われます。ご確認ください。--新幹線（会話） 2016年11月11日 (金) 23:24 (UTC)

text: なるほど、確かに初版近くからございますので、その解釈でよろしかろうと思います。わざわざのコメント・ご指摘に深く感謝致します。でありましたら、これ以上、説明を掲載すべきかの是非の議論は恐らく不要であり、お話を続けるのであればこの機会に説明の「適切な拡張・改善」を行う、と言うかたちになろうかと思います。上記の如く、英語版を後追いするかたちでの改善案が出ており、検討されております。勿論、異義、すなわち「このままでいい！」とお考えの方は、ご遠慮なくコメントを頂けたらと思います。新幹線様におかれましてはこの点について、いかようにお考えでございましょうか？--Hman（会話） 2016年11月12日 (土) 02:01 (UTC)注目を集めるため、報告アイコンを附記--Hman（会話） 2016年11月12日 (土) 02:14 (UTC)
replies: text: : 利用者:Puntti ja/sandbox/Template:Reflist/docを拝見しましたが、今回追加する「文字列の泣き別れ（Widow and orphan、直訳では「未亡人と孤児」)」の部分の表示が英語版とは異なっているようですね（なぜか脚注が中央揃えになっている）。class="reflist" の仕様が英語版と異なっているのでしょうか。--新幹線（会話） 2016年11月12日 (土) 08:47 (UTC)
replies: text: :: 環境を教えていただけますか?私の確認できる環境では、Windows10のFirefoxでは「泣き別れ」が起き、iPadからデスクトップ版を見ると起きませんでした。iPadからモバイル版を見ると発生するのですが。Androidスマホは横幅の都合で起きているのか起きていないのかはっきりしませんでした。--Puntti ja (Talk) 2016年11月12日 (土) 08:56 (UTC)
replies: text: :::Windows7 + Google Chromeです。IE11では「泣き別れ」が起きていました（IE11の出力結果を見て「泣き別れ」がようやく理解できた）。Google Chromeでは、脚注が途中で改行され、かつ中央揃えになっていますが、「泣き別れ」は起きていません（英語版では左揃え）。--新幹線（会話） 2016年11月12日 (土) 09:45 (UTC)
replies: text: ::::もしかしたらですけど、デスクトップ版をWebkitもしくはBlinkを採用したブラウザで開くとそうなるのかもしれません。後でEdgeとOpera、Chrome(いずれもWin10)で検証してみます。他の方々もどのように見えるのか報告してくだされば有り難いです。ところで、Widow and orphanの訳、何がいいんでしょうか…「泣き別れ」はあまりにも分かりにくいと私自身思いますけど、思いつきません。--Puntti ja (Talk) 2016年11月12日 (土) 10:04 (UTC)
以下に私と新幹線さん、Hmanさんの環境下におけるテスト結果を置いときます。
環境                            	ソフト                   	バージョン                        	分裂  	特記事項
Windows 7 (SP1)               	Internet Explorer     	11.0.9600.18524CO            	○   	
Windows 7 (SP1)               	Google Chrome         	54.0.2840.87 m (64bit)       	×   	中央揃えで改行される。
Windows10 RS1                 	Internet Explorer     	11.447.14393.0               	○   	
Windows10 RS1                 	Firefox               	49.0.2                       	○   	
Windows10 RS1                 	Google Chrome         	54.0.2840.99 m (64bit)       	×   	中央揃えで改行される。モバイル版表示では左揃え。
Windows10 RS1                 	Opera                 	41.0.2353.56                 	×   	Google Chromeと同一。
Windows10 RS1                 	Microsoft Edge        	38.14393.0.0                 	○   	
Windows10 RS1                 	Lunascape             	6.14.2(AppleWebKit 537.21)   	○   	
iPad Air 2 (iOS 9.3.3)        	全ブラウザ(と思われる)          	AppleWebKit 601.1.46         	×   	デスクトップ版を表示した場合
iPad Air 2 (iOS 9.3.3)        	全ブラウザ(と思われる)          	AppleWebKit 601.1.46         	○   	モバイル版を表示した場合
Smart TV Box                  	標準ブラウザ                	Android 4.0.4                	○   	
iMac (OS X El Capitan 10.11.6)	Safari                	10.0.1 (AppleWebKit 602.2.14)	△   	ウィンドウ幅などで挙動が変動
iMac (OS X El Capitan 10.11.6)	Google Chrome         	54.0.2840.71 (64-bit)        	×   	ウィンドウサイズにより左か右に固定
iMac (OS X El Capitan 10.11.6)	Firefox               	49.0.2                       	○   	
iMac (OS X El Capitan 10.11.6)	Opera                 	41.0.2353.56                 	×   	WindowsのGoogle Chromeと同様。
起きない環境もやはり存在するようです。こういう表って記載しといた方がいいですかね?--Puntti ja (Talk) 2016年11月12日 (土) 13:22 (UTC)

text: おお、これは労作ですね。・・・うーん、どうなんでしょう。一目、肥大化が気になりましたが、よくよく考えるとreflistのdocって、そんなに見るモノではない。使い方簡単ですからね。執筆者ならすぐ使いこなせる(いつか仕様や運用が変更される時が来れば、もちろんその時は一時的にアクセス数は増えるでしょうけど)。基本は初心者さん向けのものの気がします。そういう意味では書いて置いて困る情報ではないと思います。「どの程度深刻なものか」の指針になっているでしょう？？ サブページ化してリンク、と言う案も頭をよぎりましたが、あまりスマートではありませんし、「必要な情報」ならそのまま載せておくべき、が、折り畳みすら推奨されないjawpの基本の考え方のようにも思います。掲載されるなら、一応(2016年11月現在)は付けておきましょうか？versionを明記していれば不要だと言う考え方もあるでしょうが、わかりやすくはなりそうです。なお以上はあくまで私見であり、他のご意見を持たれる方がいらっしゃった時に、強く反対するつもりはありません。微妙な線です。「是非載せるべきだ！」との確信を得られるだけの根拠がまだ私の中にありません。--Hman（会話） 2016年11月12日 (土) 13:37 (UTC)
replies: text: :削るとすれば、利用者が少なそうなものを全て削り、IE、Edge、Firefox、Chrome、Safariのみにするのがいいでしょうね。できれば、どなたかMacBookとかiMacでテストしてくださるとありがたいのですが。表自体が冗長なのでしたら、「環境によっては問題が起きることもあるので、可能ならば複数の環境でテストするのが望ましい」とか、文章で書くのも手ですね。--Puntti ja (Talk) 2016年11月12日 (土) 14:02 (UTC)
replies: text: :: はい。正解が無い問題、将棋で言うならどれも一局、と言うものも、多いものです（・・・とわからずに無益な議論が繰り返されているのを良く見ますが・・・）。全部載っていてもいいし、主要なものが載っているのもいいし、別ページにしちゃうのもいいし、です。靴下の心配も無さそうですから、多数決でもいいですし、翻訳者であるPuntti ja氏に任せるわ、でも、なんか仕切ってるHmanに任せるわ、でも、本当になんでもいいと思います。しばらく、他の方からご意見が出ないか、お待ちしてみましょう。ここは急ぐ所ではありませんしね。ここだけ後で差し換えることも簡単ですから。--Hman（会話） 2016年11月12日 (土) 17:50 (UTC)
replies: text: ::: iMACがありますので一通り検証してみたのですが、検証しているうちになにがなんだか（何が正しいのか、意図される表示はどれなのか）わからなくなってきました（苦笑）。「これが泣き別れだ！」と言うスクリーンショットでもあれば良いのですが^^;。それにしても、ブラウザによって、その上ウインドゥサイズによって、全く挙動が異なることは、確かなようですね。例えばEDGEではウィンドウ幅が小さい時には良好なのですが、拡がるにつれて、半角SPCのたびに「列」が変わり、私の環境下では3列表示になりました。1つの脚注が隙間だらけで表示されているわけです。MAC版Operaでは","のたびに「列」が変わりました。テンプレートの移植時に問題が？と考え、enで軽く試してみましたが、enでも同様なようです。再現される状況は少ないとは思いますが、列幅指定を取り巻く状況が良いとは認められませんね・・・。--Hman（会話） 2016年11月13日 (日) 08:11 (UTC)
replies: text: ::::検証ありがとうございます。スペースまたはカンマで「泣き別れ」ということですね。列挙したらおそらくキリがないので、「環境(ブラウザ、ウィンドウの幅など)によっては表示がおかしくなることがあります」とか、そういう文章にした方が良さげですね。--Puntti ja (Talk) 2016年11月13日 (日) 09:20 (UTC)
replies: text: ::::: 連続して表示されるべきが、1行に表示される時に意図しないスペースが入ってしまうのが今回の「泣き別れ」と言う解釈でいいのでしたら・・・(MACに移動して再確認中・・・)利用者:Hman/sandboxにまとめておきました。本当にきりが無さそうですね。どうしても列挙するなら、サブページにするとかでしょうか(しかしメンテナンスが大変そうです)。発生する状況は相応にレアですが、発生する可能性があるのは一部の環境、ではなく、少なく無い環境、と言うレベルですね・・・。--Hman（会話） 2016年11月13日 (日) 11:22 (UTC)
replies: text: :::::: まあまあの数になりましたね…Hmanさんのsandboxの内容を表に足しました。可能ならばユーザーエージェントの文字列内「AppleWebKit/nnn.nn」の箇所を表に足していただければ幸いです。私のサンドボックスの内容も変更してみました。「行」「列」をまぜこぜにしてしまっていたため、適切に直しました。「泣き別れ」ですが、単純に「分裂」にしました。--Puntti ja (Talk) 2016年11月13日 (日) 12:41 (UTC)
replies: text: ::::::: ユーザーエージェントにつきましては、利用者:Hman/sandbox 末尾に書き足しました。何分先日まで１年半ほどjawpから離れておりますれば、mediaWikiのややこしい作表にはいささか自信がございませんでしたので、ご容赦を賜りたく存じます。また、泣き別れ部の翻訳および注意書きのご加筆・ご修正について確認致しました。私ならもう少し細かく書くのかもしれませんが、docの読者のほとんどはそれを求めていないと考え得ます。現状で、リリースにおいて問題が無い程度に、良好な状態にあると感じました。色々とお手数をおかけ致します。ありがとうございます。--Hman（会話） 2016年11月14日 (月) 07:29 (UTC)
 追記ありがとうございます。表に反映しました。やはり基本どのOSでもWebKit系ブラウザの一部、Blink系ブラウザのすべてで挙動が想定外(むしろこっちが正しいのかも?)になるようです。細かい挙動差の表は別ドキュメントか展開可能な表にしてみますか？杞憂なのかもしれませんが、必要になるときがいるかもしれませんし。--Puntti ja (Talk) 2016年11月14日 (月) 08:06 (UTC)

text: OSやブラウザの仕様が変更された将来の情報の更新も含めてきりがないとも申せましょうが(例えば、その気になればAndroid環境で複数のブラウザでチェックしてまだ書き足すこともできます・・・)、しかし必要な人には必要との考え方も当然ございます。多くの環境で不具合が発生するので、こういう使い方はするな！・・・で済む気もしないでもありませんが、現時点でただちに「不要な情報だ！」と断じるのは危険な気も致します。でしたら、何らかのかたちで残しては、おきましょうか・・・。折り畳みでの表示とサブページを作成してのリンクの比較であれば、現在の容量程度であれば、前者の方がスマートかとは思いますが。--Hman（会話） 2016年11月14日 (月) 09:03 (UTC)
(1)「colwidth=」は後方互換のために残っているだけであって，テンプレートの最初の説明に書くようなものではありません．また，「…30em}}とすると、…列幅を指定できます」は説明として変だと思います．せめて「とすると」ではなく「のようにすると」とするべきです．簡単な説明を加えてその段落を次のように書きかえてもいいと思います．「 のように長さを書くと、その列幅が確保されるように列数がブラウザに自動設定されます。」（改善の余地はありそうです．）colwidth 引数の説明は，列幅指定の段落の最後でもどこか別のところでも，適当なところに入れておけばいいでしょう．
(2) 単位との間にスペースをいれてはいけないことは英語版には書かれていますが書かなくてよいでしょうか？ em 自体の説明は不要でしょうか？ em 以外の単位について触れる必要はないでしょうか？
(3)「右」の表は環境によっては「上」に表示されますから，「右の」は不要（不適切）です．どこかの方針か何かに書いてあったような気がしますが．
(4) 「使用法」が重複しているので1.1.2の方は変えた方がいいと思います．またそこの30emの後がよく分からないのですが，「多くの脚注があり出典を直接書いている場合」とかでいいのでは．20emの後の  は   ですね．直後の例の脚注は訳した方がいいと思います．Lorem ipsum は有名なのでそのままでいい気もしますが日本語にした方がいい気もします．
(5)「パラメータ」と「引数」が混在しているので統一した方がよいでしょう．またサブセクション「scrollパラメータ（廃止）」は冗長だと思います．以下で十分では．
=== scroll引数（廃止） ===
注意：2009年5月のHelp‐ノート:脚注での合意により、脚注をスクロール表示にしたい場合は各自 Scrolled Reflist というガジェットを利用することになりました。なお、を使っている項目の脚注部分にはclass名として「reflist」が指定されていますので、ウェブブラウザのユーザスタイルシートにMediaWiki:Gadget-ScrolledReflist.cssの内容を転記すればIP利用者でも同等の効果を得ることができます。
(6) 泣き別れを必要以上に問題視しすぎではないでしょうか？ どのような閲覧環境で起こるか以前にどのような脚注を書いたときに起こるかをまず確かめるべきでしょう．原文では「極端な状況」(extreme circumstances) となっていますし，docの例も現実的ではないですし．表はdocにはまずいらないでしょう（サブページへの誘導くらいならしてもいいかもしれませんが）．そもそも泣き別れは本当に問題なのでしょうか．（なお問題視するとすれば，泣き別れの起こる可能性は改行の多い列数指定の方が大きいですから，やはり列幅指定の方が推奨されるでしょう．）
(7) 列数指定の問題は言及すべきです（泣き別れと比べると深刻な問題でしょう）．文案：列数指定の説明文の後に「指定された列数が画面幅に対して大きい場合、少ない文字数で改行されてしまいます。」これだとマイルドすぎる気もしますが．また，泣き別れに例をつけるならこっちにも例をつけていいように思います．新規作成 (利用者名) （会話） 2016年11月16日 (水) 12:37 (UTC)

text: 新規作成さんのコメントを受け、列数指定のダメな例を加え、文章を手直ししました。Lorem ipsumも1つを除き日本語の例文にして見ました。挙動が以前とは変わっているかもしれません。一度ご確認お願いします。--Puntti ja (Talk) 2016年11月16日 (水) 13:34 (UTC)
replies: text: :新たに追加していただいた例についてですが，脚注が1文字ごとに改行（私のパソコンでは）されているので，指定は5列くらいがいいかもしれません．画面の横幅が短すぎると脚注が表示されないバグ？もあるようです．また，脚注をもう少し長くした方がいいと思いました．それと，脚注を入れる場所は，句読点の直前が一般的だと思います．

text: :幅の指定に使える単位は，emだけではありません（）．他の単位を使うことがあるのかは知りませんが．新規作成 (利用者名) （会話） 2016年11月17日 (木) 12:37 (UTC)

text: :補足他．2文字はほしいと思ったのと脚注が表示されない恐れがあるので5列くらいがいいと書きましたが，環境によって異なるのでスクショにしてしまった方がいいのかもしれません．（あるいは「描画」部分の幅を設定する？）脚注非表示も下書きに追加していただきありがとうございます．

text: :scrollは相当前から使われていませんから「この注意文を」の一文は不要ではないでしょうか？新規作成 (利用者名) （会話） 2016年11月19日 (土) 09:34 (UTC)
replies: text: ::スクショについてなのですが、ブラウザの枠といいましょうか、そこの部分はライセンス的にどうなんでしょうか。（たぶんトリミングすれば確実に大丈夫だとは思うんですが…）もちろん、CC-BY-SA 3とGFDLのデュアルライセンスにします。scrollについては消しても問題なさそうな気が私もします。--Puntti ja (Talk) 2016年11月20日 (日) 07:34 (UTC)
replies: text: :::それは大丈夫な気がしますが．上にあげたこれを使ってもよさそうですし．（脚注の分裂も同時に確認できます．）新規作成 (利用者名) （会話） 2016年11月21日 (月) 09:43 (UTC)
replies: text: ::::新規作成さんの画像をそのままお借りして組み込み、元々の英語版から輸入した例の部分を除去して文章を細かいところ書き換えました。だいぶ完成に近づいたような感じがしてきました。--Puntti ja (Talk) 2016年11月22日 (火) 14:03 (UTC)
replies: text: :::::「脚注の分裂」で2箇所「複数行」となっていますが「複数列」では．スクショの例についてはもつけた方がいいと思います．使用法の訳注はdocに残すのかどうか分かりませんが，英語版では「列幅指定推奨」ではなく「列数指定非推奨」です．微妙に異なると思います．新規作成 (利用者名) （会話） 2016年11月23日 (水) 10:19 (UTC)
replies: text: ::::::記事リンクと訳注の件対応しました。訳注は元々docには入れないただのメモとして使用していたので、削りました。記事リンクですが、版番リンクにしておきました。--Puntti ja (Talk) 2016年11月23日 (水) 11:14 (UTC)
コメントアウトがちょっとおかしくなってたのでそこだけ直させていただきました．emは文字サイズによる相対的な単位です．画像の位置はもうちょっと上の方がいいかもしれません（結構空白ができてしまうので）．
これで大きな問題はなさそうですし，一旦反映しちゃってもいいんじゃないでしょうか．新規作成 (利用者名) （会話） 2016年11月24日 (木) 10:44 (UTC)
 現在のUser:Puntti ja/sandbox/Template:Reflist/docの内容でTemplate:Reflist/docを上書きしたいと思います。異論のある方は2016/12/1 23:59(JST)までに意見をお寄せください。反対意見が出なければ2016/12/2 0:00(JST)に上書きしたいと思います。--Puntti ja (Talk) 2016年11月24日 (木) 11:22 (UTC)

text: すみませんあと3点．（使用頻度は少なそうですが）liststyle引数の説明も必要では．"Source name, access date, etc." は日本語にした方がいいのでは．「使用法(Practices)」に代わるいいサブサブセクション名はないでしょうか．新規作成 (利用者名) （会話） 2016年11月24日 (木) 12:44 (UTC)
replies: text: :サブセクション名は消し忘れでしたので対処しました。liststyleについては、英語版のdocでは「:en:Template:CSS list-style-type values」が使用されており、日本語版では未移入ですので、説明としては非常に物足りないものになってしまいました。とりあえずliststyle引数の説明追加は後回しにして、上記テンプレートの移入後に行うことを提案します。--Puntti ja (Talk) 2016年11月24日 (木) 13:48 (UTC)
replies: text: :: とりあえず英語版のどこかに（仮）リンクで誘導してみてはどうでしょう．新規作成 (利用者名) （会話） 2016年11月25日 (金) 11:11 (UTC)
replies: text: :::テンプレート移入までの暫定措置として、テンプレートへの言語間リンクを記載しておきました。テンプレート移入ができ次第置き換えでいきたいと思います。--Puntti ja (Talk) 2016年11月26日 (土) 03:40 (UTC)
 既に十分時間は経っているので．新規作成 (利用者名) （会話） 2016年12月2日 (金) 08:59 (UTC)

text: 最後の編集から1週間経過確認でやろうと思ってたけどたぶん大丈夫そうですね。ありがとうございました。--Puntti ja (Talk) 2016年12月2日 (金) 09:42 (UTC)
 Template:CSS list-style-type valuesを英語版から移入しました。暫定措置として英語版へのリンクにしていた箇所を書き換えています。--Puntti ja (Talk) 2016年12月2日 (金) 14:46 (UTC)
thread_title:  doc 

message: の使用件数を検索してみました（少し古い）。直接呼び出しのみで、間接呼び出しは含まれていません。また、refsパラメータを使用しているものも検索していません。一目瞭然ですが、注釈に使うgroupも含まれていません。
2016年10月27日 (木) 23:38 (UTC)　現在
 Reflist調査
呼び出し方                    	呼び出し方                    	記事数                      	記事数          	記事数    	記事数
              	              	              	  	69,849 	
            	            	            		33,745 	
内訳                       	            	1,580                    	             	33,745 	
内訳                       	            	28,746                   	             	33,745 	
内訳                       	            	3,457                    	             	33,745 	
内訳                       	            	206                      	             	33,745 	
内訳                       	            	1                        	             	33,745 	
内訳                       	            	1                        	             	33,745 	
内訳                       	小計                       	33,991                   	             	33,745 	
         	         	         	             	1,593  	
内訳                       	         	9                        	             	1,593  	
内訳                       	         	1                        	             	1,593  	
内訳                       	         	46                       	             	1,593  	
内訳                       	         	3                        	             	1,593  	
内訳                       	         	6                        	             	1,593  	
内訳                       	         	13                       	             	1,593  	
内訳                       	         	3                        	             	1,593  	
内訳                       	         	1,348                    	             	1,593  	
内訳                       	         	1                        	             	1,593  	
内訳                       	         	19                       	             	1,593  	
内訳                       	         	58                       	             	1,593  	
内訳                       	         	51                       	             	1,593  	
内訳                       	         	1                        	             	1,593  	
内訳                       	         	22                       	             	1,593  	
内訳                       	         	3                        	             	1,593  	
内訳                       	         	5                        	             	1,593  	
内訳                       	         	2                        	             	1,593  	
内訳                       	         	1                        	             	1,593  	
内訳                       	小計                       	1,566                    	             	1,593  	
			             	1,631  	
内訳                       		2                        	             	1,631  	
内訳                       		6                        	             	1,631  	
内訳                       		2                        	             	1,631  	
内訳                       		1                        	             	1,631  	
内訳                       		58                       	             	1,631  	
内訳                       		1                        	             	1,631  	
内訳                       		1                        	             	1,631  	
内訳                       		37                       	             	1,631  	
内訳                       		40                       	             	1,631  	
内訳                       		1                        	             	1,631  	
内訳                       		1                        	             	1,631  	
内訳                       		1,410                    	             	1,631  	
内訳                       		1                        	             	1,631  	
内訳                       		22                       	             	1,631  	
内訳                       		23                       	             	1,631  	
内訳                       		10                       	             	1,631  	
内訳                       		2                        	             	1,631  	
内訳                       		8                        	             	1,631  	
内訳                       		3                        	             	1,631  	
内訳                       		2                        	             	1,631  	
内訳                       	小計                       	1,631                    	             	1,631  	
総合計                      	総合計                      	総合計                      	総合計          	106,736	
--ワーナー成増（会話） 2016年11月12日 (土) 10:49 (UTC)追加。--ワーナー成増（会話） 2016年11月13日 (日) 06:51 (UTC)
replies: text: :  ここにぶらさげます．ワーナー成増さんのは呼び出し方が限定的なので数え漏れがかなりあることは明らかでしたが，実際かなりあるようです．（下の11/23の私の（および今書いてるやつ）では数え漏れは減ってますが余計なのも僅かに入ってます．）また，「特別ページの検索」の検索の方法そのもの（？）も10/27や11/23と今 (12/13) では異なるようで，以前よりきちんと数えられるようになっています．そのことを念頭に置いたうえで，現時点での使用数は，
replies: text: :*2列以上：35302

text: :*2列：31065

text: :*3列：4010, 4206（記事以外含む）

text: :*4列：520, 552 − 17 = 535

text: :*em指定：3966（11/23は3773（私がいくつかの記事の列数指定を列幅指定に書き換える前））

text: :新規作成 (利用者名) （会話） 2016年12月13日 (火) 14:05 (UTC)

text: これを見る限り、とだけで全体の9割以上を占めているようですね。3段だとまだ3%ぐらいあるようですが、4段以上に関してはほとんど使われていないので、列幅指定に移行したとしても大きな混乱はなさそうですね。そもそも現在最も一般的と考えられる横解像度1300px前後のPCで4段以上の指定が活きる場面というのは、ハーバード形式のような短い脚注が大量に並ぶ場面などに限られ、そこまで多くないと思います。--新幹線（会話） 2016年11月12日 (土) 11:25 (UTC)

text: 以前提示された情報に比べますと、ワーナー成増様のご調査では、差が半分程度に縮まり、1:10程度となりましたね。どちらに致しましても、強力な合意なく列幅指定をスタンダード化できる情勢ではございませんが。|2 を指定されている方も、脚注長すぎやん！→あ、右に余白あるやん！→2列指定にしてここ使おう！・・・と言う方が多い気がします。また、列数指定については、折り返し（改行）ができるだけ少なくなる範囲で、かつ右の余白が短くなるケースで最大の効果を発揮すると考えております。私も色々な記事を見て、そして色々な記事を書きましたが、横1920pxで一般的な文字サイズであれば、恐らく2か3が適当となるでしょうが、1366/1280px環境も考えますと、2が無難となりそうです。4以上は、ちょっと、使われて居る方ご本人にご意図を伺ってみないとわかりませんね。また、emはほぼ現在enで推奨されている30に収まっており、かつ10または5単位にピークがあるようでいささか安心でございますが、怖いのは無駄な編集合戦です・・・（そう、和暦問題とかの再燃・・・）。仮に将来、auto機能の実装を考えるに致しましても、emを推奨とするに致しましても、使用実績は大切なものとなります。大変有用なご情報、ありがとうございました。ちなみに私は2列指定を多用しておりましたが、縦に長すぎる（最大で300超くらい出典がついた記事があったと思います）、しかし右側に余白が→なら2列にしよう、これだけのことで、執筆者の好みと言う意味よりは、閲覧者への配慮したいと言う結果やむなく2列に収まったものです。--Hman（会話） 2016年11月12日 (土) 11:55 (UTC)
 若干のゴミが入っている可能性はありますが別の方法で検索してみました．
* 3773
* 33951
** 81
** 556
** 3887
新規作成 (利用者名) （会話） 2016年11月23日 (水) 10:32 (UTC)
thread_title:  使用件数調査 

message: 過去に議論があったようですが、日本語版では列数指定の非推奨化は行われていないようで、em指定または列数指定が一般的に用いられると書かれています。
しかし、TemplateData文書は英語版に準拠しているからか列数指定はdeprecatedとはっきり書かれています。
どちらかを改めたほうがいいと思うのですが…--ひむちや（会話） 2017年8月30日 (水) 00:47 (UTC)
replies: text: そういえばコピペしたまま訳すのを忘れていました．そこの deprecated はのけておきます．新規作成 (利用者名) （会話） 2017年8月30日 (水) 05:20 (UTC)
replies: text: :  --ひむちや (会話) 2017年8月30日 (水) 10:51 (UTC)
thread_title:  列数指定に関する記述の不一致 

message: # Minerva（MinervaのCSSはVectorなどのモバイル・ビューにも適用されるようです）以外の外装において、のに起因してレイアウト崩れが発生することがあり、これはCSSの追加により解消することが可能です。同様の現象が起きていたにおいてはすでに修正を提案済みなので、詳細は以下をご参照ください。
#*Template‐ノート:Columns-list#1: margin-top関連
#*Template:Columns-list/styles.css
#以前報告にあった「泣き別れ現象」（の途中でカラムがブレークする現象）について、Win10 + IE11およびWin10+Firefox 95にて以下のJSにより解消可能であることを確認しました。なお、以前の報告とは異なりChromeにおいても類似の現象が発生する例がありましたが、それは1のCSSの適用により解消されるようです。
#*利用者:JuthaDDA/avoidColumnBreakInsideListItems.js
テストはとくに2に関しては軽く行った程度なので、実際に採用するのであればさらに行う必要があるかと思いますが、その前にまず、これらの問題を解消するためにCSSおよびJSの追加を行うことの是非について、ご意見をいただきたいと考えております（どこにコードを追加するのが適当かの検討もその後でいいかなと思います）。--Jutha DDA（会話） 2021年12月30日 (木) 13:31 (UTC)
thread_title:  段組み表示改善用CSS & JS案