1. 게시판 인터페이스의 웹 접근성.
   1. 숨은 레이어를 가능한 사용하지 않기.
   2. HTML 문법으로 수행 가능한 동작을 Javascript로 처리하지 않기.
   3. Form 전송기능을 Javascript로 처리하지 않기.
   4. 숨은 제목(h*, caption, legend)을 제공하기.
   5. label이 생략된 input은 title 속성을 사용하기.
   6. Permalink 제공하기.
   7. ‘리치 텍스트 에디터’를 제공할 때 ‘플레인 텍스트 에디터’를 함께 제공하기.
   8. 사용자의 실수(세션만료, 로그아웃, 새로고침, 뒤로가기)를 만회할 수 있는 기회 제공하기.
   9. CSS를 지원하지 않는 Form Control요소를 장식하지 않기.
2. 게시판 인터페이스의 CSS 활용 기교.
   1. 가변폭 텍스트와 줄바꿈 처리에 관한 테이블 표현 기법.
   2. 숨은 제목 제공 기법.
   3. 텍스트 버튼 만들기.

1.1. 숨은 레이어를 가능한 사용하지 않기.

숨은 레이어란 display:none을 이용하여 일부 콘텐츠를 화면에 출력하지 않고 숨겨두는 형태를 말합니다. 이 방법이 문제가 되는 이유는 현재 국산 화면낭독기가 display:none 되어있는 콘텐츠를 모두 읽어내기 때문입니다. 현재 국내에서 50%이상의 점유율을 보이고 있는 화면낭독기 ‘센스리더’는 display:none을 읽지 않아야 한다는 웹 개발자들의 충고를 일부 수용하여 환경설정에서 display:none을 읽지 않을 수 있도록 조치하였지만 기본값은 여전히 display:none을 읽도록 설계되어 있습니다. 시각장애인들이 상황에 맞지 않는(또는 불필요한) 콘텐츠를 건너 뛰는데 많은 시간을 소비한다는 점을 감안할 때 숨은 레이어는 되도록 자제하는 것이 좋다는 의견 입니다. CSS의 모든 속성에는 각각의 속성들을 여러 종류의 미디어들(시각장치, 음성장치, 점자장치…)이 어떻게 받아들여야 하는지가 정의되어 있고 display 속성은 모든 장치에서 이 속성을 받아들이도록 명시되어 있습니다. 참조 CSS2 display, CSS2 Media Group.

1.2. HTML 문법으로 수행 가능한 동작을 Javascript로 처리하지 않기.

a 엘리먼트에 유효하지 않은 href 값을 사용하고 Javascript에 의존하여 페이지 이동을 수행하는 경우가 종종 발견 됩니다. Javascript를 지원하지 않는 브라우저  환경(PC, Mobile)에서는 링크에 접근할 수 없으므로 Javascript는 사용하지 않거나 겸손하게(Javascript를 지원하지 않는 환경에서도 기능할 수 있도록 Javascript 기능은 HTML으로부터 독립적으로 분리) 설계하여야 합니다.

1.3. Form 전송기능을 Javascript로 처리하지 않기.

<input type="submit" value="확인" />, <input type="image" alt="확인" /> 엘리먼트를 사용하면 Javascript 없이도 Form 전송 기능을 수행할 수 있습니다. 그러나 이때 <a href="#" onclick=""><img /></a> 형태로 마크업 한 다음 Form 전송 기능을 Javascript로 처리하는 경우도 자주 발견 됩니다. 이런 경우도 HTML이 해야 할 일을 Javascript가 가로챈 경우로써 Javascript를 지원하지 않는 사용자 환경에서 작동하지 않습니다. 또한 화면낭독기는 HTML 마크업 기반으로 웹 문서를 읽어내기 때문에 Form 전송 버튼을 <a> 엘리먼트로 마크업 한 경우 해당 버튼을 ‘~링크’라고 읽어주게 되고 이 버튼이 진짜 Form 전송 버튼인지 확신할 수 없게 되는 문제가 있습니다. <input type="submit" value="확인" /> 형식으로 올바르게 마크업 하는 경우 화면낭독기는 ‘확인 전송 버튼’ 이라고 읽게 됩니다. <input type="image" alt="확인" /> 형식으로 마크업 하는 경우 ‘확인 이미지 버튼’ 이라고 읽어주게 됩니다.

1.4. 숨은 제목(h*, caption, legend)을 제공하기.

시각이 있는 사용자들은 전체적인 내용을 한눈에 훑어내는 능력이 있기 때문에 각각의 콘텐츠 덩어리에 소제목을 부여하지 않더라도 어떤 내용인지 파악한 다음 빠르게 무시하거나 즉시 읽기를 시작할 수 있습니다. 그러나 시각이 없는 사용자들은 소제목을 생략하면 콘텐츠 본문을 읽어보아야만 해당 항목이 무엇을 의미하는지 추측할 수 있게 됩니다. 소제목을 표현하는 엘리먼트로는 h*, caption,  legend 등이 있는데 시각이 있는 사람들에게는 보이지 않고 시각이 없는 사람들만 인지할 수 있도록 설계할 수 있습니다. 이 기법은 이 글의 본문 ‘숨은 제목 제공 기법‘에 소개되어 있습니다.

1.5. label이 생략된 input은 title 속성을 사용하기.

서식 제어 요소들(input, textarea…)을 label 엘리먼트와 명시적으로 짝지어 주어야 한다는 지침과 label 엘리먼트의 적용 문법은 익히 알고 계시리라 생각 됩니다. 그러나 때로는 너무도 익숙한 인터페이스이기 때문에 label을 생략하는 것이 관행처럼 굳어버린 서식 제어 요소도 있고 label을 넣을 수 없는 경우도 있습니다. ‘검색’ 필드에서 label 엘리먼트를 사용하지 않는것이 label을 관행처럼 생략하는 대표적인 예 입니다. 하나의 인풋을 2~3개로 나누어 놓는 형태(주민등록번호, 전화번호, 우편번호…)는 각각의 인풋에 label 엘리먼트를 모두 연결해 줄 수 없는 사례에 해당 됩니다. 이런 경우 억지로 label 엘리먼트를 사용할 필요가 없습니다. 서식 제어 요소에 title 속성을 사용해도 동일한 효과를 얻을 수 있습니다. <input type="text" title="주민번호 뒷자리" /> 라고 마크업 하는 경우 화면낭독기는 label 대신 title 속성에 적힌 문자를 읽어주게 됩니다. 그러나 label 텍스트가 존재할 때에는 되도록 title 속성을 사용하는 것 보다 label 엘리먼트와 input을 명시적으로 연결해 주는 것이 좋습니다. label 텍스트는 서식 제어 요소에 ‘포커스’를 넣거나 ‘체크’ 또는 ‘체크 해제’ 기능을 수행하기도 하는 이유 때문입니다.

예)
정보메일 수신에 동의 합니다.

1.6. Permalink 제공하기.

Permalink란 변하지 않는 고유한 URL을 의미합니다. 웹 사이트를 개편하거나 CMS^{Content Management System}를 교체하는 과정에서 흔히 게시물의 고유한 주소체계가 자주 바뀌어 불편을 격게 됩니다. 웹 사이트 관리자는 사이트가 개편 되더라도 게시물의 고유한 주소가 변하지 않도록 설계 단계에서부터 고려하여야 합니다.

1.7. ‘리치 텍스트 에디터’를 제공할 때 ‘플레인 텍스트 에디터’를 함께 제공하기.

리치 텍스트 에디터란 WYSIWYG^{What You See Is What You Get} 방식의 웹 기반 편집기를 말합니다. 포털에서 제공하는 ‘네이버 스마트 에디터’나 ‘다음 에디터’가 이에 해당합니다. 대부분의 리치 텍스트 에디터들이 갖는 치명적인 접근성 문제는 키보드로 접근할 수 없거나 또는 편집창에 한번 들어가면 키보드만으로는 빠져 나올 수 없다는 것 입니다. 리치 텍스트 에디터에 접근하더라도 Tab키를 사용하면 ‘들여쓰기’ 명령으로 받아들이기 때문에 빠져 나올 수가 없는 것입니다. 따라서 리치 텍스트 에디터를 제공할 때 플레인 텍스트 에디터를 함께 제공하여 선택할 수 있도록 하면 키보드만을 사용하거나 시각 장애가 있는 사람도 글을 작성할 수 있게 됩니다. 한편 이 둘을 함께 제공하고자 할 때 풀어야 할 문제는 리치 텍스트 에디터에서 플레인 텍스트 에디터 사이를 전환하게 될 때 서식정보(제목, 글자크기, 색상 등..)들을 어떻게 처리해야 하는지 입니다. 리치 텍스트 에디터에서 플레인 텍스트 에디터로 전환하게 되면 스타일 정보들이 모두 사라지기 때문에 발생하는 고민 입니다. 글쓰기 화면 예제 보기.

1.8. 사용자의 실수(세션만료, 로그아웃, 새로고침, 뒤로가기)를 만회할 수 있는 기회 제공하기.

사용자는 언제 세션이 만료되어 로그아웃이 되는지 모릅니다. 그것을 친절하게 경고하거나 알려주는 사이트도 거의 없기 때문에 웹에서 글을 작성하다가 잠깐 한눈을 팔게되면 오랜시간 공들여 작성한 문서를 잃게 됩니다. 또한 사용자는 실수로 새로고침(Ctrl+R. F5)키를 누르거나 뒤로가기(backspace)키를 누를 수 있습니다. 이 한번의 실수로 오랜시간 작성한 글을 잃도록 방치하는 것은 옳지 않습니다. WCAG 2.0 PR^{Proposed Recommendation} 에도 이와 관련된 새 항목이 추가 되었습니다. WCAG 2.0 Guideline 2.2.5 재인증 : 인증된 세션이 만료 되었을 때 사용자는 데이터를 잃지 않은 상태로 재 인증 후에 계속해서 활동할 수 있어야 한다.

1.9. CSS를 지원하지 않는 Form Control 요소를 장식하지 않기.

Form Control(서식 제어) 요소는 모든 브라우저들이 CSS를 제한적으로만(color, background, border, width, height 정도) 지원하고 있습니다. 이것을 제한하는 이유는 웹 개발자(디자이너 포함)가 이것의 모양을 마음대로(극단적으로) 바꾸었을 때 발생할 수 있는 치명적인 사용성 및 보안 문제 때문으로 추측 됩니다. 하지만 최근에는 디자이너들이 Form Control 요소의 디자인을 마음대로 가공하기 시작했습니다. 물론 악의적이지도 않고 극단적이지도 않아서 시각이 있는 사람이라면 마우스를 이용해서 이용할 수 있지만 보통의 경우 키보드 접근에 문제가 생기고 설사 키보드 접근을 지원(정확하게 말해서 키보드가 접근되는 것처럼 흉내내는 것)했다 하더라도 화면낭독기가 접근할 수 없게 됩니다. 왜냐하면 CSS를 지원하지 않는 Form Control 요소를 가공하기 위하여는 표현을 위한 가짜 마크업이 들어가게 되기 때문입니다. 디자인 하지 말아야 하는 Form Control 요소는 제 글 ‘서식 제어 요소의 디자인은 제한되어야 한다‘ 라는 글을 참고해 주세요.

2.1. 가변폭 텍스트와 줄바꿈 처리에 관한 테이블 표현 기법.

게시판 목록 페이지에서 가장 골치아픈 문제 가운데 하나는 테이블 셀의 너비를 효율적으로 사용하지 못하고 있다는 점 입니다. 보통의 경우 각 컬럼의 너비값을 지정하여 고정시키는데 이렇게 너비가 고정된 셀 안에서 문자들은 셀의 너비보다 커지게 되면 줄 바꿈이 되고 셀의 너비보다 작은 경우에는 공간을 낭비하게 됩니다. 지금 설명드리는 CSS 기법은 제목 컬럼을 제외한 나머지 컬럼들의 너비가 문자의 크기에 따라서 결정될 수 있도록 하고 줄 바꿈 되지 않도록 처리하는 기법 입니다. 예제 페이지에서 브라우저의 너비를 극단적으로 좁게(또는 넓게) 조절해 보세요. 게시판 목록 페이지 예제 보기.

table { width:100%; }
th, td { white-space:nowrap; }
td.title { width:100%; white-space:normal; }

2.2. 숨은 제목 제공 기법.

숨은 제목등을 display:none 을 이용하여 제공하는 기법은 화면낭독기의 설정이나 종류에 따라서 읽지 못할 수도 있고 본래 읽지 않아야 하는 속성이기 때문에 안전한 방법이 아닙니다. 따라서 화면 낭독기 사용자를 위하여 숨은 제목을 제공하고자 할 때 더 이상 display:none 기법을 사용하는 것은 안전하지 않습니다. 시각이 없는 사람에게 숨은 제목을 제공하는 CSS 기법은 다음과 같습니다. 

.selector { position:absolute; width:0; height:0; font-size:0; line-height:0; overflow:hidden; visibility:hidden; }

2.3. 텍스트 버튼 만들기.

버튼의 질감이나 입체 표현은 background-image를 사용하고 버튼의 내용물에 해당하는 문자는 텍스트로 처리하는 기법으로써 버튼을 마크업 하는 방법과 CSS 기법을 설명합니다. 문자의 길이에 따라 늘어나는 가변폭 버튼을 표현하려면 background-image를 두 번 사용해야 하는데 현재로서는 하나의 엘리먼트에 이미지를 한 번만 적용할 수 있기 때문에 표현을 위한 span 엘리먼트가 사용됩니다.

링크 버튼 :

<a href="#" class="button"><span>TEXT</span></a>

서식 전송 버튼 :

<span class="button"><input type="submit" value="TEXT" /></span> 

사용자 인터페이스 조작 버튼 :

<span class="button"><button type="button">TEXT</button></span>

텍스트 버튼 예제 보기. 예제에 사용된 이미지 보기. CSS 보기. 

1. a : URI를 ‘연결‘하기 위한 버튼으로서 <a href="#uri"> 형식으로 마크업 합니다.
2. button : URI를 연결하지 않고 단순하게 사용자 인터페이스만를 ‘조작‘하기 위한 버튼으로서 <button type="button"> 엘리먼트로 마크업 합니다. type을 명시하지 않으면 어떤 브라우저는 Form Submit 기능을 실행하기 때문에 반드시 type 속성을 button으로 지정해 주어야 합니다.
3. input : 사용자의 입력을 서버로 ‘전송‘하기 위한 버튼으로서 <input type="submit">, <button type="submit"> 엘리먼트로 마크업 합니다.

아래 준비된 예제는 버튼의 ‘목적‘과 ‘형태‘에 따라 다양한 HTML Markup 과 CSS 표현이 있음을 보여주고 있습니다. 텍스트 기반의 가변폭 버튼 표현은 좌우 2개의 이미지가 배치되어야 하는데 현재 활성 버전의 CSS 2.x에서는 Multiple Background Images와 같은 문법을 지원하지 않기 때문에(정확히 말하면 아직 브라우저들이 CSS3를 지원하지 않기 때문에) 부득이 표현을 위한 span 엘리먼트가 사용 되었습니다. IE 5.5~7, Firefox 2~3, Safari 3.x, Opera 9.x, Chrome Beta 브라우저에서의 호환성이 확보되어 있습니다.

[ 예제를 새창으로 보기 | CSS 보기 | Image 보기 White, Black, Green, Blue, Red ]

버튼의 목적을 명확하게 판단한 뒤 알맞는 엘리먼트를 사용하는 것은 접근성을 향상시켜 줍니다. 최근에는 Javascript를 지원하지 않는 브라우저 환경이 드물지만 되도록 Javascript에만 의존하여 기능을 수행하지 않도록 하는 것이 좋습니다. 특히 Link Button을 이용하여 Form을 전송하는 기능을 구현하면 Javascript를 지원하지 않는 환경에서의 상호 운용성을 확보하지 못하고 화면낭독기 장치를 이용하는 사람들의 접근성을 떨어 뜨리게 됩니다. Form 페이지의 전송 버튼을 ’submit’ 버튼 대신 ‘a’  버튼으로 마크업 하는 경우 화면 낭독기는 HTML기반으로 내용을 읽어 주기 때문에 이것을 ‘~링크’라고 읽어 주고 시각장애인은 이것을 ‘~전송 버튼’이라고 확신할 수 없는 문제가 발생 합니다.

제시된 예제는 다국어 환경의 웹 서비스에 적합하도록 텍스트 기반으로 디자인 되었으며 텍스트의 양에 따라 버튼의 너비가 가변적으로 변합니다. 색상별로 하나의 버튼 이미지를 이용하여 다양한 너비와 높이에 대응할 수 있도록 설계되어 있습니다. 이 버튼 스타일은 곧 공개될 Zeroboard XE 게시판의 1.0.7 버전에 대한 기본 테마로 탑재될 예정 입니다. 제로보드를 사용하시는 분들께서는 기본 버튼 스타일이 마음에 들지 않으실 경우 예제를 참고하여 간단하게 다양한 스타일로의 변경이 가능하고 현재의 스타일을 이용한 재 창작도 얼마든지 가능 합니다.

예제를 새창으로 보기

1. 첫째, 사용자의 자유도가 높을 것. 사용자는 원하는 색상으로 전경/배경을 얼마든지 쉽게 바꿀 수 있어야 합니다. 어떤 객체의 색상을 변경할 때 이미지 대신 CSS 코드를 이용할 수 있다면 훨씬 경제적 입니다. 물론 이미지 처리가 더욱 아름다운 표현을 위하여 필요하다는 의견에도 동의 하지만 저는 오픈소스의 진짜 디자이너는 최종 사용자 라고 생각하고 있습니다.
2. 둘째, 확장 가능성을 고려할 것. 너비, 높이, 갯수, 구조등은 항상 가변적이기 때문에 너비와 높이의 값을 고정하거나 제한된 갯수와 구조 하에서만 적당한 표현을 구사하게 되면 그 한계를 뛰어 넘어야 할 때 또 한벌의 새로운 코드를 작성해야 합니다. Tab Navigation을 만들기로 했다면 하위메뉴가 존재하는 상황도 미리 고려하여 작성해 둡니다. 처음 한번 작성할 때 시간이 많이 소요되지만 계속해서 재 사용할 수 있으므로 훨씬 효과적 입니다.
3. 셋째, 이미지는 쪼개지 말고 붙여서 사용할 것. 예를 들어 Tab의 라운딩 처리된 양쪽 모서리를 표현할 때 초심자들은 왼쪽 이미지, 오른쪽 이미지, hover, active 상태의 이미지들을 각각 따로 만드는 경우가 있습니다. 여러가지 상황에 대응하는 표현들은 단 하나의 이미지에 모두 쓸어담되 CSS를 이용하여 마치 분리된 이미지인듯 배치할 수 있습니다. 이러한 기법은 http request를 줄여주기 때문에 페이지의 성능 향상에도 영향을 줍니다. 야후에서는 이미지를 이런식으로 쓸어 담았습니다.
   

사용법

1. 탭의 기본 색, 마우스 오버 색, 활성화 된 탭의 색, 문자 색, 보더는 모두 CSS로 수정이 가능합니다.
2. 텍스트 기반으로 작성되어 있으며 문자열의 길이에 따라 탭의 크기는 가변적 입니다.
3. 탭의 크기(너비, 높이)는 padding으로 조절 합니다.
4. 사용자가 어떤 배경색을 사용하는지에 따라 1개의 이미지를 배경색과 동일한 색으로 수정하여야 합니다.
5. 약간의 코드만 수정하면 이미지 처리 방식으로도 얼마든지 전환이 가능 합니다.
6. IE 5.5~7.x, Firefox 2~3, Safari 3.x, Opera 9.x, Chrome 브라우저에서의 호환성이 확보되어 있습니다.
7. 더욱 아름다운 컬러 매치 또는 이미지로 처리된 탭 디자인이나 그 밖의 새로운 방식으로 자유롭게 구현한 다음 함께 볼 수 있도록 댓글로 공유해 주시면 대 환영 입니다. ^^;

이미지

HTML/CSS를 이용하여 화면에 보이는 삼각형의 너비와 높이 및 꼭지점 위치가 동일한 도형을 만들어 보세요.

단, 이것을 만들기 위하여 준수해야 하는 조건은 다음과 같습니다.

1. HTML과 CSS만을 사용하고 문법적으로 유효해야 합니다. HTML Validation Test, CSS Validation Test
2. Image, Javascript, SVG^{Scalable Vector Graphics} 등 다른 언어는 전혀 사용하지 않습니다.
3. body 엘리먼트 안쪽에는 다른 엘리먼트나 문자등 아무것도 넣지 않습니다.
4. Internet Explorer 6~8, Firefox 2~3, Safari 3.x, Opera 9.x, Chrome 브라우저에서 동일하게 보여야 합니다.

조건이 좀 까다롭죠? ^^; 아주 조금 힌트를 드리자면 실무에서는 거의 사용되지 않는 기교라서 여러분들은 고정관념에서 벗어나셔야 할껍니다. 문제를 해결하신 분은 자신의 계정에 문서를 업로드 하신 다음 댓글로 URL을 남겨 주세요. 정답을 가장 먼저 맞추시는 분께는 제가 식사를 한끼 대접하도록 하죠. 언제 만나냐구요? 언젠간 보겠죠? ^^;

1. 해당 요소들에 대한 스타일 변경을 대부분의 웹 브라우저가 지원하지 않기 때문이며,
2. 이를 극복하기 위하여 사용되는 트릭이 키보드 접근에 치명적이고 화면 표시 속도를 떨어뜨리기 때문입니다.

스타일 변경이 자유로운 요소들은 CSS를 이용하여 ‘border, background, width, height, image replace’ 기법 적용이 가능하나, 스타일 변경이 제한된 요소들은 width, height 만 지정이 가능합니다.

스타일 변경이 제한된 서식 제어 요소들의 디자인을 변경하는 것이 기술적으로 불가능 한 것은 아닙니다. 그러나 보통의 경우 키보드 접근이 되지 않거나 표현만을 위한 가짜 마크업으로 하여금 시각장애인을 혼란스럽게 만듭니다. 키보드가 접근되지 않는다는 것은 시각장애인이 이용할 수 없다는 것을 의미하며 이것은 ‘장애인차별금지 및 권리구제 등에 관한 법률‘에서 정한 ‘차별행위’에 해당되어 소송의 빌미가 될 수 있으므로 주의하여야 합니다. 되도록 웹 브라우저가 제공하는 고유한 인터페이스를 그대로 사용하는 것이 웹 접근성을 훼손하지 않는 방법 입니다.

보통의 기획자, 디자이너 또는 UX 전문가들이 생각하기에 ‘리셋’ 이나 ‘취소’ 버튼은 언제든지 현재의 상황으로 부터 벗어나기를 원하는 사용자를 위하여 대부분의 입력양식에 있어서 당연히 필요한 것이라고 생각해 왔습니다. 하지만 저는 제이콥 닐슨의 8년 전 글을 빌어 그것이 얼마나 잘못된 생각인지 다시 말하고 싶습니다. 이 블로그를 운영하기 전에 똑같은 이야기를 했던 적이 있었지만 현재 존재하지 않기에 다시 언급하게 되었습니다.

‘리셋’ 버튼은 현재 페이지의 입력 필드를 모두 지워서 초기화 시키는 버튼 입니다. 리셋 버튼이 사라져야 하는 이유는 다음과 같습니다.

1. 사용자들은 종종 실수로 ‘리셋’ 버튼을 클릭합니다. 만약 제공하지 않는다면 그런 엄청난 실수를 하지 않을 것입니다.
2. 사용자는 ‘전송/리셋’ 두 개의 버튼 가운데 어느 것이 올바른 버튼인지 판단해야 합니다. ‘전송’ 버튼만 제공되어 있을 때 우리는 어느 것이 올바른 버튼인지 생각할 필요가 없게 되는 거죠.
3. 현재 페이지의 모든 양식을 다시 작성해야 하는 경우는 매우 드물고 사용자는 잘못 입력된 필드만을 직접 수정합니다. ‘리셋’ 버튼은 있어도 잘 사용하지 않는다는 것입니다.

‘취소’ 버튼은 현재 페이지로부터 ‘뒤로’ 또는 ‘절차의 처음’으로 돌아가는 버튼 입니다. 취소 버튼을 되도록 사용되지 않아야 하는 이유는 다음과 같습니다.

1. 실수로 클릭할 수 있습니다.
2. 두 개의 버튼 가운데 어느 것이 올바른 버튼인지 사용자의 판단을 요구합니다.
3. 사용자들은 ‘취소’ 버튼 대신 ‘뒤로가기’ 버튼을 이용하거나 ‘원하는 곳으로 직접 이동하기’를 원합니다. 때때로 ‘취소’ 버튼은 우리를 원하지도 않는 곳으로 안내 합니다. 또한 항상 ‘절차의 처음’으로 돌아가기를 원하는 것도 아닙니다. ‘취소’ 버튼이 필요한 경우는 몇 번의 절차를 거쳐 입력한 데이터가 더 이상 서버로 전송되지 않는다는 확신을 주어야 할 때에만 필요 합니다.

지금 우리가 참여하고 있는 프로젝트 가운데 얼마나 많은 ‘리셋’과 ‘취소’ 버튼이 사용되고 있는지 살펴보시고 과연 적절한지 다시 한번 생각해 보는 계기가 되었으면 합니다. ‘사용성‘은 하나의 페이지에서 조작할 수 있는 버튼의 갯수와 보통은 반비례 한다는 사실을 늘 염두해야 합니다.

PNG-24 이미지를 배경으로만 처리하려는 경우 CSS 코드를 다음과 같이 작성 하면 IE6~5.5 브라우저에서 PNG-24 배경 이미지를 정상적으로 렌더링 합니다.

.selector{background:url(png24.png); _background:none; _filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=’png24.png‘, sizingMethod=’crop’);}

filter에 적용할 이미지의 src 경로를 상대경로로 지정하는 경우 background:url과 같이 CSS 파일을 기준으로 적용하면 안됩니다. filter에 적용하는 이미지의 경로는 HTML 문서를 기준으로 설정하여야 합니다. 즉, background의 이미지와 filter에 적용하는 이미지는 같은 이미지라 할지라도 경로의 기준이 CSS와 HTML으로 각각 서로 다르므로 이점 유의하여 적용하세요.

PNG-24를 정상적으로 렌더링 하는 표준계열 브라우저(Firefox, Opera, Safari, Chrome, IE7~8)에서는 다음과 같이 작용 합니다.

.selector{background:url(png24.png); _background:none; _filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=’png24.png’, sizingMethod=’crop’);}

PNG-24를 정상적으로 렌더링 하지 못하는 IE6~5.5 브라우저에서는 다음과 같이 작용 합니다.

.selector{background:url(png24.png); _background:none; _filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=’png24.png‘, sizingMethod=’crop’);}

언더바 ‘_’ 핵을 사용하여 IE6~5.5 브라우저에만 MS 전용 CSS Filter를 적용하는 방법입니다.

PNG-24 관련 CSS Hack 에 공통으로 발견되는 알려진 버그

이 핵 또한 다른 PNG-24 핵들과 마찬가지로 배경이미지의 배치를 원하는 곳에 할 수 없다는 것과 배경이미지의 반복이 불가능 하다는 문제가 있습니다. 배치는 기본값인 backgroun-position:left top 으로 설정이 되며 반복은 background-repeat:no-repeat 상태가 되므로 참고하세요.

IE에서는 png배경이 사용된 엘리먼트에 position:relative|absolute 속성이 들어가게 되면 자식요소의 a 엘리먼트에 마우스로 접근할 수 없는 버그가 있습니다. png배경이 포함된 요소에 position:relative|absolute 속성을 제거하거나 또는 a요소에 position:relative|absolute 속성을 함께 부여해 보세요.

아래 글은 아직 한국어로 번역되지 않은 구글의 사용자 경험^{Google User Experience} 페이지를 한국어로 번역한 것 입니다. 가능한 외부의 글을 있는 그대로 옮겨오는 포스팅을 지양하지만 오늘만큼은 그럴만한 가치가 있다고 판단 했습니다. 구글은 ‘구글의 사용자 경험’에 대하여 어떤 철학을 지니고 있는지 함께 살펴보시죠.

우리의 목표^{Our aspirations}

구글의 UX팀은 실용적이면서 빠르고, 단순하면서 매력적이고, 혁신적이면서 보편적이고, 유익하면서 아름답고, 신뢰할 수 있는 그리고 품위있는 디자인을 창작하는 것을 목표로 하고 있습니다. 이러한 열가지 원칙을 균형있게 달성하는것은 불변의 도전 과제입니다. 적절한 균형을 갖춘 제품이 구글다운 것이고 이것은 전 세계 모든 사람을 만족스럽고 기쁘게 할 것입니다. 열 가지 디자인 원칙은 구글다운 사용자 경험을 위한 것입니다.

1. Useful : 사람을 향합니다. 그들의 삶과 일과 꿈을 위하여. ^{Focus on people – their lives, their work, their dreams.}

구글의 UX팀은 명료하게 표현할 수 없는 욕구를 포함하여 사람들의 진짜 욕구를 발견하는 일을 합니다. 이러한 정보를 가지고 구글은 모든 부류 사람들의 창조력을 유도하고 현실의 문제를 해결하는 제품을 창작할 수 있습니다. 단순하게 과업을 줄이는 것이 아니라 삶의 질을 향상시키는 것이 우리의 목표 입니다.

무엇보다도 잘 설계된 구글 제품은 일상에서 유용합니다. 첨단 기술이나 시각적 효과에 의존하지 않고 사람들이 원하지 않는 것을 강제하지 않으면서 필요한 사람들을 위하여 자연스러운 발달 경로를 제공합니다. 사람들의 삶에 개입하지 않지만 세상의 정보를 탐험하기를 원하는 사용자들의 문을 열어주고, 보다 빠르고 창의적으로 일하게 하고, 친구들과 세상을 향하여 그들의 생각을 공유하게 합니다.

2. Fast : 천분의 일초까지 헤아립니다. ^{Every millisecond counts.}

사람들의 시간보다 더 중요한 것은 존재하지 않습니다. 구글의 페이지들은 날씬한 코드와 주의깊게 선택된 이미지 파일들로 하여금 즉시 열립니다. 가장 필수적인 기능들과 문자들은 가장 찾기 쉬운 위치에 배치됩니다. 불필요한 클릭, 타이핑, 단계, 기타 활동들은 제거됩니다. 구글 제품들은 단 한번의 정보만을 요청하고 단순한 기본값만을 포함하고 있어 과업은 간결하게 진행됩니다.

속도는 사용자에게 혜택이 됩니다. 충분한 이유없이 속도를 희생하지 않는것이 구글의 경쟁력 입니다.

3. Simple : 단순한 것이 더 강력합니다. ^{Simplicity is powerful.}

단순함은 사용성, 속도, 시각적 호소력과 접근성을 포함하여 훌륭한 디자인의 많은 요소들에 작용합니다. 단순함은 제품의 근본적인 기능에 대한 설계로 부터 시작하며 풍부한 기능을 창작하는것으로부터 시작하지 않습니다. 우리에게 최상의 설계는 오직 사람들이 목표로 하는 것을 실현하기위해 필요로 하는 기능을 포함하는 것 입니다. 제품들이 극단적으로 광범위한 기능과 복잡한 시각적 디자인을 요구하더라도 강력할 뿐만 아니라 단순하게 만듭니다.

구글팀은 중요한 기능을 축소하면서 단순함을 희생하기 전에 한번 더 생각합니다. 우리의 바램은 단순하게 더 많은 기능을 추가하는 것 대신 새로운 방향으로 제품을 점진적으로 변화시키는것 입니다.

4. Engaging : 초심자에게는 경험을 주고 전문가를 매혹시킵니다. ^{Engage beginners and attract experts.}

많은 사람들을 위한 설계는 최소한의 공통분모를 위한 디자인을 의미하지는 않습니다. 최상의 구글 디자인은 쉽게 접근할 수 있는 강력한 기능을 포함하더라도 표면적으로는 매우 단순하게 드러납니다. 우리의 의도는 고급 사용자들이 다른 사용자들에게 제품을 소개하는 동안 초심자가 가슴벅찬 첫 경험을 하도록 이끄는 것 입니다.

잘 설계된 구글 제품은 새로운 사용자를 끌어들이고, 필수적인 도움을 제공하며, 가장 가치있는 기능을 직관적이고 단순하게 사용하도록 확신을 줍니다. 숙력된 기능의 점진적인 개선은 사람들이 제품의 사용성을 확장할 수 있도록 도와줍니다. 언제든 저장공간을 원하거나, 온/오프라인에서 일하거나, 다양한 장치와 컴퓨터에서 자료를 공유하고자 하는 복잡한 온라인 일상속에 구글은 재치있는 기능을 제공합니다.

5. Innovative : 혁신을 두려워하지 않습니다. ^{Dare to innovate.}

일관된 디자인은 구글 제품에 대한 신뢰를 구축하며 사용자를 편하고 능률적으로 만듭니다. 그러나 따분한 것으로부터 매력적인 디자인으로 전환시키는 것은 상상력 입니다.

구글은 사용자의 욕구를 만족시켜주기만 한다면 혁신적이고 모험적인 디자인을 장려합니다. 우리 팀은 새로운 생각의 출현과 실행을 권합니다. 구글은 현존하는 제품의 기능에 필적하는 것보다는 구도 자체를 바꾸기를 원합니다.

6. Universal : 모두를 위한 설계를 합니다. ^{Design for the world.}

월드와이드웹의 인터넷 자원은 지구촌 모든 사람들에게 열려 있습니다. 예를 들어 많은 사람들은 PC 앞에만 앉아 있지 않고 휴대장치를 가지고 이동하며 구글 제품을 이용합니다. 우리의 목표는 어떤 장치나 방법으로도 접근 가능하며 현실에 대응 가능한 의미있는 제품을 디자인 하는 것 입니다. 구글은 느린 접속과 가능한 오래된 브라우저 그리고 다양한 정보 이해 방법과 다양한 화면 선택을 지원합니다. UX팀은 지구촌 곳곳의 사용자와 장치 및 문화를 위한 바른 제품을 설계하는 것과 사용자 경험의 근본적인 차이를 연구합니다. 간단한 변형 또는 겸손한 기능만으로는 사람들의 욕구를 충족하지 못합니다.

구글은 접근성을 향상시키는 일에도 전념합니다. 우리의 단순함에 대한 열정과 정보의 보편적 접근에 대한 사명은 구글의 제품이 보조기술을 지원하고 물리적 정신적 한계를 지닌 사람을 포함하여 모두에게 유용하면서도 즐길수 있는 제품이 될 것을 요구하고 있습니다.

7. Profitable : 사업 계획에 도움이 됩니다. ^{Plan for today’s and tomorrow’s business.}

구글 제품들은 사용자에게 유용하면서도 경제적으로 도움이 될 수 있도록 노력하고 있습니다다. 이 목표에 도달하기 위하여 디자이너들은 사용자들의 목표와 사업적인 고려를 한결같이 통합해야 합니다. 광고는 반드시 광고답고 유용하게 만들어야 합니다. 구글은 구글에 의존하여 생계를 이어가는 사람들과 광고에 흥미를 가진 사람들을 보호합니다.

구글은 향후 구글의 사용자들을 감소시킨다면 제품으로부터 수익을 증가시키려고 노력하지 않습니다. 만약 수익에 도움이 되는 디자인이 사용자를 기쁘게 하지 못한다면 이것은 처음부터 다시 시작해야 합니다. 모든 제품이 수익을 목표로 하지는 않지만 사업과 무관한 것도 아닙니다.

8. Beutiful : 주의를 산란시키지 않고 눈을 즐겁게 합니다. ^{Delight the eye without distracting the mind.}

사람들이 구글 제품을 보면서 ‘와 예뻐요!’ 라고 말할 때 UX팀은 고무됩니다. 긍정적인 첫인상은 사용자를 편안하게 하고 믿음을 주며 자신들의 제품으로 만들 수 있다는 확신을 갖게 됩니다.

최소한의 장식은 대부분의 구글 제품들을 깔끔하게 만듭니다. 군더더기 없는 디자인은 빠르게 로드되고 사용자들의 목표를 달성하는데 방해를 주지 않습니다. 시각적으로 호소하는 이미지와 색과 서체들은 속도와 가독성 그리고 쉬운 탐색에 대한 욕구에 대응하도록 조절되어 있습니다. 사용자와 문화적 배경에 따라서 ‘고상한 단순함’이 모든 제품에 맞지 않을 수도 있지만 구글 제품의 심미적 디자인은 사용성을 증가시키고 사용자를 즐겁게 할 것입니다.

9. Trustworthy : 사람들에게 확신을 주어야 합니다. ^{Be worthy of people’s trust.}

훌륭한 디자인은 구글 제품을 사용하는 사람들로부터 장기적인 신뢰를 얻습니다. 구글의 신뢰성은 기본적인 것들로부터 확립됩니다. 예를 들면 인터페이스는 효과적이고 전문적으로 만들고 실행은 쉽게 취소할 수 있으며 광고는 명확하고 기술은 지속적이며 사용자들은 불쾌하게 놀라지 않습니다. 게다가 구글 제품들은 경쟁자들과 공헌자들의 링크를 포함시키며 세상을 향해 열려 있습니다.

더 위대한 도전은 구글이 사용자들의 권리와 그들의 데이터를 존중하고 있다는 것을 증명하고 확신하게 하는 것입니다. 구글은 사용자들의 명백한 동의 없이 어떤 정보도 외부로 공유하지 않고 이것을 어떻게 사용하는지에 대하여 정직 합니다. 우리의 제품들은 보안 위험이나 다른 웹사이트와 차이가 있는 보안정책 및 스팸의 피해나 데이터를 외부로 도난 당할 가능성에 대하여 사용자들에게 주의를 줍니다. 구글은 사용자들의 정보 공유에 대하여 정직하지만 더 확신을 주고 싶습니다. 구글이 더 성장함에 따라 우리의 좌우명 ‘사악해지지 말자’ 는 생존에 더욱 필요한 말이 되었습니다.

10. Personable : 인간미를 보탭니다. ^{Add a human touch.}

구글은 다양한 개성을 포함하고 있고 우리의 디자인도 그렇습니다. 문자와 디자인 요소들은 친근하고 빠르고 재치가 있으면서 지겹지 않고 거만하지 않습니다. 구글의 텍스트는 사람들에게 직관적이고 동일한 경험을 제공합니다. 누군가 질문을 한다면 이웃들이 비공식적인 조언들을 제공할 것입니다. 구글은 특히 중요한 정보 또는 생계과 밀접한 경우에 개성넘치는 디자인으로 하여금 그들을 방해하지 않습니다.

구글은 모든것을 알고 있지 않으며 설계도 완벽하지는 않습니다. 우리의 제품은 반응을 원하고 그 반응에 따라 실행합니다. 현존하는 이런 디자인 원칙에 따라 구글의 UX팀은 각각의 제품에 대하여 가능한 최고의 타협점을 찾을 것입니다. 그에 따라 혁신과 개선은 지속될 것입니다.

NHN 웹표준화팀

공식적인 데이터는 아니지만 현재 NHN에서 제공하고 있는 크고 작은 네이버 서비스들은 약 100여개 이상인 것으로 추정하고 있으며 여기에 ‘한게임‘ 까지 포함하면 그 두 배수 정도의 웹 서비스가 진행되고 있다는 것을 알 수 있습니다. 이 수많은 서비스의 User Interface 기술 구현은 외주로 처리하는 일부를 제외하고 대부분 UIT Center 내에서 진행되는데 UIT Center는 전문 직군별로 다시 5개의 랩 또는 팀으로 나뉩니다. Ajax UI랩, 플래시UI랩, UI기술기획팀, 웹표준화팀, 오픈UI기술팀이 모두 UIT Center 산하에 있는 조직들 입니다. 이름만 보면 대강 무슨일을 하는 곳인지 짐작이 되시겠죠? 제가 있던 웹표준화팀은 HTML, CSS, 웹 표준, 웹 접근성 관련 기술을 다루는 곳입니다. 웹 표준이나 웹 접근성 같은 업무는 웹 표준화팀 고유의 업무라기보다 UIT Center 내 모든 직군이 다루지만 그 중에서도 웹 표준화팀과 가장 밀접한 분야라고 생각됩니다. 웹 표준화팀에서 그동안 제가 참여했던 프로젝트는 다음과 같습니다.

• 2007년 4월 Naver 데스크바 개편 - http://deskbar.naver.com/
• 2007년 5월 Naver 책 개편 - http://book.naver.com/?frm=nt
• 2007년 6월 Naver 영화 개편 - http://movie.naver.com/
• 2007년 6월 Zeroboard XE - http://zeroboard.com/
• 2007년 9월 Naver 통합검색 개편 - http://search.naver.com/
• 2007년 11월 웹표준화팀 가이드 개편 - http://html.nhndesign.com/
• 2007년 12월 Naver 회원가입 개편 - https://nid.naver.com/join.html
• 2008년 3월 Naver 이용약관 및 정책 개편 - http://www.naver.com/rules/service.html
• 2008년 4월 Naver ○○○○ 개편중
• 2008년 4월 Naver ○○○ 개발중
• 2008년 6월 Naver GNB^{Global Navigation Bar}
• 2008년 6월 Naver ○○○○○ 리펙토링

무척 많이 한 것 같은데 그룹웨어(인트라넷)나 참여율이 작은 일들을 제외하니 얼마 되지 않네요. ○○○ 처리된 것들은 아직 오픈 전이라 보안상 공개를 하지 않은 것들 입니다. 저 일들을 혼자 다 한것은 아니라 동료들과의 협업을 통해 나온 산출물들이죠. 전배 직전 하던 일들은 네이버 전체를 관통하는 서비스들로서 GNB, Footer, 회원가입, 보안로그인, 고객센터 등등 이었습니다. 워낙 서비스가 많다보니 웹 표준화팀 구성원들은 보통 때 적게는 2개에서 많게는 4개까지 다양한 프로젝트에 동시 투입되고 있는데 회사에서 가장 바쁜 팀이 아닐까 라는 생각을 한 적도 있습니다. 팀에 소속되어 있으면서 가장 보람을 느꼈던 일은 네이버가 조금씩 웹 표준화 되어가는 것에 참여하고 있다는 사실과 그것을 바라보는 일이었고 가장 안타까웠던 일은 팀의 목표를 달성 했을 때 그것이 당연한 일이라 보통은 잘 드러나지 않고 잘못 한 일은 금새 티가 난다는 사실이었습니다. 성과에 따라 팀의 평판이 달라지는 현실을 고려할 때 잘 한일들은 정말 잘 했다고 인정받을 수 있다면 좋겠다는 생각을 했고 이 문제는 앞으로도 계속 풀어가야 할 과제라고 생각합니다. 개인적으로 2008년 상반기에 UIT Center 내에서 수여하는 ‘열정상’을 받은일도 있는데 요건 참 뿌듯하고 기억에 남네요. ^^

NHN 오픈UI기술팀

2008년 9월 1일 부로 신설된 NHN의 오픈소스 개발팀 입니다. 여러분이 익히 잘 알고 계신 제로보드의 고영수님께서 팀장직을 맡게 되었고 XE^{eXtra Edition} 플랫폼을 기반으로 다양한 오픈소스 서비스를 개발할 예정입니다. 보통 사내에서 소속을 옮기는 것은 회사를 옮기는 것만큼이나 쉽지만은 않은 일인데 저와 같은 경우는 고영수님께서 적극적으로 전배를 요청해 주셨고 조직장님들의 오랜 협의와 허락 끝에 팀을 옮기게 되었습니다. 이렇게 팀을 옮길 때 개인의 의사를 매우 중요하게 생각하기 때문에 제 의사를 먼저 고려해 주셨는데요. 저는 양팀 모두 기회라고 생각하고 있고 조직이 결정해 주면 그 뜻에 따르겠다는 의사를 밝혔었고 이런 우유부단한 표현 때문에 양쪽 팀장님들께서 의사결정 하시는데 곤혼스럽지는 않으셨는지 조금은 죄송한 마음입니다.

제로보드 XE에 대하여 많은 분들이 알고 계실텐데요. 혹시 XE의 본디말도 아시는지요? 위에서 윗첨자로 표기를 해서 아시겠지만 XE는 eXtra Edition의 약자이며 제로보드의 버전이라기 보다는 개발 플랫폼 입니다. 즉, XE라는 플랫폼 위에서 우리는 국수 뽑아내듯 게시판, 사이트 빌더, 블로그, 위키, 쇼핑몰 등등을 뽑아내는 겁니다. 코어라고 부르기도 하죠. 저는 XE를 기반으로 퍼블리싱 되는 웹 서비스의 User Interface를 담당하게 되었습니다. 지금까지 해오던 일을 XE에서도 계속 진행하는 것이고 전에 하던일과 달라진 점이 있다면 이것이 오픈소스라는 점입니다.

현재는 정규직 팀 구성원이 고영수 팀장님과 저 둘 뿐이지만 곧 기획, 개발을 담당하실 분들의 입사가 예정되어 있어 새로운 서비스 개발에 박차를 가할 계획입니다. NHN에서 이렇게 오픈소스를 지원하는 이유나 목적에 대해서는 이미 많은 분들께서 언급해 주셨기 때문에 제가 굳이 이야기 할 필요는 없다고 생각되지만 NHN은 오픈소스를 단순히 사회적 책임 차원에서만 바라보는 것이 아니라 새로운 도약의 기회라고도 생각하고 있는 것 같습니다. 오픈UI기술팀은 그동안 제로보드를 주도적으로 이끌어 왔던 풀타임 오픈소스 개발자 고영수님 그리고 제게도 새로운 도약의 기회가 되리라 믿습니다. 어떤 분들께서는 NHN의 주도 면밀하고 숨은 전략이 무엇인지 먼저 생각하시겠지만 저는 그것과 더불어 사회적으로 긍정적인 파급효과를 내 줄 것이라 믿기에 이곳 팀에서의 생활도 무척 보람된 시간이 될 것으로 한층 기대가 됩니다.

오픈소스 UI 개발은 포털 UI 개발과 어떻게 다른가

우선 포털의 UI는 철처하게 고정폭 그리드 기반이라서 최종 결과물은 항상 캡쳐한 다음 디자이너분이 넘겨주는 시안과 일일이 비교하고 오차를 최소화 하게 됩니다. 최종 결과물은 그리드가 1px 만 어긋나도 다시 보수작업을 해야 하는 시스템인데 모든 브라우저에서 이것을 맞출 수는 없기 때문에 통계상 가장 사용율이 높은 IE6 에서만 그리드를 일치 시킵니다. 결론적으로 디자인의 힘이 중요합니다.

한편 오픈소스는 디자이너의 그리드 보다 UI의 재활용 효율과 확장 편의를 더 우선적으로 고려하기 때문에 이미지의 사용비율을 최소화 하고 그리드 대신 가변폭 너비와 가변 크기의 서체 사용이 요구되고 있습니다. 또한 다국어 환경과 더욱 폭넓은 OS, Browser를 지원해야 하기 때문에 높은 접근성과 상호 운용성을 유지하기 위하여 브라우저의 form control 객체들(input, select …)과 같은 요소들에 대한 디자인은 포털과 달리 일부분의 제약이 예상 됩니다. 디자인과 상호 운용성이 적절한 합의점을 찾아야 하는 과제가 있습니다.

페이지 단위로 개발하지 않고 오브젝트 단위로 개발하게 됩니다. 즉, 하나의 웹 서비스를 런칭하기 위하여 메인, 서브 순으로 진행되지 않고 레이아웃, 버튼, 목록, 페이지네이션, 레이어 등등 UI 오브젝트들을 개별적으로 구현하며 확장 가능한 형태로 여러벌을 미리 만들어 둔 다음 가져다 쓰는 형식으로 개발 됩니다. 포털에서도 일부 이런 형식으로 진행이 되지만 오픈소스 UI 개발은 더욱 이러한 방식에 의존하게 됩니다.

아직 옮긴 팀에서 다양한 경험을 쌓은것이 아니라 오늘은 이정도만 생각나네요. 더욱 많은 이야기는 차차 생각날때 마다 끄집어 내어놓고 중요한 소식들은 제 블로그를 통해서도 공유 드리도록 하겠습니다. 오픈소스 UI 개발자라니 이거 무척 영광스럽네요. ^^

Google Chrome 시작페이지

첫인상이 촌스럽다고 느꼈던것은 파랑색 때문이었나 봅니다. 계속 보고 있으니 대단히 심플한 인터페이스를 갖추고 있어서 점점 더 매력적으로 느껴지네요. 소박한 시골 처녀 같은 느낌입니다. 보통의 브라우저들이 브라우저 상단에 ‘파일, 편집, 보기 …’ 와 같은 메뉴 인터페이스를 제공하는데 반하여 Chrome은 이것을 주소 입력창 우측으로 치워버리는 과감한 시도를 했고 저는 이것이 가장 마음에 듭니다. 군더더기 없이 깔끔한 인터페이스에 100점 주고 싶네요.

Acid2 Test 결과

역시 완벽합니다. 이 결과의 의미는 Google Chrome 브라우저가 HTML/CSS를 표준 스펙에 따라서 정확하게 렌더링 해 줄것이라는 것을 보증한다는 의미 입니다. Webkit 엔진을 사용했다고 하니 Safari와 동일한 결과가 나오는 것은 어쩜 당연한 일이겠죠.

Acid3 Test 결과

Safari3 가 75/100 점을 받았는데 Chrome 은 76/100 을 받았습니다. (deute님 말씀에 따라 다시 테스트를 해보니 점수가 76, 77, 79 사이를 오락가락 하네요) 이 테스트의 의미는 브라우저가 DOM과 Javascript를 얼마나 표준대로 구현해 놓았는가를 측정하는 실험 입니다. 결과가 이렇다 보니 DOM/Javascript 개발하시는 분들이 아무래도 저같은 직군보다 더 많이 고생하시는것 같아요. ㅡㅡ;

Chrome에 대한 전반적이고 더 자세한 설명은 구글에서 제공된 페이지 ‘제작배경, 주요기능, 구글 엔지니어들이 직접 전하는 크롬 이야기‘를 참고하세요. 오늘부터 테스트 해야할 브라우저가 하나 더 늘어난 것만은 확실 하지만 그동안 Opera, Safari 브라우저의 호환성 작업을 수월하게 진행하셨다면 Chrome은 아예 신경쓰지 않으셔도 될 것 같네요. Safari와 거의 동일하게 렌더링 될 테니까요. CSS3 선택자 지원상황도 Safari와 동일하네요.

아래 이미지는 제 윈도우 작업표시줄 입니다. ^^ 뭐 이런식으로 작업하고 있습니다.