스티브 발머 이제 아픔은 그만

지난 4월 사이트가 재 다운되고 이제서야 복구했다.
복구하면서 지난 포스팅들을 주욱 돌아볼 기회가 있었다. 몇몇 깨진 이미지도 곳곳이 보이고..
초심때의 흥분감을 갖고 재미있게 둘러보고 있는 중이다.

돌아보던 글들 중 아이폰 발매 뉴스에 관한 스티브 발머 발언이 눈에 띄었다.

“500불 짜리 전화기요? 비지니스맨들은 안살껄요”

이번주 발머는 Surface 태블릿을 공개했다.  2007년 비웃던 그 때부터 지난 5, 6년간 아이폰에서부터 아이패드까지 모바일 시장은 애플에 점령당했고 마이크로소프트는 뒤통수를 맞은듯 잠잠했다.  Courier 프로토타입 이야기가 나왔지만 사라졌고 클라우드 시장에 뒤쳐지지 않으려는듯 SkyDrive도 공개했다.  하지만 언제나 부족했다. 적어도 이번주까지 지난 5년은 그러했다.  윈도우8 이 ARM에서도 구연되는것을 보면서도 그다지 관심갖지 않았다.

그런 의미에서 이번 태블릿 공개는 몇가지 큰 그림들 보여주고 있다.  마이크로소프트가 직접적인 타블릿 시장에 뛰어든 것 뿐만이 아니라 모바일과 클라우드가 보여주는 IT의 방향에 윈도우 8을 자사의 해결점으로 제시하며 애플이 자랑하는 소프트웨어+하드웨어+서비스 체제를 적극적으로 대응하게 되었다.  그래서 일까?  Surface 오프닝때 발머는 열정적으로 마이크로소프트의 하드웨어 역사에 대한 이야기로 시작한다.  그리고 하드웨어와 소프트웨어의 조합으로 이어간다.

애플은 OS X 와 iOS + App&iTunes Store, iCloud, AirPlay를 통한 통합적인 체제로 가고 있다.  하드웨어 그 이상으로 모바일 기기와 텔레비전, 데스크탑들을 묶어주는 방향에서 윈도우 8은 마이크로소프트가 보는 그 해결점으로 찾은듯 하다.  OS X와 iOS가 통합되어지지 않은 현재, 윈도우8로 모바일과 데스크탑을 동일하게 통합하는 시도로 여러 장점을 부각시킬 수 있다.  어느 기기에서든 Metro UI로 유저들에게 동일한 인터페이스를 제공함과 동시에 이제는 너무나도 친숙한 클라우드 시스탬으로 동기화가 가능하니 사용자들이 Metro UI를 받아주기만 한다면 무시할수 없는 큰 스탭이 될것으로 보인다.

물론 이것 외에도 각기 다른 시각으로 이번 터치기기 공개를 관찰 할 수 있다.  통합의 의미 이전에 태블릿 자체로써의 틈새시장 공략 성공여부라던지 키보드를 ‘장착’함으로써 태블릿과 노트북, 넷북의 라인을 모두 충족시키게 되는 관점과 기타 태블릿 시장의 반응, 그리고 대처등등 재미있는 여러 부분들이 있겠다.  가격도.

마이크로소프트는 다시한번 애플의 뒤를 쫓는 시작을 한다.  하지만 언제나처럼 카피켓이라고 혹평을 받으면서도 애플을 추월하던 영광의 날들이 새로이 다시 시작되는 것인지 너무나도 궁금하다.  이번 태블릿전쟁을 시작으로 스티브 발머의 영광의 날이 올 수 있을지..

지난 2007년의 포스팅의 마지막 질문을 다시한번 남겨본다.

“과연?”

을씨년스러운 10월. 긋바이 XP

XP 가 왕좌에서 내려온 2011년 10월.
Steve Jobs 가 one more thing 을 외치지 못했고.
dmr 를 더이상 볼수 없는 슬픈 한달이다.

부록: 일모리가 XP를 보내며…
XP 야 욕 많이 해서 미안하다. 사실 인터넷익스플로러 6 그자식 아니면 그다지 악감정이 있지도 않아.
미운정 고운정 많이 들었는데 말이지…
사실 반짝이는 정품의 너보다는 복사된 너와 더 많이 논거 같다. 미안해…

혹시 알고있니… 네가 2001년 10월 25일에 상점에서 팔리기 시작한걸…
아이러니는 아니지만 딱 10년이 걸렸구나. 수고했다..

IE9 는 OS가 밀어준다: 앞서가는 그이

이제 겨우 베타출시. 물론 그전 테스팅버전들 보통 알파버전이라고 부르는 IE의 플랫폼프리뷰 버전들도 여기저기 buzz 가 있었지만 나름 IE9 베타는 오랜만에 크게 풍파를 일으키는듯 합니다. (여기에 캬~ 넣어주기)

아마도 아주 오랜만에 IE가 IE다워지는 버전을 출시하는 것 부터해서 뜨거워질대로 뜨거워진 HTML5의 열풍을 ‘나름’ 만족시켜줄만한 버전에다가 언제나 ‘표준’의 적이라고 불려지던 IE의 첫 ‘표준’ 선두주자 (나름) 로 부상된 IE이기 때문인거 같네요. :)

지난 IE 플랫폼 프리뷰 마지막 버전에서 어떤 ‘표준’의 이야기를 종식했다면 이번 IE9 베타버전에서는 인터넷 사용의 전반적인 개선을 강조하는듯 합니다.

IE 베타 출시 이전 막바지의 글 “User Experiences: Site-Centric Browsing on Windows” 유저 사용경험 : 윈도우 OS에서의 사이트 중심의 브라우징 과 “Putting sites at the center of the browsing experience, using the whole PC: IE9 Beta Available for Download” 컴퓨터의 모든것을 동원하여 사이트를 중심으로한 브라우징 경험을 하도록하기 를 보면 대충 알수 있습니다.

OS 를 사용하여 인터넷 브라우징의 극대화를 보겠다는 시도인데 참신하고 보기 좋습니다. 그리고 그게 맞고요.


태스크바에 직접 넣어버리기.


마치 패북 플러그인을 깐것처럼 웹사이트를 os자체에서 지원하기



사이트의 색상을 브라우저에서 adapt 적응해버리기

애플의 사파리 사용을 보면 전반적인 OS 의 특정 기능을 살린 브라우저 극대화라면(브라우저 뿐만이 아닌 프로그램들이 OS의 이득을보죠) 이번 IE베타는 OS자체가 반응하는 브라우저 극대화가 아닐지.

그러고 보니 지난번 IE7,8 소개한다고 오픈했던 사이트보다는 이번 사이트가 98배 정도 나은듯합니다. ;)

IE9 베타 다운로드” 브라우징의 앞날은 아직도 넓게넓게 열려있는 광대한 대륙. 모두 달려요.


IE팀의 짱 Hachamovitch가 말하는 ie.. 대충의 사용은 볼수 있습니다

그외 IE9 글들

html5에서 제외된 longdesc를 살릴수 있을까?

한창 요즘 메일링에 북적북적 활발히 활동하는 글들이 ‘부산 kwag 스터디 모임’의 모임 후기들입니다. HTML의 요소 하나하나들을 짚어가며 공부하고 계시는데 지난번 모임때 LONGDESC 에 대한 의문점과 토론들을 하셨던 것으로 기억됩니다. 안그래도 최근 번역하던 글들중에 “rebuildingtheweb.com” 에서 longdesc속성을 정의 하며 토론하기에 번역해서 올려드립니다. 꾸준히 토론하시고 공부하시길!

참고로 longdesc 속성은 long description ‘긴 설명’을 줄인 말로 이미지에 대체 텍스트 ALT 와 함께 쓰이는 속성입니다. 보통 외부 html과 연결이 되곤 하는데요.
<img src=”graph.gif” alt=”graph image” longdesc=”graphdescription.html” />
이렇게 사용하면서 alt 이상의 이미지에 대한 표현을 할수 있는 대체적인 방법입니다. 접근성을 높이는 용도이지만 실제적으로 거의 사용되지 않을 뿐더러 많은 기술적인 문제도 따랐기에 HTML5 에서 빼버린 속성입니다.

이 글은 rebuildingtheweb의 Vlad Alexander가 제시한 “어떻게 하면 longdesc속성을 살릴수 있을까?” 를 번역한 글입니다. 최근 HTML5에서 제외되면서 이 속성에 대한 재조명들이 이루어지고 결론적으로 불필요 하다 라는 방향으로 가는 중에 생각해 볼만한 글이 올라왔군요. 저도 한창 고민하던 부분이라 재미있게 보았습니다.

어떻게 하면 longdesc 를 구할수 있는가?

longdesc 속성은 유용하게 쓰일수 있는 가능성이 있음에도 불구하고, 또한 HTML 접근성 Accessiblity Task Force 에서도 고려해주기를 바랬음에도 불구하고 HTML5 스팩에서 제외되었다. 이 longdesc 를 제외하기로 한 결정은 HTML5 팀의 개으른 반응법을 보여주었다. “이 속성은 잘 안쓰이니까 버리지 머.” 물론 그렇다고 Task Force 가 원하는데로 longdesc 가 재활성화 된다고 해도 개발자들이 열심히 쓰는 것은 아니다. 두 기관이 자신들의 의무를 다시한번 상기하고 나아간다면 올바른 해결책이 나오리라 생각 된다.

HTML5 팀의 의무

HTML5팀은 HTML5가 현재 어떻게 쓰이는지에 초점을 맞춘다. 그것을 기반으로 longdesc의 가치를 바라보며 비인기적이며 현실적으로 의도에 맞게 잘 쓰이지 않는다고 보았다. 그러나 이 상황에서 ‘어떻게’ longdesc 의 사용에 대한 문제점이 고쳐질수 있는지는 묻지 않았다. 어떻게 HTML이 잘 사용되고 있는가에 대한 의무를 바라봤을뿐 어떻게 해야 잘 사용되느냐에 대한 질문을 하지 못했다.

접근성 전문가들의 의무

접근성 전문가들의 의무는 단순히 longdesc를 HTML5에서 재활성화 시키는것 이상에 있다. 이 속성에 대한 유저와 브라우저 밴더들이 바라보는 시각을 사용할만한 기능을 가진 속성이 되도록 바꿔주어야 한다. 이것을 달성하기 위해서는 전문가들이 개발자들의 시각에서 왜 longdesc 속성이 비인기적인 요소인지를 바라보아야 한다.

한가지 제안하는 해결책

상위 WYSIWYG 에디터 개발자중의 한명이자 컨텐츠 개발자들과 꾸준한 교류를 나누는 사람으로써 longdesc 가 제대로 사용되지 않은 이유를 들자면 longdesc와 그와 연관된 속성 alt 가 HTML 스팩에서 제대로 정의되지 않고 있기 때문이라고 말하고 싶다. 그러다 보니 리포트나 기사, 강좌, 레퍼런스같은 파생적인 사용들에서 잘못된 사용을 보여주게 되고 그것들을 통해 브라우저와 Tool 벤더들이 무턱대고 불규칙적인 기능들로 사용하게 되어 버린 것이다.

많은 퍼블리셔들, 컨텐츠 개발자들이 불행하게도 alt 속성은 이미지의 짧은 설명을 삽입하고 longdesc에는 더욱 긴 설명을 삽입한다고 이해하고 있다. 글 쓰는 이들의 관점으로 보면 이것은 당연히 헛갈리는 부분이다. 그들은 ‘왜 내가 짧게 설명하고 나중에 또 길게 똑같은것을 써야 하는가?” 라고 질문하며 왜 이것이 제대로 사용될수 없는지 증명해준다.
[일모리: img 태그 안에 alt 와 longdesc를 같이 삽입하다보니 ‘왜 똑같은걸 2번 쓰는가’를 의미하는듯 하다.]

그렇다면 앞으로 alt는 이미지의 ‘문자적인 대체’ 로 속성을 정의하고, 콘텐츠 안의 이미지의 ‘설명’을 longdesc로 정의해보면 어떨까 제안해본다. 미묘한 차이이지만 의미있는 중요한 차이점으로 단순히 글자의 숫자에 반영하는 것이 아닌 의미적으로 둘의 선을 확실히 그어준다고 생각한다. 이렇게 변화된 결과는 접근성 뿐만 아니라 개발 벤더들에게도 의미있는 인터페이스 개발의 도움을 주게 될것이며 글을 작성하는 사람들에게도 올바른 컨텐츠를 작성토록 도움을 줄 것이다. longdesc 속성의 약정을 충당하기에 아직 늦지 않았다. alt 와 longdesc가 어떻게 쓰여져야 할지 HTML 레퍼런스와 글들, 강좌들을 업데이트 할수 있다. (늦지 않았다) 브라우저 벤더들에게 alt 와 longdesc가 어떻게 렌더링되어야 하는지 해석 되어야 하는지 보여주고 개선된 사용자 인터페이스를 사용하게 되면 어떤 이득과 도움을 주는지 알려주자.

결론

단순히 longdesc를 HTML5에서 다시 살린다고 해서 웹이 더 접근하기 쉽도록 변하지 않는다. 대신 longdesc같이 접근성 기능들을 인기있도록 만들어 주는 것이 HTML5 팀과 접근성 전문가들의 의무이다. 그리고 그것의 한 방법이 alt 속성과 longdesc 속성을 제대로 정의하여 브라우저 벤더들과 제작자들 퍼블리셔들이 쉽게 적용하고 사용하도록 하는 것이다.

일모리: 이것은 상당히 흥미롭다. 글자수에 따라 longdesc와 alt를 구별하기 보다는 그 의미에서 구별하여 벤더들과 개발자들이 정확히 선을 그을수 있도록 하자 라는건 longdesc 뿐만이 아니라 이미지의 접근성에 대한 시각을 바로 볼수 있도록 눈을 열어주는듯 하다. 물론 longdesc에 대한 기술적인 문제점도 많다. 특별히 댓글부분에 대한 해석을 되도록이면 하지 않았다. 우리에게도 이제 이러한 글들에 대한 바른 해석과 토론이 이루어 질 수 있는 능력이 충분히 생겼다고 생각한다.

CSS 테크닉과 성능향상 관계

작년에 David Hyatt 이 Shawun Inman 의 글에서 이러한 댓글을 달았었다.

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.
CSS3 선택자에 대한 슬픈 사실은 페이지 성능 향상에 조금이라도 신경을 쓴다면 전혀 사용하지 말아야 한다는 것이다. 순수하게 클라스와 아이디 선택자를 사용하며 자식 선택자, 하위 선택자, 인접 선택자를 사용하지 않으면 모든 브라우저에서 확연하게 성능 향상을 볼 수 있다.

David Hyatt은 모던 브라우저들의 개발에 영향을 주며 카미노를 만들고 불여우 파이어폭스를 Blake Ross 와 같이 만들어간 사람인 만큼 저 멘트에 대한 여파가 컸었다. 여러 테스팅도 진행되었고 하나같이 결론은 차이는 ‘significant’ 확연하게 차이가 나는 것이 아니므로 남용하지 않는다면 실용적인 사용에도 문제가 되지 않는다고 의견들이 모아졌었다. 오히려 그 시간에 다른 부분에서, 예를들어 JS 향상을 위해 손 보는것이 오히려 더 효율면에서 낫다라고 누군가 언급했었던 기억이 난다.

여기서 최근 재미난 테스팅을 SCREWLEWSE.COM 에서 진행했다. CSS 선택법, 사용법에 대한 카테고리를 나누어 그것이 브라우저 성능 상태와 어떤 연관성이 있을까라는 발상에서 시작 되었는데 일단은 CSS 테크닉에 있어서 나누어 놓은 3가지 방법을 살펴보아야 한다.

  1. OOCSS 한창 주목받았던 그리고 꾸준히 접목되고 있는 아이디어. 기본 룰을 담은 class 를 부르고 세밀한 부분을 다른 클라스에 담아 복수 클라스를 부르는 방법. Object Oriented CSS 객채지향 CSS 로 소개도되고 잘 알려진 것으로 안다.

    .ilmol 에 기본 속성을 정의해 주고 .ilmol-1 .ilmol-2에 각각 세밀한 부분을 넣은 후에 html에서 class=”ilmol ilmol-1″ 처럼 복수의 클라스들을 불러주는 방식.

    [code lang=”css”]
    .ilmol {margin: 10px 25px; font-size: 100%; background: black;}
    .ilmol-1 {color: red;}
    .ilmol-2 {color: yellow;}
    [/code]

  2. Sass @extend 는 OOCSS를 좀더 세분화 한 것이라고 보면 된다. 기본 룰을 담을 클라스를 새로 만들지 않고 단순히 여러 클라스를 불러 기본 룰을 정의 한 후 나중에 하나하나 세밀하게 룰을 적용하는 방법.

    .ilmol-1, .ilmol-2 {속성} 을 정의한 후 나중에 .box1 과 .box2를 정의해 주면됨.

    [code lang=”css”]
    .ilmol-1, .ilmol-2 {margin: 10px 25px; font-size: 100%; background: black;}
    .ilmol-1 {color: red;}
    .ilmol-2 {color: yellow;}
    [/code]

  3. Long / Bloated 그냥 각각의 클라스에 알아서 스타일을 주는 방식

    [code lang=”css”]
    .ilmol-1 {margin: 10px 25px; font-size: 100%; background: black;color: red;}
    .ilmol-2 {margin: 10px 25px; font-size: 100%; background: black;color: yellow;}
    [/code]

이 세가지와 CSS가 없는 스타일을 합하여 4가지들에 각 브라우저들 마다의 테스팅을 진행 하였다. 그래프상 높을수록 시간이 오래걸린다는 것이니 성능에는 반비례한다.


from screwlewse.com

위의 그래프가 보여주듯이 Sass 테크닉이나 oocss 테크닉이 평범하게 사용되는 기법과는 확연한 차이를 보여주고 있다. 특별히 oocss는 모든 브라우저에서 가장 빠르게 읽혔음을 볼수 있는데 Cascading Style Sheet 이라는 법칙인 만큼 oocss 가 적용되지 않았나 생각이 들었다.

재미있게 보셨으리라 생각되고 이 테스팅이 절대 보통하는 테크닉이 잘못되었다거나 속도가 현처히 느리다라는 결론이 아니다. 여러 테크닉을 이해하는데에 있어서 이론적인 결과물을 보여주는 것이다. 적어도 일모리에겐 어느정도의 브라우저마다의 CSS 입력방식에 대한 팁을 선사해주는 부분에서 깨닳음을 얻었다고나 할까?

IE9 가 이제 푯대다. 적어도 IE팀이 말하기엔

각종 기기들과 모든 일상이 WEB2.0이 바라 보았던 것처럼 모든 삶의 기반이 되어 가면서 그것의 통로인 브라우저의 중요성 또한 이제 심각하게 들어나고 있는 현실이다. 플래쉬 사용의 기반이 되느냐 안되느냐가 상품의 선택권에 있어서 중요한 역할을 하는 이 시대인 것이다. 이 와중에 웹의 통로의 중요한 획을 그었던 마이크로소프트의 인터넷익스플로러가 ie6의 성취감에 자축할때 브라우저들은 진화했으며 ie6을 샌드백 취급했던건 사실이다. 지난 몇년간 브라우저의 공방의 일방적인 패배앞에 채면상 채워 넣었던 브라우저가 ie7, ie8 이라면 이제 ie6의 명성을 되찾겠다는 첫 제대로된 움직임이 ie9이 아닐까 기대해본다. 승패 그 이상의 자존심의 문제로 보인듯한 움직임은 이제 여러분들이 판단하게 될 잣대가 아닐지. 물론 결과에 대해 어렴풋이 짐작은 하지만 아직은 이 글을 읽는 모두에게 판단을 맡기자 :)

HTML5, Modernized: Fourth IE9 Platform Preview Available for Developers. HTML5, 더욱 새롭게 된 4번째 IE9플랫폼 프리뷰 버전 공개 라는 글을 번역한 것이다.

HTML5, Modernized: Fourth IE9 Platform Preview Available for Developer

IE9 는 앞으로 HTML5가 웹사이트보다는 기본 어플리케이션인듯한 경험을 전달할 것이라는 전제아래 시작됬다. SVG, CANVAS, VIDEO, AUDIO, TEXT 등을 기반으로 개발자들은 컴퓨터 전체적인 역량을 사용하여 커다란 성과를 가져오게 될 것이며 근대 웹에선 비록 다른 HTML5 브라우저라고 할지라도 동일한 마크업을 사용하게 된다.

IE9 를 통하여 우리는 개발자들과 더욱 가깝게 협력하여 일을 할 수 있었다. 개발자들은 우리의 기초적인 플랫폼을 경험할수 있었으며 그것을 시작으로 하여 개발자들의 피드백, 의견들이 그 어느때 보다도 영향을 많이 끼치게 되었다. IE9 Platform Preview 버전을 2.5million 번 이상 다운로드 하였으며 IE Test Drive 웹사이트의 샘플들은 20million 이상의 방문자들이 다녀갔다. 긍정적인 피드백들과 특정 이슈들을 Connect 를 통하여 전달해 주신분들께 너무나도 감사드린다. 그러한 것들이 개발자 커뮤니티들이 지적한 부분들의 향상에 도움을 주었다.

이제 IE9의 4번째 Platform Preivew 가 이제 공개되었다. 하드웨어의 역량을 끌어낸 HTML5 (fully hardware-acclerated HTML5) 를 경험할수 있게 되었다. 여러분들은 근대 svg 와 네이티브 자바스크립트가 돌아가는 새 drive 샘플등을 경험할 수 있다. 3월에 우리는 매 8주마다 새 Platform Preview를 공개한다고 약속했었다. 이 설치와 함께 여러분들은 더욱 향상된 성능과 더욱 높은 마크업 지원을 보게 될 것이다. 또한 리포트된 많은 버그들이 개선된 것을 볼수 있을 것이다. drive 샘플들을 이하의 클립으로 보자

브라우저가 지원한다면 HTML5 비디오 태그 (h.264 코댁) 를 사용하고 그 외에는 다른 방법을 사용하게 된다. 같은 마크업이 여러 브라우저에서 인식되는 것을 보여주는 좋은 예 이다.

Fully Hardeware-Accelerated HTML5

하드웨어 가속화의 성능에 대한 장점은 IE9와 기타 브라우저들을 양 옆에 놓고 돌렸을 때에 확연하게 차이가 난다. 부분적인 하드웨어 가속이 가능한 브라우저는 개발자들과 사용자들(end users) 에게 불규칙적이고 어떤면에선 예측할수 없는 플랫폼 경험을 제공할 수 있다.

IE9 는 하드웨어를 기반으로 한 일정한 그래픽, 택스트, 미디어, 사운드와 비디오를제공한다. HAMSTER DANCE REVOLUTION, IE BEATS, MSNBC VIDEO 를 각각 다른 브라우저들로 돌려보며 차이점을 경험해보기 바란다. Psychedilic Browsing 은 하드웨어 가속이 전적으로 사용된 GPU 에서 HTML5의 CANVAS 가 무엇을 할수 있는지 보여준다.

comparison

Modern SVG

Platform Preivew 4 를 통하여 높은 상호반응과 통합되어진 svg를 보여줄수 있게되어 기쁘다. 보통 svg라 하면 개발자들은 static 이미지들과 다이아그램등의 형태를 생각한다. HTML5 와 하드웨어 가속을 사용한 svg는 상호반응하며 움직이는 시나리오를 생각할수 있는 새로운 기반으로 사용될 수 있다.

SVG DICE 예를 보면 자바스크립트로 움직임을 전달하며 보여주는 svg의 성능을 볼 수 있다. 이 샘플은 브라우저들간의 SVG 마크업을 표현하는 성능의 차이와 SVG에 CSS로 스타일을 적용 시키는 잇점을 놀랍게도 잘 보여주고 있다. 불행하게도 동일한 SVG를 다르게 표현하는 브라우저들의 차이들을 볼 수 있으며 그것은 브라우저 커뮤니티가 같은 결과물이 나올수 있도록 앞으로 노력해야 하는 것을 보여준다.

(일모리: 매일 비IE브라우저들을 쫓아가기에 바빴던 IE팀이 IE9를 통해 앞으로 일정 부분에 있어서 선두 주자로 다시 나서면서 타 브라우저 회사들에게 일침을 가하는 부분이다. 몇몇분들에겐 통쾌함을 다른분들에겐 쓰라림을 안겨주는 부분이 되기도 하겠다만.. 이하에서 자바스크립트나 마크업 테스트들에서 계속 타 브라우저들을 비교하며 여태까지의 서러움을 조금이나마 설욕한다)

자체적 자바스크립트의 조화

우리는 HTML5 어플리케이션의 성능과 브라우저들간의 동일한 마크업 출력을 위한 올바른 기반을 새우는데에 헌신하기로 작정하였다. 이를 성취하기 위한 한 부분으로 몇몇 브라우저들이 여러 자바스크립트 엔진을 껴 넣는것 과는 다르게 브라우저 안에 자바스크립트 엔진을 통합하는 것이다. 실제적인 HTML5 에 있어서 자바스크립트 엔진을 브라우저안에 통합하는 것이 자바스크립트 자체만큼이나 중요한 것이다.

4번째 Platform Preview 는 Chakra 코드네임을 가진 새 자바스크립트 엔진을 IE9 안에 넣으므로 하나의 통합된 시스탬을 만들었다.

이 깊은 통합으로 인해 실제적인 웹사이트들의 기능 향상이 이루어지며 ECMAScript 를 기반으로 한 브라우저와 스크립트 엔진사이의 shared DOM(DOM을 공용하는) 을 갖게된 최초의 브라우저 이다. 잇점들은 실제적인 성능 향상과 일정함부터 시작된다.

이 본질적인 변화에 대한 가장 쉬운 이해는 인터넷익스플로러의 이전 버전들이 어떻게 자바스크립트를 사용하였는가를 보면 알 수 있다. 적어도 약 15년간 IE는 자바스크립트를 포함하여 VBScript, 특정언어의 Peal까지 여러 프로그래밍 언어를 지원해왔다. 개발자들에게 이러한 선택권을 허락하면서 성능과 기능의 저하를 감안해야 했다. 브라우저와 이러한 언어들은 COM을 통하여 소통하였고 그것은 성능의 문제를 가지고 오게 되었다. 각 스크립트 엔진들은 DOM를 각각의 시각으로 이해하였고 모순과 불일치를 가져왔다. 그 뿐만 아니라 브라우저들은 최소의 공통분모를 갖게되었고 새 기능들을 제작하는데 더욱 어려워지게 된 것이다.

비교 다이아그램

이 4번째 Platform Preivew에선 JS 엔진을 IE9 으로 옮겼다. 이 변화로 인해 브라우저와 스크립트 엔진과의 소통이 직접적으로 되었으며 실질적인 웹사이트들에서의 성능 향상이 확연하게 들어나게 되었다. 이제 한개의 DOM으로 모든 브라우저의 서브 시스탬들 사이에서 이해하게 되었다. 자바스크립트 또한 말이다. 이 변화는 문서에 대한 일정하며 상호 운용성이 있는 시각을 제공한다. 이 단독의 DOM은 이제 ES5를 기반으로 하며 앞으로 미래를 대비하게 된다.

When programming the IE9 DOM from JavaScript, objects now feel like native ES5 objects because, underneath the covers, they actually are ES5 objects. This approach brings the benefits of ECMAScript5 to the DOM. With the fourth Platform Preview, IE9 becomes the first browser to have a fully discoverable DOM through ES5 reflection features. IE9 is the first browser to apply ES5 bindings to DOM objects, enabling a full Inheritance view of the DOM, and taking advantage of the WebIDL specification as the foundation for this support. Together, these changes provide developers a natural ES5 based programming model. Try some of these enhanced DOM capabilities out for yourself to see how well your browser’s DOM and JavaScript engine are integrated. IE9 will continue to support additional programming languages through the legacy model, but we strongly encourage developers and enterprises to take full advantage of the benefits of JavaScript moving forward.

Platform Preview 는 또한 자바스크립트 엔진 자체를 향상하는데에도 꾸준히 노력중이다. 그 잣대중의 하나가 웹킷 Sunspider 마이크로밴치마크이다. 최근 보여준 결과의 차트이다.

실제적인 html5의 성능은 자바스크립트 엔진 자체 보다는 브라우저 전체의 성능을 보여준다. 이 비디오에서 여러 브라우저들이 html5 canvas를 돌리는 비교를 볼 수 있다. 브라우저들간의 성능의 차이들은 자바스크립트들의 차이와 비교해 볼때 놀랍지 않을 수 없다. (일모리: 너무 많이 차이나서 놀랍다라고..)
우리는 타 브라우저 벤더들이 우리의 리드를 따라 (우리처럼) 성능향상을 위한 설계와 자바스크립트를 통합하는 것을 고려해 보기 바란다.

(일모리: 아 저건… 매번 사파리 새 버전이 나올때마다 스티브 잡스가 보여주던 차트가 아니던가…. 정확히 사파리 바로 앞에 위치해 있다. 보란듯이…)

동일한 마크업 그리고 테스트들

브라우저의 표준 지원의 질과 완전함을 위해서 공식적인 표준안을 채택하였다. 그들의 열리고 전체적인 의견을 수렵하는 방법은 브라우저벤더들과 개발자들 그리고 디자인 프로들을 모아 테스트하는데에 최고의 방법이다.

Platform Preview4 를 통하여 우리는 519개의 새 테스트들을 표준안에 기여하였다. 커뮤니티의 피드백을 기반으로 하여 이전에 넣었던 5개의 테스트들 또한 업데이트 하였다. 이로써 우리가 IE9개발을 하면서 기여한 테스트들의 숫자가 2,138개가 되었다. 우리는 특정 부분에 대한 테스트 피드백을 환영한다. 계속 올바른 W3C working 그룹에 테스트 사례들을 피드백 해 주기 바란다. ES5 테스트 사례 는 마이크로소프트의 Connect 를 통하여 해주기 바란다. 여러분들의 테스트들을 표준 커뮤니티에 알려주는 것도 잊지 말기 바라며 IE 테스트 센터를 통해 여러 테스크 사례들을 볼 수 있다.

이러한 테스트들은 개발자들이 여러 브라우저 테스팅 SUITE 을 통하여 브라우저들이 동일한 잣대 아래 개발되도록 돕는다. 이하의 SUITE은 완성된건 아니지만 같은 마크업의 브라우저들간의 차이점을 볼수 있다.

몇몇 사람들은 특정 테스트나 웹사이트를 표준의 잣대로 생각하며 사용한다. 각각의 사이트들이 다르게 표준을 이해하고 정도 또한 다르게 테스트를 한다. ACID3 는 몇몇 사람들이 기준으로 삼는 것 중의 하나다. 약 12개의 기술들을 100개의 조각들로 나누어 테스트를 한다. IE9의 현제 태스팅 결과이다. 지난번 83에서 이제 95까지 성장했다.

Acid 테스트 95점 표

IE9 가 개발자들이 사용하고 생각하는 표준들을 계속 통합시키면서 ACID3의 점수가 높아지고 있다. 나머지 점수는 2가지의 특정한 SVG 폰트와 SMIL에니메이션의 기술인 아직 변화되고 있는 부분이다.

(일모리 : 이하는 그에 대한 변명아닌 설명)
Support for SVG Fonts in the web development and font communities has been declining for some time. There’s already been discussion without objection of dropping SVG fonts from the Acid3 test. The community has put forth a proposal in the SVG Working Group to give SVG Fonts optional status.
Instead, developers can use the Web Open Font Format (WOFF, supported in IE9 Platform Preview 3 as well as other browsers) for both HTML and SVG content. It works well in conjunction with the CSS3 Fonts module and has broad support from leading font vendors (e.g. here, “a majority of font makers have already settled on WOFF or services like Typekit as their format of choice”). WOFF fonts are a better long-term solution for many reasons discussed previously.
Similarly, support for SMIL animation of SVG in the web development community is far from strong. The leader of the SVG standardization effort wrote that not supporting SMIL in its current state is probably best “since the SVG WG intends to coordinate with the CSS WG to make some changes to animation and to extend filters.” There’s already work started to reconcile CSS3 animations and SVG. Developers interested in animating SVG can use JavaScript, as the samples in the test drive site do today, with consistent results.
(특별히 woff 폰트가 앞으로 더 낫다는 이야기가 눈에 띈다)

이제 베타 버전의 준비

이제 4번째 Platform Preview가 나온만큼 개발자들과 디자이너들, 그리고 파트너들에게 IE9 베타를 슬슬 준비하라고 말하고 싶다.

  • 당신의 웹사이트를 IE9 스텐다드 (표준) 모드로 테스트 하십시오
    HTML5 DOCTYPE 사용하시고 여기 저기 더 자세히
  • 이제 비 IE 브라우저들에게 사용했던 마크업들을 사용해 보십시오
    IE6, 7, 8 마크업을 기반으로 하지 마시고 타 브라우저들에 사용했던 마크업을 기반으로 만들어 보십시오
  • 브라우저 인식기능 보단 기능 인식 기능을 사용하십시오
    이것으로 크로스 브라우저 차이나 기능 서포트를 제어하시기 바랍니다. 브라우저가 바뀌더래도 여러분의 사이트가 작동하게 됩니다.
  • Connect 에 문제들을 리포트 해주십시오
  • IE 9베타 유저들을 고려해주십시오. 혹시나 마크업을 개선하는 것이 너무나도 많은 어려움을 가져온다면 Compatibility View를 고려해주십시오
  • HTML5, CSS3, SVG, DOM, ES5등을 이용 하십시오

이번 Platform Preview4는 베타로 가는길의 중요한 마일스톤이다. ie9 beta 전의 마지막 preview 이기도 하다. IE9의 기반은 이제 거의 완성되었다. 개발자들과 파트너들이 베타를 준비하며 IE9의 새 역량들을 최대한 사용했으면 좋겠다.

Internet Explorer 9 Platform Preview 4 다운로드

* 번역을 마치며 본 몇가지 흥미로운 문구들

“IE9 는 앞으로 HTML5가 웹사이트보다는 기본 어플리케이션인듯한 경험을 전달할 것이라는 전제아래 시작됬다.”

“불행하게도 동일한 SVG를 다르게 표현하는 브라우저들의 차이들을 볼 수 있으며 그것은 브라우저 커뮤니티가 같은 결과물이 나올수 있도록 앞으로 노력해야 하는 것을 보여준다.”

“ECMAScript 를 기반으로 한 브라우저와 스크립트 엔진사이의 shared DOM(DOM을 공용하는) 을 갖게된 최초의 브라우저 이다.”

“우리는 타 브라우저 벤더들이 우리의 리드를 따라 (우리처럼) 성능향상을 위한 설계와 자바스크립트를 통합하는 것을 고려해 보기 바란다.”

“IE9 가 개발자들이 사용하고 생각하는 표준들을 계속 통합시키면서 ACID3의 점수가 높아지고 있다.”