보통 메뉴를 마크업할 땐 li로 나열해서 float propterty를 줘서 일렬로 늘어트린 후 감싸고 있는 상위 엘르먼트에다 width를 지정하고 margin propterty로 중앙에 위치시키는 기법이 많이 사용된다.

그런데 메뉴가 더 추가되거나 삭제되면 전체 가로 너비를 다시 지정해줘야 하는 문제가 발생하는데, 이런 단점을 보완한 기법이 있는데 바로 display:inlinedisplay:inline-block propterty에 그 해법이 있다.

CSS Wizardry에 소개된 기법으로 마크업과 CSS는 다음과 같다.

마크업:

<ul id="nav">
  <li><a href="/">Home</a></li>
  <li><a href="/about/">About</a></li>
  <li><a href="/work/">Work</a></li>
  <li><a href="/clients/">Clients</a></li>
  <li><a href="/contact/">Contact</a></li>
</ul>

CSS:

#nav{
  border:1px solid #ccc;
  border-width:1px 0;
  list-style:none;
  margin:0;
  padding:0;
  text-align:center;
}
#nav li{
  display:inline;
}
#nav a{
  display:inline-block;
  padding:10px;
}

text-aling:center;로 inline 속성을 갖게 된 li를 중앙 정렬하되 중요한 것은, li에다 display:inline;을 주고 a에는 display:inline-block;을 지정해 주는 것.

일반적으로 그냥 li에 display:inline-block;을 지정해 줄 수도 있지만, IE6-7에선 inline-block을 inline elements에 지정했을 때만 제대로 인식하기 때문에 a elements에 지정하였다.

얼핏 IE에선 inline-block이 말을 잘 듣지 않는다고 들은 것 같아서 이름 그대로 float만 떠올렸는데, IE6-7에서도 inline-block을 제대로만 활용하면 이렇듯 그 효용성은 더 높아질 것이다.

항상 웹 개발자들은 IE 렌더링 엔진의 모자름을 아쉬워하며, 사용자들이 더 나은 웹 브라우저를 설치해주기만을 간절히 바라거나, 혹은 최소의 방어 장치로 셀 수도 없는 온갖 가지의 임시 대응 패취 코드를 여기저기 심어놓는 일로 스트레스만 쌓이게 되는 일은 하루 이틀이 아니다.

이런 와중에, Google에서 문제에 직접적으로 칼을 대는 제안을 내놓았다. IE 심장을 Google Chrome의 렌더링 엔진(WebKit)으로 바꿔치기를 하려고 하는 것이다.

솔직히, 문제의 근본을 뜯어고치는 해결책은 아니더라도 살짝 돌아서 갈 수 있는 기막힌 방법이 아닐까? 주장대로만 된다면 한 번 Google Chrome Frame을 설치해놓은 IE 사용자라면, Google Chrome의 탁월한 렌더링 엔진 덕분으로 HTML5를 포함한 더 많은 표준 웹 기술을 아무런 제약 없이 맛보게 될 수 있을 테니까.

그런데, 폭 넓은 웹 기술에 관심이 많은 사용자라면 애초에 IE로 웹 서핑을 하려 하지는 않을 것이기 때문에, 결국 Google이 의도한 것은 평소 웹 기술엔 관심이 없는, 그리고 불가피하게 IE 6에 묶여있는 사람들에게 일시적으로나마 특정 사이트에 사용된 웹 기술을 사용할 수 있도록 하는 일종의 통과 패스권을 나눠주는 격이 될 테고, 또 개발자들에게는 하나의 화끈한 한 방의 해결책으로 사용될 수 있는 선택권이 추가되어 고마운 일이겠다.

자, 그럼 IE 사용자가 이 요긴한 통과 패스권을 처음 받으려면 우선 마주치는 페이지가 있는데, 살짝 혼란과 거부감이 들지는 않을까? (물론, 플러그인 설치 후 원래 페이지로 돌아가긴 하겠지만 말이다.)
Google Chrome Frame 설치 페이지
그림 속 보여지는 app은 Google이 준비중인 HTML5 기술을 이용한 야심작 Google Wave로 현재 Internet Explorer 6,7,8 모두 지원하지 않는다.

어찌 됐든 상황을 되짚어 보면, Microsoft가 열어 놓은 뒷 구멍을 통해 자신의 심장이 경쟁자의 것으로 통채로 바꿔치기된 형국이니, 앞으로 MS의 반응이 재밌어지겠군.

웹에서 넓리 사용되는 PNG 그림 형식에는 크게 두 종류로 나뉘는데 PNG-8과 PNG-24 버전이 있다. 물론 PNG-24 버전은 거의 완벽한 alpha transparency 재현이 가능하지만, 잘 알려졌다시피 IE 6에서 보기 흉하게 보이는 이유 때문에, 이를 해결하기 위한 몇몇 IE 6 PNG fix 관련 JavaScript 라이브러리들이 존재한다. 하지만, 기술적 의존도와 겹쳐저서 깔끔한 해결책이 될 수 없기에 찜찜함이 남는다.

이런 상황에서, 또 하나의 해결책이 될 수 있는 방법으로 Adobe의 Fireworks를 사용 여러 단계의 부드러운 alpha transparency가 적용된 PNG-8 파일을 생성하는 법이 주목받았지만, 문제는 다른 그래픽 어플리케이션에서는 이와 같은 방법을 그대로 사용할 수 없다는 것이 제약으로 다가올 수 밖에 없다.

그래서, 다른 방법을 찾아보다 위의 글에서도 잠깐 언급되었던 터미널 도구인 pngnq에 주목.
물론 Fireworks에서 저장하는 것처럼 언제나 휼륭한 결과물을 얻을 수는 없겠지만, 대부분 만족할 만한 효과를 낼 수 있어서 대체 방법으로 충분하다. pngnq 바이너리 파일은 여러 플랫폼들을 지원하고 있는데, 불행히도 정상적인 작동을 위해서 필요한 libpng가 Mac OS X에는 기본적으로 설치되어 있지 않아서, Mac에서 libpng 설치를 위한 간단한 패키지 인스톨러를 가지고 libpng 라이브러리 설치한 후, 내려받은 pngnq 바이너리를 /usr/bin이나 /usr/local/bin에 복사해서 사용.

pngnq 설명서를 보면 얼핏 복잡해 보이지만 기본적인 사용법은 상당히 간단하다:

$pngnq [input files]

터미널에서 위와 같이 입력하면, 원래 그림의 같은 디렉토리에, 이름 뒤 -nq8.png가 붙은 새로운 alpha transparency가 적용된 PNG-8 그림 파일을 얻을 수 있다. 변환 후 PNG 압축 도구를 이용한 후 처리도 필수.

헌데, 이렇게 IE6를 위한 꼼수들을 차곡차곡 모아 두어도 절대 개운한 기분은 아니군. :(

웹 디자인에 있어서 투명도가 섞인 PNG 그림 파일은 창의적인 디자인의 활용 폭을 넓혀주지만, 사용하는데는 한 가지 걸림돌이 있다. IE6에서 보여지는 alpha transparency가 적용된 PNG 파일은 흉측하기 마련. 그래서 여러가지 CSS hacks이 사용되기 마련인데, 그 중 가장 간단하고 효율적인 도구로 생각되는 것이 바로 Unit PNG Fix.

무엇보다도 사용법이 너무나 간단해서, 어떤 그림 파일의 조작 없이 아주 작은 크기(<1kb)의 js 파일을 올려두고 아래 코드를 추가해주면 다른 것은 잊어버려도 된다.

<!--[if lt IE 7]>
    <script type="text/javascript" src="unitpngfix.js"></script>
<![endif]-->

더군다나, 최근(08.26.08) 또 새롭게 갱신되면서 과거 불가피하게 사용되던 clear.gif 그림 파일이 더는 필요 없게 되어 한결 사용이 쉬워졌다.

그나저나, 8월 27일로 IE6의 탄생 7 주년이라는데, 끈질긴 생명력에 지쳐가는 시선들만 쌓이는군.

덧붙임 (2008.12.20): 어쩌면 골치아픈 IE6의 PNG 문제를 시원하게 해결해 줄 수 있는 새로운 치료약의 등장일지도 모르겠다. 이름이 약간 기억하기에 생소한 DD_belatedPNG로 기존 해결책들의 단점을 모두 해소한 듯.
과거 문제가 되던 background-position (fixed 제외)background-repeat 속성을 모두 지원하고, MS 전용 AlphaImageLoader 속서을 사용하지 않아서 z-index 관련 버그 걱정을 덜 수 있단다. IE를 위한 둥근 모서리 표시 기능을 제공하는 자매품 DD_roundies도 유용.

IE에게 웹 표준을 잘 인식하도록 최면을 거는 IE7 JavaScript 라이브러리가 2.0(beta) 버전으로 갱신되었다. IE7.js v2.0(beta)의 자세한 갱신 내용은 개발자의 웹 블로그의 글에 올려져 있는데, 주요 내용은 다음과 같다.

  • 이제 IE7 프로젝트는 googlecode로 자리를 옮겨서 진행됨.
  • 이제 IE7은 모듈러(modular) 형태로 배포되지 않고, 크게 IE7.js와 IE8.js 파일로 분리되서 배포됨.
  • IE7.js는 실제 MSIE7 브라우저에 포함되어 있는 기능들만을 인식하게 고쳐줌.
  • 기타 모든 기능 개선은 IE8.js로 옮김.
  • IE7의 파일 크기 축소(11KB gzipped).
  • IE7의 실행 속도 향상.
  • blank.gif 파일을 제외하고 다른 모든 의존적 추가 파일들이 필요없게 됨.
  • Google 서버를 통해 IE7/IE8.js 파일들을 바로 링크할 수 있게 됨.
  • base64로 인코딩된 그림을 위한 기능 수정은 더 이상 포함되지 않음.

간단하게 각각의 IE 6와 IE 7 브라우저를 위한 기능의 분화가 있으면서 파일도 둘로 나뉘게 되었다.
실제 웹 페이지의 적용은 이제, 라이브러리 관련 파일들을 서버에 올려둘 필요없이, 간단하게 <head>에 다음과 같이 써주면 끝.

MSIE5-6 웹 브라우저를 MSIE7처럼 행동하도록 기능을 갱신하려면,

<!--[if lt IE 7]>
<script src="http://ie7-js.googlecode.com/svn/version/xx.x/IE7.js" type="text/javascript"></script>
<![endif]-->

또는, MSIE5-7 웹 브라우저를 포함해서 MSIE7가 지원하지 않는 몇몇 CSS selectors와 속성들을 인식하도록 하려면 다음과 같이 써준다.

<!--[if lt IE 8]>
<script src="http://ie7-js.googlecode.com/svn/version/xx.x/IE8.js" type="text/javascript"></script>
<![endif]-->

아무쪼록, 나중에 IE 8이 발표되면서 또 하나의 IE9.js 파일이 등장하지 않았으면 한다.