ニコニコ大百科

>>28
検証ありがとうございます。スケーリングサイズとの組み合わせでも実質再現できるんですね。

表示倍率については、私も冷静さを欠いており記述を限定することを失念しておりました。お詫びいたします。
10%刻みの表示倍率変更はCtrl＋マウスホイールで動作します。

拡大だけではなく縮小も10%刻みなので検証いただいた通り実質の表示サイズを140%になるよう70%の200%表示もそちらから可能です。


大百科ユーザーに限らずライトなPCユーザーの方だとキーボードのみのショートカットキーよりも
メニューからの倍率選択かホイールショートカットになると思います。

あらら書いてる間にすでにレスされてた………

大百科だとCSS2がベースになっていて更に指定が限定されているプロパティが多く、
最近になってCSS3の一部プロパティが使用できるようになったりしましたが
基本的にインラインスタイルシート(直接記述 style="***"形式で記述)なので直接記述自体不可能なものもあり
今後の改善でCSS3全面開放みたいな事も難しいんじゃないかなと。


直接記述はブラウザ側のユーザースタイルシートに次いで優先順位が高いので
CSS2のプロパティの値ですら全面開放とかしてしまうと右カラム部分などを含めて大百科の記事ページ全体を好き放題できてしまいますし。

>>25
> この部分に対し変更されたdeadbull氏が早急に対応するべきでした。
レイアウトについては議論中であると認識しており、そちらの主張が通った内容を記事に反映するよう強要される段階にはないと考えております。もちろん、結論がまとまり、それを実施するのが当方であるということに決まったら対応します。

[ずれの問題]
>>22
> スクショも置いときますね。縦方向にズレているのが分かると思います。
軸の部分が上方向にずれていることを確認しました。チェック不備についてお詫び申し上げます。ただ、軸部分が数ピクセル離れる程度と軽微であり、矢絣模様と呼べなくなるほどのものではないと思います。

一方で、こちらで確認している限りでは、初版はカフェウォール錯視を連想させるようなずれを起こし、環境によってはそれ以外に、紫の部分が下にずれて白の部分に覆いかぶさるようなパターンになることがあります。
>>18はカフェウォール錯視風の外観に加え、軸が斜めになるのと、横に筋が入ります。ここまで来ると矢絣模様に似た何かなのではというのが当方の意見です。
もし当方と見えているずれ方が異なっていそうでしたらお知らせ下さい。

確かに当方の見落としはありましたが、当方の編集にに不備があるから、>>18の不備を許容しろというのは一種の相殺法ではないかと思います。

>>29
> スマホ全般で見栄えが悪くなる不具合の方が重大だと思うんですが、
その辺は立場が真逆の立場です。一応お知らせ表示以外の記事の文章部分については、画面幅にあうようにしてあり、記事が読めないということはないと思います。
当方としては、どの環境でもそこそこの視認性が確保されたほうが、特定の環境で著しく表示が崩れるよりは好ましいと考えております。
背景幅を固定したのはお知らせ表示が背景から突き出すからだったので、お知らせ表示を可変幅にしたら背景も可変幅にしても大丈夫かも。実証コードの請求をされると1レスあたり1日以上余計に係るのでご容赦を。

[背景透過]
>>26
> 今後の記事の発展を考慮すると複雑にならざるを得ない状態でテンプレ用意しても無意味ですし。
率直な話、今後この記事が発展すると本気で考えているなら、>>16の4.のようにして、矢絣模様のパターンのHTMLのみ修正するべきでだろうと思います。
>>25の
>全体的な見え方も含めてのオススメ記事
というのを原理主義的に推し進めるとそうなるかと。

背景透過に関する、双方の主張放棄にあたります。当方の主張は厳密には背景透過の外観実現に現行記事のごとくHTMLを使えということなので、当方の主張が通ったことにはならないと言えます。

[その他]
>>26
> ネガティブマージンを使用しての上下配置の限界については理解していただけましたでしょうか？
>>26がこのやり方がお嫌いなのは把握しました。まあ、色々勉強にはなったと思います。

> PC版TOPで表示される「|↓|↓|↑|↑|↓|↓|↑|↑|」は初版にもあるコメントアウト部分から引用されたのだと思いますよ。
そうでしたか。HTMLソースは走査したつもりでしたが、作業を急いでいたので勘違いがあったのでしょう。
ご教示頂きありがとうございました。

>>27
>「Ctrl」＋「＋」または「Ctrl」＋「；」もしくは「Ctrl」＋マウスホイール「上」です。
「Ctrl」＋「＋」と「Ctrl」＋マウスホイール「上」の動作が異なるのは盲点でした。
検索もしていたのですが、やり方が浅かったです。すみません。

deadbull氏
>>25
＞> この部分に対し変更されたdeadbull氏が早急に対応するべきでした。
＞レイアウトについては議論中であると認識しており、そちらの主張が通った内容を記事に反映するよう強要される段階にはないと考えております。もちろん、結論がまとまり、それを実施するのが当方であるということに決まったら対応します。

私は本記事に反映しろとは言ってないですよね？テスト記事などで試してして他の方にもその表示を実際に見てもらうべきだったと言ってますが？

[ズレ]
float使っても組み方変えればズレも変わりますよ。deadbull氏が組まれたように「▲」のborderと「｜」のような組み方すると同じ範囲でしかズレません。
他の方にも分かりやすいようにスクショ。別の中間の幅の狭いところで上下2段になってます。同一方向の矢を上下位置一定で並べてるので矢絣ではないですし右側は中間部と同じ理由で複雑にしています。また、分かりやすいように背景色を紫にしたのと▲｜以外の紫部分はmarginだけにしてます。紫と白を反転させれば記事でも簡素化できますし。
https://www.dropbox.com/s/oiq7u0aiynj3mfk/2021-11-22%20045135.png

ついでなので他の目的である部分として、この場合のスマホ表示も載せておきますね。記事全体の表示幅と確認したり矢毎での折れ方確認目的です。
https://www.dropbox.com/s/0btdfuktvdvtis1/2021-11-22%20045301.png
https://www.dropbox.com/s/omoyuvvk5qa1z48/2021-11-22%20045534.png

deadbullさんはスクショなりテスト記事なりで
「当方で>>6の外観上のデザインを再現すること自体は不可能ではありません。多分。」
「背景幅を固定したのはお知らせ表示が背景から突き出すからだったので、
お知らせ表示を可変幅にしたら背景も可変幅にしても大丈夫かも。」
等を実際に示さないと、これ以上議論進まないと思いますよ。口だけならなんとでも言えますし。

5W2Hを明確にして、特にいつまでに実証できるのか、簡潔にご回答お願いしますね。

>>36
＞>>26がこのやり方がお嫌いなのは把握しました。まあ、色々勉強にはなったと思います。

好き嫌いの話じゃなくて追記編集の部分に関係しています。何度も言ってますがプロパティの値が1000px以上は不可能だからです。左右配置にすればそこをクリアできます。

現状でheightが既に650pxであり1000pxなんてすぐそこです。マージンで引き上げてる分の文章部分を元の位置に戻すとわかりやすいので、またスクショ。
https://www.dropbox.com/s/e2kxujvnzwg5wmj/2021-11-22%20042732.png
https://www.dropbox.com/s/xol9k8kct7x4ono/2021-11-22%20042758.png

＞率直な話、今後この記事が発展すると本気で考えているなら、>>16の4.のようにして、矢絣模様のパターンのHTMLのみ修正するべきでだろうと思います。

追記されたり編集されたりと発展するのは本気で考えてますよ。何故なら静画iframe貼られたり、商品、動画貼られたり、と他の柄系の記事(格子柄/ヒョウ柄/牛柄)や色系の記事のように発展していくと思ってるからです。

なぜ貴方が>>16の4.とやらに固執されるのか理解できませんが？

私は別にレイアウトやスタイルシート部分の形に固執してませんよ。>>7の時点から貴方の組まれた↑↓のスタイルシート部分との折衷案を提案してますし。

私が妥協できないと言っている部分はこのレスで言及している範囲のことだけです。
そしてレイアウトしたデザインが重要なオススメ選出なのに
それを掲載期間中に大幅に書き換えてしまった貴方の行為について言及してますが

貴方こそ今までの議論の流れの中で終始
「こんなズレるのじゃダメだ」
「不具合あるのに選んだ運営も悪い」
「それを俺が全くズレない綺麗なレイアウトにしてやったんだ」
「変えるなら俺の指定したこの形じゃないと許さん」
という趣旨の発言をされて、差し戻された版に固執されているんじゃないですかね？
不具合と言われてもこういった現象は>>22-23であげたスクショのような原因で発生しますのでブラウザ自体のレンダリングに問題があり、大百科だけではなく他所でも同じ記述すれば同じように発生します。
グリッドレイアウトでもフレックスボックスでもズレは発生してますし。

訂正
>>36ではなく>>34でしたね、申し訳ないです。

>>36
私の言いたかったことを簡潔にまとめていただきありがとうございます。
どうしても無駄に文章長くなるだけなので編集向いてないですね私。

>>36
「当方で>>6の外観上のデザインを再現すること自体は不可能ではありません。多分。」は
見逃してあげて。
私の編集した版は>>37で述べたように全体のheightが1000px超えの大きさになってるから。

[皆様へのお願い]
>>8でも少し触れましたがレイアウトという単語について、以降下記の2つの用語を区別するようお願い申し上げます。もっと適切な用語をご存知の方はお知らせ下さい。
外観レイアウト: 記事上で視認できるレイアウト
HTMLレイアウト: ブロック要素の分割や配置の技法等

以下順不同になります。
>>35
> テスト記事などで試してして他の方にもその表示を実際に見てもらうべきだったと言ってますが？
7つくらい言いたいことのうち2つだけ、
6. 「対応」といっても色々な方法があるはずで、この語におっしゃるような意味を充填するのはやり過ぎではないかと思います。
7. しかし、おかげで作業手順に対する思想の相違が明らかになりました。こちらとしては、要件定義->コーディングという流れを想定しております。

要件も定義されておらず、満たしても採用される保証もない状況下で、コードを書くために時間を費やすことは、余力があれば別ですが、要件が変更された時に著しい手戻りを生じ好ましくないと考えております。
ですので>>16でいち早くこちら側の要件を明らかにし(というか編集コメントの段階から書いていましたが、)要件を満たしたら採用されることの保証を提供しました。

仮に、両者同時にコーディングして両者とも要件を満たした場合どちらのコードを採用するかという問題が発生しますが、この点では当方はコーディングしない代わりに優先権をお譲りしている次第です。(モデル的にはケーキの2等分問題に近いかなと思っています。: ツッコミ不要)
こちらが優先権を取らないのは、>>15で釈明したように、こちらの動機が記事の乗っ取りではないからと、下記のように期日をお約束できないということをおそらく許して頂けないだろうからです。

>>36
コード提供については上記のとおりです。もちろん自発的に提供することを妨げるものではありません。

> これ以上議論進まないと思いますよ。
こちらとしては、立場の確認と要件の合意を進めていく所存であります。

経験があればご理解頂けるはずなのですが、日数についてはお約束するのは難しいですね。トラブルがなければ1日で出来ますし、手元の履歴を調べてみると1pxの問題の解決に2ヶ月かかったこともありました。>>16でも期限を切っておりません。
(つづく)

(つづき)
>>37
> 私が妥協できないと言っている部分はこのレスで言及している範囲のことだけです。
「このレス」が>>37だけか、スレ内の全レスのことを指しているのか>>35以降を指しているのか明らかでありません。
少し考えたのですが絞り込めませんでした。そろそろ要件を絞り込んでいくべきということに異論はありません。

>>37
> 「不具合あるのに選んだ運営も悪い」
「悪い」の使い方に語弊がありそうなので補足しておくと、選んだ運営に過失はあると思っていますが、過失を避けることは難しかっただろうなとは思っています。

>「変えるなら俺の指定したこの形じゃないと許さん」
「この形」が外観レイアウトの話か、HTMLレイアウトの話かわからないのですが、
外観レイアウトについて>>10のように自分なりの意見は持っていますが、許さないというほどではないです。
HTMLレイアウトについては、要件さえ満たしていれば当方のコードは破棄して良いと>>16の時から申し上げています。

[要件]
[ズレの問題]
Firefoxは大百科のサポートしているブラウザであり、
モニターの高dpiと他のソフトウェアとの兼ね合いで、ブラウザにズーム倍率を
設定するユーザーを想定することは不合理ではないことから、初版や>>18などで生じる閲覧に支障が出るほどの不具合は、一部のユーザーに対する閲覧権侵害の問題と捉えております。

>>35
> float使っても組み方変えればズレも変わりますよ。deadbull氏が組まれたように「▲」のborderと「｜」のような組み方すると同じ範囲でしかズレません。
他の倍率での詳細がわからないのですが、ズレの問題について現行記事の上位互換を達成できるのであれば当方としてはそれで構いません。
>>16の2.を提示しましたし、初版のHTMLレイアウトが活かせるのであればその方がいいと考えていますが、出来ないということであれば>>16の1.でも結構ですと、立ち位置を変更します。
(つづく)

[要件続き]
[画像の使用の問題]
オススメされた理由の解釈が異なるようですが、>>15で述べたようにオススメされた理由は画像を使用しないとできなさそうなことを、(ユーザーが編集画面のHTMLで画像を指定せずに)HTMLのみで実現しているからだと思います。

そのため>>14で絵文字の使用を提案させて頂きました。

模様がオススメされたのだというご主張がありましたが、選出コメントは、記事のコンテンツがほぼ模様しかなかったからそのような文言になったと捉えております。

上記ズレの問題と比して、許さないのレベルはそこそこ低いです。

>>37
> そしてレイアウトしたデザインが重要なオススメ選出なのに
外観レイアウトか、HTMLレイアウトかいずれがオススメとして選出された理由と解釈されているのか明示して頂けますでしょうか。

[その他]
>>14で聞いて返ってきたのが>>17だったので聞きそびれたのですが改めて。
>>11
>大百科ではプロパティの値としてpx指定の場合、最大999.9999pxまでしか扱えない為いずれ崩壊を招きます。
この点、>>14で確認しようとしたように下記のような解決は考えられると思うのですがいかがでしょうか。
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2975779
下から上にずらすか、右から左にずらすかは、要件に抵触しないと思っているのでこだわりはありません。

>>11
> floatかtable使って横並び配置にしてしまう方が
本筋からそれますが、知りたいのでお尋ねすると、floatで出来るのはわかっていましたが、tableはできないのではないかと。
(ここまで。2レスに収まらなかったorz)

見た目の表示、レイアウトについては
私は、ほかの皆様にも分かりやすいよう見た目、表示、デザインといった語句を用いるか併用していますし
他のレスして下さった方々は、完全に外観だけを指しているのでは？

HTMLレイアウトと個人の造語で呼称して、それと混同されているのですか？
HTMLはレイアウト(上記、見た目の部分)するための物ではないです。それを担っているのはCSSなので「CSSレイアウト」ならば意味は通じますし、一般的に用いるならばこれです。

そして私はここの部分に関して貴方が誤解されるように他の方にも判別しにくいので、ソースやスタイルシートと言い換えをしています。


floatでもtableでもやり方次第で可能ですよ。このズレの部分についても原因が何か>>23で解説してるのでこれを回避できないのなら、対応するやり方に変えればいいだけです。
ちなみに>>18からで言及している、縦方向のズレも出ません。
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2975854

310倍でのスクショ(全体に赤背景)
https://www.dropbox.com/s/qi5rgfgeb37hxe8/yga-310red2.PNG

同じく比較として同倍率の現版リビジョン2974635 (全体に赤背景)
https://www.dropbox.com/s/7tk4ts2ehc1o80y/yga-310red1.PNG

ちなみにこれで全体を上下配置じゃなくて左右配置にした現版リビジョン2974635の
他レスで指摘されてたテンプレ部スマホ対応と下部の気になるところも変えるとこんな感じ
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2975858


deadbull氏以外の他の方でも私の言及部分についてご指摘があればお申し出下さい。

矢絣の様にすれ違ったままで歩み寄りの無い水掛け論や一方的な主張など不毛なやりとりは疲れるので。

>>7で既に左右配置との折衷案を提出し
何度も上下配置との違いを説明してきても否定され続け理解されたのに>>41でやっとですか……。
今まで否定されてたのにこだわりなくなるんですね。

>>41の記事型の表示で示した通り中身サイズに合わせて下部部分の処理も中身に合わせて容易に変えられるんですよ。

>>41で出されたように配置する意図は理解しましたが、複雑な構造になればなるほど、その都度背景部分伸ばすのに複雑な構造をいじったり数値指定したり追記しにくいと思いますが？

私が>>42で提出した記事型の表示のリビジョンですら構造は複雑ですが絶対に縦配置する為だけにこだわられてもmarginをpx数に頼ってしまっているためそうやってどんどん複雑になるだけですし、入れ子状態が複雑化してテスト記事で>>41で示した青の位置に追記していくのさえ至難の業になっていくと思うのですが。


それと例を出せって言われてるのに出せなくても、自分の主張するところの維持の為の例ならすぐ出せるんですね。出せって言われてるのそれじゃないのではないでしょうか？

▼皆様への質問
【透過画像に関して】
ID: e9IeJG5wyt氏は>>19で問題ないのではないか？と意見を下さっているのですが、
他の方々のご意見はいかがでしょうか？

deadbull氏はずっと差し戻し当初から当方への批判の言及材料にされていましたが容認されるそうです。
使用理由については>>26で説明させていただいた通りです。


【ズレに関して】
一部ユーザに対しての閲覧権の侵害だそうなので、>>42においてそこも解決する案を示させていただきました。
他方より考慮しなくてもよいと意見もありましたが
他の方々のご意見はいかがでしょうか？

>>44
透過画像についての意見は変わらず、使用しても問題ないと判断します。

ズレについては、直るに越したことはないと思います。
それに加えて、スマホ版での表示もクリア。コメントアウトもされていて比較的追記しやすく、拡張性もあります。
ぎみっくさん案支持に変わりありません。

それに何か別な問題が生じても、これまでの議論を見ていれば、検証可能性・スピード・クオリティともにぎみっくさんの方が信頼できますし。

私もぎみっくさん案を支持します。
ピクセル単位のズレは大百科の仕様変更やブラウザ側の仕様変更で今後いくらでも変わりうるので気にする必要はないと思いますが、「ズレの解消を理由とする編集にズレが発生している」のであれば話は別ですし、原因が特定できているならなおさらです。

閲覧権まで踏み込むとすると読み上げブラウザやテキストブラウザでの表示も保証する必要があります（https://ja.wikipedia.org/wiki/WP:ACCESSIBILITY）が、ニコニコ大百科の現仕様で完全に満たせるわけではないですし……

[>>39の用語に関する訂正]
>>42
> そして私はここの部分に関して貴方が誤解されるように他の方にも判別しにくいので、ソースやスタイルシートと言い換えをしています。
分かりました。以降当掲示板においてその表現にあわせるよう留意します。

[以下当方からの要件について]
>>42
> HTMLはレイアウト(上記、見た目の部分)するための物ではないです。
divボックスはこの記事のような使い方をするためのものではないので、それを言い出したらこの記事の存在理由が...。

> tableでもやり方次第で可能ですよ。
記事とは直接関係ないですが、やはり大百科内だとtableでは出来ないのではないかと思うのですが、検証済みなのか、未検証なのかだけでも教えて頂けませんでしょうか。

> ちなみに>>18からで言及している、縦方向のズレも出ません。
背景のパターンについて当方でも検討させていただきました。縦方向にはずれないものの、Firefox ズーム倍率 30%などで紫の矢に横線が入る現象が確認できました。
ズレの問題について現行記事の完全上位互換を達成しているとは認め難いですが、>>18のような閲覧に支障が出るようなズレは解消されているので、大百科においてこの程度の不具合は許容されるべきということが合意事項なのであれば、あえて異を唱えないことにします。

以下は編集意見・要望ではなく感想ですが、
1. お知らせ表示はそれ自体が黄色の外枠を持っているので、その外側にもう一つ境界を作る必要はないように思います。
2. 透過率が高いため、背景色が強く記事の文章が読みにくいです。

>>44
【透過画像に関して】
> deadbull氏はずっと差し戻し当初から当方への批判の言及材料にされていましたが容認されるそうです。
容認はしないですね。ただ、この点について編集強行されても抗議するに留めて差し戻しまではしないだろうとは思います。
(づづく)

[その他]
>>43
> 今まで否定されてたのにこだわりなくなるんですね。
>>14で確認を提示して>>17ではぐらかされて以降、この確認そのものに対する回答を頂いていなかったので、ズレの問題に影響しない全体構造における左右配置・上下配置について当方から議題にしたことはないはずなのですが。何かの誤解ではないでしょうか。

> 入れ子状態が複雑化してテスト記事で>>41で示した青の位置に追記していくのさえ至難の業になっていくと思うのですが。
メンテナンス性についての線引き問題ですが、自分の都合の良い場所に線を引けば何とでも言える問題でもあります。一方で、>>34で述べたように模様部分と記事コンテンツを分離してしまえば、通常の編集能力さえあれば編集可能なことに疑いの余地がありません。
おまけ程度ですが、オススメ記事になった初版では、テキストと模様は分離されていた(ちなみに模様はスマホ対応でもなかった)のですから、オススメ記事のレイアウトを忠実に守っているとさえ言えます。
>>37で
> なぜ貴方が>>16の4.とやらに固執されるのか理解できませんが？
とおっしゃっていますが、>>34は当方が固執しているのではなく>>26がメンテナンス性に対して、>>25が「オススメ記事のレイアウト」に対して、こだわりを見せたことに対するご提案です。

>>43
> 例を出せって言われてるのに出せなくても、自分の主張するところの維持の為の例ならすぐ出せるんですね。
申し上げているように、HTMLソースを提示しない理由は回答遅延を避けるためです。ご指摘の件のHTMLソース部分は当掲示板のレスよりもデータサイズが小さく、検証事項も単一であるため回答遅延の原因になりません。
また、不可能の旨を繰り返しておられるので、ご主張の虚偽について検証せずに議論が長期化する弊害の方が大きいと判断しました。

> 出せって言われてるのそれじゃないのではないでしょうか？
出せと言われたことへの対応として出したわけではございません。出さない理由は別途お答えいたしました。
(ここまで)

deadbullさん…人にあれこれ要求するなら自分も動くべきですよ。ご要求のtable組みですよ。
要求されたので組成したので、これについてあれこれアラ探しされても、もう知りません。
https://dic.nicovideo.jp/r/a/%E3%83%86%E3%82%B9%E3%83%88%E8%A8%98%E4%BA%8B/2976170

>>44への【私個人の自己見解】
［画像］
>>42の記事形式のテスト記事での現リビジョン2974635再現程度でよければ使わなくても…
初版の上下端の矢の形までやるなら使った方がよい。
他の方々は初版作成者も含めてその形を望んでいるので私もそれに従います。

［ズレ］
個人的心持ちとしては（見つけてしまってなんとかなるなら、やるしかない）
意見としては、ある程度でいいんじゃない？

▼皆様への質問
【記事上下のデザインに関して】
記事上端および下端の形は以下のどちらがいいでしょうか？
①初版およびリビジョン2974442の形式。
②現行差し戻しリビジョン2974635の形式。

①の初版およびリビジョン2974442の形式で。

どうみても①。

>>4で初めに意見表明した者として、議論が長く拡がっていることを申し訳なく思っています。お手数をとられている関係者各位には最大限のお詫びを申し上げます。本当にすみません。
三点について意見を表明します。

[画像]
使ってもいいという意見です。画像不使用であることが評価されているのは柄再現のみである初版時点での話ですが、それを他の項目にまで適用すべきだとまでは思いません。
コントラストによる可読性を考慮するなら、/oekaki_thumb/410207.pngや/oekaki/277233.pngなどを使うなり、文字色を濃いものにするなりすることだと思います。私は透過用画像を他の透過用画像に変更することに反対しません。

[ズレ]
意見としては、よりズレを少なく解決できるならその方を選ぶのが良いかと思います。
ただ、30%程度の倍率環境については私は極端であると考えており、極端であることを根拠にサポートの考慮からは外しても良いと思っています。

[上下端]
遊びのある方が好ましいという思想で①を支持しています。

①。

自分としては記事を見る人を中心に考えれば画像を組み込んでもいいと思っているので
①初版およびリビジョン2974442の形式。
でお願いします。

私が初版を作るならたぶん②にしていたと思いますが、①のほうが画像を使わずにHTMLで組んでいることがわかりやすいですね。

>>49
さすがに申し訳ないのでHTMLソースまでは要求しなかったのですが、ご用意頂きありがとうございます。
質問者の仁義として自分で出来るところまで試す、というのは>>14でやりました。

>>50
②
理由: ①のパターン部上下端のデザインは矢絣模様の仕様に含まれない。
読者に上下端がそのようになるパターンが矢絣模様であるというミスリードを与える。
介入までする気はありませんが、意見を募るような案件ではないように思います。

>>53での意見について[上下端]の点を少し訂正します:

上端は②、下端は①。

あそびの部分がある方が好ましいという思想は踏まえても、>>57でのご意見にも一理があると感じました。特に、1番目に読者が認識するはずの上部では遵守した方がいいのではと感じました。
一方、「柄は端から端まで徹頭徹尾統一すること」を絶対とするルールを私は寡聞にして存じておらず、下部分については①の方がしっくり来ているのもあってそちらを支持いたします。

上端を修正する案に関しては自分も異存はないです

>>55
そういえば、①の上下端のデザインは何を表現しようとしていたんでしょうか。