참고로 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에 대한 기술적인 문제점도 많다. 특별히 댓글부분에 대한 해석을 되도록이면 하지 않았다. 우리에게도 이제 이러한 글들에 대한 바른 해석과 토론이 이루어 질 수 있는 능력이 충분히 생겼다고 생각한다.

alt와 title의 사용 그 이상의 목적이나 실용적인 사용에 대한 실난한 분석과 비판인데요.
나름 저자의 정보전달을 위하여 의역한 부분도 더러 있습니다만 흥미로운 현실적인 발상과 화두라서 올려봅니다. 이미지는 이미지를 둘러싼 컨텐츠에 의해 이미지가 설명되어진다라는 가정아래 펼치는 토론이니 즐겁게 읽으시기 바랍니다.

I have translated the post “Should photos in photo-sharing sites have alternative text?” from “Rebuilding the Web” written by Vlad Alexander.

우리는 사진 공유 사이트의 사진들이 대체 텍스트 곧 alt 값을 갖고 있어야 접근성이 있다고 너무나도 쉽게 이야기한다. 컨텐츠 중심의 웹페이지라는 공간에서 대체 텍스트가 이미지의 접근성을 결정한다는 가정을 내리며 말이다. 그렇다면 기타 다른 플랫폼의 사진들에 대하여도 대체 텍스트를 쓰는건 어떠한가? 아니면 이제 대체 텍스트 ALT 가 사진공유 사이트의 접근성에 최선이라는 가정에 대하여 토론을 벌여야 하는 시간이 온것인가?

사진 공유 사이트들이 단순히 이미지들의 파일 시스탬인가?

디지털 카메라에서 사진을 구겅할때 이미지들에 대한 대체 텍스트는 없다. 윈도우 익스플로러나 파인더를 이용하여 하드드라이브에 있는 사진들을 볼 때에도 대체 텍스트는 없다. FTP 를 통하여 웹서버의 사진들을 볼때에도 마찬가지 이다. 그러나 웹 인터페이스를 통한 사진 공유시에는 대체 텍스트를 당연시 하게 기대한다. 왜일까?

대체 텍스트가 이미지의 접근성을 결정할까?

그렇지 않다. 대체 텍스트는 이미지가 보이지 않을시에 이미지를 담고 있는 컨텐츠를 이해하도록 돕도록 한다. 만약 대체 텍스트가 이미지의 접근성을 결정한다면 이미지 자체에 담긴 대체 텍스트 만으로도 이미지를 정확히 설명할수 있어야 한다. 많은 이미지들은 가능하지만 전부가 가능한건 아니다. 이하의 예제를 보면 단순히 대체 텍스트를 읽는다고해서 이미지를 설명하지 못함을 볼수 있다.

<p>나는 당신을 <img src="심장.gif" alt="사랑" />해! </p>

대신에 대체 텍스트의 실제적인 기능은 이미지가 보이지 않을시에 주위의 컨텐츠와 함께 협력해서 해당 컨텐츠를 이해하도록 돕는 (고로 접근성을 높이는) 역할을 하게 되는 것이다.

Context(문맥) 는 이미지를 감싸는 컨텐츠를 말하며 이미지가 어떠한 대체 텍스트를 가져야 하는지 결정하게 된다. 다른말로 하면 ‘올바른‘ 대체 텍스트는 이미지를 감싸고 있는 컨텐츠 안에서만 그 이미지를 대체 할수 있다는 것이다.

예를들어

위의 이미지의 컨텐츠가 ‘내 강아지는 돼지같다’ 라고 한다면 이 이미지에 대한 올바른 대체 텍스트는 “이 개는 코가 돼지코 같고 덩치도 크고 털색깔이 돼지색이다” 라고 할수 있을 것이다.
또, 컨텐츠가 “내 강아지는 맨날 공을 잃어버린다” 이라면 대체 텍스트는 “강아지가 바닷가에서 공을 찾고 있는 중이다” 라고 대체 텍스트를 쓸 것이다.

그러나 사진 공유 사이트에선 이러한 이미지의 컨텐츠가 존재하지 않는다. 이미지들이 단순히 슬라이드쇼 처럼 정리되어 있을 뿐이다. 어떻게 하면 올바른 대체 텍스트를 사용할수 있을까?

어떻게 하면 고려할 문맥이 제공되지 않는 상태에서 컨텐츠를 설명할수 있을까?

사진 공유 사이트에서 문자적인 컨텐츠 없이 대체 텍스트를 생산해 내는 것이 거의 불가능한 것처럼 보인다. 누군가는 할수 있다고 나설지 모르지만 현실적인 대체 텍스트의 제한가운데 직면 할수 밖에 없다. 이하의 사진 한장을 보자

“Vlad Alexnader 가 브리티시 콜롬비아 벤쿠버의 잉글리쉬베이에서 2010년 2월에 우리 강아지 길동이를 찍은 사진” 이라고 나름 유용하게 대체 텍스트를 사용 할수 있을것이다. 하지만 너무나 많은 불필요한 정보 아닌가? 왜냐하면 대체 텍스트는 유저가 이미지를 보고 얻게되는 정보와 저자가 의도하는 정보전달이 동일한 결과를 갖게하는 데에 있기 때문이다. 단순히 이미지를 보고 얻게되는 것과 위의 대체텍스트를 읽고 얻게되는 것이 동일할 확률은 희박하다.

사진 공유 사이트의 사진들이 단순히 눈을 즐겁게 하는 오락적인 부분인가 아니면 컨텐츠 인가?

사진 공유 사이트들에 있는 사진들의 목적은 무엇인가? 눈을 즐겁게 하는 목적으로 놓아져 있는 것인가 아니면 일정한 의미를 전달하고 있는가? 어떤 이들에게는 사진들이 의미를 갖을 것이다. 하지만 일반 웹 유저들에게도 동일하게 의미를 갖는가? 평범한 웹 유저들에게는 사진속의 장소나 인물들에 관심도 없을 것이며 단순히 즐기기 위한 브라우징의 한 부분일 뿐이다.

하지만 만약 시각 장애자들에게 접근이 필요한 사진들이라면 어떻게 그 의미전달을 할수 있겠는가?

문제는 사진 공유 사이트의 사진들의 대체 텍스트의 문제접을 단순히 접근성의 이슈로 넘겨버리는 데에 있다. 그리고 그러한 문제가 접근성으로 넘겨진데에는 HTML5 팀에서 alt속성을 옵션적으로 선택할수 있도록 하여 사진 공유 사이트들이 html5에 유효하도록 해버린 이유가 크다고 할수 있다.

사실 이것은 접근성의 문제가 아니다. 오히려 사용성에 대한 우리 모두에게 영향을 주는 이슈이다. 사진 공유사이트에 오는 ‘모든 방문자’가 단순히 이미지만을 보았을때 얻는 정보 이상을 얻기를 원한다. 예를들어 “회사안에서 포즈를 잡은 3명” 의 사진을 보고 얻는 정보가 무엇일꺼라고 생각하는가. 정말 원하는 정보는 “앨리스(왼쪽), 빌(중간), 캐티(오른쪽)가 2008년 12월 사무실 파티에서 찍은 사진” 일 것이다. 하지만 그 정보는 대체 텍스트 (컨텐츠)가 아니다. 이것은 보통 사이트에서 말하는 “사진설명”, 혹은 “자막” 들이다. 차라리 대체 텍스트는 비어 놓아야 한다.

<div>
<img src="123.jpg" alt="" />
<p>Alice (left), Bill (center) and Kathy (right) at office party in December 2008.</p>
</div>

결론

사진 공유 사이트들은 대체 텍스트를 비워 두는 것이 낫다. 오히려 유저들에게 사진 설명이나 자막을 넣는것을 더 권장해야 하며 모두에게 보여야 한다.

더 멀리 본다면 앞으로 새 기술들이 사진을 찍는 그 자리에서 일정한 정보들이 입력되도록 하는 것도 좋은 방법이다. 목소리입력이나 GPS 등의 기술들이 접목되는 것? 그리하여 입력된 정보들은 사진이 어디로 가던지 사진 공유 사이트더래도 공유되며 보여지게 되도록 말이다.

최근 케나다 아이폰 전화 플렌의 개선을 촉구하는 서명운동으로 스티브잡스에게 반대서명을 보낸일이 있었지만 아무튼 개개인의 서명과 함께 목소리를 높이는 좋은 시도 같습니다. 저는 미국인지라 어떻게 동참할수 있는건지는 모르겠지만 아무튼, 좋은 결과 있기를 바래봅니다.

요즘 웹표준이 부각되면서 사내에서 표준 세미나도 하시고 어렵게 어렵게 표준에 대해 노력을 힘쓰시는 분들에게 멋진 박수를 보내드리고 싶습니다. 쉽지 않은일 같지만 지금까지 변화되어 온걸 보면 그다지 먼 미래 같지는 않습니다. 화이팅을 외치면서, 이번에 웹표준 대회가 열린다고 해서 오랜만에 포스팅을 올립니다.

누군가가 시켜서 만드는 웹, 누구를 위해 만드는 것인지 알 수 없었던 웹은 이제 우리 자신과 보다 많은 사람들을 위해 개선되어 나가야 합니다. 더 많은 사람들이 더 좋은 방법을 이용하여 웹 사이트를 제작하고 사용할 수 있어야 하고, 시대가 이런 점을 이미 요구하기 시작했습니다. 이제는 가르치고 배우는 과정을 넘어 더 많은 사람이 보다 손 쉽게 이용할 수 있는 웹 표준으로 나아가야 할 것입니다. ‘규칙과 창조의 만남’이라는 슬로건처럼 웹 표준이라는 규칙을 지킴으로써 사이트가 얼마나 창조적으로 유연하게, 얼마나 더 편리해질 수 있는지를 많은 사람들이 알 수 있게 될 것입니다.

CSS Design Korea에서 주최하고, Hosting.kr, 에이콘출판사, 디지털미디어리서치가 후원하는 이번 대회는 2008년 5 월 1일부터 약 한달간 진행되며 2008년 6월 예정인 세번째 웹 표준의 날에 그 대미를 볼 수 있게 됩니다. 우리가 원하는, 모두를 위한 웹을 만들어가려는 이번 행사에 많은 분들의 참여를 기대합니다.

이번 웹표준 경진대회는 웹표준을 널리 알리고 웹표준의 멋진 프로젝트들이 여기저기 튀어나올수 있는 기회라고 생각됩니다. 많은 참여가 있으면 좋겠고 아마도 많은 학생들이 참여하지 않을까 하는 짐작을 해봅니다. 실무에서 뛰시는 분들은 시간내기가 쉽지 않겠죠? (를 뛰어넘어 밤새 제작하시는 분들이 머리속에 상상이 됩니다만…)

질문은 언제나처럼 CSS Design Korea 에 그리고 더 자세한 정보는 웹표준 경진대회 공식 사이트를 참고하시면 되겠습니다. 화이팅!

Translated with the permission of A List Apart Magazine and the author[s].
이하의 글은 A List Apart Magazine과 저자의 허락아래 번역되었습니다.

“Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8″

성장은 언제나 진통이 따른다. 브라우저도 개발자들이 특정 브라우저나 툴에 맞추게 되면 유저들이 진통을 격게된다. 새로운 브라우저 버전들이 공개되고 몇개의 버그들이나 스팩의 약간의 변화에 사이트들은 깨지게 되고 상사나 유저들이 실망하게 되는 것이다.

몇시간을 들여 왜 사이트가 깨졌는지 설명할수 있겠지만 아예 처음부터 깨지지 않는다면 더 낫지 않겠는가?

약간의 배경

CSS의 상당한 업글을 보여주었던 IE7 의 공개에 힘입어 IE팀은 완전히 새로운 렌더링을 탑제한 IE8(CSS2.1 을 최대한 따른) 개발을 시작했다. 그리고 Acid2 렌더링 테스트를 완벽하게 통과하는 기염을 토해내었다. 이것은 IE가 곧 generated content 와 data URL 을 지원한다는 것 뿐만이 아니라 hasLayout 이 완전히 사라진다는 것을 의미한다. Acid2 를 통과한 사파리나 iCab, Konqueror 그리고 오페라와 렌더링에 있어서 동격을 이룬다고 할수 있다. (Firefox3는 Acid2를 통과했지만 아직 출시되지 않았다.)

이번 새 엔진을 개발하는 동안 IE팀은 IE7 을 공개하면서 받은 여러 비판을 잊지 않았다. 몇몇 표준 구루들과 Microsoft의 몇몇 팬들까지도 IE7 이 버그나 CSS 지원에 있어서 충분하지 못했다고 생각했었고 상당수의 개발자들은 IE7 에서 깨지는 사이트들을 바라보며 불신에 속삭였다. 이에 Roger Johanssen은 자신의 블로그에 IE가 깨지는 3가지의 이유를 나열했지만 IE팀은 4번째 이유까지 발견했다. CSS 레이아웃을 가능케 하는 중요 부분인 Doctype 이 호환성을 지키기 위해서 너무나 부족함을 말이다.

DOCTYPE 스위치는 깨졌다

1998년, Todd Fahrner 가 개발자를 위한 모드와 그외의 사람들을 위한 2개의 랜더링 모드를 가능케 하도록 제안한다. 컨셉은 간단했다. 유저 에이전트(ex 브라우저) 가 표준에 적합한 DOCTYPE 을 포함한다면 제작자가 표준작업을 제대로 알고 한 문서라는 것을 가정하고 “표준”데로(W3C 박스모델을 사용하여) 렌더링을 하는 것이었다. 반대로 DOCTYPE이 명시되지 않았을 경우, “quirks” 쿽스 모드로 인식하여IE5.x/Windows 의 비표준 박스모델로 렌더링 되는 것이다.

이 컨셉은 2년후 IE5/Mac 브라우저에 처음 적용되어 타 브라우저들에 빠르게 퍼져갔다. 표준을 조금이라도 인식하는 개발자들은 이미 ‘validation’ 의 목적으로DOCTYPE 을 삽입하여 사용하고 있었으며 스펙에 따라 렌더링하는 데에는 그 이상을 따르지 않았다. 표준을 상관치 않는 개발자들에겐 DOCTYPE 을 상관치 혹은 몰랐기에 문서가 특별한 모드로 렌더링 되고 있었다.

불행하게도 다음의 두 중요한 사실이 DOCTYPE 이 표준 모드로의 스위치로써 지탱되지 못하도록 하였다.

1. A List Apart 이나 Web Standards Project 등을 통하여 표준을 자각한 개발자들은 완전한 DOCTYPE을 슬슬 삽입하게 되었고
2. IE6가 6년간 렌더링에 변동이 없었으므로 많은 개발자들이 자신들이 맞다고 생각 하게 되었다.

이 두 상황이 Doctype 스위치를 악화한 치명적인 이유는 개발자들이 Doctype을 맞게 쓰는 것이 표준을 올바로 이해하고 렌더링을 제대로 하는 것일 꺼라는 ‘가정’을 했기 때문이다. 왜 실패했는지 어떻게 아느냐고 묻는다면, 바로 IE7이 공개되었을때, 사이트들이 깨진것을 보면 알수 있다.

물론 Roger가 지적했듯이 IE6에 국한된 CSS 핵을 사용했기 때문이기도 하다. 하지만 대부분은 IE6 에서만 사이트 렌더링을 확인한 이유이거나 혹은 가장 많이 사용되는 대표적인 IE6에서만 잘 보여진다면 괜찮다고 생각했기 때문이다. IE6의 불완전함은 문서로 잘 나타나져 있었으니 개발자들이 좀 알고 있었어야 한다고 할지 모르지만 많은 개발자들은 “표준 모드” 의 옵션이 주어지지 않았거나 아예 그 존재조차 모르고 있었다.

IE의 플랫폼아키택인 Christ Wilson 은 IE의 개발의 핵심은 웹을 깨트리지 않는 것이라고 자주 이야기 하곤 했다. 하지만 슬프게도 IE7 은 많은 이들에게 바로 그것을 행해버리고 말았다. 똑같은 실패를 거듭하지 않고자 Microsoft는 Web Stands Project (저자 또한 멤버이다) 와 여러 표준을 인식한 개발자들에게 앞으로 개발자들이 올바른 표준을 준수할수 있도록 도울수 있는 방법에 대해 도움을 요청했다. 목표는 DOCTYPE 스위치 보다 더 뚜렷하며 IE뿐만이 아닌 여러 브라우저들에서도 적용이 가능한 ‘방법’ 을 찾는 것이었다.

완벽을 바라는 미래

작년 SXSW 에서 나는 운좋게도 뉴욕 공립 도서관의 Carrie Bickner 가 진행하는 토론회를 보게되었다. (Carrie Bickner, A List Apart의 Jefferey Zeldman의 부인) “디지털 유산과 Individual Collector 의 보호” 라는 주제 아래 도서관들과 개개인들이 디지털 아카이브를 유지하며 격는 문제점을 토론하고 있었는데, 대부분의 문제들은 꾸준히 업그레이드 되고 있는 파일 포멧들과 어플리케이션들에서 비롯된 것들이었다. Microsoft 오피스 2007을 예로 들면, Word1.0 버전의 문서를 그 당시 의도 했던 것처럼 렌더링, 보여주지 못한다는 것이다. 이 토론회는 나로 하여금 지금까지 웹이 얼마나 변해왔으며 앞으로 웹이 진화하며 얼마나 변화할 것인가에 대해 생각하게 하였다.

웹표준의 지지자의 한사람으로써 브라우저들의 꾸준한 발전과 함께 표준 이행을 꾸준히 개선하기를 원하지만 힘들게 만들어온 웹(테이블 레이아웃 조차도)을 보존하는 것 또한 중요하다고 생각한다. 아직까지는 Doctype 스위치가 괜찮게 돌아가니 그다지 “뒤로돌리는것” 이 어렵지 않겠지만 IE6 의 “표준” 에 맞춘 사이트는 어찌할 것인가? 많은 경우 IE7 이 제대로 렌더링 하지 못한다는걸 우리는 이미 잘 알고 있다. 그렇다면 저자가 원한데로 페이지를 보기위해서는 IE6 브라우저를 언제나 하나씩 가지고 있어야 한다는 말인가? 바로 그것이 수많은 도서관들이 옛 파일들을 보기 위해서, 보존하기 위해서 택한 방법이다. IE8이 점점 다가 오고 있는 가운데 IE7의 렌더링 엔진에 맞춘 문서들이 갖게될 문제들은 앞의 도서관들과 별반 다를 것이 없다. 과연 무엇이 해답인 것인가?

브라우저 버전에 맞추기

이상적인 세상에선 모든 스펙들이 시작에서 부터 유저에이전트들의 해석, 이행까지 완벽할것이다. 그보다 약간 덜 이상적인 버전의 세상에선 브라우저 밴더들이 꾸준히 업데이트 되는 표준들을 즉시 유저에이전트(브라우저)에 적용하여 유저들이 손가락 까딱 하지 않고 최신 버전의 브라우저를 사용 가능토록 할 것이다. 우리 개발자들 또한 최신의, 최고의 기술들을 사용하여 이전 버전 호환성의 걱정 없이 사이트나 어플들을 개발 할 것이다. 하지만 모두가 알다시피 우리의 현실은 그정도 레벨의 완벽에도 가깝지 않다.

표준은 힘들게 개발되고 발전하여 가끔은 몇년씩 걸려 “권고안” 에 상태에 이른다. 브라우저 공개의 사이클은 상품개발이나 마케팅 (보안, 기능 속도등) 과 긴밀하게 연관되어 벤더들이 표준에 직접 참여함에도 불구하고 표준 스펙의 준수는 먼 이야기가 되기 십상이다. 그리고 유저들은 특히 공공기관이나 회사들은 브라우저 업그래이드가 절대 빠르지 않다.

이 모든 요인들은 우리 웹개발자들을 사이트를 제작함에 있어서 곤란하게 한다. 우리가 원하는데로 브라우저가 보여준다는 보장이 어디있단 말인가?

CSS2.1이나 JS1.5 등의 언어의 버전을 명시하는 방법도 있긴 하다. 하지만 불행하게도 브라우저 벤더들은 몇몇 부분들의 스펙들을 적용하며 브라우저들 간의 해석이 다르기도 하니 두개의 동급의 브라우저들 에서 같은 CSS 인데도 완전히 다른 렌더링을 보여주기도 하며 같은 컨트롤이지만 완전히 다른 이벤트를 연출하기도 한다.

이러한 상황 가운데 우리 개발자들에게 주어지는 게런티, 보장, 5년 후나 지금이나 똑같이 해석될수 있는 옵션은 한가지 밖에 없다. 개발 배경이 된 브라우저들 리스트를 명시하게 한 후 해당 브라우저들을 이전 버전들도 지원케 하여 개발자가 원래 계획했던 모습들이 현재 뿐 아니라 미래에도 렌더링 되도록 하는 것이다.

이것이 바로 우리 그룹이 IE8에 제안하기로 결정한 것이며 타 브라우저들에도 적용되기를 바라는 것이다.

syntax 를 간편하게

이 “버전 지정”을 개발자들이 브라우저에 적용함에 있어서 중요하다 생각했던 부분중의 하나는 하드코딩이나 프로그램에 사용함을 쉽게 적응 할수 있도록 하는 것이었다. Conditional 코멘트나 XML 프롤로그, 혹은 HTML 프로필 형식등의 여러 syntax 옵션들을 고려해 보았고 그중 META 메타 엘리먼트 만큼 역할을 잘 수행하는 것이 없었다.

간단한 meta 선언을 삽입하여 우리는 IE8 이 어떠한 렌더링 엔진을 사용하는지 지정할수가 있다. 예를들어 이것을 head 부분에 삽입하면

<meta http-equiv="X-UA-Compatible" content="IE=8" />

IE8에서 새 “Standard Mode”를 사용하여 렌더링 하게 된다. 이 방법은 쉽게 다른 브라우저들도 포함할 수 있다.

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

이 지정법을 쉽게 설명하자면 이 meta 엘리먼트를 사용을 character 인코딩을 지정해 주는것과 같은 방식이다. 이 “버전지정”이 작동하기 위해서는 meta 엘리먼트가 head안에 최대한 상위에 위치해야 하고 타 메타 엘리먼트나 타이틀 엘리먼트가 상위에 위치할수 있으나 타 엘리먼트들 보다 아래에 위치하면 안된다.

요목조목 살펴 보신 분들은 HTTP-equiv 형을 사용한것을 아셨을 것이다. 이 뜻은 서버쪽 해더에도 다음의 삽입시에 같은 효과를 볼수 있다는 것이다.

X-UA-Compatible: IE=8;FF=3;OtherUA=4

또한 함께 사용할수도 있다. 예를들어 header 방법으로 기본락을 전체 사이트에 적용시킨 후에 각각의 필요한 페이지에 meta 엘리먼트를 사용하여 적용 시키는 것이다.

Progressive enhancement은 어디로?

특정 브라우저 버전에 지정하는 “버전지정”은 미래까지도 확실한 사이트 렌더링의 보장이 있지만 그렇다면 progressive enhancement(1)의 콘셉을 깨뜨리는 것일까? 앞으로 우리가 사이트를 만드는 방식을 바꿔야 하는 것일까? 최신 CSS 속성들이 유효할때 즉시 사용할수 있는 것인가 말이다. 이 질문들은 우리가 처음 “버전명시” 를 논의할때 갖고 있었던 많은 질문들 이었다.

예를들어 IE8이 generated content(2) 을 지원하지 않는다고 한다고 가정한 후 (Acid2를 통과한만큼 지원하지만 그저 예를 든것임) IE8을 지정하여 generated content 를 사용한다면 IE외의 타 최신 브라우저들에서는 generated content가 보여질것이고 IE9가 generated content를 지원하더래도 사이트는 IE8에 지정되어 있기에 볼수 없을 것이다. 이 사이트에 “지정” 되어 있는 정보를 IE9로 업데이트 해야 비로소 generated content를 볼수 있는 것인데, 이것은 progressive enhancement의 코어 컨셉을 역행 하는 것이다.

이 progressive enhancement 부분을 포기해야 한다는 것이 상당한 고통인만큼 이 지침은 어찌보면 public-facing 임을 감안할때 최선일지도 모른다. 앞으로 브라우저들이 어떻게 작동할 것인지에 대한 “가정”을 내리면 안되기 때문이다. IE9로의 변화가 조금이라도 사이트의 레이아웃을 깨뜨리거나 스크립트의 지침의 해석을 바꾸게 된다면 유저들에게도 재난일 뿐 아니라 새 브라우저가 나오기전에 잘 보이던 상태로 돌리기 위하여 개발팀 또한 고생해야 할것이다.(이것이 현재 웹의 상태이기도 하다) “버전지정”은 개발팀이 원할때, 새 브라우저에 맞추어야 겠다고 결정을 내렸을때, 특히 새 브라우저 버전에 맞출 시간을 우리 팀이 정하여 원하는 만큼의 시간을 맞추고(새 브라우저 출시 시간에 맞추지 않고) 작업에 착수할수 있다.

그렇다면 “버전지정”은 progressive enhancement의 끝을 말하는 걸까? 현재로써는 no, 아니다. 일단 “버전지정”이 포함되지 않은 버전들의 브라우저들을 앞으로 몇년간 써야 하고 progressive enhancement은 여러 레벨의 CSS와 JS 를 지원하는데 필요한 방법이기 때문이다. 더 나아가 conditional 코멘트를 사용하여 스타일을 구현하고 스크립트를 덧붙여 IE 브라우저들을 사용하는 것을 몇년간 더 해야하기 때문이며 마지막으로 Progressive enhancement 테크닉을 사용한 JS 는 새 브라우저를 준비하는데에 재코딩의 시간을 줄여주기 때문이다.

보너스: “edge”

위험을 감수하며 무모함을 즐기는 이들을 위하여 IE는 “edge” 라는 값을 제공하기로 했다.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

이 옵션은 권장하지 않으며 사이트를 가장 최신의 IE브라우저로 렌더링을 지정하는 방법이다. IE=1000 이라는 편법을 써서 최신 IE 브라우저를 지정 하는 것 보다는 깨끗한 방법이지 않은가? 하지만 실험용 사이트에 적용 하는것 말고는 edge값을 적용 하는 것은 그리 실용적이지 않을 것이다. 이유는 Eric Meyer 라고 해도(렌더링의 지존) 새 브라우저가 가지고 올 레이아웃이나 스크립트 버그들을 예상할수 없기 때문이다.

미래의 희망

오랫동안 우리 디자이너들과 개발자들은 사이트를 제대로 출력이 가능한 신뢰할수 있는 방법을 고대하고 있었다. 크로스 플랫폼이 가능한 스타일과 스크립트를 짜야하는 두통에다 새 브라우저의 출시와 함께 손도 대 보지 못한곳이 깨지는 아픔을 견뎌야 하고 우리의 클라이언트들과 보스, 그리고 유저들에게 예상치 못한 곳이 깨지는 원인을 설명하는것이 절대 즐겁지도 않다. 하지만 IE8 의 버전지정의 소개와 함께 터널끝에 희망의 빛이 보인다. 나는 다함께 타 브라우저 벤더들도 마이크로소프트와 뜻을 같이 하여 이 기능을 적용했으면 하는 바램이다.

1. Progressive Enhancement – 기본 컨텐츠와 기본 기능들이 모든 브라우저들과 모든 이들에게 접근이 가능케 하며 접근성, 시멘틱 마크업 그리고 외부 css 와 스크립트를 강조하는 컨셉이다.
2. Generated Content – 생성된 컨텐츠. 예를들어 :before나 :after 를 사용하여 컨텐츠를 브라우저가 직접 생산하는 것을 일컫는다.

바락 오바마는 흑인 대통령 후보로써의 헤드라인 보다는 ‘변화’의 바람을 선전하는 케네디 스타일의 대통령 후보로써 더욱 명성을 날리고 있습니다. 최근 그의 ‘변화’의 슬로건에 맞게 2007년 말 그의 웹사이트가 업데이트 됬는데요 리포지셔닝이 아닌 완전한 리디자인으로 상당한 호응을 받고 있습니다.

깔끔한 디자인과 인지하기 쉬운 네비게이션 그에 걸맞는 정리된 컨텐츠가 돋보입니다. 특히나 Information Architecture 부분이 맘에 듭니다. 과감히 디테일을 죽이고 불필요한 부가설명 보다는 짧고 명료한 아이콘과 단어들로 표현하며 어느정도의 미니멀리즘 또한 볼수 있습니다. 물론 아쉬운 부분들도 많습니다. 대통령 선거 후보인 만큼 최대한 많은 이들과 다양한 환경의 이들에게 접근해야 함에 있어서 많은 자바스크립트와 약간은 무거운 디자인 이미지들로 겨냥한 방문자들은 어느정도의 인터넷 속도와 컴퓨터 환경을 갖추고 있는 중산층 이상으로 짐작할수가 있습니다. 상당한 발전을 한 인터넷 환경과 컴퓨터들을 감안 하여 어느정도의 과감한 결단을 내린 것으로 볼수도 있겠지만 충분한 리서치를 행한 후에 결정한 것이라 짐작하고 GOOD LUCK 을 외칠수 밖에요. 전화 모뎀이나 오래된 컴퓨터를 사용하는 이들에게는 버겨운 웹서핑일수 있겠습니다. 잠깐 여담을 하자면 타 사이트들에서 요즘 자주 눈에 띄는 IE7을 위한 핵이나 코드들을 여기서도 볼수 있군요. 접근성을 위한

<div style="display:none"><a href="#featurecontent">Skip To Content</a></div> 
<div style="display:none"><a href="#mainnav">Skip To Navigation</a></div>

코드도 보이고 말이죠. 둘러보면 볼만한 흥미로운것들이 좀 있네요.

오바마가 온힘을 다해 경쟁하고 있는 후보가 있죠. 바로 전 대통령 빌클린턴의 퍼스트 레이디 힐러리 클린턴 입니다. 그녀의 웹사이트 또한 그리 나쁘지 않은 디자인과 접근성을 갖추고 있는데요. 어찌보면 오바마의 예전 사이트와 그리 다르지 않은듯 합니다. 아이콘의 재구성과 베너들을 통일성 있게 줄이고 약간만 첫페이지 컨텐츠를 스크롤 다운 할수 있도록 나열 했다면 더욱 업그레이드된 사이트가 되지 않았을지.

그러고 보니 타 후보들의 사이트도 대충 비슷하군요.

누구나 지금즘 이면 ‘그럼 우리나라 대통령 후보들의 사이트는?’ 이라는 생각이 드셨을듯 합니다. 특별히 비방하고 싶은 후보나 사이트는 없지만 여러 후보들의 사이트를 볼아보며 아쉬운 부분이 많습니다. 뭐 힐러리나 타 미국 후보들 보다 좋은면도 많지만 솔직히 여러 해외의 ‘오늘의 플래쉬 사이트’에서 자주 보이는 한국 인터엑티브 디자이너들 개발자들을 보며 기술이 딸린다 라고 말하고 싶지 않군요. 플래쉬 남용이다 테이블 남용이다 크로스브라우징이 아니다 등의 이야기가 아닙니다. 하지만 전체적으로 복잡한듯 뒤엉킨 정보 나열을 보며 하나의 정보 사이트 라기 보다는 광고 사이트를 보는듯한 기분이었습니다. 한국적인 인터넷 문화에서 비롯된 디자인과 정보나열이긴 하지만 제가 기대를 많이 하는건지는 몰라도 (매일 듣던 인터넷 강국이라 최고만 바라는 걸까요) 더 잘할수 있지 않을까 라는 바램입니다. 지금도 괜찮지만 WHY NOT MORE? 대통령 후보들 사이트를 접속하면 ‘우와~’ 라고 감탄하고 싶은건 저 뿐인가요..

이명박 : www.mbplaza.net
정동영 : www.cdy21.net
문국현 : www.moon21.kr
이회창 : www.leehc.org
권영길 : www.ghil.net

물론…. 익스플로러로 접속하시기 바랍니다…
그러고보니 각 후보들께서 싸이월드와 네이버 블로그 다음 블로그를 갖고 계시는군요;; 워우