본문으로 건너뛰기
피드

ePub에서 HTML이 달라지는 방식

frontend 약 3분
vote
0
댓글
북마크

ePub은 일반 HTML이 아닌 XHTML을 사용하며, XML 네임스페이스, 제한적 CSS 지원, epub:type 시맨틱 속성 등 웹 개발자가 알아야 할 차이점을 정리한 글

  • 1

    ePub은 XHTML 기반이라 self-closing 태그와 네임스페이스가 필수

  • 2

    e-리더의 CSS 지원은 제한적이며 네임스페이스 인식 셀렉터 필요

  • 3

    epub:type으로 미주 등 시맨틱 표현 가능하나 DPUB WAI-ARIA로 전환 중

  • 4

    Standard Ebooks 툴셋으로 ePub 스캐폴딩과 빌드 가능

ePub에서 HTML이 달라지는 방식

  • ePub은 일반 HTML이 아니라 XHTML을 사용함. XML 기반이라 self-closing 태그 필수, 네임스페이스 선언 필수, 문법 오류 하나면 e-리더가 바로 에러를 뱉음
  • 수십 년 전 HTML을 XML 위에 재구축하려던 XHTML 프로젝트가 웹에서는 실패했지만, ePub 세계에서는 아직도 현역임

CSS는 되긴 되는데...

  • e-리더는 브라우저에 비하면 구석기 시대 수준이라 :not()도 리스크 있고, :is() 같은 건 지원 안 된다고 보는 게 맞음
  • XHTML이니까 CSS에서도 네임스페이스를 인식해야 함. q[lang]이 아니라 @namespace xml 선언 후 q[xml|lang]으로 셀렉터를 써야 동작함

MathML, SVG, 그리고 epub:type

  • HTML5에서는 MathML/SVG 태그를 그냥 쓰지만, XHTML에서는 루트에 네임스페이스를 선언하고 m:math, svg:svg 같은 접두사를 붙여야 함
  • epub:type 속성으로 미주(endnote), 참조(noteref) 같은 시맨틱을 표현할 수 있음. e-리더가 이를 인식하면 모달로 미주를 보여주는 식
  • epub:type은 DPUB WAI-ARIA role 값으로 대체되는 추세이긴 한데, Apple Books에서도 아직 제대로 지원이 안 됨
  • Z39.98-2012 시맨틱 어휘로 로마 숫자 같은 더 세밀한 의미 표현도 가능하긴 한데, 지원하는 리더는 거의 없음

ePub 만드는 법

  • META-INF/container.xml → 패키지 파일(매니페스트 + 스파인) → XHTML 파일들 → zip으로 묶어서 .epub으로 확장자 변경하면 끝
  • 직접 구조 잡기 귀찮으면 Standard Ebooks 툴셋 추천: se create-draft --white-label로 스캐폴딩, se build로 빌드하면 됨

웹 기술을 안다고 ePub을 바로 만들 수 있는 건 아님. XHTML의 XML 유산이 곳곳에 영향을 미침

댓글

댓글

댓글을 불러오는 중...

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 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.