[블로터포럼] HTML5가 개발자에게 ‘기회의 땅’인 이유
화끈하고도 딱딱한 주제가 ‘블로터 포럼’ 대문에 걸렸습니다. ‘HTML5′랍니다. 기술 용어인 탓에 프로그래밍 지식이 없이 이해하는 데는 한계가 있을 겁니다. 그러니 딱딱한 주제이죠. 허나 HTML5는 요즘들어 몸값이 후끈 달아오른 따끈한 이슈이기도 합니다. 해가 바뀌면서 주목받는 기술을 꼽을 때면 빠지지 않는 단골이기도 하고요.
우연의 일치일까요. ‘블로터 포럼’을 진행한 뒤 애플 스티브 잡스가 때마침 제대로 한 방 날렸더군요. 아이폰에서 플래시를 지원하라는 어도비를 향해 ‘플래시 대안은 HTML5′라며 ‘어도비는 게으르다’고 심기를 건드린 겁니다.
왜 갑자기 여기저기서 HTML5를 외치는 걸까요. 특정분야 개발자들을 빼고는 대체로 비슷한 반응을 보입니다. HTML에 익숙한 사람도 HTML5 앞에선 꿀 먹은 벙어리마냥 얌전해집니다. 딱딱하고 어려운 게 사실이지만 알아두고 준비해야 할 기술. 이번 ‘블로터 포럼’에선 입문자 눈높이에 맞춰 HTML5를 들여다보고 싶었습니다.
- 일시 : 2010년 1월27일(목) 오후 5시~7시
- 장소 : SK커뮤니케이션즈 회의실
- 참석자 : 윤석찬 다음커뮤니케이션 DNA랩 팀장, 도안구·이희욱·주민영 블로터닷넷 기자
이희욱 | 오늘 주제가 참 어렵다. HTML5 문외한 입장에서 궁금한 점이 많다. 먼저 묻고 싶다. HTML5가 뭔가?
윤석찬 | HTML5가 어느 날 갑자기 나타난 게 아니다. 사연이 길다. 1998년 HTML4.01 이후 웹표준을 개발하는 국제 컨소시엄인 W3C는 XHTML 표준 개발에 박차를 가했다. 웹브라우저 전쟁 이후 그 작업에서 웹브라우저 제조사들이 빠졌다. 이후 웹표준의 방향은 XML을 기반한 꽤 이상적인 표준을 만들기 시작했다. 2004년 파이어폭스가 나오고 아작스(Ajax)와 웹2.0이 활성화되면서 문서가 아닌 웹애플리케이션을 위한 웹표준의 재정비가 필요했다.
하지만 이러한 현실적 요구를 W3C가 받아들이지 않았다. 웹브라우저 제조사들에게는 W3C의 XHTML2.0과 XML기반 DOM 및 이벤트 핸들러 등은 루비콘 강을 건너는 것이다. 당시 XHTML 문서가 전체 웹에서 5%에 불과했고 웹브라우저 엔진들의 차이 탓에 개발자들은 ‘크로스 브라우징’에 생고생을 하고 있었다. 2004년 W3C의 한 워크샵에서 서로 틀어진 뒤 모질라와 오페라, 애플과 구글은 별도의 ‘웹 하이퍼텍스트 애플리케이션 테크놀로지 워킹그룹’(WHATWG)이라는 공개 표준 그룹을 만들고 새로운 HTML 표준안을 만들기 시작했다. 이것이 바로 HTML5의 시초다.
도안구 | W3C와 웹브라우저 제조사 사이에 그런 의견 다툼이 있었나? 흥미롭다.
윤석찬 | 반목이 오래가지는 않았다. 2006년 팀 버너스 리 경이 ‘리인벤팅 HTML’(Reinventing HTML)이라는 글을 쓰고 WHATWG을 W3C 안으로 받아들이기로 결정하면서 2007년초께 다시 W3C에 HTML 워킹그룹이 결성됐다. 당시 재미있는 에피소드라면 WHATWG의 개방적 표준 활동에 참여하던 700여명 멤버들이 W3C 안 초청 전문가(Invite Expert) 형식으로 대거 들어왔다는 점이다. W3C 역사상 초유의 일이다. 그 때 나도 함께 했다.
기존 WHATWG 표준 초안을 가져오며 ‘HTML5′라 불렀다. 당시 IE7 개발을 맡았던 MS 유명 아키텍트인 크리스 윌슨이 워킹그룹 의장이 됐고 모질라, 오페라, 애플, 구글 등 모두 참여해 HTML5 표준을 만들고 있다.
주민영 | 복잡한 과정을 거쳤다. HTML5는 왜 만들어지게 됐나?
윤석찬 | 기존 웹브라우저들이 제공하는 웹표준 수준이 조금씩 다르고 기존 스펙의 모호성으로 인해 버그도 많다. 제조사마다 다른 렌더링 엔진을 쓰고 당연히 차이가 있다. 웹 개발자들은 각각 테스트해봐야 하는 어려움이 있다. 이를 해소하기 위해 HTML5의 새로운 문서 형식 제안하고, 이 독타입(DOCTYPE)을 사용할 경우 기존 엔진 문제점들을 고쳐 제공해줘 웹 개발자들을 고생에서 벗어나게 해주자는 취지다.
HTML5 독타입은 매우 간단하다. ‘< !DOCTYPE HTML >’ 이렇게 HTML 파일 맨 앞 줄에 넣어주면 끝이다. 이 뒤에 나오는 코드는 웹브라우저마다 HTML5에 맞춰 렌더링한다. HTML5 표준 초안은 웹브라우저 엔진 개발자들을 위해 만든 것으로, 보다 상세하게 구현 내용을 적고 있다.
두 번째 목적은 동적 웹애플리케이션을 지원할 리치 웹 기술을 담고 있다는 것이다. 멀티미디어를 다루는 ‘canvas’, ‘video’, ‘audio’ 태그를 비롯해 웹브라우저 내 로컬 스토리지를 다루는 돔 API와 드래그앤드롭 API 등 일반 표준 문서에서는 보기 힘든 다양한 기술이 뒤섞여 있다. 특히 웹 개발자 수고를 덜어줄 ‘웹폼2.0′이라는 표준과 함께 쓰면 보다 멋진 리치 웹애플리케이션을 만들 수 있다.
웹브라우저 안에 DB를 탑재해 로컬 스토리지로 활용해 오프라인에서도 데이터를 싱크해 활용할 수 있다. 구글 G메일 ‘오프라인’ 기능이 그렇게 구현돼 있다.
이희욱 | 리치 웹애플리케이션이라면 플래시나 실버라이트를 얘기할 때 자주들 언급한다. HTML5가 리치 웹에 주목하는 이유는 무엇인가?
윤석찬 | 웹브라우저 업체 입장에서 리치 웹 기술에 관심을 갖는 이유는 다양하다. 제가 참여하고 있는 모질라 커뮤니티의 경우, 웹은 읽을 수 있고(readable), 저장할 수 있고(Indexable), 편집할 수 있어야(editable) 한다고 믿는다. HTML 소스를 보고, 복사를 하고, 고칠 수 있었기 때문에 웹 문서가 비약적인 성공을 했다. 기존 플러그인 기반 리치 웹 기술들, 예컨대 플래시나 실버라이트는 그게 어렵다. 물론 이들도 XML 기술을 통해 이용자화면(UI)을 만들 때 스크립트 언어로 동작을 제어한다. 하지만 결국 읽을 수 없는 ‘바이너리’를 포함하고 있다. 이는 웹 본질과 일치하지 않는다. HTML5가 리치 웹 기술의 선택 가능한 대안으로 자리잡아야 한다.
물론 아직 플래시나 실버라이트에 비해 HTML5가 제한 사항이 많다. 하지만 궁극적으로 웹이 나아갈 방향이라고 본다. 구글이나 오페라와 애플도 이러한 점에 동의를 하고 있고 MS 역시 미온적이지만 참여를 하고 있다. 초창기 많은 사람들이 ‘리치 웹 환경에서 HTML5가 성공할 것인가’라는 물음엔 회의적이었다. 지금은 많이 바뀌었다. 이런 ‘블로터 포럼’에도 불려다니는 걸 보면. (웃음)
도안구 | HTML5가 주목 받게 된 특별한 계기나 사건이 있나?
윤석찬 | 아무래도 구글 영향이 컸다. 지난 2009년 4월에 열린 ‘구글 I/O 컨퍼런스’가 전환점이 됐다. 구글은 2008년 첫 구글 I/O 컨퍼런스에서 안드로이드와 구글 기어스를 발표했다. 구글 기어스는 리치 웹애플리케이션을 만들기 위한 웹브라우저 플러그인이었다. 하지만 2009년 컨퍼런스에선 구글 CTO가 첫날 주제로 HTML5를 다루고, 둘쨋날 구글 웨이브를 다뤘다. 그런데 첫날 HTML5를 얘기하면서 ‘HTML5가 대세’란 분위기를 크게 조성했다. 자사 웹브라우저인 ‘구글 크롬’에도 아직 탑재 안 된 HTML5 기술을 파이어폭스와 사파리로 시연할 정도였다. 그러면서 인식이 많이 바뀌었다. 구글이 드디어 HTML5에 베팅하는구나. 시장에도 긍정적인 신호를 줬다.
특히 모바일을 보면 완전히 다르다. 지금 PC의 웹브라우저 시장은 IE가 다수이고 파이어폭스, 크롬, 사파리가 따라오는 모양새다. 모바일 웹에서는 유럽 스마트폰 시장은 오페라가, 아이폰은 사파리를 기반하고 있다. 안드로이드폰이 나오면 크롬이 주력으로 들어간다. 모질라를 빼도 메이저 3사다. 결국 IE가 대세가 아니다. 모바일 애플리케이션 개발 환경은 PC 못지않게 폐쇄적이다. 이런 상황은 오래 가지 않을 것이고, 결국 범용 리치 웹 환경을 사용하는 것으로 바뀔 것이다. 특히 모바일 웹의 변화가 더욱 빠를 것 같다.
주민영 | 허나 애플 아이폰이 촉발시킨 앱스토어도 개발자 입장에선 큰 기회다.
윤석찬 | 물론 지금은 앱스토어가 유행이다. 돈벌이가 아니라 서비스를 만드는 관점에서 보면, 지금은 앱스토어용 따로, 웹애플리케이션 따로 만드는 식으로 과도기다. 결국 HTML 표준으로 웹 문서를 만들듯 웹애플리케이션도 표준으로 쉽게 만들고 서비스하는 환경이 와야 한다. 폐쇄적인 개발 플랫폼을 기반으로 하는 플레이어도 필요하지만 모두에게 이익이 되는 범용 개발 환경이 웹의 목표이고 지향하는 바다. 웹 개발자들은 이를 간과하면 안된다.
이희욱 | HTML5는 그럼 웹 개발자들을 위한 표준 기술 문서인가?
윤석찬 | 앞서 말했듯이 HTML5는 웹브라우저 엔진 개발자를 위한 스펙이다. 하지만 이 안에는 렌더링 엔진 뿐만 아니라 중요한 리치 웹 기술이 포함돼 있다. 예컨대 크롬이 탭마다 적용한 병렬 프로세스 기능이나 외부와 데이터를 주고받을 때 웹브라우저가 어떻게 처리할 지 규약도 있고, 데스크톱에서 웹브라우저로 드래그앤드롭한 파일을 어떻게 처리할 지에 관한 스펙도 있다. HTML 뿐 아니라 방대한 내용들이 추가되고 있다. 초안 자체가 어렵기 때문에 웹 개발자들이 이를 쉽게 이해하고 이용할 수 있도록 설명 문서들도 함께 만들고 있다.
도안구 | 그 스펙은 계속 추가되고 실제 구현되고 있나?
윤석찬 | W3C 표준 제정 과정을 보면, HTML5는 현재는 초안 단계다. 한 단계 넘어가기 위해 준비 중이고 이는 정해진 내부 프로세스를 따라가는 것이다. 무엇보다 중요한 건, HTML5의 어떤 기술이 웹브라우저에서 구현되고 있고 얼마만큼 사용할 수 있느냐 하는 점이다. 현재 PC 기반 웹브라우저에서 HTML5의 주요 기능을 쓰는 데는 아직 무리가 있다.
가장 중요한 건 IE가 아직 안 바뀌었고, 각 웹브라우저 제조사 사이에도 기술적 차이가 있다. 하지만 ‘canvas’, ‘video’, ‘audio’ 태그와 돔 스토리지 등은 어느정도 쓸 수 있는 단계에 와 있다. 올해 초 MS가 공식적으로 IE9에서 HTML5를 지원하겠다고 밝혔다. 어느 정도까지 지원할 지 모르겠지만, 올 3월 MIX에서 HTML5 기능을 탑재한 IE9을 만나볼 수 있을 것으로 기대한다.
주민영 | 유튜브나 비메오 같은 동영상 공유 사이트가 플래시 대신 HTML5를 수용하겠다고 해서 화제가 되기도 했다.
윤석찬 | 유튜브나 비메오 등이 수용한 건 HTML5의 일부다. ‘video’ 태그를 이용해 플러그인 도움 없이도 웹브라우저 만으로도 동영상을 서비스할 수 있다. 지금까지는 윈도우 미디어 플레이어나 플래시 플러그인을 깔아야만 가능했다. 문제는 동영상 코덱에 있다. 파이어폭스와 오페라는 오픈소스 기반 OGG 테오라(OGG Theora)를 지지해왔다. 하지만 크롬과 사파리는 특허료를 내야하는 H.264 MPEG 포맷을 지원한다. 유튜브와 비메오도 H.264 코덱을 지원하기 시작했다. 이 때문에 파이어폭스도 H.264 코덱을 지원해야 한다는 여론이 일었다. 이에 대해 모질라 제품담당 마이크 셰이버는 거부 의사를 분명히 했다.
파이어폭스가 H.264 코덱을 이용하는 데 1년에 500만 달러 정도의 특허료를 지불해야 하다. 모질라 입장에서 그리 큰 돈은 아니다. 하지만 문제는 이를 통해 서비스 개발자 및 업체 모두 2011년부터 특허료를 내야 한다. 이는 선택 가능한 대안을 중요시하는 모질라의 미션과 배치되는 것이다. 코덱은 물론 웹의 영역은 아니다. 하지만 플러그인들이 오픈웹에 큰 걸림돌이 되듯, 폐쇄형 코덱은 오픈 비디오 환경에 도움이 되지 않는다고 판단한다.
이희욱 | 그럼 유튜브 HTML5 비디오 태그와 파이어폭스의 연동은 영영 안 되는 건가?
윤석찬 | 가능성은 있다. 구글이 지난해 8월, 동영상 코덱 업체 ‘온투(On2) 테크놀로지’를 인수했다. 구글이 온투 코덱을 오픈소스와 특허 무료로 공개하는 거다. 온투 코덱은 플래시와 호환된다. 이러한 계획은 이미 구글도 밝힌 바 있다. 테오라 역시 온투의 과거 버전이 오픈소스화 된 것이다. 오픈 비디오 환경은 이래저래 구글의 결정에 큰 영향을 받게 될 것이다.
주민영 | 그럼 국제적으로 HTML5가 널리 퍼지고 있는가?
윤석찬 | 사람들이 잘 모르는 게 있다. 구글 첫 화면에서 소스코드를 열어보라. HTML5 독타입이다. 예전 HTML 4.01 독타입을 쓰다가 지난해 하반기에 바뀌었다. 그렇다고 밑에 코드들이 마크업 유효성에 다 통과된 것은 아니다. 하지만 한 발걸음이 중요하다.
2005년쯤 다음이 첫 화면을 W3C 인증을 통과한 웹표준으로 바꾼 적이 있는데, 당시 많은 사람들이 첫 화면만 웹표준을 적용하면 뭐하냐는 반응들을 보였다. 회사 내부에서 선언적으로 첫화면을 바꿈으로서 모든 웹서비스에 영향을 줘, 많은 것이 바뀌었다. 구글 내부에서도 이러한 움직임이 계속될 것으로 보인다. 그런 리더십이 업계 전반에 영향을 준다.
도안구 | 국내 웹사이트들의 HTML5 도입 현황은 어떤가?
윤석찬 | 아직까지 국내에서는 HTML5에 대한 웹 개발자들의 관심이 높지는 않다. HTML5 독타입을 쓰면 표준 모드로 동작하므로 사용해도 지장은 없다. 우선 HTML5에 대한 문서자료와 HTML5갤러리나 HTML5닥터 웹사이트에서 다양한 예제를 살펴보고, 가능한 것부터 해보는 것이 좋겠다.
- HTML4와 HTML5의 차이점 : http://channy.creation.net/project/html5/html4-differences/
- HTML5 Design Principals(영문) : http://dev.w3.org/html5/html-design-principles/
- HTML5 Reference (영문) : http://dev.w3.org/html5/html-author/
이희욱 | 그럼 XHTML은 더 이상 개발 되지 않는 것인가?
윤석찬 | 그렇지 않다. 물론 XHTML 2.0 표준 개발은 완전히 멈췄다. 지난해에 그룹이 해체됐다. 하지만 XHTML의 유용성은 그대로 있기에, HTML5 문서를 XHTML로도 표현할 수 있고 이를 위한 독타입을 선언하면 그대로 XHTML 문서로 유효하다. 이를 ‘XHTML5′라고 부른다. XHTML은 여전히 HTML5 안에서 유효하다.
주민영 | HTML5가 산업에 미치는 영향은 어떨 것으로 예상하나?
윤석찬 | 가장 큰 수혜자는 기존 웹 개발자다. 요즘 모바일 애플리케이션 개발자는 중고 매킨토시를 산 뒤 코코아 개발환경을 익혀 앱스토어에 애플리케이션을 올리고, 안드로이드 애플리케이션 개발자는 자바를 배워야 한다고들 말한다. 하지만 자신이 가진 웹 기술에 조금만 더 보태면 감탄할 만 한 리치 애플리케이션을 만들 수 있다. 예컨대 ‘R그래프‘란 서비스를 보면 HTML5를 기반한 각종 비주얼 차트를 서비스 안에 넣을 수 있다.
그러니 웹 프론트엔드 개발자가 더 많은 생각을 갖고 HTML5를 적용하는 노력을 기울여야 한다. 그게 결국은 자기에게 보답으로 돌아온다. 전세계에 제공되는 범용 웹브라우저 기반으로 웹애플리케이션을 만들면 모든 개발자가 수혜를 받는다. 결국 이게 정석이다.
웹 산업에서 대형 주자가 폐쇄된 개발 환경과 플랫폼에서 비즈니스하는 것은 당연하다. 좋은 이용자경험(UX)을 주는 것은 칭찬할 만 하다. 중요한 것은, 선택 가능하고 범용적인 웹 기반 플랫폼도 제공돼야 한다. 표준은 죽기도 하고 산업에 밀리기도 한다. 100% 올바르지도 않다. 하지만 없는 것 보다는 낫다.
이희욱 | HTML5 확산을 위한 과제가 있다면?
윤석찬 | 국내에서는 일단 HTML5가 대형 포털이 적용할 만큼 매력이 있느냐의 문제가 있다. 국내에서 이용하는 대다수 웹브라우저가 아직 지원하지 않는 부분이 있기 때문이다. 파일럿 서비스나 모바일 웹 서비스를 준비하는 사람은 HTML5를 적용해보면 좋겠다. 아이폰용 웹 페이지를 만들 때 ‘video’나 ‘canvas’ 태그 혹은 오프라인 스토리지 기능을 이용하는 아이디어를 내야 한다. 천편일률적인 모바일 페이지는 식상하다. 기왕이면 모바일 웹페이지를 만들 때 ‘엣지있게’ 만들면 좋잖나.
만약 누군가 ‘canvas’ 태그를 이용해 그림을 그리고 이를 공유하는 서비스를 모바일 웹서비스로 만들었다 치자. 그는 회사에서 인정받는 사람이 될 수 있다. 그런 점들에 개발자가 좀 더 신경쓰면 좋겠다. 스스로 찾고 배워서 도전해 봤으면 한다.
이희욱 | 새롭고 흥미로운 얘기들을 많이 들었다. 아직은 어렵고 낯선 면이 많다. 리치 웹을 플러그인 없이 구현할 수 있는 기술을 내장했다는 얘기가 기억에 오래 남는다. 웹 개발자분들이 좋은 기회로 활용했으면 하는 생각이 든다. 새로운 정보들도 자주 알려주시길 기대한다.
a요소
○ 링크(a 요소)
텍스트에 링크를 설정할 때에 a 요소를 사용하며 지정 가능한 속성은 link 요소와 거의 같다. 단, a 요소는 문서의 본문으로 표시되므로 사용성을 향상 시키려고 tabindex 속성과 accesskey 속성이 추가로 정의된다.
예) <p>자세한 것은<a herf=”링크될 주소”>제2장 컨셉트 워크</a>를 참조</p>
가급적 구체적 의미가 있지 않은 텍스트에 a 요소를 설정하지 않고, 사용자가 쉽게 해당 텍스트에 클릭을 유도할 수 있는 텍스트로 표시하는 것을 권장한다.
○ name 속성과 id 속성으로 프래그먼트 식별자 표시
문서 안의 특정위치를 나타내기 위해 a 요소에 name 속성과 id 속성으로 프래그먼트 식별자를 지정한다.(프래그먼트 식별자란, 문자 그대로 문서 안의 ‘단편’을 의미 또는 ‘앵커’라 한다.)
예1) <h3><a콘텐츠를 생각한다.</a></h3>
위 예제와 같이 name와 id 속성에 같은 값을 설정하기도 하지만, 식별자 부분에 링크를 설정할 때 herf 속성 값을 ‘URI’에 이어 ‘#’과 name 및 id 속성값을 지정한다.
예2) <p>자세한 것은<a herf=”해당 주소#name또는id속성값”>제 2장 3절 ‘콘텐츠를 생각한다.’</a>를 참조</p>
예1)처럼 지정하는 것보다 아래와 같이 h3 요소에 직접 프래그먼트 식별자를 지정하는 편이 좋다.
예3) <h3>콘텐츠를 생각한다.</h3>
id 속성에 지정할 수 있는 프래그먼트 식별자에는 HTML과 XHTML에서 차이가 있다.
| HTML | XHTML | |
| 시작 | 반드시 알파벳(a~z) | 반드시 알파벳(a~z) 또는 밑줄(_)로 시작 |
| 구성 | 숫자(0~9), 하이픈(-), 마침표(.), 밑줄(_), 콜론(;)으로 구성 | 알파벳(a~z), 숫자(0~9), 하이픈(-), 마침표(.), 밑줄(_), 콜론(;)으로 구성 |
| 비고 | 알파벳의 대/소문자를 구별 | 알파벳의 대/소문자를 구별, 대/소문자에 관계없이 ‘xml’로 시작할 수 없다. |
○ a 요소는 a 요소를 포함할 수 없다.
한 개의 블록 레벨 요소 안에 프래그먼트 식별자와 URI를 동시에 지정하는 경우에도 문제가 된다.
나쁜 예) <p><a>자세한 것은<a herf=”주소”>제 2장 3절 ‘콘텐츠를 생각한다.</a>를 참조.</a></p>
좋은 예) <p>자세한 것은<a herf=”주소”>제 2장 3절 ‘콘텐츠를 생각한다.</a>를 참조.</p>
○ tabindex 속성과 accesskey 속성을 키조작에 의한 포커스 이동 방식 제공
tabindex 속성 : 키보드 ‘Tab키’를 눌렀을 때의 포커스 이동순서를 지정한다. 0~32767까지의 값이 지정 가능하다.
accesskey 속성 : 액세스키(키보드 단축키)를 눌렀을 때의 포커스를 지정한다. 알파벳(a~z)과 숫자(0~9)등 임의의 키값을 지정하지만 대/소문자를 구별하지 않는다.
윈도우에서는 ‘alt키’와 ‘임의로 지정한 키’, 맥킨토시에서는 ‘cmd키’와 ‘임의로 지정한 키’를 동시에 눌러 작동한다.
키설정의 예)
<ul>
<li><a herf=”주소” accesskey=”d”>Designing</a></li>
</ul>
○ title 속성에 링크의 보충정보 표시
a 요소에 title 속성을 지정하여 링크의 보충정보를 표시할 수 있다.
○ 메일주소를 URI로 지정하는 경우
a 요소의 herf 속성값에 메일주소를 지정하여 해당 링크 텍스트를 클릭하면 메일 작성 프로그램이 자동 실행된다.
○ a 요소의 미래
XHTML2.0 초안에서는 herf 속성을 다른 요소에도 지정할수 있게 할 예정
| <ul> <li><a herf=”주소”>다음과 같이 바뀐다.</a></li> </ul> |
이러한 표기 법에서
| <ul> <li herf=”주소”>다음과 같이 바뀐다.</li> </ul> |
이와 같이 변경 예정이다… 짧고 간략해진다.
○ 이미지 요소(img 요소)
img 요소는 인라인 요소이지만 빈 요소이므로 </ img>를 사용한다.
img 요소는 src 속성과 alt 속성이 필수이며,
src 속성으로 이미지 파일의 URI를, alt 속성으로 대체 텍스트를 지정한다.
텍스트 브라우저와 음성 브라우저에는 alt 속성값으로 이미지를대체하여 표시/표현한다. 또 alt 속성값을 툴팁으로 표시하는 브라우저도 있다.
예) <p><img src=”링크주소 및 파일명” alt=”설명”></p>
○ alt 속성의 주의점
링크할 사진을 대상으로 alt 속성에는 ‘2001년 여름 오키나와 여행 사진’쯤으로 간략하게 적고 별도의 title 속성에 적당한 자세한 설명이 좋다.
예) <img src=”주소 및 파일명” alt=”2001년 여름 오키나와 여행 사진” title=”여름의 태양이 눈부시고 활짝 핀 꽃이 아름다웠습니다. 호텔에서 본 야경이 지금도 잊혀지지 않습니다.” />
○ longdesc 속성으로 alt 속성 보완
alt 속성과 title 속성으로 길게 설명문을 지정하는 것은 현실적이지 않기 때문에 longdesc 속성으로 자세한 설명이 있는 페이지의 URI를 표시한다.
예) <img src=”주소 및 파일명” alt=”사진의 간략한 설명” longdesc=”사진의 설명 URI” />
○ width 속성과 height 속성으로 이미지의 폭과 높이 지정
img 요소의 폭과 높이는 width와 height 속성으로 지정하며 단위는 ‘픽셀’ 또는 ‘%’이다. 하지만 ‘픽셀’ 지정이 안전하다.
예)<img src=”주소 및 파일명” alt=”파일의 간략한 설명” width=”400″ height=”300″ />
○ 링크를 설정한 이미지의 테두리선 컨트롤
a 요소로 img 요소에 링크를 설정한 경우 많은 브라우저에서 테두리선이 그어진다. img 요소의 테두리선은 CSS의 테두리관련 속성으로 제어한다. 만일 모든 img 요소에 테두리선을 표시하지 않는다면 CSS의 border 속성에 ‘0′으로 지정한다.
예) img{border:0}
○ 이미지의 배치와 여백 지정
img 요소에서 수평위치와 수직위치를 지정하려고 align 속성, 좌우여백을 지정하려고 hspace 속성, 상하 여백을 지정하려고 vspace 속성을 이용하였다. 하지만 이제는 비추천 또는 폐지되어 align 속성은 CSS의 속성으로 사용한다.
| 기존 | 변경 | 현재(CSS) |
| align 속성 | → | vertical-align, float 속성 |
| hspace, vspace 속성 | → | margin 속성 |
○ object 요소에 의한 img 요소 대체
이미지 삽입은 img 요소가 아니라 object 요소로도 가능하며 applet 요소나 iframe 요소의 기능을 포함하는 범용 오브젝트 요소이며, 앞으로 새롭게 개발될 어떤 형식의 데이터라도 문제없이 취급할 수 있다. 하지만 현재 object 요소의 브라우저 지원이 불안정하므로 이미지는 img 요소로 사용하는 것이 좋다.
예) <object data=”주소 및 파일”>XHTML의 구조도</object>
출처 – http://wjtmdxhrl.tistory.com/
HTTP (HyperText Transfer Protocol)
WWW 상에서 정보를 주고 받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고 받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었으며, 현재 가장 널리 쓰이는 버전이 1.1이다.
HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 보여지는 것이다.
HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.
요청 방법
HEAD- GET과 같은 요청이지만, 자료에 대한 정보(meta-information)만을 받는다.
GET- URL에 해당하는 자료의 전송을 요청한다.
POST- 서버가 처리할 수 있는 자료를 보낸다.
PUT- 해당 URL에 자료를 저장한다.
DELETE- 해당 URL의 자료를 삭제한다.
TRACE- 이전에 요청한 내용을 들을 것을 요청한다.
OPTIONS- 어떠한 옵션이 있는지 묻는다.
CONNECT- 프록시가 사용하는 요청.
출처 – 위키백과 ― 우리 모두의 백과사전
월드 와이드 웹 (World Wide Web; WWW; W3)
인터넷에 연결된 컴퓨터들을 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 말한다. 간단히 웹(Web)이라 부르는 경우가 많다. 이 용어는 인터넷과 동의어로 쓰이는 경우가 많으나 엄격히 말해 서로 다른 개념이다. 웹은 전자 메일과 같이 인터넷 상에서 동작하는 하나의 서비스일 뿐이다.
인터넷상의 정보를 하이퍼텍스트 방식과 멀티미디어 환경에서 검색할 수 있게 해주는 정보검색 시스템이다. 하이퍼 텍스트형식으로 표현된 인터넷상의 다양한 정보를 효과적으로 검색하는 시스템으로 전세계적으로 가장 널리 보급되어있다.
기본개념
하이퍼텍스트는 웹 브라우저라 불리는 프로그램을 통해 웹 서버에서 “문서”나 웹 페이지등의 정보 조각을 읽어들여 컴퓨터 모니터에 출력하는 형태로 보이게 된다. 그러고 나서 사용자는 각 페이지에 있는 하이퍼링크를 따라 다른 문서로 이동하거나, 그 페이지를 서비스하고 있는 서버로 일련의 정보를 보낼 수도 있다. 하이퍼링크를 따라 이동하는 행위를 흔히 웹”서핑” 또는 웹”브라우징”이라 한다. 그리고 관련된 내용들이 모여있는 웹 페이지들의 집합을 웹 사이트라 한다.
영어 단어 월드와이드(worldwide)는 보통 공백이나 하이픈 없이 한 단어로 쓰이지만, 월드 와이드 웹(World Wide Web)과 그 약어인 WWW는 공식적인 영어 낱말로 사용되고 있다.
월드 와이드 웹은 다음의 세가지 기능으로 요약할 수 있겠다. 첫번째 통일된 웹 자원의 위치 지정 방법 예를 들면 URL. 두번째 웹의 자원 이름에 접근하는 프로토콜(protocol) 예를 들면 HTTP, 자원들 사이를 쉽게 항해 할 수 있는 언어 예를 들면 HTML
역사
1989년 3월 유럽 입자 물리 연구소(CERN)의 소프트웨어 공학자인 팀 버너스 리의 제안으로 시작되어 연구,개발되었다.
- WWW에 대한 팀 버너스-리의 제안 (1989.3, 1990.5 / CERN )
원래는 세계의 여러 대학과 연구기관에서 일하는 물리학자들 상호간의 신속한 정보교환과 공동연구를 위해 고안되었다. 문자나 사진, 동영상, 음성 등이 조합된 데이터베이스인 사이트의 정보를 전용 열람용 소프트웨어인 웹 브라우저를 통해 입수한다. 또한 입수한 정보를 간단한 방식으로 젅송하는 것도 가능하다.
세계적으로 대중화된 소프트웨어는 일리노이대학교 재학생(마크 안데르센, Netscape의 전신인 Mosaic를 개발)이 작성한 것이다. 사용자들은 인터넷 ‘브라우저’의 도움으로 웹 세계를 떠돌아다닌다. 웹을 통해서 엄청나게 다양한 영역의 자료나 프로그램들, 이를테면 정부 정책 보고서부터 바이러스 박멸 소프트웨어 혹은 컴퓨터 게임에 이르기까지 다운로드할 수 있는 것이다. 웹사이트가 그 정교함을 더해감에 따라, 온갖 취향이나 구미를 만족시키는 향연장이 되었다. 여로 곳에서 종교한 그래프나 사진으로 치장하거나, 혹은 비디오나 오디오 파일을 장착하기도 한다. 웹은 또한 ‘e-상거래’를위한 주요 인터페이스 역할도 하고 있다
관리기관
월드 와이드 웹에 관련된 기술은 월드 와이드 웹 컨소시엄(W3C)이 개발하고 있다. W3C는 HTML, HTTP 등의 표준화를 진행하고 있으며, 최근에는 시맨틱 웹에 관련된 표준을 제정하고 있다.
출처 – 위키백과 ― 우리 모두의 백과사전
정의형 목록
정의형 목록(dl요소, dt요소 dd요소)
용어와 그 설명으로 구성된 목록을 정의형 목록(definition list) 이라고 한다.정의형 목록은 dl요소로 정의 하고 용어를 나타내는 dt(definition term)요소와 그 설명인 dd(definition description)요소를 포함한다. dl요소는 블록 요소이지만 dt요소 와 dd요소 이외의 요소를 포함할 수 없다.
dt요소는 인라인 요소이며 인라인 요소와 텍스트를 포함 할 수 있다. dd요소는 블록 요소 이며 인라인 요소와 텍스트를 포함할 수 있고또 블록 요소를 포함할 수 있다.
ex)
<dl>
<dt>Burma Shave Singns</dt>
<dd>Road sings commom in the U.S. in the 1920s and
1930s advertising shaving product.</dd>
</dl>
Head First HTML with CSS p146
항목 목록과 번호 목록(ul요소, ol요소, li요소)
일반적으로 목록 작성에는 ul요소 비순차적목록 (unordered list) 또는 ol요소 순차적 목록( ordered list)를 사용하여 각 항목은 li요소(list item)으로 정의한다.
ul요소,ol요소 모두 블록 요소이지만 li요소 이외의 요소를 포함시킬 수 없다. li요소는 블록 요소이며 인라인 요소와 텍스트를 포함할 수 있고 또 다른 블록 요소를 포함 할수 있다.
ex)
<p>Well I’ve made it 1200 miles already, and, and I
pressd through some interesting places on the way:
</p>
<ol>
<li>Walla Walla, WA</li>
<li>Magic City, ID</li>
<li>Bonuntiful, UT</li>
</ol>
Head First HTML with CSS p142~143
XML & XHTML
XML (Extensible Markup Language)
XML[엑스 에멜]은 1996년 W3C(World Wide Web Consortium)에서 제안한 것으로서, 웹 상에서 구조화된 문서를 전송 가능하도록 설계된 표준화된 텍스트 형식이다. 이는 인터넷에서 기존에 사용하던 HTML의 한계를 극복하고 SGML의 복잡함을 해결하는 방안으로써 HTML에 사용자가 새로운 태그(tag)를 정의할 수 있는 기능이 추가되었다고 이해하면 쉽다. 또한, XML은 SGML의 실용적인 기능만을 모은 부분집합 (subset)이라 할 수 있으며, 인터넷상에서 뿐만 아니라 전자 출판, 의학, 경영, 법률, 판매 자동화, 디지털도서관, 전자상거래 등 매우 광범위하게 이용될 전망이다.
XML은 월드와이드웹, 인트라넷 등에서 데이터와 포맷 두가지 모두를 공유하려고 할때 유용한 방법이라 할 수 있는데 , W3C의 의장인 Jon Bosak은 XML을 다음과 같이 설명하고 있다.
“향후 XML은 웹 기술상에 있어서 가장 핵심적인 진보를 가져 올 것이며, 웹의 근본을 송두리째 바꿀 것이다. XML은 안전한 전자상거래 구축을 가능하게 하고, 새로운 분산 애플리케이션 (application) 시대를 이끌어 나갈 것이다. 또한 XML은 소프트웨어 개발자와 고객의 관계를 새롭게 변화시킬 것이다. 다시 말해서 XML은 어떤 플랫폼에서나 읽을 수 있는 포맷을 제공하기 때문에 특정 회사의 제품과 관련된 특정 환경에 얽매이지 않아도 된다”
XML은 현재 W3C로부터 웹을 좀더 다양한 목적으로 이용할 수 있도록 하기 위한 도구로서 공식 추천되고 있다.
XHTML (Extensible Hypertext Markup Language)
W3C에서 설명하는 바에 따르면, “XHTML은 XML 응용으로서의 HTML 4를 다시 공식화한 것”이다. 두 가지 용어 모두가 다 생소한 독자를 위해 부연설명을 하면, HTML은 웹상에서 보일 수 있도록 작성자가 문서 내에 집어넣는 일련의 코드 (즉, 마크업 언어)들이며, HTML 4는 그것의 최신 버전이다. XML은 웹상에서 공유될 어떤 종류의 데이터를 정의하는 방법에 관한, 일련의 구조화된 규칙이다. 그것은 누구라도 특정한 목적을 위한 일련의 마크업 세트를 발명할 수 있으므로, “확장될 수 있는” 마크업 언어라고 불리는데, 모든 사람들이 그것을 사용하는 한, XML은 웹페이지의 표현을 묘사하는 것을 포함하여, 여러 가지 목적에 채택되고, 또 사용될 수 있다. 그러한 경우로, XML의 형태로 HTML을 다시 구성하는 것이 바람직하게 보였다. 그 결과가 바로, 웹페이지를 표현하기 위한 XML의 특별한 응용인 XHTML인 것이다.
XHTML은 실제로, HTML 4의 후속 버전이다. 비록 이것이 XHTML 1.0으로 불리지만, HTML 5라고 생각해도 좋을 것이다. XHTML에서는, 모든 HTML 4 마크업 태그들과 속성들이 계속 지원될 것이다. 그러나, HTML과는 달리, XHTML은 그것을 사용하는 누구에 의해서라도 확장하는 것이 가능하다. 이미 존재하는 것에 새로운 태그와 속성들이 정의되고, 추가될 수 있으며, 웹페이지 내에 콘텐츠와 프로그램을 삽입하기 위한 새로운 방법을 만드는 것도 가능하다. 외관상으로는, XHTML 파일이 다소 더 정교한 HTML 파일처럼 보인다.
장 점
W3C의 얘기를 다시 인용하면, 장점은 “확장성과 이식성”이다. 확장성이란, 웹 전달과 표현에 관한 새로운 아이디어가 생기면, 다음 버전의 HTML이나 브라우저의 지원을 기다리지 않고서도 즉시 구현할 수 있게된다. 새로운 태그들이나 속성들이 새로운 가능성들을 표현하기 위해 정의될 수 있으며, 수신 측의 일부 프로그램이 그것을 이해할 수 있고 그것들 상에서 동작할 수 있다고 가정하면, 이전에는 절대로 일어나지 않았던 웹페이지 상에 새로운 것들이 일어날 수도 있다. XHTML에 관한 특이한 확장 판들로는, 수학적인 표현, 벡터그래픽, 그리고 멀티미디어 애플리케이션 등이 예정되어 있다.
만약 확장성이 보다 복잡한 페이지와 더 큰 프로그램으로 가게 될 것 같으면, 웹페이지들이 이전에 비해 더 간단하게 만들어짐으로써 소형장치들이 그것을 처리할 수 있도록 하기 위한, 이식성에 관한 장점이 중요성을 갖는다. 이것은 이동형 장비와, 마이크로프로세서, 프로그램 및 소형 메모리가 내장된 가정용 제품들 들에서는 중요하다. XHTML은 마크업 복잡도에 몇 개의 수준을 정의하며, 각 문서의 시작부분에는 복잡도 수준을 나타낸다. 소형 장치들 내의 프로그램은 소형 프로그램과 메모리로도 처리할 수 있도록, 복잡도가 가장 낮은 수준으로 기술된 XHTML 파일들을 기대할 수 있다.
차이점과 특색
규격과 지침서를 읽으면 더 많은 내용을 알 수 있겠지만, 여기에서는 XHTML의 일부 특색과, HTML 4와의 차이점만을 기술한다.
•XHTML은 코딩 규칙을 엄격하게 준수할 것을 요구한다. 특히, 그 중에서도, 태그를 열었으면, 닫는 태그도 반드시 사용해야하고, 모든 태그들은 소문자로 기술되어야한다. HTML은 표기에 관한 한 훨씬 덜 엄격했으며, 브라우저들은 이에 관해 더욱 관대한 경향이 있었다.
•이것은 XHTML 파일이 HTML 보다 분주해지는 경향이 있을 거라는 것을 의미한다. 그러나, 그들은 코딩에 있어 더 많은 정돈을 엄격히 요구하므로 읽기에 반드시 어렵지만은 않을 것이다. 추가로, 주요 편집 및 파일 작성도구들은 아마도 읽기 쉽도록 페이지를 배치할 것이다.
•XHTML은 콘텐츠와 스타일시트와의 결합에 관한 생각을 보다 구조적이고 개념적인 방법으로 그리고 그것을 표현하는 보다 창조적인 방법 등을 장려하는 듯하다.
•XHTML은 문득 새로운 태그들을 생각해내고 추가하는 사람들, 그리고 브라우저나, 그것을 지원하는 다른 애플리케이션들을 개발하는 사람들을 위한 쉬운 방법을 제공할 것이다.
첫 번째 XHTML 규격은 현재 W3C의 실무초안 단계에 있다.
WML (Wireless Markup Language)
이전에는 HDML이라고 불렸었던 WML은, 무선 접속을 통하여 셀룰러폰이나 PDA 등에 웹페이지의 텍스트 부분이 표시될 수 있도록 해주는 언어이다. WML은 몇몇 공급회사들에 의해 표준안으로 제안되고 있는 WAP의 일부이다. WAP은 GSM, CDMA, TDMA 등과 같은 표준 데이터 링크 프로토콜의 윗면에서 동작하며, 일련의 인터넷 프로토콜들에 필적하면서, 서로 협력하는 한 벌의 완전한 네트웍 통신 프로그램들을 제공한다.
WML은 사용시 로열티를 내지 않아도 되는 개방형 언어이다. Phone.com의 웹사이트에서 WML 규격을 이용할 수 있다. Phone.com에 따르면, HTML, CGI 스크립트, 그리고 SQL 질의문 등에 지식을 가지고 있는 프로그래머라면 누구라도 WML을 사용한 표현 계층을 작성할 수 있을 것이라고 한다. 또한, HTML 페이지를 WML 페이지로 변환시켜주는 필터 프로그램을 직접 작성하거나 또는 공급회사로부터 구입하는 것도 가능하다.
1. HTML 알아보기 (HyperText Markup Language)
1. 웹 언어 (p39~P80)
사용자 컴퓨터 >>>>>>> 웹서버 <<<<<<<<<< HTML
1) 웹 서버
-인터넷에서 웹 브라우저의 요청을 기다리며 24시간 내내 쉬지 않고 작동
사용자 컴퓨터 >> 필요 >>>웹 서버 (각 서버는 HTML파일이나 그림, 음악 다른 종류 파일을 저장)
사용자 컴퓨터 <<< 제공 << 웹 서버
2) 웹 브라우저
(1) 웹 서핑을 하면서 특정 페이지를 클릭해 방문
(2) 웹 서버에 해당 HTML페이지를 요청
(3) 응답 브라우저 화면에 페이지를 보여줌
웹서버(+HTML들..) >> 사용자 컴퓨터 (회수한 페이지를 브라우저가 보여준다)
* 브라우저가 만들어 내는 것들
- 브라우저는 작성한 HTML을 읽으면서 텍스트 주위에 있는 모든 태그들을 해석
태그란 <>사이에 오는 단어나 문자
* Q & A (P44)
- Hyper Text (Link)
문서내에 어떤 위치에서 같은 문서나 다른문서의 특정부분을 지정하면 링크를 통해 연결된 데이터에 접근
* HTML 공백
HTML 문서에 있는 탭, 리턴 대부분의 공백들을 무시한다.
* 제목 (heading)에 <h1>과<h2>
<h1>~<h6> 브라우저는 연속적으로 좀더 작은 글자크기로 보여준다.
* 주석
<!–여기서 부터 라운지의 내용이 시작됩니다–!>
<HTML> 작성하기
Lounge
join us any evening for refreshing elixirs,
conversation and maybe a game or two of Dance Dance Dance.
Directions
You’ll find us right in the center of downtown Webville. Come Join us!
—————————————————————————–
<html>
<head>
<title>Lounge</title>
</head>
<body>
<h2>Lounge</h2>
<p>join us any evening for refreshing elixirs,
conversation and maybe a game or two of <em>Dance Dance Dance</em>.</p>
<h2>Directions</h2>
<p>You’ll find us right in the center of downtown Webville. Come Join us!</p>
</body>
</html>
—————————————————————————————
4) 태그 해부
<h1>Starbuzz Coffee Beverages</h1>
- <h1> – 시작태그
-</h1> -종료태그
- <h1>Starbuzz Coffee Beverages</h1> – 엘리먼트 (element) 이 경우에는 h1의 엘리먼트라고 부를수 있다
엘리먼트는 닫혀진 (enclosing) 태그들과 그사이에 있는 콘텐츠로 구성됩니다.
시작태그와 종료태그를 매칭태그라 한다.
* 엘리먼트 = 시작9opening)태그 + 콘텐츠(내용) + 종료(closing)
!! 시작태그와 종료태그는 항상 일치 시키자!!
* Q & A (p64)
질문!!
<p id = “houseblend”> 내용 </p>의 의미?
<p id = “houseblend”> 의 id 는 문단의 이름을 지정하는 것으로 특정한 스타일을 이문단만
지정할 수 있는데 그때 id를 지정해주면 이 문단만 스타일을 다르게 지정할 수 있다.
* HTML 과 CSS는 완전히 다른언어 (p70)
- # d2b48c – hex 코드
- CSS 규칙앞에 Body가 있는 이유
{“와”} 사이에 있는 모든 CSS 규칙을 HTML <body> 앨리먼트 안에 있는 콘텐츠에 적용 한다는 의미
* 핵심정리 p74
- CSS (Cascading style sheet) 는 HTML의 프레젠테이션을 제어
- <style> 앨리먼트는 항상 <head> 엘리먼트 내부에 위치
