Feed on
Posts
Comments

곧 정식 버전이 출시될 IE8은 처음 beta 버전이 배포되고 현재 RC1까지 많은 기사와 블로그 글들에서 성능 향상과 Acid2 Test를 통과해 웹 표준을 준수한 브라우저라는 이야기를 많이 실어놓고 있다.
Acid2 Test는 웹 페이지를 웹 표준에 맞게 제작했는지 검증하기 위해 HTML, CSS 검증기를 통과하는 것과 마찬가지로 브라우저가 얼마만큼 웹 표준 규격에 맞춰서 제작되었는지를 알아보는 방법 중에 한 가지라고 할 수 있다.
물론 가장 좋은 방법은 W3C에서 필요한 최소한의 권장사항을 모두 준수한 브라우저라고 하고 그것을 증명할 문서와 브라우저가 출력하는 결과로 증명할 수 있다면 속 시원하겠지만 그렇게 잘 차려진 밥상은 찾을 수 없으니..(사실 잘 못 찾겠다. 누가 좀..;)

그렇다면 Acid2 Test는 어떤 것을 검사를 할까?
acid2 test

이미 Acid2 Test는 작년, 제작 년에 줄기차게 다른 브라우저들이 통과하면서 많이 다뤘던 내용이라 좀 식상하지만..
IE8은 이제 처음 통과 한 것이니 다시 정리 해보면 Web Standards Project에서 제공하고 있는 Acid2 Test는 크게 대략 11가지 항목을 검사한다고 한다.

  • png요소 : 테스트 결과 중 눈 부분에 사용된 이미지가 png이며, 이미지가 제대로 출력 되는지 테스트 한다.
    acid2 test png
  • object요소 : 오브젝트 요소를 인식 하는지 테스트를 하며 오브젝트 안에 대체 컨텐츠(object포함)역시 인식하는 것을 테스트 한다. 이 테스트가 통과되면 IE8에서는 중첩 object와 object 안에 대체 이미지 및 컨텐츠를 표시해 줄 수 있다.
  • absolute, relative, fixed position : 레이아웃에 자주 쓰이는 position속성이 가능한 정확한 위치를 잡을 수 있는지를 테스트 한다. 이 테스트가 통과되면 더 이상 다른 브라우저와 position 위치 차이로 인해 css hack을 사용하지 않아도 된다.
  • box model : 기존 css box model 모델을 기준으로 한 테스트에서 width, height, max-width, min-width, max-height, min-height 항목을 추가한 테스트 이다.
  • css table : 테이블 태그를 이용한 레이아웃은 잘 못 된 표현방법 이기 때문에 css에서는 table처럼 레이아웃을 구성할 수 있도록 속성이 준비되어 있다. 기존 IE에서는 이 속성이 지원되지 않았지만 IE8에서는 이제 속성이 지원 되므로 의미는 더 명확하게 정할 수 있고 표현은 더 자유롭게 할 수 있게 되었다.
    acid2 test diaplay table
  • 여백 : css를 이용한 여백 계산이 얼마나 정확한지 테스트 한다.
  • 컨텐츠 생성 : 마크업을 수정하지 않고도 장식이나 주석을 추가할 수 있는지에 대한 테스트 이다. 이 항목은 확실하지 않지만 아마도 before, after, content 속성 지원에 대한 테스트를 말하는 것 같다.
  • CSS 파싱 : 알려지지 않은 css에 대해 무시할 수 있는지 테스트를 한다고 나와 있다. 그래서 그런지 이전 IE용 css hack은 더 이상 인식하지 않는다.
  • 표현 순서 : 표현에 있어 겹쳐지거나 중복되는 컨텐츠에 대한 표현 순서를 올바르게 지정 할 수 있는지에 대한 테스트 이다.
  • Line Height : inline요소의 box model중 일부 속성들의 브라우저 독립적인 속성값에 대한 테스트 이다. 이 테스트에서 일부라는 게 어떤 것 인지 정확하게 알 수 없지만 line-heigh와 vertical-align에 대한 테스트가 아닌가 생각된다.
  • 마우스 효과 : Element의 :hover class 속성이 적용 되는지 테스트 한다. 결과 페이지에서 코 부분에 마우스를 대면 색이 변하게 되는 것 인데 아마 이 부분에 대한 테스트가 아닌가 생각된다.
    acid2 test :hover
    IE8은 이 속성을 비롯해서 기타 다른 pseudo-class에 대한 지원범위도 넓어 졌다. 더 자세한 내용을 보려면 IE CSS 지원 차트를 확인하면 된다.

IE8이 Acid2 test는 통과 했다고 하지만 Firefox나 safari, opera 보다 사용율이 높은 IE 하위 브라우저들에 대한 대응은 계속 해야 한다는 문제가 남아 있다.
어찌 보면 또 하나에 브라우저가 더 추가되었다는 느낌 밖에 들 수 없을 테고 하위 브라우저 이용 율이 어느 정도 유지되는 동안은 IE8의 개선된 기능에 맞는 속성을 무턱대고 사용하는 것은 컨텐츠 접근이나 사용에 문제가 될 수 있으니 IE conditional comment 와 같은 방법을 사용하거나 충분한 테스트 후 페이지를 제작하는 것이 바람 직하다 할 수 있겠다.

이와 더불어 IE8에서 개선(?) 달라지는 사항들을 정리해 보면.. 아래와 같은 내용도 있다.

Haslayout 삭제
CSS2.1을 모두 지원하고 Acid2 Test를 통과 함으로 IE 자체 레이아웃 방식인 Haslayout기능은 더 이상 사용 하지 않는다고 한다.
이로 인해 IE8에서는 float으로 발생되는 버그나 박스 모델에서 width, height 값 인식 버그, margin 겹침 문제, position 위치가 다른 문제 등이 더 이상 발생 하지 않게 되었다.

Charset에 따라 글 간격 달라지는 문제 해결
IE(5,6,7)에서는 charset의 종류에 따라 글 간격(행간)이 달라지는 문제가 발생한다.
이 경우 가장 대표적인 문제는 텍스트 언더라인 문제와 상하 여백 문제인데 IE8에서는 Charset에 따라 텍스트 간격 차이가 없어 졌다.
하지만 텍스트 언더라인과 텍스트가 붙는 문제는 여전히 발생을 하는데 이 부분은 폰트 고유의 문제이며 중대한 문제가 아니라고 판단되는지 개선하지는 않고 있다.

브라우저 모드, 문서 모드 설정
표준을 준수한 IE8은 하위 브라우저와의 여러가지 차이가 발생 할 가능성이 있다.
이로 인해 개발자들과 사용자들에게 혼란을 줄 수 있기 때문에 하위 브라우저 호환성을 유지할 수 있는 설정 방법이 있다.
하지만 사용자 역시 브라우저에서 기본으로 제공되는 개발도구를 열어 브라우저 모드나 문서 모드를 마음대로 조작 할 수 있기 때문에 하위브라우저와 IE8을 모두 대응하기 위한 방법을 찾는 것이 더 좋을 것 같다.
(물론 사용자 조작으로 인한 변화의 책임은 사용자의 몫 이겠지?)

form 컨트롤러 자체 여백 문제 해결
모든 요소의 자체 여백은 해당 브라우저에 종속적이고 form 컨트롤러는 OS와 브라우저의 영향을 받는 부분이다.
하위 IE 브라우저에서는 다른 브라우저와 달리 form컨트롤러들이 css초기화를 하였음에도 불구하고 보이지 않는 자체 여백을 계속 지니고 있었지만(1px 테두리라고 해야 할까..) IE8에서는 이 부분이 개선되어 더 이상 자체 여백은 가지지 않는다.

Printing css 지원
기존 IE 브라우저는 프린트 페이지 여백 설정이 화면과 다른 결과로 출력 되었다.
이 때문에 미리보기나 출력을 하면 원하는 결과를 볼 수 없었는데 IE8에서는 이런 여백 문제가 개선되었을 뿐만 아니라 CSS2.1을 지원하기 때문에 print style 속성을 지원한다. 이 기능으로 인해 IE8브라우저에서는 프린트 페이지의 여백 설정이나 페이지를 나누어서 표현하는 다단기능과 같은 기능도 사용 할 수 있다.

IE8 확장 CSS 지원
IE8에서 자체적인 css 확장 속성을 제공하고 있다.
이 속성들은 현재 IE에서만 지원하는 css속성과 css3에서 지원될 속성 들을 IE8에서 사용할 수 있도록 하는 속성들이며, IE8만을 위한 전용 css로 사용 된다고 생각 할 수 있다.
아직 완전히 지원되고 있지는 않지만 내용 확인은 가능하다.
- microsoft css vendor extensions
- IE CSS Extension?

링크 url 값에 따라 :visited 인식안됨 문제
이 문제는 IE7부터 발생하던 문제였지만 IE8에서도 개선되지는 않고 있다.
방문한 url에 따라 :visited 인식이 되어야 하는 것은 당연하다고 생각하지만 IE7과 8은 url의 값이 스크립트로 구성되어 있거나 #이 들어가 있을 경우 디자인보안 문제로 인해 고의로 막았다고 하니 조금 힘이 빠지네..
링크의 :link와 :visited에 대한 구분 기준은 있지만 url의 어떤 값에 대한 정의는 특별히 없기 때문에 이 문제에 대한 정확한 정의를 내릴 수는 없어서 이런 문제가 생기는게 아닌가 싶고, 그다지 보편적으로 큰 이슈가 될 만한 문제가 아니라 생각되어서 그런지 이 부분도 역시 바뀔 것 같지는 않다.
하지만 방문 했다는 기준에 대한 :visited는 정의 내려야 하는 게 맞지 않나 생각된다.

여전히 하위 IE 브라우저 때문에 고생하고 있을 분들에게는 IE8의 출시가 어떤 영향을 줄지 궁금하지만 조금씩 더 나아지고 있는 IE와 점점 사용층이 IE6 에서 IE7 로 바뀌고 있으니 곧 IE8도 대중화 되길 바라는건 내 바램만은 아닐 것이다.
웹 표준 뿐만 아니라 기능향상과 IE8의 새로운 기능과 내용에 대해 궁금한 부분이 더 있다면 이 세미나에서 더 많은 내용을 얻을 수 있을 것이다.

2006년 12월 즈음 IE7이 출시되고 있던 것으로 기억된다.
(아마도 beta기간이 아니었나 싶다..)
당시 내가 속한 회사에서 제작 중이던 웹 사이트는 링크의 url을 기본적인 사이트 주소를 넣거나 #에 name을 붙여서 이동 하게 하거나 javascript로 이동하는 링크를 사용 했었다. 아마 대부분의 사이트에서 페이지 이동이나 컨텐츠 이동을 이렇게 하지 않았을까?

Link의 Pseudo Class :visited
IE가 아닌 브라우저를 이용해 웹 페이지를 제작해 본 사람이라면 링크의 url 경로가 스크립트로 구성 되어 있으면 :visited style이 적용 되지 않는다는 것은 잘 알 고 있을 것이다.
link의 pseudo-class중 :visited란? user agents에서 한번이라도 방문을 했는지 안 했는지를 구분하여 방문 하지 않은 페이지라면 :link로 인식 할 것이고 방문했다면 :visited로 인식하는 것을 말한다.(방문여부는 IE6 이하에서는 javascript 로 넘기는 링크라도 :visited를 인식하는 것을 보면 브라우저마다 기준이 다르지 않을까..?)

그렇다면 방문기록이 남을 수 없는 javascript로 이동한 경로는 그렇다 치더라도 #name으로 이동한 페이지는 방문 기록이 남게 된다.
웹사이트 방문기록 리스트
정상적이라면 방문기록과 href 의 url값을 비교하여 같다면 :visited로 인식이 되어야겠지만 IE7은 그렇게 되지가 않는다. 왜 그럴까?
그 당시 CDK에 글도 올려 보고 여러 사람들과 논의도 해 봤지만 그다지 중요하다는 생각이 들지 않는지 소리소문 없이 사라져 버렸는데 최근에 다시 듣게 되어서 정리하게 됐다.

CDK의 글을 보면 MS고객문의 답변 내용이 있는데 그 당시에는 답변에 대해 정확하게 정리가 되지 못하다 보니 고객문의 글을 100% 이해하기가 힘들었다. 특히 design이라는 단어가 뭘 뜻하는지 전혀 몰랐던 지라.. 그대로 묻혀 버렸는데 IE8에서도 동일하게 발생하고 있다 기에 다시 문의를 해본 결과 조금은 더 상세하게 답변을 들을 수 있었다.

답변 내용은…

[제목]
IE7: script에서 css visited 속성 사용할 수 없음.

[요약]
IE 7.0에서 CSS a:visited 속성을 기술해 주어도 href 에 # 이 들어가거나 javascript:xxx 형식으로 기술되면 기술된 속성이 반영되지 않아 색깔 구분이 안됨
샘플예제
<style> a:visited { color:blue } </style> <a href=”a.htm”> <– 정상동작
<a href=”javascript:showDetail(’b.htm’)”> <– a:visited CSS 반영안됨
<a href=”#b” onclick=”javascript:showDetail(’b.htm’)”> <– a:visited CSS 반영안됨

[원인]
Internet Explorer 7 의 강화된 보안 디자인으로 인한 현상으로, IE7 에서는 script 내에서 url history 정보를 보지 못하도록 디자인 변경되었습니다.
이로 인해 script 에서 CSS style 의 visited 속성이 적용되지 않는 것입니다.

[해결 방법]
고객사에서 관련 코드 수정하여 문제 해결.

제목이 script 사용으로 :visited가 안된 다고 되어 있지만 #이 들어도 마찬가지다.
좀 더 내용을 추가하자면 스크립트를 이용하여 이전 history 정보를 악용한 악성 사례들이 있어서 IE7 부터는 의도적으로 막았다고 한다.
자주 일어나는 일이 아니라서 잊혀져 있었던 일인데 원인을 확실히 알게 되어서 좋지만 이런 이유로 #name으로 이동하거나 링크 이동 후 자동으로 위치로 이동하기 위해 사용했던 링크 주소 방식은 방문기록에는 남지만 :visited로 인식하지 않는다니 아쉬움 생긴다.

해결방법?
IE에서는 보안정책이 강화되어 바꿀 수 없다고 하니 코드방식을 바꿔야 하지만 원천적으로 경로#name 을 인식하지 않게 되었으니 :visited를 인식할 수 있는 방법은 없을 것 같다
MS에서 제공해준 해결 방법이 있지만 사용하고 싶지 않은 건 나 뿐일까….;;

MS에서 IE8 부터 적용이 가능한 css extension을 제공한다고 한다.
ie css Extension
http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx
기존 속성에 -ms- 를 붙여서 사용하면 되며 내용과 적용되는 예시속성이 있는데…
내용을 살펴보면 세가지 사항에 대해 -ms-를 붙여 사용할 수 있다고 한다.

  • CSS 스팩에 정의되어 있지 않은 MS 확장 속성일 경우
  • CSS 스팩에 정의되어 있지만 W3C에서 아직 권고후보 상태인 경우
  • CSS 스팩에 정의되어 있는 속성

대략 이런 속성에는 적용해서 사용 할 수 있다는데 쉽게 말하면 IE전용 속성이나 css속성중에 IE가 인식하는 css 범위에서는 모두 사용이 가능하다는 이야기 아닌가? 이걸 보면 사실상 IE8 전용 css hack 이라고 말하는 편이 나을것 같다..
아무튼 filter 속성의 opacity값 문제로 찬명님과 블로그댓글 채팅(?)ㅋ 중에 몇 가지 안 사실은 -ms-로 설정할 경우 속성값은 따옴표(”") 로 감싸줘야 한다는 것이다.
예를들면..
opacity속성을 사용해서 투명도를 조절할 경우 크로스브라우저를 위한 코드여야 한다면 앞으로는 이런 코드가 되어야 한다.


#selector {
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);
opacity: .5;
}

또는


#selector {
-ms-filter:"alpha(Opacity=50)";
filter:alpha(Opacity=50);
opacity: .5;
}

이렇게 해야 한다.

좀 의문인건 filter 속성경우 -ms-를 붙여서 사용해야만 IE8에서 실행되는데
IE전용 속성인 scrollbar- 속성 경우는 -ms-를 붙이지 않아도 된다.
아직 beta단계라서 그런건지.. ie속성을 ie에게 배신당한 기분은 나만 느끼는건가.. -_-;

IE8 신규기능

올초 3월부터 시작된 IE8 beta1과 8월에 beta2, 9월 한국화버전까지 MS의 Internet Explorer(IE)도 버전업그레이드와 브라우저 변화에 노력중이다.
변화의 대표적인 예로 크로스브라우징을 맞춰야 하던 분들이 골머리를 앓고 있던 IE만의 렌더링 방식인 haslayout지원을 IE8에서는 더이상 적용되지 않도록 버리고 표준모드와 Quirks mode의 렌더링이 제작자의 의도와 맞도록 맞추고 있고, Firebug와 같은 디버그 툴의 사용 용도가 높아서 인지 IE8에서는 기본으로 기존에 개발자도구(Developer Toolbar)를 탑제해서 설치되고 있다.
이외 브라우저 충돌시 자동으로 복구를 해주는 기능이 있는데 개인적으로 이 기능은 좋은 인상을 주지 못하고 있는것 같다. 다음과 같은 상황이 있다면 말이다.. 예를들어 사이트에 들어가자마자 충돌이 나는 사이트가 있다면 브라우저를 자동으로 복하기 때문에 브라우저가 복구 된다고 한들 또 오류가 나고 또 복구 하고…. 무한으로 반복하기에 결국 브라우저를 종료시키지 않고서는 상황이 끝나지 않을것 같기 때문이다.
좋고나쁨을 아직까지 정확히 판단하기는 어렵지만 beta인 만큼 여러 시도로 다양한 기능과 개선사항을 보여주고 있는것 만은 사실이기에 기대가 되기도 한다.

신규기능
최근 브라우저들은 속도개선을 주로 내세우며 사용자들이 보다 더 빠르게 브라우저를 이용할 수 있는 것에 집중을 하고 있다.
IE브라우저는 웹표준도 웹표준이지만 이런 면에서도 유난히 좋은 인상을 주지 않는 것이 사실이지만 사용자의 이용율을 무시할 수는 없는 거의 절대적인 비율이기 때문에 이런 추가되는 기술이나 신규기능에 대해서 민감하지 않을 수는 없다.
IE8에서 내가 관심있는 신규기능은 Accelerator, Webslices이며, 두 신규 기능에 대한 간단한 설명과 현재 서비스에서 적용시 고민해 봐야할 문제에 대해 이야기 해보려 한다.
참고로 추가되는 새로운 기능이나 기술은 IE8 백서에서 더 자세히 찾아볼 수 있다.

Accelerator
Accelerator(액셀러레이터)는 beta1에서 Activity로 소개되었던 기능에서 이름이 변경된 것이다.
정보를 하나의 서비스로만 이용하지 않고 서비스 제공자가 규격화 된 xml코드를 이용해서 제공해 놓은 다양한 서비스들로 다르게 접할 수 있도록해주는 기능이다.
쉽게 이야기해 정보서비스를 이용함에 있어 사용자가 다양한 서비스를 끊김없이 이용할 수 있도록 제공해 주는 기능이다.

Accelerator 데모화면

예를 들자면..
기존에는 현재 보고 있는 웹페이지에서 다른 관련된 정보나 서비스를 이용하기 위해서 관련 키워드나 웹사이트 주소를 복사하거나 외워서 브라우저 주소창에 치거나 검색폼에 작성후 검색하고 원하는 서비스 페이지로 이동하는 방식이였다.
하지만 액셀러레이터 기능을 이용한다면 이런 절차를 줄여줄 수 있다. 액셀러레이터는 현재 페이지에서 관련 키워드나 페이지 그 자체를 자신의 브라우저에 추가된 액셀러레이터를 이용해서 바로 이용할 수 있도록 하고있기 때문이다.
위에서 이야기 했던것 처럼 사용자가 정보를 이용함에 있어 불필요한 절차를 조금이라도 줄여줄 수 있도록 해 주는 기능이라 할 수 있지만 이 기능에도 약간에 문제가 있다.
하나는 해당 서비스를 제공하기 위해 서비스 제공자는 서비스 페이지 어딘가에는 액셀러레이터를 설치할 수 있는 링크를 제공해야 한다. 한번은 설치를 해야 한다는 것이다.
다른 하나는 마우스 오른쪽 클릭이 제한된 곳이나 드래그로 컨텐츠의 하이라이트가 제한된 곳에서는 제한을 풀어야 할지 말아야 할지에 대한 고민이 생기게 된다는 것이다.
액셀러레이터는 키워드를 드래그 했을때 액셀러레이터 버튼이 활성화 되거나 마우스 오른쪽 버튼을 이용해서 사용하거나 브라우저 상단 페이지 메뉴에서 이용할 수 있게 되어 있다. 일반 적으로 가장 편한 방식이 키워드를 드래그 후 나타나는 메뉴를 이용해서 사용하는 것이 가장 좋겠지만 어떠한 이유에 의해 이런 기능을 막아놓은 사이트라면 액셀러레이터를 위해서 풀지 고민이 생기게 될 것이다.
액셀러레이터는 검색,사전,지도,메일 등 카테고리의 구분만 명확하다면 다양한 서비스와 연동을 할 수 있기에 그 매력이 상당히 높아 보이지만 위의 사항에 문제가 생긴다면 쉽지 않은 고민이 생길거라고 생각된다.

Webslices
Webslices(웹슬라이스)는 MacOS의 Webclip widget과 똑같다는 생각이 들었다.

Webslices 데모화면

hAtom 마이크로포맷 기술을 이용해서 서비스 제공자가 사용자에게 이용하고 싶은 콘텐츠만 쉽게 전달할 수 있도록 해주는 기능으로 사용자 입장에서는 즐겨찾기와 유사하게 취급되나 RSS의기능과 같이 정보갱신을 인식해 항상 최신정보를 유지하며 정보를 이용할 수 있게 해주며 정보제공자는 기존 마크업을 이용해서 제공할 수도 있다는 장점이 있다.
단순히 html만을 이용해서 제공할 수 있기 때문에 편리하지만 웹슬라이스 역시 고민해야할 점이 없는것은 아니다.
첫째로 기존 html 구조가 웹슬라이스를 제공하기위해 적합하지 않은 구조라면 웹슬라이스를 구현하기 위한 최소한의 골격을 마춰야 하는 단점이 있다.
두번째 문제는 사이트를 접속하지 않고 원하는 정보만 볼 수 있다는 장점은 사이트 접속으로 인한 수익(광고나 연동되는 기타서비스)을 추구하던 서비스에서는 그리 적합하지 않은 기능이기 때문이다.
때문에 ebay와 같은 상품의 꾸준한 정보갱신을 원하는 사용자가 많은 서비스라면 꾀나 적합한 기능이라 생각되지만 다양한 정보를 한곳에 다 표현하고 있어 정말 필요할것만 같은 한국의 포털메인 사이트와 같은 곳에서도 과연 좋은 기능일지 고민해봐야 하지 않을까 생각된다.

끝으로
Accelerator와 Webslices가 매우 매력적인 기능인건 분명하다.
beta지만 벌써부터 대응하고 있는 사이트도 생기고 있고.. 이런 현상은 IE가 단순히 사용율이 높기 때문만은 아닐 것이다.(정말 이런 기능이 필요했던 사이트도 있을 것이고…)
지금은 접목하기 힘든 서비스라도 기존 서비스를 잘 연구한다면 좋은 방향으로 사용할 수 있지 않을까 생각된다.
참고로 ebayAuction에서는 벌써 대응을 하고 있는중이고 꾀 잘 사용하고 있다고 보인다.

IE8 신규기능 개발가이드