NN:TX

다양한 욕구, 별도의 배려, 특별한 시선.

2010-04-21T02:15:08+09:00

어제 장애인의 날 기고했던 글이 네이버 다이어리에 게시가 되어 제 블로그에도 옮겨 왔습니다. 장애인의 날이라고 해서 특별한 이벤트를 준비하지 않았지만 장애에 대한 제 생각을 많은 분들과 나눌 수 있는 좋은 기회였다고 생각합니다. 투박한 글을 좀 더 차분하고 부드럽게 편집해 주신 담당자분께 감사 드립니다. 네이버 다이어리는 NHN의 공식 기업 블로그 입니다. 얼마 전까지 일방적으로 정보를 전달하는 기능에 그쳤지만 최근 댓글과 엮인글을 받아들이기로 결정하면서 열린 소통의 장으로 변신을 시도 했습니다. 미투데이와 트위터도 나란히 운영하고 있으니 네이버 이야기가 궁금하신 분들은 친구맺기 또는 팔로잉 하시면 되겠네요.

안녕하세요? NHN 오픈UI기술팀에 근무하는 정찬명 입니다. 저는 장애인이 아니며 그 분들을 잘 알고 있는 것도 아닙니다. 다만 한 가지 공통점은 있습니다. 바로 ‘특별한 어떤 욕구를 느낀다’는 것입니다. 그리고 이 욕구는 장애인이건 비장애인이건 모두 특수하고 다양합니다. 이 점이 제가 생각하는 유니버설 디자인의 출발점입니다.

'분리'와 '별도의 배려'라는 해결책에 대해

얼마 전 한 국가 산하 기관에서는 마우스의 드래그 앤 드롭을 이용한 비밀번호 입력장치를 세계 최초로 개발했다는 소식을 발표 했습니다. 그러나 마우스를 사용할 수 없는 장애인이 어떻게 사용할 수 있는지, 보충 설명이 없었기 때문에 장애인 단체는 장애인에 대한 배려 없음을 강력하게 비판 했습니다. 어떤 분들은 “장애인을 위한 별도의 방식을 만들어 보완하면 된다”는 대안을 제기하기도 했습니다. 하지만 저는 동의할 수 없었습니다. ‘별도의 배려’라는 해결책은 장애인과 비장애인을 성급히 구분하기 때문입니다.

‘장애인차별금지 및 권리구제 등에 관한 법률’은 차별에 대해 ‘장애를 사유로 정당한 사유 없이 제한, 배제, 분리, 거부 등으로 불리하게 대하는 경우, 그리고 이와 같은 사유로 불리하게 대하지 않지만 장애를 고려하지 않은 기준을 적용함으로써 장애인에게 불리한 결과를 초래하는 것’이라고 정의하고 있습니다.

마우스를 사용한 비밀번호 입력장치는 의도하지 않았지만 장애인을 해당 서비스와 분리시키는 결과를 가져왔습니다. 법 조항을 엄밀히 따지자면 차별에 해당할 수 있을 것입니다. 하지만 ‘차별이냐 아니냐’ 보다 더 중요한 일이 있습니다. 애초부터 장애인, 비장애인 모두가 이용할 수 있는 방법을 고민할 수는 없었을까 하는 것입니다.

장애인 전용 엘리베이터를 이용하도록 하는 것을 과연 장애인들은 원할까요? 장애인 전용 홈페이지를 이용하도록 하는 것을 장애인들은 원할까요? 그 누구도 특별한 욕구가 있다고 해서 특별히 분리되는 것을 원하지는 않을 것입니다.

다양한 욕구의 수용 방법에 대해

우리가 접하는 모든 제품들은 가치의 산물입니다. 어떤 제품이 시장에 나오기까지 수 많은 사람들의 가치가 개입 됩니다. 디자이너는 더 아름답게, 엔지니어는 보다 기능적으로, 영업사원은 그 제품이 더 많이 팔리기를 원할 것입니다. 제품은 시장에 나오기까지 이런 다양한 가치들을 아우르기 위하여 치열하게 경합하게 되고 소비자들은 그런 가치의 총합인 물건을 구입하게 됩니다. 그렇다면 시장에서 많은 사람들에게 오랜 시간 사랑 받는 제품은 어떤 공통된 가치를 포함하고 있을까요? 다양한 공통점이 있겠지만 그 중의 하나는 바로 ‘다양한 욕구’에 대한 수용 이라고 생각 합니다.

제 아들은 아직 초등학교에 입학하지 않은 어린 남자아이 인데요. 가끔 공중 화장실에서 미안한 생각이 들 때가 있습니다. 화장실의 남자 소변기가 너무 높은 곳에 매달려 있기 때문입니다. 엘리베이터를 탔을 때에도 비슷한 경험을 합니다. 고층으로 이동해야 하는데 아이는 수직으로 배치되어 있는 층별 버튼 가운데 키가 닿지 않는 버튼이 있습니다. 여섯 살이면 혼자서도 엘리베이터를 조작할 줄 아는데 키가 작아서 어른의 도움을 필요로 하는 경우가 있습니다.

휠체어를 탄 지체 장애인도 마찬가지 입니다. 엘리베이터의 버튼은 보다 낮은 곳에 수평으로 배치해 두면 애초부터 모두가 편하지 않았을까요? 또 시각 장애인을 위해 점자 버튼을 추가하는 일은 비효율적인 발상일까요?

최근에는 ‘터치’로 작동하는 전자제품들이 많이 쏟아져 나오고 있는데요. 이런 제품들이 오랜 시간 사랑 받으려면 무엇을 개선해야 할까요? 조작 방법을 시각에만 완전히 의존하도록 하지 않는다면 주머니 속에 넣고도 간단한 기능은 조작할 수 있지 않을까요? 다양한 사람들의 욕구를 처음부터 고려하는 것은 비용만 많이 들어가는 골치 아픈 일일까요?

특별한 시선은 불편할 수 있습니다

어떤 분들은 장애인을 장애우라고 부르기도 하는데요. 한국장애인단체총연합회에서는 이와 같은 용어의 사용을 중단할 것을 요청 했습니다. 사실 장애를 가진 분들 가운데는 ‘친구’ 이상의 연배를 가진 분들도 많습니다. 이분들을 모두 뭉뚱그려 ‘친구’라고 부르는 것은 우리 사회의 장애인에 대한 어떤 시각의 단면일 수도 있습니다.

잘 아시는 것처럼 장애인은 특정 집단으로 분류하거나 시혜의 대상으로 보는 시선에 대하여 거부감을 느끼고 있습니다. 때문에 장애인을 위하여 ‘무엇을 했다’ 라는 생색내기도 그리 달갑게 받아들이지 않습니다. 특별한 시선과 동정의 눈빛은 오히려 벽과 같다는 게 장애인들의 입장입니다.

저는 개인적으로는 ‘장애라는 말을 사람에게 쓰는 것 자체가 문제가 아닐까’라는 생각을 합니다. 진짜 장애는 ‘다른 욕구를 지닌 사람을 돕지 못하는 환경’에 있는 것이지 ‘조금 다른 사람’에게 있는 것이 아니기 때문입니다. 장애 유무를 떠나서 누군가는 나와 조금 다른 것을 자연스럽게 받아들일 수 있도록 모두가 더 노력해야 될 것 같습니다. (물론 저를 포함해서 ^^) 앞으로 네이버 서비스가 차별, 다름이 없는 서비스가 될 수 있도록 더 노력하겠습니다. 감사합니다.

장애인을 차단하는 세계 최초 신기술.

2010-04-16T02:43:19+09:00

한국인터넷진흥원(KISA)은 어제 마우스 장치에 완전히 의존하는 비밀번호 입력 방식 '시큐어 패쓰'를 세계 최초로 개발했다고 언론에 공개 했습니다. 정말 어이가 없고 우리나라 IT 기술이라는게 이 정도로 후진국인가 창피해서 고개를 못 들 지경입니다. 한번 보시죠.

전적으로 마우스(드래그 앤 드롭)를 이용한 비밀번호 입력 방식으로 키보드 사용자는 이용할 수 없다.

시각장애인은 마우스 포인터를 볼 수 없기 때문에 마우스를 사용할 수 없습니다. 또한 팔을 자유롭게 사용할 수 없는 지체 장애인은 마우스를 사용할 수 없기 때문에 마우스 스틱(빨대 모양의 막대기)이라는 장비를 이용해서 키보드를 두드립니다. 태어 날때부터 이런 장애를 지닌 사람도 있고 불의의 사고를 당해서 이렇게 되신 분들도 있습니다. 이런 장애인들은 비밀번호를 어떻게 입력해야 하나요?

더군다나 한국인터넷진흥원 이라는 곳에서 이런 기술을 개발했다고 하는데 이건 한국 인터넷을 진흥 시키기는 커녕 오히려 한국 인터넷을 망치는 기술 입니다. 이런 기술을 사용하게 되면 장애인차별금지 및 권리구제 등에 관한 법률에 의하여 소송 대상이 되고 법적 분쟁에 휘말렸을 경우 승소할 확률은 0% 입니다.

사용하지 말아야 할 기술 입니다.

스마트폰에서도 쓸 수 있는 방안을 마련한다구요? 일단 스마트폰에는 마우스가 없구요. 마우스 전용 이벤트 헨들러 같은 것도 없습니다. 스마트폰에서 마우스를 이용할 수 있는 전용 어플리케이션이라도 지원 하시게요? 어떻게 하시려는지 참 궁금합니다. 그것도 세계 최초로 개발해서 같이 특허 내십시오.

다 같이 잘 살기가 이렇게 힘들어서야 원.

jQuery를 이용하여 FAQ 목록 만들기.

2010-03-26T01:15:40+09:00

FAQ(Frequently Asked Question) 목록은 어떤 요소로 마크업 할 것인지가 가장 고민이 됩니다. 예를 들면 다음과 같은 다양한 마크업 방법이 있는데요.

ul > li > (p+p)
ul > li > (hx+p)
ul > li > dl > (dt+dd)
dl > (dt+dd) + (dt+dd) + (dt+dd) ...
dl(dt+dd) + dl(dt+dd) + dl(dt+dd) ...

오늘 제가 선택한 방법은 첫 번째 방법 이었습니다. 이 방법이 정답이라고 단적으로 말하기는 어렵고 다른 방법이 틀렸다고 말하기도 어렵습니다. HTML 구조에 정답이 있는것은 아니니까요. 하지만 제가 첫 번째 마크업을 선택한 이유를 설명드려 보겠습니다. 솔직히 말씀 드리자면 이 선택에 대한 확신은 아직 없습니다.

질문과 답변 목록은 '목록' 이기 때문에 일단 'ul, ol, dl' 요소 가운데 하나를 사용하는 것이 적합하다고 판단 했습니다.
'ol' 목록은 항목의 배치 순서에 의미가 있는 경우 사용하면 되는데 '질문/답변' 목록은 배치 순서를 바꿔도 의미가 달라지지 않는 비 순차 목록이라고 판단해서 제외 했습니다.
'ul' 목록은 항목의 배치 순서에 의미가 없는 경우 사용하면 되는데 '질문/답변' 목록은 배치 순서에 의미가 없다고 판단해서 사용 했습니다.
'dl' 목록은 정의 목록으로써 질문과 답변 형식에 사용해도 괜찮다고 판단 했지만 한 쌍의 'dt+dd' 요소를 한 번 더 감싸주는 마크업이 필요한 경우 CSS 스타일을 적용하는데 제한이 발생하기 때문에 제외 했습니다.
'dl+dl' 형식은 'dl' 요소를 '항목의 그룹핑' 아닌 단 하나의 '항목'에만 적용했기 때문에 의미에 맞지 않다고 판단해서 제외 했습니다.
'li > dl > (dt+dd)' 형식은 목록 안에 또 다른 목록을 포함시키는 형태로써 하나의 항목을 두 번이나 목록 요소로 중첩 마크업 하는 것이 남용이라고 판단해서 제외 했습니다.
'ul > li > (p+p)' 형식으로 마크업 하는 것은 '질문/답변'을 모두 각각의 문단으로 볼 수 있기 때문에 적합하다고 판단 했습니다. 그러나 '질문'과 '답변'을 동일한 요소 'p'로 마크업 했다는 점에서 여전히 뒷맛이 개운치가 않네요.
'li > (hx+p)' 형식은 목록 안에 제목(hx) 요소가 들어가는 형태로써 의미상 가장 적합하다고 판단 했지만 목록 안에서 'hx' 요소를 사용하는 것이 'hx'를 남용하는 것은 아닌지 구조의 적절함에 확신이 서지 않아서 제외 했습니다. 그러나 만약 'li>(p+p)' 구조를 선택하지 않았다면 이것을 선택했을 것입니다.
만약 한 쌍의 '(dt+dd)' 요소를 'dl' 요소로 직접 감싸는 대신 'di'(definition item)와 같이 한번 더 묶어주는 마크업 요소가 존재 했다면 저는 'dl' 요소를 선택했을 것입니다. 제가 이상적이라고 생각하는 마크업 구조는 'dl > di > (dt+dd)' 이런 구조 인데 'di' 요소는 실제로는 존재하지 않는 요소이므로 착오 없으시길 바랍니다.

jQuery를 이용한 FAQ 목록 입니다. 이런 효과를 흔히 아코디언 효과(accordion effect)라고 부릅니다. 이 예제를 새 창으로 보기

a 요소에 유효한 URL 사용하기

질문은 'a' 요소로 마크업 되어 있고 'href' 값으로는 유효한 'URL'(#a1, #a2, #a3 ...)이 포함되어 있습니다. 유효하다는 것은 링크의 목적지가 존재하고 링크 주소를 따라가면 기대했던 자원이 있다는 것을 의미 합니다. 만약 누군가에게 특정 '질문/답변' 항목을 링크 주소를 통해 알려주어야 한다면 여러분은 마우스 우측 버튼을 눌러 '링크 주소 복사' 기능을 이용할 수 있을 것입니다. URL이 유효하지 않다면 이런 편의는 불가능한 일입니다. 'href' 값으로 의미 없는 값 '#'을 넣는다면 클릭 또는 키보드 Enter를 내리 쳤을 때 키보드 포커스는 페이지 맨 처음으로 이동해 버리기 때문에 화면 낭독기 사용자(시각 장애인)는 처음부터 다시 탐색을 시도해야 합니다. 유효한 URL을 작성하는 것은 사용성과 접근성을 모두 높여주는 일로써 되도록 모든 링크에는 유효한 URL 값을 포함해야 합니다.

FAQ의 의미 있는 마크업은? - 추지호
목록(ol ul dl)의 올바른 활용 문제 - 백남중

CSS Bar Graph. Horizontal. Vertical.

2010-03-17T21:23:17+09:00

목록(ul) 요소를 이용하여 CSS로 모양을 낸 수직 막대 그래프 입니다. 이 예제를 새 창으로 보기

목록(ul) 요소를 이용하여 CSS로 모양을 낸 수평 막대 그래프 입니다. 이 예제를 새 창으로 보기

다양한(p, ul, ol, dl) 요소에 콘텐츠로 포함되어 CSS로 모양을 낸 인라인 수평 막대 그래프 입니다. 이 예제를 새 창으로 보기

배경 이미지와 CSS로 모양을 낸 별점 그래프 입니다. 이 예제를 새 창으로 보기

jQuery+CSS Tree Navigation.

2010-03-15T21:30:13+09:00

jQuery를 이용한 Tree Navigation 예제는 어렵지 않게 찾을 수 있었는데요. 키보드만으로도 조작이 가능한 접근성 있는 예제는 찾기가 쉽지 않더라구요. 공개된 소스코드를 수정해서 사용할까 하다가 공부도 할 겸 해서 직접 만들어 봤습니다.

중첩 목록(ul>li>ul>li) 구조로 마크업 했고 현재 페이지 활성 상태를 표시 하려면 해당 li 요소에 .active 클래스를 추가(서버측 스크립트로)해 주면 됩니다. 계층 구조가 무한대로 깊어지는 상황도 처리가 가능 합니다. '+/-' 토글 버튼에 키보드가 접근해서 하위 목록 토글 인터렉션을 조작할 수 있습니다.

예제를 새 창으로 보기

메뉴 건너 뛰기 링크(Skip Navigation).

2010-03-13T03:11:35+09:00

헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법
반복되는 콘텐츠 블럭을 우회하는 방법
메뉴 건너 뛰기 링크에 관한 쟁점
키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크
글로벌 네비게이션을 본문 콘텐츠보다 늦게 마크업 하는 경우
지나치게 많은 '** 건너 뛰기' 제공은 오히려 공해
메뉴 건너 뛰기에 관한 더 많은 의견들

메뉴 건너 뛰기 링크란 하나의 웹 사이트에서 모든 페이지에 걸쳐 반복해서 등장하는 글로벌 네비게이션과 로컬 네비게이션을 건너 뛸 수 있는 링크를 말합니다. 마우스를 함께 사용하는 사람은 이 링크가 왜 필요한지 알기 어렵지만 키보드만으로 웹을 탐색하는 사람들에게는 상당히 중요한 의미를 갖습니다.

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) 2.4.1 블럭 우회: 여러 웹 페이지에서 반복되는 콘텐츠 블럭을 우회할 수 있어야 한다. (수준 A)
WCAG 2.0 : 2.4.1

헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법

시각 장애인은 마우스 포인터를 볼 수 없기 때문에 키보드만으로 웹을 탐색을 합니다. 물론 Tab키와 방향키 만으로 탐색을 하는 것은 아닙니다. 화면 낭독 프로그램은 '링크만, 헤딩만' 따로 모아서 탐색할 수 있고 특히 '링크' 텍스트를 설명력 있게 제공하는 것도 당연히 좋지만 적절한 '헤딩'을 제공하는 것은 더더욱 중요합니다. 헤딩은 콘텐츠 블럭을 건너 뛸 수 있는 단서가 되기 때문이고 시각 장애인에게는 불필요한 콘텐츠를 잘 건너 뛰게 해주는 것이 매우 중요합니다. 시각이 있는 사람들도 자각하지 못하는 사이에 이미 불필요한 콘텐츠를 무시하는 것에 학습되어 있습니다. 눈에 잘 띄도록 만든 배너를 빠르게 무시하는 것은 방법이라기 보다 본능적인 반응에 가깝습니다. 헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법 입니다.

반복되는 콘텐츠 블럭을 우회하는 방법

콘텐츠와 콘텐츠 사이를 빠르게 건너뛰기 위하여 시각 장애인에게 헤딩(h1, h2, h3, h4, h5, h6) 정보가 중요하다는 사실을 말씀드렸습니다만 사실 오늘의 주제는 '메뉴 건너 뛰기' 입니다. 메뉴에 헤딩을 제공하는 사람은 별로 없고 제공해야 한다는 지침도 없으며 오히려 제공했을 때 더 어색하고 불편할 수 있습니다. 따라서 메뉴에는 보통 헤딩이 없습니다. 하지만 한 두 페이지 정도만 탐색해 보면 시각이 있고 없고를 떠나서 누구나 그것이 메뉴라는 것을 알게 됩니다. 같은 패턴의 데이터가 반복 되기 때문입니다.

한빛고등학교는 웹 사이트는 모든 페이지에 메뉴 건너 뛰기 링크를 제공하고 있다

이렇게 모든 페이지마다 지속적으로 반복되는 네비게이션들을 키보드 사용자는 어떻게 탐색해야 할까요? Tab키를 계속 누르고만 있어야 할까요? 다 필요해서 있는 것이니 반복 되더라도 계속해서 탐색하고 듣고 있어야 하는 것일까요? 아닐껍니다. 건너 뛸 수 있는 장치를 제공해 주어야 합니다. 이미 위에서 'WCAG 2.4.1' 구절을 인용했지만 블럭을 우회할 수 있어야 한다는 지침은 '수준 A' 입니다. 수준 A는 최소한 지켜야 하는 수준으로써 가장 중요하다는 의미와 맞닿아 있습니다. 우리는 반복되는 콘텐츠 블럭을 건너 뛸 수 있도록 하기 위하여 '메뉴 건너 뛰기' 링크를 제공할 수 있습니다.

메뉴 건너 뛰기 링크에 관한 쟁점

메뉴 건너 뛰기 링크를 제공해야 한다는 의견에는 거의 모든 웹 접근성 전문가들이 동의하지만 그것을 제공하는 방법에는 크게 다음과 같은 세 가지 다른 구현 방법이 있습니다.

메뉴 건너 뛰기 링크는 시각이 있는 사람도 볼 수 있도록 웹 페이지 최 상단에 항상 노출해야 한다.
메뉴 건너 뛰기 링크는 시각이 있는 사람에게는 방해가 되므로 숨김 처리하고 키보드가 접근할 때에만 노출해야 한다.
메뉴 건너 뛰기 링크는 시각이 있는 사람에게는 방해가 되므로 항상 숨김 처리 해야 한다.

여러분은 어떤 의견에 동의 하시나요? 저는 두 번째 방법을 가장 좋은 방법이라고 생각하고 있습니다. 만약 여러분이 '네이버' 웹 페이지를 개발한다면 여러분들은 모든 네이버 웹 사이트 최 상단에 '메뉴 건너 뛰기' 링크를 넣어야 한다고 생각 하시나요? 저는 그렇게 생각하지 않습니다. '메뉴 건너 뛰기' 링크는 시각이 있는 사람에게는 오히려 건너 뛰고 무시해야 할 콘텐츠가 됩니다. 마우스를 조작하는 사람에게 이 링크는 필요치 않으니까요.

그렇다고 해서 항상 숨김 처리 하는 것도 문제가 됩니다. 왜냐하면 시각 장애인만 이 링크를 사용하는 것은 아니기 때문 입니다. 시각은 있지만 손과 발을 자유롭게 사용할 수 없는 지체 장애인은 마우스 스틱이라는 빨대 모양의 막대를 이용해서 키보드만으로 웹을 탐색 합니다. 손과 발이 자유롭지 못하기 때문에 입에 막대를 물고 키보드를 두드립니다. 메뉴 건너 뛰기 링크에 접근 했을 때 링크가 화면에 보여야 하는 이유는 이렇게 시각은 있지만 키보드만을 사용할 수 밖에 없는 장애인들에게 유용하기 때문 입다. 간혹 TV에서 팔이 없는 지체 장애인이 발로 마우스를 조작하는 모습을 본 기억이 있으실 껍니다. 하지만 발이 있다고 해서 모든 지체 장애인이 발로 마우스를 자유롭게 조작하는 것은 아닙니다.

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크 예제를 만드는 것은 정말 쉽습니다. 자바스크립트는 필요치 않고 HTML과 CSS만으로 가능합니다. <a> 요소의 width, height, overflow 속성을 조절해서 기본적으로 화면에 보이지 않도록 처리한 다음 a:focus 상태일 때에는 width, height 값이 auto가 되도록 처리하는 것입니다.

키보드 접근시에만 메뉴 건너 뛰기 링크가 화면에 보이는 예제 - 이 예제를 새 창으로 보기

글로벌 네비게이션을 본문 콘텐츠보다 늦게 마크업 하는 경우

글로벌 네비게이션을 본문 콘텐츠보다 나중에 마크업 하는 경우도 있습니다. 화면에 보이는 것과 마크업 순서를 다르게 처리 한다고 해서 항상 논리적인 순서가 잘 못 되었다고 말 할 수는 없습니다. 지금 제가 사용하고 있는 Textyle 블로그와 Wordpress 블로그는 모두 본문 콘텐츠가 먼저 마크업 되고 글로벌 메뉴가 나중에 마크업 되어 있습니다. 이런 경우라면 '메뉴 건너 뛰기' 링크보다 '본문 건너 뛰기' 링크가 더 적절할 것이고 나아가 '건너 뛰기 링크'는 생략해도 됩니다. 본문 콘텐츠는 모든 페이지에서 반복되는 내용도 아니고 많은 링크가 포함되어 있지도 않기 때문 입니다.

지나치게 많은 '** 건너 뛰기' 제공은 오히려 공해

반복되는 블럭을 건너 뛰어야 한다는 지침을 잘 못 이해해서 모든 웹 페이지 상단에 굉장히 많은 '** 건너 뛰기' 링크를 제공하는 경우가 있습니다. 이것은 오히려 건너 뛰어야 할 공해 콘텐츠가 됩니다. 건너 뛰어야 할 것은 '반복되는 블럭'인데 마치 한 페이지의 '목차' 처럼 제공하는 경우가 있다는 것입니다. 건너 뛰기 링크는 보편적인 경우에 '메뉴 건너 뛰기' 하나면 충분 합니다. 한편 모든 페이지에서 반복되지는 않지만 상당히 많은 버튼이나 링크가 존재한다면 해당 블럭을 건너 뛸 수 있도록 건너 뛰기 링크를 제공하는 것이 좋습니다.

네이버 뉴스 클러스터링 - 키보드가 접근 할 때 화면에 보이는 메뉴 건너 뛰기 링크 하나를 제공하고 있다.
네이버 스마트에디터 베이직(오픈소스) - 본문에 등장하는 콘텐츠로써 키보드가 접근 할 때 도구 모음을 건너 뛸 수 있는 링크를 제공하고 있다.
미디어 다음 - 화면에 보이지 않는 메뉴 건너 뛰기 링크 하나를 제공하고 있다.

메뉴 건너 뛰기에 관한 더 많은 의견들

Skip Navigation은 Quick Link가 아닙니다. - 성민장군
KWCAG 2.0 의 Skip Navigation(건너뛰기 링크) – 본문으로 가면 그만? - 양군팩토리

CSS Tab Navigation + List Item Navigation.

2010-03-11T21:54:54+09:00

HTML/CSS와 jQuery를 이용하여 비교적 단순하지만 상당히 빈번하게 사용되는 Tab Navigation을 마크업 했습니다. 선으로 처리된 탭, 면으로 처리된 탭, 최근 게시물을 보여주는 목록 아이템 형태의 탭 디자인 입니다.

Tab Navigation 예제의 특징

중첩 목록(ul>li>ul>li)을 이용한 탭 네비게이션 예제.
목록의 계층 구조가 논리적으로 마크업 되어 있다.
키보드만으로도 접근이 가능하고 키보드 접근 순서가 논리적으로 처리되어 있다.
jQuery 사용.

CSS Vertical Navigation Bar.

2010-03-10T22:15:46+09:00

얼마 전 공유했던 'CSS Navigation Bar'는 '수평+서브메뉴 드롭다운' 네비게이션 이었는데요. 오늘 공유하는 것은 '수직+서브메뉴 드롭다운' 네비게이션 입니다. 수평 메뉴보다 수직 메뉴가 모든 면(HTML/CSS/JS)에서 코드가 더 간결하고 만들기도 쉽네요.

예제를 새 창에서 보기

특징

중첩 목록(ul>li>ul>li) 구조로 마크업 했습니다.
키보드만으로도 조작이 가능하고 키보드의 접근 순서는 논리적으로 처리되어 있습니다.
서브메뉴 토글에 jQuery의 .slideDown() 및 .slideUp() 효과를 사용 했습니다.
이미지를 한 번 사용 했습니다.

유의사항

간혹 이런 수직 메뉴의 서브 메뉴 펼침 동작을 onmouseover 이벤트 헨들러로 처리하는 경우가 있는데요. 그런 경우 사용성이나 접근성이 정말 나빠집니다.

사용성이 나빠지는 이유는 아래쪽에 있는 메뉴를 선택하기 위하여 링크 위를 onmouseover 하는 순간 해당 링크의 서브 메뉴가 펼쳐지는데 이는 보통 원치 않는 동작이기 때문입니다.

접근성이 나빠지는 이유는 마우스와 동등하게 키보드가 접근할 수 있도록 onmouseover 헨들러와 onfocus 헨들러를 병행해서 작성하지 않는 경우 입니다. 이런 경우 키보드가 서브 메뉴를 펼칠 수 없기 때문에 키보드 사용자는 서브 메뉴에 접근할 수 없습니다. onmouseover 헨들러를 사용했다면 반드시 onfocus 헨들러를 병행 작성하여 동등한 기능을 처리할 수 있도록 해야 합니다.

따라서 수직 메뉴를 드롭다운 형태로 열고 닫는 오늘의 예제와 같은 경우 onmouseover 이벤트 헨들러 사용은 절대적으로 피하는 것이 좋고 onmouseover 이벤트 헨들러 사용은 보편적인 다른 모든 경우에도 최소화 하는 것이 좋습니다.

NHN Burning Day 2010 참가.

2010-03-07T09:18:45+09:00

NHN은 2008년부터 사내에서 Burning Day 라는 행사를 시작 했습니다. 이 행사의 기본적인 개념은 개발자들이 평소에 생각하고 있던 아이디어를 구체화 시켜서 사내에 공유하는 것입니다. 일년에 한 번쯤은 각자의 아이디어와 열정으로 밤을 하얗게 불살라 보자는 거죠.

이건 정말 대박 아이디어인데 사람들은 왜 몰라줄까?

이런 생각은 평소에 누구나 가질 수 있죠. 그래서 1박 2일 동안 어떤 주제를 막론하고 원하는 것을 만들어 사람들에게 보여줄 수 있습니다. 이런 행사에서 공감을 많이 받게 되면 그 아이디어는 사업이 되거나 적어도 기존의 서비스들을 개선하는데 훌륭한 밑천이 될 것입니다.

명찰과 생존킷

저는 올해 저희 XE 팀원들과 함께 처음으로 참가를 했습니다. 개인적으로 평소에 갈망하던 아이디어가 있던 것은 아니었지만 팀원들과 좋은 추억을 만들 수 있다는 기대감이 더 컸습니다. 다양한 주전부리를 제공하는 것도 그렇구요. 휴대폰으로 미투데이에 생존킷을 찍어 올렸더니 궁금해하시는 분들이 있어서 노트북 위에 펼쳐놓고 한 번 더 찍었죠. 평소에는 손도 안대던 것들인데 이렇게 지급해 주니까 먹게 되네요. 이 밖에도 각종 먹거리들이 행사장 밖에 수북히 쌓여 있어서 오며가며 집어먹게 되어 있습니다.

생존킷 내용물

행사에 참여하기 위해 평소부터 뭔가 준비를 할 수도 있었습니다. 꼭 단 하루만에 무언가를 해야 하는것은 아닌거죠. 아마도 미리 준비를 해왔다면 좀 더 여유있게 즐길 수 있었을지도 모르겠네요. 하지만 저희 팀처럼 정말 아무 준비도 없이 노트북만 딸랑 들고와서 시작해도 괜찮은것 같아요. 기획, UI, 프로그램 산출물까지 단 하루만에 완성시켜야 한다는 제약을 즐기는 것도 매력 있던데요.

새벽 4시 버닝데이 행사장 풍경

행사장은 이렇게 작은 테이블과 의자들이 빼곡히 들어서 있는데 사람들은 정말 밤 새도록 이러고 있답니다. 오래간만에 딱딱한 의자에 오래 않아 있으려니까 사무실에 있는 허먼밀러 에어론 의자가 무지하게 그립더라구요. 물론 이렇게 않아서 개발만 하는것은 아니구요. 개발자들에게는 가볍게 즐길 수 있는 프로그래밍 문제도 제공이 되는데 제한 시간 내에 누가 가장 정확하고 빠르게 풀었는지가 실시간으로 화면에 중계 되기도 합니다. 그리고 순위별로 10만원에서 5천원까지의 상금이 즉시 지급 됩니다. 이 밖에 휴게실에 가면 각종 보드게임과 닌텐도 게임도 즐길 수 있구요.

중식으로 제공된 아웃백 도시락

버닝데이의 또 다른 이름은 사육데이 입니다. 식사부터 야식에 군것질 꺼리까지 1박 2일동안 계속해서 나오기 때문에 그런 별칭이 붙었다죠. 도시락은 식성따라 즐길 수 있도록 여러 종류가 나오는데 그 중 아웃백 도시락이 비주얼이 좋길래 집어 들었습니다.

소스코드 등록 및 발표자에게 지급된 무선 키보드 마우스 세트

먹거리도 먹거리지만 이 행사의 백미는 가장 마지막에 있는 '발표' 시간 입니다. 수십여 참가 팀들은 하루동안의 결과물들을 정확히 '4분'동안 다른 참여자들에게 소개할 수 있습니다. 물론 이건 의무적인것은 아니지만 대부분의 지원자들이 발표를 한답니다.

개인적으로 모든 아이디어에 흥미가 있었던 것은 아니었지만 대부분의 결과물들은 일단 독창적 입니다. 참가자들은 서로 다른 참가팀들의 발표를 보면서 평가를 하게 되는데 공감을 많이 받은 아이디어는 본선에 오르게 되고 본선 진출자는 몇 일 후에 다시 만나서 경합을 벌이게 된답니다. 본선에 오른 아이디어들이 빨리 세상의 빛을 볼 수 있다면 좋겠네요.

버닝데이 행사를 총괄하고 있는 권순선님

마지막으로 버닝데이에 참가하면서 느낀 점은 '버닝데이=개발자들의 축제' 라는 것입니다. 공대생들의 유머가 통하고 개발 오덕들이 기를 활짝 펼 수 있는 그런 시간과 공간을 경험할 수 있었습니다. 저는 공대생도 아니고 프로그래머도 아니지만 앞으로 기회가 된다면 매년 참가하고 싶습니다. 이런 즐거운 자리를 만들어준 회사와 담당자분들 그리고 함께 했던 동료들에게 감사한 마음입니다.

Modal Windowed Login UI.

2010-03-04T23:47:39+09:00

오늘은 XE에 사용하려고 모달 윈도우 처리된 로그인 UIO(User Interface Object)를 하나 만들었습니다. jQuery를 이용해서 스크립트도 직접 작성해 봤는데 잘 한건지 한 번 봐주시면 좋겠네요.

미리 알려드립니다만 저는 주로 인터렉션을 프로토타이핑 해서 보여줄 목적으로 자바스크립트를 작성하기 때문에 제 블로그에서 보여드리는 예제 코드가 모두 XE에 반영되는 것은 아닙니다.

예제를 새 창으로 보기

HTML

'LOG-IN' 링크에 accesskey 속성을 사용. 'Alt+L' 또는 'Alt+Shift+L' 키를 사용하면 링크에 직접 접근.
논리적인 키보드 접근 순서. 로그인 레이어를 열거나 닫더라도 포커스는 초기화 되지 않고 문맥에 알맞게 순서를 유지.

CSS

화면 전체를 덮는 반투명 레이어.
로그인 상자를 화면의 정 중앙에 배치.
서밋 버튼을 텍스트로 처리해서 텍스트를 교체할 수 있음.

Javascript

'LOG-IN' 링크를 클릭해서 모달 윈도우 처리된 레이어 띄우기.
인풋에 포커스가 들어가거나 빠질 때 '레이블' 텍스트를 숨기거나 보여주기.
'로그인 유지' 항목에 체크하면 경고문 보여주기.
'ID/PW'를 입력하지 않았을 때 상황에 맞는 알럿 띄우기.
'Open ID' 링크를 클릭하면 오픈 아이디 화면으로 전환하기.
'ESC'키를 누르거나 '여백' 또는 'X' 버튼을 클릭하면 창 닫기.

P.S.

저는 얼마 전부터 텍스타일에서 글을 쓰고 있습니다. 여러분이 만약 이 글을 제 워드프레스에서 보셨다면 배달된 글을 보고 계신 겁니다. 텍스타일에서 작성한 글은 워드프레스, 미투데이, 트위터 등으로 자동으로 배달 된답니다. 번거롭게 퍼다 나르고 다닐 일이 없어서 좋네요. 텍스타일 한 번 사용해 보세요. 즐거운 글쓰기 경험도 해 볼겸 해서 말이죠. ^^

CSS Drop Down : Emulate Select/Option.

2010-02-18T02:37:25+09:00

서식 제어 요소(Form Control Element)를 디자인 하는 것은 상황에 따라 접근성을 떨어뜨리는 경우가 있기 때문에 제한되어야 하고 신중하게 사용해야 합니다. 이미 이전에 포스팅을 했지만 다시 한번 환기하는 차원에서 제한되어야 하는 서식 요소들은 어떤 것들이 있는지 살펴보겠습니다.

스타일 변경이 제한된 서식 제어 요소들
HTML Markup	View
input type="checkbox"
input type="radio"
input type="file"
input type="hidden"	화면 출력 안됨
select, option

서식 제어 요소의 디자인을 제한하는 이유

이런 서식 제어 요소들의 디자인을 변경하는 것은 일단 브라우저들이 지원하지 않습니다. 이런 이유 때문에 이것을 디자인 하려는 시도는 실제로는 기능하지 않는 가짜 마크업을 남발하게되고 웹 접근성을 떨어뜨리는 요인으로 작용합니다. 하나의 콘트롤을 디자인 하기 위하여 화면에 보이는 마크업과 실제로 기능을 수행하는 마크업을 각각 따로 작성하게 되면 화면낭독기 사용자들은 화면 표시를 위한 가짜 마크업 때문에 곤경에 빠지는 상황이 연출됩니다.

그리고 간혹 단순한 텍스트 링크 기능을 수행함에도 불구하고 라디오 버튼을 장식적인 요소로 사용한 다음 라디오 콘트롤에 자바스크립트를 입혀서 페이지 이동을 처리하는 고품격(?) 사용자 경험을 제공하기도 하는데 매우 잘못된 방법중의 하나 입니다.

모든 서식 제어 요소들은 사용자가 '전송' 버튼을 누르기 직전까지 아무짓도 하지 않고 기다려야 할 의무가 있습니다. 왜냐하면 그것이 바로 서식 제어 요소들의 올바른 사용법이고 시각 장애인들은 그런 표준화된 그리고 전통적인 사용자 인터렉션에 의지해서 웹을 탐색하고 있기 때문입니다.

"라디오 버튼을 눌렀을 뿐인데 페이지가 이동할 줄은 몰랐어요. 저는 전송 버튼을 누르지도 않았거든요."

<select> 콘트롤을 본래 목적에 맞게 사용하기

한편 서식 제어 요소를 사용할 때 사용자 입력을 전송하는데 쓰지 않았다고 해서 무조건 틀렸다고 말할 수도 없습니다. CSS가 일반적으로 널리 퍼지기 이전에 서식 제어 요소들은 다른 HTML 요소들이 흉내낼 수 없는 효과적인 UI 콘트롤을 제공했기 때문에 그 이점만을 취하기 위한 활용사례가 많았습니다. 현재까지도 흔하게 볼 수 있는 예가 바로 <select> 콘트롤 입니다. 본래의 목적은 단일 또는 다중 선택된 사용자의 선택값을 서버측에 전송하기 위한 목적이었지만 '패밀리 사이트 바로가기, 유관 기관으로 이동'과 같이 단순하게 텍스트 링크로 처리해도 될만한 UI에 지금까지도 여전히 <select> 요소를 사용하고 있습니다. 이 때 자바스크립트로 URL 값을 처리해서 넘기는 경우도 있고 서버측 스크립트로 값을 처리해서 넘기는 경우도 있는데 어느편이 더 유니버설한 설계 방법인지는 여러분이 직접 판단해 보시기 바랍니다.

하지만 한 발 더 나아가 저는 더 이상 <select> 콘트롤을 이용하여 페이지 이동하는 기법을 사용할 필요가 없다고 생각합니다. 자바스크립트나 서버측 스크립트를 작성해서 페이지를 이동하는 방법보다 더 쉬운 방법이 있기 때문입니다. CSS 배워서 이런데 써먹을 수 있습니다. <select> 콘트롤은 이제 그만 휴가 보내고 CSS에게 일을 시켜 보세요. <select> 요소의 드롭다운 콘트롤은 고작 '숨은 링크 목록'을 토글해서 보이거나 숨기는 인터렉션일 뿐입니다.

그럼에도 불구하고 <select> 콘트롤이 사랑받는 이유

요소 본래의 목적에 맞지 않는 마크업과 복잡한 스크립트의 사용을 유발함에도 불구하고 <select> 콘트롤은 여전히 기획자, 디자이너, 개발자에게 사랑받고 있습니다. 왜 그럴까요?

좁은 공간을 효과적으로 사용할 수 있기 때문에
클릭하면 숨은 목록을 볼 수 있는 전통적인 인터페이스로써 이미 대중에게 학습되었기 때문에
오랜 세월에 걸쳐 잘 작성된 레거시 코드가 있고 새로 만들 때 복사 후 붙여넣기만 하면 되니까

정도로 요약할 수 있겠습니다. 결국 우리는 <select> 라는 콘트롤을 본래의 목적에 맞게 사용하되 '긴 직사각형의 우측 끝에 화살표가 달린 모양'만 취하면 되는 겁니다.

결론 : <select> 형태는 취하고 마크업은 버리자

위의 두 예제는 같은 모양을 하고 있지만 첫 번째 예제는 링크이고 두 번째 예제는 단일 선택을 위한 폼 콘트롤 입니다. 폼 콘트롤 우측에 'GO' 버튼이 보이시나요? '사용자가 폼을 전송하기 전까지는 아무짓도 하지 않아야 한다'는 원칙을 실천하기 위하여 존재하는 버튼 입니다. 'GO' 버튼이 없으면 어떻게 되냐구요? 아마도 키보드 사용자는 다른 항목을 선택할 기회를 갖지 못하고 첫 번째 항목을 선택하는 순간 이미 다른 페이지로 이동되어 있거나 또는 전송 버튼을 찾느라 곤경에 빠질 것입니다. 저 'GO' 버튼이 있음으로 인해서 마우스를 사용하는 대부분의 사용자들은 불편함을 느낄 수도 있을 것입니다. 하지만 '누구나 사용'할 수 있도록 유니버설하게 개선되었기 때문에 '인류 행복의 총량'에는 큰 변화가 없을 것입니다.

다행히도 저렇게 단일 선택 옵션이 하나만 존재하는 경우 폼 대신 첫 번째 예제와 같이 링크로 처리할 수 있는 경우가 거의 대부분 입니다. 폼 대신 링크로 처리하게 되면 'GO' 버튼이 필요가 없기 때문에 모든 사람들이 더 기뻐할 것입니다. 링크 목록은 클릭하기 전까지 펼침 상태로 존재하고 Enter 키를 받아야만 페이지 이동을 하기 때문에 'GO' 버튼이 없어도 키보드만으로 제어를 할 수가 있죠.

위 제시된 예제는 처리해야 할 콘텐츠가 '링크' 인지 또는 '진짜 폼의 선택'을 위한 것인지 명확하게 이해한 다음 사용해야 합니다. 단순히 링크로 처리해야 할(처리해도 될) 항목을 두 번째 예제로 마크업 한다면 오늘 제 포스팅은 말짱 도루묵 입니다. 부디 의미와 목적에 맞는 마크업을 선택해서 사용해 주실것을 부탁 드립니다. 이번 예제도 행복한고니로부터 도움을 받았습니다. 요즈음은 행복한고니가 짬짬이 알려주는 jQuery 덕분에 아주 즐거운 나날들을 보내고 있답니다. ^^

CSS Pagination Without Image.

2010-02-13T00:27:29+09:00

오늘은 민족 대 명절 기념으로 예전에 만들어 두었던 페이지네이션 예제를 소개해 드립니다. 아래 정도의 레퍼런스만 있다면 더 이상 페이지네이션 디자인을 하지 않아도 될것 같네요. 단 하나의 이미지도 사용하지 않고 만들었기 때문에 그냥 HTML/CSS 소스를 퍼가서 붙여넣기만 하시면 되요. 참 편리 하겠죠? ^^

예제를 새 창으로 보기

이렇게 페이지네이션을 만들 때 현재 페이지를 향한 링크는 걸지 않는 것이 사용성이 더 좋습니다. 자기 페이지를 향한 링크가 필요하지 않기 때문이구요. 시각장애인들에게는 현재 위치가 어딘지 알려주는 이정표와도 같은 역할을 하기 때문입니다. 저는 현재 페이지를 <a> 대신 <strong> 요소로 마크업 했습니다. 현재 페이지의 번호를 <a> 요소로 마크업 하고 스타일시트를 이용해서 색상이나 글꼴 굵기를 바꾸는 사례는 접근성이 좋지 않은 사례 입니다.

CSS Navigation Bar.

2010-02-11T00:38:45+09:00

최근 저희 팀에서는 ProjectXE 라는 것을 준비하고 있습니다. 이슈트래커 또는 버그 트래킹 시스템이라고 불리우는 종류의 프로그램이죠. 현재 issuetrackerXE 라는 이름으로 배포되고 있는 모듈의 기능과 디자인을 조금 더 개선시킨 패키지 버전이라고 볼 수 있습니다. 제가 직접 기획도 했으니까 나중에 배포가 시작되면 피드백도 부탁드려야 겠네요.

이번에는 운이 좋게도 디자인팀으로부터 지원을 받았는데요. 이렇게 디자인팀으로부터 지원을 받은 디자인은 품질이 상당히 좋아서 한 번 쓰고 말기에는 정말 아깝더라구요. 재 활용 가치가 있는 UI 콤포넌트는 가끔 처음부터 재 사용을 염두해 두고 설계를 합니다. 물론 시간이 무척 오래 걸리는 단점은 있지만 다른 누군가의 시간을 분명히 단축해 줄꺼라 믿고 있습니다.

오늘 공유해 드릴 UI 콤포넌트는 평범한 네비게이션 바 입니다. 이런 종류의 네비게이션은 너무 흔해서 일년에 열두번도 더 코딩을 하지만 항상 재 사용을 염두하지는 않았기 때문에 할 때마다 새로 만들고 처음부터 다르게 코딩 합니다. 물론 디자인이 조금씩 달라지는 것도 이유가 있겠지만 다소 소모적인 부분이 있었던 것도 사실입니다. 보기에 평범해 보이지만 재 사용과 보편적 설계를 위해서 제가 이 네비게이션 바에 얼마나 많은 정성을 쏟았는지 한 번 설명드려 보겠습니다.

CSS Navigation Bar. 새 창으로 보기

보편적이고 사용성이 좋은

수평 네비게이션은 보편적인 형태지만 하위 메뉴를 처리하는 방법에는 크게 두 가지 형태가 있습니다. 하위 메뉴를 수평으로 늘어뜨리거나 또는 위 예제와 같이 수직으로 늘어뜨리거나. 그런데 이 두 가지 형태의 메뉴 구조는 사용성이 크게 다릅니다. 하위 메뉴를 수직으로 늘어뜨리는 것이 사용성과 확장성이 훨씬 좋습니다.

하위 메뉴를 수평으로 열게 되면 사용자는 정확하게 선택하기 위하여 'L'자 모양으로 마우스 포인터를 이동시켜야 합니다. 게다가 하위 메뉴 영역을 벗어날 때 하위 메뉴가 사라지도록 처리하는 경우 사용성은 더 나빠집니다. 원하는 메뉴 링크까지 이동하려면 조심스럽게 마우스 포인터를 옮겨야 하니까요. 하위 메뉴를 수직으로 펼치면 마우스의 이동 괘적은 'I'자 모양을 그리게 되고 마우스를 옮기는 과정에서 메뉴가 닫힐 위험은 사라집니다.

웹 표준과 접근성을 지키는

이런 메뉴 구조를 테이블 <table> 요소를 사용해서 마크업하면 의미에도 맞지 않고 접근성도 떨어집니다. 네비게이션 요소는 HTML로 표현할 때 '목록' 요소 <ul>, <li>로 마크업 해야 합니다. 동등한 수준의 내용이 같은 계층에서 여러번 반복 된다면 '목록'입니다. 시각장애인이 사용하는 화면 낭독기는 이런 목록에 대하여 목록의 '시작, 끝, 단계 그리고 항목의 개수'를 음성으로 알림으로써 목록에 대한 이해를 돕습니다. 상기 예제에서 'CSS X' 버튼을 누르면 네비게이션이 어떤 HTML 구조로 마크업 되어 있는지 확인할 수 있습니다. 이렇게 코딩된 네비게이션 바는 다음과 같은 장점을 갖습니다.

상-하위 계층 관계가 논리적으로 처리되어 CSS를 지원하지 않거나 걷어낸 장치(예:모바일)에서도 이해하기 쉽습니다.
모든 항목에 키보드 접근이 가능하고 키보드 접근 순서가 의미있게 처리되어 있습니다.

이 네비게이션 바는 키보드만을 사용할 수 밖에 없는 시각장애인과 지체장애인도 사용할 수 있습니다. 키보드만으로 탐색을 시도해 보세요.

유연하고 확장하기 좋은

하위 메뉴의 개수가 상당히 많이 늘어나는 상황에서 수평으로 열리는 하위 메뉴는 필연적으로 줄바꿈을 동반하거나 메뉴의 개수를 제한하게 되지만 수직으로 열리는 메뉴는 그럴 필요가 없기 때문에 메뉴 데이터가 가변적인 상황에서 확장성이 더 좋습니다.

메뉴의 전체적인 너비는 레이아웃에 맞게 가변폭으로 조절되고 메뉴 항목의 너비도 메뉴 이름의 길이에 따라 모두 가변폭으로 처리되어 있습니다. 디자인 때문에 글자 개수를 자르거나 제한 할 필요가 없습니다.

네비게이션 바의 색상을 바꾸기 위해 새로 이미지를 컷팅할 필요가 없습니다. CSS 편집을 통해 배경색과 보더 색상만 변경해 주면 끝입니다. 은은하게 처리된 그라디언트 효과는 배경색상 위에 반투명 흰색 그라디언트 PNG 이미지를 덧붙이는 기법으로 처리 했습니다.

이미 널리 쓰이고 있는

jQuery 자바스크립트 프레임웍을 사용했기 때문에 약간의 자바스크립트 코드를 추가하거나 변형하면 누구나 쉽게 사용할 수 있습니다. 물론 지금 그대로 사용해도 될만큼 이미 스크립트가 잘 처리되어 있습니다. 자바스크립트는 행복한고니에 의해 처리 되었습니다.

브라우저 호환성

다음과 같은 브라우저에서 테스트 되었고 호환성이 확보되어 있습니다.

Internet Explorer 6
Internet Explorer 7
Internet Explorer 8
Firefox 3
Chrome 4
Safari 4
Opera 10

이 네비게이션을 처리하기 위하여 테스트 했던 거의 모든 브라우저들의 버그를 다 만났던것 같습니다. 여러분이 보시기에 HTML 코드에 '이건 왜 이렇게 마크업을 했지?' 라고 의문이 든다면 그 부분이 바로 그 흔적 입니다. 특히 IE7 브라우저의 경우 링크 영역(width)을 제대로 렌더링하지 못하는 버그 때문에 상당히 고전을 했는데 결국 방법을 찾지 못하고 자바스크립트의 도움을 받아서 디버깅 했습니다. 코딩하는데 1.5일이 걸렸고 디버깅하는 시간도 1.5일이나 걸렸습니다. 3일동안 쳐다보고 있으니 아주 지겨워 죽겠더라구요.

XE 스킨 메뉴얼 : 위젯 스타일 스킨 만들기.

2009-08-24T17:40:20+09:00

위젯 스타일 스킨이란?
위젯 스타일 스킨 미리 보기.
위젯 스타일 스킨은 어느 디렉토리에 있나요?
새 위젯 스타일 스킨 만들기.
스킨 정보 'skin.xml' 편집하기.
CSS 이걸 불러? 말어? 'import/unload'.
'widgetstyle.html' 마크업 시작하기.
'widgetstyle.html' 제목 마크업 넣기.
'widgetstyle.html' 더보기 마크업 넣기.
'widgetstyle.html' 마크업 완성 예제.

위젯 스타일 스킨이란?

위젯 스타일 스킨은 위젯의 박스 디자인을 보완하기 위하여 만들어 졌습니다. 하지만 스킨만 있는 것은 아닙니다. 다음과 같은 중요 데이터를 추가할 수 있습니다.

위젯 헤더 - 위젯 블럭의 제목 데이터를 추가 할 수 있습니다.
목록 더보기 - 위젯 목록의 더보기 링크를 추가할 수 있습니다.

위젯 스타일 스킨은 다음과 같은 디자인 요소를 장식 합니다.

위젯 헤더
위젯 목록 더보기
위젯의 보더
위젯의 배경 색 / 글꼴 색

위젯 스타일 스킨 미리 보기.

아래 이미지는 XE에 탑재되어 있는 단순한 콘텐츠 위젯으로 게시물의 최근 데이터를 출력하는 화면 입니다. 아직 위젯 스타일이 적용되기 전의 모습 입니다.

아래 이미지는 XE에 기본으로 탑재되어 있는 위젯 스타일 스킨을 콘텐츠 위젯에 적용한 화면 입니다. 콘텐츠 위젯 목록에 '박스 디자인, 헤더, 더보기 링크'가 추가된 모습 입니다. 다양한 위젯 스타일 스킨이 존재 합니다.

위젯 스타일 스킨은 어느 디렉토리에 있나요?

/XE 설치 폴더/widgetstyles/

폴더에 있습니다.

새 위젯 스타일 스킨 만들기.

기존의 위젯 스타일 사본을 활용하는 것도 좋은 방법 이지만 HTML/CSS를 잘 다루시는 분들은 그냥 새로 만드시는 것을 더 권장 드립니다. ^^; 저는 myStyle 이라는 새 위젯 스타일 스킨 디렉토리를 만들었습니다. 물론 디렉토리와 파일만 만들어 놓았고 아직 아무 내용도 없습니다.

반드시 있어야 하는 파일은 다음과 같습니다. css 폴더와 img 폴더는 굳이 만들지 않아도 되지만 관리 편의상 있으면 좋겠지요.

skin.xml - 위젯 스타일 스킨의 정보 파일 입니다. 스킨 정보와 저작자 정보가 포함되어 있습니다.
widgetstyle.html - 데이터 출력에 필요한 HTML 마크업 파일 입니다.
preview.gif - 관리자 화면에 표시되는 스킨 미리보기 이미지 입니다.

스킨 정보 'skin.xml' 편집하기.

다음 코드는 위젯 스타일 스킨을 구성하는데 필요한 최소한의 코드 입니다. 저작자 정보를 입력하고 '제목, 더보기 텍스트, 더보기 URL'을 입력받을 수 있습니다. 이 항목은 관리자 모드에서 출력 됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<widgetstyle>
    <title xml:lang="ko">마이 위젯 스타일 스킨</title>
    <description xml:lang="ko">나만의 위젯 스타일 스킨 입니다.</description>
    <version>0.1</version>
    <date>2009-12-24</date>
    <preview>preview.gif</preview>
    <author email_address="dece24앳gmail.com" link="http://naradesign.net/">
        <name xml:lang="ko">Jeong, Chan Myeong</name>
    </author>
    <extra_vars>
        <var name="ws_title" type="text">
            <name xml:lang="ko">제목</name>
        </var>
        <var name="ws_more_text" type="text">
            <name xml:lang="ko">더보기 텍스트</name>
        </var>
        <var name="ws_more_url" type="text">
            <name xml:lang="ko">더보기 URL</name>
        </var>
    </extra_vars>
</widgetstyle>

'제목, 더보기'에 텍스트 대신 이미지를 등록해 사용하고 싶다면 <extra_vars>...</extra_vars> 사이에 다음 코드를 추가 합니다.

제목 텍스트나 제목 이미지 앞쪽에 아이콘을 등록해서 사용하고 싶다면 <extra_vars>...</extra_vars> 사이에 다음 코드를 추가 합니다.

CSS 이걸 불러? 말어? 'import/unload'.

위젯 스타일 스킨에 필요한 CSS 파일을 부르거나 또는 XE 코어 모듈이 부르는 레거시 파일(default.css, button.css)을 로드하지 못하도록 할 수 있습니다.

특정 CSS 파일을 위젯에서 사용하려면 widgetstyle.html 파일에 다음과 같이 선언 합니다.

특정 CSS 파일을 게시판에서 불러오지 않으려면 widgetstyle.html 파일에 다음과 같이 선언 합니다.

'widgetstyle.html' 마크업 시작하기.

위젯 스타일 스킨의 HTML 마크업은 정말 단순 합니다. widgetstyle.html 파일에 위젯의 바깥쪽에서 출력할 HTML 코드를 마크업 해주기만 하면 됩니다. 가장 먼저 할 일은 위젯 스킨 스타일의 최상위 division과 위젯 콘텐츠 노출 변수를 넣어 줍니다. 최상위 division에는 다른 위젯 또는 위젯 스타일들과 겹치지 않는 고유한 클래스 이름을 사용해야만 CSS 명령 사이에 충돌이 일어나지 않습니다.

<div class="myWidgetStyle">
{$widget_content}
</div>

위젯 콘텐츠 노출 변수 {$widget_content} 부분에는 위젯 또는 직접 작성한 데이터가 노출될 것입니다.

'widgetstyle.html' 제목 마크업 넣기.

위젯의 제목 단계가 <h2 />가 될지 <h3 />가 될지 모르기 때문에 여러분의 웹 사이트 문서 구조에 적합한 헤딩 단계로 마크업을 하세요. 위로부터 '아이콘 이미지가 등장하는 경우 출력, 제목 이미지가 등장하는 경우 출력, 텍스트 제목인 경우 출력' 하라는 명령이 추가 되었습니다. 스킨에서 지원하지 않기로 결정한 명령줄은 작성하지 않아도 됩니다. 제목이 출력되기를 원하는 위치에 다음과 같이 작성 하세요.

관리자 모드에서 입력한 '아이콘, 제목 이미지 또는 제목 텍스트'가 위젯 스타일 스킨으로써 출력될 것입니다.

'widgetstyle.html' 더보기 마크업 넣기.

위젯이 게시물의 목록인 경우 '더보기 텍스트와 링크'를 출력할 수 있습니다. '더보기 텍스트'는 스킨에서 기본 문자를 지정해도 되지만 관리자 모드에서 입력 받을 수 있기 때문에 관리자 모드에서 입력한 '더보기 텍스트 및 링크' 또는 '더보기 이미지 및 링크'를 유연하게 받아서 처리하려면 다음과 같은 마크업을 출력하기를 원하는 위치에 추가 합니다. 스킨에서 지원하지 않기로 결정한 명령줄은 작성하지 않아도 됩니다.

위로부터 '더보기 URL에 http://를 넣은 경우의 링크, 더보기 URL에 http://를 넣지 않은 경우의 링크, 더보기 이미지를 입력 받은 경우, 더보기 텍스트만 사용하는 경우, 더보기 텍스트를 입력하지 않은 경우'를 고려한 마크업 입니다.

{@$widgetstyle_extar_var->ws_more_url=trim($widgetstyle_extar_var->ws_more_url);}


<a href="{$widgetstyle_extar_var->ws_more_url}" class="myWidgetMore">

<a href="http://{$widgetstyle_extar_var->ws_more_url}" class="myWidgetMore">

     
     <img src="{$widgetstyle_extar_var->ws_more_image}" alt="{$widgetstyle_extar_var->ws_more_text}" />
     
     {$widgetstyle_extar_var->ws_more_text}
     
     more
     
</a>

이와 같이 작성하면 관리자 모드에서 입력한 '더보기 텍스트 또는 더보기 이미지와 링크'가 출력될 것입니다.

'widgetstyle.html' 마크업 완성 예제.

완성된 하나의 예제 입니다. div.myWidgetStyle 이라는 최상위 블럭 아래 h3.myWidgetHeader(제목)과 {$widget_content} (내용) 그리고 a.myWidgetMore(더보기) 링크가 순서대로 노출 될 것입니다.

<h3 class="myWidgetHeader">
        
        <img src="{$widgetstyle_extar_var->ws_title_icon}" alt="" />
        
        
        <img src="{$widgetstyle_extar_var->ws_title_image}" alt="{widgetstyle_extar_var->ws_title}" />
        
        
        {$widgetstyle_extar_var->ws_title}
        
        
    </h3>
    

    {$widget_content}

    {@$widgetstyle_extar_var->ws_more_url=trim($widgetstyle_extar_var->ws_more_url);}
    
    
    <a href="{$widgetstyle_extar_var->ws_more_url}" class="myWidgetMore">
    
    <a href="http://{$widgetstyle_extar_var->ws_more_url}" class="myWidgetMore">
    
        
        <img src="{$widgetstyle_extar_var->ws_more_image}" alt="{$widgetstyle_extar_var->ws_more_text}" />
        
       {$widgetstyle_extar_var->ws_more_text}
         
       more
       
    </a>
    

</div>

XE 스킨 메뉴얼 : 콘텐츠 위젯 스킨 만들기.

2009-08-21T17:34:10+09:00

콘텐츠 위젯이란? 이게 왜 나왔지?
콘텐츠 위젯으로 표현할 수 있는 데이터와 스킨 유형은?
콘텐츠 위젯 기본 스킨 파일의 위치와 구조.
콘텐츠 위젯 기본 스킨 사본 만들기.
'skin.xml' 스킨 정보 수정하기.
CSS 이걸 불러? 말어? 'import/unload'.
HTML 파일의 목록과 역할.
콘텐츠 위젯의 HTML/DOM 구조.
콘텐츠 위젯 화면 갈무리.
테이블로 작성된 텍스트 목록.
목록으로 작성된 텍스트 목록.
테이블로 작성된 썸네일 목록.
목록으로 작성된 썸네일 목록.
갤러리 목록.
웹진 목록.

콘텐츠 위젯이란? 이게 왜 나왔지?

콘텐츠 위젯은 XE가 수집해 둔 사용자 콘텐츠로부터 원하는 데이터를 원하는 위치에서 원하는 형식으로 출력할 수 있도록 돕습니다. 콘텐츠 위젯이 등장하기 전까지 우리는 다음과 같은 위젯에 의존해서 원하는 데이터를 출력해 왔었지요. 아래 나열된 위젯들은 모두 2007년도에 제작되었고 XE에 기본으로 탑재되어 배포가 되어 왔는데요. 지금부터 설명해 드리는 콘텐츠 위젯은 아래 나열된 위젯들을 단 하나의 위젯으로 통합한 것입니다. 위젯들이 그동안 각개 전투 하느라 고생이 많았지요. 이제는 좀 푸~욱 쉬었으면 좋겠습니다. ^^ Good-bye!

최근 문서 출력 (newest_document) - ./widgets/newest_document/
최근 댓글 출력 (newest_comment) - ./widgets/newest_comment/
최근 이미지 출력 (newest_images) - ./widgets/newest_images/
최근 엮인글 출력 (newest_trackback) - ./widgets/newest_trackback/
RSS 리더 (rss_reader) - ./widgets/rss_reader/
탭 형태 최근 문서 출력 (tab_newest_document) - ./widgets/tab_newest_document/
웹진 형태 최근 문서 출력 (webzine) - ./widgets/webzine/

위 나열된 7개의 위젯을 하나로 통합한 혁신적(?)인 위젯이 바로 2009년도에 등장한 다음의 콘텐츠 위젯 입니다.

Content 위젯 (content) - ./widgets/content/

위젯을 이렇게 통합한 이유는 스킨 디자인의 일관성을 유지하고 유사한 데이터를 출력하는 스킨이 그 모양이 다르다고 하여 별도의 스킨으로 제작되는 비효율적인 관행을 개선하기 위함 입니다.

콘텐츠 위젯으로 표현할 수 있는 데이터와 스킨 유형은?

콘텐츠 위젯으로 표현할 수 있는 데이터 유형은 다음과 같습니다.

게시물 - 게시판, 위키, 이슈트레터 ... 작성된 게시물들.
댓글 - 게시판, 위키, 이슈트레터 ... 작성된 댓글들.
첨부 이미지 - 게시판, 위키, 이슈트레터 ... 첨부된 이미지들.
엮인글 - 게시판, 위키, 이슈트레터 ... 엮인 글들.
RSS 피드 - XE 뿐만 아니라 RSS를 지원하는 모든 종류의 외부 게시물을 출력 가능.

콘텐츠 위젯으로 표현할 수 있는 스킨 유형은 다음과 같습니다.

'제목' 목록.
'썸네일+제목 목록'
갤러리 스타일의 '썸네일+제목' 목록.
웹진 스타일의 '썸네일+제목+내용' 목록.

스킨 유형은 사용되는 HTML 코드에 따라서 '~테이블 목록'과 그냥 '~목록'으로 나뉘는데요. 이렇게 구분해서 제공하는 이유는 상황에 따라서 각각 장단점이 있기 때문입니다. '테이블 목록'의 장점은 <table> 요소를 활용해서 화면에 보이지 않는 그리드를 형성하고 어떠한 상황에서도 배치가 깨지거나 글자가 겹치는 일이 없습니다. 하지만 의미론적 마크업 측면에서 최적의 마크업은 아니라고 판단 합니다. 한편 '일반 목록'은 <ul> 요소를 활용해서 보다 의미있게 마크업을 하고 시각장애인들이 사용하는 화면낭독기 도구는 몇 개의 목록이 있는지를 음성으로 제공해 주기 때문에 접근성 측면에서 권장 됩니다. 한편 '일반 목록'은 가변적인 데이터들을 좌우 끝으로 정렬해서 배치하려는 경우에 우측 배치에 한계가 있습니다. 콘텐츠 위젯 생성시 데이터 배치 순서를 마음대로 바꿀 수 있는데 스킨을 제어하는 CSS는 그런 상황에 유연하게 제어할 수 없어서 데이터 배치 순서에 따라 CSS를 그때 그때 고쳐 사용해야 하는 단점이 있습니다.

콘텐츠 위젯 기본 스킨 파일의 위치와 구조.

콘텐츠 위젯 스킨은 '/XE 설치 폴더/widgets/content/skins/' 위치에 있고 만약 다른 콘텐츠 위젯 스킨을 업로드 하지 않았다면 'default' 라는 위젯 스킨 하나가 다음과 같이 존재할 것입니다.

콘텐츠 위젯 기본 스킨 사본 만들기.

새로운 스타일의 콘텐츠 위젯 스킨을 만드려면 기본 스킨의 사본을 이용하는 것이 좋습니다. 저는 제 입맛에 맞는 스킨을 제작하기 위해 다음과 같이 'default' 스킨의 사본 'naradesign' 을 만들었습니다. '나라디자인 콘텐츠 위젯 내려받기'. 만약 이 메뉴얼을 참고로 새 콘텐츠 위젯 스킨을 제작하려면 '나라디자인 콘텐츠 위젯'을 모체 스킨으로 사용하여 제작할 것을 권장 합니다. 'default' 스킨으로부터 웹 접근성과 HTML 유효성을 개선 했습니다.

'skin.xml' 스킨 정보 수정하기.

스킨 사본을 만들고 가장 먼저 해야 할 일은 'skin.xml' 파일을 수정하는 일입니다. 여러분의 이름과 웹 사이트 주소를 입력하는 등 다음과 같이 수정 합니다. 스킨 정보 수정 후 'XE 관리자 > 사이트 설정 > 위젯 > Content 위젯 > 코드 생성 > 스킨' 항목에서 여러분의 스킨 항목이 표시되면 정상적으로 작성된 것입니다.

<?xml version="1.0" encoding="UTF-8"?>
<skin version="0.2">
    <title xml:lang="ko">나라디자인 콘텐츠 위젯 스킨</title>
    <description xml:lang="ko">단순한 것이 최고! 나라디자인 콘텐츠 위젯 스킨 입니다.</description>
    <version>0.1</version>
    <date>2009-08-20</date>
    <author email_address="dece24앳gmail.com" link="http://naradesign.net/">
        <name xml:lang="ko">Jeong, Chan Myeong</name>
    </author>
    <colorset>
        <color name="white">
            <title xml:lang="ko">밝은색 배경에 어울리는</title>
        </color>
        <color name="black">
            <title xml:lang="ko">어두운 배경에 어울리는</title>
        </color>
    </colorset>
</skin>

만약 흰색 배경과 어두운색 배경에 모두 대응하는 스킨을 제작할 필요가 없다면 <colorset>...</colorset> 부분을 다음과 같이 삭제하고 됩니다.

CSS 이걸 불러? 말어? 'import/unload'.

콘텐츠 위젯 스킨에 필요한 CSS 파일을 부르거나 또는 XE 코어 모듈이 부르는 레거시 파일(default.css, button.css)을 로드하지 못하도록 할 수 있습니다.

특정 CSS 파일을 위젯에서 사용하려면 content.html 파일에 다음과 같이 선언 합니다.

특정 CSS 파일을 게시판에서 불러오지 않으려면 content.html 파일에 다음과 같이 선언 합니다.

HTML 파일의 목록과 역할.

content.html - 위젯 출력에 필요한 'HTML/CSS/JS' 파일을 불러옵니다. 콘텐츠 위젯의 최상위 블럭 입니다. '_tab_***.html' 파일을 인클루드 합니다.
_tab_none.html - 모듈을 탭으로 분리하지 않는 경우 출력 됩니다. 목록을 인클루드 합니다.
_tab_top.html - 모듈을 상단의 수평 탭으로 분리하는 경우에 출력 됩니다. 목록을 인클루드 합니다.
_tab_left.html - 모듈을 좌단의 수직 탭으로 분리하는 경우에 출력 됩니다. 목록을 인클루드 합니다.
normal.html - '일반 글' 목록 입니다. 테이블형 목록과 일반 목록이 포함되어 있습니다. 썸네일은 포함되어 있지 않습니다.
image_title.html - '썸네일+제목' 목록 입니다. 테이블형 목록과 일반 목록이 포함되어 있습니다.
image_title_content.html - '썸네일+제목+내용' 목록 입니다. 테이블형 목록과 일반 목록이 포함되어 있습니다.
gallery.html - 갤러리 스타일의 '썸네일+제목' 목록 입니다.

콘텐츠 위젯의 HTML/DOM 구조.

새 콘텐츠 위젯 스킨을 제작할 때에는 사본의 모체가 되는 스킨으로부터 HTML에 포함되어 있는 CSS 선택자 이름을 모두 바꿔주는 것이 좋습니다. 변경하는 이유는 다른 위젯 스킨들과 한 페이지에서 혼용하여 사용하는 경우 같은 선택자 이름을 만났을 때 CSS의 우선순위에 충돌이 발생할 수 있기 때문 입니다. 아래 소개하는 HTML 구조와 CSS 선택자 이름은 'default' 스킨이 아니라 'default' 스킨을 개선한 'naradesign' 스킨의 구조 입니다. HTML 구조는 대체적으로 유사하지만 큰 차이가 있고 CSS 선택자 이름은 모두 바꾸었습니다. 새 스킨을 제작할 때 'default' 스킨보다 'naradesign' 스킨의 사본을 이용하는 것을 강력하게 권장 합니다. 여러가지 면에서 기존 스킨의 단점을 보완했기 때문입니다. ncw라는 클래스 이름은 Naradesign Content Widget의 약어를 클래스 이름으로 사용한 것입니다.

아래 돔 구조에서 '★' 별 표시는 탭을 사용하는 경우에만 출력되는 블럭 입니다. '◀' 세모 표시가 있는 4개(텍스트 목록, 썸네일 목록, 갤러리 목록, 웹진 목록)의 목록은 이 가운데 선택된 한 가지 목록만 출력됨을 의미 합니다.

div.ncw(콘텐츠 위젯 콘테이너)
- ul.ncwTabContainer.ncwTabHr(수평 탭일 때) | ul.ncwTabContainer.ncwTabVr(수직 탭일 때) ★
  - li.ncwTab(비활성 탭) | li.ncwTab.active(활성 탭) ★
    - button.ncwTabButton(탭 버튼) ★
    - div.ncwListContainer(탭 하위 목록과 페이지네이션 콘테이너) ★
      - div.ncwLastTitle(텍스트 목록) ◀
        table.ncwList(테이블 목록) | ul.ncwList(일반 목록)
        ul.ncwListPagination(목록 페이지네이션)
      - div.ncwLastThumb(썸네일 목록) ◀
        p.ncwThumbArea(썸네일 영역)
        div.ncwListArea(목록 영역)
        table.ncwList(테이블 목록) | ul.ncwList(일반 목록)
        ul.ncwListPagination(목록 페이지네이션)
      - ul.ncwGallery(갤러리 목록) ◀
        li(아이템)
      - ul.ncwWebzine(웹진 목록) ◀
        li(아이템)
        p.ncwThumbArea(썸네일 영역)
        p.titleArea(제목 영역)
        p.authorArea(글쓴이 영역)

콘텐츠 위젯 화면 갈무리.

콘텐츠 위젯 스킨을 제작할 때 가능한 모든 데이터를 출력하도록 설정하고 다음과 같은 화면을 모두 테스트 해야 합니다.

NN:TX

다양한 욕구, 별도의 배려, 특별한 시선.

'분리'와 '별도의 배려'라는 해결책에 대해

다양한 욕구의 수용 방법에 대해

특별한 시선은 불편할 수 있습니다

관련 포스트

장애인을 차단하는 세계 최초 신기술.

jQuery를 이용하여 FAQ 목록 만들기.

a 요소에 유효한 URL 사용하기

관련글

CSS Bar Graph. Horizontal. Vertical.

jQuery+CSS Tree Navigation.

메뉴 건너 뛰기 링크(Skip Navigation).

헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법

반복되는 콘텐츠 블럭을 우회하는 방법

메뉴 건너 뛰기 링크에 관한 쟁점

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크

글로벌 네비게이션을 본문 콘텐츠보다 늦게 마크업 하는 경우

지나치게 많은 '** 건너 뛰기' 제공은 오히려 공해

메뉴 건너 뛰기에 관한 더 많은 의견들

CSS Tab Navigation + List Item Navigation.

Lined Tab Navigation

Faced Tab Navigation

List Item Navigation

Tab Navigation 예제의 특징

CSS Vertical Navigation Bar.

특징

유의사항

NHN Burning Day 2010 참가.

Modal Windowed Login UI.

HTML

CSS

Javascript

P.S.

CSS Drop Down : Emulate Select/Option.

서식 제어 요소의 디자인을 제한하는 이유

<select> 콘트롤을 본래 목적에 맞게 사용하기

그럼에도 불구하고 <select> 콘트롤이 사랑받는 이유

결론 : <select> 형태는 취하고 마크업은 버리자

CSS Pagination Without Image.

CSS Navigation Bar.

보편적이고 사용성이 좋은

웹 표준과 접근성을 지키는

유연하고 확장하기 좋은

이미 널리 쓰이고 있는

브라우저 호환성

XE 스킨 메뉴얼 : 위젯 스타일 스킨 만들기.

위젯 스타일 스킨이란?

위젯 스타일 스킨 미리 보기.

위젯 스타일 스킨은 어느 디렉토리에 있나요?

새 위젯 스타일 스킨 만들기.

스킨 정보 'skin.xml' 편집하기.

CSS 이걸 불러? 말어? 'import/unload'.

'widgetstyle.html' 마크업 시작하기.

'widgetstyle.html' 제목 마크업 넣기.

'widgetstyle.html' 더보기 마크업 넣기.

'widgetstyle.html' 마크업 완성 예제.

XE 스킨 메뉴얼 : 콘텐츠 위젯 스킨 만들기.

콘텐츠 위젯이란? 이게 왜 나왔지?

콘텐츠 위젯으로 표현할 수 있는 데이터와 스킨 유형은?

콘텐츠 위젯 기본 스킨 파일의 위치와 구조.

콘텐츠 위젯 기본 스킨 사본 만들기.

'skin.xml' 스킨 정보 수정하기.

CSS 이걸 불러? 말어? 'import/unload'.

HTML 파일의 목록과 역할.

콘텐츠 위젯의 HTML/DOM 구조.

콘텐츠 위젯 화면 갈무리.

테이블로 작성된 텍스트 목록.

목록으로 작성된 텍스트 목록.

테이블로 작성된 썸네일 목록.

목록으로 작성된 썸네일 목록.

갤러리 목록.

웹진 목록.