129
-
1 ななしのよっしん
2021/10/30(土) 09:54:32 ID: zR6zYfG0mI
お絵カキコでいいやんｗ
-
👍0👎0
-
2 ななしのよっしん
2021/10/30(土) 12:38:20 ID: UywPXaWoo1
すごいけど説明入れたいな。でも下手にいじると崩れそう
-
👍0👎0
-
3 ななしのよっしん
2021/11/16(火) 19:43:46 ID: 29j3MnxOeZ
オススメ記事おめでとうございます。大百科トップページに表示すると文章がコナミコマンドになってますね
-
👍0👎0
-
4 ななしのよっしん
2021/11/19(金) 01:13:45 ID: QbEHMFxa5i
なんか編集合戦起きかけてる？
高さ累積って別に大した問題ではない気がするんだけれど•••少なくともバグではない
自分は柄が多く見れたほうが楽しいと思う。コードもスマートだしぎみっく氏の案を支持します -
👍0👎0
-
5 無気力P
2021/11/19(金) 01:58:05 ID: WDdfjmgN6u
初版作成者です。
いろんな人のWebデザイン論が見ることができて参考になるけど
自分もぎみっく氏のデザインが好きだしなんか折衷案ないかな -
👍0👎0
-
6 ぎみっく
2021/11/19(金) 03:11:46 ID: dqXuFgJnKB
オススメ記事選出おめでとうございます。
編集にて、お騒がせしているようで申し訳なく思っています。
まず、deadbull氏が編集されたのはFireFoxにて表示倍率を130%などにした場合に表示が崩れるからだと理解しております。
これについては他のレンダリングエンジン系のブラウザと異なり、ネガティブマージン(-25pxなど)を使用した場合のfirefoxの独自の計算方法と
倍率依存で小数点以下の数値の計算方法の違いからおこることであり、
なるべく縦横マイナス方向への移動は避けるようにするのが解決策なのでdeadbull氏の編集の方向性は間違ってないと思います。
しかし、逆に縦並びで文章部分全体をネガティブマージン使って上へ引き上げてしまうとheightの指定が絶対必要になりfont-sizeなど環境で変化するheightに対応しきれなくなります。
現にdeadbull氏が編集された版ではChromeなどのフォントサイズ指定の極大(24px)では文章部分が下にはみ出してしまいます。
どちらにしろ自分が編集した版もdeadbull氏が編集された版も文章編集だけでもエディタを無効にして作業しないといけない部分が出てくるので容易には編集できなくなってしまいますが…。 -
👍0👎0
-
7 ぎみっく
2021/11/19(金) 03:34:57 ID: dqXuFgJnKB
元のソースの形を崩したくなかったので初版のをベースに編集しましたが、
deadbull氏の編集されたように表示されるレイアウトを変えずにソースの形を変えるようにして組んで
自分が編集したように左右配置の表示位置重ね合わせってのはどうでしょうか？ -
👍0👎0
-
8 ななしのよっしん
2021/11/19(金) 06:57:14 ID: U12mtF1wPw
>>3
トップページのオススメ記事の紹介文が「↓|↓|↑|↑|↓|↓|↑|↑|...」になっているのは、初版は文章が全く無かったので選者が作ったものかと。
>>5
オススメ記事選出おめでとうございます。
HTMLを丸ごと書き換えざるを得なかったことについては、当方としても大変心苦しく思っております。
パリロンシャン競馬場につていは当面修正する予定を入れていないので、そちらの修正はよろしくお願いいたします。
> 自分もぎみっく氏のデザインが好きだしなんか折衷案ないかな
好きなデザインというのが、単純に外観のことを指すのか、HTMLの書き方を指すのかによりますが、どちらの話でしょうか。当方で>>6の外観上のデザインを再現すること自体は不可能ではありません。多分。
>>6
> フォントサイズ指定の極大(24px)では文章部分が下にはみ出してしまいます。
これは事実ですが、当方が指摘しているFireFoxとSafariにてズーム倍率を120%にした時のパターンくずれと異なり、矢絣模様の記事としての意味が損なわれるほどの問題ではなく、>>6がした編集を正当化する理由として引き合いに出すのは不適切です。
フォントサイズ指定の問題について言えば、Firefoxで24px以上のフォントサイズを指定可能なので、フォントサイズを大きくすると下にはみ出る現象は根本的には不可避と考えられ、対応としては
1. フォントサイズ72pxまで対応する
2. ある程度のところで折り合いを付ける
3. フォントサイズ固定にする
のいずれかになると思われます。上下可変長に出来そうな気がしますが、まだ試せていません。
>>7 (+ >>5)
1. 矢絣模様パターンに用いるHTMLのベースは当方のもので良いということでしょうか。
2. 背景透過は画像を用いずに、当方がしたように透過風のHTMLパターンを別に作って文章部分の背景にあてるという方針でよろしいでしょうか。
3. 左右重ね合わせでどのようなメリットが出るのでしょうか。編集履歴で見ると確認できないのですが、記事になっていたときは上下方向が可変長だったのでしょうか。
-
👍0👎0
-
9 無気力P
2021/11/19(金) 10:57:51 ID: WDdfjmgN6u
ご返答ありがとうございます。
自分はHTMLにそんなにこだわりがないのと、こういったデザインは入門者に近い初心者なので
ぎみっく氏のような模様を大きく見せるレイアウトをdeadbullが作っていたたけるのでしたら問題はありません。 -
👍0👎0
-
10 deadbull
2021/11/19(金) 22:17:24 ID: U12mtF1wPw
>>9
ありがとうございます。当方がやるとしたら、概要から関連項目までは一つのブロックにすることになると思います。模様を見せるなら後方のマージンを拡張するとかかと考えていますが、やってみないことには。 -
👍0👎0
-
11 ぎみっく
2021/11/20(土) 00:19:29 ID: dqXuFgJnKB
>>8
もう一度、根本的な部分から解説させていただきますね。
■上下配置でのheightとネガティブmarginでの指定は、
大百科ではプロパティの値としてpx指定の場合、最大999.9999pxまでしか扱えない為いずれ崩壊を招きます。
これが左右配置にすべき最大の要因です。
そしてフォントサイズに関してですが、正当化云々の引き合いとかではなく
FireFoxの10％刻みの表示倍率と同様に、詳細設定をしなくても各ユーザーが使用できるサイズであるためChromeの「極大」を例に出しただけです。
それを72pxまで…とか仰るのなら
72pxに固定してテスト記事なりユーザー記事なりでdeadbull氏の方法で試してみてください。
先述のプロパティの値の上限に引っ掛かりレイアウト不可能になりますよ。
◆あと重要な点としては、ソースを含めたレイアウト全体がオススメ選出の理由になっているのに
オススメ掲載期間中にスタイルを丸々変えてしまうような編集自体がおかしくないですか？ってこと。
ですので私が編集した版では、敢えてベースを初版のスタイルに戻していたのです。
丸々スタイルシート書き換えてよいのならfloatかtable使って横並び配置にしてしまう方が
無気力P氏 及び deadbull氏の書かれたのよりもスマートですし、そうした方が容易になります。
でも「今このタイミング」でそれをするのは違うでしょ？ -
👍0👎0
-
12 ななしのよっしん
2021/11/20(土) 00:55:01 ID: kk1DHKDTsU
編集者の方々がこの記事の議論を交わしてるようだけど、レベル高すぎてさっぱりわからん通りすがりの人
でもなんかよりニコニコしてない雰囲気な気はする -
👍0👎0
-
13 無気力P
2021/11/20(土) 03:15:02 ID: WDdfjmgN6u
自分は議論とか好きですし技術を持ってる人に学びたいので大丈夫ですよ。
今来たかたは過去どんなデザインを辿って行ったかは「編集履歴を閲覧」から「閲覧」でリビジョンを見られるので
そちらを見ていただければ。
ほぼ立て逃げに近かったので自分もあまり突っ込めないのですけど -
👍0👎0
-
14 deadbull
2021/11/20(土) 09:23:14 ID: U12mtF1wPw
別件ですが、「💮」のUnicode絵文字が見えない方っていらっしゃいますか。お知らせ表示の花丸に「画像」が使われているのがずっと気になっていて、置き換えを検討したいと思っているのですが。
>>13
初版へのリンクを関連項目に入れたほうがよろしければそうします。
長くなりましたので、以降複数レスに分割して順不同でお答えいたします。
>>11
>大百科ではプロパティの値としてpx指定の場合、最大999.9999pxまでしか扱えない為いずれ崩壊を招きます。
お教え頂きありがとうございます。色々参考にさせて頂きます。確認ですが、ブロックを上下に分割、あるいは負のマージンを持つdivボックスを入れ子にしても対応不可能でしょうか。
> 詳細設定をしなくても各ユーザーが使用できるサイズであるためChromeの「極大」を例に出しただけです。
初期設定のChromeでは、フォントサイズは設定画面を開かないと変更できないと認識していますが、何か方法があるのでしょうか。
> それを72pxまで…とか仰るのなら
>>8で3通りの方針を示したうち、1.は出来ないということは理解いたしました。ご検証ありがとうございます。>>6は、フォントサイズの指定はしなかったようなので、2.のお立場であると認識いたしました。
対応すべきフォントサイズの上限を決めていただけるのであれば、ご指摘の問題は背景を下方向に拡張することで対応可能です。直ちに直すべきということでしたらそうします。
一応腹案として、入り切らない場合はスクロールバーが出るようにすることも考えてきました。例によって試せてませんが。
> floatかtable使って横並び配置にしてしまう方が
事前に一度検討していて、tableに border: none; border-collapse: collapse; border-spacing: 0px;
各下位要素に border: none; margin: 0px; padding: 0px;
するところまで試しましたが、一部セル間隙が消せませんでした。border-spacingも大百科では使えないようです。
いい方法をご存知でしたらご教示願います。
floatは、1pxでも想定とずれると端が次の段に移動してしまうリスクが怖くて使用しておりません。スマホ版だと記事幅が可変ですし。
(つづく) -
👍0👎0
-
15 deadbull
2021/11/20(土) 09:36:28 ID: U12mtF1wPw
(つづき)
>>11
>オススメ掲載期間中にスタイルを丸々変えてしまうような編集自体がおかしくないですか？ってこと。
これは確かに重要な点と思いますので、当方からも釈明させて頂きます。
>>13のお立場を突き詰めると、「環境によっては本来の状態が推定できないほどレイアウトが崩れるHTMLでも運営がオススメ記事にしたのだから、それは仕様です」ということになりますが、当方としては、「運営は不具合に気づかずにオススメ記事に選出した可能性が高い」という見解を持っています。
仮にそうであるとすると、このオススメ記事は誤ったHTMLソースパターンの推奨情報を発信し続けることになり、速やかに対処されなければなりません。この記事初版をお手本として、パリロンシャン競馬場のようなレイアウトを作成された場合、元になる座標がわからない第三者が修正するのは極めて困難だからです。
ここで>>5に相談するべきという意見もありえますが、パリロンシャン競馬場の掲示板で同様の問題を指摘したにもかかわらず、未だ対応の意思を表明いただいていないことからも、迅速な対応は望めないと判断しました。
> でも「今このタイミング」でそれをするのは違うでしょ？
>>8で申し上げた通り、オススメ記事作成者の名誉を簒奪するような結果となってしまい、この点につきましては>>5に対して大変申し訳無く思い心を痛めております。ですが、上記釈明のとおり「今このタイミング」するべきだと考えておりますので、前述の「それは仕様です」的立場からのご批判は甘んじて受ける所存です。
さてここで、>>8における>>7への回答の2.へと立ち返らせていただきますが、>>13はオススメ記事に選出されたことを論拠とされておられますが、当方が文章部分の透過背景風の背景をHTMLで実現しているのに対して、>>6は半透過「画像」を使用していらっしゃいます。
https://ch.nicov ideo.jp/ nico-nic o-pedia/ blomaga/ ar206295 1 
に記されている通り、画像を使わないのがオススメの理由なのに、一方でオススメ記事に選出されたことを根拠としつつ、他方で画像を使用なさるのは、自己矛盾があるのではと考えます。
(つづく) -
👍0👎0
-
16 deadbull
2021/11/20(土) 09:45:45 ID: U12mtF1wPw
(つづき)
>>11, >>9
長くなりましたが、以上を踏まえて当方の現時点での立ち位置を示させていただきますと、
1. >>5にはオススメ記事作成者としての名誉回復の機会が与えられるべきだと考えております。
従って、>>5が、当方が指摘した問題(透過背景の件を含む)を解決した上で、(もちろん新たなレイアウトくずれを起こさないことが前提ですが)自らの手で変更をなさるということであれば、当方の作成したHTMLを破棄することに異議はありません。
2. >>5がご自分でなさらないことが確定した場合は、>>6にお鉢を回します。ただ、初版のHTMLこそがオススメというお立場なわけですから、1.で付した条件に加えて、矢絣模様のパターンに使うHTMLは初版のものをベースにするという条件を付させて頂きます。
というか、できるんだったら>>6が編集する段階でして頂いていれば、当方も差し戻しまではしなかったかもしれません。
3. >>6ご自分でなさらない場合は、>>9のレイアウトに対する要望は当方が出来る範囲で対応させていただきますが、HTML及びブラウザの仕様や、当方との見解の相違により完全にはご要望に沿えない場合があることは予めご容赦下さい。
4. >>6がどうしても初版のレイアウトがオススメされたのだから正統だと主張を撤回なさらないのであれば、一度初版の記事に戻した上で、「当記事はブラウザによってはズーム倍率でレイアウトが崩れます。ズーム倍率をリセットして閲覧して下さい」と注意書きした上で、「粗品」の記事同様に記事のコンテンツは矢絣模様のパターンの下の無地の背景に書くのが「正しい」ことになると思います。
ですが、不具合のあるHTMLを晒し上げするような真似は当方にはとてもできません。
(ここまで。長文失礼。) -
👍0👎0
-
17 ぎみっく【このレスは議論内容とは関係ありません】
2021/11/20(土) 19:19:52 ID: dqXuFgJnKB
>>14-16 deadbull氏
『ニコニコ大百科:楽しく過ごすために』を熟読されてからご自身の発言を読み返されたらよいと思います。
ずっと我慢していたのですが、【高圧的な上から目線の発言】や【論点のすり替え】
この記事の編集コメント及びレスでもそうですが
「パリロンシャン競馬場」「粗品」など【他記事のことをこの記事の編集議論で話題に出す】など
color=red（無気力P）氏や私を個人攻撃したいがために持ち出しているとしか捉えれませんよ。
その記事のことはその記事の掲示板で解決するべきですし、おかしくないですか？
そして他記事の議論を理由にこの記事の編集を強行されたこと自体も間違ってると思います。
見た目のレイアウトもスタイルシートによるソースの大幅改定も掲示板での議論が必要な大規模な編集だと思いますが…
そして他所の話を持ち出すのであれば、こちらも話題に出しますが貴方は他の記事でも何度も同様な揉め事を繰り返されてますよね？貴方の自分の主張を押し通して異を唱える者は全員敵みたいなのはよくないと思いますよ。
私は、ちゃんと自分の非は認めたいと思います。
私がリビジョン番号2974442で行った編集も前版と比べると大規模な編集行為に当たるので先に掲示板にて、その旨をお知らせして議論するべきでした。
不快な思いをさせてしまって大変申し訳ありませんでした。 -
👍0👎0
-
18 ぎみっく
2021/11/20(土) 23:32:31 ID: dqXuFgJnKB
とりあえずfloat: left;で組む形のサンプル。
https://dic.nico video.jp /r/a/%E3 %83%86%E 3%82%B9% E3%83%88 %E8%A8%9 8%E4%BA% 8B/29751 66
deadbull氏は中途半端な表示倍率での「レイアウト崩れが…」と仰いますが、それは何度も述べている通り
10%刻みの半端な表示倍率に問題がありdeadbull氏の編集された版でもズレが発生してますよ。
これは大百科がどうとかっていう問題でもありませんのでどうしようもありません。
それより矢絣よりも調子良さそうなガスリーが気になる。 -
👍0👎0
-
19 ななしのよっしん
2021/11/20(土) 23:48:40 ID: e9IeJG5wyt
見比べましたが、2案で比べるなら、私はぎみっくさん派ですね。
現行のレイアウトはスマホ版で右にはみ出てるから、見栄え的にもSEO的にもよろしくないです（特にGoogleはそういうのにSEOが厳しくなる）。
逆にぎみっくさんのはスマホ版でも横幅がきっちり収まっていて問題ないです。
運営生放送・運営Twitterを見る限り、PCよりスマホからの閲覧が現状大半みたいですし、スマホからのレイアウトを優先すべきだと思います。
>>15では運営のオススメ選出コメントを論拠にしていますが、
＞こちらの記事は画像を使わずにHTMLの表現のみで模様が描かれています。
＞興味のある方はソースを見てみると楽しいかもしれません。
とあるように、主題は矢絣模様の表現です。
厳密に言うなら、初版の段階で<h2>や<ul>にデフォ画像が使われていますが、そこに触れていないあたり、主題は自明でしょう。
なんなら第二版の段階でオススメ記事お知らせに画像使われてます。
選出コメ・初版作成者へのリスペクト加味しても、そこまで画像の不使用に拘泥するものでもないじゃないんですかね。
deadbullさん1人だけがそこにこだわっているように見受けられます。
ソースコードも、ぎみっくさんのほうがわかりやすくてコメントアウトまで丁寧にされてますし、初版へのリスペクトもありますし、ぎみっくさん案を支持します。
>>18の
＞deadbull氏の編集された版でもズレが発生してますよ。
が事実ならなおのことです。 -
👍0👎0
-
20 deadbull
2021/11/21(日) 00:10:41 ID: U12mtF1wPw
>>17はひとまず置くとして
>>18
> deadbull氏の編集された版でもズレが発生してますよ。
具体的な発生環境(OS、ブラウザ、ズーム倍率)を教えて下さい。改めていくつかのOS、ブラウザで確認しましたが、>>18のサンプルはずれますが、当方の書いた記事でずれる環境は確認できませんでした。
なお、報告しておくと、ハードウェアによって初版のずれ方が異なるという現象を確認しました。人によって問題意識を共有頂けないことがあるのも無理からぬことかも知れません。日数がかかりそうですが引き続き検証を進めたいと思います。 -
👍0👎0
-
21 ぎみっく
2021/11/21(日) 01:51:46 ID: dqXuFgJnKB
>>19
ありがとうございます。私の方もテンプレ回避に冒頭にdisplay: none;入れといたのでSEO的にはアウトなんですけどね…。
>>20 deadbull氏
私が当初から申しているように10％刻みの表示倍率によりズレるのは小数点以下の数値が関わってくるからで
これに関しては1px単位でどんな調整しようが、全ての環境で完全な対策は不可能です。
ですので、なるべくズレが起きない・ズレが最小限になる程度のところで妥協するしかありません。
特にFireFoxは小数点以下の数値を丸めないので、小数点以下の細かなズレが重なっていってしまうのは避けられないです。そのFireFoxで10％刻み倍率表示して小数点以下の数値の出やすい環境にして「ズレるズレる」と言われても…となってしまうのです。大きくズレるのはなるべく無くした方がいいですが。
普段から1px単位とかに拘った編集してたりするのでそういう部分のズレが拡大したりするのはどういった場合に起こるかというようなことを確認したりとかばっかりしてるので…
他の記事の話題は出したくないのですが、rotate使って傾いた状態にすると特に、傾いたboxを囲う形で傾いていないboxを算出してそれを元にレンダリング計算を行うので45度傾けた正方形を並べても平方根の算出してるようなもんで小数点以下の値のズレの蓄積が大きくなります。
当方編集の「粗品」の記事も>>6で出したネガティブマージン(負の値のマージン)を使用しているので倍率によって大きく崩れますし、
deadbull氏の作られたグラフ機能でも扱ってるそれぞれの単位が小さいからマシですが、記事の色相環なんかは90％表示くらいで点線状態になったりします。
-
👍0👎0
-
22 ぎみっく
2021/11/21(日) 02:08:39 ID: dqXuFgJnKB
どこで妥協すべきか？を模索するべきなので>>7の時点で案を出しました。>>19の言われている通り左右配置にすることで、私が編集したリビジョンで既にスマホ向けの対応もしておいたのですが、そこも理解されないまま次々と議論の方向性を変えられて困惑しました。
>>15で
＞「環境によっては本来の状態が推定できないほどレイアウトが崩れるHTMLでも運営がオススメ記事にしたのだから、それは仕様です」ということになりますが、当方としては、「運営は不具合に気づかずにオススメ記事に選出した可能性が高い」という見解を持っています。
と矛先を変えられたり、他記事のことを持ち出されたので
>>17のような苦言を呈させていただきました。
要求されたので
Windows 10 Pro バージョン 20H2 FireFox 140%表示ですよ。スクショも置いときますね。縦方向にズレているのが分かると思います。
https://www.drop box.com/ s/sossnx lvzfkji7 2/yagasu ri.PNG 
個人的にはOSはあまり関係ないと思いますけどね。モニタ、ディスプレイ関係がこういう微妙なズレを生んでると思いますが。 -
👍0👎0
-
23 ぎみっく
2021/11/21(日) 05:51:55 ID: dqXuFgJnKB
ブラウザの表示倍率を変えた時にどのような現象が起きて表示がズレているか分かりやすいスクショ乗せときますね。
分かりやすいようにtable内に赤色の背景色を入れて火狐で倍率180％で表示した例です。
■中段選択部分と
左下『要素』の部分が適用しているスタイルシートです。
■右下『ボックスモデル』部分が実際にレンダリングされたサイズになります。
① https://www.drop box.com/ s/6mn2k1 0b2bd9z2 p/%E7%9F %A2table .PNG
要素で指定しているborder: 0; padding: 0; width: 24px; height: 24px; border-right: 2px solid #ffffff;となっている部分が
ボックスモデルではwidth: 23.45px; height: 24px; border-right-width: 1.65px;とされてレンダリングされています。
② https://www.drop box.com/ s/whi91k h6rrclmz v/%E7%9F %A2table 2.PNG
こちらではtopとleftに指定しているborder-widthの24pxが、それぞれ23.65pxとされています。
ちなみに倍率100％の表示ではちゃんと24pxと計算するので比較用に同じ個所の等倍表示のも載せておきますね。
https://www.drop box.com/ s/jyb1wk mpvmgwcn d/%E7%9F %A2table 3.PNG
こういった感じでズレがどんどん重なっていくので全体で見ると大きなズレとなってしまうのです。
これは大百科以外で同じようにCSS当てても同様の表示になります。赤い部分が見えているところはtdでもdivのboxでもboderの枠線でもない「隙間」になってしまうのです。
ですので0以外の数値を扱う数が多くなるネガティブマージンとかはズレ拡大を招きますよと言ってました。
そして最終的にはその小数点以下のpx位置を表示するのにどの位置に表示するのかはモニタ・ディスプレイとその設定などによって変わってきます。
そんなことより「否マナー」が横向きの矢絣模様に見えてしかたないんだが… -
👍0👎0
-
24 deadbull
2021/11/21(日) 09:16:37 ID: U12mtF1wPw
>>21
> ですので、なるべくズレが起きない・ズレが最小限になる程度のところで妥協するしかありません。
この点については同感です。程度の線引きについては意見の相違があるようです。
>>22
> Windows 10 Pro バージョン 20H2 FireFox 140%表示ですよ。
すみません。確認しようとしたのですが手元のFirefoxの倍率はどれも100->110->120->133->150(%)なのですがどうやったら140%にできるんでしょうか。
>>20の続報ですが、ハードウェアというよりWindowsのディスプレイ設定の「拡大縮小とレイアウト」の倍率に依存するみたいです。
>>18が編集するつもりのようですけど、>>13はもう改訂する意思はないということでよろしいですか。もしあるなら>>16に基づきそれを支持しますが。 -
👍0👎0
-
25 ぎみっく
2021/11/21(日) 18:50:39 ID: dqXuFgJnKB
おさらいさせていただきますね。
■まず表示のデザインに関して。■
>>4氏、>>19氏、そしてデザインを考えてレイアウトし初版作成された無気力P氏も含めて模様の表示(レイアウト)に関し
上下端の処理の仕方、全体の表示する縦のサイズなど、deadbull氏が差し戻された版よりも私が編集した版の方がいいと…これは初版の表示レイアウト形式の方がよいとのお考えだと思います。
私も矢絣模様の反物なども含めて全体的にドーンと連なる矢が並ぶイメージの方がインパクトあるなと感じたので
初版のレイアウトをベースにさせて編集させていただきました。
deadbull氏は「当方で>>6の外観上のデザインを再現すること自体は不可能ではありません。多分。」と言っているのにそれに対してはテスト記事で表示するなどの形で実行もされず>>14-16のような発言をされています。
全体的な見え方も含めてのオススメ記事なので、この部分に対し変更されたdeadbull氏が早急に対応するべきでした。
>>24の時点ではdeadbull氏は現状の版から一切変更する気は無いとみてとれますがその方針が甚だ疑問です。 -
👍0👎0
-
26 ぎみっく
2021/11/21(日) 19:51:56 ID: dqXuFgJnKB
■記事ソースのスタイルシートに関して■
これはずっと堂々巡りしている感じがしますが、ネガティブマージンを使用しての上下配置の限界については理解していただけましたでしょうか？
これについては今後、他の編集者に追記される場合も含めて少しでも編集しやすくする為にも
文章を表示する範囲のheightをpx値で指定しなきゃならなくなるなどの編集しにくさを回避する意味合いもあります。
そもそも上下配置の限界で今の文章量の倍程度の記述で追記できなくなります。
私の編集のリビジョン番号2974442では左右配置にすることでその部分も含めて追記する編集者がheightなどをいじらなくても済むようにしていますし、最下部コメントアウトのテンプレ部分をコピペするだけで
多くの編集者が不慣れであろうエディタ無効状態での項目追加にも考慮してあります。
そして固執して何度も噛みつかれていましたが
真意を理解されていなかったので、回答せずにいた画像(半透過お絵カキコ)の使用ですが、
このテンプレ部分を簡素にするためです。
今後の記事の発展を考慮すると複雑にならざるを得ない状態でテンプレ用意しても無意味ですし。
ついでなので言いますが
PC版TOPで表示される「|↓|↓|↑|↑|↓|↓|↑|↑|」は初版にもあるコメントアウト部分から引用されたのだと思いますよ。
そういったコメントアウトとかの部分も含めて選出だと思いますし。 -
👍0👎0
-
27 ぎみっく【雑談】
2021/11/21(日) 20:30:24 ID: dqXuFgJnKB
私は要求に応えてテスト記事にサンプル書いたり、スクショまで用意して説明したりしてますが、
deadbull氏は「試せてません」とか「再現すること自体は不可能ではありません。多分。」と発言するだけで
結局それを具体的に提示することは全くされていませんよね？
それでいて>>16のように記事編集の主導権は自身が握っていて、
初版作成された無気力P氏に対し「入門者に近い初心者なので」と発言されているのに無理難題を吹っ掛けるような姿勢での発言をされるのが理解できません。
あと、すっごく初歩的なんですけど表示倍率操作は
「Ctrl」＋「＋」または「Ctrl」＋「；」もしくは「Ctrl」＋マウスホイール「上」です。
縮小は逆にそれぞれ「マイナス」「ー」「下」です。macはcommandでしたっけ？ -
👍0👎0
-
28 ななしのよっしん
2021/11/21(日) 22:11:19 ID: Q6z7rc3UXK
横から失礼します。
手元のWindows 11 Home 21H2/Firefox 94にて、「Ctrl+"+"」およびハンバーガーメニュー＞「ズーム」で表示倍率を指定したところ、>>24の方の仰るとおり100%→110%→120%→133%→150%と推移しました。
下記の設定値変更や拡張機能なしに素のFirefoxで140%表示ができるというのであれば、Firefoxのバージョンを教えていただいてもよろしいでしょうか。
なお、140%表示自体はabout:config→toolkit.zoomManager.zoomValuesの値に「1.4」を追加することで可能です。
加えて設定＞一般＞ズーム＞「文字サイズのみ変更」のチェックを外すことで、手元のFirefoxでも>>22のスクリーンショットの現象が再現できました。
またモニタとブラウザの兼ね合いを確認するため、手元のディスプレイをスケーリング200%設定に変更し、上記設定値に「0.7」を追加して（Firefox上で）70%×（Windows上で）200%＝（実質）140%とすることでも現象を再現できました。 -
👍0👎0
-
29 ななしのよっしん
2021/11/21(日) 22:38:40 ID: e9IeJG5wyt
>>28
ctrlとマウスホイール操作で表示できますよ。
ところで、PCの特定ブラウザの特定倍率で起きる不具合（どちらの案でも軽微なズレが出てきてしまうもの）よりも、
スマホ全般で見栄えが悪くなる不具合の方が重大だと思うんですが、
deadbullさんはそれを解消する気はあるのでしょうか？
ここのところのレスを見る限りあまり編集そのものに意欲的でないですし、
ぎみっくさん案のならテスト記事で挙動確認取れてますし、
なおのことぎみっくさん案の方がいいと思うんですが。 -
👍0👎0
-
30 ななしのよっしん
2021/11/21(日) 22:47:35 ID: Q6z7rc3UXK
>>29
盲点でした。ctrl+ホイールなら素のFirefoxでも140%表示できました。ありがとうございます。
繰り返しになりますが、再現を試みる方は設定＞一般＞ズーム＞「文字サイズのみ変更」のチェックが外れていることをご確認頂ければと思います。
以下雑談：
position:absoluteで一撃だと思ったんですが、大百科だとposition指定使えないんですね……
あとはdisplay:gridとか使えれば…… -
👍0👎0
