인터넷 익스플로러7(이하IE7)의 가장 최근 테스트 버전인 RC1설치해 보았습니다. 베타 버전은 설치를 완료해도 실행 하자마자 죽는 바람에 테스트하지 못했습니다만, RC1은 무사히 실행되는군요. 기능상의 변화는 다들 아실것이라 여겨 생략하고 생산자의 측면에서 접근해 보겠습니다. IE7은 스타일 시트(이하 CSS)에 IE6(5)전용으로 만들어놓은 * html 라인을 더이상 참조하지 않게 되었습니다. CSS천하통일도 얼마 남지 않은 느낌입니다. 가장 마음에 드는 것은 이미 오페라 브라우저가 구현하고 있는 방식인 페이지 확대기술입니다. 글씨체의 확대가 아닌 페이지 확대기술이 도입되어 IE7에서는 문자열이 두줄로 늘어나는 경우를 위한 대비를 조금은 느슨히 해도 되겠습니다. 그리고, 정작 웹표준은 잘 준수하고 있는지 한번 살펴봅시다.

IE7.jpg

저의 CSS 작업 스타일은, 비교적 CSS표준안을 잘 표현하는 파이어폭스(이하FF)에 최적화하고 다음으로 IE전용 스타일 코드를 작성합니다. IE사용자가 8~90%에 육박하는 이 시점에서 굳이 FF를 최우선으로 작업하는 이유는 여러가지가 있습니다. FF에 최적화 해 놓으면 IE를 제외한 대부분의 브라우저(사파리, 오페라, 넷스케이프)에서 깨져 보이는 일은 없습니다. 약간의 오차가 있기는 합니다만, 대체 HTML태그(DL, DD, DT, OL, UL, LI 등)나 통용되는 CSS코드로 변경하여 대부분 해결할 수 있습니다. 맥의 사파리또한 IE못지 않은 생뚱맞은 CSS처리 방식을 자랑했습니다만, 맥용 FF가 나온 후로는 FF의 여러가지 처리방식을 따르는 추세입니다. 재미있게도 한때 최고의 점유율 자랑했던 넷스케이프는 FF와 IE의 드로잉방식 중 택일하는 기형적인 형태로 개발되었습니다. 결국, 웹 표준안을 따르지 않는 브라우저들(사실상, IE7을 제외한 IE시리즈로 국한됩니다만)로 인해 시간과 비용을 쓸데없이 소모해야하는 현실입니다.

소모전이 불가피하다면 최대한 피해를 줄이는 것이 상책입니다. FF의 플러그-인에는 매우 다양한 개발자 도구가 있습니다. 그 중에도 'Web Developer Toolbar'는 탁월한 개발환경을 제공합니다. 즐겨쓰는 기능 중 하나인 'Element infomation'은 마우스무브 이벤트에 따라 엘리먼트의 스타일 프로퍼티를 실시간으로 디스플레이합니다. 이와 비슷한 기능을 하는 IE용 Developer Toolbar가 있기도 합니다만, FF용에 비하면 완전 '응가'입니다. 'EditCSS'를 사용하면 사이드 프레임에 로드된 CSS코드를 수정하여 실시간으로 표시되는 결과를 확인하는 것도 가능합니다.(특히, 자바스크립트 디버깅환경은 두말하면 잔소리라구요!) 아무튼, 이런저런 유용한 기능으로 스타일 코드 작성 및 크로스-브라우저 지원에 소모되는 시간을 효과적으로 줄일 수 있습니다.

인터넷 익스프로러 7의 웹표준 준수는 구라(?)다.

ie7.gif

문제는 표준을 따른다고 자칭하는 브라우저들과 똑같이 보이지 않는다는 것입니다. 좌측화면은 올라로그 메인의 로그인 화면을 올 10월 출시예정인 FF2.0베타와 IE7rc1을 비교한 스크린샷입니다. IE7은 IE6과 비슷하게 margin과 padding값을 처리하면서 IE6을 위해 작성한 * html 라인을 무시해버리는 결과가 나타납니다.(뭡니까~ 이게~ 베타도 아니고 RC잖아요...) 비단, 깨지는 것이 이 곳만은 아닐 것입니다. 이대로 출시 된다면 IE7 전용 커스터마이즈가 별도로 필요하게 되잖습니까. 특정사이트에서는 로그인조차도 안되더군요. 더불어 간단한 테스트를 통해 자바스크립트 처리속도를 측정하니 엘리먼트생성에 있어서 갑나게 딸리는 성능을 보여주었습니다.

더욱 큰 문제는 IE7을 설치하면 종전에 사용하던 IE6은 사라지기 때문에 IE6에 커스터마이즈 작업을 할 수 없다는 것입니다. 그래서 IE7의 개발지원에는 IE6의 엔진도 별도로 지원했으면 하는 바램입니다. 그렇지 않으면 프론트앤드 엔지니어의 책상에는 작업용 메인PC와 저사양 테스트PC, 사파리 테스트용 맥 그리고 IE7이 설치된 서브PC까지 추가로 필요하게 되겠군요. 써글...

Comments