MediaWiki‐ノート:Common.css/過去ログ/2019年

ページのコンテンツが他言語でサポートされていません。

CommonsTicker について[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

CommonsTicker のスタイル群は、 2006年6月頃に「ひとまず」として導入されたものです[1]。その後の経緯は不明ですが、Wikipedia:CommonsTicker を見ると、かつては利用されていたようです[2]。このスタイル群を、現在では使われていないものと判断し、除去してしまおうと思っています。いかがでしょうか。--Frozen-mikan（会話） 2012年4月1日 (日) 16:46 (UTC)[返信]

フォント指定の復帰提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
「Wikipedia:井戸端/subj/現在のWikipediaのフォント」も参照

以下のような指定の追加……すなわち「フォント指定のみの原状復帰」を提案します。 

h1,h2 {font-family: "MS Pゴシック", sans-serif !important; }

とにかく早急に（今日明日にでも）修正すべき問題ですし、投票とか要請などしていては何週間かかるやら分かりません。そもそも相手をしてくれるかどうかすら確証はありません。それよりは、自分たちでjawp内だけでまず対応すべきです。余白変更？については特に批判も出ていませんし、一緒にどうこうする必要はないでしょう。--氷鷺（会話） 2014年4月6日 (日) 03:01 (UTC)[返信]

賛成 明らかな不具合や苦情がある状態ですから、応急処置的にでも問題がある点をまず速やかに現状復帰して従来の形に戻すべきでしょう。Mediawiki側への依頼など今後どうするかということは、現状復帰したあとで腰をすえて議論するのがいいのではないかと思います。--重陽（会話） 2014年4月6日 (日) 03:38 (UTC)[返信]
賛成 不具合がある状況ですので、無視できる問題ではありません。応急処置に賛成します。--リョリョ 2014年4月6日 (日) 03:50 (UTC)[返信]
コメント 賛否は表明しませんが、ご提案の内容でしたら、セレクタを「div#content h1, div#content h2, div#content #firstHeading」とする方が !important 無しに上書き出来ると思います。いかがでしょうか。--Frozen-mikan（会話） 2014年4月6日 (日) 04:02 (UTC)[返信]
質問 類似の案件として、セレクタ「html body」で指定されている本文のフォントについては対処が必要になりますでしょうか。 --Frozen-mikan（会話） 2014年4月6日 (日) 05:03 (UTC)[返信]
質問 変更対象ページについて。本件はベクター外装 (Vector skin) にのみ適用されている変更点に対するご提案だと思いますが、Common.css を変更した方がよろしいでしょうか。--Frozen-mikan（会話） 2014年4月6日 (日) 05:03 (UTC)[返信]
今そういった話をすべきではない、というこの提案の意図はご理解いただけてますでしょうか？ 動作すれば問題ないし、なんなら編集権持ちが勝手に適宜変えてくれて構わない……むしろ今すぐにでも合意云々なしに独断で対処してくれることが望まれています。繰り返しますが、そういう話を悠長にしている事態ではないから、こうしている訳です。ここではその話はお終いにしてください。--氷鷺（会話） 2014年4月6日 (日) 05:42 (UTC)[返信]
コメント そのような対処がお望みでしたら、この件については気にしないことにします。--Frozen-mikan（会話） 2014年4月6日 (日) 05:56 (UTC)[返信]
賛成 　応急処置は早急に行うべきでしょう。細部は応急処置を実行する方におまかせします。細かい事をどうするかまでここで話し合っていては時間を浪費するだけです。応急処置をまず行っておいて、後からさらによくすればいいでしょう。--ぱたごん（会話） 2014年4月6日 (日) 05:23 (UTC)[返信]
提案 念のため。以降は、上記のような具体的な提案には縛られず、あくまで「今回のフォント変更を原状復帰する。具体的な編集箇所・編集内容は、フォント指定の原状復帰という目的に合わせて、対処する編集権者が適宜変更する」ということでお願いします。（それはここでは話さない方向で）--氷鷺（会話） 2014年4月6日 (日) 05:55 (UTC)[返信]
賛成 応急修正に賛成です。本格的な修正についてはまた考えましょう。--Tam0031（会話） 2014年4月6日 (日) 13:28 (UTC)[返信]

コメント 上記のCSSは「MS Pゴシック」と半角文字＋半角スペースで指定されていますが、よく知られているようにこれは「ＭＳ Ｐゴシック」と全角文字＋半角スペースで指定しないと駄目です。もし上記のCSSでMSPゴで表示されたならば、それはお使いのブラウザのデフォルトのゴシック体がたまたま「ＭＳ Ｐゴシック」だったのが sans-sefif で呼び出されただけであり、たとえば私はデフォルトが「IPA Pゴシック」なので「IPA Pゴシック」で表示されます。Frozen-mikan氏が意図を汲んで編集してくださったから良かったものの、このような場で提案するソースとしてはお粗末過ぎます。技術的なことが分からないならば、今後は地の文で提案してください。合理的な提案であれば、分かる人がきちんと編集します。--Starchild1884（会話） 2014年4月25日 (金) 22:20 (UTC)[返信]

今更その程度の苦言ですか。具体的な内容はどうでもよく、議論すべきでもないため、井戸端のものを適当に持ってきただけです。フォント名の全角半角くらいは当然知っていましたし、気づきはしましたが、直す必要も調べる必要も考える必要もないと判断しました。とりあえず動作し問題が改善され、致命的な副作用がなければ良いのですよ。粗末だろうが何だろうがそこは問題ではありません。こうやって素人が口を出してくるのが嫌なら、後でもよい話をぐだぐだと続けていないで、そのお粗末な対応よりマトモなことをさっさとしてしまえば良いのです。それすらしなかった方に偉そうに言われる筋合いはありません。--氷鷺（会話） 2014年4月25日 (金) 23:00 (UTC)[返信]
コメント そうお考えなのであれば、この件に関しては気にしないことにします。--Starchild1884（会話） 2014年4月25日 (金) 23:54 (UTC)[返信]

応急処置の範囲をバグ回避のみに絞る[編集]

応急処置により現在はすべてsans-serifが指定された状態になっています。Windows IEで表示バグが存在する以上、これは必要な処置であったと認識しています。

ですが、目的が「IEのバグ回避」であったのに、現状は「明朝の表示をゴシックに戻す」という、目的外の副作用も含まれてしまっています。ですので、今回の処置の範囲をより狭く、IEのバグ回避のみに絞り込んだCSSに置き換えてはどうかと考えています。 

div#content h1, div#content h2, div#content #firstHeading {
	font-family: "Linux Libertine", Georgia, Times, "游明朝", "HGP明朝B", "ＭＳ Ｐ明朝", serif;
}

このリンクから適用後の状態をテストできます。（テスト用コードには、強制有効にするため !important を追加しています）

意図:

  • デフォルト記述のCSSの意図を最大限尊重すること
  • Win8.1にはクオリティの高い游明朝がバンドルされているのでそれを阻害しないこと
  • Wikipedia:井戸端/subj/現在のWikipediaのフォント#ローカル対応についてでのYhiroyukiさんの意見を参考に、せめてOfficeユーザーだけでもＭＳ Ｐ明朝を使用せずに済むようにしたい
  • Windows以外の環境でユーザー個別のフォント選択を極力阻害しないこと（MacOSにも游明朝があるそうですが、上記の記述では名称が異なり有効にならないはずです）

Win8.1環境がないので、お持ちの方は試してくださると助かります。--cpro（会話） 2014年4月25日 (金) 02:49 (UTC)[返信]

  • コメント 緊急に応急処置が必要だったのはWindows環境でIEの旧バージョンにバグがあったためですが、もう一つ根強い批判があったのは欧文でGerogiaフォントが使用された場合のオールドスタイルの数字と和文との相性が最悪だということです。ですので、Georgiaの指定は抜いておくべきだと思います。--Wolf359borg（会話） 2014年4月25日 (金) 08:01 (UTC)[返信]
オールドスタイルの数字の評判が悪かったことは認識していますし気持ちはわかるんですが、今回の提案はあくまで、応急処置は応急処置としてすべき範囲である「IEのserifバグ回避」にとどめよう、という主旨ですので、そのあたりご理解いただけると助かります。Georgiaについては、強い違和感を抱く人が相当数いたとしても、変更直後では単なる慣れの問題と実際のデザインの悪さとの区別が難しい状態ですので、別途議論しましょう。--cpro（会話） 2014年4月25日 (金) 08:29 (UTC)[返信]
  • 反対 主旨は理解できます。しかしながらGeorgiaの件は単なる慣れの問題と軽視すべきではありません。別途議論ということなら応急処置に修正を施す必要もないはず。よってご提案に反対いたします。--Wolf359borg（会話） 2014年4月25日 (金) 08:49 (UTC)[返信]
問題の切り分けをしませんか。IE対応でフォント個別指定を追加するのはバグ対応です。Georgiaフォントを除去するのはUIの再変更です。--cpro（会話） 2014年4月25日 (金) 09:10 (UTC)[返信]
  • 条件付反対 きちんと選択肢を精査し十分に取捨選択した上でコミュニティによる投票を行うなど、その影響範囲の大きさに見合った意思決定を行うという提案であれば賛成します。現行の応急措置は大々的にコミュニティの意見集約をして意思決定したわけではありませんので、喫緊の問題が一段落したところであらためてコミュニティの信任を得る（もしくは他の選択肢が選ばれる）というプロセスが必要だという意見はあって然りだと思います。しかし、このタイミングでこの規模の提案のみでフォントのカスタマイズを敢行することには反対です。
    現行のローカルcssでも、対応箇所はバグ回避のためのフォント変更のみに絞られており、それ以外の不必要なカスタマイズは行われていないはずで、しかも既に問題発生から数日が経ち応急処置にも成功しており、現時点で具体的なメリットの無い性急な対応が必要とは思いません。
    さらに現在、「mw:Talk:Typography refresh」の方でいろいろなフィードバックを受けて議論が進行しているようですので、その行方をある程度見極めてから対応を考える方が合理的でしょう。Gerogiaの見出しは（英語版の表示でも）やっぱりまずいよとか、非ラテン語圏との相性も考えようとか、いろいろ真剣に考えていただいている方々がいる中で、本家でも異論が出て議論中のスタイルをわざわざ日本語版ローカルのスタイルシートに再導入するメリットは無いと思います。--ディー・エム（会話） 2014年4月25日 (金) 13:27 (UTC)[返信]
    コメント 「対応箇所はバグ回避のためのフォント変更のみに絞られており、それ以外の不必要なカスタマイズは行われていないはず」というのは、そうでもないです。Frozen-mikan氏の編集には body, html 要素に適用されている部分がありますが、韓国漢字問題への暫定対処としては不要なものです。当時「Helvetica, Arial, sans-serif」となっていたのを「sans-serif」で上書きしたわけですが、これは誰からも何も言われませんでしたが、要らなかったのです。--Starchild1884（会話） 2014年4月25日 (金) 22:12 (UTC)[返信]
    それは見出しと本文のフォント指定の整合性を取るために必要だった措置かと思いますし、現在はWMのオリジナルのCSSもバグ対応などのためサンセリフのみの指定になっているようですので、現状では特に追加的な対応は不要かと。いずれにしてもきちんとコミュニティの信任を得るべきというのはあると思いますが、そうであればきちんとした信任投票・もしくは他の選択肢も交えた投票による意思決定の体裁を整えないと、それぞれの主観で「この緊急措置がベストでなかった」とか「こっちの対処方法にしてほしかった」とかいうことを言い合っても意味が無いし、時計の針を巻き戻して緊急時の応急処置を今からもう一回やり直せというのは実利的なメリットが何も無くナンセンスなので。「今からここをこう変えたら現状よりもこんなに良くなる」という具体的な改善案であれば検討対象として意味があると思いますが、それにしても影響範囲に見合う意思決定の体裁は整えないと。--ディー・エム（会話） 2014年4月28日 (月) 14:43 (UTC)[返信]
    コメント 自分としては、mw:Typography_refreshにある「明朝体にすることで節の区切りが分かり易くなるようにした」旨の発言は充分合理的で具体的な改善点でもあり、これは慣れの問題やただの変更アレルギーといった「理由の無い反対」より優先されるのは言うまでもない、と考えているのです。モノブック→ベクターの時も色々ありましたし（その前の変革はそのころ居なかったので知りません）。「Geogiaのオールドスタイル数字はベースラインがほぼ常に揃っている日本語フォントとは絶望的に相性が悪い」というのは充分合理的な反対意見でありGeogiaは除外すべきと思いますが、それは明朝体自体を選ばない理由にならないです（ディー・エム氏の仰った『詳細に個々のフォントを選り好みして指定しているその提案内容はなおのこと「IEのバグ回避のみに絞り込んだCSS」ではない』というのは充分合理的な理由で、先に述べた「利点」と妥協点を見つける必要はあると考えます）。--Starchild1884（会話） 2014年4月29日 (火) 23:48 (UTC)[返信]
条件付賛成 【総括】議論の無意味な長期化を防ぐため、「暫定的に」上記の案から Georgia を除いたものを適用すべきと思います。
今回の「暫定対処」に関しては、まず前提として『フォントが Geogia を含み和文フォントを含まない serif に変更された』ということがあり、続けて
  1. Windows IEの無視できない数のバージョンで、和文フォント部分が serif のみだと韓国漢字で表示されてしまう。（表示のバグ。字義自体が変わってしまう可能性もあり重大な問題）
  2. 1の改善のためには明朝体和文フォントの直接指定が必要である。また、ゴシック体なら問題は発生しない。（このため「暫定的に」ゴシック体が適用されました）
    1. 明朝体を選択した場合、WindowsであればMSP明があるはずである。
    2. MSP明は見辛いフォントなので、MS Officeがインストールされていれば入っているフォントをMSP明の前に入れるべきである。
    3. Windows以外の環境、たとえばOS Xなどではより良いフォントがあるのに、WinIE対応の副作用で妙なフォントが表示されることになる。可能な限り、環境に適したフォントをOfficeフォントより前に入れるべきである。
  3. 財団の方針として「全世界版で見栄え（フォント）をできるだけ統一したい」「節が節だと分かりやすいようにフォントを serif に変えた」というのがあり、これは充分納得できる理由である。（これに納得できないという意見は出ていなかったと思います）
  4. 財団が全世界版で統一したフォントの中に、一般の日本人には馴染みが薄いオールドスタイルのフォントが含まれていた。（バグではない）
というのがあって、Geogia問題は実はとても優先順位が低いです。井戸端での議論でも全く Geogia が指示されていないということもありませんでした。ただ、これに反対する意見が多数出ていたことも事実であり、この優先順位の低い問題への反対のために、より優先順位の高い「全世界版での見栄えの統一」を阻害することは宜しくないと思います。まず Geogia を外すことは、やむを得ない抵抗として妥協すべきと思います。
なお井戸端でも言ったように最終的にはガジェット化すべきと思いますが、とりあえず「暫定対処」ということで Vector.css を変更しましょう。--Starchild1884（会話） 2014年4月25日 (金) 22:12 (UTC)[返信]
  • 賛成 あくまでも「応急処置」だったのですから「応急処置の範囲」を「バグ回避のみに絞る」ことに賛成です。「バグ回避」以外の部分については、変更維持を望む人が改めて提起してjawp全体での賛否を問うべきでしたが、そのような動きがないならば、いったんデフォルトに戻すべきです（もし「Gerogiaフォント」について「大々的にコミュニティの意見集約」を提起すると手を挙げる方がおられるなら、Geogiaを例外扱いすることにも反対はしませんが）。--miya（会話） 2014年4月25日 (金) 23:59 (UTC)[返信]
  • コメント Georgia を除いた上で検討をすすめるのはよいでしょう。しかしながら、Starchild1884さんの「Geogia問題は実はとても優先順位が低いです」との発言の根拠はなんでしょうか？ウィキペディアン以外の利用者の側に立った視点が欠如していると言わざるを得ません。「財団の方針」というさももっともらしい言葉を使っていらっしゃいますが、mw:Talk:Typography refreshの状況をご確認いただけているでしょうか？Geogia問題は日本だけの話ではありません。まして日本では、「オールドスタイル数字はオシャレだけど和文との相性が良くない」というのがWebデザイナーの定説になっていると思います。「暫定対処」として性急に変更する必要があるとは思いません。MediaWikiの状況を見据えつつ、「本格的な修正」を検討すべきと考えます。--Wolf359borg（会話） 2014年4月26日 (土) 00:27 (UTC)[返信]
    コメント 優先順位が低いのは、韓国漢字問題はバグなのに対して、Geogiaフォント問題はデザイン上の意見の相違であってバグではないからです。そして先日行われた「応急措置」は「バグ対応」でした。問題を明確にしないまま「一刻も早く対処を」だけ連呼されて有耶無耶になった感もありますが、基本的に先日行われたのは「Georgiaだと見辛いという意見への対応」ではありません（他問題への対処のついでに変わっただけ）。Cpro氏も仰っているとおり、まず問題を切り分けてください。--Starchild1884（会話） 2014年4月26日 (土) 21:38 (UTC)[返信]
  • 反対 現状では反対です。1.「デフォルト記述のCSSの意図」（見出しserif、本文sans-serif）はアルファベットのみなら十分に理解できるのですが、日本語の文書においてこれはちと違和感があります。逆の見出しsans-serif、本文serifならまだ許容範囲ですが。2.Georgiaは論外。3.Win7＋MS Officeという相当数のユーザが該当するであろう環境では、改定案を適用した結果として見出しHGP明朝B、本文メイリオあるいはMSPゴとなるわけですが、この組み合わせであってもMSP明よりはマシなものの見栄えはかなり悪いです。汎用のserifだけにするなら反対はしませんが、特定フォントの指定をするのであれば十分な議論が必要と考えます。--Claw of Slime（会話） 2014年4月26日 (土) 01:10 (UTC)[返信]
    コメント 1. 紙に印刷されたもの（あるいはpdfなど）であればともかく、PCやタブレットのディスプレイでの表示ではそれほど節ゴシック／本文明朝に拘る必要はないでしょう。紙で読む際に節ゴシック／本文明朝が良いのであれば、Print.cssを編集する方法があります。 3.「汎用のserifだけだとIEで問題が起こる」ので、IEを見捨てるのでないかぎりフォント指定は止むを得ません。少なくともログインユーザに関しては、ガジェット化＋ガジェット無効にすることで上書きCSSを使わない（自分のブラウザのデフォルト明朝体で表示される）ようにできます。また、「徒に時間をかける」ことは「十分な議論」と必ずしも同義ではありません。現在出されている明朝フォントは、井戸端での議論で提案されたものです。--Starchild1884（会話） 2014年4月26日 (土) 21:38 (UTC)[返信]
  • コメント もしかしてお忘れになっていると困りますので一点確認しておきます。Vectorスキンは標準スキンですのでその変更はウイキペディア登録利用者以外の全ての閲覧利用者にも適用されます。そしてその人々の大多数は自分でスタイルシートをいじって対処する術もなく、ましてここでこのような議論が行われていることも知りません。問題を切り分けるのがスマートなやり方だから、というだけでそれらの人にオールドスタイル数字と明朝の和文が混在した見出しを読むことを共用するのは、ウィキペディアンの傲慢というものです。どうか、そういう配慮を忘れないで下さい。--Wolf359borg（会話） 2014年4月27日 (日) 01:41 (UTC)[返信]

コメント もし現行の対応内容が必要最小限の措置でないと批判されるのであれば、詳細に個々のフォントを選り好みして指定しているその提案内容はなおのこと「IEのバグ回避のみに絞り込んだCSS」ではないですし、現時点で特に緊急性のない提案内容ですから、幅広い合意形成のプロセスをあえて避ける理由はないと思います。もし仮に、今後新たにバグ対応のみに限定したCSS（"Linux Libertine", Georgia, Times, "MSP明朝", serif;）を提案されたとしても、そもそもWMF側の意向としてネイティブのスタイル指定を無理に使って欲しいというアナウンスは特にないと思いますので、わざわざそのようなものをあえて採用する理由は無いでしょう。むしろ、「問題があればローカルCSSで対応して」[3]とか、「日本語用のカスタマイズが必要であれば言ってくれればMWのスタイルシートに組み込むよ」[4]といったアナウンスを頂いているぐらいなので。

私自身はどちらかといえば現状支持なので、このまま新たな合意形成方法の提案が無いままひとしきり賛成・反対を言い合った状態で議論停止したとしてもユーザー側に具体的な不利益が及ぶとは考えていませんし心配もしていませんが、いずれかの時点できちんと日本語版コミュニティの総意を汲んだ合意形成をすべきということは、私も必要だと考えています。そのためには、

  • コミュニティによる決定方法（予想される選択肢の性質上、候補全体への投票後に決選投票を行う２段階の方式が公平で良いと思いますが、その手順や期間などについて合意を得る必要がある）
  • その合意形成の選択肢となる候補の選定方法（選択肢が多すぎても選びにくいので候補の絞り込み作業はおそらく必要）
  • コミュニティとして結論を得た際の取り扱い方法（現状どおり日本語版のローカルCSSとして対応するか、日本語ユーザー用の仕様としてMediaWikiのデフォルトに加えてもらうか）
  • コミュニティへの広範な周知（上記の検討内容についての周知、その後、概要が決まった段階で実施についての具体的な周知）

といったことをきちんと詰めた上で、十分な周知・検討の上でやっていく必要があると思います。私の個人的な意見としては、MW側の議論の方をもう少し見極めてからの方が良いと思っていますが、現時点で速やかにその作業に着手したいというご意見の方がいらっしゃるのなら、上記のような手順の整理をきちんと行っていただいた上で、コミュニティ内での十分な周知のもと、改めて具体的な提案をいただきたいと思います。--ディー・エム（会話） 2014年4月27日 (日) 04:10 (UTC)[返信]

賛成 暫定措置として賛成します。日本語全体のデフォルトフォントについては恒久的なものとして結果を出すべくもっと丁寧に詰めるべきですし、開発側が言うようにローカル対応で済ませずMWデフォルトに組み込むべきです。デフォルトにしなければ仕様が変わる度に微修正を加える羽目になると思います。--Marine-Bluetalk✿contribs✿mail 2014年4月27日 (日) 04:48 (UTC)[返信]
  • 反対 現状ではかなり強く反対です。「Wikipedia:井戸端/subj/現在のWikipediaのフォント」の議論をざっと見る限り、「バグに限らず、変更後のフォント表示には問題がある」という意見が多いようです。無理に元に戻すことは、多くのユーザーの反発を招き、かえって結論が遅れる可能性があります。それよりも、「デフォルト記述のCSSの意図を最大限尊重したcss」を別途準備し、有志がそれを使用・議論して改善案を作り、それをメディアウィキ側に提案する（mw:Talk:Typography refreshなど）、という流れが無理が無いように思います。--Freetrashbox（会話） 2014年4月27日 (日) 07:37 (UTC)[返信]
    • コメント 「有志がそれを使用・議論して改善案を作り～」に関して。私自身が適用していたわけではなくて伝聞であり、一部誤っている可能性があることをあらかじめ言っておきますが……どうも「ベータ版」を適用していた場合、ウィキメディアプロジェクト全体に明朝体が適用される前からテストとして明朝体が適用されていたらしいのです。ベータテスターの中にバグのあるブラウザを使っている人が居なかったか、居ても大した問題ではないと報告しなかったか、何にせよそれは不幸なことでしたが、「明朝体である」ことに対して強く異議を唱えた人が居なかったからこそウィキメディアプロジェクト全体に適用されたと考えるのが自然であり、財団による変更は「有志による意見の反映」だと考えることもできます。井戸端でも言いましたが、明朝体への変更は慣れの問題や変更行為そのものへのアレルギー以上のものでない可能性を捨て切れず、そういう意味では有志のみであれこれ話すよりも一旦（もちろんバグの無い形で）変更を適用した方が話がまとまりやすいかもしれません。有志で話し合って決めても「自分は議論を知らなかったので反対」のような理不尽な反対が出るおそれもあります。変更されたものに異論があるならば、井戸端であったようにどこかに書き込むでしょう（少なくともGeorgiaフォントと和文のアンバランスなどは充分納得できる意見でした）。--Starchild1884（会話） 2014年4月27日 (日) 21:08 (UTC)[返信]
      • 言葉足らずでしたが、有志案をそのままメディアウィキ側に提案するということではなく、有志案がある程度まとまればまずウィキペディア日本語版のコミュニティに採用提案し、合意形成した後にメディアウィキ側に提案する、という意味です。◆「変更を適用した方が話がまとまりやすいかもしれません」というのは、理由がよく分かりませんでした。実際の変更に勝る告知は無い、といったことでしょうか？告知が目的であれば、例えば1日だけ変更して元に戻す、といった手法も取れそうに思いますが、いかがでしょうか？--Freetrashbox（会話） 2014年4月30日 (水) 13:07 (UTC)[返信]
        コメント 「実際の変更に勝る告知は無い」はその通りだと思います。実際、明朝体に変わった直後は井戸端への書き込みが沢山ありましたが、暫定処置が施されてからはぱたりと止まってしまいました。あのまま書き込みが続いていれば、「明朝体が見辛いと言うが具体的にどういう理由で？」などが詰められたかもしれませんでしたので残念です（韓国漢字問題対応は止むを得ませんでしたが）。ただ、自分としましては、ゴシック体へ戻すことを「元に戻す」とは考えていないのですよね、賛否両論が発生して上書きされたとはいえ今のデフォルトは明朝体なので。バグさえなかったならば明朝体への変更理由も充分納得できるものでしたし。--Starchild1884（会話） 2014年4月30日 (水) 23:04 (UTC)[返信]
  • 反対 バグ回避よりもフォントの問題のほうが、批判の声も影響範囲も大きかった訳ですし、あたかも「バグ回避のみが必要だった」という前提を捏造するような真似は容認しがたいです。というか「それまでの快適な閲覧を阻害した」訳ですから、「バグではない」なんてのは正しくないですね。最低でも、GeorgiaとMSP明朝の排除は必要でしょうけど、提案者はGeorgiaフォントをあくまで残すことに拘っているあたり、極めて悪質です。デフォルトのCSSを尊重する理由など存在しませんし、そもそも日本語や漢字文化圏の文化を理解せず考慮せずに作られたものを尊重するというのがナンセンスです。言語や文字の文化を理解せずに共通化という発想は乱暴、幼稚でしかなく、多言語プロジェクトとして発展してきたウィキペディアの歴史に対する冒涜であり、他言語・他文字を使う文化圏への攻撃です。何がバグかって、Typography refresh とかいう思いつき・計画自体がプロジェクトに発生したバグですよ。--氷鷺（会話） 2014年4月27日 (日) 13:15 (UTC)[返信]
    • コメント Cpro氏の原案は別として、私は最初からGeorgiaは外そうと言ってるんですが、読んでますか？ また、この議論の意味を理解していれば「MSP明朝の排除は必要」などという発言は出ないと思うのですが、趣旨はきちんと理解されているでしょうか。
      さて、4月27日の氷鷺氏の投稿で、氷鷺氏の手口といいますか、何故「一刻も早く！」と連呼するだけで具体的な理由を書かなかったのか、Frozen-mikan氏が質問してさえ「今そういった話をすべきではない」などと流したのか、誰の目にも明らかになったと思います。私は、こういった手口によって行なわれたことが、ウィキペディアのコミュニティの中でなし崩し的に是とされてしまうことは避けるべきだと考えます。現状維持で合意されるならばそれはそれで尊重しますが、それは氷鷺氏の行なったような手口で成されるものではないはずです。--Starchild1884（会話） 2014年4月27日 (日) 21:15 (UTC)[返信]
  • コメント 例えば、暫定対応をTypography_refreshが入る以前のjawpの状態と同じになるように修正する、というご提案であれば賛成できます。ただそれも今それをやらなければいけない必要性は無いと思います。いったんTypography refreshに準拠してIEバグ対応だけにすべきと主張される方々のご意見はいかがなものかと思います。
変更直後では単なる慣れの問題と実際のデザインの悪さとの区別が難しい状態
Geogia問題は実はとても優先順位が低いです。
いいえ断じて違います。Gerogiaのオールドスタイル数字は欧文文章の小文字に調和するように設計された字体です。これが和文の字体と調和しないのは明白であり常識といっていいです。単なる慣れという言葉が出たのは、実はあまりよく見ていなかったか、美的感覚に致命的な欠陥があるかのどちらかでしょう。前者であることを祈ります。
IE対応でフォント個別指定を追加するのはバグ対応です。Georgiaフォントを除去するのはUIの再変更です。
私には馴染みがありますが、これはエンジニアの思考・論理に似てますね。ソースコードのリファクタリングとかそんな感じです。「切り分ける」ためだけに大きな影響を与えるcssをいじるというのは、その程度のつまらない理由です。しかしながら、そんなウィキペディアンの事情など知ったことではない一般の方々＝ユーザー側の視点が欠如しています。IEバグの件が判明したことで緊急度や説得力が増しましたが、そもそもの率直な声は「急にフォントが見づらくなった。早く元に戻してほしい」です。これは井戸端もそれで始まっていますし、ネット上でもそういう意見・苦情がいくつも見られました。Yahoo!知恵袋ではこんな感じ[5][6][7]ですし、某匿名掲示板もあの時点で検索すると結構引っかかりました（そりゃもう、散々な言われようでした）。そういった声を無視し、IEバグ回避が目的だったのだからいったんそれだけに絞る、というのはウィキペディアンの横暴・傲慢です。
財団の方針として「全世界版で見栄え（フォント）をできるだけ統一したい」「節が節だと分かりやすいようにフォントを serif に変えた」というのがあり、これは充分納得できる理由である。（これに納得できないという意見は出ていなかったと思います）
まずTypography_refreshを「財団の方針」と言うのは幻想です。単なるソフトウェアの変更プロジェクトに過ぎません。考えが足りなかったり、間違っていることもあるでしょう（mw:Talk:Typography refreshやmeta:User talk:Steven (WMF)#Typography changesを読んでみてください）。jawpが黙ってこれに従う理由も義務もありません。そんなことなら各言語版に独立したコミュニティなど不要でしょう。そもそも、「早く元に戻してほしい」という声を無視しておいて「納得できないという意見は出ていなかった」はあんまりだと思います。
問題を明確にしないまま「一刻も早く対処を」だけ連呼されて有耶無耶
私の感覚では「一刻も早く対処を」だったのが、IEバグ問題が注目されてバグ対応ということで有耶無耶、だと思います。
暫定措置として賛成します。日本語全体のデフォルトフォントについては恒久的なものとして結果を出すべくもっと丁寧に詰めるべきですし、
うーん…丁寧に詰めるべきというのは同感ですけど、それなら現在の応急処置を今いじる必要はないはずですよね？
これが、モノブックスキンとかなら、ここまでしつこくは言いません。ベクタースキンは規定のスキンなので、登録利用者以外には選択の余地なく適用されるのだということを忘れないようお願いいたします。--Wolf359borg（会話） 2014年4月27日 (日) 22:29 (UTC)[返信]
コメント ええとですね。「財団の方針には従わなくてもよい」というのは「財団の方針に従ってはいけない」ということではないですよ。変更理由が合理的なので財団の方針に強いて反対する理由はない、ゴシックにしようという日本語版ウィキペディアの一部の方の理由に（明朝体に戻すことと比べれば）合理的な理由がない、というだけで。--Starchild1884（会話） 2014年5月8日 (木) 21:39 (UTC)[返信]

バグ回避のみに絞った対処案：JSを用いたUA判別によるCSS振り分け[編集]

JavaScriptを用いてIE10以前（「韓国漢字問題」の発生するブラウザ。他にもあれば他のも）を判別し、判別されたブラウザにのみ「バグ回避のためのCSS」を読みこませる……という処理は、現在のjawiki/MediaWikiで可能でしょうか。

バグ回避のみに絞った対処を考えた場合、CSSのみの変更ですと問題ない環境にまでMSP明朝などを押しつけることになることが大きな問題点でしたが、これが可能であればその点は解決します。実際に適用した場合「JSの読み込み遅延」などから実用に耐えない可能性もありますが、ひとまず「技術的に可能か」だけ、分かる方にお聞きしたいです。（私はJSの読み書きは全くできません。MWの技術的なことも分かりません）--Starchild1884（会話） 2014年5月18日 (日) 22:02 (UTC)[返信]

可能です。サンプルを書きましたので各位お試しください。（ソース: MediaWiki:Test/findOldIE.js / 動作確認用リンク。IE10以前だとサイドバー背景がピンク色になりメッセージ表示します。IE11以降か非IEブラウザだとサイドバー背景が緑色になります）
このサンプルではbody要素へのstyle指定ですが、MW名前空間のCSSページを外部CSSとして動的に読み込んだりすることもたぶんできると思います。--cpro（会話） 2014年5月20日 (火) 01:16 (UTC)[返信]
コメント ありがとございます。存外、シンプルなコードで済むのですね。可能としてももっと複雑になるのかと思っていました。（自分のIEバージョンは11なのですが、このブラウザ標準搭載の「開発者ツール」機能で10以前での表示を確認しました）--Starchild1884（会話） 2014年5月20日 (火) 22:15 (UTC)[返信]
コメント スクリプトはwithJSで適用されていますが、実際に使うとなった場合はデフォルトで呼び出されるガジェットとして実装することになるのでしょうか。JavaScriptは久しぶりなのですが自分なりに少し試してみています。外部スタイルシートを動的に読み込むのがまだ出来ていないのですが、どういったコードになるでしょうか。あと気になるのは、全環境で動くスクリプトだと互換性や安全性などにも十分配慮が必要になってくるかと思いました。--Wolf359borg（会話） 2014年5月21日 (水) 11:12 (UTC) 下記のようなコードかなあとやっていたのですが、[返信]
$(function() {
    var ua = window.navigator.userAgent.toLowerCase();
    var isOldIE = ua.indexOf('msie') >= 0; //IE11以降はMSIEの文字は入らない
    var hrefOldIE = '/HeadingOldIE.css';
    var hrefOther = '/HeadingDefault.css';
    $('head').append('<link>');
    css = $("head").children(":last");
    css.attr({rel: 'stylesheet', type: 'text/css'});
    if(isOldIE) {
        css.attr('href', hrefOldIE);
    } else {
        css.attr('href', hrefOther)
    }
});
Wikiページに書いたものをCSSファイルのURLとして渡すにはMediaWikiの仕組みを知らないといけないことに気づきました。それに実装追加場所はたぶんMediaWiki:Common.jsですよね。そこに書いてあるwithCSSの仕組み
    importStylesheet(extraCSS)
を使うんだろうなと見当をつけたところでMediaWiki知らない私はここでストップです。--Wolf359borg（会話） 2014年5月21日 (水) 22:45 (UTC)[返信]
コメント 実際にやってみたらあっさりできました。ついでなので、IE6以前とかMacも判別させる処理を作ってみました。スクリプトはこちらで、フォント指定はIE6用、IE7-IE10用、Mac用、その他Windows用です。Windows 7の環境しかないので実際のフォント表示については確認していませんが、User-Agentを切り替えてデバッガで見た限りでは期待通り動作しているようです。それでフォントの切り替え動作なのですが、利用者カスタムJSの処理タイミングのせいなのか、いったんゴシックで表示されてから明朝に切り替わるのがはっきり目視できるのが気になりました。しかるべき場所に実装してsans-serif指定を外して改善されるのならばよいですが、変わりがないとするとちょっと実用に疑問符が付きそうです。--Wolf359borg（会話） 2014年5月23日 (金) 22:55 (UTC) サンプルスクリプトをデバッグ出力コメントアウトした版にリンク修正。--Wolf359borg（会話） 2014年5月24日 (土) 01:06 (UTC)[返信]
コメント 動作についてのみ。まず、切り替え速度について。$(function(){/* 本体 */}) は、jQueryのDOM構築待ち関数ですが、本件ではDOMの構築を待つ必要はないため、使用しなくても構わないはずです。また、他のファイルを読み込む時間は mw.util.addCSS() を使い、CSSデータを同じファイルに入れることで省略可能と思います。次に、利用者環境の判定について。今のMediaWikiでは $.client.profile() というものもあります。--Frozen-mikan（会話） 2014年5月24日 (土) 04:03 (UTC)[返信]
コメント アドバイスありがとうございます。やっぱり結構忘れちゃってるものですね。とりあえずDOM構築待ち関数から処理を出したのを試してみましたがあまり変わりませんでした。mw.util.addCSS() はあとで試してみようと思います。ここからが本題になるのですが、色々試してるうちにjawpとしてはどこまでのブラウザをサポートすべきかという疑問が生じてきました。実環境は持ってなくてIETesterで確認しただけなのですが、IE5.5環境ですと利用者JSで mw.loder.load() や importScript() を使っただけでエラーのため判別処理前で停止してしまい、あげくにはMediaWiki:Common.jsの設定も反映されなくなりました。IE6環境ではエラーで停止することもなく判定処理も可能でしたが、$.client.profile() は jQueryを使っているのでリスキーだと思います。また古いブラウザを仕方なく使っている人はセキュリティ上、JavaScriptを禁止にしてる可能性が高いかと。もちろん最初からJavaScriptが動かない環境もあります。フェイルセーフの観点から、JavaScriptによる判定を表示品質や利便性向上のために使うのはアリですが、バグのある環境を救うために使うのは方法として間違っているという気がします。--Wolf359borg（会話） 2014年5月25日 (日) 02:12 (UTC)[返信]
コメント 気になったので更に覗かせてもらいました。vector.js から switch font.js を読み込んで、そこで各種CSSファイルを読み込む形になっている点が気になりました。読み込みが2回あり、そのたびに、読み込み列の最後に並ぶので、遅くなる要因になっているのではないか、と思います。ブラウザのキャッシュが使えるなら別ですが、日本からの通信遅延もあり、サーバーへの問い合わせで100-500ミリ秒程かかるでしょうし、読み込み数制限で待たされることもあります。--Frozen-mikan（会話） 2014年5月25日 (日) 04:36 (UTC)[返信]
コメント $.client.profile()を使って判定し mw.util.addCSS()でスクリプト中にハードコーディングしたスタイルを追加するようにしてみました。不要なファイル読み込みを減らすために vector.js に処理を直に書いたところ[8]、速度の問題は改善されたようです。IE6の処理を条件コンパイルコメントで書こうとしたのですが、どうもMediaWiki通すと？おかしくなるみたいなので諦めました。--Wolf359borg（会話） 2014年5月25日 (日) 06:05 (UTC)[返信]
追記です。上では改善されたようですと書いたのですが、通常のリロードでは気にならなくなったという意味合いでして、たまにちらっとゴシックが見えてしまう事がありました。速度に関して、井戸端ページの表示時間をGoogle Chromeのデベロッパーツールでざっと計測（20回平均）して比較してみました。5つのケースについて計測した結果は下記となりました。()内は分散値です。
  1. フォント切り替え処理を全く入れてない状態　…　2.87秒 (0.08)
  2. DOM構築待ち関数でimportStylesheet()使用　…　3.25秒 (0.39)
  3. switch font.js読み込んでimportStylesheet()使用　…　3.09秒 (0.03)
  4. switch font.js読み込んでmw.util.addCSS()使用　…　2.75秒 (0.06)
  5. switch font.js読み込まずにmw.util.addCSS()使用　…　2.78秒 (0.06)
ケース4がゴシックがはっきり見えてしまうのに所要時間が一番短くなっており、全体の時間だけで比較はできないようです。やっぱり処理はMediaWiki:Vector.js（上ではここで議論が行われていることに引っ張られてMediaWiki:Common.jsと書いてしまいましたが）とかに入れてみないと評価できない気がします。とは言うものの、ほとんどの利用者に影響するインターフェースに手を入れてのテストは慎重に行うべきでしょう。--Wolf359borg（会話） 2014年5月26日 (月) 22:12 (UTC)[返信]

情報 CssUserAgent という html 要素にUA名のclassを仕込むライブラリ(MITライセンス)があるのですが、これは使えないのでしょうか。このライブラリだとcssを読み分ける必要がなくなります[9][10]。また、cssでIEのみ表示を変更する方法もあるようです[11]。--Yhiroyuki（会話） 2014年5月27日 (火) 14:13 (UTC)[返信]

コメント CssUserAgentを使えるかどうかはさておき、html要素に環境判別のclassを追加してスタイルシート側で対処する手法を試してみました（スクリプト、スタイルシート）。外部スタイルシートに記述することによりメンテナンス性が上がるのがメリットですが、セレクタを必要なだけ並べなくてはならないため複雑になってパフォーマンスが落ちてしまうようです。抜けがあったりどういう解釈されるかわからない不安さもありますね。--Wolf359borg（会話） 2014年5月27日 (火) 22:58 (UTC)[返信]
古いブラウザの判定も考慮して修正してみました。ライブラリには依存しない最低限のスクリプト[12]とし、デフォルトのフォント指定をsans-serif、その後にモダンブラウザ判定で付加したクラスの孫指定でフォント指定を上書きするCSSファイル[13]にしてみました。旧IE用設定の方をクラス指定にしなかったのは、IE6だとどうもクラスの孫指定のセレクタを認識しないらしく、またJavaScriptを無効にしてる場合にデフォルト設定が使用されるようにとの配慮からです。--Wolf359borg（会話） 2014年5月31日 (土) 05:25 (UTC)[返信]

提案 このブラウザ判別を利用して、IE10以前にはバグ回避CSS（当面は font-family: sans-serif で。個別指定の選定には極めて時間がかかるのはご覧の通りなので）を読みこませ、それ以外は素のまま（elseを書かない、あるいはブレイク（に相当するもの）のみにする）という処理を行なうことを提案します。特定ブラウザにのみ適用させたいバグ対応としては、これが最善なのではないかと思います。--Starchild1884（会話） 2014年5月20日 (火) 22:15 (UTC)[返信]

  • コメント 反対 サンプルコード1つを見ただけで今までの議論の問題を解決せずに新たな正式提案を出すというのはちょっと気が早すぎるのではないでしょうか。また、すでに申し上げている通り、IEバグのみが問題で本来そのための対処であったという認識は正しくありません。現状でとりあえず問題がないのに、検討を脇においてまず対処を急ごうとされるのか理解できません。十分納得できる理由があれば賛成できるかもしれませんので、急ぐ理由を教えていただけますでしょうか。なお、ブラウザ環境ごとに異なるスタイルを適用する手法はIEバグに限らず有用だと思いますでの、技術的な検討は進めていくべきかと思います。--Wolf359borg（会話） 2014年5月21日 (水) 10:57 (UTC) 反対票とします。--Wolf359borg（会話） 2014年5月22日 (木) 09:42 (UTC)[返信]
  • 賛成 なおIEバグのみが問題で本来そのための対処であった、と認識しています。--Ks aka 98（会話） 2014年5月22日 (木) 05:54 (UTC)[返信]
  • コメント 上で技術的な検討をしていますのでそちらもご覧ください。--Wolf359borg（会話） 2014年5月25日 (日) 02:17 (UTC)[返信]
  • コメント Starchild1884さんの意見募集の告知[14]において「技術的にはかなり簡単に対処可能であることが確認されています。」とありましたが、上の技術的な検討の状況をごらんになれば性急すぎるご提案であったことがお分かりいただけるかと思います。cproさんはUA判別の簡単なサンプルを示されて希望的見解をおっしゃっただけで、お墨付きを与えるような意図までは無かったものと思われます。技術的なことがよくわからない（これはプログラムスキルのことではありません）のであれば急いで正式に提案をなさらずともよろしいでしょう。魅力的なアイデアをつぶやいていただければ、それに興味を持った人が検討を進めて形にしてくれるはずです。あとこれは余談ですが、発端となった「フォント指定の復帰提案」以降、関連議論がこのページで行われていますが、ベクタースキンのフォント設定に関することですので、MediaWiki‐ノート:Common.css は場所として適切なのだろうかと疑問に思う次第です。しかも本節はもはやCSSだけの話ではなくなっていますし。--Wolf359borg（会話） 2014年5月28日 (水) 09:52 (UTC)[返信]


Wikipedia:お知らせ#記事・セクション見出しのフォント変更についての意見募集 (2) 再以降のコメント[編集]
  • コメント バグ回避のみに絞った対処案にあらためて賛成：このような変更を加えていない姉妹プロジェクトのページ、wikt:ja:Wiktionary:編集室, b:ja:Wikibooks:談話室, q:ja:Wikiquote:井戸端, s:ja:Wikisource:井戸端などをWikipedia:井戸端と比べてみましたが、私のブラウザ（Firefox, Chrome, IE11）ではバグらしきものも見当たらず、フォントも別におかしいとは思わなかった（ゴシックがいいか明朝がいいかというのは、単に慣れや好みの問題化と思われます）ので、明白なバグがおきるブラウザ以外はMediaWikiのデフォルトに戻してほしいですーその上で、やはり変更が必要という意見が出たら、今度はちゃんと1週間以上議論してから変更してください。ところで、以前言われていた「韓国語字体で表示」されるなどの「バグ」はまだ残っているのでしょうか？コモンズではこれまで中国語っぽい字体で表示されることがしばしばありましたが、しばらく待てばバグ修正されたのか通常の日本語字体に戻りました。◆"Georgiaフォント"の話は、どこがどう問題なのか、（私のように）フォントに詳しくない利用者にも明確にわかる対比を明示してください。（初めて見る人には論点がわかりにくいと思いますので、井戸端で仕切りなおしたほうがいいかもしれません）--miya（会話） 2014年7月2日 (水) 07:44 (UTC)typo訂正しました。--miya（会話） 2014年7月3日 (木) 05:30 (UTC)[返信]
  • コメント まず、提案者のStarchild1884さんへはお伝えしたのですけれど、実は「技術的にはかなり簡単に対処可能であることが確認」という認識には齟齬があります。そしてベクタースキンについての事なのでここは議論場所に適切ではないように思います。miyaさんがおっしゃるように井戸端での仕切り直しが良いかもしれません。
さて、バグに関するご質問が出ましたのでmw:Typography_refreshによって日本語環境で起こった問題についてですけど、
(1) 欧文で最適化されたフォント指定と和文とのミスマッチの問題。特にWindows環境での「Gerogia」と「ＭＳ Ｐ明朝」の組み合わせ。
(2) Internet Explorer 10以前のバージョンにおいてserif指定すると和文が「Batang」（韓国字体）優先で表示される問題。
大きくこの2つに分けられると思います。好みや慣れの違いもあるでしょうが環境依存の問題でもあり、なかなか問題意識が共有できていないようです。(1)ですと「Linux Libertine」をインストールしていると「Gerogia」のようなオールドスタイル数字はありませんし、OS X環境やWindows環境でもブラウザのserifフォントを設定していれば、「ＭＳ Ｐ明朝」より高品質なフォントが使用されて違和感が少ないでしょう。SafariやSleipnirは独特のフォントレンダリングを行いますし、WindowsにMacTypeなどを入れているかもしれません。(2)では最新のOS環境では改善済みですので問題に気づくこともありません。また「Batang」フォントを削除しちゃってる人がいるかもしれません。などという具合です。バグ回避といった場合は(2)だけを指しています。私は(1)も無視できない問題だと思っています。少なくともウィキペディアン以外の一般閲覧者がウィキの文字がおかしいと騒ぎ出したのは(1)の問題を含んでいました。「ＭＳ Ｐ明朝」嫌いの人は相当数いるようですので。
次に個々の問題について簡単に説明いたします。
「Gerogia」のオールドスタイル数字
オールドスタイル数字は辞書のページ番号、年号の表記なんかで見かけたりしますが、高さが揃っていないあれです。（参考：[15][16][17]）基本的に欧文本文の小文字に調和するように設計された字体なのですが、欧文でいうと大文字だらけの和文の中にこの数字が混じっていると相性は最悪です。標準フォントで合わせるならライニング数字の「Times New Roman」一択です。
Windows環境での標準serifフォントの「ＭＳ Ｐ明朝」
節見出し程度の大きさで液晶画面に表示させた「ＭＳ Ｐ明朝」は欧文の美しいフォントと比べて格段に見劣りします。カスレやガタツキが目につき、基本細身なのでボリュームのある「Gerogia」とアンバランスです。あまり良い例ではないですが（数字が入ったのを選んだだけ）国鉄キハ391系気動車を「Gerogia」と「ＭＳ Ｐ明朝」で表示するとこうなります。
IEの旧バージョンで韓国字体「Batang」で表示される問題
これはマイクロソフトのコミュニティサイトに投稿された質問記事がわかりやすいです。IE11では修正されていますが、それより古いバージョンにおいてfont-family指定がserifの場合、韓国字体である「Batang」が優先的に使用されます。質問サイトではIE8-10となっていますが、実際はIE5.5おそらくもっと前からのバグです。問題再現のテストページをIETesterというソフトで旧バージョンをシミュレートして表示させてみました。IE5.5、IE7、IE9です。一番上がserifで一番下がBatangです。一部の漢字がBatangと同じ字体になり、円記号がウォン記号になっているのがわかるかと思います。
問題点としては以上になりますが、いかがでしょうか。
それで私としては、いったんTypography_refreshに戻してから議論（もちろん暫定対処時の経緯を思えばわからなくもないのですが）には反対で、議論してから対処すべきという立場を取っています。なぜなら、規定スキンのベクターの設定の問題だからです。現状のローカル設定を取り消してしまうと、ウィキペディアをただ閲覧しているだけの一般の人たちの多くは議論することもできず、対処法もわからずに、また「キモチワルイ」フォントのウィキを見ることを強要されてしまうでしょう。他のスキンであれば気にしないで済むのですけれどね。--Wolf359borg（会話） 2014年7月2日 (水) 22:52 (UTC)[返信]
  • コメント 丁寧なご説明ありがとうございます。逐次、感想を述べさせていただきます。
IEの旧バージョンで韓国字体「Batang」で表示される問題
問題再現のテストページでの例示をありがとうございます。たしかにこれは困るでしょう。これへの対応に反対している人はいないようですね。
Windows環境でのGeorgiaと「ＭＳ Ｐ明朝」の組み合わせ
同じ文字列（国鉄キハ391系気動車）をコモンズとjawpの利用者Sandboxに投稿して比べてみました。一部の数字（3と9）が下にでていることを「最悪」とおっしゃっておられるわけでしょうか？　やはり好みの問題としか。少なくとも正しく読めるし（それが一番大切）、いったんTypography_refreshに戻すことを全力で反対しなくてはいけないほど「最悪」とは思いません。戻した上で（または現段階でBatang問題と平行して）「Times New Roman」にすることを正式提案なさったら、おそらく反対はいたしませんが、理想的にはガジェット化してそれぞれの環境にあった表示方法を選択できるようにすることでしょう（Batang問題がなければ、早急対処ではなくガジェット化で解決が図られたであろうと思っています）。
井戸端での仕切りなおしの際には、ガジェット化という選択肢も含めていただければ幸いです。--miya（会話） 2014年7月3日 (木) 05:30 (UTC)[返信]
感想ありがとうございます。韓国字体問題はご理解いただけたようで良かったです。オールドスタイル数字に関しては参考サイトもご覧ください。国鉄キハ391系気動車は最適な例として紹介したわけではありません。むしろ見て欲しかったのは節見出しの「ＭＳ Ｐ明朝」の方でして。オールドスタイル数字は欧文のエックスハイト（小文字xの高さ）を基準にデザインされています。0、1、2はエックスハイト、3、4、5、7、9は下に飛び出し、6、8は上に飛び出し（と言っても和文の高さに届きません）ています。ベースライン揃えなので和文と中心線はずれ、上も下もガタガタになります。組版やWEBデザインをかじった人なら和欧混植の難しさや和文にオールドスタイル数字を混ぜるのが禁じ手（わざとやる事はあります）なのは常識と言ってよいでしょう。また、これは私見ですが「Gerogia」が第2候補になっているのは標準フォントの中でスクリーンフォントとして最適化された字体だからでしょう。第1候補の「Linux Libertine」がライニング数字であるように特にオールドスタイル数字を推奨しているというわけではなさそうです。日中韓でのGerogia問題はすでに報告済みでありMetaWikiは問題として認識しています。
正しく読めることが一番なのであれば現状の一律sans-serif指定が一番安全で間違いがないわけで、そもそも変える必要がないはずです。なぜいったんTypography refreshの状態に戻す必要があるのでしょう。これはStarchild1884さんにも質問したのですけれど、私が見落としている現状の問題点があって、それを早急に対処する必要があるのならおっしゃってください。もし、氷鷺さんの手続きに問題があったから白紙に戻すというだけの理由でしたら、そんなつまらないことのために無関係な一般の利用者にしわ寄せを一時的でも与えるようなことはやめてほしいと思います。そういう後ろ向きの提案でなく、Typography refreshの意図を汲んで jawpでのよりよいフォント指定を議論するのであれば喜んで協力いたします。
さて、ガジェット化の選択肢ですが、クライアント環境によりフォント指定を切り替える処理（くどいようですが韓国字体問題対処に限らずです）を導入するのなら、個人設定から指定できるガジェットにするのも良いかなとは私も思っています。各自でCSS周りをカスタマイズしている人にとってはサイト側の個別フォント指定は邪魔な押し付けにしかなりませんので、無効に出来る方がありがたいでしょう。ただし、MediaWiki:Vector.cssでの font-family: sans-serif; 指定は残してこれをデフォルトとし、切り替え処理でそれを上書きするようにする必要があります。まず安全確実な設定にし、それから必要に応じてフォントを切り替えるということです。JavaScriptやCSSの互換性に問題がある環境、JavaScriptを禁止している利用者も当然いますので、それらを切り捨てても良いというお墨付きがあるのでなければ、なるべくフェイルセーフな方向にすべきだからです。切り替え処理については私なりに試行錯誤して自分の環境で使用中です。興味があるなら利用者:Wolf359borg/vector.jsと利用者:Wolf359borg/vector.cssをご覧ください。転記して試しても構いません。これはWindowsとMacに切り替え、そして古いバージョンなどはそのままという動作にしてあります。Mac環境お持ちの方にはぜひ試してほしいです（私はWindows 7しかないので）。なお、利用者カスタムJSなのでロードタイミング上、再描画が気になる場合があります。これ以上はウィキ技術部の方に依頼してテストしてもらう必要がありますね。--Wolf359borg（会話） 2014年7月3日 (木) 12:50 (UTC) 脱字修正。--Wolf359borg（会話） 2014年7月4日 (金) 12:16 (UTC)[返信]
Wolf359borgさん、Wikipedia:ガジェット/提案#クライアント環境でフォント指定を切り替えるガジェットの提案と評価依頼（2014年7月5日～）のご提案ありがとうございました。また、Wikipedia:井戸端/subj/日本語版の記事・セクション見出しのフォント検討（ 2014年7月17日～）の提起もありがとうございました。井戸端にコメントする前に、こちらでいただいたコメントへにこちらでお返事を書かせていただきます◆(1)については、利用者:Wolf359borg/見出しフォント比較ページを見せていただきましたが、やはり「好みや慣れの違い」が大きく、変更直後の反発はあっても、時がたてば慣れて気にしなくなる可能性もあったのではないかと思っています（現にモバイルビューの見出しは「ＭＳ Ｐ明朝」のままのようですが、クレームは見当たらないようです）が、そもそもフォントに詳しくない素人の感想ですので、フォントに関する「常識」が共有できていないことはご容赦ください。◆"なぜいったんTypography refreshの状態に戻す必要があるのでしょう" について：（老婆心かもしれませんが）jawpがさらにガラパゴス化することへの懸念、のようなものです。「Typography refreshの状態」をjawp独自の設定で上書きし、MediaWikiのデフォルトから乖離する・・・今現在はまあ良いとして、将来、MediaWikiが改善されていく潮流から、jawpだけが取り残されてどんどんガラパゴス化がすすんでしまうのではないか、という懸念です。そのため何らかの方法で、MediaWikiデフォルトの状態でもjawpが使えるようにしておいてほしいと願ったのです。基本的に、Ks aka 98さんの 2014年5月7日 (水) 17:57 (UTC) のコメントに近い考えですが、とりあえずは、ガジェット化してコミュニティの皆さんにjawpローカル仕様とMediaWikiデフォルト仕様を比較可能な状態にしておいてもらえれば、将来、あきらかにMediaWikiデフォルトのほうが優れている状況になったとき、改めて検討できると思っています。--miya（会話） 2014年7月24日 (木) 07:12 (UTC)[返信]
返信 (miyaさん宛) コメントいただいたので私もこちらに。結局はそれぞれの好き嫌いに起因する感情的な問題に帰結してしまうのですが、利用者の満足度の観点からは見過ごせないことではあります。もし十分な告知がされていたら、あれほどの混乱にはならなかったでしょう。ＭＳ Ｐ明朝に関しては日本人特有の細かいところにうるさいという気質が影響してるかと。標準環境だとGeorgiaのでっぷりした書体との組み合わせというのも致命的でした。IEバグに関しても事前に検討する余裕があればＭＳ Ｐ明朝で統一するでもよかったわけです（原因を考えれば、sans-serifで問題が生じなかったのはたまたまとも言えます）。jawpがガラパゴス化することへの懸念はたしかにあります。長く活動されてきた方々はメタとの関係が良好とはいえなかった時期を経験されてきていると思いますので、特にそう思われるのでしょう。ただ、無条件に受け入れてしまうのもどうかなと思うのです。少なくとも4月の時点ではmw:Talk:Typography refreshにおいて、Gerogia抜きの提案とか、sans-serif系の提案とかあったわけですが、その後どうなったのやら…今開発中のmw:WinterというUIのTypography Refreshモジュール（Snowflakes）を見たら、がっつり
#content.typography h1, #content.typography h2, #content.typography h3, #content.typography h4 {
	font-family: Georgia, serif;
}
と書いてありました。あちらの方々のGerogia好きは相当なものらしいです。--Wolf359borg（会話） 2014年7月24日 (木) 10:08 (UTC)[返信]
「あれほどの混乱」・・・大部分のユーザーにとっては（私と同じように）「文句を言っている人たちがいるけど、いったい何が問題なんだろう？？？」というところだったのではないでしょうか。ともあれ、「jawpがガラパゴス化することへの懸念」をご理解いただきありがとうございますWinterのPrototypeも見てみました。ほんとはこういうテスト段階でどんどん提案していくのが良いんでしょうね。--miya（会話） 2014年7月27日 (日) 15:28 (UTC)[返信]
コメント （miyaさんへのコメント）MSP明朝に関するご指摘について。
現実問題として、Wolf359borgさんのガジェットでMSP明朝が表示される環境はほとんど無いはずです（MS Officeが入っていないWindows7以前のPCで、IE10以前のブラウザを使用していないケースだけだと思います）。動作確認のために意図的にその環境を再現でもしない限り、その条件での表示チェックはほとんど誰もしていないのではないでしょうか？
それと、モバイルビューでMSP明朝が表示されるユーザーも非常に少数だと思われます（WindowsRTのタブレットとWindows Phoneぐらい？）。おそらく最大シェアはiOSだと思いますが、iOSでモバイルビュー利用の場合はヒラギノ明朝で表示され、なおかつsafariブラウザであればh3以下の見出しもゴシックでなくなぜか明朝になってくれるので、下階層の節見出しとの強弱関係の齟齬が生じにくく、違和感を抱く人は少ないと思います。この節見出しの明朝化現象は、Wikipedia側で意図的に細工したものでないとすればSafari固有の特性（font-family無指定の場合は一律ヒラギノ明朝になる、しかもユーザーによる設定変更不可という仕様）に起因するものと推測します。あと、Andoroidの場合はバージョンや取り込んだアプリの種類次第でフォントの充実度はまちまちかもしれませんが、基本的にMSP明朝は入っていないので表示されないはずです。
私は、Typography refreshのデザイン意図とMSP明朝は両立できない（ありえない）という意見です。しかし、それを一般ユーザーに提供できるレベルできちんと両立するための具体的な目算があるならばそれを検討対象から外す理由はありませんが、今のところそういう実践的な説明を伴ってMSP明朝を推す意見というのは出てきていないと思います。
そういう意味では、上でWolf359borgさんが紹介されている見出しフォント指定のアレンジは興味深い面があると思います。Georgia依存という側面は勿論あるとしても、それに加えて、h3以下の要素もserifに変更することによってh2とh３の階層構造と視覚的な強弱との整合性の問題をクリアするという意図があると推測されますので、そういう具体策を伴った提案であれば選択肢のひとつとして建設的な議論の材料にもなってくるとは思います。--ディー・エム（会話） 2014年7月24日 (木) 13:36 (UTC)[返信]
MSP明朝と他の明朝をほとんど識別できない素人です、すみません。◆Georgiaの問題につきましては、ディー・エムさんの例示してくださった「3年B組金八先生」（File:Wikipedia (Ja) typography sample（Mac OS 10.9.4 + Safari 7.0.5）.png）を拝見してようやく得心しました。行の途中ならともかく、行頭で字が下がっているのは、たしかに見苦しいです。「游明朝Medium」「ヒラギノNormal」「MSP明朝＋Times」ならどれも良い感じにと思えますが、Boldはちょっと濃すぎる印象です（あくまでも個人の好みですが）。◆「モバイルビューでMSP明朝が表示されるユーザーも非常に少数」？私は、Windows7/IE11・Chrome36・Firefox31.0およびiPad mini/Safariで3年B組金八先生を表示させて見たのですが、ログアウト状態でもログイン状態でも3年B組金八先生の「3」が下にずれた状態で表示されたので、このモバイルビューが「Georgia＋MSP明朝」だろう・・・ということは、jawp独自の設定はモバイルビューには及んでいないのだろう・・・と思い込んだのですがちがっていたのでしょうか？--miya（会話） 2014年8月3日 (日) 15:26 (UTC)[返信]
4月のjawp独自の応急処置はあくまでベクタースキンのスタイルの修正[18]なのでモバイルビューは関係ないはずですね。今後はデスクトップの方もモバイルビューみたいな外観に移行していくみたいなんで、モバイルビューについて調べたほうがいいかもですね。--Wolf359borg（会話） 2014年8月3日 (日) 16:09 (UTC)[返信]
コメント モバイルビューはjawpの設定（ベクター用css）とは無関係です。iPad miniなどのiOS環境であればMS明朝ではなくGeorgia & ヒラギノ明朝で表示されているはずです。記事名（h1見出し）とh2見出しの全角文字（「登場人物」など）がノーマルのヒラギノ明朝、h3やh4見出しの全角文字（「坂本家」など）がBoldのヒラギノ明朝。
Win7の場合は、モバイルビューでも[19]の右下の表示例に近い状態で表示されているはずです（h3見出しの「坂本家」などはビットマップ文字の疑似明朝Boldに変わっているはず）。デフォルトのブラウザ環境であれば、iPadの表示状態とは目に見えて違いがあると思います。
ただ、その表示環境で閲覧している利用者は多くないと思われます。一般ユーザーがモバイルビューで閲覧しようとするとその都度PC用表示から切り替える必要がありますし（この前一時的にiOSのデフォルトがモバイルビューになっていましたが、１日ほど経ったら元に戻りました）、常時モバイルビューに設定しているログインユーザーもそうそういないと思われます。
フォントの太さや種類等については色々な意見があると思います。特に游明朝については、ひらがな混じりの場合に印象がかなり変わるはずです。漢字に比べてかな文字の大きさが小ぶりで余白を大きくとった本文テキスト用の上品なデザインなので、見出しとして使うにはBold指定（OSバンドルの游明朝BoldはDemibold=弱めのBoldのみ実装）の方がバランス的には良いと思います。そのあたりは、意見調整しながら候補を絞りつつ、選択肢の内容や決定手順が具体化した段階で最終的に投票で決めれば問題無いと思います。--ディー・エム（会話） 2014年8月4日 (月) 15:26 (UTC)[返信]
コメント スクリプトの遅延（描画の遅延）は、実のところ殆ど誰も気にしません。かつて私（2009年の話なので旧アカウント名 LuckyStar_Kid です）も「MediaWiki‐ノート:Common.css/過去ログ2#H1～6に「clear: both」を設定する提案」や「Wikipedia:井戸端/subj/節リンク移動問題へのJavaScript方式による対処の提案」で遅延問題について熱弁しましたが、問題視した人は自分以外にいませんでした。今は私も気にしていません。--Starchild1884（会話） 2014年7月3日 (木) 21:19 (UTC)[返信]
コメント 苦言 そういう子供じみた言い訳はもう勘弁して下さい。「技術的にはかなり簡単に対処可能であることが確認されています」の文言は前回の2014年5月20日 (火) 22:42 (UTC)の告知[20]と一緒ですよね。この時はcproさんが好意で示してくれたIE10以前とそれ以外の判別方法のサンプルコードを見ただけのはず。これだけでは何の技術的担保になっていないばかりか、本件ではjQueryは使用できません。また「MW名前空間のCSSページを外部CSSとして動的に読み込んだりすることもたぶんできると思います」という希望的見解（まさかこれで正式提案するとはcproさんも思っていなかったのではないでしょうか）も動的にCSSファイルを追加読み込みする方法はとても実用にならないことがわかっています。技術的な検討への誘導[21]や技術的目処はまだ確認できておらず議論場所も不適切[22]とご指摘申し上げましたが無視されましたよね。それでしばらく放置していたと思ったら、なんら見直しも、どうして人が集まらないのかを客観的に分析することもなく、同じような告知をなさったわけです。どうして人が集まらないのか？それは現状で特に問題が無いからです。ほぼ、Typography refresh以前に戻っているわけですから。そりゃ関心が無いわけです。それに「お知らせ」をマメにチェックしてる人が多いとも思えませんし（そもそも皆がお知らせをチェックしてたらTypography refreshで大騒ぎする前に対策してたはずです）。結局、氷鷺さんによる「フォント指定の復帰提案」の議論に納得がいかないからやり直したい、それだけなんですよね？その他に現状ではどうしてもまずい合理的な理由があるなら拝聴いたしますが、議論を差し置いてまずローカルハックを取り消す必要があるにしては、ずいぶんとのんびりと構えてますね。事が起こったのは4月ですがもう7月ですよ。今までいったい何をしてたんです？それで、過去の議論を例に出して「スクリプトの遅延（描画の遅延）は、実のところ殆ど誰も気にしません」ですか。節リンクという重要な機能の問題と、そもそも現状で問題ないところに余計な処理を追加して見出し文字全部が不自然に再描画されることを同一視されるとは呆れました。重いサイトならページレイアウトが変化しながらだんだん表示されていく様はよく見る光景ですが、ゴシックで表示された文字が不自然に明朝に化けるサイトというのはどうなんでしょう。それに遅延だけじゃなくてブラウザ互換性の問題もあるわけです。私はフォント切り替え処理を公開してますけど、Starchild1884さんがそれを試した形跡が全くないし、私に問い合わせもないのはどういうことでしょうか？技術的な話はわからないし、関心がないし、協力するつもりもないわけですね。それなら無責任に技術的な話に言及しないでほしいです。--Wolf359borg（会話） 2014年7月4日 (金) 12:16 (UTC)[返信]
コメント えーとですね、まず私には「jQuery」が何なのか分かりません。ライブラリみたいなもの？であれば、当初のcpro氏の提示されたサンプルそのようなものは含まれていないと思います。cpro氏のサンプルは非常に単純で、プログラムを書けない私でも、大昔に学校の授業で習った何らかのプログラミングの知識で「読む」ことはできます。if-else文ですから初等英語の知識だけでも何をやりたいのかは分かるかもしれません。そういう意味では、紛うことなく「技術的にはかなり簡単に対処可能」なんですよ。いざとなれば1行1行対応するhtmlやCSSを追加すれば何とかなるのだろうと判断できますから。
一方、Wolf359borg氏の提示されたサンプルは私は読めません。複雑な処理をするサンプルを書いて、ほら処理速度が云々と言われても、あなたの書いたその複雑なスクリプトではそうなのでしょうねとしか言いようがありません。スクリプトを読み書きできない者として敢えて言いますが、技術的な詳細を詰めたいならばしかるべき場所に移動してください。せっかく「技術的なことが分からなくても全く問題ありません」として、技術問題ではなくその対処手段について幅広く意見を募集しようとしているのに、ことごとくWolf359borg氏がそれを潰しています。--Starchild1884（会話） 2014年7月6日 (日) 21:21 (UTC)[返信]
コメント 苦言 まだお分かりでないようなのではっきりと申し上げます。cproさんはたんに好意からあのサンプルを示されたのだと思いますから遠慮していましたが、あれではあなたの当初の提案に対しての技術的な裏付けを何ら担保しておりません。あのコードはちょっと検索すれば中学生でも書ける程度のIE判別の初歩と、jQueryを使ってbody要素にアクセスして背景色を変えてるだけのものでしかありません。あなたはそれすら読み取れない程度なのです。それであなたは一体何を確認したのですか？cproさんの希望見解を真に受けただけですよね？私は問題は解決していないと主張していたのに都合が悪いから眼と耳を塞いでいたんんですよね。私に質問しましたか？他のウィキ技術部の方に質問しましたか？技術的な目処を付けたのは私の試行錯誤の努力とFrozen-mikanさんの貴重なアドバイスがあったからです。その間、あなたは何をしていました？
「技術的にはかなり簡単に対処可能」なんですよ。いざとなれば1行1行対応するhtmlやCSSを追加すれば何とかなるのだろうと判断できますから。
いやもう、開いた口が塞がらないというのはこのことです。あなたが何一つ理解していないし、理解できないし、理解するつもりもないのがよくわかりました。
技術的な詳細を詰めたいならばしかるべき場所に移動してください。
ここは「MediaWiki:Common.css」という重要なUI設定ファイルのノートページです。極めて技術的な検討をする場所です。技術的な検討と無関係に意見募集をしたいのなら井戸端でやってください。これもすでに申し上げたはずなのですが。
ことごとくWolf359borg氏がそれを潰しています。
いいえ、少なくともこの場所においてはあなたは何もしていなかったのですから、そのようなことをいう資格はありませんよ。さらに申し上げるなら、Wikipedia:井戸端/subj/現在のWikipediaのフォントにおいて、適切なフォント指定についての意見が出されていたのに、ご自分がIPAフォント指定してるからフォント指定は困るとか、MediaWikiに報告する際に欧米人にも深刻度が伝わるようにIE問題に絞ったものを、それしか問題が存在してないかのように言い出して、その結果としてcproさんのご提案に至っているわけですから、あなたこそ対処を停滞させている張本人だという自覚を持ってください。
すでに私はガジェットの提案をさせて頂いていますので、あなたはどうぞ井戸端で意見募集をなさってください。もう一度申し上げますが、技術的な話はわからないなら、無責任に技術的な話に言及しないでください。大変に迷惑ですし、協力していただいたcproさん、Frozen-mikanさん、Yhiroyukiさんなどにも失礼です。--Wolf359borg（会話） 2014年7月6日 (日) 23:29 (UTC)[返信]
コメント 個人への非難に終始するならば利用者ノートへ書くべきだと思いますが。私が第三者であれば、Wolf359borg氏のようなコメントばかりあったら議論に参加する気は起きません。また、技術問題に傾倒するあまり何故明朝体に変わったのかという点をお忘れなのではないか思います。--Starchild1884（会話） 2014年7月9日 (水) 21:50 (UTC)[返信]

h1、h2見出しのフォントに関する投票の提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

5月3日現在、mw:Typography refreshの件に関して、韓国語版の方でフォントを元に戻すかどうかの意見集約（コメント依頼）が開始されたようです[23]（ko:위키백과:사랑방 (기술)/2014년 5월#문서 서체 변경에 대한 의견 요청）。日本語版ウィキペディアとしても動くのにちょうど良いタイミングではないかと思います。各国があまりバラバラに動いてしまうとMW側が延々と結果待ち状態に陥ってしまう懸念もありますし（どのみち動かないという可能性もありますが）、逆にこちらの結論が出るタイミングでMW側で全然別方向の対応が出てきてしまうとちぐはぐが生じて苦慮する懸念もあるので、他と歩調を合わせられるならそれが無難なように思います。

そういった諸々の状況も踏まえ、この件について、以下のとおり投票の実施を提案します。実施の賛否や実施要領についてご意見があればお願いします。もしも合意が得られるなら下記の期日どおり実施、現時点で実施の合意が難しそうなら期日の延期もしくは一旦提案を撤回して仕切り直しとしたいと思います。

提案趣旨
2014年4月3日、ウィキメディア全体の仕様変更として、記事見出し（h1、h2要素）のフォント変更（Wikipedia:お知らせ#Tech News: 2014-15）が実施されました。これを受けて、日本語版ウィキペディアでは当該の仕様変更による問題を限定的に回避するため、従来どおりの見出しフォントに戻す応急処置を急遽実施し、現在に至っています（Wikipedia:井戸端/subj/現在のWikipediaのフォント）。ただしこれはあくまで暫定措置として合意されたものであり、必ずしも本サイトの長期的な仕様としてコンセンサスを得た変更ではありません。
さらに現在、「#応急処置の範囲をバグ回避のみに絞る」にて見出しのフォントを明朝体にすべきとの提案も出されましたが、現状のような通常の議論による合意形成プロセスでは満場一致に近い賛同を得る必要があり、提案側のハードルが高すぎて現実的な論争解決は望めません。このまま形骸的な意見交換を継続するだけでは結局結論の先送りにしかならず、また、現状の対処方法について信任を得ることにも繋がりません。したがって、このままうやむやに議論を放置してしまうことはいずれの立場からしても望ましい状況ではなく、できるだけ早期に日本語版ウィキペディアのコミュニティ全体としての総意を確認する必要があると思われます。
投票の主題
ウィキペディア日本語版の記事見出しを明朝体に変更するかゴシック体のままにするかの投票
投票資格（案）
2014年5月5日 0:00 (UTC) 時点で、全名前空間の編集回数10回以上のログインユーザー。多重アカウントによる投票は禁止（違反票は無効）。
告知方法・期間（案）
「Wikipedia:投票/リスト」・「Wikipedia:コミュニティ・ポータル」・「Wikipedia:コミュニティ・ポータル」（Template:意見募集中）・「Wikipedia:お知らせ」にて、2014年5月13日 0:00 (UTC) までに告知開始
投票期間（案）
2014年5月20日 0:00から2014年5月27日 0:00まで (UTC)
投票のルール（案）
投票者は、日本語版ウィキペディアにおける記事見出し（記事名と、"== ==" で記述する節の見出し）の書体を
のいずれに決定するのかを選んで投票する。
  • A案が過半数だった場合、日本語版ウィキペディア記事の見出しを正式に明朝体（セリフ）へと変更する。具体的には、次の手順を行う。
    1. 日本語版のローカルCSSで、記事の見出し（h1, h2要素）の書体を次の明朝体フォントに変更する。
      • Linux Libertine , Times（半角英数字[2]）
      • ヒラギノ明朝ProN（MacOS & iOS用）
      • 游明朝（Windows8.1用）
      • HGP明朝B（8.1以外のWindows + MS Officeインストール環境用）
      • MSP明朝（8.1以外のWindows + MS Office無し環境用 / ※旧IEバグ対応のため必須）
      • serif（上記以外の環境用）
    2. 上記のフォント指定にGeorgiaフォントを入れるかどうか等の意見調整を行い、最終決定した案を日本語版の正式決定としてメディアウィキのスタイルシートに反映してもらうよう依頼を行う[3]。
  • B案が過半数だった場合、日本語版ウィキペディア記事の見出しはゴシック体のまま変更なしとする。日本語版ウィキペディアでの正式な結論として、当該の結果（h1, h2要素に "font-family:sans-serif" を指定）をメディアウィキのスタイルシートに反映してもらうよう依頼を行う[3]。
  • A案とB案の票が同数のときは、いくつかの折衷案（例：記事名のみ明朝化する、メイリオなど非明朝の代替フォントを導入する、等）を検討し、投票で決める[4]。
  1. ^ 旧IEのバグ対応のため詳細なフォント指定が必須 。
  2. ^ Georgiaは暫定的にオミット
  3. ^ a b 私自身は、メディアウィキのスタイルシート変更の作業・手続きに関する権限・知識が無いので、他の方にお願いすることまでしかできません。あらかじめご了承ください。
  4. ^ 両候補が同数の場合の規定について、さらに異論が出て通らなそうならこの規定ごと除去でいきたいと思います。その場合は私の投票権を放棄して（同数になる場合のみ投票して）同数にならないよう調整します。

--ディー・エム（会話） 2014年5月5日 (月) 12:03 (UTC)（一部、文章表現を整理・修正しました。--ディー・エム（会話） 2014年5月7日 (水) 16:16 (UTC)）[返信]

投票提案に関するコメント[編集]

  • メタへの依頼は、最終段階に近い状態になってからがよいように思います。今回の結果は暫定処置として実施するということですので、そのためにメタを煩わすのもどうかという気がします。ただしウィキペディア日本語版でこのようなことが議論されている、ということをメタに報告し、時々経過を報告しておくのが望ましいように思います。これは、メタの人に状況を理解しておいてもらうためにも重要だと思いますし、ウィキペディア以外の日本語プロジェクトへの予告としても必要なように思います。また、投票実施前に、画面のイメージを作成してアップロードするか、または変更後の状況を体験できるcssを作成するのが望ましいように思います。ついでながら「Wikipedia:投票/リスト」掲載への便宜を考えて「投票の主題」の文言も考えて置いた方がよいと思います（些事ではありますが、案外こういうところで揉めがちなので）。--Freetrashbox（会話） 2014年5月6日 (火) 08:33 (UTC)[返信]
  • metaに関しては私もFreetrashboxさんと同意見です。それで投票提案についてなんですが…もし今投票を行うなら、まずは選択肢2の「元に戻す」か「あらためてフォント設定の検討を行う」かの2択ではないでしょうか。選択肢1およびそれが過半数だった場合に暫定措置の変更を行うなど性急すぎて容認できません。私がcproさんによる「応急処置の範囲をバグ回避のみに絞る」との提案に明確に反対した主旨は、応急処置の暫定修正など不要でありすべきではなく、別途暫定ではないフォントの検討きちんと行いそれにもとづいて変更すべき、というところにありました。記事見出しを明朝基調にするということも現時点では決め付けるべきではないと思います。ちなみにこれは私が明朝基調に反対しているという意味ではありません（実際、Linux LibertineとHGP明朝Eの組み合わせはわりと気に入ってました）が、和文のことをきちんと考慮したとは到底思えないTypography refreshに盲従する必要はないということです。--Wolf359borg（会話） 2014年5月6日 (火) 14:17 (UTC)[返信]
    返信 基本的な部分で誤解があるのかも。これは暫定措置を決定する提案ではありません。正式な最終結論を得るための投票実施の提案です。
    ご助言ありがとうございます。「投票の主題」を加筆し、「投票のルール」の説明も表現を若干修正しました。
    メタへの依頼はもちろん最終決定後（ゴシックに決定した場合は投票終了=最終確定）の想定です。メタへの報告は投票実施が決定したタイミングで行うことを想定しています。--ディー・エム（会話） 2014年5月7日 (水) 16:16 (UTC)[返信]
  • つまり、A案は明朝体（セリフ）のフォント設定をこれから検討するのではなく、
div#content h1, div#content h2, div#content #firstHeading {
    font-family: "Linux Libertine", Times, "ヒラギノ明朝 ProN", "游明朝", "HGP明朝B", "ＭＳ Ｐ明朝", serif;
}
のように実際に変更するという事なのですね。うーん、応急処置の暫定修正という意味のない提案が立ち消えになり、やっときちんとしたフォント検討が始まると思っていたのですが。これでは私はB案に投票する他ありませんね、残念です。明朝がいいかもと思っている人の票も減らすことになるでしょう。--Wolf359borg（会話） 2014年5月7日 (水) 17:24 (UTC) 一部修正 --Wolf359borg（会話） 2014年5月7日 (水) 17:31 (UTC)[返信]
返信 それもちょっと違って、A案は明朝体（セリフ）のフォント設定をこれから検討するというものです。ただし、検討作業が完了するまで待てないよ、という前段の提案事項・一連の議論に鑑みて、それまで仮の明朝のセットを反映させる、というものです。B案の場合は一択なので（投票後の検討作業期間が発生しない）ので不要な行程となります。--ディー・エム（会話） 2014年5月8日 (木) 04:07 (UTC)[返信]
  • 結局、A案は暫定措置に投票することになってるではありませんか。検討作業が完了するまで待てないよ、という前段の提案事項・一連の議論に鑑みてとおっしゃいますが、たかだか数名にも満たない「応急処置の範囲をバグ回避のみに絞るべき」という自己満足を要求する方々の溜飲を下げることを優先する理由があるのでしょうか？前節や井戸端で申し上げましたが、ベクタースキンは規定スキンですので、これの変更はここで議論している人のみならず、ウィキペディア日本語版を閲覧する全ての一般の方々にも影響します。また他の日本語版プロジェクトでもこちらの動向を見守っているようです。そういった影響の大きさを忘れないで下さい。いい加減なやり方で事をすすめるのなら、何もせずに現状維持に努めたほうがずっとよいです。そもそも、韓国語版で意見集約が開始されたからと、慌ててこちらで投票を行う必要があるとは思えません。下の方で引用したSteven Wallingさんのメッセージにもあるように日本語版でremoving the serif headersした事実は把握されているわけですし。フォントの規定値を言語ごとに設定可能な修正が実装されるなら、なおさら慌てる必要はないでしょう。--Wolf359borg（会話） 2014年5月8日 (木) 11:18 (UTC)[返信]
  • これに関連してちょっと疑問点があるのですが、よろしいでしょうか。韓国語版での意見集約においてリンクされたSteven Wallingさんのメッセージなのですが、それの下記部分
3). Jon Robson has put up a patch to allow LESS styles to be set per-language.[c] This means that many local site hacks, like Japanese Wikipedia removing the serif headers or Farsi Wikipedia having to set completely different Farsi-friendly fonts, will potentially no longer be necessary. Review and testing is needed! — Steven Walling、[Design] Typography refresh, now that dust has settled[24]
で日本語版に触れているのですが、どうにも正確に意図を掴み切れないでいます。どなたか翻訳していただけるとありがたいです。--Wolf359borg（会話） 2014年5月6日 (火) 15:21 (UTC)[返信]
  • コメント フォントの規定値を言語ごとに設定可能な修正が提案されたので、日本語版でserif指定を外したり、ペルシャ語版で独自のフォントを指定したりするような、言語固有のローカル設定は不要にできるということのようです（This means that many local site hacks　will potentially no longer be necessary. ）。ただ、この修正はまだ承認されていないようです[25]。--Yhiroyuki（会話） 2014年5月6日 (火) 16:14 (UTC)[返信]
    返信 渡りに船の仕様追加でありがたいですね。--ディー・エム（会話） 2014年5月7日 (水) 16:16 (UTC)[返信]
  • 投票を最終決定とすることに反対します。フォントの変更は、ウィキペディア日本語版だけの問題ではなく、メディアウィキとしての変更であり[26]、その方向性については共有し、試用期間をおく必要があると思います。つまり、見慣れたものから変えれば、よっぽどじゃなければ抵抗あるのが普通ですから、バグへの対処でゴチにしたけど、バグを回避して明朝にできるなら、明朝でしばらく（一月ほどでも）様子を見て、慣れさせる期間を作り、フォントの調整や意見募集をして、その後に最終結論を問う、というのが適切なステップだと思います。--Ks aka 98（会話） 2014年5月7日 (水) 17:57 (UTC)[返信]
    返信 当提案では投票資格がログイン編集者のみなので、動作確認用にユーザーカスタマイズ用のガジェットがあれば必要十分かと。逆に、既に上で指摘のでているとおり、スクリーンショットの出力見本は必要になると思います。投票の実務上、投票資格を限定せざるを得ないということは、投票者各位は自分個人の表示環境と好みだけではなく、投票権の無い編集者や編集参加していない一般利用者の満足度向上を主な基準として判断いただく必要があるので、各自のデバイスに依存せず万人の出力を確認いただける用意はしなければというのは念頭にあります。思いつつ、まだ用意できてないという……そこはすみません。できるだけ簡易な出力テストの結果画面みたいな感じで、それはすぐ用意したいと思います。
    十分に出力結果を無難な程度にコントロールできる対案を事前に作成・合意できるのであれば、ベータテスト的な試用期間を置いても良いと思いますが、一般読者に対しても影響を及ぼす話ですから、そのベータリリースの是非自体を投票でなく話し合いで決められるのかどうかが疑問ではあります（今回のフォント変更は既にリリースされ、結果としてとりあえず戻すことになっているという状況なので）。早急に明朝を要望されている方々がそれまで十分待てるよ（その結論が出るまでは現状の暫定措置延長を追認するよ）、というのであればその流れもありという方向で良いと思います（上記の提案で、明朝案の詰め作業を事後にしたのはその理由です）。--ディー・エム（会話） 2014年5月8日 (木) 04:07 (UTC)[返信]
強制的に慣れるための期間があったほうがいい、という意見ですので、スクリーンショットの出力見本とは違います。環境の違いもありますが、たとえばウォッチリストやRCなどでも確認する必要があります。最初の変更では太字が区別しにくくなっていたとも感じたので。ベータリリースは、Geogiaを外したcproさんのやつを使えばいいんじゃないかな。基本は、大きな見出しをゴチにするか明朝にするか、ですよね。いずれかが決まれば、好みのレベルで細かい書体の選択は、後から調整。この書体はダメというものもあるでしょうから、それが表示されることは避けなければならない。
で、投票自体は資格付きでいいと思うんですが、これは編集者だけではなく一般の閲覧者にも関わる問題ですから、citenoticeで事情を説明して広くコメントを集め、その上で投票というのがいいんじゃないでしょか。このプロセスをはさむことで、「変更後のフォント表示には問題がある」という意見が「単なる慣れの問題」かどうかが、多少見えてくるでしょう。投票権の無い編集者や編集参加していない一般利用者の満足度向上を主な基準として判断しなければならないのですから、限られたメンバーで検証できることには限りがありますし。一部の環境では、また大きなバグが出てくるかもしれません。
暫定導入＋citenotice、意見募集に1週間、修正が必要ですぐ対応できるものはその場で対応、検討や問題の修正に1週間の猶予、最終投票、でどうですか？　--Ks aka 98（会話） 2014年5月8日 (木) 05:32 (UTC)[返信]
強制することが目的だというのであれば、そこのところはユーザーに対するスタンスとして容認できません。それでは一体誰のための仕様変更なのかわかりません。ユーザー自身が明朝の見出しに慣れるための機会を求めているのであればそれに応える必要があるかもしれませんが、それを確認する有力な手段のひとつが投票であり、実行する順序が逆です。
技術的な動作確認が目的であれば一般ユーザーにまで試用を強要して行うべきではないですし、投票に先立って新書式の感覚を体感することが目的であれば、一番シビアと考えられるOffice無しWindows7 (or XP) ユーザーの表示状態（MSP明朝、cproさん原案を採用する場合はMacOS+MS Office & Firefoxでも同じくMSP明朝）を再現して判断材料にしてもらわなければ意味がありません。たまたま条件に恵まれた表示環境を持つユーザーが自分より劣悪な表示環境のユーザーが存在することに気づかないまま、自分の表示環境だけを見てこれなら許容可能と安易に早合点されてしまうと、むしろ問題の根幹を見えなくしてしまいかねないので。とはいえ私はMSP明朝の試用を全てのユーザーに一律に強制することも反対であり、ログインユーザー向けの見本提供（ユーザースタイルシートか、デフォルトoffのガジェット）で対応するのがベストという意見です。
また、現在のフォント指定は暫定措置であるとはいえ、相応の手順を経て仕様修正を実施しているものですので、それに対する異論や不信任ということであれば、対案とともにきちんと議論なり投票なりを提起して変更すべきです。もしもそうではなくて、あくまで意見募集のための一時的手段としてテスト表示を実施するのであれば、一般利用者の閲覧環境に影響を及ぼす期間は必要最小限とすべきで、1週間の意見募集期間のみで問題無いのではないかと思います。--ディー・エム（会話） 2014年5月8日 (木) 13:55 (UTC)[返信]
  • どうもディー・エムさんがおっしゃっていることは一貫してないように思えるのですが、どうでしょう。Ks aka 98さんに対してはユーザーに強制するのは容認できないとおっしゃっているにもかかわらず、投票で明朝スタイルの見出しが選択されたなら、「検討作業が完了するまで待てないよ、という前段の提案事項・一連の議論に鑑みて、それまで仮の明朝のセットを反映させる」[27]、これはユーザーに強制することではないのですか？そもそも、検討作業が完了するまで待てないと主張されてる方は本当にいるのでしょうか？もしかすると2、3名というところでしょうが、その方々に確認したのでしょうか？ありもしない主張を代弁している気がします。仮にそういう主張をされているとしても、前節の最後に私が述べたことに対して、子供だましの詭弁ではなしに納得の行く反論をしていただける方はいらっしゃるのでしょうか？また、私に対しては「A案は明朝体（セリフ）のフォント設定をこれから検討するというものです」[28]、と返信されていらっしゃいますが、投票のルール（案）を見ますと、「上記のフォント指定にGeorgiaフォントを入れるかどうか意見調整を行い、最終決定した案を」とあり、まるでGeorgiaフォントのことだけが未決事項であるかのごとくですよね。フォント設定をこれから検討するとおっしゃったのは、ひょっとして嘘も方便ということなのでしょうか？--Wolf359borg（会話） 2014年5月8日 (木) 21:57 (UTC)[返信]
    • 返信 いろいろいただきましたので順番に。
    • 「ユーザーに強制することではないのですか？」 > 投票で決めましょうというのが私の提案です。
    • 「作業が完了するまで待てないと主張されてる方は本当にいるのでしょうか？」 > 既に表明しているとおり、私自身は現状からの変更を急ぐべきという意見を持っていないので、意見を募った結果、それを早急に希望する方がいなければいないでむしろ歓迎です（いないということを確認できることが、その場合は重要）。
    • 「まるでGeorgiaフォントのことだけが未決事項であるかのごとく」 > これは表現をはしょりすぎて不適当だったかもしれませんが、他にもフォント修正の意見があれば当然同時に検討する流れになるでしょう。最初に返ってきたご意見を拝見して、最初の書き様だとなんとなく白紙から別途議論を立ち上げるかのような誤解を与えてしまっているのかなと感じて（投票でフォントの大方針を決定する意味が伝わってないようでしたので）表現を簡略化しただけなので、当初から実質的な内容の変更は意図していません。投票の目的についても、明朝にするかゴシックにするかという単純な表現に書きなおしたのも（正確性の面では語弊があるのは承知していますが、議論に支障は無いと考えられ、わかりにくいよりは良いだろうと）同じ理由です。（言葉足らずですみません、修正しました[29]）--ディー・エム（会話） 2014年5月9日 (金) 03:35 (UTC)[返信]
上の節では、検討作業が完了するまで待てないと主張されてる方はみあたりませんでした。
  • cproさん、Starchild1884さん、miyaさん、Marine-Blueさんは、応急処置への手続きとしてバグ回避についての合意はあるが、ゴシックに戻す合意はないと受け取っています。その上で、Typography refreshの方向を尊重しながら、検討しよう、と。
  • Wolf359borgさん、Claw of Slimeさん、Freetrashboxさんのうち、Freetrashboxさんはフォント変更への不満が大きかったとしていますが、Wolf359borgさん、Claw of Slimeさんは応急処置の手続きについての言及をしていません。この3者は、今のままで、Typography refreshの方向に沿ったフォントを検討していこう、という考えです。
  • このほかの議論参加者に氷鷺さんがいらっしゃいますが、Typography refresh全否定です。
  • 応急処置に賛意を示した方は、その後の件については誰も意思表示していません。
物事を早く進めるなら、ぼくがさっき書いた手順です。バグ出しや、いろんな環境への対応もできますから。穏当に進めるなら、検討の後に仮導入です。それにしても、導入後バグだしや環境への対応のステップは必要となります。いずれにしても、何かを「決定」するなら、その後、でしょう。
ディー・エムさんの投票提案は、Typography refreshのことを検討・検証する機会は作らずに、現状維持で決定させることができる、ってものになっちゃってます。意思決定には、判断のための知識が必要ですが、Typography refreshについても、明朝系での印象についても、それが決定的に不足しているままに、多数決で決めてしまう。これは、適切な多数決にはなりません。Wikipedia:調査投票の方法もご確認いただければ。
なおスティーブンさんのコメントは、言語ごとに（種類を減らしての）スタイルを認めるパッチをあてた。これは、ローカルサイトのハック（ローカルでの上書き）はもはや不要ってことを意味する。レビューとテストが必要なんだ！！！ってものですね。--Ks aka 98（会話） 2014年5月9日 (金) 06:01 (UTC)[返信]
であれば議論による検討を継続ということで良いと思います。
「Typography refreshのことを検討・検証する機会は作らずに」 > 従前からの「Wikipedia:井戸端/subj/現在のWikipediaのフォント」や「#応急処置の範囲をバグ回避のみに絞る」の議論だけでは検討・検証が足りないという問題提起であれば、足りないと述べてください。議論の現況分析や解決手段の判断に関して意見の相違点を伺えることは貴重ですし傾聴に値すると思いますが、誤解を招く表現は避けてください。
それと、「ゴシックに戻す合意はない」という言及は誰もしていないと思います。対処範囲や手段の選択についての異論はもちろんあるものの、「#フォント指定の復帰提案」やその前段の「Wikipedia:井戸端/subj/現在のWikipediaのフォント#原状復帰の提案について」で「フォント指定のみの原状復帰」・「もとのフォントの状態に戻してもらう」と明示されており、そのことを疑う意見は今のところ出ていないと思います。--ディー・エム（会話）
コメント 「ゴシックに戻す合意はない」に関して。これについては、私は 2014年4月27日 (日) 21:15 (UTC) に意見を述べていますのでご参考までに。冷静に考えていただきたいのですが、どう好意的に解釈しても「理由は明確ではないが明朝体は見辛いという意見がたくさん出ているのでゴシック体にしよう」というのは「とにかく早急に（今日明日にでも）修正すべき問題」ではありません。一方でいわゆる「韓国漢字問題」は、日本語部分が日本語で表示されないという明らかな不具合ですから、対処方法があるならば早急に対処すべき案件でした。提案者の氷鷺氏は「今そういった話をすべきではない」などと言って具体的な変更すべき理由を述べず、これが「理由は明確ではないが明朝体は見辛いという意見がたくさん出ているのでゴシック体にしよう」という提案であったことを述べたのは私が苦言を呈してからでした。また、氷鷺氏の提案を「バグ対応だな」と思えば（思い込めば）それに賛成し、あるいは強いて反対しないという人も多くいるでしょう。このような手口を用いて行なわれた変更が、しかも提案から時間を置かず超スピードで行なわれた変更が、合意を得たものと言えるのかは疑問に思います。（一応言っておくと、対処者のFrozen-mikan氏がどうこうというわけでは決してありません。何らかの問題があるとすれば、このような手口を用いて変更を急がせた氷鷺氏にあると考えるのが自然です）
あと、細かい点なのですが、正確には「ゴシック体に戻したのを明朝体に変更するか否か」ではなくて「ゴシック体に変更したのを明朝体に戻すか否か」なんですよ。普段であればこんなものは言葉遊びの域なのですが、氷鷺氏の手口を見るに、この点は明確にしておかなくてはならないと思いました。--Starchild1884（会話） 2014年5月9日 (金) 21:57 (UTC)[返信]
氷鷺さんの提案と進め方には強引さはあったでしょう。ですが、見出しをいったんゴシックに修正することは必要なことだったと思います。前節での私のコメントを読み返してみてください。IEバグの件はそれの優先度を高め、対処を早める要因になったにすぎません。氷鷺さんとの間にどんな感情的軋轢があるのかは存じませんが、これ以上この件の対処にそういうものを持ち込まないようにお願いいたします。それと言葉遊びの件ですが、Starchild1884さんはウィキペディアン以外の一般の利用者への配慮が足りないと思います。完全に作り手の都合・論理なんですよ。ウィキペディア内の事情などあずかり知らぬ閲覧者にしてみれば、「急にウィキペディアのフォントが明朝のキモイのになった。なにこれ？」→「しばらくしたら元に戻ったヤレヤレ」です。Typography refresh自体が日本語環境においてはバグ以外の何物でもなかったわけです。それに、「ゴシック体に変更したのを明朝体に戻すか否か」とおっしゃいますが、IEバグ対応もあるしGeorgiaフォント抜き（賛成していただいていたはず）ですから、明らかに「戻す」ではないですよね。「財団の方針には従わなくてもよい」というのは「財団の方針に従ってはいけない」ということではない、みたいな発言も言葉遊びの域に過ぎません。「ゴシックか明朝か」「Typography refreshに従うか従わないか」といった視野狭窄状態になるべきではなく、Typography refreshをきっかけに日本語版でのフォント設定を見直す検討を始めるべきだと思います。#フォント指定の復帰提案においてTam0031さんがおっしゃっていた「本格的な修正についてはまた考えましょう」ですね。いかがでしょうか。--Wolf359borg（会話） 2014年5月10日 (土) 00:03 (UTC)[返信]
コメント 「明朝体は見辛い」という意見の根拠は比較的明確で、KAWASAKI Hiroyukiさんのコメント（2014年4月6日 (日) 09:32）や、Claw of Slimeさんのコメント（2014年4月26日 (土) 01:10）、韓国語版ユーザーGaladrienさんのコメント（02:52, 4 April 2014‎ ）、それといちおう私のこの言及（05:57, 6 April 2014の2点目…英語ダメなもので総じて表現が適当ですが）でも言及があるとおり、Typography refreshの設定が通常のパブリッシングデザインのセオリーと逆になっているので、慣れとかそういうレベルの問題ではないです。単に「見出しが明朝よりゴシックの方が良い」ではなくて「それをやるなら普通は本文を明朝にするでしょ」という、従前の仕様変更の説明のどこにも無い異論が異口同音に複数のところから出てくるというのは、これが個々人の感覚的な話ではなくて、実際に広く共有されたデザイン上の常識だということに他なりません。そのことについての知識や経験があるかどうかによっても、この問題に対する深刻度の認識が分かれるのかもしれません。あるいは逆にウェブデザインに造詣の深い方々からすると、本文での明朝使用は（文字が小さく）美しくないという声はあるかもしれません（先入観かもしれませんが）。
その点ではStarchild1884さんは既に印刷用cssのカスタマイズをいち早く提言されており[30]、（これの違和感が画面上より紙媒体で顕著に出るいうところまで含めて）このフォント選択の視覚的影響についてもそれなりに熟知した上であえてこれまでのような立場のご意見を述べられているのだと思いますし、レンダリング上のバグに比べればフォントの問題は優先度が低いというのも確かにそうっちゃそうなのですが、だとするならばバグ対処だけに限定した最小限の変更とは一体どういうものなのか？という点で見解の相違があるのだと思います。
もしも現行のフォント指定を必要最小限の対処策でないとみなすなら、それと同じ基準で考えるならば今出ている対案の方がローカル固有のフォント指定を増強して（好き好んでやっているわけではないということは理解しています）サイト側からユーザーへの支配率が絶対的に高く、デバイス環境による落差を顕著に拡大させるため、むしろ趣旨から逆行しているというのが私の意見です。しかし既存の暫定措置に異論があるならば本来は元に戻しましょうというのが筋論ではあるし、かといって不具合を承知で単純機械的に元に戻すのはさすがに無責任すぎるというのはWolf359borgさんご指摘のとおりですし[31]、さりとてこのまま対処が長引いて、もしも将来的に「一時しのぎで合意を得ただけのはずなのに延々引き延ばしやがって」みたいな批判が出てきたら「じゃあどないせえっちゅうねん！」と思いつつも「そりゃそうですよね」と受け止めざるを得ないはめに陥るし…。本当の意味で誰が見ても必要最小限の対処内容に絞りつつ、なおかつユーザーに不利益を与えないミニマムな代替案を、まずはとにかく導きだすしかないのかなと。今思う方向性としてはそんなところです。--ディー・エム（会話） 2014年5月10日 (土) 04:34 (UTC)[返信]
コメント 「通常のパブリッシングデザインのセオリーと逆」に関しては、私は「紙面上ならともかくディスプレイ上でならそれほど問題ないのではないか」と考えていますが、しかし問題があること自体は認識しています。メリット・デメリットのどこに重きを置いているかであり、本来であればこれは議論を通じて落とし所を探ることができるはずなんです。当ノートでも、建設的な意見を出されている方々は、総じてメリット・デメリットともに理解して発言していると思われます。
一方で、井戸端で多く出された「明朝体は駄目、ゴシックが良い」というだけの意見には、そういったメリット・デメリットについての言及がありません。当ノートにもある「Typography refreshそのものがバグ」といった発言も結局その理由について説明していないし、「多数が明朝体に反対している」というのも自分の意見というものが無い、そしてそれを指摘してもポイントのずれた返答しかしない……となれば、それは単純に変更に対する拒否反応なだけでしょう？と考えるのは自然だと思います。すなわち、本質的には「メリット・デメリットの両面を考慮して進めなければならない議題」であり、当ノートでもそういう方向で進めるべきであるにも関わらず、大多数にとっては結局「ただの慣れの問題」でしかない、ということです。いかに声高らかに「絶対明朝体反対！」と叫んでも、内容の無い意見をいちいちこちらで心血注いで汲み取るのもちょっと違う気がします。とはいえそういう発言により議論が停滞させられたとて、追い出すわけにもいかないのですが。たとえば「明朝体がキモい」というならばそれはそれで結構ですが、意見として述べるならばキモい理由やそれがゴシック体でならば起きないという説明をすべきであるのに。
現時点では、Ks aka 98氏の提案が一番無難な落とし所かなという気はします。少なくとも、合理的ではあります。「暫定」明朝体の時間は最低16日は必要だと思います。1週間に1回程度のアクセスの人が「変更」を経験して、ある程度日が経ってきちんと考えがまとまったのを意見として投稿しようとすると、これより短い期間というのは適切ではないと思います。--Starchild1884（会話） 2014年5月10日 (土) 21:06 (UTC)[返信]
コメント できるだけ多数のフィードバックを得るために実際のサイト表示を変更して注目を集めるというのは考え方としてはありだと思いますが、ただ既出のフォント案を適用して「あなたの環境で表示されるフォントは許容範囲ですか？」と聞いたところでそれだと単なるMS Officeのシェア調査にしかならないので、やるとなれば全環境にMSP明朝を適用して「こういう表示状況のユーザーも発生しますけどあなたなら許せますか？」と聞かないと意見聴取としては意味が無いと思います。非Officeユーザーを「ああご愁傷さま」的に切り捨てるのでなければ。
ある程度時間をかけて進めても良いのであればそれよりも、品質的に問題ないケースから順番に加えていく方法のほうが良いのではないかと思います。まだ下記の投票見送りの合意確認中なのでこれは正式な提案ではないですが、次のような順序で進めることはできないかというのが今の思いです。
  1. まず現在のフォント指定（sans-serifのみ）にLinux LibertineとTimesを加えることを検討。
    • これは手続き論的な文脈でいえば、現在の暫定措置を必要最小限の対処内容（オリジナルのCSSから、Georgia問題→フォント削除1件・IEバグ回避→フォント変更1件のみに限定）に改訂し、当初の暫定措置の継続が是か否かという議論をそこで完結するための変更です。もう一つの意図として、次の2番目のステップで全角ゴシックと半角ローマンの混成が発生することの是非（Linux LibertineとTimes指定を温存か除去か）を実際に体感して判断しておいてもらうという目的を含みます。
  2. さらにHGP明朝EとiOS用ヒラギノ明朝W6、游明朝Demiboldを加えるかどうか検討し、導入[※注]。
    • そもそも今般のTypography refreshの全体的なデザイン調整は事実上Georgia前提の仕上がりになっており、その是非はともかく、結果的にそれと似た太さの字体であれば日本語の明朝でも元のデザイン意図には上手くはまるので、一般的な書体の中でその条件に合致するヒラギノ明朝W6（iOS & MacOS+Safari, Chrome）、游明朝Demibold（Win8.1+IE, Chrome, Opera）、HGP明朝Eを先行導入するというものです。それらのフォント指定を追加するだけならそれ以外の環境でもノーリスク（従来どおり日本語フォントがゴシックのままになるだけ）ですし、Office（明朝Eの方はWinとMac版両方に同梱）と最新Win&MacOS（Firefox以外）とiOS（androidはどのみち明朝指定不要でしょう）なので実際かなりのカバー率で変更が反映されることになると予想します。
  3. 次の検討課題として、MSP明朝を除き、上記以外の明朝フォントを導入するかどうか意見集約・投票。
    • HG明朝E以外のオーソドックスなフォントの場合、boldにしないと見出し用途には細すぎる感があるものの、かといってHG明朝を組み込むとなるとbold指定はおそらく厳しいので（不可能ではないものの字形が劣化するので）、個人的には積極導入にはあまり気乗りしません。しかし游明朝やヒラギノ明朝などはフォントデザイン自体のクオリティでそれなりに好感も持たれると思いますし、見出しとしての機能性を特段重視しなければモニタ上での美観がさほど破綻するようなものでもなく、もっぱら感覚的な問題なので、これは投票で決めれば良いのではないかと思います。「MSP明朝を除いて」というのは具体的には、 "……, 'MS　P明朝', serif " を用いず "……, メイリオ, serif" にする（XPもカバーするならMSPゴシックも加える）というものです。
  4. MSP明朝の扱いも一応検討。
    • 見出しの書体として実用的でないと思いますが、「財団がserifと言ってるからserif以外不可」（実際には別に言ってないとは思うのですが、仮に）みたいな意見が出てくる可能性も無きにしもあらずなので、いちおう問題提起は行って確認はしておく必要が。
で、3番目の投票時に2の変更をキャンセルしてゴシックに戻す案・2のフォント選択を細めのHGP明朝Bに変更する案などを選択肢に入れて結論を出す形にすれば、それ以上ユーザーに影響大なフォントパターンの導入実験まで敢行しなくても判断に困るとも思えませんし、問題無いと思います。さらに、これに加えて印刷用のスタイル指定（見出しはいじらず本文を明朝にするのが良いように思います）を別途行うという流れでいければ、現状の暫定措置の変更議論への対応もこなせつつ、最終的なクオリティ面でも、最大公約数的な評価としてそんなに支障は出ないように思います。--ディー・エム（会話） 2014年5月11日 (日) 08:27 (UTC)（※注 ^ フォントと対応可能環境の情報を追加しました。--2014年5月12日 (月) 12:00 (UTC)）[返信]
コメント 確かに、バグ対応のみに絞った表示（MSP明朝）はjawikiで用いることが許容できないことなのか調査しないことには話が先には進みませんね。ウィキニュースほかウィキメディアプロジェクトとの兼ね合いもありますし（少なくとも「書体の統一」という意味においてjawikiは現在イレギュラーな状態です）、ひとまず、絶対に明朝を使用してはならない理由が提示されない限りにおいて、少しずつテスト導入してみて意見収集と改善をしていくということでよいのではないでしょうか。「なし崩し的な恒久化」への反対があれば、期限を切っても良いでしょう。（井戸端でも言ったとおり、個人的には最終的には「デフォルトでオンのガジェット化」を考えています。私は明朝はIPAフォントを使いたい）
ディー・エム氏の提案も悪くはないのですが、この際、当初のcpro氏の案のまま「まずやってみる」でも良いのではないかと思います。それで、1～2週間ごとに意見を集約して少しずつ改善していく……なども良さそうです。CSSページを編集する管理者の負担は増えてしまいますが、その辺はご協力お願いします。先にも述べましたが、月末くらいまで待ってみて、絶対に明朝を使用してはならない理由が提示されない限り、「明朝体に戻してみる」でよいと思います。--Starchild1884（会話） 2014年5月17日 (土) 22:02 (UTC)[返信]
当初のcpro氏の案には反対です。しかし投票によって多数の支持を得るなら実施を妨げるべきでないと考え、投票による解決を提案していたところですので、投票実施の有無の最終確認（下記）をあと１週間延長し、様子をみたいと思います。--ディー・エム（会話） 2014年5月17日 (土) 23:20 (UTC)[返信]
  • しばし放置してましたので私の主張を整理します。コメント位置に悩みましたが、とりあえずここに。ディー・エムさんの合意確認期間告知を横線で区切らせていただきました。
  1. 現状で特に実害は無いので結論を急ぐ必要はないと思います。まずはきちんとしたフォント見直しの検討をすべきで、そうでなければ当面現状維持で。
  2. 「明朝かゴシックか」というニ者選択にこだわるべきではありません。また「明朝に戻す」という認識も正確ではありません（明朝に反対という意味ではありません）。
  3. 本ノートで「建設的な意見」が出されないのは当然で、当初の提案に対するコメントの場だからです。フォント見直しの検討を開始すべきです。
  4. 当初のcproさんのご提案には再度反対を表明します。
  5. これからの進め方、およびディー・エムさんの2014年5月12日のご提案に関しては後述します。
1について。
  • Typography refresh導入時はjawp内外で不満意見が噴出しましたが、現状そういう意見は目にしません。何よりこのページの議論に参加している人がたったこれだけなのが現状で特に実害は生じていないことを明確に物語っています。
  • 現状の応急処置がIEバグ対応以外のものを含んでいるからそれを切り分けるためにまず修正しようとか、Typography refreshに追従するべきという意見は理解はできるものの、それにこだわるのは内輪の人間・作り手の論理であり、プログラマが納得いかないコードの書き直しをしたがるようなものです。こと一般への影響度が高いVectorスキンのフォント設定に関しては対処を急ぐ理由にはならない、と考えます。
  • 他の姉妹プロジェクトと書体が統一されていないことはたしかに問題ではありますが、残念ながらjawpに比べ他プロジェクトの知名度と影響度は段違いに低いのが現状で、書体統一はjawpでの検討を踏まえてからで十分間に合う話だと思います。もちろん他プロジェクトからの異論があれば別ですが。
2について。
  • sans-serifの見出しがTypography refreshによってserif系のフォント設定に変更されたものを応急処置でsans-serifに上書きして「ゴシックに戻した」のであり、「明朝をゴシックに変更」したわけではありません。したがって「明朝に戻す」という表現は正しくありません。
  • 絶対に明朝を使用してはならない理由が提示されない限り、「明朝体に戻してみる」、これは明朝にするのが当然であるという決め付けに基づく論理であり、考慮に値しません。
  • せっかくのこの機会を「明朝 vs ゴシック」論争にしてしまうのは実にもったいない話です。閲覧環境も様々で昔とは変わってきています。ここらできちんと見直しをすべきだと思います。
  • ちなみに私はWindows 7+Firefoxの閲覧環境ですが、応急処置が施されるまではLinux Libertineをインストールし、serifをHGP明朝Eに置き換えて表示させていました。
3について。これはStarchild1884さんへの反論になります。
  • 前節は応急処置の範囲をバグ回避のみに絞ったものに設定を変更する、というcproさんのご提案であり、本節はできるだけ早期にjawpの総意を確認するために見出しフォントを明朝体に変更するかゴシック体のままにするかの投票を行う、というディー・エムさんのご提案が主題です。どちらもこれからフォント設定を検討するという場ではありませんでした。私は、とりあえず変えてみるではなくまず検討を行ってから、のスタンスでしたのでうかつに「建設的な意見」を申し上げることはできない状況でした。
  • ご自分が考えるところの「建設的な意見」や「合理的理由」に合致しない、という決めつけで複数他者の意見を不当に軽んじる姿勢はいかがなものかと思います。
4については特に補足することはありません。
5について。
  • 私が漠然と考えているこれからの進め方ですが、下準備として考慮すべき各閲覧環境を洗い出し、告知を出して他の方のご意見を求めた上でフォント設定の暫定案を検討、それを踏まえてあとはおおむねディー・エムさんの流れでよろしいかと思います。ただし意見集約のための体感は擬似環境やスクリーンショットを用意するなどして、実際の設定変更は最小限に留める配慮が望ましいと思います。
以上、長文失礼いたしました。--Wolf359borg（会話） 2014年5月18日 (日) 03:35 (UTC)[返信]

冒頭の投票実施の提案について、現在のところ、反対意見有り、賛成意見無しという結果です。あと1週間ほど待って、賛成意見や投票実施の修正案がどなたからも無いようでしたら、投票による早期の仕様変更は見送りということで本提案を閉じたいと思います。--ディー・エム（会話） 2014年5月9日 (金) 14:15 (UTC)[返信]

念のため、合意確認の期間をあと１週間延長したいと思います。--ディー・エム（会話） 2014年5月17日 (土) 23:20 (UTC)[返信]

取り下げ 投票を希望する意見が特に出ませんでしたので、投票は見送りといたします。--ディー・エム（会話） 2014年5月25日 (日) 14:06 (UTC)[返信]

Lintエラーを修正（対応していないpre終了タグを除去）しました。--MawaruNeko（会話） 2018年7月9日 (月) 14:29 (UTC)[返信]

Announced JavaScript change for badges implementation[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.css which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene*（会話） 2014年8月18日 (月) 20:26 (UTC)[返信]

Infoboxのクラス追加[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

Infoboxのクラス追加を提案します。{{Infobox Settlement}}をそろそろ英語版の最新版のように{{Infobox}}を使用したのに更新すべきではないかと考え、Template:Infobox Settlement/testcasesでテストしたところ、横の罫線が表示されておらず違和感を覚えます。なので横の罫線が入るように英語版から以下のクラスの追加を提案します。 

/* Styles for geography infoboxes, eg countries,
   country subdivisions, cities, etc.            */
.infobox.geography {
    border-collapse: collapse;
    line-height: 1.2em;
    font-size: 90%;
}

.infobox.geography  td,
.infobox.geography  th {
    border-top: 1px solid #aaa;
    padding: 0.4em 0.6em 0.4em 0.6em;
}
.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
    border-top: 1px solid #aaa;
    padding: 0.4em 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
    border: 0;
    padding: 0 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
    border-top: 0;
    border-bottom: 1px solid #aaa;
    padding: 0 0.6em 0.4em 0.6em;
}

.infobox.geography .maptable td,
.infobox.geography .maptable th {
    border: 0;
    padding: 0;
}

（en:MediaWiki:Common.css 2016年7月28日 (木) 21:40‎(UTC)より転記）

よろしくお願いします。--K-iczn（会話） 2016年8月31日 (水) 16:36 (UTC)[返信]

 反対寄り 提案の順序についてですが、先に{{Infobox Settlement}}にて提案を行ったほうがよかったと思います。さて、この提案についてですが、{{Infobox Settlement}}側の工夫で対処できますし、テンプレートの使用も地理分野の記事に限られますから、私はわざわざすべての記事に影響するMediaWiki:Common.cssを変更しなくてもいいかなと思っています。{{Infobox Settlement}}側の工夫の一例をSpecial:Permalink/61026150に（サンドボックスとして）書いてみましたので、参考にしていただければと思います。こちらでもこのclassがそのまま使われているようですが、style指定もされているので、そのままでも問題ないでしょう。--Waiesu（会話） 2016年9月4日 (日) 12:47 (UTC)[返信]
確認しました。Waiesuさんの書き方で問題なく罫線が表示されますので一旦この提案は取り下げます。--K-iczn（会話） 2016年9月4日 (日) 13:59 (UTC)[返信]

Typography refresh 対策用ガジェットの廃止提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

かつて Typography_refresh でVectorスキンの見出し(h1/h2)がセリフ/明朝書体になり、これを打ち消すためのスタイルが追加されたり、スタイルを上書きするガジェットが作られたりしてきました。

一方で、開発者側でも見出しフォントを再検討する議論の中で非ラテン文字の言語版での問題が挙がり、去る2016年7月、ja/he/ko の3言語について見出しの書体が「font-family: sans-serif;」のみの指定に変更されました。

既定の見出しの書体がサンセリフになった以上、以下は役目を終えたと言えるでしょう。

  • ガジェット「Vector 外装の書体を文字体裁の更新以前と同じ（サンセリフ／ゴシック体のみ）にする」 - IP利用者を含め既定で有効なガジェット。「font-family: sans-serif;」を指定する。

また、見出しをセリフ系書体にする場合の適切なスタイル指定を検討するための以下の試験用ガジェットも当面不要となったものと思います。

というわけで、上記ガジェット2点の廃止を提案します。再度セリフ体が採用されるような場合はまた必要とされるかもしれませんので、廃止といってもMediaWiki:Gadgets-definitionから定義を除外するだけの処置になると思います。以上、ご意見お待ちしております。--cpro（会話） 2016年11月8日 (火) 04:17 (UTC)[返信]

反応がいただけないですが、このまま廃止してしまって大丈夫なかんじでしょうか。念のため今月いっぱい待って、特に問題なさそうなら実施しようと思います。--cpro（会話） 2016年11月22日 (火) 04:43 (UTC)[返信]
標準機能を打ち消すことを問題としたガジェットであったため、廃止して差し支え無いと考えます。文句を言われてもそれが標準仕様である旨を説明し、必要があれば各利用者での対応を求めるべきです。--Marine-Bluetalk✿contribs✿mail 2016年11月22日 (火) 06:54 (UTC)[返信]

チェック 済 廃止を実施しました。Marine-Blueさん賛同ありがとうございました。 --cpro（会話） 2016年12月6日 (火) 00:52 (UTC)[返信]

読点用hlistクラスの追加提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
.hlist-comma dd:after,
.hlist-comma li:after {
    content: "、";
    font-weight: normal;
}

参考議論：Wikipedia‐ノート:表記ガイド#羅列の区切りに用いている読点を中黒に修正することについて、プロジェクト‐ノート:アニメ#各話リストのスタッフ列挙に用いている読点「、」について

hlistの区切り文字には「 · 」「 | 」「 - 」がありますが、日本語の羅列では読点「、」の方が自然で見やすいことも多いため、新たに読点「、」を追加することを提案します。--XRGD（会話） 2017年3月27日 (月) 08:08 (UTC)[返信]

反対 hlistは主にNavboxなどのナビゲーションテンプレートで用いられるclassで、Navboxではリンクの区切りに読点を用いることは一般的ではないことから、特に追加する必要性を感じません。--新幹線（会話） 2017年3月27日 (月) 10:06 (UTC)[返信]
コメント hlistはナビゲーションテンプレートだけで使用するclassではありません。en:Apple Inc.のInfoboxなどでも使用されています。--XRGD（会話） 2017年3月27日 (月) 10:21 (UTC)[返信]
コメント 反論がありませんが、異論はないとみなしてよろしいでしょうか。--XRGD（会話） 2017年4月3日 (月) 08:51 (UTC)[返信]
賛成 人名の列挙など読点を区切りに用いる記事は多く、Help:ページの編集#横リストの節でもある通り改行の問題が解決出来ますので、導入されれば有用性は高いと思います。なので、導入されれば積極的に使いたいと思いますので、追加を望みます。--えのきだたもつ（会話） 2017年3月27日 (月) 13:11 (UTC)[返信]
賛成 導入する事によるメリットは十分にあります。navbox以外にも使用用途はありますし、infoboxや表などでの使用も考えられます。--mirinano (talk) 2017年3月27日 (月) 13:53 (UTC)[返信]
報告 追加されました。また、{{hlist}}のclass指定（class=hlist-comma）が省略できるようにした{{hlist-comma}}を作成しました。--XRGD（会話） 2017年6月7日 (水) 12:00 (UTC)[返信]

Navbox関連の設定をtableタグに限定しないよう変更する提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

モジュール‐ノート:Portal bar#モジュールの更新提案にて、Common.cssにおけるNavbox関連の設定でtableタグ限定のもの（table.navbox）をタグ限定無し（.navbox）に変更する提案を行っています。もしよろしければ、そちらでコメントをしていただければ幸いです（議論が拡散しないよう、こちらでのコメントは避けていただくと助かります）。--ネイ（会話） 2018年4月4日 (水) 16:01 (UTC)[返信]

上記の提案については特に問題がなかったため実施しましたが、追加で.navboxの設定にbox-sizing: border-box;を追記する提案を提出したため引き続きコメントを募集します。--ネイ（会話） 2018年4月14日 (土) 04:20 (UTC)[返信]
追加提案も実施しました。--ネイ（会話） 2018年4月21日 (土) 06:41 (UTC)[返信]

hlistを区切り部分で改行できるようにdisplayをinlineからinline-blockに変更する提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

Wikipedia:バグの報告#エピソードリストでスタッフ名が改行されないで、{{Hlist-comma}}や{{Hlist}}が改行されず、これらを使用した表が横に伸びるという現象が報告されています。この解決策として、Common.cssのl.181、 .hlist dd, .hlist dt, .hlist liのスタイルを、display: inline;からdisplay: inline-block;にするという変更を提案しています。--MawaruNeko（会話） 2018年7月9日 (月) 14:07 (UTC)[返信]

MediaWiki.orgにあるもとのコードでは、数年前に nowrap が廃止されたようです。これに追従するというのはどうでしょうか？ ウィキペディア日本語版のコードは基本的に数年前に移入してから追従しておらず、一部独自機能（新規の区切り記号のみ、でしょうか？）が追加された状態のようです。詳しく調べてはいないのですが、hlist のおもな開発者の Edokter さんによれば、いろいろ問題が続くので hlist での nowrap 指定をなくした、というような経緯があるそうです。nowrap は必要に応じて、個別テンプレート等のなかで指定するようにしたほうがいいのかもしれません。 --whym（会話） 2018年7月11日 (水) 14:20 (UTC)[返信]
なるほど、情報ありがとうございます。IE8はさすがにもう考えなくてもよいのではないかと思いますが、最近はモバイル版なども考慮する必要がありますし、難しいところですね。スペースで単語が区切れているのでnowrapを指定しなくてもある程度きれいなところで改行される英語などの言語と比較すると、日本語だと単語の区切り位置が機械的には分からないという違いもありますし。--MawaruNeko（会話） 2018年7月11日 (水) 15:16 (UTC)[返信]
むしろ、日本語の単語に関しては、単語の途中で改行してもいいように思っていますが。原稿用紙に書くとき、行末で単語が切れたりするのは普通のことですよね（括弧などの禁則処理は別として）。「日本語組版処理の要件」を見ても、分割禁止に当たるのは、日本語文中のアラビア数字の連続や欧文文字の連続など、例外的なものに限られています。ブラウザの実装によるのかもしれませんが、Google Chrome で試したかぎりでは、記号やラテン文字については、nowrap を解除しても分割禁止が働くようです。人名のリストなど、長すぎることはないと分かっているから見栄え上改行を禁止したい、という場合があるのだろうと思いますが、それは記載内容がある予想できる、個別のテンプレートで対応するべきではないかと思います。とはいえ、この問題がつづくとあとに残る弊害が出そうですので、原因の解明や長期的な方向性と当座の対応策は別に議論すべきかもしれません。この問題を回避するためと思われる、「*」を追加する編集がいくつかのテンプレートで行われています[32][33]。こういった編集はあとで戻す必要がありそうです。 --whym（会話） 2018年7月21日 (土) 00:14 (UTC)[返信]
なるほど。日本語の改行については、Navboxでわざわざ項目単位でnowrapで区切っていたテンプレートが少なからず見受けられたので、hlistのnowrapもそういう目的なのだと思っていました。また、Wikipedia:バグの報告#エピソードリストでスタッフ名が改行されないで、hlistの各要素に空白を入れるという対応策も出ているようです。個人的には、上で提案した方法に限らず、改行に関する問題を改善できればいいと思います。--MawaruNeko（会話） 2018年7月22日 (日) 12:21 (UTC)[返信]
hlistの区切り文字末尾に空白が挿入されないのは明白なバグなので、改行云々関係なく修正されるべきだと思います。なお、inline-blockに修正するとNavbox関係の表示が乱れるようです。--新幹線（会話） 2018年7月23日 (月) 01:31 (UTC)[返信]
表示が乱れるということならinline-blockはやめたほうがよさそうですね。手元でテストした際は問題なさそうに見えたのですが、どのページで乱れましたか？（ブラウザも教えていただけるとありがたいです）--MawaruNeko（会話） 2018年7月23日 (月) 13:33 (UTC)[返信]
Template:一ツ橋グループを閲覧すると表示が乱れます。ブラウザはGoogle Chromeです。--新幹線（会話） 2018年7月26日 (木) 11:27 (UTC)[返信]
なるほど、リストに入れ子がある場合は、レイアウトの構造が変わるので、全く違う表示になってしまいますね。しかし現状でもTemplate:一ツ橋グループのリストは横に並んでいないので、入れ子のあるリストはhlistの想定した使い方なのでしょうか…--MawaruNeko（会話） 2018年7月26日 (木) 13:52 (UTC)[返信]
コメント MediaWiki:Common.cssの「Display nested lists inline and allow them to wrap」「Add parentheses around nested lists」の部分が入れ子のためのスタイルです。改行の不具合と同時期から表示が崩れていますが、本来はen:Template:Appleのように表示されるはずです。--XRGD（会話） 2018年7月26日 (木) 14:27 (UTC)[返信]
ありがとうございます。本来の動作はこのようになるはずだったのですね。もしinline-blockを適用した場合、入れ子になっている部分全体が改行されないので、非常に不格好になってしまいますね。--MawaruNeko（会話） 2018年7月26日 (木) 15:31 (UTC)[返信]

取り下げ inline-blockの適用は、入れ子になっている部分があると、全体が改行されないため、不適切であることがわかりましたので、取り下げさせていただきます。議論にご参加いただいた皆様ありがとうございました。現状の改行されない問題自体は残っているため、引き続きWikipedia:バグの報告#エピソードリストでスタッフ名が改行されないでの議論をお願いいたします。--MawaruNeko（会話） 2018年7月26日 (木) 15:31 (UTC)[返信]

hlist-commaの不具合について[編集]

この節は次の利用者の依頼で過去ログ化されました： （hlist関連の修正は1月に終わりました）ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

セクションに{{hlist-comma}}のリンクがありましたが、セクションリンクが上手く作動しないためリンクを除去しています。--アルトクール（会話） 2018年8月26日 (日) 08:39 (UTC)[返信]

ようこそ実力至上主義の教室へ#各話リスト、フルメタル・パニック!#各話リスト（IV）など、{{hlist-comma}}を使用している箇所で、以前は正常に行われていた改行が、行われていなくなり表示が乱れている事に気が付きました。 これは不具合なのでしょうか？あるいは仕様変更などにより、使用方法が変更されたのでしょうか？ ご存知の方は、ご教授頂けると幸いです。 また、不具合の場合は、修正して頂けると助かります。--えのきだたもつ（会話） 2018年7月16日 (月) 08:19 (UTC)[返信]

Wikipedia:バグの報告#エピソードリストでスタッフ名が改行されないで報告済です。現在問題解決のため、上の提案がなされています。--Sazanamiya（会話） 2018年7月16日 (月) 09:47 (UTC)[返信]
コメント 返信ありがとうございました。もう報告済みだったのですね。皆様で色々と模索して頂いている様ですので、経緯を見守りたいと思います。--えのきだたもつ（会話） 2018年7月16日 (月) 13:20 (UTC)[返信]

CommonsTicker関連の廃止[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

Wikipedia:CommonsTicker関連の書式指定は廃止してもいいでしょうか。利用者:CommonsTickerは10年ほど動きがありません。影響するのは[34]などのメンテナンス目的に設置されていたページの過去版のみのように思われます。現在の大多数の閲覧者の表示に影響しない部分をここに置きつづけるのは避けたほうがいいと思います。m:User:Duesentrieb/CommonsTickerを見るかぎり、利用者:Suisuiさんが事情をご承知だったようですが、いかがでしょうか。 --whym（会話） 2018年8月13日 (月) 10:00 (UTC)[返信]

上記Wikipedia:CommonsTickerのほか、関係するのはTemplate:TickerEntry（同ページ専用のテンプレート、廃止ずみの表示あり）のみのようなので、役目を終えたものと判断し、書式指定は除去しました。 --whym（会話） 2018年8月25日 (土) 14:39 (UTC)[返信]

hlist関係の改訂提案[編集]

この節は次の利用者の依頼で過去ログ化されました： （hlist関連の修正は1月に終わりました）ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

hlist関係のスタイルシートを以下のように改訂する提案をします。Wikipedia:バグの報告#エピソードリストでスタッフ名が改行されないで報告されているバグに対処するためのものです。 

/* Generate interpuncts */
.hlist dt:after {
    content: ": ";
    white-space: normal;
}
.hlist dd:after,
.hlist li:after {
    content: " · ";
    font-weight: bold;
    white-space: normal;
}

/* 日本語版の独自仕様。-pipe と -hyphen */
.hlist-pipe dd:after,
.hlist-pipe li:after {
    content: " | ";
    font-weight: normal;
}
.hlist-hyphen dd:after,
.hlist-hyphen li:after {
    content: " - ";
    font-weight: normal;
}
.hlist-comma dd:after,
.hlist-comma li:after {
    content: "、 ";
    font-weight: normal;
}

--新幹線（会話） 2018年8月29日 (水) 07:42 (UTC)[返信]

コメント このセクション先頭で案内されているバグの報告に上がっていた内容についてはMediaWiki‐ノート:Common.css/hlist関連表示不具合 201807に転記しております。セクション読み込みをかけようと思いましたが、現状はリンクのみとさせていただきます。--アルトクール（会話） 2018年9月2日 (日) 15:54 (UTC)[返信]

PDFファイルへのリンクに付ける画像を修正する提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年3月7日 (木) 17:51 (UTC)[返信]

Wikipedia:井戸端/subj/「Template:PDFlink」のロゴマークが表示されなくなった に関連して、修正提案を出します。skin個別のCSSに「リンクの最後が.pdf で終わるもの等に画像を付ける」という記述があり、その画像が document.png となっています。英語版ではこれを Common.css で上書きしています（導入時の差分:[35]）。勿論、未対応のブラウザ(IE6等)では表示されませんが、document.png のままでは勿体無いので、日本語版でも追加して頂きたいと思います。現在の英語版の記述は以下の通りです（条件の一部は動作確認済み[36]）。 

/* Change the external link icon to an Adobe icon for all PDF files
   in browsers that support these CSS selectors, like Mozilla and Opera */
#content a[href$=".pdf"].external, 
#content a[href*=".pdf?"].external, 
#content a[href*=".pdf#"].external,
#content a[href$=".PDF"].external, 
#content a[href*=".PDF?"].external, 
#content a[href*=".PDF#"].external,
#mw_content  a[href$=".pdf"].external, 
#mw_content  a[href*=".pdf?"].external, 
#mw_content  a[href*=".pdf#"].external,
#mw_content  a[href$=".PDF"].external, 
#mw_content  a[href*=".PDF?"].external, 
#mw_content  a[href*=".PDF#"].external {
    background: 
        url("http://upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif")
        center right no-repeat;
    padding-right: 16px;
}

ご検討よろしくお願いします。--Frozen-mikan 2009年9月1日 (火) 16:33 (UTC)[返信]

10年前の提案を蒸し返すようでアレですが、PDFLinkテンプレートを使わなかった場合でもリンクアイコンを変えるべきだと思いますので、再提案したいと思います（Help:外部リンクアイコンで気づいたクチです）。10年後の今では英語版のCSSに変更がございましたので、下記の変更で提案いたします。 

/* Change the external link icon to an Adobe icon for all PDF files */
.mw-parser-output a[href$=".pdf"].external,
.mw-parser-output a[href*=".pdf?"].external,
.mw-parser-output a[href*=".pdf#"].external,
.mw-parser-output a[href$=".PDF"].external,
.mw-parser-output a[href*=".PDF?"].external,
.mw-parser-output a[href*=".PDF#"].external {
	background: url("//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif") no-repeat right;
	/* @noflip */
	padding-right: 18px;
}

特に問題がなければ1週間後に実施します。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

報告 編集しました。--ネイ（会話） 2019年3月7日 (木) 17:51 (UTC)[返信]

これらのコードを追加してください[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年3月7日 (木) 17:51 (UTC)[返信]

こんにちはこれらのコードを追加してください。それは、テンプレートのドキュメント用です 

/* For template documentation */
.template-documentation {
    clear: both;
    margin: 1em 0 0 0;
    border: 1px solid #aaa;
    background-color: #ecfcf4;
    padding: 1em;
}

90.192.240.142 2014年3月26日 (水) 17:32 (UTC)[返信]

5年前の提案で実装されなかったようですが、モジュール:Documentationで必要になりますので改めて提案します。具体的な更新内容は下記の追加です。 

/* For template documentation */
/* TemplateStyles */
.template-documentation {
	clear: both;
	margin: 1em 0 0 0;
	border: 1px solid #a2a9b1;
	background-color: #ecfcf4;
	padding: 1em;
}

特に問題がない場合、1週間後にモジュールの更新とともに編集します。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

（追記）保護編集依頼のテンプレートを除去しました。問題がございましたら差し戻して構いません。--ネイ（会話） 2019年2月24日 (日) 16:42 (UTC)[返信]
報告 編集しました。--ネイ（会話） 2019年3月7日 (木) 17:51 (UTC)[返信]

段落の字下げ[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年3月7日 (木) 10:13 (UTC)[返信]

段落の字下げをして欲しいです。 

p {
text-indent: 1em;
}

-- signed by にょろん (会話) 2016年5月22日 (日) 12:08 (UTC)[返信]

2年以上前の提案なので、現時点では失効したと考えられます。私自身はこの変更には反対なので、改めて提案もしません。そのため、一旦{{Section resolved}}をつけておきますが、ほかの方が改めて提案することは妨げません。（過去ログ化される前に再提案する場合はSection resolvedを除去していただければと思います）--ネイ（会話） 2019年3月7日 (木) 10:13 (UTC)[返信]

prettytable関連の廃止提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年3月16日 (土) 15:05 (UTC)[返信]

wikitableとprettytableの差があまりにも小さい（背景色や枠の色などがわずかに違う程度）ため、標準で搭載されているwikitableに一本化することを提案します。一例として、table.prettytableとwikitableの指定を下記に示します。

  • wikitable: background-color: #f8f9fa; color: #222; margin: 1em 0; border: 1px solid #a2a9b1; border-collapse: collapse;
  • prettytable: background: #f9f9f9; border: 1px solid #aaa; border-collapse: collapse;

現時点では標準名前空間だけで400ページ以上で使用されていますので、ボット作業依頼の提出も併せて提案します。--ネイ（会話） 2019年3月7日 (木) 17:51 (UTC)[返信]

特に反対がなかったため、合意成立とみなして、prettytableからwikitableへの置換のボット作業依頼を提出します。--ネイ（会話） 2019年3月16日 (土) 03:34 (UTC)[返信]
報告 ボット作業が完了しましたので、prettytableクラスをCommon.cssから除去しました。--ネイ（会話） 2019年3月16日 (土) 15:05 (UTC)[返信]

一部の色の更新提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年3月16日 (土) 02:29 (UTC)[返信]

メタウィキにあるm:Wiki color formatting help#WikimediaUI color palette (M82)によると、背景色に使われる浅い灰色は現在ウィキペディア日本語版で使われている#f9f9f9とは微妙に違う#f8f9faとなっています（実際にソースコードで確認できます）。また枠の色もウィキペディア日本語版で使われている#aaaとは微妙に違う#a2a9b1となっています。そのため、これらの2色を一括で置き換える（#f9f9f9を#f8f9faに、#aaaを#a2a9b1に）ことを提案します。--ネイ（会話） 2019年3月7日 (木) 17:51 (UTC)[返信]

報告 編集しました。--ネイ（会話） 2019年3月16日 (土) 02:29 (UTC)[返信]

スタイルが使用されている箇所の情報を募集[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年3月23日 (土) 14:10 (UTC)[返信]

以下の幾つかのセレクタでは、使用箇所について情報が書かれていません。現時点もしくは過去の使用状況についての情報がありましたら、教えて頂きたいです。他に用途不明のスタイルが有りましたら、列挙をお願いします。--Frozen-mikan（会話） 2012年4月1日 (日) 15:35 (UTC)[返信]

#disambig[編集]

情報 英語版では18:49, 16 April 2009 (UTC)の版で除去されました。en:Template:Disambiguationで使われていたが、14:48, 13 October 2008 (UTC)でDmboxに移行したため未使用となっていました。日本語版でもTemplate:Aimaiが2009年11月24日 (火) 07:31 (UTC)にDmbox使用に更新されたため、曖昧さ回避では使われなくなりました。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
提案 除去を提案します。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
報告 除去しました。--ネイ（会話） 2019年3月4日 (月) 14:52 (UTC)[返信]

#spoiler[編集]

情報 en:MediaWiki talk:Common.css/Archive 5#Deprecated classesで除去されました（20:35, 24 June 2008 (UTC)の版）。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
提案 除去を提案します。--ネイ（会話） 2019年3月4日 (月) 14:52 (UTC)[返信]
報告 除去しました。--ネイ（会話） 2019年3月16日 (土) 02:29 (UTC)[返信]

.Talk-Notice[編集]

情報 en:MediaWiki talk:Common.css/Archive 5#Deprecated classesで除去されました（20:35, 24 June 2008 (UTC)の版）。Tmboxが存在しない時期に使用されたと思われます。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
提案 除去を提案します。--ネイ（会話） 2019年3月4日 (月) 14:52 (UTC)[返信]
報告 除去しました。--ネイ（会話） 2019年3月16日 (土) 02:29 (UTC)[返信]

.metadata-label[編集]

情報 英語版では2006年12月24日に.persondata-labelに改名され、09:20, 17 April 2009 (UTC)の版で除去されました。英語版の情報ではen:Template:Persondata（2016年に削除）に使用されているとのことで、日本語版のTemplate:Persondataでも確認しました。現在Template‐ノート:Persondataにて廃止を提案していますので、それが済んだらCommon.cssから除去してよいと考えます。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]
提案 Persondataが廃止されたら除去することを提案します。--ネイ（会話） 2019年3月8日 (金) 13:38 (UTC)[返信]
提案 Persondataの廃止が合意され、当該テンプレートが白紙化されましたので、ボット作業依頼によるテンプレート除去を待たずともCommon.cssから除去できると考えます。そのため、改めて除去を提案します--ネイ（会話） 2019年3月16日 (土) 02:29 (UTC)[返信]
報告 除去しました。--ネイ（会話） 2019年3月23日 (土) 14:10 (UTC)[返信]

脚注の文字サイズについて[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年4月4日 (木) 13:49 (UTC)[返信]

Help‐ノート:脚注/過去ログ2#脚注の文字サイズ統一にて、脚注の文字の大きさは統一の提案が採択されていますが、これがスタイルの指定がうまくいっていないです。コンテンツ側で文字の大きさを指定すると、視力の良い人にしか見えないので、万人向けには使い勝手が悪いです（参考：Wikipedia:アクセシビリティ）。コンテンツ側は100%にして、視力の良くない利用者がブラウザー側で文字の拡大をするというのが利用しやすさ、アクセシビリティです。Help‐ノート:脚注#脚注サイズの覚書にも説明しておきました。

統一の提案でフォントサイズ90%での統一を意図していたのが、コメントで Reset font-size という部分のスタイルの指定があるので、標準的な <references />や{{Reflist}}では、100%になっている。

{{Refbegin}}は、{{Reflist}}の引数と同じで、 出典を表示する際の列に対しての指定を行う機能です。MediaWiki:Common.cssの div.refbegin {font-size: 90%;} にかかって、これがリセットされていないのか、この場合にはフォントサイズ90%になっている。

ユーザビリティを考慮すると div.refbegin {font-size: 90%;}の除去（つまり実際のコードで ,[改行] div.refbegin の除去）が望ましいと思いますが、調査・提案などが手間ですので説明だけしておきます。--タバコはマーダー（会話） 2017年4月1日 (土) 04:32 (UTC)[返信]

提案 改めて、タバコはマーダーさんが説明した変更（div.refbegin指定の除去）を提案します。英語版などでも除去されており、合わせる形となります。--ネイ（会話） 2019年3月16日 (土) 02:27 (UTC)[返信]
報告 編集しました。--ネイ（会話） 2019年4月4日 (木) 13:49 (UTC)[返信]

infobox geography関連の追加提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年4月5日 (金) 16:11 (UTC)[返信]

現在、主に翻訳記事で使われることを想定しているTemplate:Infobox フィンランドの州など地誌記事向けのテンプレートが一部関連CSSの未導入により正常に表示できません。そのため、下記を英語版から導入することを提案します。 

/* styles for bordered infobox with merged rows */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
	border: 0;
	border-top: 1px solid #a2a9b1;
	/* @noflip */
	border-right: 1px solid #a2a9b1;
}

.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
	border: 0;
	/* @noflip */
	border-right: 1px solid #a2a9b1;
}

/* Styles for geography infoboxes, eg countries,
   country subdivisions, cities, etc.            */
.infobox.geography {
	border-collapse: collapse;
	line-height: 1.6em;
	font-size: 88%;
}

.infobox.geography  td,
.infobox.geography  th {
	border-top: 1px solid #a2a9b1;
	padding: 0.4em 0.6em 0.4em 0.6em;
}
.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
	border-top: 1px solid #a2a9b1;
	padding: 0.4em 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
	border: 0;
	padding: 0 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
	border-top: 0;
	border-bottom: 1px solid #a2a9b1;
	padding: 0 0.6em 0.4em 0.6em;
}

.infobox.geography .maptable td,
.infobox.geography .maptable th {
	border: 0;
	padding: 0;
}

不具合修正なので、直接編集してもよかったですが、これまで提起されなかったことを鑑みて、1週間コメントを募集してからにします。--ネイ（会話） 2019年3月25日 (月) 14:40 (UTC)line-heightを1.6emに、font-sizeを88%にして、より現行の表示に近くなるようにしました。--ネイ（会話） 2019年3月25日 (月) 14:54 (UTC)[返信]

（追記）少し延ばして、{{Infobox Settlement}}の更新と同時に編集するものとします。--ネイ（会話） 2019年3月25日 (月) 14:47 (UTC)[返信]
チェック 済 更新しました。--ネイ（会話） 2019年4月5日 (金) 16:11 (UTC)[返信]

userlogin関連の除去[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年4月13日 (土) 13:21 (UTC)[返信]
/* ### nowrap for some table headings ### */
label[for="wpUserEmail"],
label[for="wpNick"],
label[for="wpUserLanguage"],
label[for="wpOldpass"],
label[for="wpNewpass"],
label[for="wpRetypePass"],
#userlogin2 label,
#userloginForm label {
    white-space: nowrap
}

上記の部分ですが、現行のログインページやパスワード変更ページには見当たらず、指定する必要がなくなったものと考えられます。そのため、除去を提案いたします。--ネイ（会話） 2019年4月6日 (土) 11:47 (UTC)[返信]

報告 編集しました。--ネイ（会話） 2019年4月13日 (土) 13:21 (UTC)[返信]

medialist関連の編集[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年4月13日 (土) 13:21 (UTC)[返信]
/* Icons for medialist templates [[Template:Listen]], [[Template:Multi-listen_start]], [[Template:Video]], [[Template:Multi-video_start]] */
div.listenlist {
    background: url("//upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Gnome-speakernotes.png/30px-Gnome-speakernotes.png");
    padding-left: 40px;
}

div.videolist,
div.multivideolist {
    background: url("//upload.wikimedia.org/wikipedia/en/thumb/2/20/Tango-video-x-generic.png/40px-Tango-video-x-generic.png");
    padding-left: 50px;
}

/* Style rules for media list templates */
div.medialist {
    min-height: 50px;
    margin: 1em;
    background-position: top left;
    background-repeat: no-repeat;
}

div.medialist ul {
    list-style-type: none; 
    list-style-image: none;
    margin: 0;
}

div.medialist ul li {
    padding-bottom: 0.5em;
}

div.medialist ul li li {
    font-size: 91%;
    padding-bottom: 0;
}

上記についてですが、下記の編集を提案します。

  • videolistとmultivideolistは未使用のため除去。
  • medialistは当該テンプレートのtemplatestylesに移動済みのためCommon.cssから除去。
  • listenlistは画像をsvgに変更。具体的には英語版と合わせる形となり、下記のように変更します。
/* Icons for medialist templates [[Template:Listen]],
   [[Template:Multi-listen_start]], [[Template:Video]],
   [[Template:Multi-video_start]] */
/* TemplateStyles */
div.listenlist {
	background: url("//upload.wikimedia.org/wikipedia/commons/4/47/Sound-icon.svg") no-repeat scroll 0 0 transparent;
	background-size: 30px;
	padding-left: 40px;
}

特に反対がない場合、1週間後に編集します。--ネイ（会話） 2019年4月6日 (土) 11:47 (UTC)[返信]

報告 編集しました。--ネイ（会話） 2019年4月13日 (土) 13:21 (UTC)[返信]

IPAクラスの一部フォントの復帰提案[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年4月21日 (日) 03:54 (UTC)[返信]

Wikipedia:バグの報告#IPA, Unicodeクラスのフォントの不具合で一旦提案した内容ですが、事情により改めてこちらで提案致します。

2009年10月2日 (金) 14:29 (UTC)の版（差分）でmizusumashiさんがIPAクラスから除去されたフォントのうち、Lucida Sans UnicodeとArial Unicode MSの2つ、もしくはLucida Sans Unicodeだけを復活させることを提案します。

2009年9月23日 (水) 14:22 (UTC)の版までは、IPAクラスのフォント指定は以下のようになっていました。 

.IPA {
    font-family: 'Chrysanthi Unicode', 'Doulos SIL', 'Gentium', 'GentiumAlt', 'Code2000', 'TITUS Cyberbit Basic', 'DejaVu Sans', 'Bitstream Vera Sans', 'Bitstream Cyberbit', 'Arial Unicode MS', 'Lucida Sans Unicode', 'Hiragino Kaku Gothic Pro', 'Matrix Unicode', sans-serif;
}

しかし、Wikipedia:バグの報告#IPA, Unicodeクラスのフォントの不具合でのmizusumashiさんの検討の結果、Bitstream Vera Sans、Lucida Sans Unicodeでは1つ、TITUS Cyberbit Basic、Arial Unicode MS、Code2002では3つ、Chrysanthi Unicode、GentiumとGentiumAlt、Code2001では4つ、Bitstream Cyberbit、LastResortでは多数のIPA記号の表示に問題があることが分かりました。それらのフォントが除去された結果、現在のIPAクラスのフォント指定は以下のようになっています。 } 

.IPA {
    font-family: 'Charis SIL', 'Doulos SIL', 'DejaVu Sans', 'Code2000', 'Hiragino Kaku Gothic Pro', 'Matrix Unicode', sans-serif;
}

しかし、現在設定されているこれらの「正しく表示できる」フォントのうち、どれか1つでも最初からインストールされている、あるいは自分でインストールしているという人の割合は高くないと考えられます。従って、多くの人は、IPAクラスの場合でもデフォルトのフォントで表示されている人が多いと考えられます。

一方、Lucida Sans UnicodeはWindows2000・XP・VISTA・7に標準でインストールされているフォントであり、Arial Unicode MSはMicrosoft Office 2000・2002・2003・2007に付属するフォントです。従って、現在のWindowsとOfficeのシェアを考えると、これらのフォントが既にインストールされている人の割合は非常に高いと推定できます。そのような人では、IPAクラスの場合、MS P ゴシックに存在する記号はそのフォントで、存在しない記号はLucida Sans UnicodeかArial Unicode MSで表示されているという状態だと思われます。

そこで、Lucida Sans UnicodeとArial Unicode MSを、一番低い優先順位で追加して以下のようにすることを提案します。 

.IPA {
    font-family: 'Charis SIL', 'Doulos SIL', 'DejaVu Sans', 'Code2000', 'Hiragino Kaku Gothic Pro', 'Matrix Unicode', 'Lucida Sans Unicode', 'Arial Unicode MS', sans-serif;
}

こうすれば、全て正しく表示できるフォントを既にインストールしている人は、そのまま正しいフォントで表示されます。また、全て正しく表示できるフォントをインストールしていない人は、現時点でもMS P ゴシックにない記号がLucida Sans UnicodeやArial Unicode MSで表示されているでしょうから、今まで正しかった表示がおかしくなるということはなく、問題がある部分はそのままです。ただしフォントが統一されるので見苦しさがなくなります。従って、現在より状態が悪化する人はいないと思われます。

なお、Arial Unicode MSがインストールされている人はほとんどがWindowsユーザーであり、Lucida Sans Unicodeがインストールされていないのは考えにくいと思われること、Arial Unicode MSよりLucida Sans Unicodeのほうが表示の問題点が少ないことから、Lucida Sans Unicodeのみの追加でも構わないと考えています。約90%の人（Windowsユーザーの大部分）にデフォルトで不揃いのフォントを表示させるよりは、僅かな記号の表示に問題があっても、約90%の人にフォントが揃った状態で見てもらえるメリットのほうがずっと大きいのではないでしょうか。Lucida Sans UnicodeとArial Unicode MSでうまく表示できない記号はいずれもIPA記号の中では使用頻度が低いので、大きな問題にはならないでしょう。

その他の除去されたフォントについては、インストールしている人の割合と表示の問題点の数を考えると、復活させる必要は特にないと考えます。Enirac Sum 2010年2月3日 (水) 18:58 (UTC)[返信]

IPAの発音記号の中には、MS P ゴシックでは正常に表示されるが、Arial Unicode MSにすると正常に表示できなくなる発音記号が存在するため、Arial Unicode MSの追加は避けたほうがよいと思います。逆にWIndowsの場合メイリオだと正常に表示できる発音記号が多いため、メイリオを追加されてはいかがでしょうか。根本的な解決方法として昨今のブラウザでは埋め込みフォントに対応したものが増えてきているので発音記号にはフォント埋め込みタグの利用を使えるようにはできませんか。--122.220.1.166 2010年2月6日 (土) 19:31 (UTC)[返信]
不便なぐらいならともかく、表示に問題があっては事情を知らない読者には誤解を招きかねないのでまずいかと。代替案として、Template:ルビのようにユーザースタイルシートで対処するという方法を提案しておきます。--Kurz 2010年2月12日 (金) 10:06 (UTC)[返信]

特にこうした方がいいというわけではありませんが、とりあえずコメントします。

  • 現在、ヒラギノが指定されていますが、ヒラギノは (見た目が悪いのは置いても) /t̪/ や /r̝/ のような結合文字を正しい位置に表示してくれない問題があります。ここで話題になっているメイリオも (少なくとも Windows 7 では) 同じ問題があります。
  • Windows 7 の Lucida Sans Unicode は、硬口蓋入破音 /ʄ/ (U+0284) のグリフが誤っており、よろしくないようです。
  • Windows 7 の Tahoma はよさそうですが、XP 上では実装されていないグリフがあり、問題です。
  • Windows 7 の Microsoft Sans Serif はよさそうですが、XP 上では結合文字の表示に問題があります。

現状では、標準のフォントですべてを正しく表示させるのは難しそうです。--Pekanpe（会話） 2013年10月2日 (水) 07:39 (UTC)[返信]

上記の提案から数年経過しましたが、特に修正が行われたわけではないようです。現時点ではほとんどのブラウザがWindows XPサポートを切り捨てている状況（Internet Explorer、Mozilla Firefox、Google Chromeでサポートが打ち切られています）とWindows XPのシェアの低さ（statcounterによると、2019年3月時点で1.2%程度）からして、Windows XPで正常表示できないことを理由にTahomaとMicrosoft Sans Serifを追加しないことは（以前はともかく、現時点で）あまり適切ではないと考えます。従って、TahomaとMicrosoft Sans Serifの追加を再度提案いたします。--ネイ（会話） 2019年4月13日 (土) 13:38 (UTC)[返信]

チェック 済 特に反対がなかったため編集しました。--ネイ（会話） 2019年4月21日 (日) 03:54 (UTC)[返信]

.hiddenStructure について[編集]

この節は次の利用者の依頼で過去ログ化されました： ネイ（会話） 2019年4月24日 (水) 09:34 (UTC)[返信]

「Wikipedia:アクセシビリティ」にもありますが、.hiddenStructure を使って要素を隠す方法はテキストブラウザなどでは正しく表示されません。このようなHTML/CSSハックを用いるより、制御文を用いた方が、記述内容の明確化になって良いと思います。そろそろ、このスタイルを廃止した方が良いと思いますが、皆様はどう思われているでしょうか。（なお、MediaWikiで検索をしたところ、幸い、記事本文中では使われていないようです。また、テンプレートでは、使われているものの、ほとんどは廃止されたものであり、英語版以外から輸入されたテンプレートで使われているものが残っている程度のようです。）--Frozen-mikan（会話） 2012年4月1日 (日) 09:42 (UTC)[返信]

賛成 　以前、テンプレートからの除去作業を進めていたのですが、イタリア語版から持ち込まれたテンプレートの整理が面倒で放置していました。廃止に賛成です。--fryed-peach [会話] 2012年4月1日 (日) 11:37 (UTC)[返信]
情報 現時点で下記のテンプレートが残っています。

以上です。9件とも解決できましたら、廃止できると考えます。--ネイ（会話） 2019年2月24日 (日) 16:40 (UTC)[返信]

9件のうち4件から除去しましたので、済マークを付けました。--ネイ（会話） 2019年3月16日 (土) 03:26 (UTC)[返信]
テンプレート2件が廃止されましたので、済マークを付けました。--ネイ（会話） 2019年3月23日 (土) 15:33 (UTC)[返信]
1件から除去しましたので、済マークを付けました。--ネイ（会話） 2019年4月6日 (土) 11:19 (UTC)[返信]
1件から除去しましたので、済マークを付けました。--ネイ（会話） 2019年4月15日 (月) 16:41 (UTC)[返信]
1件から除去しましたので、済マークを付けました。これにより現時点で廃止されていないテンプレートから全て除去いたしましたので、.hiddenStructureをCommon.cssから除去することを正式に提案いたします。--ネイ（会話） 2019年4月16日 (火) 02:16 (UTC)[返信]
チェック 済 編集しました。--ネイ（会話） 2019年4月24日 (水) 09:34 (UTC)[返信]
「https://ja.wikipedia.org/w/index.php?title=MediaWiki‐ノート:Common.css/過去ログ/2019年&oldid=90095768」から取得