▲

HTML Table에도 API가 있다는 사실을 아시나요?

 (christianheilmann.com)
10P by GN⁺ 23시간전 | ★ favorite | 댓글 1개
  • 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 이벤트가 추가된 것처럼, 테이블에도 이벤트나 고급 기능을 도입할 수 있다고 언급
  • 이를 통해 테이블이 단순한 레이아웃 도구가 아닌 데이터 구조로서의 지위를 가질 수 있음
▲
GN⁺ 23시간전  [-]
Hacker News 의견

  • 많은 사람들이 기사를 제대로 읽지 않은 것 같음
    이 글의 핵심은 <table> 태그 자체가 아니라 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 조작을 대체해버려서, 이런 기본기를 아는 사람이 드물어진 느낌임
      <table> 태그가 처음 추가됐다는 C|net 기사를 읽던 때가 생각남. 나도 이제 꽤 나이 든 듯함

  • 반년 전쯤 MDN 문서를 보거나 AI가 추천해서 이 API를 썼던 기억이 있음
    rows와 cells 속성은 키보드 네비게이션 구현에 매우 편리했음
    관련 예시는 ClickHouse 코드에서 볼 수 있음

    • 요즘 웹에서 제일 안타까운 건 div로 테이블을 만드는 사람들임
      정렬도 안 되고, 특히 M365 Admin처럼 테이블 구현이 엉망인 사례가 많음

  • 버튼 관련 논의(이전 스레드)와 비슷한 맥락임
    10~15년 전쯤부터 모든 게 <div>로 바뀌면서 시맨틱 마크업 대신 UI 도구 상자처럼 HTML을 쓰게 되었음

    • DOM이 본래 시맨틱 문서가 아니라 렌더링 타깃으로 쓰이기 때문임
      시맨틱 HTML은 좋은 개념이지만 현실적으로는 기대하기 어려움
      게다가 시맨틱 요소들은 기본 스타일이 있어서, 개발자들이 중립적인 <div>를 선호하게 됨
      사실 <div>와 <span>을 따로 둔 것도 디자인 실수라고 생각함
    • 20년 넘게 HTML을 써왔지만, 내 경험상 대부분은 여전히 의미 있는 태그를 잘 사용함
      물론 일부는 모든 걸 div로 처리하지만, 버튼 같은 경우는 대체로 올바르게 작성함
    • 이런 변화는 불가피했다고 봄
      웹의 대부분 콘텐츠가 마케팅 중심이라, 기업들은 원하는 형태로 보여지길 원함
      기술 문서를 위한 별도의 DocBook 웹이 있다면, 사용자가 직접 스타일을 적용할 수 있어 흥미로울 것 같음

  • Stable Diffusion 이미지 비교용 툴을 만들 때 이 API를 써봤음
    행과 열이 많아서 테이블을 자주 재생성해야 했는데, 문자열로 한 번에 만드는 방식보다 DOM 업데이트가 느림
    각 API 호출이 DOM을 즉시 갱신하기 때문인 듯함

  • “전체 테이블을 다시 렌더링하지 않아도 된다”는 설명이 있었는데, 사실 표준 DOM 메서드도 이미 그렇게 동작함
    그래도 지루한 DOM 탐색을 줄일 수 있다는 점은 꽤 멋짐

    • WebKit 코드를 살펴보니, 내부적으로는 동일한 로직이 돌아가서 성능 차이는 거의 없음

  • HTML form API도 다시 재발견할 필요가 있음

  • 테이블의 문제는 데이터를 채우는 게 아니라, 검색·정렬·필터링 기능이 전혀 없다는 점임

    • 어떤 것과 비교해서 그런 말인지 궁금함
      테이블에서도 그런 기능을 구현하지 못할 이유는 없다고 생각함

  • “이 API가 버려졌다”는 말이 이해되지 않음
    나는 여전히 HTML 테이블을 만들 때 자주 사용함

    • ‘Abandonware’라는 표현은 원래 라이선스 맥락에서 쓰이는 용어라, 여기서는 다소 과장된 제목임
      저자는 이 API가 확장 여지가 있는 오래된 영역이라고 말하고 싶었던 듯함
      폼 API처럼 테이블에도 정렬·필터링 같은 기능이 추가될 수 있다고 봄
    • 요즘은 대부분 React나 Svelte 같은 선언형 UI 프레임워크를 쓰기 때문에, 이런 명령형 DOM API는 점점 틈새 영역이 됨
    • 한마디로, 지금은 React 시대임

  • 예시 코드는 흥미롭지만, 변수명을 너무 줄여서 가독성이 떨어짐
    b, t, r, c 대신 의미 있는 이름을 쓰는 게 좋음

    • 이런 논의는 결국 자전거 보관소 논쟁처럼 사소한 부분에 집중하는 느낌임
    • 짧은 스코프에서는 짧은 변수명을 쓰는 게 자연스러움
    • 그래도 한 글자 변수명은 잘못된 최적화라고 생각함
      Haskell을 쓰는 입장에서 특히 공감함
    • 짧은 이름 자체보다 (ri, i)처럼 인덱스 혼용이 더 헷갈림
      비슷한 역할의 변수는 길이도 통일하는 게 좋음
    • let b = document.body; 같은 줄은 특히 읽기 힘듦
      몇 바이트 아끼려다 인지 부하만 커짐
답변달기