모든 HTML 요소가 포함된 블로그 포스트

 (patrickweaver.net)
5P by GN⁺ | ★ favorite | 댓글 1개
  • 웹 접근성을 공부하던 Patrick Weaver는 Eleventy 기반 개인 사이트에서 100개 이상의 HTML 태그를 실제 페이지에 적용하며 의미론적 HTML을 실험함
  • 처음 목표는 향후 글 작성 때 낯선 요소의 CSS 때문에 발목 잡히지 않는 것이었지만, 이 한 글을 완성하는 데 1년 반이 걸림
  • MDN Web Docs의 HTML 요소 목록을 기준으로 <article>, <main>, <nav>, <section>, <search>, <hgroup> 같은 구조 요소를 재검토함
  • <bdi>, <ruby>, <samp>, <wbr>, <dialog>, <template> 등 덜 익숙한 요소는 방향성, 발음 표기, 프로그램 출력, 줄바꿈, 상호작용, 웹 컴포넌트 같은 구체적 사용처를 드러냄
  • 브라우저 지원, 정적 사이트 생성, Safari 비디오 재생, deprecated 태그 동작처럼 HTML의 의미와 실제 구현 사이에는 호환성의 흔적이 남아 있음

실험의 출발점과 목표

  • 웹 접근성을 더 배운 뒤, 흔히 쓰지 않는 HTML 요소를 살펴보고 개인 사이트에 반영하기 시작함
  • 사이트는 Eleventy로 만들어졌고, 블로그 글 본문을 <article>로 감싸며 레이아웃 템플릿에 <main>을 추가함
  • 이미지 캡션을 위해 <figure>와 <figcaption> 스타일을 이미 다듬었고, Recurse 관련 footnote 또는 sidenote 구현에도 흥미를 느낌
  • MDN Web Docs의 HTML 요소 목록을 기준으로 모든 요소를 한 글에서 써보기로 함
    • 목표는 앞으로 글을 쓸 때 이전에 쓰지 않은 요소 때문에 CSS 업데이트가 지연되지 않게 하는 것이었음
    • 실제로는 이 글 하나를 위해 스타일과 템플릿을 고치는 데 1년 반이 걸림
  • <html>처럼 글 본문에 직접 넣기 어려운 요소도 있지만, patrickweaver.net에서 보면 페이지 어딘가에 모든 요소가 쓰이도록 구성함

문서 구조와 메타데이터 요소

  • <html>에는 별도 변경이 필요 없었지만, lang="en" 같은 lang 속성을 항상 기억하지 못한다는 점을 확인함
  • <base>는 이 글을 쓰기 전에는 익숙하지 않았고, 이후 상대 링크와 함께 레이아웃 템플릿에 추가함
    • 로컬 개발과 상대 링크에서 몇 가지 문제가 생겼지만 쉽게 해결됨
    • <head>, <link>, <meta>, <style>, <title>은 이미 익숙하고 사이트에 존재하던 요소였음
  • <body> 문서를 읽으며 onbeforeprint, onblur 같은 속성을 접함
    • onbeforeprint는 이전에 더 우회적인 방식으로 처리했던 기능과 관련됨
    • onblur는 주 용도가 성가신 팝업처럼 보였음

콘텐츠 섹션과 제목 계층

  • <address>는 우편 주소 전용이라고 생각했지만, 이메일 주소와 링크에도 쓸 수 있음을 알게 됨
  • 블로그 포스트 템플릿에는 이미 <article>을 적용했고, 문서를 읽은 뒤 사이트의 모든 페이지에도 맞을 수 있는지 고민함
  • footnote 영역에는 <aside>를 사용함
    • <aside>는 문서의 주요 내용과 간접적으로 관련된 부분을 나타냄
    • 향후 sidenote처럼 스타일링할 가능성을 남김
  • 사이트 디자인에는 원래 <footer>가 없었지만 이 글에는 추가함
  • <header>는 페이지 상단에만 쓰고 있었으나, 여러 개를 써도 된다는 점을 확인하고 각 블로그 글의 헤더 영역에도 적용함
  • 제목 계층도 함께 정리함
    • 기존에는 사이트 이름을 <h1>, 섹션명을 <h2>, 글 제목을 <h3>로 사용함
    • 문서와 W3C 팁을 읽은 뒤, 페이지에 따라 <h1>의 대상이 달라지도록 바꾸고 스타일은 클래스로 처리함
    • 이는 HTML과 CSS의 관심사 분리에 더 맞는 방식으로 판단함
  • 2022년 초 실험을 시작한 뒤 2023년 여름 공개 전까지 <hgroup>과 <search>가 MDN 문서에 추가됨
    • <hgroup>은 섹션 제목과 부제 <p>를 묶는 데 사용함
    • <search>는 검색 결과가 아니라 검색 입력을 나타내는 의미 요소임
    • 정적 생성 사이트라 서버 검색 결과 생성이 없어서 예제에는 JavaScript가 필요함
    • 2023년 기준 MDN 헤더 검색이나 google.com에서도 <search>를 보지 못함
  • <main>은 이 탐구를 시작하게 만든 초기 호기심 중 하나였고, MDN 목록을 읽은 뒤 상단 메뉴에는 <nav>를 추가함
  • <section>도 글에 넣었지만, Markdown과 HTML을 섞어 작성할 때 시각적으로 중첩을 명확히 유지하기 어려워 다른 곳에서 자주 쓸지는 불확실함

텍스트 콘텐츠 요소에서 얻은 관찰

  • <blockquote>는 이전에 트윗 임베드에 썼지만, 이 글에서는 독립 인용문 스타일을 추가함
    • 문서를 자세히 보기 전에는 <blockquote>의 cite 속성과 <cite> 요소를 몰랐음
  • <dd>, <dl>, <dt>는 뒤늦게 알게 된 요소이며, <ol>과 <ul>에 비해 <dl>은 상대적으로 덜 알려진 점을 이상하게 느낌
    • <ol>과 <ul>은 기본 margin이 있지만 <dl>은 <dd>에 margin이 있음
  • <div>는 과용 때문에 현대 웹에서 나쁜 평판이 있지만, 이 사이트에서는 처음엔 적게 쓰임
    • 함께 스타일링하려는 요소가 생기면서 약 20개 정도까지 늘어남
    • 일반적인 “section”이 많지 않은 사이트에서는 많은 <div>가 불필요할 수 있음을 보여줌
  • <figure>와 <figcaption>은 Medium에 있던 글을 옮기며 이미지 캡션을 의미론적으로 표현하려고 추가한 초기 요소임
    • 문서상 <figure>는 이미지뿐 아니라 일러스트, 다이어그램, 코드 스니펫에도 쓸 수 있음
    • 현재 코드 블록 중에도 <figure>를 쓸 수 있는 곳이 많다고 판단함
  • <hr>는 시각적 가로선이 아니라 의미론적 구분으로 정의된다는 문서를 보고 스타일을 다시 살핌
    • hr:after에 이모지를 넣었지만, 스크린 리더에서 어떻게 동작하는지 확인이 필요함
  • <menu>는 처음 접한 요소였고, 브라우저가 사실상 <ul>처럼 취급한다는 점 때문에 HTML5까지 남은 것이 의외였음
  • <p> 문서는 기대보다 지침이 적었고, 긴 글이 아닌 텍스트가 “정말 문단인가”라는 질문을 남김
  • <pre>는 코드 블록용으로만 생각했지만, 의미 있는 공백을 표시하는 데도 쓸 수 있음을 확인함

인라인 텍스트 의미 요소

  • <a href="#">link</a>는 placeholder처럼 써왔지만, 실제로는 페이지 맨 위로 이동하는 링크였음
  • <abbr>는 MDN 문서가 “저자의 편의를 위한 것”이라고 설명해 가장 덜 쓰일 가능성이 높은 태그처럼 보였음
  • <b>와 <strong>의 차이는 HTML5에서 <strong>이 <b>를 대체한 것이라고 생각했던 기존 이해와 달랐음
    • 실용적 규칙으로는 대체로 <b>를 단어 단위, <strong>을 문장이나 구 단위에 쓰겠다고 정리함
    • 이는 실제 구분을 단순화한 경험칙임
  • <bdi>는 주변 텍스트와 방향이 다를 수 있는 텍스트를 다루는 요소임
    • 예시는 이름이지만, 임의의 사용자 입력 유니코드 텍스트에도 적용 가능하다고 봄
    • 향후 임의 입력을 포함할 수 있는 태그를 <bdi>로 감싸려 함
  • <bdo>는 RTL 언어를 자주 다루지 않아 덜 쓸 것 같지만, 소량의 RTL 텍스트를 처리하는 법을 아는 것은 유용함
  • <br>는 과거 <div>처럼 오용되던 시기가 있었지만 CSS가 강해지며 덜 그럴 가능성이 있다고 봄
    • 문서의 예시가 시라는 점에서 문단과 독립 행 사이의 경계가 어떻게 고려됐는지 궁금해함
    • 일부 경우 <pre>가 더 맞을 수도 있음
  • <cite>와 <q>는 많은 언어에서 눈에 보이는 구두점으로 이미 표현되는 의미를 HTML 의미 요소로 다시 나타냄
    • <cite> 기본 스타일은 기울임이고 <q>는 텍스트에 없는 따옴표를 추가함
  • <code>는 글 전체에서 많이 쓰였고, Google Docs의 Markdown 지원이 <code>를 쓰는지 궁금했지만 문서 HTML을 보니 Google Docs는 현재 <canvas>로 렌더링함
  • <data>는 MDN 예시가 제품명에 제품 ID를 value로 붙이는 방식이라 실제 사용처를 떠올리기 어려웠음
    • 사용자에게 보일 ID라면 표시하는 편이 낫고, 사용자에게 보이지 않을 ID라면 누구를 위한 데이터인지 불분명함
    • <data>는 W3C HTML5 specification에는 보이지 않는다고 확인함
  • <dfn>은 정의 자체가 아니라 정의 안의 용어를 감싸는 요소라 이름이 이상하다고 봄
    • 공식 채택되지 않은 HTML 2.0 제안에만 포함된 것으로 보인다고 정리함
  • <em>과 <i>도 <b>와 <strong>처럼 사용 기준을 고민하게 만듦
    • 실용 규칙으로는 대체로 <em>은 단어, <i>는 문장이나 구에 쓰겠다고 정리함
    • 문서 예시는 <i>를 혼동 가능성이 있는 표현에 주의를 끄는 용도로 많이 씀
  • <kbd>는 키보드 키 지정용이지만, “Right click” 같은 동작에도 맞는지 경계가 궁금하다고 봄
  • <mark>는 사용자가 책에 형광펜을 긋는 것 같은 양방향 저작 웹의 흔적처럼 보였음
  • <rp>, <rt>, <ruby>는 동아시아 타이포그래피에서 발음, 번역, 음역 정보를 제공하는 데 쓰임
    • <rp>는 소스에 포함된 괄호 문자를 숨기는 데 쓰임
  • <s>는 이전에는 맞았지만 현재는 정확하지 않거나 관련 없는 텍스트를 나타내는 취소선 요소임
    • HTML 4.01에서 deprecated 됐다가 HTML5에서 의미가 재정의됨
    • 일부 스크린 리더가 취소선을 알리지 않아 혼란을 줄 수 있고, MDN 권장 CSS를 사이트에 추가함
  • <samp>는 프로그램 출력 표시용이며, 이전에는 <code>로 처리하던 Raspberry Pi 글을 <samp>로 업데이트함
  • <small>은 작은 텍스트 렌더링에 쓰이지만, 대부분은 CSS를 계속 쓸 것 같다고 봄
  • <span> 문서를 보며 <div style="display: inline">이나 <span style="display: block">처럼 모순적인 스타일을 허용하는 이유를 처음 궁금해함
  • <sub>와 <sup>는 이전에 CSS 구현을 썼을 가능성이 있지만, footnote와 수식 예시에 적용함
  • <time>은 의미론적 HTML에 유용해 보여 블로그 글 날짜에 적용함
    • Google 검색 결과에서도 <time>을 쓰지 않는 것 같다고 관찰함
  • <u>는 MDN이 “대부분의 경우 실제로 쓰고 싶지 않을 것”이라고 강하게 안내하는 요소로, 철자 오류 표시가 주요 권장 용도처럼 보였음
  • <var>는 수학 또는 프로그래밍 변수 문자열을 의미론적으로 나타내며, 피타고라스 정리 예시에 <sup>와 함께 사용함
  • <wbr>는 긴 단어, 특히 URL을 특정 지점에서 줄바꿈하게 만드는 문제를 해결함
    • 긴 URL에 break point를 넣으면 화면 너비별로 더 읽기 좋게 줄바꿈됨
    • 하이픈 문자를 URL에 포함해도 현대 브라우저에서 명확한 break point가 생김
    • 줄바꿈 없는 URL은 레이아웃을 깨지 않도록 별도의 스크롤 가능한 <p>로 감쌈

이미지, 멀티미디어, 임베드

  • <area>와 <map>은 예전에 이미지맵류 웹사이트를 만들었음에도 익숙하지 않았던 요소임
    • 요즘 잘 쓰이지 않는다는 점을 보여주듯 <area> 경계 디버깅 도구가 쓰기 어려웠음
    • 탭 포커스 중에는 한 번에 하나의 <area> 경계만 보이고, 스타일링은 동작하지 않았음
    • <area>는 모양을 가진 <a>에 가깝다고 봄
  • <audio>는 HTML5의 대표 멀티미디어 태그라 이미 써봤지만, 2020년대에 예상보다 자주 보이지 않는 점이 의외였음
    • Bandcamp 플레이어는 UI가 커스텀 <a>, <div>, <table> 조합이지만 숨겨진 <audio>를 사용함
  • <img>에서는 srcset 속성을 새롭게 살펴봄
    • 화면 폭별로 서로 다른 이미지 3개를 제공하는 데모를 만들었음
    • 브라우저 캐시와 scaled display가 동작에 영향을 주므로, 효과를 보려면 private window와 non-scaled 또는 non-retina display가 필요할 수 있음
  • <audio>와 <video>는 <img>보다 덜 널리 쓰이고, 온라인 비디오는 주로 YouTube에 중앙화되어 보인다고 봄
    • 오디오는 팟캐스트처럼 개별 파일을 제공하는 방식이 더 분산되어 있음
  • <video>에는 몇 가지 제약이 있었음
    • self-closing tag로 만들었을 때 렌더링되지 않았음
    • 작성 시점의 Safari는 개발 서버가 “Range” request header를 지원하지 않아 비디오를 지원하지 않았을 가능성이 있음
    • GitHub Pages에 올린 호스팅 버전에서 Safari 재생이 되는지 궁금해함
    • <track> 문제는 Eleventy 빌드에서 .vtt 파일을 제대로 설정하지 않은 것이 원인이었음
  • <embed>와 <object>는 많은 용도가 <video>와 <iframe> 같은 특정 태그로 대체됐는데도 deprecated 되지 않은 점이 의외였음
  • <iframe>은 “inline frame”이라는 90년대식 이름이 살아남았고, <frame>은 HTML5에서 deprecated 됨
    • display: inline으로 렌더링된다는 점도 확인함
  • <picture>와 <source>는 서로 다른 상황에서 이미지 버전을 바꾸는 데 의도된 요소임
    • 마우스/트랙패드에서는 컴퓨터 아이콘, 터치스크린에서는 휴대폰 아이콘, 어느 쪽도 아니면 fallback 이미지를 보이는 예시를 만듦
  • <portal>은 iPad 스타일 링크 미리보기와 SPA 같은 성능 이점과 관련된 실험적 요소로 보였음
    • 2023년 기준 어떤 브라우저에서도 기본 활성화되어 있지 않음
    • 예전 Chrome 실험 플래그가 있었던 것으로 보이나, 2023년에는 chrome://flags에서 사용할 수 없었음
    • HTML 5 Spec에는 없는 것 같고, MDN 문서에 왜 포함됐는지는 불확실함

SVG, MathML, 스크립팅

  • MDN 문서가 <svg>와 <math>를 함께 묶는 점이 흥미로웠음
    • <svg>는 Figma와 Sketch 같은 도구 덕분에 쉽게 프로토타입하고 내보낼 수 있어 널리 쓰임
    • <math>는 더 드문 요소로 보임
  • <svg>는 직접 원을 그리는 예시에 사용함
  • <math>는 MathML 네임스페이스의 비 HTML 요소를 감싸는 wrapper에 가깝다고 보고, 간단한 식만 넣음
  • <canvas>는 2020년 Recurse Center에서 선을 선명하게 그리는 문제를 깊게 살펴본 적이 있음
    • MDN 문서를 통해 브라우저별 <canvas> 최대 크기가 있다는 점을 새로 알게 됨
    • 현대 브라우저는 각 차원이 약 32,000픽셀 수준임
    • <canvas>, <script>, <noscript>로 가짜 <marquee>를 다시 구현함
  • <script>는 낡게 느껴질 요소라고 예상하지 않았지만, 글을 쓰며 실제로 직접 쓰는 일이 적다는 점을 깨달음
    • 대부분의 JavaScript는 빌드 도구가 하나의 <script> 태그로 묶어 넣음
    • 그래서 <script>는 markup 태그라기보다 boilerplate처럼 느껴짐
  • <noscript>는 대화형 웹사이트에서 충분히 넣지 않았던 요소라고 봄
    • 특히 minified/compiled SPA에서는 <noscript>가 없으면 사용자가 빈 페이지를 볼 수 있음
    • 이 글에서는 모든 <script> 태그와 함께 <noscript>를 넣음

편집 표시, 표, 폼, 상호작용

  • <del>과 <ins>는 MDN 문서를 보며 처음 접한 요소이며, 워드프로세서에서 쓰일 법한 요소처럼 보였음
    • Google Docs 렌더링도 떠올렸지만, 다시 <canvas>로 렌더링된다는 점을 확인함
  • <table>은 초창기 웹에서 레이아웃 목적으로 과용됐지만, 데이터가 늘어난 최근 웹에서는 오히려 드물게 쓰이는 점을 아이러니하게 봄
    • 이유로는 투박한 기본 디자인과, 데이터베이스 테이블에 저장된 데이터를 웹 UI에서는 다른 관점으로 보여주려는 목적을 듦
    • 글 자체는 문서 기반이라 실제 표 데이터는 없지만, 2023년 Apple emoji set 기준일 가능성이 있는 이모지 데이터를 예시 표로 넣음
    • <col>과 <colgroup>은 이전에 몰랐고, 커스텀 비 <table> 디자인보다 이들을 쓸 경우가 많을지는 모르겠다고 봄
  • <form>과 관련 요소는 보통 제출 시 새 페이지로 이동하는 경우에 썼지만, 페이지 내 사용자 상호작용에도 유효함
    • 접근성 측면에서 폼 요소가 가장 중요할 가능성이 크다고 보고, 앞으로 구현 시 문서를 참고하려 함
  • <details>와 <summary>는 “JavaScript 없이도 할 수 있다”는 사례로 흔함
    • 이런 펼침/접기 UI는 예전에 JavaScript나 jQuery로 처음 만들었던 기능이었고, HTML 몇 개 태그로 쉬워진 점이 흥미로움
    • 오늘날 HTML spec에 제안됐다면 CSS 유사 효과로 대체되며 철회됐을지도 모른다고 추측함
  • <dialog>는 HTML만으로 존재한다는 점을 몰랐던 요소임
    • 스타일 효과 이상으로 유용하려면 JavaScript가 필요함
    • alert()보다 커스텀한 상호작용을 만들면서도, CSS로 스타일링할 수 있는 단순한 방식임

웹 컴포넌트와 deprecated 요소

  • 웹 컴포넌트는 오래전부터 더 배워야 할 목록에 있었고, MDN의 해당 섹션을 읽게 되어 반가웠음
  • 웹 컴포넌트 렌더링에 JavaScript와 Class 문법이 필요하다는 점은 의외였음
    • Shadow DOM을 더 읽은 뒤, HTML에는 스타일 캡슐화 내장 방식이 없기 때문에 납득함
    • 개념적으로 <iframe>과 어느 정도 비슷해 보인다고 봄
  • <slot>과 <template>을 이용해 글의 목차를 만드는 데 웹 컴포넌트를 사용함
    • 프론트엔드 프레임워크 컴포넌트처럼 자식 템플릿 요소의 속성으로 쓰일 property를 넘기는 방법을 빨리 찾지 못함
    • 각 자식에 전체 <a> 요소를 넘겨 <li> 안에서 올바른 href를 설정함
  • deprecated HTML 요소도 글 끝에 포함함
    • <big>, <acronym>, <font>, <nobr>, <strike>는 레이아웃 관련 기능이 CSS로 이동한 예시임
    • <content>와 <shadow>는 웹 컴포넌트 spec의 일부였지만 완전히 구현되지 않아 실제 구현하지 못함
    • <dir>은 디렉터리 나열을 위한 웹서버식 <ul>처럼 보이며, Eleventy 정적 사이트의 디렉터리 목록 예시에 사용함
  • <frame>과 <frameset>은 <body> 대신 쓰이도록 설계돼 일반 본문에 직접 넣기 어려웠고, <iframe> 안에서만 사용함
  • <image>는 공식 specification 일부가 아니었다는 MDN 설명 때문에 동작하지 않을 것으로 예상했지만, 2023년 일부 브라우저에서는 동작하는 것처럼 보였음
    • 이는 <img>와 혼동할 가능성에 대한 fallback일 수 있다고 봄
  • <menuitem>은 Firefox 8~84에서 부분 지원됐다고 하지만, 로컬에 설치한 오래된 버전에서도 예시를 동작시키지 못함
  • <noembed>는 <noscript> 같은 fallback에 가까운데 deprecated 됐고, <embed>는 spec에 남아 있는 점이 의외였음
  • <param>은 <object> 속성 대신 왜 별도 요소였는지 불분명하다고 봄
    • 글을 시작했을 때는 MDN의 “Embedding Content” 섹션에 있었지만, 끝낼 때는 deprecated 됨
  • <plaintext>는 deprecated 요소 중 실제로 동작하는 점이 눈에 띔
    • 그대로 쓰면 이후 페이지가 소스 코드로 렌더링되기 때문에 <iframe>으로 감쌈
  • <xmp>와 <tt>는 닫는 태그가 있어 source code나 teletype식 monospace 텍스트 표시에 본문에서 사용할 수 있었음
  • <rb>와 <rtc>는 동아시아 문자 발음 표시용이었지만, spec이 단순화된 것으로 보인다고 정리함
  • MDN 목록에 없던 <!-- comment -->도 다른 HTML 태그 목록을 확인하며 추가함
  • 2013년 MDN의 오래된 목록에는 <blink>, <spacer>, <bgsound>, <isindex> 같은 요소가 있었음
    • <blink>는 접근성 이유로 현재 대부분 브라우저가 무시함
    • <spacer>는 현대 브라우저에서 동작하지 않고 CSS로 처리할 기능임
    • <bgsound>는 더 멀티미디어적인 웹 문서 비전을 암시함
    • <isindex>는 JavaScript가 없는 세계에서 온 요소처럼 보임
  • <applet>도 언급하지만 시도하지 않음
  • footnote를 위한 네이티브 HTML 구현은 없다는 점을 뒤늦게 발견함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 작성자가 프레임(frames) 을 기억하기엔 너무 어린 듯함 :) 위키백과 글(https://en.wikipedia.org/wiki/Frame_(World_Wide_Web))만 링크하려 했지만 설명이 썩 좋지는 않음
    초기 웹이 대중화됐을 때 프레임은 메뉴, 사이드바, 계속 보이는 헤더 등에 흔히 쓰였고, 위에는 고정 헤더, 왼쪽에는 사이드바, 가운데에는 본문 프레임을 두는 식이 많았음
    각 프레임은 자체 뒤로/앞으로 기록을 갖는 등 꽤 독립적으로 동작해서, 링크가 기본적으로 해당 프레임만 바꾸기도 했음. 그래서 뒤로 가기, 앞으로 가기, 새로고침이 직관적이지 않았고, 잘못된 내용이 한 프레임에 로드되면 처음부터 다시 들어가는 것 말고는 복구가 까다로웠음
    CSS가 프레임의 주요 사용처를 대부분 대체한 건 다행이고, 사용자 입장에서 프레임은 정말 다루기 고통스러웠음

    • 기억나는 프레임 사용처 중 하나는 다른 사이트들의 색인 사이트였음. 왼쪽 사이드바에 여러 링크가 있고, 오른쪽 프레임에서 해당 사이트가 열리는 구조였음
      브라우저 탭이 없던 시절에는 꽤 괜찮은 용도였고, 기록을 왔다 갔다 하거나 여러 창을 관리하는 것보다 한 창 안의 프레임에서 링크 목록을 훑는 편이 더 나았음
    • CSS의 왕인 Eric Meyer도 예전 CSS 참조 문서를 아직 프레임 페이지로 유지하고 있음: https://meyerweb.com/eric/css/references/css1ref.html
    • 90년대에 GeoCities에서 처음 만든 웹사이트도 frameset을 썼고, 정확히 위에서 말한 배치였음
    • https://tintara.tripod.com/FramesSuck.html
    • <frame>과 <frameset>은 이제 단순히 비권장이 아니라 오래전부터 폐기된 요소임: https://html.spec.whatwg.org/dev/obsolete.html#obsolete

  • 잠깐 다뤄지긴 하지만, 화면에는 숨기면서 스크린 리더에는 남기는 간단한 표준 CSS 선언이 아직도 없다는 게 터무니없게 느껴짐
    지금까지 본 건 여전히 clip을 쓰거나, 내용을 페이지 바깥으로 옮기거나, 비슷한 꼼수들뿐임. 왜 이게 display의 대체 값이나 추가 속성이 아닌지 모르겠음
    이걸 해결할 수 있는 speak 속성이 이론적인 CSS 모듈 중 하나에 떠돌긴 했지만, 구현체 채택은 거의 없는 것으로 알고 있음

  • 글쓴이가 혼란스러워한 <menu> 요소에 대해 말하자면, HTML 5.2는 2021년에 W3C에서 폐기되고 WhatWG HTML Living Standard로 대체됐음
    WhatWG 표준은 HTML 5.2와 달리 <menu>를 폐기하지 않았고, “사용자가 수행하거나 활성화할 수 있는 명령을 나타내는 li 요소들의 순서 없는 목록 형태로 된 도구 모음”으로 다시 정의함
    위키백과의 요소 목록과 HTML 버전 정보는 여기서 오래된 듯하고, <menu>는 아직 살아 있음. 다만 여러 번 비권장 처리된 역사와 최근 브라우저들도 정확한 의미 부여에 혼란을 겪었던 점을 보면, 거의 항상 적절한 ARIA 역할(toolbar, menu, menubar)을 붙인 <ul>을 쓰는 편이 나음

  • 이 요소들 대부분이 널리 쓰이지 않는 이유는, 더 이상 존재하지 않는 문제를 풀려던 오래된 시도였거나, 글쓴이도 인정하듯 CSS로 더 잘 해결할 수 있었거나, 브라우저 구현에 크게 의존했기 때문임
    예를 들어 <details>와 <summary>가 모든 상시 업데이트 브라우저에 들어왔을 때 기대했지만, 내용을 갑자기 펼치는 대신 사용자를 안내하듯 미끄러지게 열려면 JavaScript가 필요했음. 내가 본 가장 나은 구현은 WAAPI를 썼고, Safari는 독자적인 의사 요소까지 추가함

    • JavaScript 없이도 슬라이드 애니메이션은 가능하긴 한데, 닫힐 때는 그다지 예쁘지 않고 열릴 때는 괜찮음: https://codepen.io/dada1smo/pen/LYydWBg
      내 코드는 아니고 css-tricks 링크의 댓글에서 찾은 것임
    • <small>은 예전에는 서식 태그였지만, HTML5에서는 작은 글씨 주석(fine print) 태그가 됐음.[1] <font> 같은 순수 서식 태그는 오래전에 비권장 처리되고 사라졌음
      [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/small

  • <details>/<summary> 태그는 중첩할 수 있음. 한 번은 이걸로 선택형 모험 게임을 만들어 회사 인트라넷에 올렸음
    조각을 이어 붙이는 생성 스크립트가 있었고 실제 텍스트는 몇 쪽 분량뿐이었는데, HTML이 5MB가 됐음. 그날 브라우저를 많이 망가뜨렸고 결국 삭제해야 했음

    • 흥미로운데 잘 이해가 안 감. details/summary 중첩이 어떻게 5MB HTML로 이어졌고, 그게 어떻게 많은 브라우저를 망가뜨렸는지 더 듣고 싶음

  • 1995년쯤 HTML을 처음 배웠을 때가 떠오름. Kevin Werbach의 Barebones Guide to HTML을 기억하는 사람 있나?
    사실상 모든 HTML 태그와 그 역할을 나열한 사이트였음. 그 자료, 텍스트 편집기, 초기 버전 Netscape Navigator만 있으면 바로 배우고 실험할 수 있었음

  • 며칠 전 웹 탐색 AI 에이전트를 만들려다 Hacker News 댓글이 테이블 안의 테이블 안의 테이블로 구현돼 있는 걸 보고 충격받았음

    • 그걸 알고 오히려 기뻤음. HN을 더 읽기 쉽게 하려고 userContent.css를 만들었고, 본문 폭을 제한하고 line-height를 1.5em으로 두고 모든 문단에 추가 위쪽 여백을 줬음
      이제 넓은 브라우저에서 한 줄에 250자가 표시되는 HN을 힘들게 읽지 않아도 됨. 각 문단이 읽기 쉬워졌고, 문단 구분도 줄 간격보다 더 뚜렷하게 보임

  • 시맨틱 HTML은 잠재력이 큼. 개인적으로는 본문 각주를 오른쪽 여백에 더 작거나 반투명한 글꼴로 두고, 필요하면 <details>/<summary> 펼침 요소를 붙이는 스타일을 좋아함
    하지만 이런 스타일을 실제로 구현하려면 매번 CSS를 꽤 자세히 알아야 제대로 굴러가는 듯함

  • 먼저, 이건 정말 훌륭한 학습 방식이고 좋은 연습임
    예전에는 갑자기 쓸 수 있게 되어 신났던 낡고 지금은 안 쓰이는 요소들을 글쓴이가 보며 용도를 추측하는 것도 재미있음
    다만 Mosaic 이후 모든 버전의 HTML을 손으로 작성해 온 입장에서, MDN이 description list처럼 소급해서 이름을 바꾸는 것은 마음에 들지 않음. 원래 명세의 definition list가 더 좋음
    내게는 dl, dt, dd를 “정의 목록”, “정의되는 용어”, “정의”로 생각하는 편이 더 자연스러움. description이 definition보다 넓은 말이긴 하지만, definition list라고 보면 dl에는 용어(dt)와 정의(dd)가 있다는 걸 기억하기 쉬움
    W3도 definition list라고 부름: https://www.w3.org/TR/html4/struct/lists.html#edef-DL

  • 실제 세상에서 <h6>까지 도달한 경우를 본 적이 있나?

    • 있음. 첫 기술 직장은 초지역 마케팅 대행사였고, 대부분의 시간을 작은 지역 상점들의 식당 메뉴와 판매 정보를 갱신하는 데 썼음
      식당 메뉴는 계층이 말도 안 되게 깊어지곤 했는데, 많은 식당이 너무 많은 메뉴를 만들었기 때문임. 모짜렐라 스틱과 아란치니를 제대로 보여주려면 Restaurant -> Menu -> Antipasti -> For Groups -> Fried -> Cheesy 같은 계층이 필요할 때가 있음
    • 있음. 명세나 다른 기술 문서에서는 나온다. 예를 들어 HTML 명세[1] 자체가 그렇음
      [1]: https://html.spec.whatwg.org/#link-type-next
    • 짜증나는 것 중 하나임. 왜 1~6으로 제한하고, 임의 크기를 지정하는 속성을 허용하지 않는지 모르겠음
    • 예전 교수이자 상사가 쓴 거대한 책을 웹 버전으로 만들었는데, 확실히 제목 6단계를 썼고 어쩌면 그 이상도 필요했음
답변달기