1. 2000년대 중반부터 혁신의 단초를 제공하게 된 것은 바로 웹 표준과 웹
2.0이다.
우선 구글 같은 검색 엔진과 검색 광고의 성장과 특히, 블로그와 같은 사
용자 생산 콘텐츠를 잘 검색하기 위하여 HTML과 CSS 레이아웃을 통한
웹 표준 기법이 각광 받기 시작했다. 이른바 구조(Structure)와 표현
(Presentation) 그리고 동작(Behavior)를 분리하여 검색 크롤러(기계)가 콘
텐츠를 읽고 쓸 수 있도록 하는 것은 매우 중요한 시작점이 되었다.
특히 이러한 방식은 웹 개발에 있어서 개발자와 디자이너 간의 역할 분
담을 명확히 하고 코드 유지 보수 및 생산성에 큰 영향을 미쳤다. 게다가
장애인을 위한 웹 접근성에도 매우 뛰어난 개발 방법론이 되었다. 2004년부
터 실리콘밸리의 많은 웹2.0 스타트업들이 웹 표준 기법을 기반으로 다양
한 웹 서비스를 선보이기 시작하였고 국내에서도 많은 영향을 미쳤다.

2. 첫째, 기존의 HTML 문법이랑 사용법을 최대한 지원하고 단계적 기능
축소(Graceful degradation)이 가능하도록 한다. <b>, <i> 같은 기존의 비
표준 태그의 사용도 용법을 정해 가능하게 했으며 <embed> 같은 이미 사
용하던 표준도 재사용하도록 하여 웹 개발자들이 너무 문법에 억매이지 않
도록 하는 ‘호환성(Compatibility)’을 제공한다.
둘째, 실제 웹 개발자들이 겪고 있는 가장 중요한 문제를 순위에 따라 나
누되 문제점을 분리해서 독립적으로 해결 하는 유용성(Utility)의 원칙이다.
예를 들어, 웹폼(Web Form)에 email, number, date 같은 새로운 속성을
추가함으로써 사용자 입력 값의 유효성 확인에 드는 (항상 하는) 삽질을 줄
일 수 있도록 하였다. <input> 태그에 datetime 속성을 넣어주면 웹 브라
우저가 자동으로 달력을 표시해 준다. 또한 IE에서만 사용 가능 했던
contenteditable 속성이 표준화 되어 모든 HTML 요소를 사용자가 직접
편집할 수 있게 함으로서 위지윅 에디터의 호환성 문제도 사라질 것이다.
특히, 이미 웹 콘텐츠의 일부가 되어 버린 비디오와 오디오 콘텐츠 재생을
웹 브라우저에서 내부적으로 구현하여 보편적 접근이 가능하고 캔버스
(Canvas)와 벡터 그래픽(SVG)를 통해 2차원 도표와 같은 콘텐츠도 마크
업으로 표현 할 수 있도록 멀티미디어의 보편적 접근성을 높혔다.
셋째, 상호 호환성(Interoperability)으로 웹 브라우저가 상호 호환을 위
해 최대한 자세하게 기술하되 오류 처리 방법을 명시하도록 하였다.
HTML5의 기본 표준 문서 첫 부분은 웹 브라우저 간 HTML 문법 오류에
대한 자세한 사례와 이에 대한 브라우저의 처리 방법을 명시해 두었다. 따
라서 웹 브라우저간 이러한 문법적 오류로 인해 웹 개발자들이 실질적인
어려움을 겪는 문제를 해결하였다.

3. 90년대 후반 웹 브라우저 업체의 점유율 전쟁 중에 상용 브라우저 벤더들의
비표준 태그들이 남발되면서 개발자들은 크로스 브라우징(Cross Browsing)
라는 기법 때문에 고생하게 되었고 플래시 같은 서드파티 플랫폼이 등장
하였다.
웹의 기술적 혁신은 웹 브라우저 업계에도 역시 시작 되었고 W3C는 견고한
웹 문서를 제공한다는 꿈을 가지고 XML을 기반으로 하는 XHTML로의 전환을
시도한다.
2004년 W3C의 한 워크샵에서 생긴 의견 차이 때문에 모질라, 애플, 오페라
등은 W3C 밖에서 새로운 버전의 HTML 표준을 준비하기 시작했다.
이들은 웹 하이퍼텍스트 워킹그룹(WHATWG)이라는 공개 그룹을 형성하여
자신들이 만드는 새로운 표준안에 누구나 참여할 수 있도록 개방하였다.
2006년 10월 웹의 창시자이자 W3C를 이끌고 있는 팀 버너스 리(Tim Berner-
Lee)는 ‘Reinventing HTML’이라는 글에서 XHTML의 전환 실패와 더불어
새 HTML 작업을 시작할 것을 천명하였다.
W3C의 새 HTML 워킹 그룹은 새 표준의 이름을 ‘HTML5′라고 명명 하고
WHATWG가 작업하던 대부분의 표준안을 그대로 수용하였다.

4. 2009년 7월 W3C에서는 XHTML2.0 W/G의 활동을 완전히 접었다.
XHTML2는 XHTML1.0을 더 발전 시키기 위해 작업해온 표준이다.
XHTML2.0은 사라졌지만 XHTML이 사라진 것은 결코 아니다.
XHTML이 가지고 있는 견고한(well-formed) 문서 규격은 대형 웹 서비스에서
이용되는 마크업의 개발자 생산성 및 유지 보수에 도움이 되고 있는 점이
입증 HTML5에서도 여전히 XHTML을 지원한다.

5. 하지만 이러한 장점에도 불구하고 90년대 후반 웹 브라우저 업체의 점유
율 전쟁 중에 상용 브라우저 벤더들의 비표준 태그들이 남발되면서
HTML의 기본 정신을 훼손되었다. 실질적으로 IE vs. Netscape의 사이에
서 피해를 본 것은 ‘웹 개발자’들이었다. 크로스 브라우징(Cross
Browsing)라는 기법 때문에 고생을 했는가 하면 IE의 독주 상태 때문에
웹 서비스의 혁신이 늦어졌고 사실상 프론트 엔드의 기술 혁신은 플래시
같은 서드파티 플랫폼으로 넘어가 버렸다.
게다가 웹 표준 기구인 W3C는 견고한 웹 문서를 제공한다는 꿈을 가지
고 XML을 기반으로 하는 XHTML로의 전환을 꾀하였다. 따라서 HTML
은 4.01 버전을 끝으로 더 이상 업그레이드 되지 않는 낡은 표준으로 남았
다.

6. 새롭게 등장한 HTML5와 기존의 강자의 역할이었던 Flash와의 싸움은 꽤 오래 끌고
갈것이라고 생각하고 있었는데 세계를 강타해버린 아이폰이 플래시를 버린 덕분(?)
에 의외로 HTML5에 힘이 크게 실리고 있는 느낌입니다. 항상 세미나 가면 전세계 PC
에 99프로정도 설치되어 있다고 자랑하던 Adobe였는데(플랫폼장악력에서 엄청나다
고 할 수 있죠.) 아이폰이 플래시를 거부한 덕에 모바일시장에서는 맥을 못추고 있는
데다가 스마트폰에서 엄청난 퍼센티지를 자랑하는 아이폰덕에 모바일용 사이트들도
플래시 사용을 꺼리고 있기 때문에 급격히 힘을 잃어가는 듯한 느낌입니다. 엄청난
몸값과 장미빛 미래를 가지고 있던 플래시개발자들도 아직은 판단은 이르지만 애플
이라는 하나의 회사덕에 좀 뿌옇게 된 분위기입니다.

7. iPhone과 iPad에 Flash가 안들어간 것에 대한 질문에 대답하면서 잡스옹이 "Adobe is
Lazy"라며 강력하게 비판을 했습니다.(그외 Google에 대해서도 쓴소리를 했죠.) Adobe
가 게을러서 Flash가 엉망이라 애플은 Flash를 받아들이지 않을 것이며 HTML5가 그 대
안이 될 것이라고 하였습니다.
얼마 전, 스티브 잡스가 구글과 어도비에 대해 맹비난을 퍼부어 이목을 끌었는데 두 회
사가 왜 이리 조용하나 싶더니 드디어 어도비가 말문을 열었다. 그것도 플래시를 직접
만든 케빈 린치 어도비의 최고 기술 책임자가 말이다.
스티브 잡스의 "어도비의 플래시 기술은 HTML 5에 밀려 쓸데없는 기술이 될 것이다"
라는 발언에 케빈 린치는 자신의 블로그에 먼저 "참 좋은 제품에 플래시 플레이어가 들
어있지 않다는 것에 많이 놀랐다며, 한 업체가 사용자의 선택권을 뺏는 것이 과연 올바
른 처사냐"는 글을 남겼다.
사실상 전 세계 85퍼센트 이상의 웹사이트 컨텐츠는 플래시로 만들어졌으며, 그 중 98
퍼센트가 PC에서 열리고 재생된다. 게다가 광고는 물론 게임, 비디오 그리고 애니메이
션 등 수 많은 분야에서 플래시가 쓰이고 수십억의 사람들이 이를 보고 있다. 때문에 이
영역이 쉽사리 HTML 5에 넘어간다는 것도 무리가 있다. 게다가 HTML 5가 아무리 방대
한 기술을 가지고 있다한들 모든 부분을 대처하기에는 아직 완벽하지 않은 것이 사실이
며, 몇 몇 브라우저에서만 겨우 지원하는 단계에 가깝다.
린치의 이 같은 말에 수긍할 수 밖에 없음에도 불구하고 HTML 5의 어떤 점이 애플과
어도비 사이에 냉기류를 형성시킨 것일까? 그렇다면 HTML 5를 먼저 살펴보자.

8. 이러한 웹의 기술적 혁신은 웹 브라우저 업계에도 역시 시작 되었다. 오
픈 소스 프로젝트인 모질라(Mozilla) 커뮤니티에서 개발한 파이어폭스와
애플의 사파리, 오페라 그리고 구글 크롬에 이르기 까지 2004년부터 다양
한 웹 브라우저들이 시장에 쏟아져 나오기 시작했다.
2004년 비IE 브라우저 세계 점유율이 5% 안팎이던 것이 2010년 현재
거의 40%에 육박하고 있으며 유럽의 경우는 이미 50%를 넘었다. 웹 기술
의 변화에는 이러한 마이너 웹 브라우저 업체의 혁신과 사용자들의 선택에
힘입은 바 컸으며 마이크로소프트가 2007년 IE 개발팀을 다시 만들 정도였
다.
그러나, 웹 표준화 기구인 W3C는 이러한 변화를 수용할 준비를 하고 있
지 못했다. 2004년 W3C의 한 워크샵에서 생긴 의견 차이 때문에 모질라,
실전 HTML5 가이드
10
애플, 오페라 등은 W3C 밖에서 새로운 버전의 HTML 표준을 준비하기
시작했다. W3C의 다른 표준화 기구 보다는 상대적으로 개방되어 있었지만,
다양한 웹 브라우저 환경에서의 웹 개발자의 고충과 웹 애플리케이션이라
는 현실적인 변화를 받아들이지 못했다.

9. • HTML 의 한계로 인해서 유행처럼 번졌던 플러그인과 엑티브엑스 컨트롤의 문제들로
인해 웹은 순수한 HTML만으로는 표현이 불가능한, 너무도 많은? 외부기술에 의존하여
웹의 접근성은 현저하게 떨어지는 상황
• HTML4는 웹문서에 텍스트나 이미지, 표등을 삽입 하는 기능뿐
•브라우저간에 문서를 처리하는 방식이 달라 결과화면을 만들기 위해 브라우저별로
따로 소스를 작성하는 고생을 해야한다.
•단순히 인터넷을 통해 문서를 보기 원했던 것을 뛰어 넘어, 화려하고 인터랙티브한
화면 흐름과 멀티미디어, 예측할 수 없는 사용자들의 요구사항들을 충족시키기 위해
우리들은 HTML 에 갖가지 기술들을 만들어 내고, 포함시키고, 또 그러한 기능들을
사용할 수 있도록 하기위해 사용자들에게 "OK" 버튼을 눌러야만 사용할 수 있다는
협박으로 클릭을 강요하고, 언제, 어떻게 일어날지도 모르는 재앙에 따르는 책임을
사용자들에게 전가시켜왔다.

10. 현재 구성되어 있는 수많은 컨텐츠를 잘 보여주고 하는데는 Flash를 지원하면 당연히
좋겠지만, PC가 아닌 아이폰/아이패드 등의 스펙으로 현재 수많은 너무 많은 것들이
PC환경에 맞춰져 만들어진 Flash로 구성되어 있는 그런 웹으로 원활히 보여준다는 것
도 그다지 좋지 않은 것은 맞는 것 같다. 그리고 애플이 옵션으로라도 flash를 보거나 할
수 있게 했더라면 또 지금만큼 HTML5가 화제가 되지도 전체적인 웹이 나아가는 방향
의 변화에도 크게 영향을 주지는 못했을 것 같다.
애플의 이런 정책이 아니었다면 아마 계속 수많은 컨텐츠는 Flash로 만들어졌을테고...
요는...HTML5, Flash 누가 이길까나... 대체된다거나 그런 것이 아닌 나름 균형을 맞추
어 나가는 방향으로 가는것이 참 바람직한 것 같고.. Flash라는 엄청난 존재를 배제하는
엄청난 대인배적인 정책으로 애플은 미래의 웹이 나아갈 방향에 큰 영향을 미치고 있다
는 것이다.....기존 수많은 컨텐츠와 개발자, 애니메이터를 가진 Flash라는 엄청난 존재
를 배제시키고도 아이폰/아이패드를 엄청나게 히트시킨 애플도 참 대단하다는 생각..

11. Flash는 엄연히 화려한 애니메이션 등을 만드는데 매우 특화되어 태어났었고 그 영역
은 HTML5가 침범하기는 쉽지는 않을테니..다만 Flash가 그동안 애니메이션을 시작
으로 동영상/음악 플레이어, 게임, 텍스트 꾸밈 등등의 다양한 영역을 다 점령해나가
기 시작해서 웹에서 Flash에 대한 의존도가 너무 높아졌었던듯 싶다. 이제 너무나도
웹에 기본이 되어가는 음악, 영상 등등의 것들이 Flash에 너무 의존하게되어 가는 것
은 좋지 않은 것은 맞는 듯하다.
이런 시점에서 애플의 정책은 어떤 의도를 가지고 있던 너무나 Flash에 의존적으로
가고 있는 방향에서 HTML5에 큰 관심을 불러일으키게 된 것은 매우 긍정적인 결과
인 것 같다.
꼭 Flash 자체의 문제라고 말할 수는 없지만 잘못 만들어진 Flash들로 인해 엄청나게
시스템에 부하를 주는 경우도 많은 것은 사실이고 Flash가 다 점령해가던 영역들을
HTML5와 적당히 나누어가지면서 나가는 방향은 좋은듯하다.

12. • 웹은 이제 단순히 정보를 보여주는 웹이 아닌 스스로 특정기능을 실행하는 프로그램
ex) 구글 문서도구, MS의 웹오피스의 편집 프로그램, 네이버의 네이버 me
• 플러그인과 엑티브엑스기술에서 웹을 해방시키고 웹의 접근성과 상호운영성 또한
높이게 하는 결과를 가져오게 될 것이다.
•HTML5 전체 스펙이 완성되지 않았지만 HTML5의 많은 부분은 현재로서도 사용 가능
•HTML5를 지원하는 장치와 브라우저가 점점 늘어나고 있음.
(마이크로소프트, 구글을 위시한 기업들이 각 사의 브라우져를 Web OS 로서의 기반
플랫폼으로 구성하고 있고, 각 사들의 서비스들을 HTML 5로 제작하여 차세대 Web
환경에서의 주도권을 갖기위해 노력) N-screen등으로 변화가 불고 있으며 조작해야할
주변기기의 종류도 다양해진다.
•so, 디자이너와 개발자들은 최종 스펙까지 기다려서는 안됨
•이미 html4도 초안이 2007년에 나왔지만 우리는 이미 사용하고 있었기때문에..

13. 의미 있는 문서?
전 세계에 퍼져 있는 웹 문서의 수는 어마어마하다.
구글 검색을 통해 찾지 못할 정보가 없을 만큼 방대한 웹 문서들이 존재한다
웹 문서를 온라인에 등재하는 목적은,초기에도 그랬지만 현재에도 그리고 미래에도 마찬가지로
정보 공유, 정보 전달에 궁극적인 목적이 있다
웹에 문서를 표현하기 위해 문서 규칙을 마크업 형태로 정의한 것이 HTML 이다
초기 웹, 그리고 웹을 위한 HTML 문서는 약속된 몇명 만을 위한 것이었지만 시간이 갈수록 웹을 기반으로 하는
정보 공유와 취득의 요구는 기하급수적으로 늘어났다. 지금은 웹 없는 정보란 상상할 수 없을 정도이다.
이렇듯 자료가 방대해지는 것은 정보의 소스가 다양해 진다는 긍정적인 측면이 있는 반면,
너무 방대한 자료로 인해 원하는 정보를 정확하게 찾기 힘들다는 부정적인 측면도 존재하는 것이다
특히 모호한 표현과 일관되지 않는 문서구조는 정확한 정보 검색에 걸림돌이 된다
이러한 흐름에 따라 정확하고 가치 있는 정보 탐색을 위한 요구사항이 점점 늘어나고 있는데,
웹 세상에 방대하게 퍼져있는 웹 문서를 보다 쉽게 탐색하고 보다 정확하게 해석하고 보다 의미있게
구분하고 보다 쉽게 조합하기 위한 시맨틱 웹(Semantic Web)도 이런 요구에 부응하기 위해 탄생한
개념이다
시멘틱 웹을 위해서는 정보를 표현하는 문서의 구조가 규칙적이고 일관되어야 한다
HTML5 에서는 문서 구조를 위한 새로운 마크업들이 추가되었는데 이는 바로
시멘틱 웹의 실현을 위한 시멘틱 요소의 추가이다

14. 기존 웹 문서의 한계
HTML5 이전의 웹 문서 즉 HTML 문서는 구조보다는 표현을 위한 수단에 가까웠다
Table 태그, ul, li 태그, div 태그 등으로 문서 구조를 정의할 수 있지만 이것은 의미있는 구조라기
보다는 표현을 위한 구조 잡기에 가까웠다. 다시 말해 각 태그들은 일관된 목적을 위해 사용되는 것이 아니라 문서
를 Display하기 위해 제각각의 형태로 사용되어진게 사실이다.
다시 말해 HTML5 이전의 문서 표현 태그들은 문법적 규칙은 있었으나 구조의 규칙은 존재하지 않았다
이러한 문서는 사람이 읽기에는 적합하지만 자동으로 문서 구조를 파악하고 분류 및 탐색하기에는 힘든 구조이다.
즉 시맨틱스럽지 못하다는 것이다
참고로 의미있는 구조의 대표적인 형태가 XML 문서이다
XML 의 탄생 자체가 논리적인 문서 구조를 위한 것이며 텍스트 기반의 표준화된 형식이기 때문에
매우 시맨틱스럽다고 할 수 있다. SOAP, RSS 등에 XML이 이용되는 것도 바로 이러한 측면 때문이다
W3C에서는 이러한 XML의 특징을 HTML로 녹여서 시맨틱 웹을 실현하고자, XHTML 이라는 스펙을 내 놓기도 했
다. XHTML은 HTML을 XML형식으로 기술할 수 있도록 하여 XML 자체의 장점인 데이터의 구조화 및 의미화 그리
고 확장성을 웹 문서에 적용하기 위한 기술이다
W3C는 한때 XHTML 을 차세대 웹 표준으로 추친하고자 했으나 기대만큼 널리 보급되지 못해 중지되었지만 시맨
틱 웹을 향한 의지는 꺼지지 않았다
HTML5에 추가된 시맨틱 요소
XHTML 의 보급 실패 이후 제안된 것이 바로 HTML5 이다
XHTML 에 이어 HTML5에서도 시맨틱을 향한 의지가 포함되어
머리글, 바닥글, 탐색줄, 사이드바와 같은 문서 구조를 위한 시멘틱 태그들이 추가되었다
이러한 시멘틱 태그들은 문서의 구조와 영역 그리고 범위를 명확히 함으로써 웹 페이지의 전체 또는 부분에 의미를
부여할 수 있게 하여 HTML 문서를 보다 시맨틱하게 구성할 수 있도록 한다

15. IE(Internet Explorer) 를 위한 대안
표에서도 나와 있듯이 IE 8 을 포함한 이전버전에서도 HTML5 의 시멘틱 요소를 지원하지 않는다
IE8에서(그리고 그 이전 버전에서) <section> 이나 <article>와 같은 태그를 사용하면 브라우저는 이를 인식
하지 못할 뿐더러 이들 태그에 부여된 스타일도 적용되지 않는다. 따라서 이들 요소에 스타일이 정상적으로
표현되기 위해서는 createElement() 함수를 이용해 새로운 태그를 정의해야 한다
문서에 정의된 HTML5 요소 모두에 이 처리를 다 해주어야 하는데 이를 도와주는 스크립트가 구글 코드를
통해 제공되고 있다

16. HTML 의 한계
HTML, 참... 오랜 기간동안 사용된 언어임에 틀림없다.
그리고 HTML 4 에 대한 그때의 지식으로 오늘날까지도 HTML 을 읽고 있는 것을 보면 변화 없이 멈추어버린 언
어라고 생각이 될 수도 있겠지만 HTML 의 버전업이 없다고 웹이 발전하지 않았다는 말은 아닐 것이다.
본래 HTML 이 처음 만들어졌을 때의 목적은 인터넷을 통해 문서를 보기 위함이었다.
자신이 가지고 있는 문서들을 웹을 통해서 볼 수 있도록 문서 형태로 표현할 수 있는 그 수단? Language가 필요
했다.
Dos 의 640K 메모리 장벽이 그러했고, Y2K 밀레니엄 버그가 그러했듯이, HTML 또한 그 당시에는 지금의 웹을
상상도 할 수 없었으리라 생각된다.
단순히 인터넷을 통해 문서를 보기 원했던 것을 뛰어 넘어, 화려하고 인터랙티브한 화면 흐름과 멀티미디어, 예
측할 수 없는 사용자들의 요구사항들을 충족시키기 위해 우리들은 HTML 에 갖가지 기술들을 만들어 내고, 포
함시키고, 또 그러한 기능들을 사용할 수 있도록 하기위해 사용자들에게 "OK" 버튼을 눌러야만 사용할 수 있다
는 협박으로 클릭을 강요하고, 언제, 어떻게 일어날지도 모르는 재앙에 따르는 책임을 사용자들에게 전가시켜
왔다.
웹은 그렇게 HTML 버전의 발전은 없었지만 HTML 의 한계를 벗어나기위한 방향으로 발전?되어 왔다.
하지만 그렇게 한계를 벗어나기 위한 발전이 반복되면서 한계의 극복은 더욱 불완전한 웹환경으로 몰아가기 시
작했다.(너무 장황한거 아녀? ㅡㅡ' 어여 영웅이 나타나야 할 것 같은...)
세상은 이런 불완전함을 깨뜨리고 순수하고 완전한 존재를 원하게 되었다.
그래서 나타난 것.
"HTML 5" 다.

17. XX에 최적화라는 말은 YY 또는 ZZ에서는 문제가 발생할 수도 있다는 위험을 내포하고 있다. 모바일에
최적화된 웹사이트라는 말도 크게 다르지 않다. 더군다나 모바일 최적화라는 말을 아이폰 최적화, 또는 몇몇
단말기에 탑재된 안드로이드 브라우저 최적화라는 말로 사용하는 현실에서는 이런 위험성이 더 크다.
내가 최근에 실무에서 접해본 가장 작은 화면 크기는 180픽셀이었다. 우리나라에서도 현재 화면폭이
240픽셀인 휴대폰으로 웹사이트를 사용하고 있다. 실제로 이렇게 작은 화면을 가진 휴대폰을 사용해 보면
우리가 보통 모바일에 '최적화'되었다고 얘기하는 많은 모바일 전용 페이지들이 말처럼 최적화되지 않았다는
것을 알 수 있다. 모바일이라는 환경은 우리가 생각하는 것 이상으로 다양하다. '최적화'라는 접근 방법으로는
그 다양성을 만족시킬 수 없다.
이런 문제를 해결하기위한 시도는 과거에도 계속 있었다. 그 시도들이 쌓여서 새로운 개념으로 재탄생하게
되었는데 바로 반응형 웹디자인(responsive web design)이라는 개념이다. 화면 너비에 따라 유동적으로 변하는
유동형 레이아웃(fluid layout)과 유연한 이미지(flexible image), 그리고 미디어 쿼리(media queries)가
어우러져서 특정 환경에 '최적화'된 방법이 아니라 환경에 반응하여 스스로 적응하는 방법이다.
반응형 웹디자인 개념이 나오기 이전에도 비슷한 시도들이 많이 있었다. 하지만 너무 넓은 화면이나 좁은
화면에서는 한계가 있을 수 밖에 없었고 정말로 원하는 디자인을 적용하기는 쉽지가 않았다. 하지만 미디어
쿼리의 등장으로 이런 고민이 해결되었다. 반응형 웹디자인을 적용한 웹사이트들을 살펴보면 보다 쉽게 이해할
수 있다(인터넷 익스플로러는 IE9부터 미디어 쿼리를 지원하기 때문에 오페라나 파이어폭스와 같은
브라우저를 사용해야 한다. IE에서도 적용하는 방법은 차후에 다뤄볼 예정이다.). 브라우저 창의 크기를
바꿔가면서 웹사이트가 어떻게 반응하는지를 살펴보면 된다.
'예산이 충분'하다면 아이폰용 사이트도 만들고 아이패드용 사이트도 만들고 갤럭시 탭용 사이트도 만들고
여러벌 만들 수 있는대로 만드는 것도 좋다. 하지만 이런 접근 방법은 만들어진 이후 유지 비용도 고려해야 하고
새로운 단말기가 나올 때 마다 기민하게 대응해야 하는 방법이라는 것을 유념해야 한다. 물론 할 수 있고 실제로
하는 기업도 있다. 하지만 대부분의 경우에는 이렇게 계속적인 투자를 하기가 쉽지 않을 것이다.
모바일 환경에 대응한다고 아이폰용 사이트 하나 만들고 손터는 에이전시가 많다. 단말기도 없는 상황에서
모바일 페이지를 테스트하겠다고 덤비는 사람도 있다. 그동안 방법을 몰랐다면 이 반응형 웹디자인을 살펴보는
것이 도움이 많이 될 수 있을 것이다. 지금은 핸드폰 몇종에 태블릿 두어개 나왔지만 앞으로는 정말 다양한
환경을 고려해야 한다. 실제로 이미 TV도 나왔다.

18. 우리는 지금까지 컴퓨터 OS에 따라 웹에서 비디오나 오디오플레이어를 이용해서
실행하고 그렇지 않을경우 플래쉬 재생 프로그램을 장착하여 동영상을
변환하면서
힘들게 동영상을 올려왔다.
하지만 이런 번거로움 없이 html5가 지원하는 플레이어를 사용한다면 앞전의
고민은 끝낼수 있다.
이 모든 고민을 해결 할수 있는 비디오 태그를 살펴보자
HTML5의 비디오 태그가 플래쉬 재생 프로그램을 대체 할 수 있으리란 기대가
커지면서 어떤 비디오 코덱이 표준 자리를 차지할 것인가를 놓고 매일 갖가지
뉴스들이 쏟아져 나오고 있다.
그동안 가장 유력하게 거론되어 온것은 가장 많이 사용되어왔지만 사용료를
지불해야하는 H.264코덱이였다. 그러나 HTML5의 입장에서는 유료기술을
표준으로 할수 없다는 입장을 고수하였고 2010년 초 구글이 VP8코덱을 오픈
소스로 공개함으써 또다른 이슈를 낳고 있다.
결국 H.264는 유료정책을 포기, HTML5 웹표준 동영상 재생용도로 사용할 경우에
한해 무료로 사용할 수 있게 한다는 정책 발표, 또다른 이슈화가 될것으로 보인다.

19. 지금까지 HTML 폼을 만들려면 마크업을 이용해서 텍스트 필드나 단추같은 폼을
만들고, 자바스크립트를 이용해서 확인프로그램을 실행해야 했다. 하지만
HTML5에서는 폼만들기가 훨씬 편리해졌다.
단추로 폼 컨트롤
그전에 form엘리먼트 안에 button엘리먼트에서 별도로 기능이 수행 가능하게
되었다고 보면된다. 그리고 form보다 button엘리먼트 의 수행이먼저 처리된다.
다음은 form과 button에서의 동일 역할 수행의 속성 엘리먼트 비교이다.
action : Formaction
enctype : Formenctype
method : Formmethod
novalidate : Formnovalidate
target : Formtarget
http://wufoo.com/html5/attributes/13-formaction.html
http://www.clearboth.org/wiki_html5/doku.php?id=html5:attribute:formaction

20. 쿠키는 웹사이트가 사용자의 하드디스크에 집어넣는 특별한 텍스트 파일로, 이것은 후에 그 사용자에 관하여 무엇인가를
기억할 수 있도록 하기 위한 것이다. 일반적으로, 쿠키는 특정한 사이트에 대한 그 사용자의 취향을
기록한다. 웹의 프로토콜인 HTTP를 사용하면, 웹 페이지에 대한 각각의 요구는 다른 요구들과 상관 관계없이 모두
독립적이다. 그렇기 때문에 웹 서버는 그 사용자에게 이전에 어떠한 페이지가 보내어졌는지에 관한 아무런 기록도 가지고
있지 않으며, 심지어 그 사용자가 이전에 방문했었는지조차 알기 어렵다. 쿠키는 웹서버에게 사용자에 관한 파일을 사용자
컴퓨터에 저장하도록 허용하는 장치이다. 쿠키 파일은 대개 자신이 사용하는 브라우저 디렉토리의 하부에 저장된다 (예를
들어, 넷스케이프 디렉토리의 서브 디렉토리 등). 쿠키 디렉토리에는 사용자가 방문했던 각 웹사이트에 대한 쿠키 파일들이
모두 저장되어 있다.
쿠키는 일반적으로 배너광고를 회전시키기 위해 사용되기도 하지만, 사용자가 쓰고 있는 브라우저의 형식 또는 그
웹사이트에 이미 제공했던 다른 정보에 기초를 두어 서버에서 보낼 웹 페이지들을 사용자에게 맞추는 데에도 사용된다. 물론,
웹 사용자들은 쿠키가 자신의 컴퓨터에 저장되는 것에 동의해야만 하는데, 대개는 이러한 것들을 통해 웹사이트가
사용자들을 좀더 잘 지원하는데 도움을 준다.
로컬 스토리지 예를들어 웹사이트 방문자수를 계산 해야 할때 이용한다.

21. Web Workers 개념도
웹 워커는 HTML 페이지에서 Worker 라는 객체를 통해 실행된다
HTML 페이지에 Worker 객체를 생성하기 위해서는 워커의 작업을 정의한
자바스크립트파일(.js)
을 Worker 객체 생성 시 전달해 줘야 한다
ex) var worker = new Worker("worker.js")
이후 롱~타임 작업은 .js 파일에 정의된 스크립트로 수행되며,
HTML 페이지와는 서로 데이터를 주고 받을 수 있는 매커니즘이 제공되는 것이다
양쪽 모두 상대에게 데이터를 송신할 때는 postMessage 라는 메서드를 이용하며
데이터를 수신할 때는 onmessage 이벤트를 통해 전달 받는다
아래 그림은 기본적인 (단일) 워커와 HTML 페이지 간 데이터 송/수신 개념도 이다

22. 여러가지 모바일 OS기반으로 하는 애플리케이션이 속속 소개되면서 웹 애플리케이션에 대한 관심도
높아지고 있다. 모바일 웹 애플리케이션을 사용하기 위해서는 인터넷에 연결할 수 없는 순간에도
애플리케이션이 실행되도록 하는 오프라인 웹 애플리케이션이 중요하다. 그를 위해서 필수적인 애플리케이션
캐시 기능에 대해 알아보자
웹 애플리케이션은 모바일 OS에 구애받지 않고 어떤 환경에서든 실행할 수 있기 때문에 주목받게 될것이다.
하지만 모바일 환경의 웹 애플리케이션은 웹상에서 실행하는 것이기 때문에 웹에 접속 할수 없는 상황에서도
애플리케이션이 실행 되도록 하는것이 중요하다. 오프라인 상태에서도 애플리케이션이 실행되도록 하기 위해
필요한 것이 애플리케이션 캐시 기능이다.
웹 애플리케이션 제작에 있어서 중요한 기능 중 하나가 클라이언트 쪽에서 데이터를 저장 할 수 있는
기능입니다. 지금까지는 쿠키정도의 기능이 다였는데, 그나마도 일시적인 저장 기능밖에 없었기 때문에
애플리케이션을 제작하는 데는 도움이 되지 않는다. html5에서 새로 소개하는 웹 스토리지 기능은 쿠키와
어떻게 다른지 살펴보자