hyiromori’s blog

Webエンジニア hyiromori の技術メインのブログです。

CSSだけでテーブルの縦横2列を固定してスクロールできるようにする

はじめに

タイトルのような、とても大変な要件のテーブルを作って欲しいという要望があったので、その際に試行錯誤した結果を記録しておいたエントリです。

サンプル

CodePenで作ったサンプルです。

See the Pen ScrollTable with fixed 2rows & 2columns header. by hyiromori (@hyiromori) on CodePen.

コードの解説

このコードではposition: stickyを使用することで、テーブルの行、列を固定しています。

position: stickytop right bottom left と組み合わせて使うことで position: relativeposition: absoluteを組み合わせたような動きが可能になる指定です。

Safari ではposition: -webkit-sticky;のようにベンダープレフィックスをつけないと動作しませんでした。

詳細はMDNの解説をご覧ください。

position: sticky の対応状況

Can I Useによれば、モダンブラウザは対応済みです。 ちなみにChromeなどは

Supported on th elements, but not thead or tr

とある通りthead trにバグがあるようです。 このサンプルはthead trに指定していないので、対応ブラウザなら正常に動作するはずです。

幅と高さの制約

position: sticky を使用するため、一部のセルは幅または高さを固定する必要があります。 今回のサンプルは、縦横それぞれ2列を固定するため、以下を固定しなければなりません。

  • 1行目の高さ(2行目のtopを指定しないと固定できないため)
  • 1列目の幅(2列目のleftを指定しないと固定できないため)

実際に使用する場合は、これらのセルを指定した幅と高さで必ず収まるように要素を配置しないといけません。

表示上の制約

テーブルの親要素の幅が十分に広い場合、右側に余白ができてしまう場合があります。 これは table {width: 100%} を指定しても解消できませんでした。

WindowのResizeイベントMutationObserver を使って、 ある程度の幅以下になったら横スクロールを適用するという方法で乗り切りました。

ResizeObserverも使えますが、まだまだ対応ブラウザが少ないです。 対応ブラウザが増えたらこちらも使えるかもしれません。

WebRTC の資料リンク集

WebRTC を調査していた際に集めたリンク集です。

RFC

ミドルウェア

テストツール

Voluntasさん

時雨堂代表取締役社長さん。

日本語の情報はかなり少ない中で、かなり技術的な話がわかりやすく書かれています。

SkyWayの中の人

こちらも、貴重な日本語情報です。

その他

今更ながら HTTP/2 について調べてまとめてみた

この記事の目的

今更ながら HTTP/2 がどのようなものかを調べたくなったので、その結果をまとめた記事になります。 あくまで概要をまとめたもので、今はたくさんの良記事があるので、詳細が知りたい場合は最後の参考文献のリンク先を見ると参考になると思います。

HTTP/2 の特徴

  • ストリームという概念を導入したことで HTTP/1.1 に比べて効率的に通信できます
  • ヘッダー圧縮を行うことで HTTP/1.1 より通信量を減らすことができます
  • サーバープッシュによりリクエストされる前にサーバーからリソースを送信することで HTTP/1.1 よりラウンドトリップ回数を減らすことができます
  • HTTP/1.1 と互換性があります
  • 事実上 TLS による暗号化が必須になります
  • モダンブラウザは対応済です (最新の対応状況は Can I Use で確認してください)

ストリームとは?

HTTP/1.1 の欠点

HTTP/1.1 では、1回目のリクエスト→1回目のレスポンス→2回目のリクエスト→・・・というように、一度リクエストをするとそのレスポンスを受け取ってから次のリクエストを行う必要があります。 大量の画像やファイルで構成されているページを表示する際には、この制約が大きなネックになります。そのため、モダンブラウザでは複数のコネクションを同時に使用することで高速化を図っているそうです。 また、HTTP/1.1 では HTTP パイプラインという高速化手法もありますが、問題があることから、ほとんどのブラウザでは既定で無効になっています。

ストリームを導入することでどう変わるか?

ストリームとは、1つのコネクションの中に独立した複数の仮想的なコネクションのようなものがあり、リクエストとレスポンスを並列で行えるようになるため、1つのコネクションで効率的に通信が行えるようになります。

ヘッダー圧縮とは?

HTTP/1.1 は数百バイト〜数KBあるヘッダーを非圧縮かつ全てのヘッダーを毎回送受信する必要があります。 HTTP/2 では HPACK という圧縮方式を使用し、データ自体を圧縮するとともに、ヘッダーのキャッシュを行うことで差分のみを送受信することが可能になり、ヘッダーを効率よくやり取りできます。

サーバープッシュとは?

HTTP/1.1 では、通常最初に HTML ファイルを受け取ってから、再度描画に必要なリソースをリクエストする、という形になっています。 HTTP/2 では、リクエストに対し(クライアントからのリクエスト無しに)予めサーバーから必要と思われるリソースを送信することが可能になっています。 これにより、ラウンドトリップ回数を減らし、リソースの読み込みまでの時間を短縮することができます。

HTTP/1.1 との互換性

HTTP/2 通信を開始する際は、最初に従来どおりの HTTP リクエストの中に、以下のヘッダー情報を加えて送信し、サーバーから 101 Switching Protocols のレスポンスを受け取ってから HTTP/2 の通信を開始することで、互換性を保っています。

  • Connection: Upgrade, HTTP2-Settings
  • Upgrade: h2c

HTTP/2 を使うメリット

HTTP/2 はここまでの説明の通り、様々な手法で効率よく通信を行えるようになるため、 HTTP/1.1 よりページの読み込み時間が短縮されることが、最大のメリットだと思います。 また HTTP/1.1 との互換性があるため、HTTP/2 非対応のブラウザであってもアクセス可能であるため、導入が容易であることもメリットであると思います。

HTTP/2 を使うデメリット

全てのサイトで高速化されるわけではないことだと思います。例えば、もともと必要なソースが少なく、リクエスト数が少ない場合はあまり恩恵が受けられないと思います。 ただ、遅くなるわけではないので、デメリットという程でもないかと思います。 あとは HTTP/2 に対応する作業コストといったところかと思いますので、実質デメリットはないかな、と思いました。

調べてみた感想

HTTP というプロトコルはステートレスでシンプルなプロトコルが最大の特徴だと個人的には思っているのですが、HTTP/2 は結構複雑だな、という印象です。ヘッダーの圧縮とか、ステートレスな点もありますし。 ただそれも、HTTP が世界で圧倒的に普及した結果、僅かな高速化でも大きな影響があるため、あらゆる手法を取り入れていこうとした結果なのだろうな、とも思います。 デメリットもほぼないと言っても良さそうなので、利用できる時は積極的に使っていくべき技術だと感じました。

参考文献