それは当然の動作ではないでしょうか？
0か1ではなく0.5（テキストデータだけ先行読込、HTML組立は開いたときにやる）を求めるのであれば、デフォルト動作変更は反対です。負荷軽減が薄れます。 どうしても、というのであればオプション化は反対しませんが、需要があるかは疑問符です。
素晴らしい要望です。 アンカーの名前に仮名や漢字が使えるようになって、さらにアンカーを自分で書かなかったときに自動生成される名前が見出しの名前と同じになったら、すごく便利だと思います。
これまでの意見を簡単にまとめたいと思います：
議論がある程度終わりましたので、運営からのコメントをお願いします。@wikiwiki
運営に動いてほしい という要望ということ？ であればこれ以上議論しようがないのでは？
公式のマニュアルをユーザに編集させるのは非現実的すぎるので、他の方の意見にあるように 引き続きマニュアル整備を要望し続けるか、有志で非公式プラグインマニュアルwikiを立ち上げるのが妥当かと思います。
主は「運営ができなければユーザー側で手伝いたい」とは一言も言っていないのですり替わってはいますね 自分たちでwikiを作って参加するのは>> 9の通り自由なので、ここでは>> 5のように元々あるさんぷるwikiを一般にも編集できるように要望する方がいいかと
何がすりかわったのかよくわかりませんが、マニュアルを整備してほしい→運営でできないのであればユーザが手伝います という話ですよね？
関連性があっても、話題のすり替えはあまり好ましくないです。 （木主の要望は、プラグインマニュアルの再整備・内容の充実です）
そもそも「プラグインのWikiを作る」ことは（18歳以上なら）誰にでもできますので、 運営に要望するようなことではないです。 自由に作ればいいでしょう。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
余裕がないからとかでしたら開放して有志での更新もありなのかなと思います
こちらでは、twitter_tweetプラグインが何の問題もなく使えています。 特定のポストを表示させようとしたときや、特定の他のプラグインと組み合わせて使ったときにだけ、起こる問題なのかもしれません。
具体的にどこのwikiのどのページに、どういったソースを書いて問題が起きたのかを示したほうが、対処が早くなる可能性があります。
同じ要望は過去にもありましたが、 https://zawazawa.jp/wikiwiki-request/topic/69 放置されたまま3年半近く経っていますので、 何らかの理由により、やるつもりがないのだと思われます。
csvとしてダウンロードできる機能は便利なのですが、荒らしの対応にあたっては手間が掛かるのは変わらず、ブラウザから確認できた方が親切です。 実際にあった例として、荒らし行為(似たような漢字に置き換える、URLの変更等)が発覚したあと、当日や直近数日のログから確認と復旧を行ったものの、実際は期間を空けて(数週間～)荒らし行為が行われており、復旧に時間がかかりました。このような場合、ブラウザ側で期間指定をして当該ユーザーの編集行為を絞り込めればより早く復旧できた可能性もあります。 こうした理由から、かつてのDiifnaのように一定期間は日付を跨いだ検索を実装頂きたく思います。
賛成です。マニュアルと言いつつあまりマニュアルの役目を果たしていないように思えます。>> 2さんの仰っている通りユーザー参加型の形式でもよさそうです。
賛成です。 利用しているwikiが使っているプラグインが、マニュアルを見ても載っていないことが多くてよく混乱しています。 切実にお願いします。プラグインのwikiがあったら自分も参加します。
公式Xの投稿日を見るに、こちらのトピックを受けて内容が追記されていたようですね。 https://x.com/wikiwiki_japan/status/1947539662194806924 ありがとうございました。
仕様上lazy系の中に入れた目次は表示されないようです。 https://wikiwiki.jp/pp/eco-plugins-guide (一番下のFAQに書いてあります)
賛成です。 公式Xの投稿を見て「ecache」の後継にあたる「fcache」の存在を知りました。 調べたら過去に投稿されてましたが、公式Xの投稿を逐一確認してないので気づきませんでした。 同投稿の「lazy_fold」と「lazy_accordion」に関しても追加していただきたいです。 プラグインの存在を簡単に知る方法がないと本末転倒なので、一ヶ所にまとめていただきたいです。 詳細な使い方や更新による挙動変化を含めると、切実に「wikiwikiプラグインのwiki」が欲しい。
@wikiwiki おそらく、popularが削除済みの記事も表示することは多数の利用者が煩わしく思っていたものであると考えます。 この要望については検討していただけないのでしょうか。
賛同します。 先日のアップデートによりWiki自体に管理者パスワードorサブパスワードでログイン出来る機能が追加されましたが、それでログインしている場合はページの凍結をバイパス出来ると便利かと思います。 既に指摘の通り、凍結解除・再凍結の分の操作が減る事、凍結忘れのリスクを回避出来る事の他、可能性は低いながら、凍結解除＆編集している間に荒らされてしまうリスクも回避する事が出来ます。
返信ありがとうございます。 こちらでも通常通り、表示されなくなったことを確認できました。
今はもう、表示されなくなったようです。プラグインが動作しているかどうかまでは、分かりませんが。 一時的な不具合ではないでしょうか。
wikiの管理者は、Googleアナリティクスを使って閲覧の統計を得たり、傾向を解析できるようになっています。 Googleアナリティクス: https://developers.google.com/analytics?hl=ja
得たい情報をもっと具体的に示してもらえれば、もう少し違った話ができるかもしれません。
この場合にも目次が生成されないようです。 lazy_foldの中に入れているincludeの内容に目次が含まれている場合: 引用元のページでは目次が生成されているにも関わらず、引用先に目次がされない
＃lazy_fold/lazy_accordion(option){{ ＃include(引用ページ) }}
引用ページの記述
＃contents/contentsx 内容 内容
既存のfoldをlazy_foldで置き換えた場合、折りたたみの内容が他の折りたたみの中に移動して表示されたり、内容を取得できないというエラーが表示される事があります。
お世話になっております。こちらの不具合についてですが、その後何か進展などありましたでしょうか？ googleカレンダーの埋め込みを一案として考えており、調査動向が気になった次第です。
同じ内容を選択できるプラグインみたいなものがあったらいいなと思いました。 現在の内容だと別のタグに同じ内容を選択したい場合は同じ内容を2回記載しないといけないので スペースを取ってしまいます。1か所記載したところから別のタグに同じ内容をコピー出来るみたいな感じでしょうか？ 使用した感想を率直に書きました違っていたらスミマセン。
メニュー時にできる左の無駄な空白を詰める
今確認したところ、これが改善されていました。 先頭タブ左の余白はほぼなくなり、メニュー幅に収められる量が少し増えました。ありがとございます。
wikiの編集中に自分も使いたい場面があったので実装を希望します。 また、対応してくださるなら、「fold」と「navfold」のどちらもインライン型で使えるようにしてほしいです。
自分もアカウント制は賛成です! 自分のWiki荒らしが多いので あとできればWikiごとにアカウントを 別々を希望しています
タブ機能についての追加要望となりますが、 「デフォルトで表示するタブを変更する機能」の実装を希望します。
現在の仕様は左端固定ですが、使い方として 新しいタブを後ろに追加し、それを最初に表示させたいケースがあります。
中間のタブをデフォルトにする運用はあまり思いつかないため、 個人的には先頭か末尾かを指定できれば十分です。
お手数ですが、ご検討いただければ幸いです。
タブの多段対応要望に関して、現在のデザインのまま実装されたとすると 選択中のタブが分かりづらくなる懸念があります。
最下段のタブは問題ありませんが、上段は太字表記のみになるため若干分かりにくくなります。 （小さい文字や1文字タブを設定するとこの問題はより顕著になります。）
もしタブ多段対応が実装されるならば、タブの選択・非選択状態をより明確に区別できるよう併せて検討いただきたいです。
選択・非選択状態の区別の例：
個人的には選択中タブの文字装飾を変更するのがシンプルでよいと思います。
アカウント制の実装は、大規模な荒らしが発生した際に、ごく一部の信頼できるユーザーのみが編集を継続できるようにすることを主な方向性として検討しているものと理解しています。 しかし、ホワイトリストを管理者が手動で認証する方式にすると、管理者は荒らし対策、Wikiの復旧作業に加えて、申請者の編集履歴を確認する作業を並行的に行うことになり、新たな作業が生じませんか？
現時点で議論されているホワイトリスト登録制度には、平常時に生じるメリットがほとんどないように見受けられ、多くの利用者は必要性を感じずアカウント申請を行わないと考えています。結果として（必要性が生じる）緊急時に申請が集中すると予想しています。
緊急時にアカウント申請への手動承認が必要だとすると、管理者としては「承認後からロックダウン解除の期間で本当に編集するか分からないユーザーに労力を割きたくない」「申請の照合作業よりも復旧作業を優先したい」と感じるのではないでしょうか。 ロックダウン中の承認作業が負担となれば、ロックダウン中のホワイトリスト制度は実際には機能しないことを意味します。
このため、管理者の負担減少を目的に、自動承認機能が必要だと考えています。 「SMS認証を必須とする」「該当ユーザが1ヶ月以上前から（editプラグインを用いた）編集実績がある」などの条件を設ければ、懸念されている安全性も一定程度担保しつつ、ロックダウン中でも意欲的な編集者の作業を許可し、管理側の負担も抑えられると考えますが、いかがでしょうか。 （仮に手動承認を要求するのであれば照合作業が負担とならないUIが必要で、別のスレッドの議論を引き合いに出してしまい恐縮ですが、現状の編集差分ログ機能ではその要求を満たしていないと考えます） 私自身、かなり想定が飛躍しているようには思われますので、皆さまの考えを伺いたいです。
>> 23 「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というケースが起こるのであればタブという形はあまり向いていないのではないでしょうか。 終了部分にラベルを表示しても結局は文章を先頭から読み直すためにスクロールが必要になるので、そういったケースで便利に読むのであればタブよりも「スクロールに追従する目次」などの方が有用ではないかなと思いました。
tabプラグインの範囲内なのか分かりにくい点については同感です。 ただ、水平線などを末尾に配置する形やcssboxとの併用など、編集者がどのような形で範囲を明確にするか選べるという意味では現行の仕様も良いと思います、デザインの自由度が高いですから。
タブラベルの多段化はflexでいう所のflex-wrapのような「折り返しを許可するか否か」を指定できるシンプルなものがあると嬉しいですね。 多段化が目当てでなくとも、ラベル名を省略してほしくないケースでも使えそうに思います。
確かに多段設置可能になれば、カラム幅を気にせずにタブが置けるようになるので、 より便利になりますね。
flex_boxのようにタブ幅が数値で指定でき、 引数オプションで、カラム幅に合わせて自動で折り返し表示可能になれば、 サイズ超過分が自動で下段表示となり、キレイにレイアウトできると思います。
追記：
「タブ幅が数値で指定でき…」と書きましたが、 （タブの）サイズでなく個数指定の方が良いかもしれません。
例えば、列の最大数を「5」と指定した場合、 超過分は自動で下段にレイアウトされ、 タブ幅は、タイトル文字列 or カラム幅に合わせて自動調節されるみたいな。 （レイアウトオプションは、左寄せ or カラム幅合わせの2択か、 文字列合わせの場合のみ中央寄せを加えた3択）
※ご要望が多かった「プルダウン形式」は、今回は採用を見送っています。
プラグイン使用してみて複数の情報ブロックを、タブ化したい項目があるので、皆さんが代替案として要望している多段タブを希望します。
また、どこまでがtabプラグインの範囲内なのかが利用者に分かりづらいことも要改善点と感じました。 タブ領域の開始部分だけでなく終了部分にもラベルを表示するか選べるオプションや、 タブ領域を表示している間は、ラベルを（#tablescrollプラグインのように）ページ上部に固定するオプションが選べたりするとよいかなと感じます。
こちらの意見・要望に賛同します。
とサンプルサイトにも記述があり、すでにwikiwiki運営様の方でも認識はされていると存じますが 「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というときにラベルのある上部まで遷移しなければならないというのが想定以上にストレスだなと感じます。とりわけページの中盤でタブを使用するページにおいて顕著です。
また、どこまでがtabプラグインの範囲内なのかが利用者に分かりづらいことも要改善点と感じました。
タブ領域の開始部分だけでなく終了部分にもラベルを表示するか選べるオプションや、 タブ領域を表示している間は、ラベルを（#tablescrollプラグインのように）ページ上部に固定するオプションが選べたりするとよいかなと感じます。
>> 21 私はメニューでの利用ついて述べています。通常ページについての意見ではありません。 デザインや調整値は共通や固定である必要はありません。
現状はメニュー・通常ページ内問わず共通デザインのため、全くの無関係であるとは言えません。 メニュー表示のためだけに、全体で使いづらくなるような変更をされては困るという意見を述べただけです。
「メニュー内表示時に限りデザインを変更したい」という意図で要望されているようですので、 通常ページでの利用に影響が出ない変更になるのであれば問題ありません。
私はメニューでの利用ついて述べています。通常ページについての意見ではありません。 デザインや調整値は共通や固定である必要はありません。 タブのためにメニューの幅を変更することは考えてません。今ところメニュー幅の方が優先度が高いです。
それは当然の動作ではないでしょうか？
0か1ではなく0.5（テキストデータだけ先行読込、HTML組立は開いたときにやる）を求めるのであれば、デフォルト動作変更は反対です。負荷軽減が薄れます。
どうしても、というのであればオプション化は反対しませんが、需要があるかは疑問符です。
素晴らしい要望です。
アンカーの名前に仮名や漢字が使えるようになって、さらにアンカーを自分で書かなかったときに自動生成される名前が見出しの名前と同じになったら、すごく便利だと思います。
これまでの意見を簡単にまとめたいと思います：
議論がある程度終わりましたので、運営からのコメントをお願いします。@wikiwiki
運営に動いてほしい という要望ということ？
であればこれ以上議論しようがないのでは？
公式のマニュアルをユーザに編集させるのは非現実的すぎるので、他の方の意見にあるように
引き続きマニュアル整備を要望し続けるか、有志で非公式プラグインマニュアルwikiを立ち上げるのが妥当かと思います。
主は「運営ができなければユーザー側で手伝いたい」とは一言も言っていないのですり替わってはいますね
自分たちでwikiを作って参加するのは>> 9の通り自由なので、ここでは>> 5のように元々あるさんぷるwikiを一般にも編集できるように要望する方がいいかと
何がすりかわったのかよくわかりませんが、マニュアルを整備してほしい→運営でできないのであればユーザが手伝います という話ですよね？
関連性があっても、話題のすり替えはあまり好ましくないです。
（木主の要望は、プラグインマニュアルの再整備・内容の充実です）
そもそも「プラグインのWikiを作る」ことは（18歳以上なら）誰にでもできますので、
運営に要望するようなことではないです。
自由に作ればいいでしょう。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
余裕がないからとかでしたら開放して有志での更新もありなのかなと思います
こちらでは、twitter_tweetプラグインが何の問題もなく使えています。
特定のポストを表示させようとしたときや、特定の他のプラグインと組み合わせて使ったときにだけ、起こる問題なのかもしれません。
具体的にどこのwikiのどのページに、どういったソースを書いて問題が起きたのかを示したほうが、対処が早くなる可能性があります。
同じ要望は過去にもありましたが、
https://zawazawa.jp/wikiwiki-request/topic/69
放置されたまま3年半近く経っていますので、
何らかの理由により、やるつもりがないのだと思われます。
csvとしてダウンロードできる機能は便利なのですが、荒らしの対応にあたっては手間が掛かるのは変わらず、ブラウザから確認できた方が親切です。
実際にあった例として、荒らし行為(似たような漢字に置き換える、URLの変更等)が発覚したあと、当日や直近数日のログから確認と復旧を行ったものの、実際は期間を空けて(数週間～)荒らし行為が行われており、復旧に時間がかかりました。このような場合、ブラウザ側で期間指定をして当該ユーザーの編集行為を絞り込めればより早く復旧できた可能性もあります。
こうした理由から、かつてのDiifnaのように一定期間は日付を跨いだ検索を実装頂きたく思います。
賛成です。マニュアルと言いつつあまりマニュアルの役目を果たしていないように思えます。>> 2さんの仰っている通りユーザー参加型の形式でもよさそうです。
賛成です。
利用しているwikiが使っているプラグインが、マニュアルを見ても載っていないことが多くてよく混乱しています。
切実にお願いします。プラグインのwikiがあったら自分も参加します。
公式Xの投稿日を見るに、こちらのトピックを受けて内容が追記されていたようですね。
https://x.com/wikiwiki_japan/status/1947539662194806924
ありがとうございました。
仕様上lazy系の中に入れた目次は表示されないようです。
https://wikiwiki.jp/pp/eco-plugins-guide (一番下のFAQに書いてあります)
賛成です。
公式Xの投稿を見て「ecache」の後継にあたる「fcache」の存在を知りました。
調べたら過去に投稿されてましたが、公式Xの投稿を逐一確認してないので気づきませんでした。
同投稿の「lazy_fold」と「lazy_accordion」に関しても追加していただきたいです。
プラグインの存在を簡単に知る方法がないと本末転倒なので、一ヶ所にまとめていただきたいです。
詳細な使い方や更新による挙動変化を含めると、切実に「wikiwikiプラグインのwiki」が欲しい。
@wikiwiki
おそらく、popularが削除済みの記事も表示することは多数の利用者が煩わしく思っていたものであると考えます。
この要望については検討していただけないのでしょうか。
賛同します。
先日のアップデートによりWiki自体に管理者パスワードorサブパスワードでログイン出来る機能が追加されましたが、それでログインしている場合はページの凍結をバイパス出来ると便利かと思います。
既に指摘の通り、凍結解除・再凍結の分の操作が減る事、凍結忘れのリスクを回避出来る事の他、可能性は低いながら、凍結解除＆編集している間に荒らされてしまうリスクも回避する事が出来ます。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
返信ありがとうございます。
こちらでも通常通り、表示されなくなったことを確認できました。
今はもう、表示されなくなったようです。プラグインが動作しているかどうかまでは、分かりませんが。
一時的な不具合ではないでしょうか。
wikiの管理者は、Googleアナリティクスを使って閲覧の統計を得たり、傾向を解析できるようになっています。
Googleアナリティクス:
https://developers.google.com/analytics?hl=ja
得たい情報をもっと具体的に示してもらえれば、もう少し違った話ができるかもしれません。
この場合にも目次が生成されないようです。
lazy_foldの中に入れているincludeの内容に目次が含まれている場合:
引用元のページでは目次が生成されているにも関わらず、引用先に目次がされない
引用ページの記述
既存のfoldをlazy_foldで置き換えた場合、折りたたみの内容が他の折りたたみの中に移動して表示されたり、内容を取得できないというエラーが表示される事があります。
お世話になっております。こちらの不具合についてですが、その後何か進展などありましたでしょうか？
googleカレンダーの埋め込みを一案として考えており、調査動向が気になった次第です。
同じ内容を選択できるプラグインみたいなものがあったらいいなと思いました。
現在の内容だと別のタグに同じ内容を選択したい場合は同じ内容を2回記載しないといけないので
スペースを取ってしまいます。1か所記載したところから別のタグに同じ内容をコピー出来るみたいな感じでしょうか？
使用した感想を率直に書きました違っていたらスミマセン。
今確認したところ、これが改善されていました。
先頭タブ左の余白はほぼなくなり、メニュー幅に収められる量が少し増えました。ありがとございます。
wikiの編集中に自分も使いたい場面があったので実装を希望します。
また、対応してくださるなら、「fold」と「navfold」のどちらもインライン型で使えるようにしてほしいです。
自分もアカウント制は賛成です!
自分のWiki荒らしが多いので
あとできればWikiごとにアカウントを
別々を希望しています
タブ機能についての追加要望となりますが、
「デフォルトで表示するタブを変更する機能」の実装を希望します。
現在の仕様は左端固定ですが、使い方として
新しいタブを後ろに追加し、それを最初に表示させたいケースがあります。
中間のタブをデフォルトにする運用はあまり思いつかないため、
個人的には先頭か末尾かを指定できれば十分です。
お手数ですが、ご検討いただければ幸いです。
タブの多段対応要望に関して、現在のデザインのまま実装されたとすると
選択中のタブが分かりづらくなる懸念があります。
最下段のタブは問題ありませんが、上段は太字表記のみになるため若干分かりにくくなります。
（小さい文字や1文字タブを設定するとこの問題はより顕著になります。）
もしタブ多段対応が実装されるならば、タブの選択・非選択状態をより明確に区別できるよう併せて検討いただきたいです。
選択・非選択状態の区別の例：
個人的には選択中タブの文字装飾を変更するのがシンプルでよいと思います。
アカウント制の実装は、大規模な荒らしが発生した際に、ごく一部の信頼できるユーザーのみが編集を継続できるようにすることを主な方向性として検討しているものと理解しています。
しかし、ホワイトリストを管理者が手動で認証する方式にすると、管理者は荒らし対策、Wikiの復旧作業に加えて、申請者の編集履歴を確認する作業を並行的に行うことになり、新たな作業が生じませんか？
現時点で議論されているホワイトリスト登録制度には、平常時に生じるメリットがほとんどないように見受けられ、多くの利用者は必要性を感じずアカウント申請を行わないと考えています。結果として（必要性が生じる）緊急時に申請が集中すると予想しています。
緊急時にアカウント申請への手動承認が必要だとすると、管理者としては「承認後からロックダウン解除の期間で本当に編集するか分からないユーザーに労力を割きたくない」「申請の照合作業よりも復旧作業を優先したい」と感じるのではないでしょうか。
ロックダウン中の承認作業が負担となれば、ロックダウン中のホワイトリスト制度は実際には機能しないことを意味します。
このため、管理者の負担減少を目的に、自動承認機能が必要だと考えています。
「SMS認証を必須とする」「該当ユーザが1ヶ月以上前から（editプラグインを用いた）編集実績がある」などの条件を設ければ、懸念されている安全性も一定程度担保しつつ、ロックダウン中でも意欲的な編集者の作業を許可し、管理側の負担も抑えられると考えますが、いかがでしょうか。
（仮に手動承認を要求するのであれば照合作業が負担とならないUIが必要で、別のスレッドの議論を引き合いに出してしまい恐縮ですが、現状の編集差分ログ機能ではその要求を満たしていないと考えます）
私自身、かなり想定が飛躍しているようには思われますので、皆さまの考えを伺いたいです。
>> 23
「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というケースが起こるのであればタブという形はあまり向いていないのではないでしょうか。
終了部分にラベルを表示しても結局は文章を先頭から読み直すためにスクロールが必要になるので、そういったケースで便利に読むのであればタブよりも「スクロールに追従する目次」などの方が有用ではないかなと思いました。
tabプラグインの範囲内なのか分かりにくい点については同感です。
ただ、水平線などを末尾に配置する形やcssboxとの併用など、編集者がどのような形で範囲を明確にするか選べるという意味では現行の仕様も良いと思います、デザインの自由度が高いですから。
タブラベルの多段化はflexでいう所のflex-wrapのような「折り返しを許可するか否か」を指定できるシンプルなものがあると嬉しいですね。
多段化が目当てでなくとも、ラベル名を省略してほしくないケースでも使えそうに思います。
確かに多段設置可能になれば、カラム幅を気にせずにタブが置けるようになるので、
より便利になりますね。
flex_boxのようにタブ幅が数値で指定でき、
引数オプションで、カラム幅に合わせて自動で折り返し表示可能になれば、
サイズ超過分が自動で下段表示となり、キレイにレイアウトできると思います。
追記：
「タブ幅が数値で指定でき…」と書きましたが、
（タブの）サイズでなく個数指定の方が良いかもしれません。
例えば、列の最大数を「5」と指定した場合、
超過分は自動で下段にレイアウトされ、
タブ幅は、タイトル文字列 or カラム幅に合わせて自動調節されるみたいな。
（レイアウトオプションは、左寄せ or カラム幅合わせの2択か、
文字列合わせの場合のみ中央寄せを加えた3択）
プラグイン使用してみて複数の情報ブロックを、タブ化したい項目があるので、皆さんが代替案として要望している多段タブを希望します。
こちらの意見・要望に賛同します。
とサンプルサイトにも記述があり、すでにwikiwiki運営様の方でも認識はされていると存じますが
「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というときにラベルのある上部まで遷移しなければならないというのが想定以上にストレスだなと感じます。とりわけページの中盤でタブを使用するページにおいて顕著です。
また、どこまでがtabプラグインの範囲内なのかが利用者に分かりづらいことも要改善点と感じました。
タブ領域の開始部分だけでなく終了部分にもラベルを表示するか選べるオプションや、
タブ領域を表示している間は、ラベルを（#tablescrollプラグインのように）ページ上部に固定するオプションが選べたりするとよいかなと感じます。
現状はメニュー・通常ページ内問わず共通デザインのため、全くの無関係であるとは言えません。
メニュー表示のためだけに、全体で使いづらくなるような変更をされては困るという意見を述べただけです。
「メニュー内表示時に限りデザインを変更したい」という意図で要望されているようですので、
通常ページでの利用に影響が出ない変更になるのであれば問題ありません。
私はメニューでの利用ついて述べています。通常ページについての意見ではありません。
デザインや調整値は共通や固定である必要はありません。
タブのためにメニューの幅を変更することは考えてません。今ところメニュー幅の方が優先度が高いです。