'web standard/crossbrowsing'에 해당되는 글 1건

  1. 2008.07.29 크로스브라우징 팁
web standard/crossbrowsing2008. 7. 29. 10:40

출처 좋은생각 | 윤꽁주
원문 http://blog.naver.com/jeong1278/140035799454

웹 표준에 관심이 있다면 웹 접근성이나 크로스 브라우징에도 관심이 있을 것입니다. 웹 접근성은 웹 표준의 상위목적이며 크로스 브라우징은 웹 접근성 가운데 Vendor 호환성을 충족하는 기술입니다. 간혹 ‘웹 표준 지키면 크로스 브라우징은 저절로 얻을 수 있는것 아니었어?’ 라고 생각하는 분들도 계신데 이자리에서 오해를 푸셨으면 합니다. 웹 표준은 W3C 권장지침만 지키면 되는 것이지만 크로스 브라우징은 브라우저 제품별 특성(버그)을 모두 극복해서 동일하게 보이거나 또는 기능하도록 해야 하기 때문에 훨씬 어렵고 예측불가능한 문제와 자주 만나게 됩니다. 웹 표준 방식의 코딩은 시간이 너무 많이 걸린다는 오해도 여기에서 비롯됩니다. 정확히 말하면 웹 표준 때문에 시간이 많이 걸리는 것이 아니라 브라우저 제품의 버그를 극복하는 과정(크로스 브라우징)이 개발자들의 시간을 좀먹고 있는 상황입니다. 만약 모든 브라우저의 렌더링 방식에 버그가 없다고 가정하면 ‘웹 표준 vs 비 표준’ 개발자가 동일 사이트를 개발한다고 했을 때 ‘백이면 백’ 웹 표준 개발자의 코딩이 훨씬 빠를 것입니다. 도박은 별로 좋아하지 않지만 제게 내기를 걸어오셔도 좋습니다. 버그 투성인 IE 브라우저(암적인 존재)만 세상에서 사라져 준다면 이런 문제는 말끔하게 해결될 것 같은데 말이죠. IE, 생각할 수록 열받네요. 아래 설명중 제가 IE 라고만 표기하는 것은 IE6~7 을 모두 포함합니다. (IE:Internet Explorer, FF:Firefox, OP:Opera, SF:Safari)

바른 DTD(Document Type Definition)를 사용할것.

앞서 버그 투성이라고 소개했던 IE 조차도 DTD 만 제대로 적어주면 제법 표준에 따르는 렌더링방식을 취하게 됩니다. DTD 를 적지 않으면 브라우저들은 Quirk Mode 상태(어물쩡한 상태)로 렌더링 하기 때문에 바른 DTD를 적어주는 것은 크로스 브라우징의 첫 번째 원칙 입니다. DTD 조차 정의하지 않은 상태로 크로스 브라우징 한다는 것은 애시당초 불가능 합니다. 현재 활성 버전의 HTML 은 XHTML 1.0 이므로 XHTML 1.0 DTD 를 소개 합니다. 프레임셋 DTD와 호환모드 및 표준모드가 있는데 저는 호환모드를 권장 합니다. 프레임셋 DTD는 프레임이 있는 문서의 프레임셋에 정의하는데 프레임은 강력하게 비추천 하므로 권장하지 않으며 표준모드는 강력하게 추천하지만 너무 엄격해서 이를 적용하기 어렵기 때문에 소개하지 않겠습니다. 아래는 하위버전 호환성을 고려하면서 약간은 느슨한 상태의 호환모드 DTD 입니다. 제 블로그의 DTD도 이것이고 제가 최근에 개발하는 웹사이트의 DTD도 모두 이것입니다.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

공통선택자 ‘*’ 를 활용할것.

브라우저 제품에 따라서 특정 element 에 대한 margin, padding, line-hight, letter-spacing, font-size 등등… 많은 것들에 대한 차이가 존재 합니다. 특히 가장 빈번하게 발생하는 문제는 의도하지 않았던 여백에 대한 문제 입니다. 다행히도 공통선택자 ‘*’ 는 이런 문제를 간단하게 해결해 줄 수 있습니다. ‘실전 웹 표준 가이드‘ 또는 ‘CSS 마스터 전략‘ 이라는 책을 읽어보신 분들이라면 제 설명이 굳이 필요 없을것 같습니다.

* {margin:0; padding:0;}
or
* { margin:0; padding:0; font-size:small; font-family:돋움, Dotum, AppleGothic, sans-serif;}

위 예제 가운데 첫 번째는 앞서 소개해드린 서적에서 보통 설명하고 있는 방식의 예제이고 두 번째는 그것을 응용하여 실무에서 활용하고 있는 방식입니다. 제가 사용하는 공통선택자에 font 속성을 적용한 것과 font 속성에 대표속성(단축속성)을 사용하지 않는 이유가 궁금하실껍니다. 공통선택자에 font 를 정의하는 이유는 body 태그에 적용한 font 속성은 form 내부의 element 와 th, td 태그에까지 이를 상속하지 않는데 반하여 공통선택자에 이것을 적용하면 모든 element 에 대한 font 를 완벽하게 통일할 수 있기 때문입니다. 또한 font 에 대표속성(예: {font:small 돋움, Dotum, AppleGothic, sans-serif})을 사용하지 않는 이유는 이를 사용하는 경우 h1~h6, th, strong 태그가 기본적으로 지니고 있는 font-weight 까지 모두 초기화(normal) 되기 때문입니다. font의 대표속성을 사용할 때 font-weight 따위를 정의하지 않으면 font-wight:normal 상태로 렌더링 됩니다. 딱, 저 정도만 정의해 놓으면 일단 모든 브라우저에서 나타나는 margin, padding 관련 렌더링의 차이는 간단하게 해결 되고 사이트의 기본서체 문제까지 해결됩니다. 이것은 브라우저 제품마다 다른 element 의 렌더링 차이를 CSS로 극복하는 크로스 브라우징의 기초 입니다.

의도하지 않았던 여백이 발생하는 경우 inline 을 의심하거나 또는 그 면적을 float 으로 없애줄것.

의도하지 않았던 여백이 발생하는 경우는 보통 inline 형태의 element 문제 또는 IE 의 버그 때문 입니다. inline 형태의 element 는 항상 line-height 를 지니고 있습니다. 따라서 의도하지 않았던 여백이 발생하는 경우 일단 inline element 의 line-height 문제가 아닌지 먼저 확인해 보아야 합니다. line-height 도 화면에서 분명히 면적을 차지하고 있습니다. 안타깝게도 line-height 속성을 CSS 에서 따로 정의하지 않았다면 웹 브라우저 제품마다 line-heght 를 다르게 렌더링 할 것입니다. 이 때문에 어떤 브라우저에서는 의도한 대로 나타나지만 어떤 브라우저에서는 박스와 박스 사이에 여백이 생길 수도 있는 것입니다. 또 다른 문제는 잘 알려진 IE 버그로서 block 된 li 에 발생하는 알 수 없는 여백의 문제 입니다. 이럴 때에는 해당 li 가 화면에서 차지하는 면적을 제거하기 위하여 li {float:left; clear:both} 를 적용하고 float 된 li 의 면적이 부모 element 에게는 유효하게 전달되도록 ul {overflow-hidden} 을 적용해 보시기 바랍니다. 단, 이 팁이 모든 경우에 적당한 것은 아닐껍니다. 특히 세로 네비게이션 코딩시 문제가 발생하면 적용해 보시고 다른 경우에도 적절하게 응용해 보시기 바랍니다. 설명을 듣고도 잘 해결이 되지 않으면 제게 문의해 주세요. 친절 A/S 해드리겠습니다.

면적을 차지하는 것과 그렇지 않은 element 이해하기.

화면 레이아웃을 결정할 때 position 속성을 사용하거나 또는 float 을 사용하라고 배웠을 것입니다. {position:absolute} 상태일 때에는 화면에서 면적을 차지하지 않는다는 것을 잘 알고 계실껍니다. 그리고 {position:absolute} 상태일 때에는 그다지 렌더링 관련 버그를 만나는 경우가 없을 것입니다. 하지만 float 의 경우 IE 에서는 버그가 있으므로 FF, OP 브라우저와의 차이가 발견되면 일단 IE 를 믿지 마시기 바랍니다. 이것에 대한 문제해결은 float 이 화면에서 면적을 차지하지 않는다는 사실과 IE 에서는 이와 관련된 버그가 있다는 사실을 인지하는 것으로부터 시작됩니다. 자주 발견되는 IE 의 렌더링 오류는 float 된 요소와 float 되지 않은 요소가 만나는 방법입니다. float 은 원래 주변의 inline 요소만 흐르도록 하는것이 맞지만 IE 는 block 된 이웃 요소도 float 의 영향을 받습니다. 아래 예제를 FF, OP, SF, IE 에서 각각 렌더링 해보시면 제 설명의 이해를 돕습니다.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<title>IE의 float 관련 버그 확인</title>
<style type=”text/css”>
#a { float:left; width:100px; height:100px; background:#00F}
#b { width:100px; height:100px; background:#F00}

</style>
</head>
<body>
<div id=”a”></div>
<div id=”b”></div>

</html>

코드를 실행해 보셨으리라 믿고 설명을 계속 이어가겠습니다. FF, OP, SF 에서 b 상자는 보이지 않습니다. 왜냐하면 a 상자가 화면에서 면적을 차지하지 않고 붕 떠있으면서 b 상자를 가리고 있기 때문입니다. 하지만 IE 의 경우 b 상자는 float 의 영향을 받아서 a 상자의 오른쪽에 흐르고 있습니다. FF, OP, SF 의 렌더링이 맞고 IE 가 잘못된 렌더링을 출력하고 있으므로 당황하지 마시기 바랍니다. 한편 IE 처럼 렌더링 시키려면 b 상자에도 float 속성을 넣어주면 됩니다. float 된 element 는 float 되지 않은이웃 element 와 서로 간섭하지 않지만 float 된 이웃 element 끼리는 서로의 면적을 인식하게 되기 때문입니다. 추가적으로 IE 6.x는 float된 요소에 적용된 margin을 두 배로 출력하는 버그가 있습니다. 따라서 float을 사용할때 margin을 함께 사용하지 않는것도 중요한 팁 입니다.

Firefox 를 사용하고 IE Tab, Opera view 부가기능을 활용할 것.

일단 크로스 브라우징을 목표로 하고 있다면 IE 브라우저를 기본 브라우저로 사용하지 마십시오. IE 는 CSS 를 렌더링 함에 있어서 수많은 버그를 포함하고 있기 때문에 기준으로 삼을만한 브라우저가 못됩니다. FF 를 기본 브라우저로 채용하고 FF 의 확장기능(IE Tab, Opera View)을 이용하여 IE, OP 브라우저의 렌더링 결과를 확인하십시오. 사실 CSS 를 가장 정확하게 렌더링 해주는 브라우저는 Opera 와 Safari 입니다. Safari 는 Mac OS X 전용 브라우저이므로 Windows 에는 설치할 수 없습니다. 하지만 두 개의 브라우저 모두 Acid2 Test 를 통과한 브라우저 이므로 렌더링 결과는 Opera 와 Safari 가 크게 다르지 않습니다. 단, Safari 를 제대로 지원하려면 Mac 전용 서체 (ex: AppleGothic, AppleMyeongjo)를 보조서체로 사용하여야 합니다. Safari 브라우저의 Simulator Test 는 가능합니다. 현재 FF 2.x 버전도 Acid2 Test 를 통과하지는 못했으며 CSS와 관련된 약간의 버그를 포함하고 있습니다. 그러나 표준 준수율이 매우 높기 때문에 기본 브라우저로 채용하더라도 크게 문제는 되지 않을 것입니다. 또한 FF 의 확장기능으로 하여금 타 브라우저의 렌더링 결과를 쉽게 관측할 수 있기 때문에 이것을 사용하라고 권장하는 것입니다. FF 를 기본 브라우저로 사용하고 IE Tab 을 이용하면 IE 를 실행하지 않고도 FF 에서 IE 의 렌더링 엔진을 사용할 수 있습니다.(상태표시줄의 FF 로고를 클릭하면 렌더링 엔진을 IE 으로 전환해줌) 단, Opera view 는 Context Menu(마우스 우측 버튼>이 페이지를 Opera 로 보기)를 이용하여 OP 브라우저를 직접 실행하게 되어 있습니다.


Posted by 수라