화끈하고도 딱딱한 주제가 ‘블로터 포럼’ 대문에 걸렸습니다. ‘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닥터 웹사이트에서 다양한 예제를 살펴보고, 가능한 것부터 해보는 것이 좋겠다.

이희욱 | 그럼 XHTML은 더 이상 개발 되지 않는 것인가?

윤석찬 | 그렇지 않다. 물론 XHTML 2.0 표준 개발은 완전히 멈췄다. 지난해에 그룹이 해체됐다. 하지만 XHTML의 유용성은 그대로 있기에, HTML5 문서를 XHTML로도 표현할 수 있고 이를 위한 독타입을 선언하면 그대로 XHTML 문서로 유효하다. 이를 ‘XHTML5′라고 부른다. XHTML은 여전히 HTML5 안에서 유효하다.

주민영 | HTML5가 산업에 미치는 영향은 어떨 것으로 예상하나?

윤석찬 | 가장 큰 수혜자는 기존 웹 개발자다. 요즘 모바일 애플리케이션 개발자는 중고 매킨토시를 산 뒤 코코아 개발환경을 익혀 앱스토어에 애플리케이션을 올리고, 안드로이드 애플리케이션 개발자는 자바를 배워야 한다고들 말한다. 하지만 자신이 가진 웹 기술에 조금만 더 보태면 감탄할 만 한 리치 애플리케이션을 만들 수 있다. 예컨대 ‘R그래프‘란 서비스를 보면 HTML5를 기반한 각종 비주얼 차트를 서비스 안에 넣을 수 있다.

그러니 웹 프론트엔드 개발자가 더 많은 생각을 갖고 HTML5를 적용하는 노력을 기울여야 한다. 그게 결국은 자기에게 보답으로 돌아온다. 전세계에 제공되는 범용 웹브라우저 기반으로 웹애플리케이션을 만들면 모든 개발자가 수혜를 받는다. 결국 이게 정석이다.

웹 산업에서 대형 주자가 폐쇄된 개발 환경과 플랫폼에서 비즈니스하는 것은 당연하다. 좋은 이용자경험(UX)을 주는 것은 칭찬할 만 하다. 중요한 것은, 선택 가능하고 범용적인 웹 기반 플랫폼도 제공돼야 한다. 표준은 죽기도 하고 산업에 밀리기도 한다. 100% 올바르지도 않다. 하지만 없는 것 보다는 낫다.

이희욱 | HTML5 확산을 위한 과제가 있다면?

윤석찬 | 국내에서는 일단 HTML5가 대형 포털이 적용할 만큼 매력이 있느냐의 문제가 있다. 국내에서 이용하는 대다수 웹브라우저가 아직 지원하지 않는 부분이 있기 때문이다. 파일럿 서비스나 모바일 웹 서비스를 준비하는 사람은 HTML5를 적용해보면 좋겠다. 아이폰용 웹 페이지를 만들 때 ‘video’나 ‘canvas’ 태그 혹은 오프라인 스토리지 기능을 이용하는 아이디어를 내야 한다. 천편일률적인 모바일 페이지는 식상하다. 기왕이면 모바일 웹페이지를 만들 때 ‘엣지있게’ 만들면 좋잖나.

만약 누군가 ‘canvas’ 태그를 이용해 그림을 그리고 이를 공유하는 서비스를 모바일 웹서비스로 만들었다 치자. 그는 회사에서 인정받는 사람이 될 수 있다. 그런 점들에 개발자가 좀 더 신경쓰면 좋겠다. 스스로 찾고 배워서 도전해 봤으면 한다.

이희욱 | 새롭고 흥미로운 얘기들을 많이 들었다. 아직은 어렵고 낯선 면이 많다. 리치 웹을 플러그인 없이 구현할 수 있는 기술을 내장했다는 얘기가 기억에 오래 남는다. 웹 개발자분들이 좋은 기회로 활용했으면 하는 생각이 든다. 새로운 정보들도 자주 알려주시길 기대한다.


♣ 자료출처 : 블로터포럼


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret
새로 발표된「파이어폭스 2」브라우저에 크래쉬를 일으킬 수 있는 두 번째 시큐리티 취약성이 발견되었다. 이 취약성은 오픈 소스 브라우저인 파이어폭스 2가 자바스크립트 코드를 처리하는 것과 관계가 있다.

제공업체인 모질라의 관계자는 1일(미국 시간), 이 취약성으로 인해 악용된 웹페이지를 열람하게 되면 브라우저가 강제 종료된다고 설명했다. 그는 무엇보다 시큐리티 메일링 리스트 등에서 지적한 내용과는 반대로, 이 버그가 파이어폭스 2로 가동되는 PC상에서 임의의 코드를 실행하는데에 악용될 가능성은 없다고 말했다.

이 취약성은「자바스크립트 레인지」라 불리는 오브젝트에 존재하는데 모질라가 지난 주에 인정한 파이어폭스 2의 서비스 거부(DoS) 취약성과는 다르다. 모질라에 의하면, 그보다 더 심각하고 파이어폭스의 이전 버전에서 수정되었던 취약성과 관계가 있다고 한다.

파이어폭스 2가 발표된 지 일주일 정도가 지났지만 일반에게 공개되고 모질라도 인정한 취약성은 이 둘 뿐이다. 모질라는 이에 대해 모두 경미한 문제라고 말했다.

한편, MS의 새로운 브라우저「IE 7」은 지난달 18일(미국 시간)의 발표가 있은 지 불과 일주일 만에 위장 주소와 관련된 취약성이 발견되었다. MS는 IE 7을 피싱 사기에 대항할 수 있는 브라우저로서 디자인했는데, 이 취약성은 피싱 사기를 숨기려는 범죄자에게 악용될 우려가 있다.

시큐리티 감시기업인 시큐니어에 의하면, IE 7에 적어도 2건의 취약성이 더 존재한다고 했다. MS는 이에 반론을 제기해, 보도된 문제 중 하나는 IE 7이 아닌 아웃룩 익스프레스와 관련된 것이고 또 다른 문제는 제품 사양의 문제이지 취약성은 아니라고 강조했다.

인기가 높은 웹 브라우저의 새로운 버전이 연이어 발표됨에 따라 버그 헌터들은 그 프로그램들에서 최초로 시큐리티 결함을 찾아내려 하고 있다.

현재까지는 그렇게 발견된 취약성이 이 브라우저로 가동되고 있는 PC를 탈취하는데에 악용된 사례는 없었다. 아마도 이러한 공격을 유도하는 취약성이 가장 위험할 것이다. @


♣자료출처: CNET News.com

WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Mozilla Firefox 1.5

Daily/Prog 2006. 7. 23. 19:25


스크립트의 호환 여부를 체크하기 위해
브라우저를 하나 더 설치하라는 싸부님 말씀.

어짜피 부장님 컴퓨터에 파이어폭스 설치되어 있어서
최대한 버텨보려 했건만;

넷스케이프8.1과 파이어폭스1.5를 두고,
갈등, 고민 완전 하다가
강력한 넷스케이프보다는 가벼운 파이어폭스를 추천받아

파이어폭스 즉시 설치.

아직 많은 테스트를 해보진 못했지만
Formatted Source / Dom Inspector 원츄~

WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  1개가 달렸습니다.
  1. 자바스크립트 콘솔 원츄-
secret

웹사이트 구축시 CSS를 사용하면 HTML에 들어있는 반복되는 형식 코드를 CSS 스타일 시트에 통합함으로써 HTML 자체에서 제거할 수 있기 때문에 시간과 노력을 줄일 수 있다. 또한 스타일을 사용함으로써 다중 텍스트 블록의 형식을 만들고 레이아웃을 제어함으로써 여러 페이지의 형식을 만들어낼 수 있다.

여기에 재사용할 수 있는 형식을 한 곳에 보관할 수 있기 때문에 개발 시간도 단축할 수 있다. 특히 웹사이트를 편집하거나 계속 업데이트해야 할 경우 더욱 효과가 크다.

반면 CSS는 스타일 시트에 스타일을 추가하면서 파일이 금방 엉망이 될 수 있다는 것이 단점이다. CSS에는 HTML 태그 속성을 재정의하는 스타일과 다양한 텍스트 블록의 형식을 정의하는 클래스와 id 셀렉터, 페이지 레이아웃을 위한 스타일 등이 포함되며 몇몇 스타일들은 전체 웹사이트에 적용되기도 하며 다른 것들은 개별 페이지에 적용되기도 한다.

또한 브라우저간 호환성 문제를 해결하기 위해 임시 변통책을 사용해야 하는 경우도 있다. 스타일 시트에 포함되는 모든 것들을 고려해볼 때 CSS 스타일 시트를 관리하는 일관된 계획이 없다면 통제권이 순식간에 사라져 버릴 것이라는 사실은 명약관화하다.

CSS 스타일의 조직화

CSS 개발을 해본 적이 없는 많은 웹 개발자들이 흔히 하는 실수는 단일 CSS 파일에 웹사이트 전체 스타일을 구겨 넣는 것이다. 이러한 방식은 몇 개 페이지로 구성돼 있으며 특정 스타일을 가진 아주 작은 웹사이트라면 괜찮게 적용될지도 모른다. 그러나 일반적인 다른 웹사이트들은 여러 개의 CSS 파일을 쓰는 게 낫다.

예를 들면 사이트 전체에 적용되는 단일 CSS 파일을 먼저 개발하고 서로 구분지을 수 있는 웹페이지들의 집합 각각에 대해 별도의 CSS 파일을 두는 방법이 있을 수 있다. 즉 특정 부서를 위한 스타일이나 다른 레이아웃 스타일을 지닌 페이지가 있을 수 있다는 것이다.

그리고 고유한 스타일을 필요로 하는 특정 페이지에 대해서는 각 페이지마다 별도의 CSS 파일을 둔다. HTML 헤더에 넣기에 스타일이 너무 많을 경우다. 또한 적당한 CSS 파일을 각 페이지에 연결하거나 가져오게 할 수 있다. 그렇게 되면 페이지를 표시하는데 필요한 스타일을 모두 적재할 수 있으며 다른 페이지에서만 나타나는 불필요한 것들은 적재되지 않는다.

CSS 스타일 시트를 조직화하는 데 있어 본인이 애용하는 기법은 스타일 시트 파일을 섹션으로 분리하는 것이다.

예를 들어 메인 스타일 시트에서 첫번째 섹션에는 사이트의 전체 애플리케이션에 폭넓게 적용되는 스타일을 둔다. 즉 HTML 태그의 속성을 재정의하는, 가장 빈번한 스타일이 위치하게 된다. 다른 섹션에는 네비게이션 바나 각주와 같은 보편적인 페이지 요소의 형식을 정의하는 데 필요한 스타일을 담는다.

또 다른 섹션에는 사이트 전체에 걸친 페이지 레이아웃을 통제하는 스타일을 담는다. 나머지 섹션들은 점점 더 범위를 좁혀 스타일을 집합시킨 것들을 담는다.

특정 사이트에서 모든 사이트 전반에 적용되는 스타일은 단일 CSS 파일로 만들 수 있으며 각 섹션은 코멘트로 구분된다. 그러나 보다 복잡한 사이트의 경우라면 각 섹션을 별도 파일로 만드는 게 좋다. 많은 웹 개발자들은 페이지 레이아웃을 위한 스타일을 별도로 두고 텍스트나 다른 요소를 정의하기 위한 스타일을 다른 CSS 파일에 두기를 좋아한다.

‘클래스 남용’은 피해라

웹 개발자들을 괴롭히는 또다른 문제 중 흔해빠진 것으로는 클래스와 ID의 남용을 들 수 있다. 클래스와 ID를 마크업에 추가하고 CSS 스타일을 정의해 요소들의 형식을 만드는 것은 CSS의 사용방식에 있어서 기초가 된다.

그러나 형식을 정의하고 싶은 모든 것에 대해 자동으로 클래스를 정의하려고 마음먹기는 상당히 쉽다. 하지만 실질적으로 HTML 태그의 속성을 재정의하는 것이 대상 요소의 속성을 나타내는 새로운 클래스를 정의해 계속 적용하는 것보다 훨씬 효율적이다.

스타일 시트에서 필요한 클래스 스타일의 갯수를 줄이는 또 다른 방식은 이미 존재하는 두개의 스타일을 단순히 결합하는 것보다 동일 페이지 요소에 여러 개 스타일을 적용하는 것이다.

최선을 다해 코드를 작성하고 나머지는 테스트에 맡겨라

믿거나 말거나’일지도 모르지만 사실 개발 기간 중에 웹페이지를 보는 데 사용하는 브라우저가 CSS 스타일 시트 개발에 큰 영향을 준다.

엄청난 시장 점유율 때문일지 몰라도 많은 웹 개발자들이 인터넷 익스플로러를 주요 웹브라우저로 사용하고 잇다. 이들은 대다수 방문객들이 사용하는 브라우저에서 보기 좋도록 사이트를 먼저 개발하고 다른 브라우저가 해당 사이트를 표시하는 방식에 따라 적당히 조절해나간다. 분명 논리적인 접근법으로 보인다.

하지만 문제는 인터넷 익스플로러가 웹브라우저 중 가장 표준을 따르지 않는다는 것이다. 따라서 IE를 사용하는 웹 개발자가 작성하고 있는 코드에는 인터넷 익스플로러의 수많은 특이점들이 불가피하게 탑재되는 경우가 발생한다. 따라서 보다 표준에 부합하는 브라우저에서 코드를 동작시키려면 상당부분을 다시 써야 한다.

다행히도 인터넷 익스플로러가 가진 문제는 웹사이트들이 전반적으로 표준에 부합하는 추세로 나아감에 따라 결국 없어질 것이다. 미래를 염두에 둔다면 표준에 맞춰 코드를 개발하는 것이 나으며 현재 최적화되지 않은 브라우저에서도 사이트가 동작하도록 필요한 임시조치를 취하는 것이 좋다.

표준에 부합하는 코드를 구형 웹브라우저에서 동작시키는 브라우저 해킹 방법은 여러 곳에 잘 기록돼 있다. 이 해킹 방법을 추가하고 나중에 지우는 것이 특정 브라우저의 특이점들을 제거하기 위해 코드를 재작성하는 것보다는 낫다.

목적이 표준에 부합하는 코드 개발이라면 가장 표준에 부합하는 웹브라우저를 사용해 HTML 페이지를 보는 게 낫다. 현재 가장 적합한 웹브라우저는 모질라의 파이어폭스다. 파이어폭스에서 원하는 효과를 얻은 후 다른 웹브라우저에서 그 페이지를 테스트하고 웹브라우저 호환성 문제를 해결하기 위해 해킹을 추가하거나 코드를 변경하는 절차를 시작하라.

파이어폭스 웹브라우저의 또 다른 장점은 웹 개발자를 위한 툴바 확장이 제공된다는 것이다.

위의 권고를 따른다 해도 인터넷 익스플로러로 웹사이트를 보면서 많은 시간을 보낼 수 있다. 하지만 다른 웹브라우저에서 개발 결과물을 먼저 본다면 결과적으로 코드가 더 깨끗해질 것이라는 점은 확실한 사실이다.


♣ 자료출처 : http://www.zdnet.co.kr


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret