リクエスト広場

cssbox,flex_box で中身が無かった場合のhtml出力フラグの要望

2 コメント
views
4 フォロー

cssbox/flex_box 大量使用しているまとめたいなページを用意し、そこからincludexで必要個所だけ抽出するように作っています
必要個所以外は抜かないようにfilterを掛けていますが、結果的に{{}}の間に何もないcssbox/flex_boxが大量に残り、それに比例してHTMLタグが大量に作成されます
そのまま出した場合だと900kb(これも多い)ですが、タグのせいでHTMLデータ量が3MBに膨れ上がってしまいます

null を活用した方法も検討したのですが、抜き出すパターンが多すぎて(30パターン以上)対応しきれず、プラグイン側の方で対応いただけないでしょうか

イメージとしては以下の感じです

#cssbox("backgound-color:#fff"){{}} → <div style="backgound-color:#fff"></div>
#cssbox("backgound-color:#fff",blankhtml=off){{}} → ※出力されない
#flex_box{{}} → <div class="flex-box" style=""><div class="flex-box-inner"></div></div>
#flex_box(blankhtml=off){{}} → ※出力されない
#flex_box(100,blankhtml=off){{}} → ※出力されない

贅沢を言えば ↓ の入れ子の場合も対応できると一番ありがたいです

#cssbox("backgound-color:#fff",blankhtml=off){{{
#flex_box(100,blankhtml=off){{
}}
}}}
→ ※出力されない
flex
作成: 2024/04/12 (金) 22:04:22
通報 ...
1
01v 2024/04/13 (土) 11:53:49

状況がよくわからないです。
例えば以下

結果的に{{}}の間に何もないcssbox/flex_boxが大量に残り、それに比例してHTMLタグが大量に作成されます

まとめページの容量が膨れ上がると言ってるのですか。
cssやflexで記述した結果が不正に大容量で出力されるわけではないですよね。
書いたとおりに出力された結果なら仕方ないと思います。
求めてる機能はcssやflexにとって何も意味がないのではないでしょうか。
includexで活用するためにcssやflex側を対応するのは本末転倒だと思います。
includexの使い方を工夫するか、まとめページの書き方を工夫してみたらどうですか。
まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。

2

>まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
イメージつきにくい感じですかね、例えばまとめページは以下のような感じで500近いキャラがいます。(本来はflex_box間のmargin消すためにcssbox使ってるから更に入れ子になってます)
これを「図鑑順」に並べたいページと「種類・レア別(図鑑No表示は省く)」に分けたいページに使います。

https://wikiwiki.jp/~~/まとめページ
#flex_container{{
#flex_box{{
|~図鑑No.001|h
|剣士★5~&ref(キャラ画像.png);~キャラ名|
}}
#flex_box{{
|~図鑑No.002|h
|剣士★4~&ref(キャラ画像.png);~キャラ名|
}}
#flex_box{{
|~図鑑No.003|h
|魔術師★5~&ref(キャラ画像.png);~キャラ名|
}}
#flex_box{{
|~図鑑No.004|h
|弓師★5~&ref(キャラ画像.png);~キャラ名|
}}
#flex_box{{
|~図鑑No.005|h
|剣士★5~&ref(キャラ画像.png);~キャラ名|
}}
:
}}}

で、includexで呼び出す側にflexやcss持っていくと、ていうのはまず難しいかと。抽出したデータの間に入れるとか(replace的な仕組みがあれば)、「図鑑順」「種類・レア別」用に分けたまとめページを作れば可能かもしれませんが。。。

ここまで書きましたが、#nullで試行錯誤し、なんとかまとめページ側を改良する(もちろんflex_box/cssboxはそのまま)ことで求めていた結果になったのでこの件問題なしとさせていただきます。
※改良後:HTMLデータ量=900kbぐらい。複雑化しすぎたせいで本文コストが3000ms近いけど、ecacheのおかげか実測全体は100ms切ってるので良しとします。

要望は具体的な提案や理由を書いて下さい。
×