1.
웹과 관련한 일을 하시나요? 그러시면 W3C가 제공하는 표준(Standard)를 읽어보시나요? 그동안 함께 했던 수많은 개발자중에서 W3C를 꼼꼼히 읽었던 분은 손가락으로 꼽을 정도입니다. W3C가 제공하는 표준의 문서들을 보면 W3C Standard, Web Design and Applications, Web of Devices, Web Architecture, Semantic Web, XML Technology, Web of Services 및 Browsers and Authoring Tools입니다.
이중에서 가장 기본적인 HTML과 관련한 표준을 제공하는 HTML Current Status를 보면 주제별로 표준을 나열하고 있습니다. HTML5를 보면 아주 긴 문서입니다. 눈에 쏙쏙 들어오는 양식은 아닙니다.
HTML5 A vocabulary and associated APIs for HTML and XHTML
이와 달리 WHATWG가 제공하는 표준은 무척 유용한 편집입니다. 저는 WHATWG라는 그룹이 있는지 몰랐습니다. 아주 오랜 역사를 가지고 있더군요.
What is the WHATWG?
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.
Welcome to the WHATWG community – Maintaining and evolving HTML since 2004중에서
또한 W3C와 일정부분 대립하는 면도 있는 줄 처음 알았습니다. WHATWG이 제공하는 HTML 표준은 W3C와 다른 이름으로 불립니다. HTML Living Standard라고 합니다. 이렇게 부르는 이유가 있더군요. W3C가 제정한 표준을 다른 시각으로 편집한 버전이라고 생각했는데 완전히 틀린 이해입니다.
우리가 공식적으로 “Web Applications 1.0″라고 부르던 표준을 “HTML5″라 명명하고 W3C와 공동 작업을 시작한 것은 지금부터 몇 년 전 (2007 년경)이었습니다. 우리는 이름을 “HTML5″로 변경하고 W3C에 그 사본을 제출하였습니다. 그러다 얼마 지나지 않아, W3C에서 표준을 나름의 기준에 따라 분할했기 때문에 (즉, 2D Canvas API, Server-Sent Event, postMessage 등) WHATWG 측에서도 그것에 맞추도록 노력해 보았습니다 .하지만, 여러 버전의 표준이 있는 것으로 혼동을 주어 WHATWG 측에서는 제가 담당하는 정리한 하나의 표준 표준에만 담기로 하였습니다. 우리가 지금 “HTML Living Standard“라고 부르고 있는 것입니다.
WHAT HTML 표준과 W3C HTML5와의 향후 관계중에서
보완이 아니라 대립으로 보였습니다. 왜 이렇게 나뉘었을까, 궁금해졌습니다. 어떻게 이해해야할까요? 이와 관련한 이해를 돕는 글입니다.
윤석찬 씨는 표준 확산이 파편화를 없애지 못할 것이라 봤다. 다른 소프트웨어 플랫폼과 웹 기술의 특성이 본질적으로 다르기 때문이다. 그는 웹 개발자들은 iOS나 안드로이드 등 다른 플랫폼 개발자들처럼 기술 기반이 안정화되고 통일되기를 기다려선 안 된다고 지적한다.
“여타 SW개발처럼 웹 개발도 플랫폼에 의존합니다. (안정화 시점이 있기 때문에) iOS나 안드로이드 개발자들은 표준을 바라보고, 완성되길 기다립니다. 그런데 웹 개발자들은 표준을 기다리면 안 됩니다. 웹은 항상 진화하고, 100% 우리가 원하는 상태에 도달하지 않으니까요. 파편화는 기본적인 것, 원래 있던 것입니다. 웹에서 파편화를 배제하는 환경은 어불성설입니다. 20년 전에 있긴 있었죠. ‘액티브X’를 쓸 때. 그 시기는 웹 생태계의 ‘암흑기’였습니다. 아무 것도 발전하지 않았죠. 지금은 빠른 발전이 이뤄지고 있죠.”
웹기술 업계에서 ‘리빙 스탠더드(Living Standard)’라 일컫는 개념이 윤 씨가 말한 ‘항상 진화하는 웹’을 가리킨다. 살아 있는 생물처럼 표준도 시시각각 달라진다는 의미를 강조한 용어다. 개발자들이 일관된 사용자 경험을 만들기 위해 시시각각 대응해야 한다는 뜻이기도 하다.
“새 브라우저가 나올 때마다 최신 표준 기술을 테스트해 보고, 그걸 어떤 사용자들에게 제공할 것인지 고민하는 방식으로 대응해야 합니다. 제가 있었던 포털 사이트 운영 회사는 불특정 다수 대규모 사용자들에게 서비스를 제공하는데요. 다른 회사는 그렇지 않고 특정 사용자에게 특정 서비스를 제공합니다. 이 경우엔 하위 호환성과 폴백 기능을 제공하는 식으로 더 많은 사용자들에게 대응하려는 자세가 요구됩니다. 새로운 기능이 언제 표준화할 것인가 기다리면 결국 항상 뒤쳐지게 됩니다. 프론티어가 돼야 합니다.”
소속 회사가 운영해야 하는 서비스와 목표 사용자의 특성 등을 종합해, 새로운 웹 기술 도입과 기존 사용자 환경 지원의 균형점을 찾아 대응하는 게 파편화된 웹 환경에서 권장할만한 웹 개발자의 일이라는 얘기다. (중략)
윤 씨는 개발자들이 자바스크립트를 활용해 다양한 표준 기술을 조합하는 방향으로 움직임에 따라 브라우저 개발업체들은 그걸 지원할 수 있는 기본 수준의 API를 제공하는 데 초점을 맞추는 흐름도 생겼다고 전했다.
“웹 개발자는 고수준의 기능을 만들어내고, 그걸 단순화할 수 있는 저수준 API를 브라우저에 탑재하는 경향이 생겼습니다. W3C 내부에서 일괄 주도하는 기존 표준화 방식대로라면 2~3년 걸릴만한 일을 외부 개발자들이 먼저 실험적으로 만들어내고, 테스트하고, 이후 웹표준화에 반영되게 유도하는 선순환 구조가 된 거지요.”
웹 파편화는 필연…표준 기다리지 마라중에서
표준과 혁신에 대한 시각의 차이가 편집의 차이로 나타난 듯 합니다. 어찌되었든 개인적으로 훨씬 유용한 문서입니다. 특히 HTML: The Living Standard A technical specification for Web developers은 짧아서 꼭 정독하면 좋습니다.
그리고 Unofficial diff viewer for WHATWG HTML Standard and W3C HTML.는 HTML5과 WHATWG의 HTML Live Standard의 차이를 일목요연하게 정리했습니다. HTML5 Work Splits Into ‘Living’ And ‘Snapshot’ Standards. Developers Need Not Worry, Says Living Standard Leader의 제목처럼 Living과 Snapshot으로 각 표준을 이해하는 것도 한 방법일 듯 합니다.
2.
W3C와 WHATWG의 표준을 찾아본 이유는 CSS와 관련한 작업때문입니다. 현재 작업하는 프로젝트의 목표중 하나가 Cross Browser입니다. WebKit을 엔진으로 하는 브라우저를 기반으로 작업한 라이브러리가 다른 브라우저에서도 정상적으로 동작하도록 하는 일을 해야 합니다. CSS 속성을 Webket이라는 접두사를 이용하여 정의한 소스를 수정하여야 하는 일입니다. 어떤 방법이 가능할까 고민을 해보았습니다.
인터넷으로 검색을 한다가 Firefox will support non-standard CSS for WebKit compatibility을 읽었습니다. 이 기사속에서 채미있는 자료가 있었습니다. 찬찬히 살펴보는 중입니다.
Compatibility Living Standard — Last Updated 7 September 2016
PostCSS – A tool for transforming CSS with JavaScript와 a href=”https://css-tricks.com/autoprefixer/” target=”_blank”>Autoprefixer: A Postprocessor for Dealing with Vendor Prefixes in the Best Possible Way 그리고 PostCSS Mythbusting: Four PostCSS Myths Busted을 살펴보니까 전혀 다른 발상도 가능하더군요. 모든 브라우저에서 비슷하게 보이도록 CSS를 100% 표준에 준하도록 개발하는 것 말고 각 브라우저의 특성에 맞도록 브라우저별 차이를 반영한 개발입니다. 이런 방법을 택하려고 하면 Automactic Build 환경을 만들어야 합니다만 현재 프로젝트의 개발환경으로는 불가능합니다. 빌드가 아닌 방법을 찾아보니까 Sublime Text를 이용하는 방법이 있더군요. 플러그인인 Autoprefixer을 설치한 후 자동으로 소스를 수정하도록 하는 방법입니다.
Adding CSS Vendor Prefix Automatically with Sublime Text
덧붙임) W3C가 몇 일전 HTMl 5.1 표준을 발표하였습니다. 이후 WHATWG도 HTML Live STandard를 Fetch하였습니다.
HTML 5.1 W3C Proposed Recommendation, 15 September 2016
Fetch Living Standard — Last Updated 15 September 2016
