ニコニコ大百科

[画像使用] [ズレの許容範囲]は回答してるので
>>44の
[上下端]のみ

①　ただし『矢』であることが認識できるように
上端では上向きの矢は矢尻を、下向きの矢は矢羽根を末端とする。下端はその逆。


-------　以下、スタイルシート関連のまとめ　-------

小難しいこと書いてありますが考え方としては、こういうことですよ。っていうのと
補足としてオマケで完全正解のパターンも載せておきました。上から順に読んでね。
https://www.dropbox.com/sh/aar0lglkoo5pcap/AABm2RPWU2VPTNGFqp0cL6uTa

>>60
そのほうがパターン化しやすかったのでそれ以上もそれ以下もないです
ウェブデザインに慣れてる人に深読みさせてしまったのなら申し訳ないです

>>62 そもそもの根本的な部分からの質問なんですが、
丸々全面的にソースコード書き換えてしまうことに抵抗はまったくないですか？
見え方としては変わらないと思いますが、表現しようと努力されていた部分も全部台無しにするかもしれません。

それでも、「見る人を中心に考え」て変えてしまっても問題はないですか？

>>62
貴重な制作秘話をありがとうございます。

>>61までを読んで、上端を切りそろえ、下端だけ>>61のデザインにし、記事の下端は(紫の)矢の形を示すために切らなかったと本文中に明記するというのもありかと思いましたが、
1. 断端が>>61になるような使用場面は考えにくい
2. 白地の空間に細い矢が2本突き出すような部分ができて、あまり見栄えがよくない
3. 矢の形を示す目的なら、紫の矢を1本抜粋した白地背景のボックスを別に作る方が適切
と考えるので、当方は>>57から変更なしで。

>>61(解説)
詳細な解説お疲れ様です。色々勉強させて頂きます。
何か回答した方が良ければお知らせ下さい。回答不要ならこの部分への応答は不要です。

皆様ご回答ありがとうございます。
・透過画像使用は、全体的に使用可とするご意見が多いようです。
　使用する場合は背景の透明度を考慮し使用画像を変更すべきという案もありました。

・ズレに対する対応は、現実的な範囲での対応を求めるご意見が多いようです。
　
・上下端に対しては、①の意見と、②の意見と、①＋②の組み合わせで意見が分かれ、更なる議論が必要なようです。

>>57
この記事の議論当初よりその部分についても意見が分かれているのじゃないかと思っていましたので、必要かと。御覧のように分かれております。

>>64
deadbull氏にだけ向けたものではなく、こういった記事デザイン/レイアウトをするために、
スタイルシート部分を書き換えられる全ての方々へ向けたものですので回答は必要ありません。

>>63
見る人を中心に考えるなら自分は問題ないです、むしろ勉強になります

>>42
> ちなみに>>18からで言及している、縦方向のズレも出ません。
Android版のChromeで見るとデフォルト状態でも横線が入るようです。当方の確認不備についてお詫び申し上げます。
当方はこの現象を良いことだとは思っておりませんが、>>47で横線を閲覧に支障が出ないズレに分類し、異を唱えないと述べた手前、>>42のパターンについて当方の側から異は唱えるのはやめておきます。

>>67
知ってますし仕様です。何度も言及している通り、表示倍率が半端になるのでレンダリングでのリサイズで発生します。

【例】
表示幅(CSSピクセルなどと言います) 360pxの泥スマホでPC版大百科を表示した場合360pxに対し、右カラムまで含めた1045pxが100%の表示幅になります。
そして、そのうちの記事を表示する幅720pxは68.88995125...%となります。その表示幅の中で表示しているので……というお話に。
ちなみに初版もdeadbull氏が編集された版もスマホでPC版表示すると全て出ますよ。
これはboxとboxの境界線には必ず出てしまうのでそれを嫌うなら、全てのboxに>>61の最後で紹介したやつを入れてくださいっていう途方もなく面倒な話になります。

>>66
ご回答ありがとうございます。ここまで長期に渡りご迷惑お掛けしたのとは完全に別なやり方になってしまいますが、ご容赦頂けると幸いです。
なお、この方法を使っても上記のスマホでPC版を閲覧した際に出る境界部分の若干の隙間による横線は出ます。

>>67の補足させていただきますね。
FireFoxは小数点以下を丸めないと>>21で説明させていただきましたがChrome,EdgeなどのBlinkは逆に丸めるんです。

ですので、スマホの表示幅と表示するサイトの表示幅が合致している状態では丸めた数値で表示していても出ないboxの枠組みのラインが表示幅とズレると出てしまいます。

スマホ版の表示でもピンチで拡大したりすると、その丸めた値と実際の値に差が出てしまうので、この枠組みのラインは出てしまいます。

他記事の例はあまり出したくないですが、理解しやすいので出しますと
『魔理沙は大変なものを盗んでいきました』の記事をスマホでFireFoxとChrome双方で表示して
冒頭箇所の動画サムネイル画像組み合わせ部分を拡大してみるとChromeのみ画像の組み合わせ部分に
ラインが入るのが理解できると思います。

>>69をスマホのCromeから表示しているのをリモートデバッグ機能を使いPCのChromeのデベロッパツール(開発者ツール)から確認している画面のスクショです。左側がスマホ実機での表示画面のミラーリング画面です。

右端の薄字の「height　52.3047px」が計算上のheigtの値です
https://www.dropbox.com/s/urbuqoi632oaxh6/2021-11-28%20020416.png

右上の四角のboxの表示域の68×52.305の「52.305px」というのが実際に表示しているheightの値です
https://www.dropbox.com/s/tz9k6qdoarqbuaa/2021-11-28%20020441.png

この違いがこういったラインを作っています。
「68×…」の部分で割り切れてるから縦線入るのおかしくね？って感じた方もいると思いますが、
スマホの表示幅が変わらずにズームして隠れている部分も含めて全体が何％の拡大率になっているかをイメージすると分かりやすいと思います。これは今までにやりとりしていた部分と似てますね。
なので、ちょうど2倍とか4倍(200%,400%)にピッタリ拡大できればラインの出ない状態になります。

ってこんなの誰も興味ないし説明してもついてこれないじゃないですか、やだー
→→→→→→→→→→→→→→→→→→→→
←←←←←←←←←←←←←←←←←←←←
→→→→→→→→→→→→→→→→→→→→
←←←←←←←←←←←←←←←←←←←←

記事どうするかの話に戻っていい？

私の認識不足により、双方の理解度の違いを充分把握しておらずできる・できないの水掛け論など長々とレスを重ねてしまい、初版作成者 color=red（無気力P）氏、deadbull氏、そしてレスして参加下さった方々、記事を閲覧された方々

みなさまに不愉快な思いをさせてしまったことを深く反省しております。大変申し訳ございませんでした。

deadbull氏に対して>>17で 楽しく過ごすために を読み返すべきだと
自ら発言しておきながら、自分も同様の発言をしてしまっていたことをお詫び申し上げます。

とくに初版作成者のcolor=red（無気力P）氏に対しては、オススメ記事に選出された記事をこのような形で汚してしまってお詫びの申し上げようもございません。

大変ご迷惑をおかけいたしまして、申し訳ございません。

さて、このたび>>66にて無気力P氏にも再度確認させていただきご了承も頂けましたので
テスト記事リビジョン2977422
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2977422
にて初版復元の形にてborderから線形グラデーションへの置き換えによって記事表示の確認をさせていただいております。
表示では三角形のパーツになっており矢の形が形成されておりますが、四角形部分と同じ四角形の背景色が斜めに二分割されているだけの状態になるので中身としては別物になってしまいますがいかがでしょうか？

関係者各位のみなさまが、この点について問題ないと判断され、またdeadbull氏におかれましても>>16で出された条件の範囲内だと認めてくだされば、こちらの方法を取らさせていただいてもよろしいでしょうか？
※>>67-70のラインは出るかもしれませんがご容赦ください。

再度になりますが大変ご迷惑をおかけいたしまして、申し訳ございませんでした。

双方の認識不足により結果として長期化してしまったものの、ぎみっくさんはその認識の差を埋めて早期解決へ導くために誠実に対応なさっていたのでそこまで謝る必要はないように感じます。

>>71
linear-gradientを使うなら三角形と四角形に分けなくても菱形を作れるのではと思って組んでみました。この形であれば>>67-70のラインは生じないかと思います。
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2977537

懸念材料としては中身が更に別物になってしまうこと、また上下端を②にする場合に処理が面倒くさいことになりそうな点が挙げられます。特に後者は議論次第で致命的な欠点になりえますので、私の案はとりあえず叩き台程度に捉えていただければと思います。


【おまけ】
せっかくなのでlinear-gradientの限界に挑戦してみました（拡大縮小で粗が出るのはノークレームで）
https://jsfiddle.net/btnm1o0a/

菱形じゃなくて平行四辺形ですね、失礼しました（リンク先テスト記事ではちゃんと「平行四辺形」って書いてるから許してください）

>>72
ご迷惑お掛けしております。

拝見させていただきました。ありがとうございます。確かに「白／ 赤 ／白」の形にしてパーツの枠を変えてしまえば赤い部分に白い線が入ることは無いですね。
>>67-70と同じ理由で、白い■部分をmargin使用で省略してる初版とか>>71と同じ形なんですが
「iPhoneXサイズ幅でPC版表示」のようなときに白margin部分にだけ赤がはみ出してくるので
marginの白部分も全部線形グラデーションに取り込んでもいいかもしれませんね。
そしてまたどんどん別物になっていく………。

上下端②は切る位置を限定しなければ、margin使って隠せばなんとかなると思います。

「おまけ」みたいにあれこれ使えたらいいのですが…
%は整数のみ999％までとかtransparentはbackground-colorでしか使えないとか制限多すぎて、つらたん

>71
> テスト記事リビジョン2977422
こちらで表示確認中ですが、以前Android番Chromeで出ていた横線は出なくなったようです。修正ありがとうございます。しかしながら、Chromeのデフォルト設定の場合などで、斜めの線がギザギザになる場合が多々見られました。

> またdeadbull氏におかれましても>>16で出された条件の範囲内だと認めてくだされば、
ズレの問題について現時点の当方の回答としては>>47と同じですが、>>47で急いで答えて失敗しているので、本当に採用する予定の版の評価には数日お時間を頂きたいです。

>>74
> %は整数のみ999％までとかtransparentはbackground-colorでしか使えないとか制限多すぎて、つらたん
同感です。

>>75の評価を>>71に対して予定します。終了予定日は2021/12/3-2021/12/4とさせていただきます。
この予告は、他の方がズレの問題について意見を述べること、ズレの問題に依存しない件について議論を進行することを妨げません。

>>75-76
あなたの「検討」とか「評価」とか求めていませんので、必要ありませんよ。
>>72でID: Q6z7rc3UXK氏が改善提示してくださったようにフェーズは次の段階へと進んでると思います………。

そもそも記事を書き換えることに対して「評価」とかする権利が誰かひとりにあるとすれば、それは貴方ではなく初版作成者であるべきですし、記事はみんなで「良くしていく」ものです。

「良くするため」の意見ではなく否定したいがためにされているのでしたら私にも他の方々にも迷惑です。
もう2週間近く、他の方々を巻き込んでいますが「良くするため」に意見くださった方々の意見は無視したりと、「良くするため」に行動されているとは思えません。

初版作成者の無気力P氏が仰るように一番は「見る人のため」、次が「あとから編集する人のため」
そして根幹になければいけないのが>>2の「すごいけど説明入れたいな。でも下手にいじると崩れそう」と記事のデザインを考えられた「無気力P氏に対するリスペクト」です。

長期に渡りご協力ありがとうございます。

▼皆様への質問
【記事内、記述部の枠に関して】
透過画像の使用する/しない、文字可読性のための背景透過率を抜きにして、記事内の記述部分に対する処理は以下のどちらがよろしいでしょうか？
①当記事リビジョン2974442のような各部独立型
https://dic.nicovideo.jp/r/a/%E7%9F%A2%E7%B5%A3%E6%A8%A1%E6%A7%98/2974442

②テスト記事リビジョン2975858のような記述部一体型
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2975858

※参考として、②の方式で先の質問の下端カットの形式を採用した場合は、画像不使用かつエディタの有効無効を切り替えずに簡単に追記することが可能です。
①でも画像不使用自体は可能です。(エディタ無効でソース部のテンプレからコピペすることになります。)

諸事情あり離れていましたが、ここまで続いていたとは……。
改善ではなく議論を長引かせることが目的となっている節がありますし、
今後はdeadbullさんの具体的改善意見でないものについてはスルーでいいのかもしれませんね。
付き合いきれないというのが正直なところです。

>>78
好みの話で言えば、②です。
①でもいいと思いますが、見出しと記述をそれぞれで区切るよりも、
こんな感じにした方が、各部の繋がりが明確になるとは思います。
https://imgur.com/a/3D7J8VY
ソースコードがより複雑になるようだったら、やらなくて構いません。

>>79
そちらの形の方が各部が明確になり見やすいですね。

以降①は>>79で提案された形として引き続きご意見募集したいと思います。

ソースコードが複雑化することはありません。>>78で示した通り、テンプレとなるコピー元を用意しておき丸々ペーストすれば細かい部分に触れることなく追記可能な形にできます。

>>77にあるようにdeadbullさんの「評価」はこの記事において各1ユーザーの意見以上の価値を持ちませんから、誰もそれを待つ義理は無いと愚考します。早期で簡潔かつより多くの人の望む落とし所を選ぶのが最良でしょう。

【記事内、記述部の枠に関して】
>>79で示されたところの①案を支持します。
この背景では各項目が分離していた方が視認性があると感じています。

>>78
個人的には②のほうがニコ百エディタで後から編集しやすいと思います

>>78の2択であれば②ですが、>>80の2択ならまあどちらでもありえるとは思います。

>>79案で作った場合、後の編集で部分的に②になったとしてもデザインが大きく破綻するわけではないので、数ヶ月か数年経った後に暇な人が>>79案に直すくらいの悠長さでも十分許容範囲となる気はします

テスト記事リビジョン2978392
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2978392
のソースを覗いてもらえばわかりますが、各項目を分離するとしても画像使わないでこのくらいの感じなので>>84の言われるような悠長さで構わないのかなと思います。

エディタでの編集しやすやについても、各項目が既にあるところへの追記程度だったら問題なくできますし、問題がありそうなのは項目新規追加くらいになるので>>79-80案でもいいかなとも思います。

視認性の部分で、内容枠の余白と透過の度合いのサンプルを作ってみましたがいかがでしょうか？

余白についてはスマホとPC(フォントサイズによっては両方のパターンで縦並びになる)でのジレンマがあり、
透過については文字視認性と模様の視認性のジレンマがあり、模様については透過部分ではない模様の視認範囲を大きくとることで解決するかと思いますがどうでしょう？

コメントアウト手抜きしたのはごめんなさい。

>>75の「斜めの線がギザギザ」は線形グラデーションの明確な線引きで出ているので
50% 50%と明確な色の変化をさせている箇所を49% 51%などと変えると
49%から51%の範囲で赤から白、白から赤へのグラデーションが掛かるので解決します。

>>85の内容枠のtransform: rotate3d(0,0,0,0deg);はz-indexを強制的に変更するための仕掛けです。

>>76について報告します。
組み合わせ爆発の問題で完璧に出来たとは言えませんが、一通りチェックさせて頂きました。

>>71
> テスト記事リビジョン2977422
>>75で横線が消えたと申し上げましたが、元の色に戻して検証すると、Android版Chromeでの横線は残っていたようです。赤だとかなり分かりにくいですが、改めて目を凝らすと横線が残っていました。見間違いがあったことをお詫び申し上げます。
理由は確認していないのですが、>>72(2977537)だと横線は出ないようです。

>>75で指摘した以外では、33%以下のズーム倍率で矢の棒の部分が消える現象が、各種ブラウザで確認できました。
文字が読めなくなるほどの縮小であれば、細い線が消えることは避け得ない場合もあるかとは思うので、>>71(色は赤から元に戻した状態)であれば>>47と同様に対応することといたします。

ただ、>>72は>>71との比較検討に値するとは感じました。

もうホント勘弁してよ。>>71で言ってる通り>>67-70で言ってるラインは消せないよって説明してるよね？

んで>>72で出してくれた案のように元の構造自体を変えてしまえばラインは出てても見えなくなるよねっていう話も>>74までで済んでるから、貴方の遅いし頓珍漢な評価とか要らないよって言ってるじゃないですか。

＞理由は確認してないですが、
じゃなくて原因が分かっているから確認しなくても「出ますよ」って話もしてて原因が分かってるから「隠せますよ」って決着してますよ。

他の人がそれを理解して記事を良くするために話を進めてるという「理由」も理解できませんか？

>>79で言われるように目的が違うんじゃないかと感じるので、以後私はスルーさせていただきますね。

さて、話を戻しまして>>78以降の【記事内、記述部の枠に関して】ですが、
意見が半々ですので、引き続き議論していくとして

>>85で提示させていただいたリビジョンの記述部分の左右の余白、透過についてはいかがでしょうか？
スマホでの<p>タグ左右のmarginが0なため、透過の文字視認性と同様に記述枠外左右の模様と色が近くなり視認性が悪くなってしまうと思うのですが…。

>>89

marginの設定は付与した方が良いと思います
透過率は75%以上かなとは思っていますが、>>85のリビジョンでの例では一つ一つの例が小さく間隔も狭いので、錯視的な影響で検証性が下がっているような気がします