คุณรู้หรือไม่ว่า 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 นี้มี ศักยภาพในการขยายความสามารถของตารางในฐานะโครงสร้างข้อมูล และยังมีช่องให้เพิ่ม event หรือความสามารถเสริมแบบเดียวกับ form ได้

ภาพรวมของ HTML Table API

  • นักพัฒนาส่วนใหญ่สร้างตารางด้วย เมธอด DOM (createElement เป็นต้น) หรือ แทรกสตริงด้วย innerHTML แต่แบบหลังมี ความเสี่ยงด้านความปลอดภัย
  • ใน HTML มี HTMLTableElement API แบบเก่าอยู่แล้ว ซึ่งช่วยให้จัดการ เนื้อหาตาราง, แถว, เซลล์, ส่วนหัว, ส่วนท้าย, caption, 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 form มี formData หรือ change event เพิ่มเข้ามา ตารางก็อาจรองรับ event หรือความสามารถขั้นสูง ได้เช่นกัน
  • สิ่งนี้อาจทำให้ตารางมีสถานะเป็น โครงสร้างข้อมูล ไม่ใช่แค่เครื่องมือจัดเลย์เอาต์เท่านั้น

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
sonnet 2025-11-04

ในฐานะนักพัฒนาที่มีประสบการณ์ค่อนข้างน้อย ผมรู้สึกทึ่งกับบทความที่พูดถึง API ซึ่งใช้งานกันมาตั้งแต่แรก ราวกับเพิ่งไป "ค้นพบ" มันมา
 
GN⁺ 2025-11-02
ความเห็นจาก Hacker News

  • ดูเหมือนหลายคนจะไม่ได้อ่านบทความอย่างละเอียด ประเด็นสำคัญของบทความนี้ไม่ใช่ตัวแท็ก `` เอง แต่เป็น DOM interface สำหรับ table โดยเฉพาะ ตัวอย่างเช่น เมธอดอย่าง HTMLTableElement.prototype.insertRow() หรือ HTMLTableRowElement.prototype.insertCell() ใช้งานได้เข้าใจกว่า createElement() หรือ appendChild() แต่ใน UI แบบอิงไลบรารี อย่าง React, Svelte, Vue ทุกวันนี้แทบไม่ค่อยได้ใช้เมธอดพวกนี้แล้ว สิ่งที่น่าสนใจคือมันจัดการให้อัตโนมัติได้แม้จะละ thead, tbody, tfoot เหมือนไวยากรณ์ HTML ในช่วง 5 ปีที่ผ่านมา ฉันเคยใช้ .insertRow, .insertCell, .createTHead, .rows, .cells โดยตรงในสคริปต์เดโมอยู่บ้าง ในแง่สไตล์โค้ด ฉันคิดว่าการใช้ for แทน forEach และตัดอาร์กิวเมนต์ index ออกจะดูสะอาดกว่า

    • ทุกวันนี้เฟรมเวิร์กเข้ามาแทนที่ การจัดการ DOM พื้นฐาน มากเกินไป จนรู้สึกว่าคนที่รู้พื้นฐานแบบนี้มีน้อยลง ทำให้นึกถึงตอนที่อ่านข่าว C|net ว่าแท็ก `` ถูกเพิ่มเข้ามาใหม่ ตอนนี้ฉันก็คงอายุมากพอสมควรแล้วเหมือนกัน

  • จำได้ว่าเคยใช้ API นี้เมื่อราวครึ่งปีก่อน เพราะเห็นจากเอกสาร MDN หรือไม่ก็ AI แนะนำ พร็อพเพอร์ตี rows กับ cells สะดวกมากสำหรับการทำ คีย์บอร์ดเนวิเกชัน ตัวอย่างที่เกี่ยวข้องดูได้จาก โค้ดของ ClickHouse

    • สิ่งที่น่าเสียดายที่สุดบนเว็บทุกวันนี้คือ คนที่ทำตารางด้วย div มันจัดเรียงก็ไม่ได้ และโดยเฉพาะเคสอย่าง M365 Admin ก็มีตัวอย่างการทำตารางที่เละเทะมาก

  • เป็นบริบทคล้ายกับการถกเรื่องปุ่ม(เธรดก่อนหน้า) ตั้งแต่ราว 10~15 ปีก่อน ทุกอย่างเริ่มกลายเป็น `` หมด จน HTML ถูกใช้เหมือนกล่องเครื่องมือทำ UI แทนที่จะเป็น semantic markup

    • เพราะเดิมที DOM ถูกใช้เป็นเป้าหมายของการเรนเดอร์ ไม่ใช่ เอกสารเชิงความหมาย semantic HTML เป็นแนวคิดที่ดี แต่ในทางปฏิบัติคาดหวังได้ยาก แถมองค์ประกอบเชิงความหมายยังมีสไตล์ตั้งต้นติดมาด้วย เลยทำให้นักพัฒนาชอบ ที่เป็นกลางมากกว่า จริง ๆ แล้วฉันคิดว่าการแยก กับ `` ออกเป็นคนละอย่างก็เป็น ความผิดพลาดด้านการออกแบบ
    • แม้จะใช้ HTML มานานกว่า 20 ปี แต่จากประสบการณ์ของฉัน คนส่วนใหญ่ก็ยังใช้ แท็กที่มีความหมาย กันอยู่ แน่นอนว่ามีบางคนใช้ div กับทุกอย่าง แต่กรณีอย่างปุ่ม ส่วนมากก็ยังเขียนกันถูกต้อง
    • ฉันมองว่าการเปลี่ยนแปลงนี้หลีกเลี่ยงไม่ได้ เพราะคอนเทนต์ส่วนใหญ่บนเว็บเป็นแบบ เน้นการตลาด บริษัทต่าง ๆ เลยอยากให้มันแสดงผลในแบบที่ตัวเองต้องการ ถ้ามีเว็บ DocBook แยกต่างหากสำหรับเอกสารเทคนิค ที่ผู้ใช้สามารถลงสไตล์เองได้ ก็น่าจะน่าสนใจดี

  • ตอนทำเครื่องมือเปรียบเทียบภาพของ Stable Diffusion ฉันเคยใช้ API นี้ เพราะมีทั้งหลายแถวและหลายคอลัมน์จนต้องสร้างตารางใหม่บ่อย ๆ แต่ การอัปเดต DOM ช้ากว่า วิธีสร้างเป็นสตริงทีเดียว น่าจะเป็นเพราะแต่ละการเรียก API ทำให้ DOM อัปเดตทันที

  • มีคำอธิบายว่า “ไม่จำเป็นต้อง re-render ทั้งตาราง” แต่จริง ๆ แล้วเมธอด DOM มาตรฐานก็ทำงานแบบนั้นอยู่แล้ว ถึงอย่างนั้น การลด การไล่สำรวจ DOM ที่น่าเบื่อ ได้ก็ถือว่าเจ๋งมาก

    • ฉันไปดูโค้ดของ WebKit มาแล้ว ภายในก็ใช้ลอจิกแบบเดียวกัน จึงแทบ ไม่มีความต่างด้านประสิทธิภาพ

  • HTML form API ก็ควรถูก ค้นพบใหม่ อีกครั้งเหมือนกัน

  • ปัญหาของตารางไม่ใช่เรื่องการใส่ข้อมูล แต่คือมัน ไม่มีความสามารถด้านค้นหา·จัดเรียง·กรองเลย

    • อยากรู้ว่าเป็นคำพูดที่เทียบกับอะไร ฉันไม่เห็นเหตุผลว่าทำไมฟีเจอร์พวกนั้นจะทำบนตารางไม่ได้

  • ฉันไม่เข้าใจคำพูดที่ว่า “API นี้ถูกทิ้งร้างแล้ว” ฉันยังใช้มันบ่อยอยู่เวลาสร้างตาราง HTML

    • คำว่า ‘Abandonware’ เดิมทีเป็นคำที่ใช้ใน บริบทเรื่องไลเซนส์ ดังนั้นเอามาใช้ตรงนี้ถือว่าเป็นชื่อที่ค่อนข้างพูดเกินจริง ดูเหมือนผู้เขียนต้องการจะสื่อว่ามันเป็น พื้นที่เก่าแก่ที่ยังขยายต่อได้ มากกว่า เหมือนกับ form API ตารางก็น่าจะเพิ่มความสามารถอย่างการจัดเรียงหรือกรองได้
    • ทุกวันนี้คนส่วนใหญ่ใช้ declarative UI framework อย่าง React หรือ Svelte กัน ดังนั้น DOM API แบบ imperative พวกนี้จึงค่อย ๆ กลายเป็นเรื่องเฉพาะทาง
    • พูดสั้น ๆ ก็คือ ตอนนี้มันคือ ยุคของ React

  • โค้ดตัวอย่างน่าสนใจ แต่ย่อชื่อตัวแปรมากเกินไปจนอ่านยาก ควรใช้ ชื่อที่มีความหมาย แทน b, t, r, c

    • สุดท้ายแล้วการถกแบบนี้ก็ให้ความรู้สึกเหมือน ข้อถกเถียงโรงเก็บจักรยาน ที่ไปโฟกัสกับรายละเอียดเล็กน้อยเกินไป
    • ในสโคปสั้น ๆ การใช้ชื่อตัวแปรสั้น ๆ ก็เป็นเรื่องธรรมชาติ
    • ถึงอย่างนั้น ฉันก็ยังคิดว่าชื่อตัวแปรตัวเดียวเป็น การปรับให้เหมาะสมผิดจุด ในฐานะคนที่ใช้ Haskell ฉันยิ่งเห็นด้วยมาก
    • สิ่งที่ทำให้งงมากกว่าชื่อสั้นคือการใช้ index ปะปนกัน อย่าง (ri, i) ถ้าตัวแปรมีบทบาทคล้ายกัน ก็ควรให้ความยาวชื่อสอดคล้องกันด้วย
    • บรรทัดอย่าง let b = document.body; อ่านยากเป็นพิเศษ ประหยัดไปไม่กี่ไบต์ แต่กลับเพิ่ม ภาระทางความคิด เท่านั้น