HTML TableにもAPIがあるのをご存じですか？

 (christianheilmann.com)
13 ポイント 投稿者 GN⁺ 2025-11-02 | 2件のコメント | WhatsAppで共有
  • HTMLTableElement API はかなり前から存在するものの、ほとんど使われていない HTMLテーブル操作用の組み込みインターフェース
  • このAPIを使うと tbody, thead, tfoot, caption, row, cell などを直接生成・参照でき、変更時にもテーブル全体を再レンダリングする必要がない
  • サンプルコードでは ネストした配列データをテーブルに変換し、insertRow() と insertCell() を通じて行とセルを追加する方法を示している
  • t.rows[1].cells[1] のように インデックスでセルにアクセスしたり、insertRow(-1) で 最後の行を追加したりと、さまざまな操作が可能
  • 筆者は、このAPIには データ構造としてのテーブル機能を拡張できる可能性 があり、フォーム(form)のようにイベントや追加機能を持たせる余地があると述べている

HTMLテーブルAPIの概要

  • ほとんどの開発者は DOMメソッド(createElement など) または innerHTML 文字列挿入 でテーブルを生成するが、後者には セキュリティ上のリスク がある
  • HTMLには古くから HTMLTableElement API があり、これを通じてテーブルの 本文、行、セル、ヘッダー、フッター、キャプション、要約(summary) などを扱える
  • このAPIでは テーブル全体を再レンダリングせずに 個々の要素を操作できる

コード例: 配列からテーブルを生成

  • 例では次のような ネストした配列 をテーブルに変換する
    • [['one','two','three'], ['four','five','six']]
  • document.createElement('table') でテーブルを作成し、各行(insertRow)とセル(insertCell)をループで追加する
  • 各セルの内容は innerText で設定する

セルへのアクセスと修正

  • 生成されたテーブルのセルには インデックスベースでアクセス できる
    • 例: t.rows[1].cells[1] → <td>five</td>
  • 行やセルを 削除したり新たに追加 したりすることもできる
    • 例: t.insertRow(-1) で末尾に行を追加
    • t.rows[2].insertCell(0) で新しいセルを作成し、innerText = 'foo' で値を設定

APIの限界

  • insertRow(-1) のような 直感的でないインデックス規則 がある
  • TH 要素を直接生成する方法がなく、すべてのセルが TD として扱われる

今後の拡張可能性

  • 筆者は、テーブル生成が煩雑なのが現状だと指摘し、このAPIを見直して機能を拡張する必要性 を提起している
  • HTMLフォームに formData や changeイベント が追加されたように、テーブルにも イベントや高度な機能 を導入できると述べている
  • これにより、テーブルは単なる レイアウトツールではなくデータ構造 としての地位を持ちうる

関連記事

2件のコメント

 
sonnet 2025-11-04

比較的経験の浅い開発者として、最初から使ってきたAPIをまるで「発掘」したかのように語る文章には驚かされます。
 
GN⁺ 2025-11-02
Hacker Newsの意見

  • 多くの人は記事をきちんと読んでいないように見える この投稿の要点は `` タグ自体ではなく、table専用のDOMインターフェースにある たとえば HTMLTableElement.prototype.insertRow() や HTMLTableRowElement.prototype.insertCell() のようなメソッドは、createElement() や appendChild() より直感的だ ただし React、Svelte、Vue のような ライブラリベースのUI では、こうしたメソッドはほとんど使われなくなった HTMLの文法と同様に、thead、tbody、tfoot を省略しても自動で処理される点は興味深い 自分はここ5年ほどのデモスクリプトで .insertRow、.insertCell、.createTHead、.rows、.cells を直接使ったことがある コードスタイルの面では、forEach の代わりに for を使い、インデックス引数を省くほうがすっきりしていると思う

    • 今ではフレームワークが 基本的なDOM操作 を置き換えすぎていて、こうした基礎を知っている人が珍しくなった気がする `` タグが最初に追加されたという C|net の記事を読んでいたころを思い出す。自分ももうかなり年を取ったようだ

  • 半年ほど前に MDN のドキュメントを見るか、AI に勧められてこの API を使った記憶がある rows と cells プロパティは キーボードナビゲーション の実装に非常に便利だった 関連する例は ClickHouse のコード で見られる

    • 最近のWebでいちばん残念なのは、divでテーブルを作る人たち だ ソートもできず、特に M365 Admin のようにテーブル実装がひどい例が多い

  • ボタンに関する議論（以前のスレッド）と似た文脈だ 10〜15年ほど前から、すべてが `` に置き換わり、セマンティックマークアップ の代わりに HTML を UI ツールボックスのように使うようになった

    • DOM が本来 セマンティックな文書 ではなくレンダリング対象として使われているからだ セマンティックHTMLは良い考えだが、現実にはあまり期待できない しかもセマンティック要素にはデフォルトスタイルがあるので、開発者は中立的な を好むようになる 実際、 と `` を分けていること自体が 設計ミス だと思う
    • 20年以上 HTML を使ってきたが、自分の経験では大半の人は今でも 意味のあるタグ をきちんと使っている もちろん何でも div で済ませる人もいるが、ボタンのようなものはたいてい正しく書かれている
    • こうした変化は避けられなかったと思う Web コンテンツの大半は マーケティング中心 で、企業は望んだ形で表示されることを求めるからだ 技術文書のための別個の DocBook Web があれば、ユーザーが自分でスタイルを適用できて面白いかもしれない

  • Stable Diffusion の画像比較ツールを作ったときにこの API を使ったことがある 行と列が多く、テーブルを頻繁に再生成する必要があったが、文字列でまとめて生成する方式より DOM 更新のほうが遅い 各 API 呼び出しが DOM を即座に更新するためだと思われる

  • 「テーブル全体を再レンダリングしなくてよい」という説明があったが、実際には標準の DOM メソッドもすでにそのように動作する それでも 退屈なDOM探索 を減らせる点はかなり良い

    • WebKit のコードを見てみると、内部では同じロジックが動いていて、性能差はほとんどない

  • HTML form API ももう一度 再発見 される必要がある

  • テーブルの問題はデータを埋めることではなく、検索・ソート・フィルタリング機能がまったくないこと だ

    • 何と比べてそう言っているのか気になる テーブルでもそうした機能を実装できない理由はないと思う

  • 「この API は捨てられた」という言い方が理解できない 自分はいまでも HTML テーブルを作るときによく使っている

    • ‘Abandonware’ という表現はもともと ライセンスの文脈 で使われる用語なので、ここではやや大げさなタイトルだ 著者はこの API が 拡張の余地がある古い領域 だと言いたかったのだろう form API のように、テーブルにもソートやフィルタリングのような機能を追加できると思う
    • 今では大半が React や Svelte のような 宣言的UIフレームワーク を使うため、こうした命令的 DOM API はますますニッチな領域になっている
    • ひと言でいえば、今は Reactの時代 だ

  • サンプルコードは興味深いが、変数名を省略しすぎていて可読性が低い b、t、r、c の代わりに 意味のある名前 を使うほうがよい

    • こうした議論は結局 自転車置き場の議論 のように些細な部分に集中している感じがする
    • 短いスコープでは短い変数名を使うのが自然だ
    • それでも1文字の変数名は 誤った最適化 だと思う Haskell を使う立場として特に共感する
    • 短い名前そのものより、(ri, i) のような インデックスの混在 のほうが紛らわしい 似た役割の変数は長さもそろえたほうがよい
    • let b = document.body; のような行は特に読みにくい 数バイト節約するために 認知負荷 だけが増えている