タイトルの通り、表をスクロールしても見出しを固定できる機能がほしいです。
今のところは表を小分けにして対応しています。
px
#
埋め込み先の背景色と馴染まない場合に指定して下さい。通常は埋め込み先の背景色をそのまま利用します。
px
wikiwikiスタイルでは文字サイズやフォントが自動的に調整されます。
次のコードをWIKIWIKIのページに埋め込むと最新のコメントがその場に表示されます。
// generating...
試験実装中の
#tablescroll
プラグインです。お試しいただけますでしょうか?
使用感を教えていただけたら幸いです。
高さ固定のスクロール可能テーブル
領域内でヘッダを上部に固定してスクロール可能。
横はみ出しがあっても水平スクロールできる。
高さ省略時は 500 がデフォルト。
先頭列を固定したスクロール可能テーブル
横スクロール時に先頭列が固定される。
横はみ出しでスクロールが起きる場合でないと意味がない。
画面上部にヘッダ貼り付け
横はみ出しは切れる。
関連トピック スクロール時における先頭行/列の固定についての要望
https://zawazawa.jp/wikiwiki-request/topic/90
とてもいいですね。3つとも便利に使えそうです。
(と言っても横スクロールはまだ試していませんが…)
このまま正式実装でも良いと思いますが、(修正)表の外枠とそれ以外の枠線の太さが異なってしまうのはどうにかならないでしょうか。
(外枠の太さは適用前と変化なし。それ以外の枠線は太くなる。単に見栄えだけの問題)
追記:
修正を確認しました。対応ありがとうございます。
1箇所だけ太くなってしまう部分があるのですが、
この部分は修正不可能なのでしょうか。
上記例のヘッダー2行目の「A」の左隣の枠線が該当します。
上記例のようにセルに色を付けると目立つのですが、
直らないのであれば、個人的には構いません。
2023.8.3 追記:
3種類のうち、領域指定の上2つはtablesortとの併用ができず、
screen-stickyオプションでは右端の見切れが回避できません。
こちらのトピックでも要望されていますが、
screen-sticky動作で横スクロール可能にならないと、
正式実装はかなり厳しいように思います。
早速返信いただきありがとうございます!
過去にほしいって発言したこと忘れてました。
閲覧数の多いページで使って利用者にも感想を求めてみます。
ありがとうございました。
非常に使いやすくて素晴らしいです。ありがとうございます。
その上で、要望になってしまうのですが…
行固定のスクロール可能テーブルはヘッダ行(h)がついてれば複数固定可能なように、列固定のスクロール可能テーブルも複数列の指定固定ができるようになれば嬉しいな、と考えております。
プラグイン追加ありがとうございます。
試しに表を作成してみましたが、先頭行・先頭列を固定すると、表の罫線が太くなってしまいます。
一般的に、表は罫線が細いほうが見やすいのです。
表のすべての罫線を太くしてしまうと、内容よりも罫線が目立ってしまい、見づらくなるのです。
先頭行・先頭列を固定しても、罫線は太くせずに、普通の罫線のままでいいと思います。
参考
https://clip-blog.com/table-design/#index_id6
https://diamond.jp/articles/-/68395
これは有用な機能です。
ヘッダ行が常駐するのでtablesortとの相性もよいです。
既存の表に適用したいですが、しかし問題があります。
また追加で検討いただきたい機能があります。
まずは1と2の問題点が解決できればリリースに問題はありません。
可能ならば3以降の機能追加もご検討ください。
今回htmlを覗いてなんとなく仕組みが分かったので、自分の環境で実験してみました。
素人の見様見真似なので、例は適当に解釈してください。
1) fix-colは対象列が"|~A|"だと機能しない
例えば以下。|~2|のところは機能しません。
先頭列は強調表現で"~"で記述することは良くあるので、これでは使えません。
以下のように修正すれば上手く行くようです。
2) 罫線はオリジナルと同じに
太いと目立ちすぎる。機能を使ってない表と見た目が違うので違和感が出る。
以下のようにすると以前とほぼ同様になりました。ただしヘッダ/フッタの境界線は二重になります。まあこれはこれでいいかなと。
3) 固定列は複数できるとよい
ヘッダ行は必要なら複数行積めるので、今のままでもなんとかなる。
しかし列は先頭1列だけだと不自由なのでなんとかしたい。
例えば1列目大分類、2列目中分類、3列目小分類みたいな書き方は良くある。
追加で任意の2列をロックできるようにする。
fix-col(先頭固定)とは別に、例えばfc2、fc3とかオプションを作る。
fc2もfc3も機能は同じで、固定したい列番号と左からの固定位置を指定する。例えば以下。
利点は任意の列を任意の位置に固定できる。
fix-colと組み合わせれば左から2列目3列目も固定できるし、fix-colを使わず独立して任意の列を好きなようにロックできる。
問題点は固定値を自分で割り出さないといけない。テーブルのc定義書式で幅を決めれば見当はつくが試行錯誤が必要。またスマホなど環境が変わるとズレるかも。
4) 右端と最下段も固定可能に
一番下が最新情報だったり、左下が基準点となることもあるので最下段で固定可能に。
右端は備考列や単位列固定に使える。
オプションが増えると長くなるので、fix-の文字列は無くてもよいかも。
5) 高さ指定のとき、縦のスクロールバーを最下段開始指定できるように
表を下に向かってどんどん追記することがある。例えば履歴だったり追加要素だったり。
こういった表は従来、全体が長くなるのでfoldで畳んだりしてる。
今回の機能はヘッダ固定と表示領域の高さ指定できるので、これを利用すれば常時展開しても邪魔にならなくなる。
このとき最初の表示位置が表の一番下であってほしい。つまりオプションでスクロールバーの初期位置を下に指定できるとよい。
(これは未検討。)
非常に有用なプラグインだと思います。
細かいところなのですが、
*見出し行
tablescroll(300){{
|a|b|c|h
|1|2|3|
|4|5|6|
}}
といった形で見出し行の直後に表が配置されているページにおいて、表をスクロールするときに少しだけヘッダー行が移動してしまいます。
大きな差し障りはありませんが、感覚的には気持ち悪く感じてしまうため、修正していただきたいです。
失礼しました、以下のような場合です。
*見出し行
#tablescroll(300){{
|a|b|c|h
|1|2|3|
|4|5|6|
}}
連絡が遅くなりました。
さきほど閲覧数の多いページへプラグインを導入中に罫線が細くなったのを確認しました。
とりあえずの要望としては細いのを希望しようと考えおりましたので助かりました。ありがとうございます。
フィードバックありがとうございます。
ひとまず上記の不具合を修正しました。
引き続きよろしくお願いします。
試験実装ありがとうございます。非常に使いやすいです。
大きな問題ではないのですが、popupプラグインを併用したときに、新規ページとして開かれた表がスクロールなしになるようにプラグインを記述する(*1)と、表と一緒にpopupのボタンもスクロールされるようになってしまうので、できればスクロールされないような記述が可能になると、より使いやすくなるだろうなと感じました。
※1 tablescroll→popup→その他プラグイン(tablesortなど)の入れ子
6) 状況に応じて縦スクロール幅制限を外したい
私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
ほぼ表だけが書かれてるページ。簡単な凡例や説明書きなどはある。
includexで複数ページがから呼び出される。
ページソースは文書を主として、表(複数)をincludexで呼び出す。
期待する動作
文章の中に表を組み込んでいるため、表示されるとき表が大きすぎると邪魔。ページ全体に対する表の表示領域を限定したい。
表ページへリンクとPopoutを組み込んで、必要なときは表だけに着目できるようにする。
表ページ及びPopoutは表を最大限活用するために使う。
このときはページバランスを気にする必要はないので画面幅を最大限利用したい。
ただし表が大きすぎると、やはりヘッダーが画面の外に逃げてしまう問題はあるので、tablescrollは使いたい。
閲覧者ごとに表示環境が違うため、高さは固定値ではなく表示環境ごとの最大としたい。
同様に横が収まるか分からないのでfix-colも使いたい。
問題点
screen-stickyは高さ最大相当になるが、fix-colと同時に使えない。
またfix-colを使わずとも横方向にはみ出し部分は表示できない。
以下の書き方だと、表ページ及びPopout時にtablescrollが機能しない。
あるいは内側にtablescrollを入れれば高さ制限が掛かってしまう。
どうなれば良いか
tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。
時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか?
overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
>画面上部にヘッダ貼り付け
>横はみ出しは切れる。
なのですが、横はみ出しは切れないように(というより先頭列を固定した横スクロールと併用できるように)ならないでしょうか?
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。
何とかならないでしょうか?
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、1つ問題点を確認しています。
先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
有用なプラグインの実装ありがとうございます。
画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll{{
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、
一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、
つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。
試しに|~|があるべき位置に
<td style="display:none;"></td>
とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。
他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
改めて。
<td style="display:none;"></td>
このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。こう書いて|~|の部分を
<td style="display:none;">A</td>
と変換すれば、fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。
tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
既に報告があるようですが、念のため再度不具合を報告しておきます。
のような形式で先頭列を固定すると、Eのセルが固定されてしまいます(以下の画像で言うと、「開始日」のセルです)。
Aだけが固定化されるよう修正いただけないでしょうか。
互換性や保守性の観点から、tablescroll はテーブル書式にのみ動作する仕様といたしました。
iPhoneやiPadなどのiOS上のブラウザは、一般的なブラウザとは異なる独自の仕組みで動作しており、
この影響で互換性の問題が生じる場合があります。
テーブル書式以外の文字列やプラグインが挿入されると、正しく動作しない、
あるいは不安定になる現象が確認されたため、このような対応を取らせていただきました。
結合された先頭列についても、保守性や互換性の観点から非対応とさせていただきます。
(エラー表示になる予定です)
仕様をご理解いただき、慎重にご利用いただけますと幸いです。
かしこまりました。今後もアナウンスがあると今後の方針も決めやすいです。よろしくお願いいたします。