>まとめページの方に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切ってるので良しとします。
状況がよくわからないです。 例えば以下
結果的に{{}}の間に何もないcssbox/flex_boxが大量に残り、それに比例してHTMLタグが大量に作成されます
まとめページの容量が膨れ上がると言ってるのですか。 cssやflexで記述した結果が不正に大容量で出力されるわけではないですよね。 書いたとおりに出力された結果なら仕方ないと思います。 求めてる機能はcssやflexにとって何も意味がないのではないでしょうか。 includexで活用するためにcssやflex側を対応するのは本末転倒だと思います。 includexの使い方を工夫するか、まとめページの書き方を工夫してみたらどうですか。 まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
存在しないファイルを指定するからそうなるので、未指定にすればいいです。 attachrefは添付するファイルを後から指定できる機能です。 以下のように先頭を未指定にします。リンクをクリックすれば添付できます。
&attachref(,nolink,zoom,150x150){■};
ご助言ありがとうございます。各製品/MenuBarページはそのようにすると反映されなくなったので、 MenuBarページだけをそのように適用して様子見してみようと思います。
自分でも詳しく調べてみて、こちらに記載している下記の内容と助言頂いた内容が合致して理にかなっているので、納得しました。
page=ページ名 キャッシュを区別するページ名。デフォルトではカレントページ。MenuBarなど、他のページの一部として動作するページ内に設置する場合に page=MenuBar のように設定します。
>> 2で示したWikiWiki公式の説明では
キャッシュを区別するページ名。デフォルトではカレントページ。MenuBar に設置する場合に page=MenuBar とするためのようなもの。
とあるので、カレントページに関する認識がおそらく違うのではないかと‥‥ MenuBarが常にカレントページであるならこのpage=MenuBarの説明は書かれていないでしょう。 MenuBarページ自体を開かなければ、MenuBarはカレントページにならないはずです。
少なくともWikiWiki公式からピンポイントで page=MenuBar という一例が示されている以上、指定して損は無いかと思います。
すみません、紛らわしかったようなので書きかえておきます。 &refと&attachrefで注意文が若干異なりますが、両方でそうなります。
回答ありがとうございます。ecacheプラグイン周辺の記述はどのページにおいても、ここ最近は変更していないので運営サイドのメンテナンスが行われた挙動変更によるものと考えています。
ためしがき/echcheテストによれば、
page=ページ名 キャッシュを区別するページ名。デフォルトではカレントページ。MenuBar に設置する場合に page=MenuBar とするためのようなもの。
オプション指定がない場合はecacheプラグインを置いているページのキャッシュを参照する。つまりページをまるごとecacheプラグインで囲むような場合はpage指定が不要。
とあり、各ページのecacheの対象はMenuBarページも含めてカレントページのため、特に変更せずにこれまで通りで良いと考えております。
今回のように、見るページによって編集履歴内容が違い、ひどいページだと1日以上もの更新が滞るような問題は今までに発生してきませんでした。(ecache時間指定3601秒をしているため)もし、仕様変更がなされたのであれば、運営より具体的にどのようにすべきなのかアナウンスがほしいところです。
関係しているか分かりませんが、ecacheの引数にpage指定が無いのが気になりました。 もしかするとpage指定が無いことで各ページごとにMenuBarのキャッシュが作られているのかもしれません。
https://zawazawa.jp/wikiwiki/topic/8#ecacheプラグイン こちらの説明を読む限りでは、下記のようにしてキャッシュ先にMenuBarを指定してあげる必要があります。
#ecache(reset=3601,page=MenuBar){{{
MenuBarを編集したところ、反映されるようになりました。
編集内容 #includex(others/strategy-simple-list,num=9:13,titlestr=off,firsthead=off) ↓ #includex(others/strategy-simple-list,num=8:12,titlestr=off,firsthead=off)
なぜ、各ページの表示不備が治ったのか不明です。意図せず原因不明のまま自己解決しましたが、今後も再発するおそれがあるため「解決済」タグは付けずにしておきます。
refの話ですか。タイトルのattachrefでそうなりますか。
このように書くと少しだけの空白ができます、こちらを使ってみるのはどうでしょうか
-ほげほげ ほげほげ ~ほげほげ (この上に空白ができる)
#table_editに関してトピック作成しようと思って検索したらヒットしたのでこちらに。
現在の書式では、主に以下の理由から利用しないまたはできない事があります。
上でも書かれていますが、とりあえず以下のような記述ができるだけでもかなり助かります。
#table_edit{{ 表 }}
編集の手間や敷居を下げるための書式なのに、使いづらくてそもそも利用されないのは本末転倒だと思います。
その他の要望として、#table_editの個別編集画面で表示される列の項目(表の1行目)に改行の書式「&br;」を適用しないようにしていただきたいです。 表の横幅の都合で「&br;」を利用してるだけなので、個別編集画面にも適用させて視認性を悪化させるのは避けて欲しいです。
プラグインの導入をご検討いただきありがとうございます。
表示について気になる点がありますのでご連絡いたします。
表の上段はＨ&br;Ｐというような形でbrプラグインを用い無理やり縦書きにしたもの、 下段は&tategaki{ＨＰ};というような形で本tategakiプラグインを用い縦書きにしたものです。 下段の縦書き部分が若干右寄せになっており、可能であれば修正していただきたいです。
当環境はgoogle pixel 6a/android ver.14で、ME edge 123.0.2420.61とChrome 123.0.6312.80の2つのブラウザで上記のような表示になることを確認しています。
項目の行でも2行以上の結合があっても同事象が起こります。
先頭列が上下で結合して2列目から結合していない場合
2列目まで上下で結合して3列目から結合していない場合
更に続報です。先月末リリースのEdge 121にて正式対応しました。（現在は後続の122がリリースされています） https://forest.watch.impress.co.jp/docs/news/1564032.html
残る懸念はiOS 15のみとなります。
2に付いてですが、Shift+Ctrl+Rのすべて置換についても機能していません。 上記ショートカットは、通常ではページの再読み込みに割り当てられています。 ブラウザによってはダイアログボックスによる警告がありますが、気づかず再読み込みしてしまい編集内容を消し飛ばしてしまうので、早急の修正をお願いしたいです。
問題の本質には関係ありませんが、tooltipの表示が重なってしまうことも多いので、ツールチップの表示位置を変更できるようになると助かります。
画像のように同じtooltipクラスを連続して呼び出すことで処理が正常に進んでいない可能性があります。
現時刻で再確認したところ、不具合は発生しなくなりました。運営にご対応いただけたものと思われます。
モバイル編集でも似たような手順で不具合が起きています。具体例をお伝えします。構文ハイライト (β版 ver 0.4.0)がONだと事象は発生せず、OFFで起こります。ご確認の程、よろしくお願いします。
環境 iPhoneSE3 iOS17.4(21E219) 試したブラウザ Safari Chrome Ver.123.0.6312.52
こちら改善をお願いします。問題はjavascript起因で複数回呼び出した時にonmouseoutができていないと思います。 何らかの要因で解決が難しい場合は、用語集を使わずに:hoverでシンプルに扱える代わりのtooltipプラグインが欲しいです。
私も同じ現象が起こっているので恐らくwiki側のバクかと思います。 GoogleChromeから利用しています。
ありがとうございます。
zawazawaのリクエスト広場に投稿し直しました。以降の投稿はこちらのトピックにお願いいたします。
検証どうもありがとうございます。
|~&tategaki(,upright){ﾗﾝｸ・ランク・Rank};|
|~&tategaki(upright){ﾗﾝｸ・ランク・Rank};|
改めて検証者と同じ記述で確認しましたが、第三者とは異なる結果となりました。管理しているWikiではアナリティクスによると、モバイルユーザーが8割以上(内、Android3割/iPhone7割)を占めます。可能ならば、ご対応いただきたいところです。 当環境 iPhoneSE3 Ver.17.3.1 →17.4(21E219)にアップデートして再確認済 検証ブラウザ Safari Chrome Ver.123.0.6312.52
Windows10 chrome環境下にて 次のような内容で試しましたが、そのような現象は見られませんでした…。
ただ、以下の内容では引数が正しくないため、初期値のmixed指定となり結果的に90°回転します。
>> 8の画像では引数が空なので同様にmixed指定となり、こちらも90°回転します。 改めて引数の指定が正しかったか確認してみるのはどうでしょうか。
そうなんですね。もし、技術的にできそうならば、ご対応いただけたなら幸いです。
こちらはWIKIWIKI向けのリクエスト広場なので、zawazawaに関する事柄はこちらへ投稿した方が良いかもしれません。 https://zawazawa.jp/zawazawa-request/
言い換えると、「投稿データの取り扱いについて、ユーザー側の意思をどの程度は尊重しようとする考えなのか」がわかるような情報です。その辺りを補う情報があった方が、zawazawaのことをよく知らない人、その辺のことを気にしやすい分野の人や気にされやすい内容の集まりでも、より誘いやすくなりそうです。
半端な知識ですが、フォントの方に半角カナの縦書き用フォントが用意されていないことが原因かもしれませんね。
今しがた、以前と同じく黒文字に戻っていることを確認できました。 こちらの環境によるものだったかもしれませんが、対応ありがとうございます。
Wiki利用者によって、新たな不具合が見つかりましたので、改善していただきたくお伝えいたします。
半角カナを利用すると引数を記述するしない関わらず、90度回転したままになります。こちらについても合間を見てご対応の程、よろしくお願いします。
即座にご対応いただきまして、どうもありがとうございます。表示される文字と並び替えボタンが重なり合わないことを確認させていただきました。また、Appleが修正していない不具合であることも承知いたしました。
他にも、私や他のユーザーが提案している要望についても、もし宜しければサーバーに過度の負荷が掛かると想定されないと判断した利便性のあるプラグインについては実装をご検討ください。
適切にサーバー運営していただき、いつも助かっています。今後ともご対応よろしくお願いします。
お試しありがとうございます。縦書きの表示を調整しました。 今回の調整はあくまで、よく使われそうなパターンで、Appleが修正していない不具合を誤魔化す仕様となります。(iPhoneなどApple製品のブラウザに不具合があります。) ご理解の上、使用していただけたら幸いです。
また上記でお伝えしたように、編集プレビュー画面の表示と「ページの更新」ボタンを押した後ではレスポンシブデザインの影響なのか、表示幅サイズが最適化されて実際の反映内容と異なることをお伝えいたします。正式にプラグインを実装される前にご対応をいただければ幸いです。
編集プレビュー画面 「ページの更新」ボタンを押した後
改善されるまでの間、ユーザー側でできる一時措置を施しました。一時措置前の対象ページのご確認をお願いいたします。
表組みと一緒に使われることの多いプラグインはtablesortなので、お時間ある時にご対応いただけると助かります。
セキュリティ強化などのお忙しい中、ご対応いただきまして、どうもありがとうございます。 実際に表組みにtablesortとnobrを併用しているページに&tategaki(,upright){...};と&tategaki(){...};を使用して、意図したい通りに表示できました。対象ページ
改善点があり、提案いたします。 表組みがデカいとレスポンシブデザインの影響なのか、表示幅サイズが最適化されてPC表示でもモバイル画面でも、tablesortを使用時に表示される並び替えボタンと文字が重なり合ってしまいます。作成した提案ページのように表示幅サイズ37ぐらいにして、重なり合わないように調整していただけると幸いです。 wikiwiki運営へ返信する形にするため、一度をコメント削除しました。
お試し実装です。 個別のプラグインや書式には縦書き対応しておりませんので、 レイアウトが崩れるたり表示されないことがあります。 特にブロック型とは相性が悪いのでご注意ください。
&tategaki([height][,upright|sideways|mixed]){...}; #tategaki([height][,upright|sideways|mixed]){{ ... }}
細かい仕様は忘れましたが、アドブロック(広告ブロック)系のブラウザ拡張機能が有効化されているとカウンターが正常に機能しなくなります。もし有効化されている場合は無効化して改善されるかご確認ください。
>まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
イメージつきにくい感じですかね、例えばまとめページは以下のような感じで500近いキャラがいます。（本来はflex_box間のmargin消すためにcssbox使ってるから更に入れ子になってます）
これを「図鑑順」に並べたいページと「種類・レア別(図鑑No表示は省く)」に分けたいページに使います。
で、includexで呼び出す側にflexやcss持っていくと、ていうのはまず難しいかと。抽出したデータの間に入れるとか(replace的な仕組みがあれば)、「図鑑順」「種類・レア別」用に分けたまとめページを作れば可能かもしれませんが。。。
ここまで書きましたが、#nullで試行錯誤し、なんとかまとめページ側を改良する(もちろんflex_box/cssboxはそのまま)ことで求めていた結果になったのでこの件問題なしとさせていただきます。
※改良後：HTMLデータ量＝900kbぐらい。複雑化しすぎたせいで本文コストが3000ms近いけど、ecacheのおかげか実測全体は100ms切ってるので良しとします。
状況がよくわからないです。
例えば以下
まとめページの容量が膨れ上がると言ってるのですか。
cssやflexで記述した結果が不正に大容量で出力されるわけではないですよね。
書いたとおりに出力された結果なら仕方ないと思います。
求めてる機能はcssやflexにとって何も意味がないのではないでしょうか。
includexで活用するためにcssやflex側を対応するのは本末転倒だと思います。
includexの使い方を工夫するか、まとめページの書き方を工夫してみたらどうですか。
まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
存在しないファイルを指定するからそうなるので、未指定にすればいいです。
attachrefは添付するファイルを後から指定できる機能です。
以下のように先頭を未指定にします。リンクをクリックすれば添付できます。
ご助言ありがとうございます。各製品/MenuBarページはそのようにすると反映されなくなったので、 MenuBarページだけをそのように適用して様子見してみようと思います。
自分でも詳しく調べてみて、こちらに記載している下記の内容と助言頂いた内容が合致して理にかなっているので、納得しました。
>> 2で示したWikiWiki公式の説明では
とあるので、カレントページに関する認識がおそらく違うのではないかと‥‥
MenuBarが常にカレントページであるならこのpage=MenuBarの説明は書かれていないでしょう。
MenuBarページ自体を開かなければ、MenuBarはカレントページにならないはずです。
少なくともWikiWiki公式からピンポイントで page=MenuBar という一例が示されている以上、指定して損は無いかと思います。
すみません、紛らわしかったようなので書きかえておきます。
&refと&attachrefで注意文が若干異なりますが、両方でそうなります。
回答ありがとうございます。ecacheプラグイン周辺の記述はどのページにおいても、ここ最近は変更していないので運営サイドのメンテナンスが行われた挙動変更によるものと考えています。
ためしがき/echcheテストによれば、
とあり、各ページのecacheの対象はMenuBarページも含めてカレントページのため、特に変更せずにこれまで通りで良いと考えております。
今回のように、見るページによって編集履歴内容が違い、ひどいページだと1日以上もの更新が滞るような問題は今までに発生してきませんでした。(ecache時間指定3601秒をしているため)もし、仕様変更がなされたのであれば、運営より具体的にどのようにすべきなのかアナウンスがほしいところです。
関係しているか分かりませんが、ecacheの引数にpage指定が無いのが気になりました。
もしかするとpage指定が無いことで各ページごとにMenuBarのキャッシュが作られているのかもしれません。
https://zawazawa.jp/wikiwiki/topic/8#ecacheプラグイン
こちらの説明を読む限りでは、下記のようにしてキャッシュ先にMenuBarを指定してあげる必要があります。
MenuBarを編集したところ、反映されるようになりました。
編集内容
#includex(others/strategy-simple-list,num=9:13,titlestr=off,firsthead=off)
↓
#includex(others/strategy-simple-list,num=8:12,titlestr=off,firsthead=off)
なぜ、各ページの表示不備が治ったのか不明です。意図せず原因不明のまま自己解決しましたが、今後も再発するおそれがあるため「解決済」タグは付けずにしておきます。
refの話ですか。タイトルのattachrefでそうなりますか。
このように書くと少しだけの空白ができます、こちらを使ってみるのはどうでしょうか
#table_editに関してトピック作成しようと思って検索したらヒットしたのでこちらに。
現在の書式では、主に以下の理由から利用しないまたはできない事があります。
上でも書かれていますが、とりあえず以下のような記述ができるだけでもかなり助かります。
#table_edit{{
表
}}
編集の手間や敷居を下げるための書式なのに、使いづらくてそもそも利用されないのは本末転倒だと思います。
その他の要望として、#table_editの個別編集画面で表示される列の項目(表の1行目)に改行の書式「&br;」を適用しないようにしていただきたいです。
表の横幅の都合で「&br;」を利用してるだけなので、個別編集画面にも適用させて視認性を悪化させるのは避けて欲しいです。
プラグインの導入をご検討いただきありがとうございます。
表示について気になる点がありますのでご連絡いたします。
表の上段はＨ&br;Ｐというような形でbrプラグインを用い無理やり縦書きにしたもの、
下段は&tategaki{ＨＰ};というような形で本tategakiプラグインを用い縦書きにしたものです。
下段の縦書き部分が若干右寄せになっており、可能であれば修正していただきたいです。
当環境はgoogle pixel 6a/android ver.14で、ME edge 123.0.2420.61とChrome 123.0.6312.80の2つのブラウザで上記のような表示になることを確認しています。
項目の行でも2行以上の結合があっても同事象が起こります。
先頭列が上下で結合して2列目から結合していない場合
2列目まで上下で結合して3列目から結合していない場合
更に続報です。先月末リリースのEdge 121にて正式対応しました。（現在は後続の122がリリースされています）
https://forest.watch.impress.co.jp/docs/news/1564032.html
残る懸念はiOS 15のみとなります。
2に付いてですが、Shift+Ctrl+Rのすべて置換についても機能していません。
上記ショートカットは、通常ではページの再読み込みに割り当てられています。
ブラウザによってはダイアログボックスによる警告がありますが、気づかず再読み込みしてしまい編集内容を消し飛ばしてしまうので、早急の修正をお願いしたいです。
問題の本質には関係ありませんが、tooltipの表示が重なってしまうことも多いので、ツールチップの表示位置を変更できるようになると助かります。
https://pukiwiki.sourceforge.io/?自作プラグイン/tooltip2.inc.php
画像のように同じtooltipクラスを連続して呼び出すことで処理が正常に進んでいない可能性があります。
現時刻で再確認したところ、不具合は発生しなくなりました。運営にご対応いただけたものと思われます。
モバイル編集でも似たような手順で不具合が起きています。具体例をお伝えします。構文ハイライト (β版 ver 0.4.0)がONだと事象は発生せず、OFFで起こります。ご確認の程、よろしくお願いします。
当事象を確認したパターン
環境
iPhoneSE3 iOS17.4(21E219)
試したブラウザ
Safari
Chrome Ver.123.0.6312.52
こちら改善をお願いします。問題はjavascript起因で複数回呼び出した時にonmouseoutができていないと思います。
何らかの要因で解決が難しい場合は、用語集を使わずに:hoverでシンプルに扱える代わりのtooltipプラグインが欲しいです。
私も同じ現象が起こっているので恐らくwiki側のバクかと思います。
GoogleChromeから利用しています。
ありがとうございます。
zawazawaのリクエスト広場に投稿し直しました。以降の投稿はこちらのトピックにお願いいたします。
検証どうもありがとうございます。
改めて検証者と同じ記述で確認しましたが、第三者とは異なる結果となりました。管理しているWikiではアナリティクスによると、モバイルユーザーが8割以上(内、Android3割/iPhone7割)を占めます。可能ならば、ご対応いただきたいところです。
当環境
iPhoneSE3 Ver.17.3.1
→17.4(21E219)にアップデートして再確認済
検証ブラウザ
Safari
Chrome Ver.123.0.6312.52
Windows10 chrome環境下にて
次のような内容で試しましたが、そのような現象は見られませんでした…。
ただ、以下の内容では引数が正しくないため、初期値のmixed指定となり結果的に90°回転します。
>> 8の画像では引数が空なので同様にmixed指定となり、こちらも90°回転します。
改めて引数の指定が正しかったか確認してみるのはどうでしょうか。
そうなんですね。もし、技術的にできそうならば、ご対応いただけたなら幸いです。
こちらはWIKIWIKI向けのリクエスト広場なので、zawazawaに関する事柄はこちらへ投稿した方が良いかもしれません。
https://zawazawa.jp/zawazawa-request/
言い換えると、「投稿データの取り扱いについて、ユーザー側の意思をどの程度は尊重しようとする考えなのか」がわかるような情報です。その辺りを補う情報があった方が、zawazawaのことをよく知らない人、その辺のことを気にしやすい分野の人や気にされやすい内容の集まりでも、より誘いやすくなりそうです。
半端な知識ですが、フォントの方に半角カナの縦書き用フォントが用意されていないことが原因かもしれませんね。
今しがた、以前と同じく黒文字に戻っていることを確認できました。
こちらの環境によるものだったかもしれませんが、対応ありがとうございます。
Wiki利用者によって、新たな不具合が見つかりましたので、改善していただきたくお伝えいたします。
半角カナを利用すると引数を記述するしない関わらず、90度回転したままになります。こちらについても合間を見てご対応の程、よろしくお願いします。
即座にご対応いただきまして、どうもありがとうございます。表示される文字と並び替えボタンが重なり合わないことを確認させていただきました。また、Appleが修正していない不具合であることも承知いたしました。
他にも、私や他のユーザーが提案している要望についても、もし宜しければサーバーに過度の負荷が掛かると想定されないと判断した利便性のあるプラグインについては実装をご検討ください。
適切にサーバー運営していただき、いつも助かっています。今後ともご対応よろしくお願いします。
お試しありがとうございます。縦書きの表示を調整しました。
今回の調整はあくまで、よく使われそうなパターンで、Appleが修正していない不具合を誤魔化す仕様となります。(iPhoneなどApple製品のブラウザに不具合があります。)
ご理解の上、使用していただけたら幸いです。
また上記でお伝えしたように、編集プレビュー画面の表示と「ページの更新」ボタンを押した後ではレスポンシブデザインの影響なのか、表示幅サイズが最適化されて実際の反映内容と異なることをお伝えいたします。正式にプラグインを実装される前にご対応をいただければ幸いです。
編集プレビュー画面
「ページの更新」ボタンを押した後
改善されるまでの間、ユーザー側でできる一時措置を施しました。一時措置前の対象ページのご確認をお願いいたします。
表組みと一緒に使われることの多いプラグインはtablesortなので、お時間ある時にご対応いただけると助かります。
セキュリティ強化などのお忙しい中、ご対応いただきまして、どうもありがとうございます。
実際に表組みにtablesortとnobrを併用しているページに&tategaki(,upright){...};と&tategaki(){...};を使用して、意図したい通りに表示できました。対象ページ
改善点があり、提案いたします。
表組みがデカいとレスポンシブデザインの影響なのか、表示幅サイズが最適化されてPC表示でもモバイル画面でも、tablesortを使用時に表示される並び替えボタンと文字が重なり合ってしまいます。作成した提案ページのように表示幅サイズ37ぐらいにして、重なり合わないように調整していただけると幸いです。
wikiwiki運営へ返信する形にするため、一度をコメント削除しました。
お試し実装です。
個別のプラグインや書式には縦書き対応しておりませんので、
レイアウトが崩れるたり表示されないことがあります。
特にブロック型とは相性が悪いのでご注意ください。
お試し実装です。
個別のプラグインや書式には縦書き対応しておりませんので、
レイアウトが崩れるたり表示されないことがあります。
特にブロック型とは相性が悪いのでご注意ください。
細かい仕様は忘れましたが、アドブロック(広告ブロック)系のブラウザ拡張機能が有効化されているとカウンターが正常に機能しなくなります。もし有効化されている場合は無効化して改善されるかご確認ください。