Bạn có biết bảng HTML cũng có API không?

 (christianheilmann.com)
13 điểm bởi GN⁺ 2025-11-02 | 2 bình luận | Chia sẻ qua WhatsApp
  • API HTMLTableElement đã tồn tại từ lâu nhưng là giao diện tích hợp sẵn để thao tác bảng HTML hầu như không được sử dụng
  • Với API này, có thể trực tiếp tạo và truy cập tbody, thead, tfoot, caption, row, cell mà không cần render lại toàn bộ bảng mỗi khi thay đổi
  • Đoạn mã ví dụ cho thấy cách chuyển dữ liệu mảng lồng nhau thành bảng và thêm hàng, ô bằng insertRow() và insertCell()
  • Có thể truy cập ô theo chỉ số như t.rows[1].cells[1], hoặc thao tác đa dạng như thêm hàng cuối cùng bằng insertRow(-1)
  • Tác giả cho rằng API này có tiềm năng mở rộng chức năng của bảng như một cấu trúc dữ liệu, và có thể bổ sung sự kiện hay tính năng như với form

Tổng quan về API bảng HTML

  • Phần lớn lập trình viên tạo bảng bằng các phương thức DOM (createElement v.v.) hoặc chèn chuỗi innerHTML, nhưng cách sau có rủi ro bảo mật
  • HTML có API HTMLTableElement lâu đời, cho phép xử lý phần thân bảng, hàng, ô, tiêu đề đầu, chân bảng, caption, tóm tắt (summary)
  • API này cho phép thao tác từng phần tử mà không cần render lại toàn bộ bảng

Ví dụ mã: tạo bảng từ mảng

  • Ví dụ chuyển mảng lồng nhau sau thành bảng
    • [['one','two','three'], ['four','five','six']]
  • Tạo bảng bằng document.createElement('table'), rồi lặp để thêm từng hàng (insertRow) và ô (insertCell)
  • Nội dung mỗi ô được đặt bằng innerText

Truy cập và chỉnh sửa ô

  • Có thể truy cập ô của bảng đã tạo theo chỉ số
    • Ví dụ: t.rows[1].cells[1] → <td>five</td>
  • Cũng có thể xóa hoặc thêm mới hàng và ô
    • Ví dụ: thêm hàng ở cuối bằng t.insertRow(-1)
    • Tạo ô mới bằng t.rows[2].insertCell(0) rồi gán giá trị với innerText = 'foo'

Giới hạn của API

  • Có các quy tắc chỉ số khó trực quan như insertRow(-1)
  • Không có cách tạo trực tiếp phần tử TH, mọi ô đều được xử lý thành TD

Khả năng mở rộng trong tương lai

  • Tác giả chỉ ra việc tạo bảng hiện nay khá phiền phức và đề xuất cần xem xét lại API này để mở rộng tính năng
  • Giống như HTML form đã được bổ sung formData hay sự kiện change, bảng cũng có thể được thêm sự kiện hoặc tính năng nâng cao
  • Nhờ đó, bảng có thể có vị thế như một cấu trúc dữ liệu chứ không chỉ là công cụ bố cục

Bài viết liên quan

2 bình luận

 
sonnet 2025-11-04

Là một lập trình viên còn tương đối ít kinh nghiệm, tôi thấy ngạc nhiên trước những bài viết nói về một API đã được dùng từ đầu như thể vừa mới "khai quật" ra nó.
 
GN⁺ 2025-11-02
Ý kiến trên Hacker News

  • Có vẻ nhiều người đã không đọc kỹ bài viết Điểm cốt lõi của bài này không phải là chính thẻ ``, mà là giao diện DOM dành riêng cho table Ví dụ, các phương thức như HTMLTableElement.prototype.insertRow() hay HTMLTableRowElement.prototype.insertCell() trực quan hơn createElement() hoặc appendChild() Tuy nhiên, trong UI dựa trên thư viện như React, Svelte, Vue, những phương thức này hầu như không còn được dùng nữa Điều thú vị là cũng giống cú pháp HTML, dù bỏ qua thead, tbody, tfoot thì chúng vẫn được xử lý tự động Trong 5 năm gần đây, tôi đã trực tiếp dùng .insertRow, .insertCell, .createTHead, .rows, .cells trong các script demo Về phong cách viết code, tôi thấy dùng for thay vì forEach, và bỏ tham số chỉ số đi thì gọn gàng hơn

    • Dạo này framework đã thay thế quá nhiều thao tác DOM cơ bản, nên có cảm giác ngày càng hiếm người nắm những kiến thức nền này Tôi nhớ hồi đọc bài trên C|net khi thẻ `` vừa được thêm vào. Chắc tôi cũng già đi khá nhiều rồi

  • Tôi nhớ khoảng nửa năm trước đã dùng API này sau khi đọc tài liệu MDN hoặc được AI gợi ý Thuộc tính rows và cells rất tiện để triển khai điều hướng bằng bàn phím Có thể xem ví dụ liên quan trong mã nguồn ClickHouse

    • Điều đáng tiếc nhất trên web hiện nay là những người làm bảng bằng div Không sắp xếp được, và đặc biệt có nhiều trường hợp triển khai bảng rất tệ như M365 Admin

  • Đây là câu chuyện cùng mạch với tranh luận về button (chuỗi trước) Từ khoảng 10–15 năm trước, mọi thứ dần chuyển sang ``, và HTML bị dùng như một hộp công cụ UI thay vì semantic markup

    • Vì DOM vốn được dùng như mục tiêu render hơn là một tài liệu ngữ nghĩa Semantic HTML là một ý tưởng hay, nhưng trên thực tế khó mà kỳ vọng nhiều Hơn nữa, các phần tử semantic có sẵn style mặc định, nên lập trình viên thường thích trung tính hơn Thật ra tôi còn nghĩ việc tách riêng và `` cũng là một lỗi thiết kế
    • Tôi đã dùng HTML hơn 20 năm, và theo kinh nghiệm của tôi thì phần lớn mọi người vẫn dùng thẻ có ý nghĩa khá đúng cách Tất nhiên có người xử lý mọi thứ bằng div, nhưng với những thứ như button thì nhìn chung vẫn viết đúng
    • Tôi cho rằng sự thay đổi này là không thể tránh khỏi Phần lớn nội dung trên web mang tính marketing, nên doanh nghiệp muốn nó hiển thị đúng theo hình thức họ mong muốn Nếu có một web DocBook riêng cho tài liệu kỹ thuật, nơi người dùng có thể tự áp style, thì có lẽ sẽ khá thú vị

  • Tôi đã dùng API này khi làm công cụ so sánh ảnh Stable Diffusion Vì có rất nhiều hàng và cột nên phải tái tạo bảng thường xuyên, nhưng cập nhật DOM chậm hơn so với cách dựng toàn bộ bằng chuỗi một lần Có lẽ vì mỗi lần gọi API đều cập nhật DOM ngay lập tức

  • Có đoạn giải thích rằng “không cần render lại toàn bộ bảng”, nhưng thật ra các phương thức DOM tiêu chuẩn vốn đã hoạt động như vậy Dù vậy, việc giảm bớt khâu duyệt DOM nhàm chán vẫn khá hay

    • Tôi đã xem mã WebKit, và bên trong vẫn chạy cùng một logic nên gần như không có khác biệt về hiệu năng

  • API của HTML form cũng cần được tái khám phá

  • Vấn đề của table không phải là điền dữ liệu, mà là hoàn toàn không có tính năng tìm kiếm, sắp xếp, lọc

    • Tôi tò mò là đang so với cái gì Tôi không thấy có lý do gì mà table lại không thể triển khai những tính năng đó

  • Tôi không hiểu câu “API này đã bị bỏ rơi” Tôi vẫn thường xuyên dùng nó khi tạo bảng HTML

    • Cách diễn đạt ‘Abandonware’ vốn là thuật ngữ dùng trong ngữ cảnh giấy phép/phần mềm, nên ở đây là một tiêu đề hơi cường điệu Có lẽ tác giả muốn nói rằng đây là một mảng cũ vẫn còn chỗ để mở rộng Tôi nghĩ table cũng có thể được bổ sung các tính năng như sắp xếp, lọc, giống API của form
    • Hiện nay đa số dùng framework UI khai báo như React hay Svelte, nên các DOM API kiểu mệnh lệnh này dần trở thành lĩnh vực ngách
    • Tóm lại, bây giờ là thời đại của React

  • Mã ví dụ thì thú vị, nhưng tên biến bị rút gọn quá mức nên khó đọc Tốt hơn nên dùng tên có ý nghĩa thay vì b, t, r, c

    • Những tranh luận kiểu này cuối cùng lại giống tranh cãi chuyện vặt vậy
    • Trong phạm vi ngắn thì dùng tên biến ngắn là điều tự nhiên
    • Dù vậy, tôi vẫn nghĩ tên biến một ký tự là một kiểu tối ưu hóa sai lầm Với người dùng Haskell như tôi thì điều này càng dễ đồng cảm
    • So với tên ngắn, thứ gây rối hơn là kiểu trộn lẫn chỉ số như (ri, i) Các biến có vai trò tương tự thì độ dài tên cũng nên thống nhất
    • Những dòng như let b = document.body; đặc biệt khó đọc Tiết kiệm vài byte nhưng lại chỉ làm tăng gánh nặng nhận thức