본문으로 건너뛰기
J
피드

HTML <time> 엘리먼트, 페이지 8%에서 쓰이지만 사실 아무것도 안 한다

frontend 약 3분
tags
#html#semantic-html#accessibility#browser#web-standards
vote
0
댓글
북마크

HTML time 엘리먼트가 시맨틱 마크업으로 널리 쓰이지만, 실제로 브라우저나 보조 기술에서 활용하는 경우가 거의 없음. 구글도 Schema.org를 추천하고, time의 잠재력은 2010년 이후 이행되지 않은 약속으로 남아있음.

  • 1

    Chrome 기준 페이지 로드의 8%에서 time 엘리먼트 사용 중

  • 2

    브라우저가 time을 활용하는 기능은 사실상 없음 — 렌더링만 함

  • 3

    NVDA/Narrator만 타임스탬프를 읽어주지만 UX 개선 여부는 애매

  • 4

    Google은 time 대신 Schema.org의 datePublished/dateModified 추천

  • HTML의 <time> 엘리먼트, 다들 쓰긴 쓰는데 사실 아무것도 안 한다는 이야기
  • 흔한 패턴이 있음: "4시간 전 게시됨" 같은 상대 시간을 보여주면서, 호버하면 정확한 날짜를 툴팁으로 띄우는 거. <time datetime="...">4 hours ago</time> 이렇게 시맨틱하게 쓰면 브라우저가 알아서 뭔가 해줄 것 같은데... 안 해줌
  • Chrome 사용 통계 기준으로 <time>은 페이지 로드의 약 8%에서 사용되고 있는데, 실제로 이걸 활용하는 브라우저나 보조 기술이 거의 없음
  • 업데이트: NVDA와 Narrator 스크린 리더가 타임스탬프를 읽어주긴 하는데, 오히려 사람이 읽기 편한 "4시간 전"을 날짜로 바꿔서 읽어버리니 접근성 개선인지 애매함
  • <time>의 유일한 실용적 쓸모는 검색 엔진이 날짜 스니펫 추출하는 데 쓰는 것 정도인데, Google 공식 문서는 <time>을 언급도 안 하고 Schema.org의 datePublished/dateModified를 추천함
  • 2010년에 Bruce Lawson이 상상한 유스케이스가 지금 봐도 좋음: 브라우저가 이벤트를 캘린더에 추가해주거나, 태국 로컬 브라우저가 그레고리력을 불교력으로 변환하거나, 일본 브라우저가 "16:00"을 "16:00時"로 표시하는 것
  • 결론: 시맨틱 HTML의 이행되지 않은 약속 같은 존재. 그래도 글쓴이는 계속 쓸 거라고 함. Marge Simpson 말처럼 "그냥 멋있으니까(I just think it's neat)"

시맨틱 HTML의 이상과 브라우저 구현 현실의 간극을 보여주는 대표적 사례. 웹 표준이 정의만으로는 부족하고 벤더 구현이 따라와야 한다는 교훈.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.