NARADESIGN

웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD


크로스브라우징 팁.

본문 건너 뛰기

웹 표준에 관심이 있다면 웹 접근성이나 크로스 브라우징에도 관심이 있을 것입니다. 웹 접근성은 웹 표준의 상위목적이며 크로스 브라우징은 웹 접근성 가운데 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로 극복하는 크로스 브라우징의 기초 입니다.

공통 선택자를 사용하면 웹 페이지 렌더링 성능에 좋지 않은 영향을 줍니다. 되도록 공통 선택자 사용을 피하는 것이 좋습니다.
2010.3.23 업데이트.

의도하지 않았던 여백이 발생하는 경우 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 브라우저를 직접 실행하게 되어 있습니다.

관련 포스트

웹 UI 개발자의 ‘웹 브라우저’ 이야기.

 

분류: CSS,웹 접근성,웹 표준 | 2007년 1월 12일, 10:00 | 정찬명 | 댓글: 24개 |
트랙백URI - http://naradesign.net/wp/2007/01/12/108/trackback/

24개의 댓글이 있습니다.

  1. 신현석 댓글:

    * 에 font-size를 small로 선언하면 전부다 상속되어서 점점 작아질 거에요. 1em외의 값을 font-size에 *로 선언하는 것은 불편할 것 같습니다.

  2. 정찬명 댓글:

    상대크기만 상속되죠. small 은 절대크기라서 상속되지 않습니다.

    http://trio.co.kr/webrefer/css2/fonts.html#value-def-absolute-size
    http://www.w3.org/TR/CSS21/fonts.html#value-def-absolute-size

    다른분들을 위하여 추가설명을 곁들이면 xx-small | x-small | small | medium | large | x-large | xx-large 은 절대크기 이며 각 단계별로 1.2 배의 크기변화가 있습니다. small 은 화면상에서 0.75em 또는 12px 과 같은 크기로 보입니다.

    한편 larger | smaller 는 상대크기라서 상속 됩니다. 이 역시 1.2 배의 크기변화를 가져오게 되고 small 크기의 서체에 larger 를 적용하면 1.2 배 커지면서 다음단계인 medium 크기가 됩니다.

  3. 어부바 댓글:

    제가 [웹표준]에 대해 제일 걱정되는 부분은 역시 [우리 회사의 홈페이지를 방문하는 고객들이 어떤 브라우저를 많이 사용하느냐]는 부분입니다. 파이어폭스가 뭔지도 모르는 고객들에게 웹브라우저를 추천하는 것 보다는 일단 익스플로러로 코딩하는 것이 마음이 편하지 않을까 하는 생각입니다. 일본에서 일하고 있는데, 여기 일본도 익스6의 점유율이 80%이상이 되네요. 물론 마음이 괴로워 웹표준을 하지 않겠다는것은 프로로서의 자격상실이라고 생각하지만 말입니다.

  4. 정찬명 댓글:

    어부바님, 반갑습니다. 웹 표준은 단순하게 많은 사람을 고려하여야 한다는 개념과는 다릅니다. 웹 표준은 모든 사람을 고려하고 있는 보편적 성질의 것입니다. 때문에 누군가 1%의 확률로 Safari를 사용하더라도 그것을 고려하여야 한다고 말하는 것입니다. 세상의 모든 퍼블리셔 들이 다시 IE를 위한 코드만을 생산한다고 한다면 소비자들은 결국 IE에서 벗어나지 못합니다. 저는 파이어폭스를 메인으로 사용하고 있지만 어떤 페이지들은 IE만을 위한 방식으로 코딩이 되어 있어서 그런 웹 사이트는 아예 파이어폭스 대신 IE로만 접속합니다. 하지만 해당 웹사이트 운영자는 파이어폭스 접속자가 없어서 파이어폭스는 고려하지 않아도 된다고 말하더군요. 그게 과연 맞는 말일까요? IE 사용자만을 위하여 코딩해 놓고 파이어폭스, 오페라, 사파리 접속자가 없다고 말하는 것은 우습다는 말입니다. 저라면 IE만을 위한 코딩에 마음이 더 불편할 것 같습니다.

  5. 이선주 댓글:

    테이블을 안 쓰고 해보니까. 표준보다도 제작시 생기는 다양한 문제에
    대응하기가 편하네요.

    스토리보드의 변화, 클라이언트의 변덕, 새로운 요소의 삽입 시에 테이블보다 10배는
    편합니다.

    문제는… IE 버그… 6.0보다는 7.0이 그래도 더 낫군요.

  6. 조준희 댓글:

    항상 읽기만 하다가 처음으로 글을 남깁니다…
    위에 보면 * 로 기본적인 폰트크기나 종류 마진 등등을 설정해줄 수 있다고 하셨는데 여기에서 이해할 수 없는 현상(?)이 있어서요. 테스트는 파이어 폭스하고 사파리로 해봤구요.
    * 설정 없이 그냥 출력을 하면 기본 폰트크기가 16px(1em, 100%)로 출력이 되구요, 물론 * 에 폰트크기를 1em으로 설정을 해줘도 같은 결과가 나옵니다. 근데 * 에 0.75em을 주면 기본 폰트크기가 실제 0.75em(12px)보다 작게 출력이 되네요? 왜 그럴까요?
    * 에 1em을 주고 body에 0.75em을 주면 기본 폰트 크기가 기대한 12px 크기로 출력이 되는데…

  7. 정찬명 댓글:

    조준희님 안녕하세요? 반갑습니다. ^^

    em은 px과는 다른 상대단위라는 것을 먼저 이해하셔야 합니다.
    px은 그 크기가 한번 정해지면 어느곳에 위치하던지 자신의 크기는 변하지 않습니다.

    하지만 em은 자신의 크기를 결정할 때 절대적인 기준이 없고 항상 부모로부터 그 크기를 상속받은 다음 자신의 크기를 결정하기 때문에 부모가 어떤 크기였는지를 기준으로 자신의 크기도 상대적으로 바뀝니다.

    따라서 아래와 같이 코딩하시면 코드의 중첩이 깊어질수록 자식의 크기는 부모 크기의 75% 수준으로 계속해서 줄어듭니다.
    * {font-size:0.75em;}

    아래와 같이 단지 4단계의 코드 중첩만 있는 경우를 예로 들면..
    html – body – div – div
    75% – 75% – 75% – 75%

    코드의 중첩이 깊어질 수록 부모의 크기에 비례해서 자신의 크기는 75% 밖에 클수 없으므로 증조할아버지는 그 크기가 가장 크고 증손자뻘 되는 자식은 보이지도 않을만큼 작아지게 되는 것입니다.

    마지막에 언급하신 방법은 제가 em을 사용할 때 즐겨 쓰는 방법입니다.
    * { font-size:1em;}
    body { font-size:0.75em;}
    이렇게 하시면 픽셀로 환산했을 때 모든 서체크기가 12px 크기로 설정됩니다.

    설명이 도움이 되셨으면 좋겠습니다 ^^;

  8. 조준희 댓글:

    와우~ 친절한 설명 감사드립니다~
    * 에 폰트값을 1 이아닌 다른 값을 주면 깊이에 따라서도 계속 영향을 준다는 걸 몰랐습니다…
    나름대로 이렇게 저렇게 테스트해본다고 해보고 올렸던건데…ㅎㅎㅎ ㅡ..ㅡa
    다음번에는 좀더 날카로운(?) 댓글을 달 수 있도록 하겠습니다.

  9. 정찬명 댓글:

    도움이 되신것 같아서 기쁩니다 ^^ 날카로운 질문은 무섭습니다 ㅡㅡ;

  10. 이승희 댓글:

    이걸 빼야하는 상황입니다.
    파이어폭스에서는 dtd 를 넣으면 js 파일이 보이지 않아서 빼야하는데요 ~
    dtd를 뺏더니……………..
    IE에서 여백이 생깁니다..
    위에 IE 버그같은데요.. 어떤식으로 작업을 해야하는지요..

  11. 이승희 댓글:

    상단에 DTD를 넣었는데요 안보이네요
    xhtml 1.0 traditional DTD 넣었습니다.

  12. 정낙훈 댓글:

    나눔고딕에서 “가 이상하게 출력이 되네요. 모양이 예쁘긴 한데, 저 따옴표로 인해서 제대로 출력이 되지 않네요. ^^;;

  13. 정찬명 댓글:

    아, 그건 아마도 나눔고딕 문제가 아니라 글 작성시 HTML Entity가 바뀌는 문제 때문일 껍니다. 코드에 사용되는 따옴표는 본래 “…” 이런 원형을 지니고 있지만 HTML Entity로 변형이 되면 & #8220 ;…& #8221 ; 이런 원형을 갖게 되는데 이 둘은 서로 다르고 HTML 코드가 FCKeditor 안에 포함되는 과정에서 자동으로 바뀌고 있습니다. 바뀌는 이유는 HTML 문서 본문에서는 쌍따옴표를 Entity로 변환해서 표기하는 것이 표준 문법이기 때문입니다.

    분명히 애로사항이기는 한데 그렇다고 문법을 거스르기는 싫어서 놔 두고 있습니다. ㅜㅜ;

  14. Daisy 댓글:

    * 공통선택자에 폰트 속성에서 생기는 문제에 대한 오랜 ‘의문과 귀찮음’을 해소시켜주셨네요.
    감사합니다. 대표속성을 사용해서라니;;; 두둥;; ㅡㅜ

  15. 나에 댓글:

    small, large 같은 형식은 브라우저마다 디폴트 크기가 다르다고 알고 있는데
    크로스브라우징을 위해서라면 살짝 배척을 해야할 듯 한데…
    제가 잘못 알고 있나요?

  16. 정찬명 댓글:

    크로스브라우징을 무어라고 정의하느냐에 따라서 괜찮기도 하고 그렇지 않기도 할 것 같습니다. 제가 생각하는 크로스브라우징은

    첫째, 이기종 브라우저간 동일한 콘텐츠를 제공하는 것이고.
    둘째, 이기종 브라우저간 시각적으로 다르다는 것을 쉽게 지각할 수 없는 정도로 구성하는 것.

    입니다.

    따라서 서체의 크기가 1px 달라지는 상황에서 크로스브라우징을 만족 했는지 또는 못했는지를 판단하는 것은 개인이나 집단에 따라서 다를 수 있다고 생각합니다.

  17. 홍창수 댓글:

    이 곳에 가끔 들르는데 이렇게나 좋은 글을 왜 이제야 보는지 모르겠습니다.
    크로스브라우징 때문에 항상 골치 아팠는데…
    공부가 되네요.
    감사합니다.

  18. 인쇄쟁이 댓글:

    좋은글이군요!!

    링크걸어놓고 자주 와야겠습니다.^^

  19. 정지영 댓글:

    정말 도움이 많이되어요
    요즘 표준웹에 푹 빠져있는데
    좋은 정보 감사합니당~

  20. 정찬명 댓글:

    @정지영
    위 내용 중 공통 선택자를 사용하라는 내용은 웹 페이지 렌더링 성능에 좋지 않은 영향을 줍니다. 되도록 공통 선택자 사용을 피하는 것이 좋습니다. 최근 발견된 정보라서 업데이트 했습니다. 감사합니다.

  21. […] 없애줌, 주로 CSS의 문제 발생 http://prefixr.com/  Cross-Browser CSS를 만들어줌 http://naradesign.net/wp/2007/01/12/108/ 4. 웹앱, 네이티브앱, 하이브리드앱 웹앱 – 웹브라우저에서 작동할 […]

  22. 익명 댓글:

    ……..대박정보네요………………………………..
    퍼갈께횼!!!!!!

  23. 김윤정 댓글:

    아고,.. 이름 하고 안적었네요~ㅋㅋㅋ
    제 블로그에 담아놓고 보고보고보고 하겠숩니다!

  24. 익명 댓글:

    안녕하세요 ie7 오류문제를 찾다가 보게 되었는데요
    ie7,8에서만 깨지는데 핵을 써도 제대로 안나오네요 ㅜㅡㅜ
    크로스브라우징을 해서 오류를 발견했을때 해결 방법도 포스팅 해주세요~
    제가 완전 쌩초짜인데 아무리 찾아도 크로스브라우징과 오류해결에 대해 자세하게 설명해주는 곳이 없어서요 부탁드립니다!

댓글 쓰기

전송된 글이 나타나지 않는다면 필터링 된 것입니다. dece24앳gmail.com 으로 메일 주세요.
(X)HTML 코드 사용이 가능하지만 소스 코드 출력을 원하시면 <꺽쇠>는 [괄호]로 변환하여 작성해 주세요.

필수 아님

필수 아님