⚽️ 목표
복잡한 W3C와 WHAWG의 히스토리
•
역시나.. 뭐랄까.. 개인적으로 무언가를 새로 알아가는 과정에서 어떠한 결정, 변화에 대한 히스토리 정리가 선행되지 않으면 이해도도 떨어진다. 그래서 찾아보고 조사해봤다. HTML 5가 나오기 까지 길고 복잡해했던 명세+표준 전쟁에 대해.
TL;DR
HTML5는 더이상 없다.
•
WHATWG가 W3C와의 웹표준 전쟁에서 승리했다.
•
HTML5는 더이상 사용하지 않는 단어다. HTML Livign standard가 존재하기 때문이다.
1. 들어가기 전 - XHTML
eXtensible HyperText Markup Language
<!-- Content-Type: application/xhtml+xml -->
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<title>XHTML</title>
</head>
<body>
<p>I am a XHTML document</p>
</body>
</html>
XML
복사
XHTML 예시 코드
•
후에 알아볼 WHAWG 탄생에 기여(?)를 한 XHTML에 대해 먼저 정리한다.
•
HTML과 XHTML 그 사이에 존재하는 어떤것, 겉으로 보기에 차이점이 거의 존재하지 않는다.
규칙
•
<!DOCTYPE> is mandatory
•
The xmlns attribute in <html> is mandatory
•
<html>, <head>, <title>, and <body> are mandatory
•
Elements must always be properly nested
•
Elements must always be closed
•
Elements must always be in lowercase
•
Attribute names must always be in lowercase
•
Attribute values must always be quoted
•
Attribute minimization is forbidden
Strictness
xhtml의 엄격한 에러핸들링
•
HTML과 비교했을 때 제일 큰 차이점은 엄격함과 규칙 이다. → 위 규칙이 지켜지지 않을 경우 브라우저에 에러가 표시된다.
•
HTML의 경우 느슨한 규칙을 가지고 있어 잘못된 문법을 가진 코드나 오타의 경우에도 브라우저가 대부분 알아서 잘 렌더해준다.
•
XHTML은 HTML과 다르게 문법적 에러가 존재할 경우 에러를 출력하며 화면을 그리지 않는다.
◦
여기서 말하는 문법적 에러의 경우 잘못된 nesting, 대문자 소문자 구분, 오타 등등이다.
◦
물론 모던 웹 환경에서도 이와 같이 비슷한 Error Overlay를 출력하지만 큰 차이점이 존재한다. 모던 웹 개발환경에선 개발환경에서만 에러가 출력되지만, ”XHTML은 프로덕션 환경에서도 똑같이 페이지 렌더 없이 에러를 출력했다는것”.
모던 웹 환경
•
엄격한 룰이 양날의 검이 되었다. 브라우저간 호환성을 위해 코드의 엄격함을 추가했지만 하지만 당시 이용자들은 “굳이… 지금도 잘 돌아가고 HTML은 내 실수들 다 용인해주는데 에러라고 잘못됐다고 뭐라하는 XHTML을 사용해야돼?”라는 생각에 XHTML 사용을 꺼려했다.
IDE에서의 잘못된 태그 사용으로 인한 에러 출력 예시
•
모던 웹 개발환경에서는 필요성이 더 줄어들었다.(그 전에 포기된 기술이지만) eslint, typescript와 같은 코드/타입 검사기들이 등장했으며 적절한 설정이 적용되었을 경우, 처음부터 빌드 마저 불가능하게 만들 수 있기 때문이다.
•
end tag가 필요 없는 태그에 end tag를 사용하는 경우, 없는 attribute를 사용하는 경우와 같은 간단한 실수들은 개발 환경에서(IDE, 개발 서버) 미리 검증될 수 있다. 이미 개발환경에서 엄격한 코드 검사를 수행하는데 굳이 런타임 환경에서도 엄격한 룰 검사가 존재해야할 이유가 있을까? 오히려 또하나의 error prune 한 요소가 될 수 있다.
•
하지만, 규칙의 엄격함은 당시 상황에서는 “올바른 코드 작성”을 위해 필요한 요소가 아니였을까? 잘못된 태그 사용, 잘못된 구조사용, 필수 태그의 미존재가 당시 표준 명세를 만들던 W3C에게는 못마땅 했을 것 이다. 그리고 브라우저 제조사들 조차도 이용자의 실수를 보완해주는 로직을 작성하는것 또한 하나의 추가적인 개발이 완성되어야 하는 부분이고. → 브라우저의 자동보완 로직은 XSS 취약점에도 잘 활용된다.
◦
지금 당장 lint, typescript, prettier 다 끄고 개발하는것과 똑같았던 상황이라는건데, lint의 힘을 믿는 사람으로써 W3C의 입장이 이해가 잘 가는 부분이다.
◦
실제로 당시 XHTML을 믿고 사용하던 사용자들도 많이 존재했다.
Deprercation
•
결국 XHTML은 사장 되었다. 굳이 하나의 제일 큰 이유를 뽑자면 HTML5 표준의 승리가 되겠다.
•
사소한 이유도 많지만 “굳이 XHTML을 사용해야할 이유를 모르겠다”가 제일 압도적인 이유였다. 이미 HTML의 유연한 에러대응에 편해진 개발자, 퍼블리셔들은 복잡한 규칙이 존재하는 XHTML 다시 적응할 이유를 충분히 느끼지 못했다.
•
이해가 잘 되지 않는다면 현재 본인들의 개발환경에 대입해서 생각해보자. 서로 다른 개발환경(NextJS, Vite, CRA)들은 전부 다른 Error Overlay를 띄운다.
NextJS Error Overlay 예시
•
이 Error Overlay들이 실 프로덕션 환경에서 모두 출력된다고 가정해보면 XHTML의 (프로덕션에서도 존재하는)강력한 룰이 당시 개발자들을 얼마나 힘들게 만들었는지 알 수 있다.
2. WHATWG
Web Hypertext Application Technology Working Group
시작- Ian Hickson
•
2004년, W3C의 XHTML으로 표준 변경에 불만을 가진 Ian Hickson이 메이저 브라우저 제조사들 (Apple, Opera, Mozilla)을 모아 결성한 그룹이다.(당시 Opera 직원)
•
당시 W3C의 우선순위는 XHTML에 있었기 때문에 2004년 당시 마지막 업데이트는 1999년에 이루어진 HTML 4.01이 마지막 이였으며 그 후론 전무했다.
•
역시나 마이크로소프트는 없었다. 이때 마이크로소프트는 XHTML을 밀고있었기 때문이다.(Internet Explorer 전성기 때의 그 마소)
요즘은?
“The main focus up to this point has been extending HTML4 Forms to support features requested by authors, without breaking backwards compatibility with existing content.”
•
당시 Mail을 한번 읽어보자. W3C의 느린 표준화 속도, 포괄성에 동의하지 않아 만들어졌다는 글들도 인터넷 상에 많이 돌아다니지만 당시 전송된 메일을 확인했을때는 XHTML에 반대가 제일 큰 이유로 유추된다.
◦
W3C에서는 XHTML을 밀고 있었기 때문에 기존 HTML4는 개발이 당연히 없었을 것 이다. 넓게 보면 느린 표준화 속도도 포함될 수도 있겠다.
•
WHATWG 결성 이 후에도 W3C와 서로 협력하여 새로운 웹표준을 많이 만들었으나 항상 W3C보다 WHATWG에서 먼저 처리되었었다.
◦
하지만 W3C의 표준으로 승인되기 전에 Chrome, Mozilla 브라우저에서 기능이 먼저 추가되는 경우도 많이 있었다. → W3C 표준은 형식적인 절차 일 뿐 사실상 WHATWG에서 정한 표준이 실제 표준이되는 기이한 현상이였다.
XHTML의 끝과 HTML5으로 복귀
In 2006, the W3C indicated an interest to participate in the development of HTML5 after all, and in 2007 formed a working group chartered to work with the WHATWG on the development of the HTML5 specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHATWG site.
•
2006년 W3C는 HTML 5개발에 다시 의향을 밝히며 WHATWG와 같이 함께할것을 요청하며 XHTML의 명맥은 끊어지기 시작한다. → 2007년 부터 다시 결합하게 된다.
2009 - W3C
22 December 2009
https://www.w3.org/News/2009#entry-6601
W3C 2009년 뉴스 → XHTML2 Working group의 해산
•
시간이 지나 2009년 말, 많은 사람들이 XHTML에 대한 행복 회로를 돌렸지만 XHTML 2(1도 많이 안썼을 텐데 2 까지 나왔다는 사실이 더 놀랍다) Working Group이 활동을 멈추고 HTML 5에 전념하기 시작한다.
3. 다시 분열 - Snapshot vs Living standard
이제부터 HTML5가 아닌 HTML
HTML is the new HTML5
https://blog.whatwg.org/html-is-the-new-html5
WHATWG의 표준 방식 변경 블로그 포스팅
•
2011년 1월 19일, WHATWG의 HTML 표준은 새로운 기술의 명세를 만들고 각종 프로세스를 밟아 다음 버전(5.1과 같은 버저닝 또는 스냅샷)에 추가하여 업데이트하는 프로세스는 새로운 기능 추가에 너무 오랜 시간이 걸린다는 이유로 HTML 표준을 스냅샷 하는 방식이 아닌 Living standard, 수시로 추가되는 표준으로 변경했다.
또 Ian Hickson
“If you've been happily ignoring the W3C's involvement with HTML these past
few years, you can stop reading now. If you got a bunch of bugmail
recently and want to know why, the explanation is below.”
•
메일 서두다. 아무래도 W3C의 간섭이 맘에 들지 않았을 것이다. 발전에 저해, 방해만 하고 있으니.
•
2012년 까지 W3C와 WHATWG는 함께 일해왔으나 HTML 표준 명세의 기준에 대한 입장차이가 존재했다.
•
W3C는 스냅샷을 만들어 “버전으로 관리 해야한다”라는 입장
•
WHATWG는 “버전과 관계없이 Living standard”를 만들어야한다는 입장
•
이때 까지만해도 Ian Hickson이 W3C의 명세와 WHATWG의 명세 모두 담당했으나 이때 부턴 WHATWG의 명세의 작성만 담당하게 된다. 그렇다, 이렇게 서로 다른 2개의 명세가 세상에 존재하게 된다.
4. 다른 분열의 예시 - cite
W3C HTML 5.2 문서 방문 시 출력되는 경고창
•
W3C의 HTML 5.2 명세 페이지를 방문하면 Outdated 경고 모달이 출력된다. 그리고 링크를 클릭하면 WHATWG의 Living standard로 링크가 변경된다.(스포일러지만 W3C HTML 5 표준은 끝났다.)
HTML Standard
Element/a
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-cite-element
WHATWG Living standard - cite element
<cite> 태그 표준의 차이
WHATWG | W3C | |
element 설명 | The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc.). This can be a work that is being quoted or referenced in detail (i.e., a citation), or it can just be a work that is mentioned in passing. | The cite element represents a reference to a creative work. |
사람 이름의 포함에 대한 차이점 | A person's name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people's names. (In some cases, the b element might be appropriate for names; e.g. in a gossip article where the names of famous people are keywords rendered with a different style to draw attention to them. In other cases, if an element is really needed, the span element can be used.) | It must include the title of the work or the name of the author (person, people or organization) or an URL reference, or a reference in abbreviated form as per the conventions used for the addition of citation metadata. |
•
명세의 차이가 존재했다. 물론 W3C의 “reference to a creative work”와 WHATWG의 “represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc.)”에는 큰 차이가 없다.책, 에세이, 시, 노래가 reference to a creative work이 될 수 있기 때문이다.
•
문제는 사람의 이름 포함 여부에 존재했다. W3C는 author의 이름을 반드시 포함해야한다는 표준을 작성했고 WHATWG는 사람의 이름을 포함해선 안된다는 표준을 작성했다.
•
이런 표준의 차이가 업계 종사자들에게 스트레스로 다가오기 시작했다.
5. DOM 4.1
•
2018년, WHATWG의 Living standard가 실질적 표준이 되어가는 상황에서 DOM 4.1 표준에 W3C와 WHATWG와 의견 충돌이 생기기 시작한다.
•
물론 이 이전에도 많은 의견대립이 존재했지만 DOM 4.1이 W3C에게 가장 큰 결정타였다.
역사의 현장
•
Web 역사의 현장 그 자체를 확인해보자.
•
주요 브라우저 제조사들이 DOM 4.1 명세를 거절하는 이유는 여러가지다.
◦
어차피 WHATWG living stadard를 따라가는데 왜 혼란되게 W3C standard를 카피하고 (심지어 마이너 수정)해서 배포하는가?
◦
역시나 WHATWG의 living standard에서 W3C가 fork 해 몇가지 변경사항을 추가했지만 그중 호환 불가능한 변경사항이 존재한다. 그럼에도 왜 W3C의 CEO는 강제로 표준화에 밀어붙이는가?(참고로 W3C CEO는 멤버가 아니였다.)
◦
표준화 과정도 준수하지 않았다. 근데 왜 따라야 하는가?
◦
실제 브라우저 관련 엔지니어들은 WHATWG에 있는데 왜 W3C가 개입하는가?
•
물론 W3C의 DOM 4.1은 표준화 될 수 없었다. 단 하나의 브라우저 제조사들도 DOM 4.1에 맞게 업데이트 하지 않았기 때문이다.
6. 결론 - W3C와 HTML5의 끝
W3C의 항복 문서
•
2019년 5월 28일, DOM 4.1 사건으로 부터 얼마가지않아 W3C는 패배를 선언한다. 이때 부터 HTML5는 사라지고 Living standard 하나의 표준만 남게된다. → 이 때 부터 W3C는 recommendation만 하고 선택은 WHAWG에서 한다.
•
현재 W3C의 HTML 5 관련 페이지 방문 시 WHATWG Living standard 페이지로 자동 이동한다.
HTML5는 없다.
•
W3C의 마지막 HTML5 버전인 5.3을 마지막으로 이제 HTML 5는 사라졌다. 이 이후로 WHATWG가 주축이 되어 웹표준을 작성, 관리하며 2011년 부터 Living Standard라는 표준에 지속적으로 업데이트 하는 방식으로 추가되고 있다. HTML5 표준은 더 이상 존재하지 않는것, 정확히 표현하자면 Living Standard가 올바른 단어다.
•
이젠 HTML5란 단어의 의미가 많이 흐려졌다. JS 생태계로 치자면 ES6같은 워딩이 되었다. 그만큼 많은 변화가 있었느니 하나의 획기적인 업데이트, 사건이 되었으니 그런게 아닐까?
◦
JS 생태계에선 ES6를 모던 JS 로직으로 퉁치는 경향이 있다. HTML 5은 좀더 포괄적인 개념으로 최신 CSS, HTML, JS 전부 포함해서 호칭하는 경향도 있다.
남아있는 찝찝함
•
우리 모두. Internet Explorer가 높은 점유율을 이용하여 무슨 악행을 했는지는 잘 알 고 있을 것 이다. 이젠 크롬, 정확히 말하면 크로미움이 압도적인 점유율을 가져가고 있다.
•
사실상 safari, fireforx를 제외하면 전부 chromium 엔진을 사용하고 있는 상황이다. 여기서 조금만 삐끗하게 된다면 이전 Internet Explorer 때의 악몽이 다시 돌아올 수 있다.
•
실제로 구글 독스와 같은 프로덕트가 “크롬에서만” 잘 돌아간다는 이슈가 많이 존재했었다. 같은 chromium을 사용하고 있는 edge에서는 안되지만 같은 버전의 크롬에서는 잘돌아간다는 케이스도 많이 존재했다. 독점은 위험하다.
•
멀지 않은 옛날 “이 사이트는 윈도우와 Internet Explorer에 최적화 되어있습니다”와 같은 메시지 기억나는가?
•
그와 다르지 않게 요즘 웹에서는 “이 사이트는 chrome 최신버전에 최적화 되어있습니다.”와 같은 메시지를 흔하게 볼 수 있다.
한 서비스의 Google Chrome 최적화
◦
실제로 해당 서비스는 safari에서 이용 시 로딩안됨, 느림, 기능 클릭시 반응 없음 과 같은 이슈들이 존재해 본인은 해당 서비스를 위해 chrome을 설치해야만 했다.
◦
이러한 현상이 과연 그들이 지켜온 웹 표준에 부합하는 현상일까? 라는 생각을 하게 만든다.
•
여러분 웹 표준의 평화를 위해서 꼭 non-chromimum, 맥에서 제일빠른! safari 또는 웹표준의 선두주자 Firefox를 씁시다!