본문으로 바로 이동 페이지 설정으로 이동 메뉴로 이동
페이지 설정
  • 어떠한 의견도 좋습니다. 웨버스터디가 더 나은 모습이 되도록 의견을 보내주세요.

크로스 브라우징

최초 작성일
최종 수정일
이번 시간에는...
크로스 브라이징(Cross Browse)에 대해 다룹니다. 이를 위해 웹킷, 블링크, 게코, 트라이던트 같은 레이아웃 엔진에 대해 살펴보고, 보다 쉬운 작업을 위한 CSS 초기화는 어떻게 하는지, 또 IE는 어떻게 대처해야하는 지 알아 봅니다.

여러분들의 웹 페이지를 만들고 나면, 그 웹 페이지가 모든 브라우저에서 깨지지 않고 의도한 대로 올바르게 나오길 원합니다. 이런 작업을 '크로스 브라우징'이라고 합니다. 이번 시간에는 이 '크로스 브라우징'에 대해 다루도록 하겠습니다.

웹 표준의 준수

전에 웹 표준에 대한 강의에서 말씀 드렸듯이 기본적으로 표준을 준수해야, 브라우저간 차이를 줄이고 무엇이 문제인지 찾아내기 쉽습니다.

또한 최신의 브라우저들은 표준을 잘 준수하고 있기 때문에, 표준을 준수하는 마크 업과 CSS 속성을 사용하면, 거의 동일하게 나오게 됩니다.

하지만, 그럼에도 브라우저간 약간의 차이가 있고, 때로는 버그를 가지고 있습니다. 보통 이러한 차이는 브라우저의 엔진에 따라 어느 정도 분류가 가능합니다.

브라우저의 엔진

브라우저의 엔진이라는 것을 처음 들어보시는 분들도 많으실 것입니다. 하지만 사실 브라우저를 실질적으로 랜더링해주는 것이 바로 이 '레이아웃 엔진'이기 때문에, (Layout engine, 또는 랜더링 엔진이라고 합니다.) 다른 브라우저라도 같은 엔진을 사용한다면 거의 비슷하게 보여줍니다.

이 '엔진'을 스마트폰에 비유를 해보자면, 이 엔진은 안드로이드나 iOS같은 운영체제(OS)로 볼 수 있습니다. 아이폰과 안드로이드폰은 서로 전혀 다른 운영체제를 가지고 있습니다. 하지만 삼성이나 LG, HTC 등의 안드로이드 스마트폰은 같은 운영체제를 가지고 있으며, 각 제조사마다 약간의 기능이나 디자인에 차이를 두고 있습니다.

엔진도 이와 같이 각각의 브라우저가 같은 엔진을 사용한다면, 둘의 페이지 출력방식은 거의 비슷합니다. 그렇기 때문에, 크로스 브라우징의 가장 먼저는 각 브라우저들을 엔진 별로 확인하는 것이 중요합니다. 또한 나중에 CSS3를 사용하게 될 때에도 아직 정착되지 않은 기술들은 엔진 별로 작성을 하기 때문에, 크로스 브라우징을 위해서 엔진을 알아놓는 것은 매우 중요합니다.

엔진의 종류

트라이던트 (Trident)

이 엔진은 마이크로소프트의 레이아웃 엔진입니다. 마이크로소프트의 엔진답게 IE가 사용하는 엔진입니다. IE는 버전 별로도 랜더링 되는 모습이 상이해서 웹을 제작하는 하는 분들에게 언제나 많은 고뇌를 가져다 주곤 했습니다. 하지만 8버전부터는 그래도 표준을 많이 준수하기 시작해서, 지금 최신 버전의 IE는 다른 브라우저들과 거의 비슷한 모습을 보여주고 있습니다.

이 트라이던트 엔진은 IE 뿐 아니라, 아웃룩 같은 마이크로소프트의 이메일 클라이언트도 사용하고 있으며, 종종 윈도우 프로그램들의 미니 브라우저들도 주로 이 엔진을 많이 사용합니다.

게코(Gecko)

이 엔진은 모질라 재단의 레이아웃 엔진입니다. 역시 모질라 재단의 엔진이기 때문에 파어어폭스가 사용하는 엔진입니다. 이 엔진은 파이어폭스 뿐 아니라 모질라 재단의 이메일 클라이언트인 선더버드 역시 이 엔진을 사용합니다.

웹킷(Webkit)

이 웹킷 엔진은 초기에 애플사가 사파리 브라우저의 엔진으로 사용하기 위해 차용한 엔진입니다.

이 엔진은 초기에는 애플사가 개발했으나, 지금은 웹킷 프로젝트로 분리하여 개발하고 있습니다.

이 엔진은 사파리뿐 아니라 크롬에서도 사용되었던 엔진입니다. 또한 iOS나 안드로이드의 기본 브라우저들이 이 웹킷 엔진을 사용하고 있기 때문에, 사실상 점유율이 매우 높은 엔진이라고 할 수 있겠습니다.

프레스토(Presto)

이 엔진은 오페라 소프트웨어의 엔진입니다. 그렇기 때문에 오페라 브라우저가 사용하던 엔진입니다. 하지만 오페라는 15버전부터 이 엔진을 더 이상 사용하지 않기로 했기 때문에, 이제는 더 이상 사용하지 않게 될 엔진이라 보시면 됩니다.

블링크(Blink)

원래는 웹킷 엔진을 사용하던 구글 크롬이 개발의 문제에 따라, 애플이 주도하고 있는 웹킷보다 구글 스스로가 주도적으로 이끄는 엔진으로 개발된 엔진입니다.

하지만 이 블링크 엔진은 웹킷에서 줄기를 가져 나왔기 때문에, 아직까지는 웹킷엔진과 거의 비슷한 모습을 보여줍니다.

또한 이제 프레스토 엔진을 버린 오페라가 이 블링크 엔진을 사용하고 있습니다.

듀얼 엔진

웹 브라우저 중에 맥스톤(Maxthon)이나 국내 이스트소프트의 스윙(Swing)같은 브라우저를 보면, 크롬 같으면서도 액티브X를 지원합니다. 이런 브라우저들은 독자적인 엔진이 있는 것은 아니고, 두 가지 엔진을 번갈아 사용하는 방식입니다.

이런 종류의 브라우저들은 보통 트라이던트와 웹킷(또는 블링크)엔진을 사용합니다. 브라우저의 메뉴를 보면 이름은 조금 다르지만 '고속모드'와 '호환모드'를 가지고 있습니다. 여기서 '고속모드'를 사용할 경우 웹킷(또는 블링크) 엔진으로 페이지를 보여주게 되며, '호환모드'를 사용할 경우 트라이던트 엔진으로 보여주는 것입니다.

레이아웃 엔진을 보트로 비유한 그림
브라우저의 엔진 도표

브라우저의 기본 스타일

우리가 CSS없이 HTML 파일만 웹 브라우저로 볼 경우, h1 요소를 보면 글씨 크기가 일반 글씨보다 배로 커 보이고, p 요소를 보면 위 아래로 간격이 있습니다.

사실 이러한 형태가 보여지는 이유는 브라우저가 자체적으로 CSS 스타일을 가지고 있기 때문입니다. 다시 말해 p 요소 같은 경우에 브라우저가 자체적인 CSS로 'margin: 1em 0;'과 같은 스타일을 주는 것 입니다.

또한 이 파일을 만약 각 브라우저에서 열어보신다면, 보여주는 게 비슷하지만 크기나 간격 등이 조금 다르다는 것을 알 수 있습니다. 사실 각 요소가 가지는 기본적인 스타일 역시 표준으로 제정되어있긴 합니다만, 브라우저마다 (특히 엔진마다) 조금씩 차이가 나는 게 사실입니다.

CSS 초기화

하지만 이런 차이점을 보다 편하게 작업하기 위해서 차이나는 부분들에 미리 스타일을 주는 방법이 있습니다. 이러한 방법을 'CSS 초기화'라고 보통 부릅니다.

보통 CSS 작업을 하면서 브라우저에서 기본적으로 들어간 여백(margin, padding) 때문에, 종종 혼동을 가져오기도 합니다. 그래서 보통 모든 요소들의 여백을 0으로 만들어 놓고 작업을 합니다. 다음과 같은 CSS를 넣는 것입니다.

우리가 아직 배우지 않은 선택자가 등장하는데요, 바로 '*'입니다. 이 선택자는 모든 요소를 선택하는 선택자입니다. 하지만, 이 '*'로 선택을 하게 되면, 브라우저가 랜더링 하는데 (미미하지만) 속도 저하가 올 수 있다 하여 일일이 요소에 스타일을 주기도 합니다. 다음과 같은 방식입니다.

주요한 요소들을 선택해서 여백을 없애는 방법입니다. 이 외에도 ul, ol 같은 리스트 요소에서 list-style 같은 속성은 거의 쓸 일이 없기 때문에, 다음과 같은 코드도 많이 넣는 코드입니다.

그리고 IE 같은 경우 img 요소의 기본적으로 border가 들어가는 경우가 있는데, img 요소에 border를 쓸 일도 거의 없으므로, img 요소에 'border:none;'을 주기도 합니다.

그리고 전체를 거의 감싸는 body요소에 글씨 색상이나 기본적인 크기, 글꼴 등을 넣어주는 식입니다. 그 외에 a요소에 색상을 부여하는 것도 많이 넣는 코드입니다.

이 CSS 초기화에는 정답이 없습니다. CSS를 코딩 하는 사람의 스타일이나 웹 페이지의 특성 등에 따라 넣으시면 됩니다. 이 초기화 CSS는 검색엔진을 통해 조금만 검색해봐도 예시가 많이 나오니, 그 예시들을 복사해서 사용하셔도 됩니다.

CSS 초기화에서 권하지 않는 것

이 부분은 제가 실무를 하면서 경험했던 점들을 토대로 말씀 드리는 것입니다. 이 부분은 그냥 참고만 하시고, 본인이 직접 경험하면서 깨닫기 바랍니다.

초기화에 너무 많은 스타일을 넣지 말 것

이 부분은 특히 사이트가 커지면 커질 수록 느끼는 문제점입니다. 초기화하는 부분에 더 편하게 작업하기 위해서 스타일을 많이 넣다 보면, 이렇게 넣어버린 스타일 때문에 일이 더 불편하게 되는 경우가 있을 수 있습니다. 보통 더 편한 작업을 위해서 사이트의 임의의 스타일을 주기도 하는데요. 문제는 초기화 CSS는 나중에 수정하기가 매우 힘들어 집니다. 이게 사이트의 페이지가 많으면 많아질 수록 더욱 심해지는데, 거의 모든 페이지와 요소가 영향을 받기 때문에, 나중에 초기화 CSS를 잘못 고쳤다가는 예상할 수 없는 수 많은 깨짐을 경험하게 됩니다.

특히, 대형 사이트에서는 주로 개편이 부분부분 일어나게 되는데요, 개편이 되더라도, 개편이 아직 안된 페이지들(잘못된 초기화 CSS를 그대로 사용하고 있는 페이지)로 인해 잘못된 초기화 CSS를 또 다시 계속 써야만 하는 상황이 올 수 있습니다.

때문에, 제 개인적인 생각으로 초기화는 정말 최소한의 스타일만 주는 것이 좋습니다. 저는 심지어 아예 초기화가 아예 없어도 상관 없다는 생각도 드는데요. 아무래도 그럼 굳이 한 번만 줄 속성을 여러 번 줘야 하는 상황이 있을 수 있으니, 여백 정도의 최소한만 주는 것이 좋지 않을 까 합니다. 그리고 만약 처음 공부하는 입장이라면, 한번 초기화 없이 CSS를 작성해서 크로스 브라우징 해보는 것도 좋은 방법이라고 생각합니다.

속성의 상속을 무시하게 만들지 말 것

보통 초기화 중에 제가 가장 싫어하는 것은 모든 요소에 font-size 속성을 주는 것 입니다. 많은 사이트들을 보면, 은근히 모든 요소에 font-size를 주는 경우가 많이 있습니다. 예를 들면 다음과 같이 주는 것입니다.

여기서 선택자를 간략하게 표시하기 위해서 '*'을 사용했지만, 개별 요소를 나열해서 하는 것도 동일합니다.

이렇게 글씨 크기를 모든 요소에 정해주면, h1~h6 요소를 포함해서 모든 요소의 글씨 크기가 12px이 됩니다. 이게 매우 깔끔하게 초기화 되어 보입니다.

하지만, 이렇게 작성할 경우, 속성의 상속이 이뤄지지 않습니다. 예를 들어 다음은 p 요소에 strong 요소가 들어가 있는 경우입니다.

여기서 위의 초기화 스타일을 준다면 글씨 크기는 12px로 보여질 것입니다. 이런 상황에서 p 요소에 글씨 크기를 16px로 키운다고 합시다. 그럴 경우 다음과 같이 보여지게 됩니다.

동해 물과 백두산이 마르고 닳도록...

p 요소의 글씨 크기를 16px로 바꿨기 때문에 안의 strong 요소도 같은 크기로 늘어나기를 바랬지만, 초기화 CSS 때문에 strong은 12px로 보여주게 됩니다. 이를 수정하기 위해서 strong에도 글씨크기 16px를 줘야 합니다.

하지만, 이 상황에서 다음과 같이 수정해야 한다면 어떻게 될까요? strong 안에 span을 넣었습니다.

'백두산'이란 단어는 다시 12px이 됩니다. 이를 수정하기 위해 또 span 요소에 글씨크기 16px를 또 줘야 합니다.

이런 작업은 정말 스타일을 주면서 짜증나는 일입니다. 문제는 이미 다른 페이지들이 완성되어 서비스를 하는 경우, 이 초기화 속성을 바꿀 수도 없다는 것입니다. 모든 페이지를 다 개편하지 않는 이상, 이 한번 선언된 초기화는 바꾸기 힘들어집니다.

font관련 속성 같은 경우는 대부분 요소의 기본 스타일이 부모 요소의 스타일을 상속받습니다. 그렇기 때문에 이러한 속성은 전체 요소를 아우르는 body나 html 요소에 한 번만 적용해 주면, 대부분의 요소들이 이 글씨 크기를 상속 받습니다.

불안정한 바닥 위에 지어진 건물의 모습
잘못된 초기화 CSS를 고치는 일은 많은 것을 감수해야 할 수 있습니다.

IE의 크로스 브라우징

앞서 엔진에 대해 이야기 했듯이, IE는 트라이던트 엔진을 사용합니다. 그리고 이 IE는 버전에 따라 상이한 랜더링으로 웹 제작자들에게 많은 시련을 주었다는 것도 알고 계실 것 입니다.

그나마 IE8부터는 어느 정도 표준을 준수하며, IE9부터 CSS3까지 지원하면서 IE9 이상의 브라우저에서는 거의 다른 브라우저와 비슷하게 보여집니다. 문제는 IE7를 포함한 그 이하의 버전들입니다. IE7이나 특히 IE6까지 내려가면, 웹 표준을 준수하며 작성된 페이지들을 아주 제멋대로 랜더링 합니다.

IE를 제외한 브라우저들은 대부분 자동적으로 업데이트가 일어나기 때문에, 다른 브라우저들은 최신 버전만 확인해도 거의 무방합니다. 하지만, IE같은 경우는 사용자가 윈도우 업데이트를 해야만 업데이트가 일어납니다. 게다가 IE의 업데이트는 선택적인 부분이기 때문에, 대부분의 사용자는 아예 모르고 있기도 합니다. (대부분의 사용자들은 본인이 사용하는 IE의 버전이 몇인지 조차 모르고 있습니다.) 게다가 IE는 Windows의 버전에 따라 최대 업데이트 할 수 있는 버전이 한정되어 있습니다.

그렇기 때문에, IE는 버전 별로도 크로스 브라우징을 해야 합니다. 무작정 사용자에게 최신 IE를 사용하도록 강요한다면, 그 사용자는 IE 업데이트 대신, 그냥 잘 나오는 다른 서비스를 이용할 것입니다. 하지만 문제는 IE를 제외한 브라우저들끼리 맞추는 것보다, IE를 버전 별로 맞추는 것이 더 어렵다는 것 입니다. 그래도 다행히 IE를 버전 별로 맞추는 방법은 몇 가지 있습니다.

IE 핵(Hack)

이 IE 핵이라는 것은 편법적인 방법입니다. 이 핵의 원리는 스타일을 줄 때 특수문자를 넣어서, 다른 브라우저들에서는 인식을 못하지만, IE의 특정 버전의 브라우저에서는 인식하게 하는 방법입니다.

다음은 글자 색을 IE 핵을 이용해서 준 CSS입니다.

앞에 보시면, 속성 이름 앞에 '*' 또는 '_'과 같은 특수 문자를 넣은 것을 확인할 수 있습니다. 속성 명 앞에 '*'를 넣을 경우, 이 속성은 IE7 이하(IE6,7) 브라우저들에서만 인식합니다. '_'를 넣을 경우는 IE6 이하의 브라우저에서 인식을 하게 되고요. IE7 이하에서 레이아웃이 깨지는 부분을 이 핵들을 이용해서 잡아 줄 수 있습니다.

사실 핵 중에 IE8용 핵이라고 나와있는 것도 있지만, 실제로 사용해 봤을 때, IE9, 10에서도 적용이 되어 넣지는 않았습니다. 이 외에도 IE핵을 검색해보면 몇 가지가 더 나오니 한번 검색해 보시기 바랍니다.

IE용 주석을 이용한 방법 (Conditional comments)

앞선 IE 핵을 이용한 방법은 IE7 이하의 브라우저에서는 간단하게 쓸 수 있는 방법입니다. 하지만 이러한 핵을 이용한 방법은 IE8 이상의 브라우저에서 구분해내기가 어려우며, 특히 CSS 소스를 지저분하게 만듭니다. 그리고 편법이라는 사실 역시 사용하는데 께름칙하게 만듭니다.

이 IE용 주석을 이용한 방법은 좀 더 공식적이며, 더 범용적이고, 더 깔끔하게 처리를 할 수 있습니다. 이 방법은 HTML 문서 내에서 주석을 이용하는데, 조금 특별한 주석을 사용해서 IE를 구별해냅니다.

위와 같이 주석의 형태이나 주석의 시작 부분에 괄호[]를 넣어 IE 버전을 명시하고, 끝나는 부분에 [endif]를 넣어 종료시켜 줍니다.

이러한 방법을 쓰면, IE 구 버전을 위한 별도의 CSS를 분리 시킬 수 있습니다. 이를 통해, 현재의 CSS 소스를 더욱 깔끔하게 유지할 수 있게 됩니다. 또한 HTML문서 안의 주석 형태이기 때문에, CSS 뿐 아니라, JS나 다른 내용 뭐든지 들어갈 수 있습니다.

앞의 소스는 IE 주석을 이용해서 IE6에만 문구를 노출하여, 최신 브라우저로 업데이트 하도록 권장하고 있습니다.

이 [if ~]에 들어가는 문구는 [if IE 7]처럼 IE7 한가지 버전에서만 인식하도록 쓸 수도 있지만, 'IE7 이상'이라던가, '미만'과 같은 범위를 명시해 줄 수도 있습니다. 만약 [if lt IE 7]이라고 if와 IE 사이에 'lt'를 적어줄 경우 IE 7를 포함하지 않은 더 하위 브라우저(less than)들을 선택하게 됩니다.

범위 지정 문구

lt
less than - 미만 (명시된 버전 미 포함)
lte
less than or equal to - 이하 (명시된 버전 포함)
gt
greater than - 초과 (명시된 버전 미 포함)
gte
greater than or equal to - 이상 (명시된 버전 포함)

메타를 이용한 IE 모드

앞서 살펴본 IE 핵과, 주석을 통한 처리방법은 일단 가장 최신 브라우저에 맞추어 스타일을 적용하고, 그 다음 핵과 주석 등을 이용해서 하위 브라우저에 맞게 추가적인 스타일을 주는 방식입니다.

예전에 IE가 거의 절대적인 점유율을 보이던 시절, IE가 버전업을 하게 되면, 너무나도 다른 랜더링 방식 때문에 웹 제작자들은 또 새롭게 수정을 해야 했습니다. 작은 사이트면 그나마 다행이지만, 대형 사이트라면 이 IE 업데이트가 오류를 몰고 오는 근심의 태풍으로 보였을지 모르겠습니다.

이러한 점에 대한 마이크로소프트사의 배려이었을 지는 잘 모르겠지만, IE는 하위 브라우저 랜더링을 지원합니다. 다시 말해 IE의 버전이 9이더라도 IE7과 동일하게 랜더링 해주는 것입니다. 이것은 당시에 IE의 업데이트로 생겼을 많은 유지보수들을 줄여 주었을 것입니다. 또한 웹 페이지를 만들 때에도, 한가지 버전의 IE만 맞추면 되기 때문에, 보다 수월하게 페이지를 제작할 수 있습니다. 이 IE 모드는 다음과 같이 사용합니다.

위의 메타 요소를 head 요소 안에 넣어두는 것입니다. 이 meta요소가 있으면 IE가 문서를 읽고 랜더링 할 때, IE7 모드로 랜더링을 합니다. 물론 content 값을 'IE=6'으로 바꿔서 IE6에 맞출 수도 있고 다른 버전으로 맞출 수 도 있습니다. 그리고 만약 'IE=edge'를 넣어주면, 해당 브라우저가 할 수 있는 가장 최신의 모드로 랜더링 합니다. 다시 말해 각 버전에 맞게 출력됩니다.

이 방법을 이용하면, IE의 여러 버전을 고민할 필요가 없기 때문에, 당장 사용하고 싶은 욕구가 들지 모르겠습니다. 하지만 만약 신규 페이지라면 절대 사용하지 않기를 권장합니다. 사실 많은 웹 서비스들도 이런 방법을 사용한 페이지가 많이 남아있습니다. 남아 있다는 말은, 정말 아직 수정을 못해서 남았다는 것으로, 현재 대부분 개편된 신규 페이지들에서는 사용하지 않습니다.

이렇게 쓰지 않는 이유로 한가지는, 이렇게 구형 랜더링 방식으로 출력할 경우, 최신의 CSS3를 활용할 수가 없습니다. 물론 아직까지 국내 웹 페이지에 CSS3의 비중은 아직 많이 낮긴 합니다. 하지만 꼭 CSS3가 아니더라도, IE8부터 지원하는 몇 가지 유용한 스타일도 있습니다. (이 모드를 사용할 경우, 보통 IE7 모드를 사용합니다.) 만약 위의 모드로 IE7 이하로 고정해놓는다면, 그러한 스타일을 사용할 수 없게 됩니다.

두 번째 이유로는 이제 브라우저의 점유율에서 IE가 절대적인 위치가 아니기 때문입니다. 이제 크롬이나 파이어폭스 등 다양한 브라우저의 사용자가 늘어나고 있기 때문에, 어차피 표준에 맞게 제작을 한 뒤에, 구 버전 IE에 맞추는 작업을 해야 합니다. 최근에 나온 IE9 이상의 브라우저에는 표준을 준수하여 작업하면 거의 동일하게 나옵니다.

그리고 마지막으로, 가장 결정적인 이유가 있습니다. 바로 IE가 업데이트 될 수록 하위 브라우저 모드가 완전치 않다는 것입니다. 특히 제 경험상 IE10부터 점점 그런 모습이 보여지는 데요, 실제 IE7의 모습과 IE10의 IE7 모드의 모습이 일치하지 않는 모습이 종종 보입니다. 문제는 이런 부분은 IE 핵이나 주석을 이용한 방법으로도 구분해낼 수 있는 방법이 없다는 것입니다. 이러한 문제는 IE10의 IE7모드가 어떻게 보이는 지까지도 연구해야 하며, IE10에서 버전이 더 높아질 수록 하위 브라우저 모드는 점점 더 불안정해 질 것입니다. 왜냐하면, 하위모드로 랜더링 하는 웹 페이지는 점점 줄어들고 있으며, 그만큼, 버그에 대한 확인과 문제제기는 더욱 줄어들 것이기 때문입니다.

다시 말해서, 만약 페이지를 하위 랜더링을 기준으로 만들게 된다면, 그 만큼, 당신의 웹 페이지는 수명이 길지 않게 되며, 때로는 대처 불가능한 문제를 만날 지 모릅니다.

IE6 장례식

앞서 보았듯이 IE는 웹을 만드는 사람들과 애증의 관계를 가지고 있습니다. 하지만 좋은 소식이 하나 있습니다. 바로 'IE6의 장례식'입니다.

이 소식은 지난 2010년 3월 1일 부로 구글에서 IE6를 지원하지 않는다 라고 해서 기획된 것입니다. 아무래도 IE6을 지원하기에 업무적인 부담이 그만큼 컸기 때문일 것입니다. 그리고 이 맘 때부터 점차적으로 전세계적으로 많은 웹 서비스들이 IE6를 지원하지 않고 있습니다.

IE6 장례식 사이트 모습
IE6 장례식 (IE6 장례식을 표현한 홈페이지의 모습, 아쉽게도 이 사이트는 현재 운영되지 않습니다.)

또한 IE의 점유율이 절대적인 국내에서도, 다행히 IE6의 점유율은 매우 떨어져서, 현재 IE6를 지원하지 않는 웹 사이트들도 많습니다. 예전에 항상 IE6 때문에 골머리를 앓았던 웹 개발자들도 한결 나아진 것입니다.

그리고 2014년 4월 8일 부로 마이크로 소프트가 Windows XP의 지원을 종료하였습니다. 이로 인해 Windows XP의 점유율이 낮아지게 되면, Windows 7에는 기본적으로 IE8부터 설치가 되기 때문에, IE7 까지도 점유율이 많이 낮아질 것이라는 전망을 내놓을 수 있습니다. 이 IE7, IE6을 고려하지 않게 되면, 정말 핵이나 IE만을 위한 스타일을 굳이 넣을 필요가 거의 없어지게 됩니다. 지금 웹 제작을 공부하는 여러분에게 정말 희소식이 아닐 수 없습니다.

마이크로 소프트사의 XP지원 종료를 알리는 웹 페이지
XP 지원종료 알림

하지만 그럼에도 저는 IE6까지 최소한은 나올 수 있도록 권장 드립니다. 분명 Windows XP의 지원이 중단되고, 점유율은 급격히 떨어질 것입니다. 하지만 현실적으로 XP는 굉장히 많이 보급되었습니다. (합법적이든, 불법적이든 말입니다.) 그리고 여전히 아무것도 모르고 XP를 사용자들은 매우 많으며, 아까 말씀 드렸듯이 그 분들은 본인이 IE6을 사용하고 있는지 조차 모릅니다. 또한, 개인이 사용하는 PC가 아닌 도서관 등 공용으로 사용하는 PC의 경우 매일매일 복구되는 방식이 많기 때문에, 여전히 IE6를 사용하고 있는 것을 종종 목격할 수 있습니다.

물론 IE6,7에서 다른 브라우저와 동일하게 나오는 것은 힘든 일입니다. 때문에 제가 말씀 드리는 것은 IE6,7에서는 깨지고 투박하게 보이더라도, 최소한 정보에 대한 접근은 다 가능하도록 배려해 놓는 것입니다. 또한 구형 IE에서는 사용자에게 구형 브라우저를 사용하고 있다는 것을 알림으로써, 사용자가 자연스럽게 IE를 업데이트 하도록 권유하는 것이 좋습니다.

정리

이상으로 크로스 브라우징에 대해 말씀 드렸습니다. 조금 길게 쓰긴 했지만, 지루하지 않으셨길 바랍니다. 이번 강의에서 내용이 좀 이해가 가지 않더라도, 그냥 참고만 하고 넘어가시면 됩니다. 이 크로스 브라우징은 여러분이 웹 페이지를 제작하면서 자연스럽게 겪게 될 문제입니다.

이 강좌에서는 구형 IE의 버그들에 대해선 특별히 다루지 않습니다. 구형 IE 버그에 대해서는 검색해보면 자료가 많이 있으니, 나중에 작업을 하시면서 IE 버그에 대해서는 직접 찾아보시기 바랍니다.

요점 정리
  • 크로스 브라우징의 기본은 웹 표준 준수.
  • 브라우저 엔진
    • 브라우저는 브라우저의 레이아웃 엔진을 가지고 있음.
    • 트라이던트 엔진은 인터넷 익스플로러에서 주로 사용.
    • 게코 엔진은 파이어 폭스에서 주로 사용.
    • 웹킷 엔진은 사파리에서 주로 사용하며, 예전 크롬에서도 사용.
    • 프레스토 엔진은 오페라에서 사용, 하지만 현재는 오페라가 블링크 엔진을 쓰면서 거의 안쓰게 됨.
    • 블링크 엔진은 현재 크롬과 오페라가 사용. (예전 웹킷에 뿌리를 둔 엔진)
  • CSS 초기화
    • CSS 초기화는 각기 조금씩 다른 브라우저의 기본 스타일을 평준화 시키는 작업.
    • 상속을 무시하고, 너무 많은 CSS 초기화는 오히려 추후 유지보수를 더욱 힘들게 할 수 있음.
  • IE
    • 예전 IE의 경우, 표준을 준수하더라도 다르게 보여질 수 있음.
    • 이를 해결하기 위해선 핵(Hack)을 사용하거나, IE용 주석을 사용.
    • 메타 태그를 이용해서 IE 하위 버전 모드를 할 수 있으나, 또 다른 버그를 만들어 낼 수 있기 때문에 비 권장.
    • IE6은 지원 종료로 IE6까진 고려하지 않는 추세. 하지만, IE6 사용자에게도 최소한의 정보 접근은 보장해야 함.

이 글이 유용하셨다면 친구들에게 공유 해주세요.