自動削除のONにしない限り自動的に削除されないというのはどうですか？
以下の可能性があるので自動で削除されては困ります。
改めて。<td style="display:none;"></td>このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。
<td style="display:none;"></td>
|A|1| |~|2| |B|3|
こう書いて|~|の部分を<td style="display:none;">A</td>と変換すれば、 fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。 tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
<td style="display:none;">A</td>
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか? overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、 一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、 つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。 試しに|~|があるべき位置に<td style="display:none;"></td>とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。
ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。 他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
有用なプラグインの実装ありがとうございます。 画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、１つ問題点を確認しています。 先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
#tablescroll(,fix-col){{ |~先頭ヘッダー|>|~項目カテゴリー|~その他|h |~|~項目A|~項目B|~|h ||||500|c |~先頭|||| }}
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。 何とかならないでしょうか？
ページ編集フォームごと表示されないようです
さらに。 行と列の追加、挿入、削除、コピペが出来るように。 特に列は従来エディタだと面倒だったところ。ミスをすると表が崩れて壊滅的になり、しかもどこを間違えたのか捜索が大変。巨大な表だとスプレッドシートを使うか正規表現置換を駆使する必要があるが、出来る人は限られる。
セル内改行を&brとするか↲キーで可能にするかはエディタの表示メニューで選択。
スプレッドシートから範囲コピペ可能に。
0ベースで検討できる贅沢な状況のようですが。 閲覧状態から対象箇所を直接指定で編集できるのは魅力的です。｜棒が沢山並んだ巨大な表のソースでは、どこを編集してるのかわからないので、大抵スプレッドシートに展開してから編集してます。 一方でそれをダブルクリックなどで手軽に編集可能になってしまうと、誤操作や意図せぬ書き換え、イタズラの敷居が下がります。 またもし一箇所ごとに変更が反映されるなら、その度に更新が入り負荷が高そうです。編集が競合したときどうなるのかも気になります。
見出し内編集のように特定のボタンを押すと表編集エディタが開くのが良いと思います。ボタンは表外の右上が良いと思います。目に付きにくい所がいいです。
エディタはスプレッドシートのように扱えると良いです。つまり縦横二次元の表のまま、コピペ、範囲指定、セルごとの書式など操作できるように。ショートカットやスマホで操作出来るようボタンメニューも。左側に入力エリア、c書式行や//コメント行を含めて。(UI的にコメント行が難しければなしで)。右側にプレビュー画面。
エディタは通常編集画面からも呼び出せると良い。
上記だけだとプラグインではなく、見出し内編集のように標準組み込みでも良いかもしれません。ただ完成した表をロックしたいとかあるかもしれないので、逆にプラグインで編集ロックできると良いかも。既にそんなプラグインがあったような。
私の場合zrecentはコメント更新確認の目的で使っているので、新規トピックや本文側の更新が反映されなくても不便は無いです。
zawazawaをwikiwikiのコンテンツのコメント機能のために使うのか、zawazawaの内容を方を主としてそちらの状況をwikiwikiで確認したいのかの違いだと思いますが、zrecentはpcommentの代替として前者の目的で登場したと思います。
機能拡張しても損はないとおもいますが。例えば本文をコメント0番として反映させるとか。
6) 状況に応じて縦スクロール幅制限を外したい 私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
期待する動作
問題点
#tablescroll(高さ指定){{ #popout{ includex(表ページ) }} }}
どうなれば良いか tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。 時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
本文ページ #表示領域指定プラグイン(高さ){{ includex(表ページ) }} 表ページ #popout{{ #tablescroll(高さ最大){{ |表| }} }}
>画面上部にヘッダ貼り付け >横はみ出しは切れる。 なのですが、横はみ出しは切れないように（というより先頭列を固定した横スクロールと併用できるように）ならないでしょうか？
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
確認いたしました。期待していた挙動です。修正ありがとうございます。 より深いところ、プラグイン名やパラメータのパターンマッチのところに原因があったのですね。根源の調査と根本的な対策、その修正規模感に比してとても素早い対応をしていただき、ありがとうございました。
自分は最近使い始めたばかりですが、新着が表示されないことに今まで誰も不満が無いのであれば需要が無いということなのでしょうか？ 他に利用されている方のご意見も聞きたいです。
もし改善される見込みがある場合の仕様提案です ・現在の表記はタイトル全文が表示されて長すぎることがあるのである程度の文字数以降は省略する ・新着トピックにNewをつける
こんなイメージです
24時間以内に投稿 ・新たな編集可能テーブルプラグイン(table_edit2.inc... 2023-06-07 ・表の見出しを固定する機能 ・zrecentプラグインで表示されないトピックがある ・「recent」ページ名でフィルタをかけられるようにする... ・ ページ名変更と一括変換機能をサブパスワード保持者に... 2023-06-06 ・flexboxの境界線と背景色指定 ・コメントフォームでの画像展開時のリロード不具合 ・tooltipプラグインのterm引数に、他のインラインプラ... ・構文解析の不具合仕様について New
仕様が古く実装できなかったのですね、それは失礼いたしました
自分がよく編集しているWikiにはこのようなとてつもないサイズの表があるのですが、入力する量が多いため、入力フォームを作成できるようになればかなり楽になると思います また、この表は下にどんどん追加していくという追記のやり方よりは、対応するグループに応じて間に挿入していく追記がメインですので、
表のセルをダブルクリックするとセルが入力フォームになって直接入力できる
もしこのような実装に決定した場合、下の行を追加するような機能もあると嬉しいです
ただ、直近のアップデートでスプレッドシートからコピペで表を貼り付けできるようになったので スプレッドシートを運用するのであればプラグインが拡張することに魅力はあまり感じないのかなと思います。
複数人でスプレッドシートをメンテできるのと、Wiki側で表を調整できる人が1人いればいいので
これは魅力を感じました。
表の角のアイコンをクリックするとGoogleスプレッドシートのような入力画面になる データベースからレコードを操作して表を作成したり書き込んだりできる
試験実装ありがとうございます。非常に使いやすいです。 大きな問題ではないのですが、popupプラグインを併用したときに、新規ページとして開かれた表がスクロールなしになるようにプラグインを記述する(*1)と、表と一緒にpopupのボタンもスクロールされるようになってしまうので、できればスクロールされないような記述が可能になると、より使いやすくなるだろうなと感じました。
※1 tablescroll→popup→その他プラグイン(tablesortなど)の入れ子
システム的にこのプラグインを導入することはできません。 同等の機能で新しく作ることは可能ですが、このプラグインの仕様は古すぎます。 新しい仕様をご検討いただけたら幸いです。
例えば
などです。
引き続き議論をお願いいたします。🙇♂️
需要があれば導入いたしますので、引き続き議論いただけたら幸いです。 仕様など(例えばリストのリンク先はどうするのか、表記はどのようにするのか)もお考えください。
こちらのプラグイン、技術的に問題があるのでなければ再度検討願いたいです
遅くなりました。 希望のものが実装されております。ありがとうございました。
たしかに管理者の負担が大きい部分はあります 例えば、サブパスワード保持者がリネームをリクエストして、管理者が承認後に自動でコマンドが発行されるような仕組みがあれば最終的な判断は管理者というのは変わりはないので便利かもしれません。
いずれにしてもリネームが管理者1人しかできないというのは、何か手を加えてほしいところではあります。
あくまで仕様なので、変更をするつもりはないということでしょうか。残念です。
WIKIWIKI さんぷるWIKIのMenuBarでも以下のようにwikiwiki officialのトピックを表示しようとしていますが公式が投稿したトピックが広く周知されないのはいかがなものかと思いますが・・・
*zawazawaの最新のトピック [#zc67eff8] #zrecent(wikiwiki,wikiwiki-help,wikiwiki-request)
元々ブロック型プラグインではダブルクオートで囲めばよかったんですね。 csssboxプラグインの説明ページでもダブルクオートで囲んだ例に変えていただいた方がわかりやすいと思います。 ご回答ありがとうございました。
1) fix-colは対象列が"|~A|"だと機能しない
2) 罫線はオリジナルと同じに
見出し行の直後に表が配置されているページにおいて、表をスクロールするときに少しだけヘッダー行が移動してしまいます。
フィードバックありがとうございます。 ひとまず上記の不具合を修正しました。
引き続きよろしくお願いします。
連絡が遅くなりました。 さきほど閲覧数の多いページへプラグインを導入中に罫線が細くなったのを確認しました。 とりあえずの要望としては細いのを希望しようと考えおりましたので助かりました。ありがとうございます。
申し訳ございません。 #zrecentは最新のコメントリストを出力するプラグインです。 トピックの更新は対応しておりません。
#zrecent
解決済とさせていただきます。
仕様です。
#foldはブロック型プラグインです。 行頭に書いて使います。
#fold
#pcommentは指定されたページのコメントリストを表示しています。 リスト内にブロック型のプラグイン書式が挿入されると正しく表示されないことがあります。
#pcomment
失礼しました、以下のような場合です。
*見出し行 #tablescroll(300){{ |a|b|c|h |1|2|3| |4|5|6| }}
非常に有用なプラグインだと思います。 細かいところなのですが、
*見出し行
|a|b|c|h |1|2|3| |4|5|6| }}
といった形で見出し行の直後に表が配置されているページにおいて、表をスクロールするときに少しだけヘッダー行が移動してしまいます。 大きな差し障りはありませんが、感覚的には気持ち悪く感じてしまうため、修正していただきたいです。
ブロック型ならダブルクオートで囲んで任意の文字列をひとつの値と解釈させることができます。
関連トピック pukiwiki の構文解析が持っていた不具合仕様を修正しました。
ダブルクオート囲みで正しく構文が解釈できるようになりました。
&tooltip("昔むかし&color(#00b8ee){あるところに};");
「段落を作りたくないときは、第2引数にテキストを書きます。」とありますが、「,」(カンマ)を含むテキストを書こうとするとパラメータの区切りと判定されてしまってカンマ以降が表示されません。 対策としてカンマを数値文字参照で記述すればいいんですがちょっと面倒です。 第2引数を最後の括弧の直前までとするか、cssboxの説明に注意点として書いていただけたらと思います。
5) 高さ指定のとき、縦のスクロールバーを最下段開始指定できるように 表を下に向かってどんどん追記することがある。例えば履歴だったり追加要素だったり。 こういった表は従来、全体が長くなるのでfoldで畳んだりしてる。 今回の機能はヘッダ固定と表示領域の高さ指定できるので、これを利用すれば常時展開しても邪魔にならなくなる。 このとき最初の表示位置が表の一番下であってほしい。つまりオプションでスクロールバーの初期位置を下に指定できるとよい。 (これは未検討。)
4) 右端と最下段も固定可能に 一番下が最新情報だったり、左下が基準点となることもあるので最下段で固定可能に。 右端は備考列や単位列固定に使える。 オプションが増えると長くなるので、fix-の文字列は無くてもよいかも。
//追加オプション fix-foot .tablescroll-fix-foot table tfoot{position:sticky;bottom:0;z-index:2} //追加オプション fix-col-last .tablescroll-fix-col-last table tr>*:last-child{right:0;position:sticky;z-index:1;border-left:1px solid}
自動削除のONにしない限り自動的に削除されないというのはどうですか？
以下の可能性があるので自動で削除されては困ります。
改めて。
<td style="display:none;"></td>このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。こう書いて|~|の部分を
<td style="display:none;">A</td>と変換すれば、fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。
tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか?
overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、
一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、
つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。
試しに|~|があるべき位置に
<td style="display:none;"></td>とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。
他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
有用なプラグインの実装ありがとうございます。
画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll{{
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、１つ問題点を確認しています。
先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。
何とかならないでしょうか？
ページ編集フォームごと表示されないようです
さらに。
行と列の追加、挿入、削除、コピペが出来るように。
特に列は従来エディタだと面倒だったところ。ミスをすると表が崩れて壊滅的になり、しかもどこを間違えたのか捜索が大変。巨大な表だとスプレッドシートを使うか正規表現置換を駆使する必要があるが、出来る人は限られる。
セル内改行を&brとするか↲キーで可能にするかはエディタの表示メニューで選択。
スプレッドシートから範囲コピペ可能に。
0ベースで検討できる贅沢な状況のようですが。
閲覧状態から対象箇所を直接指定で編集できるのは魅力的です。｜棒が沢山並んだ巨大な表のソースでは、どこを編集してるのかわからないので、大抵スプレッドシートに展開してから編集してます。
一方でそれをダブルクリックなどで手軽に編集可能になってしまうと、誤操作や意図せぬ書き換え、イタズラの敷居が下がります。
またもし一箇所ごとに変更が反映されるなら、その度に更新が入り負荷が高そうです。編集が競合したときどうなるのかも気になります。
見出し内編集のように特定のボタンを押すと表編集エディタが開くのが良いと思います。ボタンは表外の右上が良いと思います。目に付きにくい所がいいです。
エディタはスプレッドシートのように扱えると良いです。つまり縦横二次元の表のまま、コピペ、範囲指定、セルごとの書式など操作できるように。ショートカットやスマホで操作出来るようボタンメニューも。左側に入力エリア、c書式行や//コメント行を含めて。(UI的にコメント行が難しければなしで)。右側にプレビュー画面。
エディタは通常編集画面からも呼び出せると良い。
上記だけだとプラグインではなく、見出し内編集のように標準組み込みでも良いかもしれません。ただ完成した表をロックしたいとかあるかもしれないので、逆にプラグインで編集ロックできると良いかも。既にそんなプラグインがあったような。
私の場合zrecentはコメント更新確認の目的で使っているので、新規トピックや本文側の更新が反映されなくても不便は無いです。
zawazawaをwikiwikiのコンテンツのコメント機能のために使うのか、zawazawaの内容を方を主としてそちらの状況をwikiwikiで確認したいのかの違いだと思いますが、zrecentはpcommentの代替として前者の目的で登場したと思います。
機能拡張しても損はないとおもいますが。例えば本文をコメント0番として反映させるとか。
6) 状況に応じて縦スクロール幅制限を外したい
私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
ほぼ表だけが書かれてるページ。簡単な凡例や説明書きなどはある。
includexで複数ページがから呼び出される。
ページソースは文書を主として、表(複数)をincludexで呼び出す。
期待する動作
文章の中に表を組み込んでいるため、表示されるとき表が大きすぎると邪魔。ページ全体に対する表の表示領域を限定したい。
表ページへリンクとPopoutを組み込んで、必要なときは表だけに着目できるようにする。
表ページ及びPopoutは表を最大限活用するために使う。
このときはページバランスを気にする必要はないので画面幅を最大限利用したい。
ただし表が大きすぎると、やはりヘッダーが画面の外に逃げてしまう問題はあるので、tablescrollは使いたい。
閲覧者ごとに表示環境が違うため、高さは固定値ではなく表示環境ごとの最大としたい。
同様に横が収まるか分からないのでfix-colも使いたい。
問題点
screen-stickyは高さ最大相当になるが、fix-colと同時に使えない。
またfix-colを使わずとも横方向にはみ出し部分は表示できない。
以下の書き方だと、表ページ及びPopout時にtablescrollが機能しない。
あるいは内側にtablescrollを入れれば高さ制限が掛かってしまう。
どうなれば良いか
tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。
時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
>画面上部にヘッダ貼り付け
>横はみ出しは切れる。
なのですが、横はみ出しは切れないように（というより先頭列を固定した横スクロールと併用できるように）ならないでしょうか？
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
確認いたしました。期待していた挙動です。修正ありがとうございます。
より深いところ、プラグイン名やパラメータのパターンマッチのところに原因があったのですね。根源の調査と根本的な対策、その修正規模感に比してとても素早い対応をしていただき、ありがとうございました。
自分は最近使い始めたばかりですが、新着が表示されないことに今まで誰も不満が無いのであれば需要が無いということなのでしょうか？
他に利用されている方のご意見も聞きたいです。
もし改善される見込みがある場合の仕様提案です
・現在の表記はタイトル全文が表示されて長すぎることがあるのである程度の文字数以降は省略する
・新着トピックにNewをつける
こんなイメージです
仕様が古く実装できなかったのですね、それは失礼いたしました
自分がよく編集しているWikiにはこのようなとてつもないサイズの表があるのですが、入力する量が多いため、入力フォームを作成できるようになればかなり楽になると思います
また、この表は下にどんどん追加していくという追記のやり方よりは、対応するグループに応じて間に挿入していく追記がメインですので、
もしこのような実装に決定した場合、下の行を追加するような機能もあると嬉しいです
ただ、直近のアップデートでスプレッドシートからコピペで表を貼り付けできるようになったので
スプレッドシートを運用するのであればプラグインが拡張することに魅力はあまり感じないのかなと思います。
複数人でスプレッドシートをメンテできるのと、Wiki側で表を調整できる人が1人いればいいので
これは魅力を感じました。
試験実装ありがとうございます。非常に使いやすいです。
大きな問題ではないのですが、popupプラグインを併用したときに、新規ページとして開かれた表がスクロールなしになるようにプラグインを記述する(*1)と、表と一緒にpopupのボタンもスクロールされるようになってしまうので、できればスクロールされないような記述が可能になると、より使いやすくなるだろうなと感じました。
※1 tablescroll→popup→その他プラグイン(tablesortなど)の入れ子
システム的にこのプラグインを導入することはできません。
同等の機能で新しく作ることは可能ですが、このプラグインの仕様は古すぎます。
新しい仕様をご検討いただけたら幸いです。
例えば
などです。
引き続き議論をお願いいたします。🙇♂️
需要があれば導入いたしますので、引き続き議論いただけたら幸いです。
仕様など(例えばリストのリンク先はどうするのか、表記はどのようにするのか)もお考えください。
こちらのプラグイン、技術的に問題があるのでなければ再度検討願いたいです
遅くなりました。
希望のものが実装されております。ありがとうございました。
たしかに管理者の負担が大きい部分はあります
例えば、サブパスワード保持者がリネームをリクエストして、管理者が承認後に自動でコマンドが発行されるような仕組みがあれば最終的な判断は管理者というのは変わりはないので便利かもしれません。
いずれにしてもリネームが管理者1人しかできないというのは、何か手を加えてほしいところではあります。
あくまで仕様なので、変更をするつもりはないということでしょうか。残念です。
WIKIWIKI さんぷるWIKIのMenuBarでも以下のようにwikiwiki officialのトピックを表示しようとしていますが公式が投稿したトピックが広く周知されないのはいかがなものかと思いますが・・・
元々ブロック型プラグインではダブルクオートで囲めばよかったんですね。
csssboxプラグインの説明ページでもダブルクオートで囲んだ例に変えていただいた方がわかりやすいと思います。
ご回答ありがとうございました。
フィードバックありがとうございます。
ひとまず上記の不具合を修正しました。
引き続きよろしくお願いします。
連絡が遅くなりました。
さきほど閲覧数の多いページへプラグインを導入中に罫線が細くなったのを確認しました。
とりあえずの要望としては細いのを希望しようと考えおりましたので助かりました。ありがとうございます。
申し訳ございません。
#zrecentは最新のコメントリストを出力するプラグインです。トピックの更新は対応しておりません。
解決済とさせていただきます。
仕様です。
#foldはブロック型プラグインです。行頭に書いて使います。
#pcommentは指定されたページのコメントリストを表示しています。リスト内にブロック型のプラグイン書式が挿入されると正しく表示されないことがあります。
失礼しました、以下のような場合です。
*見出し行
#tablescroll(300){{
|a|b|c|h
|1|2|3|
|4|5|6|
}}
非常に有用なプラグインだと思います。
細かいところなのですが、
*見出し行
tablescroll(300){{
|a|b|c|h
|1|2|3|
|4|5|6|
}}
といった形で見出し行の直後に表が配置されているページにおいて、表をスクロールするときに少しだけヘッダー行が移動してしまいます。
大きな差し障りはありませんが、感覚的には気持ち悪く感じてしまうため、修正していただきたいです。
ブロック型ならダブルクオートで囲んで任意の文字列をひとつの値と解釈させることができます。
関連トピック
pukiwiki の構文解析が持っていた不具合仕様を修正しました。
ダブルクオート囲みで正しく構文が解釈できるようになりました。
関連トピック
pukiwiki の構文解析が持っていた不具合仕様を修正しました。
「段落を作りたくないときは、第2引数にテキストを書きます。」とありますが、「,」(カンマ)を含むテキストを書こうとするとパラメータの区切りと判定されてしまってカンマ以降が表示されません。
対策としてカンマを数値文字参照で記述すればいいんですがちょっと面倒です。
第2引数を最後の括弧の直前までとするか、cssboxの説明に注意点として書いていただけたらと思います。
5) 高さ指定のとき、縦のスクロールバーを最下段開始指定できるように
表を下に向かってどんどん追記することがある。例えば履歴だったり追加要素だったり。
こういった表は従来、全体が長くなるのでfoldで畳んだりしてる。
今回の機能はヘッダ固定と表示領域の高さ指定できるので、これを利用すれば常時展開しても邪魔にならなくなる。
このとき最初の表示位置が表の一番下であってほしい。つまりオプションでスクロールバーの初期位置を下に指定できるとよい。
(これは未検討。)
4) 右端と最下段も固定可能に
一番下が最新情報だったり、左下が基準点となることもあるので最下段で固定可能に。
右端は備考列や単位列固定に使える。
オプションが増えると長くなるので、fix-の文字列は無くてもよいかも。