이젠 Doctype Switch가 아니라 Version Targeting?

Web Standards 댓글이 없음 »

지금 웹 개발자들 사이에선 갑자기 터져나온 차기 IE8에서 처음 도입될지도 모를 소위 “Version Targeting”에 관한 논쟁으로 시끌거리고 있다.

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

이 웹 사이트는 IE X에 최적화되어 있습니다.의 부활?

당연한 얘기지만, 제대로 된 웹 개발자들은 웹 표준 규약을 준수하면서 접근성이 좋고 동시에 효율적이고 유용한, 그리고 점진적으로 확장 가능한(progressive enhancement) 웹 사이트를 개발하려고 하지 결코 특정 버전의 웹 브라우저만을 목표로 개발하지는 않는다고 믿고 있다. 그런데 이번 소식은 어쩌면 이런 믿음에 찬 물을 끼얹는 얘기가 될 수도 있다.

이런 얘기가 나온 것이, 앞으로 웹 표준 규약을 정말 잘 따르는 IE8을 발표하게 된다면, 현재 다수의 웹 표준을 무시하고 제작된 많은 웹 사이트들이 무참히 깨져 보이게 되는 현상을 막아보겠다는 의도로 이해되지만, 그 실제 구현 가능성이 의심스럽고 (IE8에 내장된 Time Machine?), 설령 이것이 그대로 구현된다고 하더라도, 위의 제안서에 의도된 대로 다른 웹 브라우저들에서도 똑같이 이번 version targeting 관련 meta tag가 구현되지는 않기만을 바랄 뿐이다. (다행히, 이미 WebKit에서는 version targeting을 구현하기 어렵다는 점을 밝혔다.)

이 소식을 듣고 가장 먼저 드는 의문은, 만약 이 meta tag을 완전 무시해서 개발된 지금의 사이트들은 IE8에서는 과연 IE6의 랜더링 엔진을 쓰게 될 것인가? 아니면 IE7? 짐작컨데, 이 경우는 또 Doctype switch에 따라 IE7(Standards mode)과 IE6(Quirks mode)를 오락가락 할 듯한데, 이렇게 되면 미래에 사용자가 아무리 더 똑똑한 웹 브라우저로 접속해도 해당 웹 사이트는 개발자의 손을 떠나 하나의 특정 랜더링 엔진에 묶여버리는 것은 아닌지?
몰론, 이것을 방지하기 위한 방법으로 한 줄의 meta tag를 추가해주고, 오래된 사이트의 경우 새로운 웹 표준 환경에 맞게 오래되고 잘못된 코드를 수정해주면 되겠지만, 과연 개발자의 주기적 유지보수가 지원되고 있는 웹 사이트는 얼마나 될 것이며, 어쩌면 웹 표준 나몰라라 하는 무지한 웹 개발자의 경우 이 version targeting을 역 이용해서 아예 자신의 웹 사이트를 자청해서 IE6에 묶어놓는 경우도 빈번할 것이다.

결국, 혁신에는 둔감해졌으나 시장 장악력을 최우선시 할 수 밖에 없는 MS가 독점적 위치에 있는 웹 브라우저의 자리를 앞으로도 계속 고수하기 위한 또 하나의 방어막이자 웹 표준으로 가기 위한 걸림돌로 밖에 보이지 않고, backwards compatibility를 앞세워서 현재의 웹 환경을 그냥 꽁꽁 얼려버릴지도 모를 일이다.

가장 우려되는 점은 이것이 실제 구현될 경우, 특히 IE의 독과점이 지속되고 있는 국내의 현실을 비추어 볼 때, 웹 표준화의 진척 속도는 더 느려질 수 밖에 없을 것이고, 어쩌면 웹 환경은 더 오랫동안 IE6 혹은 IE7에 묶여버리게 되리라는 예측이다.
더러운 먼지는 털어내야지, 진공 포장해서 고이 간직할 필요는 없지 않은가?

이번 제안을 몇 번씩 읽어봐도 장점이라고 예시된 backwards compatibility나 더 가속화될 IE의 웹 표준 기술 지원 주기(?), 개발시 특정 IE 버전을 위한 가상 머신의 불필요, 더 예측 가능하고 계획된 점진적 개발의 진행 등 여러 이점들 보다도, 이것이 가져올 더 심각한 부작용이 염려되는 것은 어쩔수 없다.

But wait, a lot of people say at this point, why isn’t this a problem for Firefox, or Safari, or any other browser? The answer is that developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in “standards mode,” even though it didn’t follow the specification – because they’d already made their content work with our model.

IEBlog: Compatibility and IE8

그건 웹 표준이란 존재를 모르는 무지한 웹 개발자들의 불평이었겠지.

그나마, 이제 HTML5의 spec은 훨씬 더 명확해졌다는 소식은 들려오지만, 앞으로의 웹 개발 환경은 훨씬 더 복잡해지겠군. IE6 mode, IE7 mode, Super Standards mode… 😕

IE8에서 Super Standards mode를 원하세요? 그럼, 할 일이 하나 더 있군요. 아래의 meta tag를 추가하는 것도 잊지 마세요. 이제 Super Standards mode는 공짜가 아니랍니다! 아참, 요놈은 IE8 전용.

<meta http-equiv="X-UA-Compatible" content="IE=8" />
꼬리표:

IE7.js가 알파 딱지를 떼다.

CSS, JavaScript, Web Standards 댓글이 없음 »

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 파일이 등장하지 않았으면 한다.

꼬리표:

JavaScript에서 event를 쓸 때 고려해야 할 IE만의 차이점들

JavaScript, Notes 댓글이 없음 »
  • IE에서는 event listeners를 붙이거나 없앨 때, addEventListener/removeEventListener 대신에, attachEvent/detachEvent를 쓴다.
  • IE에서는 event 이름의 형식이, event가 아닌, onevent 형식을 쓴다.
  • IE에서는 event object를 해당 listener의 한 전달 변수(argument)로 돌려주지 않아서, 대신 global event 변수를 써서 접근해야 한다.
  • event 발생시 기본적으로 주어진 action이 실행되는 것을 막으려면 preventDefault method를 쓰는 것이 정석이지만, IE에서는 event object의 returnValue 속성 값을 false로 지정해 주어야 한다.
  • IE는 event 전달 과정(propagation) 중에서 보통 맨 처럼 진행되는 capture phase를 지원하지 않는다.
  • 다른 객체들로의 event 전달 과정을 멈추려면, stopPropagation method를 쓰는 대신에, event object의 cancelBubble 속성 값을 true로 지정해 줘야 한다.

  • IE에서는 event listeners를 method가 아닌 독립된 function으로 불러와서, event를 일으킨 target element를 알아볼 때 간단한 this 키워드를 쓸 수가 없고, 대신에 여러 단계의 상당히 복잡한 과정을 거처야만 얻을 수 있다.

    if (typeof element.addEventListener != "undefined") {
      element.addEventListener("event", eventListener, false);
    } else if (typeof element.attachEvent != "undefined") {
      var thisListener = function() {
        var event = window.event;
        if (Function.prototype.call) {
          eventListener.call(element, event);
        } else {
          target._currentListener = eventListener;
          target._currentListener(event);
          target._currentListener = null;
        }
      };
      element.attachEvent("onevent", thisListener);
    }
  • IE에서는 어느 한 element의 event listener가 DOM에 속해있는 또 다른 node의 reference를 포함하고 있을 경우, 사용자가 다른 페이지로 이동하더라도 해당 listener와 함께 관련된 DOM node들이 메모리에서 지워지지 않고 상주하게 된다. (IE 6의 memory leak 현상은 근래에 있었던 보안 패치에도 불구하고 여전한 듯.)

프휴~ 🙁

꼬리표:

TextMate의 CSS bundle에 포함된 IE hacks

Apple, Mac & iOS, CSS 댓글이 없음 »

TextMate와 함께 기본적으로 제공되는 CSS 번들에는 못난 Internet Explorer, 특히 IE 6 만을 위해서 사용될 수 있는 CSS hacks이 들어 있다.

바로 Other 항목 밑에 있는 것들로, 예를 들어 IE 6에게 png 그림의 투명도를 제대로 표시하게 하려고 Microsoft 전용 AlphaImageLoader Filter를 쓴 것이 있는데, background tab trigger로 사용될 수 있다.

.png-transparent {
  background-image: none;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/images/transparent.png', sizingMethod='image/scale/crop');
}

또 CSS3의 opacity 속성을 지정할 때는 IE를 위해 MS의 Alpha Filter가 사용된다. -moz-opacity 속성은 오래된 버전의 Mozilla 계열 브라우저들(Mozilla 1.7과 Firefox 0.9 이전) 위한 것으로 지금은 삭제해도 무관하다.

.opacity-div {
  opacity: 0.5;
  -moz-opacity: 0.5;
  filter:alpha(opacity=50);
}

그런데, 이것들 말고도 자주 쓰이는 꼼수들이 더 있기 마련인데, 개인적으로 두 가지를 더 추가해서 쓰고 있다.
하나는 IE 6 만을 위한 꼼수로, 이 놈은 CSS의 max-width와 min-width 속성을 전혀 알아듣지 못하는 관계로 할 수 없이 또 MS 전용 expression() 속성을 빌려와서 적용해 주어야 한다.
아래는 IE min-max-width라는 이름으로 저장된 CSS snippet의 내용인데, tab trigger로 iemwidth를 지정해 주었다.

width:expression(document.body.clientWidth > ${1:980} ? "$1px" : (document.body.clientWidth < ${2:480} ? "$2px": "auto" ));

또 하나는 CSS layout을 구성할 때 자주 쓰이는 snippet으로 float된 자식 요소를 감싸주려고 과거에는 CSS의 :after pseudo-element를 써서 float을 clearing하는 벙법이 많이 사용되었으나, IE가 아직까지 CSS 2.1의 :before와 :after pseudo-element를 지원하지도 않거니와, 더 간편한 방법으로 알려진 pseudo-element를 쓰지 않고 float을 clearing하는 방법이 많이 사용되는데, 여기에는 또 IE 6 이하 버전 때문에 꼼수가 들어가야 한다.
그래서 아래는 짧지만 타이핑의 수고를 덜어주기 위해 IE 7까지 고려한 새 float clearing 방법을 참고해서 추가한 아주 간단한 snippet이다.

${1:.clearfix} {
  overflow: hidden;
  ${2:_}height: 1%; /* IE 6 fix */
}

IE의 경우, float된 자식을 감싸려면 부모가 MS 전용 속성인 “hasLayout“이 true 값을 가져야 하는데, 우연히도 IE 7에 와서는 overflow의 속성이 주어질 경우(visible 제외) 자동으로 hasLayout 값을 갖게 되면서 또 다른 꼼수를 사용할 필요가 없다. 하지만, 불행히도 IE 6에서는 여전히 hasLayout 값을 주려면 이미 알려져 있는 여러 hasLayout 값을 갖게 하는 CSS 속성들 가운데 하나를 적용해 주어야 한다. (위에서는 “Holly Hack”이라 일컬어지는 height: 1%를 사용했고, 다른 브라우저들로부터 감추기 위해 underscore hack이 사용되었지만, 부모 요소에 height 값을 지정할 필요가 없다면 밑줄은 필요없다.)

이런 꼼수들의 실제 적용은 나중에 CSS 파일에 따로 모아서 사용하는 것이 사이트 관리하는데 수월할 것이다.

꼬리표: