ニコニコ大百科

>>90
こんな感じの方が見やすいですかね。
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2978972
一応、不透明度65%から5%刻みで100までやってみましたが、リビジョンの方にも書いた通り素材お絵カキコ使わなければ細かなところまで攻めれます。

>>91
ありがとうございます。
私は82.5%〜85%が見やすく感じました。

75%～85%くらいですかね。文字の読みやすさだけ見れば90%にしたいけど背景も見せたいしうーん

>>46でアクセシビリティの話を出したので、WCAG 2.0に基づくコントラスト比を計算して「これ以上がマスト」という数値を提示したかったのですが、大百科標準のリンク色+標準の背景色の時点で既にAA基準不適合になってたので諦めましたorz

>>88
> もうホント勘弁してよ。>>71で言ってる通り>>67-70で言ってるラインは消せないよって説明してるよね？
>>87は>>75の見間違えを訂正するためにラインについて言及せざるを得ませんでした。

> 貴方の遅いし頓珍漢な評価とか要らないよって言ってるじゃないですか。
編集後に記事を見た人から指摘を受ける場合を考えると、検証環境を持たない人に対して不利な情報を開示せずに賛成を集めたと言われないためにも、事前に指摘は受けておいた方がよいかと思いますが…

私も両立させるには80%～85%程度の範囲じゃないかな？と思ってます。

ID: QbEHMFxa5i氏が>>53で出してくれたように透過素材お絵カキコに頼ると、限られたパターンの不透明度から選ばなくちゃいけなくなるし、任意の不透明度作ることできないし…っていうのもあったりして。

アクセシビリティに関しても>>93で言われる通りですし、文字色リンク色と模様の色の明度が近すぎる(リンク色とは明度が同一)ので、色相も近くどうしても視認性が悪くなってしまうのが…

スマホのために左右marginどうしよう？ってのも同じ理由で隣接してしまうと…って部分からです。

これは、より多くの人の目で見てもらった方が良さそうな問題かなと。
opacity使ってやっておけば後からの変更も容易になりますし、後々修正入れてもいいんじゃないかってのもあります。

>>47で当方が
>あえて異を唱えないことにします。
という言葉を用いている以上、全体からの同意を得られれば当方抜きで>>42や>>71(あるいは>>72)を元に進行が可能なはずなので、
>>88で、
> 以後私はスルーさせていただきますね。
などと宣言する必要はないはずなのですが、
>>77で
>「良くするため」の意見ではなく否定したいがためにされているのでしたら私にも他の方々にも迷惑です。
と述べているあたりからして、そのあたりが伝わっていないのかもしれないと推測するに至りました。

>>94で述べているように、編集後のクレームを想定した先回りで、必須な修正の要求ではございません(もちろん修正できるならそれに越したことはありません)。

推測が外れていたら申し訳ございません。

無視の宣言を維持しておられる方に意見するのもどうかと思いますが、動きがなさそうなのでこちらから提言させていただきます。

>>77の
> フェーズは次の段階へと進んでると思います
の具体的内容を明らかにして頂けませんでしょうか。

>>71が最終案候補だったのは取り下げられたのかどうか。
>>72が最終案候補になったのか。
>>71 >>72 を比較検討する段階なのか。
>>86による>>71の修正が最終案候補に取って代わるのか。
>>86による>>72の修正が最終案候補に取って代わるのか。
もしくは他の何かなのか。

何と応答しようとも、「フェーズ」の内容設定次第で頓珍漢であるという評価を下される恐れがあり、他の方もコメントしづらいのではないかと思います。

>>93
透過率は当方が出した話なので補足しておくと、当方の版は透過率87.5%相当のはず。
特にこだわったわけではないですが。>>93で言うと>>85%が読む妨げにならないラインかなと思うので、それほど外してもいないかと。

>>97
透過率87.5%でなく不透明度87.5%の誤りでした。透過率ベースで計算していたため逆になってしまい失礼いたしました。

他の記事でもそうですが、基本的にdeadbullさんの理解力が低く見当ハズレの言動を繰り返し、他の編集者の負担を10倍ぐらいに跳ね上げることしかしてないと思います。
他の編集者を潰したいのでしたら、私が潰されたので成功してますよ。

ここまでの流れで理解できてないならそもそも議論に参加するラインに立ててないし、いちいち流れ止めるのやめてくれない？

ここまで何度も説明していても理解できてない方が他にも居ると困るので、もう一度だけ簡単に。

>>67-70で言及している構造上どうしても出現するラインについては>>69で述べてる盗んでいきましたの記事を
AndroidのChromeで拡大してみるとわかりやすいです。
iPhoneユーザーだったりして確認できる環境のない方のためにも>>70にて実際の環境での表示例をスクショしたのと同等なものを画像で提示しております。

>>71で上記の部分については>>71では出ますよという断りも既にしてあります。それを後から文句言われる方はいないと思いますが…。不利な情報？の事前開示しているので「必要ありません」と言っています。
そもそも>>77で申しているとおり、この方法での解決を望む・望まないの決定権が誰かひとりにあるのでしたら、無気力P氏にあると思われます。

>>72でID: Q6z7rc3UXK氏が提示してくれた方法、>>74でそれに対し私が更に改良するならばと言及している方法についても、ソースコードの形として初版の形から変化する部分が大きくなるので、その部分についての判断についても同様です。

「次のフェーズ」とは、記事の余白や不透明度などなど細かな部分ではありますが記事の見た目を決定付ける大事な部分に関して、それぞれ議論を詰めていくべき箇所です。

もっと前の段階より、私は何度も他の方々へ向けて質問をさせていただきましたが、deadbull氏に腰を折られて中断してたりしますし…。

私も質問していてそんな事されるの嫌ですし、せっかく時間割いて回答して下さってる方々も「こんな質問必要ないよね」とか言われたら嫌だと思います。
そういった現在も見受けられる言動を含めて「頓珍漢」と表現させていただきました。

もう本当にこれ以上は一切無視させていただきます。

さて、話を戻しまして見え方に関しての質問へと。途中で途切れていますので…。

【記述枠内左右余白について】
テスト記事リビジョン2978392下部 https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2978392
にて表示しているように左右余白に関して「1.無し」と「2.有り」のどちらがよいでしょう？
スマホ版にて<p>タグの左右marginが0なため文字視認性がかなり異なります。

【記述枠内背景透過について】
テスト記事リビジョン2978972 https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2978972
不透明度65%から5%刻みで100%までサンプルとして表示してありますが、どのくらいがいいでしょう？それ以外でも見やすいと思う数値があればお答えください。

>>99-100氏もぜひご回答を。

自分は左右余白あり、透過率70が見やすいです

「2.有り」に一票。透過率は75%～85%くらいで変わりなしです
ブログパーツを横並びさせたいならpタグのmarginを減らせばいくらでも調節可能なので（↓の3.）、今は気にしなくて大丈夫かと思います
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2980991

私も余白あり、透過率は70%前後が見えやすいと思います。

>>102
余白は有り。文字の可読性とレイアウトのバランスを考えるなら透過率は80%～90%が好みです。
ただし、自動リンクの文字色を変更するのであれば75%ぐらいまでなら許容範囲内になります。

みなさま、ご回答ありがとうございます。
・余白は有りで一致しているようです。ID:Q6z7rc3UXK氏が>>104で提示してくださったように該当箇所だけpタグのmarginを減らす方がよいでしょうね。

・透過に関しては、人によって見え方が違ったりするので差が出ますね…
70～90の間で、全体に文字色指定をするのも視野に入れた方がよいでしょうか？

模様が見えにくくなる点については上下の透過させない部分での余白を大きくとることで模様を把握しやすくする方法もありかと思います。

PCでは横並びで表示される模様の数が多いのと、大百科全体の灰色背景(#e6e7e8)の影響もあって85%前後が見やすいのかなと。
スマホでは逆に横並び表示が少なくなることで70%くらいの方が見やすくなるんじゃないかなって思います。

全体に文字色指定する、全体を太字にする、透過部分のベースを白ではなく灰色とか補色の薄めた色にするっていう方法が考えられるんだけど、最後の色自体を変えるのは、全体的にくすんだ感じになってしまうのでやりたくないな…と。

その他の「ここは、こうした方が」というご指摘はございませんでしょうか？

テスト記事でちょっと色々表示してみたけど………斜めのギザギザそんなに気になる？
スマホで全般的にボヤけるほうが気になると思うんだけど。他の方々はどう？

https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2982841

linear-gradient対策は49.9%と50.1%くらいが好みなのですが、小数点を通してくれない大百科ぇ……
合計2%ずれるくらいならギザギザ承知で50%と50%にしたいですね、個人的には

>>110
自分も同じような感じです。といっても目視でそこまで判別つくような感じでもないし…と。

px固定サイズですし、面倒ですが%からpxに置き換えてしまえばそれぞれ加減して可能なのですが、
そうすると今度は小数点以下第四位までの制限に引っかかって24×√２×0.5の丁度50%になる値に誤差が出るのでどうしたらいいものかなと。
>>72で提示して下さったように制限なければpx単位でもいいんですけどねー。ほんと制限厳しすぎるっす。

テスト記事リビジョンで>>111で言ってるpxでの指定で試してみました。↓
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2984590

0.2pxずつ加減して合計0.4pxで49.3%と51.7%に近い数値なので合計1.4%くらいずれていることになるのですが、見え方どうでしょう？

iframeのmax-widthの話は、そもそも途切れるのを前提にする環境が320px幅の4とか5とか旧SEとかの旧世代iPhoneと、現行機種でない少数のAndroid系スマホくらいなので、考慮しなくてもいいかなと……。
現行機種とかで考慮しなきゃいけない最小360px幅だとmax-width付与しても切れる右端は余白部分だけなので問題ない範囲です。

というか320pxサイズは表示幅自体が足りなくなるのでmax-width付与しなくてもカットされるし…

>>101から当方待ちの状態ではないはずですが>>101はひとまず置いておいて、
>>94に基づき、>>75で述べた>>16の1.(>>16の2.については>>40で立ち位置を変更しているので)に合致しているかに関する評価・検討を>>112に対して行った結果をご報告いたします。

Windows版Chromeズーム倍率110%で、左から4,5,8,9,12,13列目の上から3または2本目の矢の棒の途中が途切れるようです。OS側で「拡大縮小とレイアウト」の倍率を125%以上にすると起きませんが、225%で類似の現象が起きます。
現行の記事でも軸が数ピクセルずれる現象よりは軽微ですし、本来の状態が推測できなくなるような問題ではないと考えるのは>>33, >>47で触れている通りです。

ズーム倍率33%以下で棒が消える現象は、>>112のリンク先にも記述がありますし、>>87で述べたように特に問題ではないと考えます。

>>67のような横線は確認できませんでした。
>>75で述べたキザギザの現象の出現も認められませんでした。
>>109のぼやけについては、少なくとも>>112についてはないような気がしますがよくわかりません。

検討する項目も環境も増えてきたので見落としはあるかもしれませんが、背景に関しては現行の記事の上位互換を名乗ってもよいのではと思いました(※個人の感想です)。

>>99
> 他の編集者を潰したいのでしたら、私が潰されたので成功してますよ。
分野にもよりますが、手広くやっている手前、一定の割合で衝突が発生するのは避けられないと思います。
それでも、思い出せないほど件数が多いわけではないのですが、心当たりがありません。どちら様でしょうか。

deadbullさん、別に貴方待ちではありませんので大丈夫ですよ。他の方々も含めて反応待ってるだけです。
というか、そもそもみなさんそういった些細な部分は気にされないようですが…。

＞左から4,5,8,9,12,13列目の
>>109で提示したリビジョン2982841の灰色背景部分(一段分の抜き出し)の構成を見ると理解できますが、
「↓↓↑↑」の繰り返しで一段が構成されていて、1の↓と4の↑は軸の途中部分で一段分の構成部分を切っています。
ですので、1,4,5,8,9,12,13列目は切れ目を可視化できますよ。という形でその下に黒背景部分で見えやすい表示をしてるので、他の方もそこを見て確認していただければいいかなと。

2の↓と3の↑は紫の矢羽根の▲の頂点の部分で一段分のパーツの構成を区切っているので矢柄(軸)部分も矢羽根部分も区切りのラインが見えたとしても色が変わる部分なので見えないor白色部分に白色の区切りが出るので見えない
というかたちになるので、2,3と同様の構成に変えれば出なくなります。

初版の形式を極力変えたくないので上下端を加味して初版の縦四段分を一段として構成するのに1,4の形にしましたが、変更しましょうか。


>>72でみゅありいさんが提示してくださったリビジョン2977537のように白部分をmarginで構成すると同様の条件下で横の矢の部分が左右にはみだしてくるので、それも回避しなきゃ…って話は>>74でしましたね。

ギザギザは他環境でまだ顕著に出るの認識してますし、ボヤけるのとの妥協点も微妙だったりするので悩んでたりします。


下端の処理の仕方とかも………。

って>>114で言ってるようなのは既に>>49で言ってる
＞［ズレ］
＞個人的心持ちとしては（見つけてしまってなんとかなるなら、やるしかない）
＞意見としては、ある程度でいいんじゃない？

の（見つけてしまってなんとかなるなら、やるしかない）くらいの範囲の自己満足な世界の話なので
他の方々が「このくらいでよくね？」って感じる箇所で妥協するべきなんですが、どうでしょう？

見つけてしまってるので私は自分じゃ止められないし、やろうとすればどんどん複雑になっていって加筆が困難な形になっていくので誰か止めて！た͜͜͏̘̣͔͙͎͎̘̜̫̗͍͚͓͜͜͏̘̣͔͙͎͎す͜͜͏̘̣͔͙͎͎ơ̟̤̖̗͖͇̍͋̀͆̓́͞͡け̜ͪ̅̍̅͂͊て

テスト記事 リビジョン2989025
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2989025

こんな感じで見出しアイコンやリストマーカーの画像を排除するのも可能だけど、編集しにくくなるだけだよね…

皆様より多数のご意見をいただきありがとうございます。
>>114までの範囲でズレ／画像使用／余白／不透明度などなどについて>>2を根本的な方向性と捉え本記事に反映させてあります。

>>79のような各部分の独立型についてはエディタ無効にしないと編集しにくくなるので一旦採用を見送ってます。

上下端については、意見も分かれていましたし、可変サイズで上端は別にして下端を完全な形で初版と同一の形にするのは途轍もなく複雑なことをしなきゃいけなくなるので上記の理由で不採用になってます。

>>116で触れてたりする見出しアイコンやリストマーカーの画像なんかも無くすことできるけど、編集しにくくなるだけなので導入してません。

静画などのiframeブログパーツを含めて記述量が2倍になっても背景模様が自動的に出てくるようになってるので追記されてっても暫くは大丈夫だと思いますが、一応コピペ追加用範囲指定してあります。

余白、文字色、不透明度など変更しやすいようにコメントアウト入ってますので、ご自由に変更下さい。

編集及び調整お疲れ様です。
記事が更新されたようなので見に来ましたが、良い感じになっていてGJです。
（状況分かってない人でもソースコードのスクロールバーを見た時点でこれヤバイやつだと分かりますね…）

記事更新おつかれさまでした。
長期間に及び当記事に関わっていただいたぎみっく氏及び多くの大百科ユーザ様には感謝です。

編集お疲れさまです。
細部の追求と編集しやすさや拡張性、そして初版形式の踏襲という狭間で大変だったと思いますが、白い線対策も含めて妥協点としてはほぼ100点ではないかと思います。


というわけで亀レス失礼します。
>>8>>26>>34で言及されているオススメ記事の紹介文については、deadbullさんの指摘のとおり選者が作ったものと考えて間違いないのではと思います。HTMLコメントから抜粋すると「↑↓↑↓」あるいは「- ↑↓ =- ↑↓ =」になるはずで、「|↓|↓|↑|↑|↓|↓|↑|↑|」の順番にはならないので。
（下手に刺激したくなかったのでレスを控えていました。話の蒸し返しになってしまい申し訳ない……）