Lined Tab Navigation

Faced Tab Navigation

List Item Navigation

Tab Navigation 예제의 특징

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

특징

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

유의사항

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

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

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

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

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

예제를 새 창으로 보기

HTML

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

CSS

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

Javascript

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

P.S.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

예제를 새 창에서 보기

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

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

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

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

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

보편적이고 사용성이 좋은

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

하위 메뉴를 수평으로 열게 되면 사용자는 정확하게 선택하기 위하여 ‘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일동안 쳐다보고 있으니 아주 지겨워 죽겠더라구요.

1. 명세의 시작과 끝
2. 명세의 주석
3. 연산 기호들
4. 등장하는 용어들
5. 본체와 변수
6. 요소와 속성
7. 요소 명세 읽기
8. 속성 명세 읽기
9. 참고

DTD에 표시된 URI(예: loose.dtd 또는 xhtml1-transitional.dtd)를 내려받아서 명세를 한 번이라도 열어보신 분들이라면 알 수 없는 낯선 문자들에 대한 당혹스러움을 감출 수 없었을 것입니다. HTML/XHTML의 문법 규칙들이 포함되어 있고 브라우저가 이것을 어떻게 해석해야 하는지에 대한 단서가 기록되어 있습니다. 만약 DTD가 없다면 여러분은 <address> 요소 안쪽에 어떤 요소가 허용되는지 알 수 없을 것입니다. <address> 요소 안쪽에는 블럭 요소를 허용하지 않지만 예외적으로 HTML 4.01 호환 모드(Transotional) DTD에서 블럭 요소인 <p> 요소를 허용합니다. 문법 검사기(HTML Validator)는 DTD를 근거로 문법을 검사하기 때문에 호환 모드에서 <address> 요소 안쪽의 <p>를 적법하다고 간주하며 HTML 4.01 엄격 모드(strict.dtd)에서는 적법하지 않다고 오류 메시지를 보여줄 것입니다. DTD는 HTML/XHTML 문서에 대한 가장 기초적인 명세로써 웹 브라우저가 HTML을 해석하는 기준이 되고 문법 검사기가 유효성을 판단하는 기준이 됩니다. 

지금부터는 이해를 돕기 위하여 HTML 4.01 호환모드 DTD인 http://www.w3.org/TR/html4/loose.dtd 파일을 내려받은 후 화면에 열어놓거나 또는 웹 페이지 버전의 loose.dtd 페이지(추천)를 열어놓은 다음 이 글과 번갈아 보면서 내용을 천천히 정독해 주시기 바랍니다. HTML 4.01 Transitional DTD를 기준으로 설명하겠습니다. 이 포스트는 내용은 조금 어렵지만 몇가지 낮선 단어들과 규칙들을 익힘으로써 HTML과 XHTML 명세를 다른 사람에게 물어보지 않고도 스스로 터득할 수 있는 근본적인 지식이 될 것입니다.

명세의 시작과 끝

DTD에서 HTML 요소 및 속성에 대한 명세 구문은 여는 꺽쇠와 느낌표(<!)로 시작하여 닫는 꺽쇠(>)로 끝납니다.

<! 이곳에 명세가 들어갑니다 >

명세의 주석

명세의 주석은 — 2회 연속 작성된 하이픈 — 문자 안쪽에 기술합니다. 주석 안쪽에 포함된 내용은 기계적으로 해석되지 않고 사람이 읽을 수 있도록 자연어 문장으로 처리되어 있습니다. 아래 첫 번째 주석은 순수한 주석문이고 두 번째 주석은 명세 안에 포함된 주석문 입니다. 주석은 한 줄 또는 여러줄이 될 수 있습니다.

<!– 이곳에 주석의 내용이 들어갑니다 –>
<! 이곳에 명세가 들어갑니다 – 이곳에 주석의 내용이 들어갑니다 –>

연산 기호들

연산 기호들은 주로 특정 요소가 자식 요소로써 어떤 요소들을 어떻게 허용하는지 정의할 때 사용합니다. 예를 들어 <a> 요소는 다른 인라인 요소들은 모두 허용하지만 예외적으로 자신과 동일한 요소인 <a> 요소만은 자식으로 둘 수 없다고 -(A) 선언되어 있는데 이러한 선언은 모두 연산자를 통해 표시 됩니다. 

• ( … ) : 연산 그룹의 범위
• A : A는 필수적이며 한 번만 사용할 수 있다
• A+ : A는 필수적이며 한 번 이상 사용해야 한다
• A? : A는 생략하거나 한 번만 사용할 수 있다
• A* : A는 생략하거나 한 번 이상 사용할 수 있다
• +(A) : 추가적으로 A를 사용할 수 있다
• -(A) : 예외적으로 A는 사용할 수 없다
• A | B : A 또는 B로써 순서에 무관하게 사용할 수 있다
• A, B : A 그리고 B는 순서를 지켜야 한다
• A & B : A 그리고 B는 순서에 무관하다

등장하는 용어들

• #PCDATA(Parsed Character Data)
  XML 해석기에 의하여 해석되는 문자 데이터를 의미 합니다. 텍스트와 HTML 요소들을 있는 그대로 브라우저로 보내는 것이 아니라 적절하게 렌더링하기 위하여 변환합니다. 예를 들면 ‘<, >’ 기호는 요소의 시작 또는 끝으로 해석하고 ‘&’ 기호는 HTML 문자의 본체(Entity)가 시작되는 것으로 간주 합니다. 따라서 #PCDATA 안쪽에서 ‘&’ 기호를 해석하지 않고 화면에 그대로 표시하려면 HTML Entity 형식을 빌어 ‘&amp;’ 와 같이 작성해야 합니다.
• CDATA(Character Data)
  XML 해석기에 의하여 해석되지 않는 문자 데이터를 의미 합니다. CDATA 안쪽에서 표기하는 모든 문자는 해석기가 해석하지 않기 때문에 브라우저에 그대로 전달 됩니다. 부등호(<, >)와 연산자(&) 사용이 많은 <script> 요소 안쪽에서 웹 브라우저가 이 기호들을 HTML 요소 또는 Entity가 시작되는 것으로 오해하는 것을 예방하기 위하여 CDATA 형식을 선언 <![CDATA[ ... ]]> 하기도 합니다.
• #REQUIRED
  반드시 요구되는.
• #IMPLIED
  생략 가능한. (생략하는 대신 웹 브라우저가 기본 값을 제공하거나 부모로부터 상속을 받기도 함)
• #FIXED
  주어진 값만 사용할 수 있는.

본체와 변수

DTD에서는 본체(Entity)와 변수(Parameter) 개념을 사용합니다. 본체란 변수의 실체(원래 모습)이며 변수는 본체를 대체하는 문자 입니다. <!ENTITY> 구문 안쪽에 선언된 내용들은 본체와 변수에 관한 선언 입니다.

<!ENTITY %  변수 이름  "변수의 실체">

예를 들어 <h1>~</h6> 요소는 %heading; 이라는 변수 이름의 실체 입니다. <h1>~<h6> 요소는 각각의 이름만 다를 뿐 각각의 요소는 모두 동일한 속성과 콘텐츠 모델(자식 요소)을 갖습니다. DTD에서는 같은 내용을 일일이 반복해서 열거하는 것을 피하기 위하여 <h1>~</h6> 요소에 대하여 %heading; 이라는 변수를 선언했습니다. %heading;에 대한 실체는 문서 상단에 한 번 선언해 놓고 본문에서는 <h1>~<h6> 요소 대신에 %heading; 이라는 변수를 사용합니다. 다음 구문은 %heading; 이라는 변수와 본체를 선언하는 구문 입니다.

<!ENTITY % heading "H1|H2|H3|H4|H5|H6">

다음 구문은 DTD 본문에서 %heading; 이라는 변수를 사용한 예 입니다. 퍼센트 ‘%‘ 기호로 시작하여 세미콜론 ‘;‘ 기호로 끝나는 것은 모두 변수이며 모든 변수들은 각각의 실체에 해당하는 본체가 문서 상단에 기술되어 있습니다. (%heading;)의 본체는 (H1|H2|H3|H4|H5|H6) 이므로 아래 구문은 <h1>~<h6> 요소의 명세를 기술하는 구문 입니다.

<!ELEMENT (%heading;)>

요소와 속성

요소에 대한 명세는 <!ELEMENT> 안쪽에 선언되고 이 요소의 속성에 대한 명세는 <!ATTLIST> 안쪽에 선언 됩니다. <!ELEMENT> 구문이 등장하면 곧 관련된 <!ATTLIST> 구문이 자연스럽게 등장합니다.

<!ELEMENT 이곳에 요소의 명세가 들어갑니다>
<!ATTLIST 이곳에 속성의 명세가 들어갑니다>

요소 명세 읽기

요소의 명세는 다음과 같은 순서로 기술하는데 띄어쓰기를 이용해서 각각을 구분 합니다. 

<!ELEMENT  요소 이름  시작 명세  종료 명세  자식 명세  – 주석 –>

‘시작 명세’와 ‘종료 명세’는 단순히 태그가 ‘필수(-)’적인지 또는 ‘생략(O)’할 수 있는지를 선언합니다. ‘자식 명세’는 다른말로 표현해서 ‘허용하는 자식 요소의 형태’라고 이해해도 됩니다. 조금 더 구체적으로 이해하기 위하여 문단을 의미하는 <p> 요소의 명세를 보여 드리겠습니다. 

<!ELEMENT P – O (%inline;)* — paragraph –>

<p> 요소의 명세를 사람이 이해할 수 있는 자연어로 번역하면 다음과 같습니다. %inline; 이라는 변수가 연산을 위한 괄호() 안에 포함되었고 별표 연산자 ‘*’를 통해서 몇 번 사용할 수 있는지도 설명 되었습니다.

P 요소는 시작 태그가 반드시 필요(-)하고 종료 태그는 선택적(O)이다. 인라인 콘텐츠만(%inline;)을 자식으로 가질 수 있는데 이를 생략하거나 한 번 이상 사용(*)할 수 있다. — 문단을 의미한다. –

<p> 요소에 대하여 웹 브라우저 또는 문법 검사기는 다음과 같이 해석할 것입니다.

1. ELEMENT : 요소에 관한 명세임
2. P : 요소 이름은 P
3. - : 시작 태그는 필수적
4. O : 종료 태그는 선택적
5. (%inline;) : 자식 요소로써 인라인 콘텐츠만 허용
6. * : 자식 요소는 생략하거나 한 번 이상 사용 할 수 있음
7. – paragraph — : 문단임

요소 이름 다음에 등장하는 기호 하이픈(-) 또는 알파벳(O)는 시작 태그 또는 종료 태그가 필수적인지 선택적인지를 기술하는데 하이픈(-)은 태그의 선언이 필수적임을 의미하며 알파벳(O)는 선택적으로 생략할 수도 있다(can be Omitted)는 것을 의미 합니다. 만약 시작과 종료 태그가 모두 필수적이라면 ‘P – -’ 이라고 표기 될 것이며 모두 필수적이지 않다면 ‘P O O’ 라고 표기 했을 것입니다.

시작 태그와 종료 태그 다음에 등장하는 ‘자식 명세’는 자식 요소로써 무엇을 허용할 것인지에 대한 내용이 선언됩니다. 예를 들어 HTML/XHTML 호환모드에서 <address> 요소는 기본적으로 인라인 요소만을 허용하나  예외적으로 <p> 요소도 허용하고 있는데 DTD 명세는 이것을 어떻게 설명하는지 확인해 보겠습니다.

<!ELEMENT ADDRESS – - ((%inline;)|P)*  – information on author –>

<address> 요소는 시작과 종료 태그가 모두 필수적이고 인라인(%inline;)요소 또는(|) 문단 요소 <p>를 사용할 수 있다. 자식 요소들은 모두 생략이 가능하고 한 번 이상 사용할 수 있다.

<img> 요소와 같이 자식 요소를 포함하지 않는 요소들은 어떻게 선언할까요? ‘자식 명세’를 정의하는 곳에 EMPTY 라고 적혀 있는 경우 자식 요소를 가질 수 없다는 의미 입니다.

<!ELEMENT IMG – O EMPTY — Embedded image –>

<img> 요소는 시작태그는 필수적이지만 종료태그는 생략 가능한데 자식 요소는 비어(EMPTY)있다.

속성 명세 읽기

속성에 관한 명세는 항상 관련 요소에 대한 명세 다음에 등장하지만 어떤 요소에 대한 설명인지 보다 명확히 하기 위하여 명세 안쪽에 명시적으로 관련 요소 이름을 지명 하고 있습니다. 속성의 명세는 다음과 같은 구조를 갖습니다.

<!ATTLIST  관련 요소 이름을 지명
    속성 이름  속성의 값  속성의 기본 값 또는 필수적인지 아닌지  – 설명 –
>

좀더 구체적으로 이해하기 위하여 <input> 요소에 대한 속성 명세를 예제로 옮겨 왔습니다. 일단 어떤 모양인지 눈여겨 봐 주세요. 이해하기 쉽게 몇 가지 속성만 추렸고 각각을 분리해서 설명드리겠습니다.

<!ATTLIST INPUT 
%attrs;    – %coreattrs, %i18n, %events – 
type    %InputType;    TEXT    – 타입 – 
name    CDATA    #IMPLIED    – 서버측에 넘겨주는 이름 –
>

어떤 요소의 속성에 관한 명세인지 지명하는 부분은 다음과 같이 명세의 첫 번째 줄에 등장 합니다. <input> 요소에 관한 속성 목록을 나열하겠다는 의미로 해석하면 됩니다.

<!ATTLIST INPUT

다음 구문은 온통 퍼센트 %기호로 시작하여 세미콜론; 으로 끝나는 ‘변수’로만 작성되어 있습니다. 이런 경우에는 변수가 무엇을 의미하는지 해석해야 합니다. %attrs; 라는 변수에는 다른 HTML 요소에서도 공통으로 사용되는 전역 속성들의 목록(예를 들면 id, class, style, title과 같은)이 포함되어 있습니다. 그런데 — 주석 — 안쪽에는 %attrs;라는 변수가 또 다른 변수들의 집합이라는 것을 설명하고 있네요.

%attrs;    – %coreattrs, %i18n, %events –

%coreattrs; 라는 변수는 모든 HTML 요소들의 핵심(core) 속성에 해당하는 id, class, style, title 속성을 하나의 변수로 만든것 입니다. 

%i18n; 이라는 변수는 국제화 속성으로써 lang, dir 속성을 하나의 변수로 만들었습니다. %i18n; 이라는 변수 이름은 본래 %internationalization;(%국제화;)이라는 용어가 너무 길어서 알파벳 첫 글자 ‘i’와 마지막 글자 ‘n’ 사이에 있는 18개의 알파벳을 모두 표기하지 않고 숫자로 바꿔 표기한 것입니다. 국제화 속성의 하나인 lang 속성은 콘텐츠의 자연어가 어떤 언어인지(예를 들면 영어인지 한국어인지) 지정하는 속성이고 dir 이라는 속성은 문자의 방향(direction)에 관한 속성 입니다. 대부분의 언어가 왼쪽에서 오른쪽으로(Left To Right) 읽고 쓰기 때문에 기본값은 dir="ltr" 이고 모든 요소에서 생략되어 있습니다. 만약 아랍어라면 dir="rtl" (Right To Left) 으로 지정하여 기본 ‘ltr’ 으로 설정된 방향 속성을 ‘rtl’ 으로 덮어쓰기 해야 할 것입니다.  

%events; 라는 변수는 자바스크립트 이벤트 핸들러들의 집합으로써 다음과 같습니다. 

• onclick     — 버튼을 누른 후 뗌 –
• ondblclick     — 버튼을 연달아 두 번 클릭 –
• onmousedown     — 버튼 누름 –
• onmouseup     — 버튼 뗌 –
• onmouseover     — 마우스 포인터가 위에 있는 –
• onmousemove     — 마우스 포인터가 움직임 –
• onmouseout     — 마우스 포인터가 벗어남 –
• onkeypress     — 키를 누른 후 뗌 –
• onkeydown     — 키를 누름 –
• onkeyup     — 키를 뗌 –

다음은 type 이라는 속성에 관한 명세 부분 입니다. ‘속성 이름, 속성의 값, 속성의 기본 값’ 순으로 명시되어 있습니다. 속성이 ‘필수적인지 아닌지’의 여부는 표시되지 않았는데 왜냐하면 ‘속성의 기본 값’이 표기되어 있기 때문입니다. 속성에 기본 값이 있다는 것은 속성을 생략할 수 있다는 의미로 해석이 가능하기 때문에 #IMPLIED라는 설명은 생략되었습니다.

 type    %InputType;    TEXT    – 타입 –

사람이 이해할 수 있는 말로 type 속성에 관한 명세를 풀어보면 다음과 같이 해석할 수 있습니다.

<input> 요소에는 말이지 type 이라는 속성이 있어
type 이라는 속성은 %InputType; 이라는 값을 가질 수 있는데
%InputType;은 TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET |    FILE | HIDDEN | IMAGE | BUTTON 이런 값들을 가질 수 있지
그리고 이 많은 값 가운데 기본값은 TEXT 란다
type="text" 이것이 <input> 요소의 기본 값이라는 거지
속성에 대한 기본 값이 있기 때문에 이 속성은 생략(#IMPLIED)할 수도 있단다

다음은 name 속성에 관한 명세 입니다.

name    CDATA    #IMPLIED    – 서버측에 넘겨주는 이름 –

name 속성은 값으로써 CDATA(브라우저가 해석하거나 변조하지 않고 전달이 가능한 순수한 문자들)만 올 수 있는데 이 속성은 생략할 수 있다는 의미 입니다.

참고

• HTML 4.01 Transitional DTD – http://www.w3.org/TR/html401/loose.dtd | http://www.w3.org/TR/1999/REC-html401-19991224/sgml/loosedtd.html
• HTML 4.01 Strict DTD - http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd | http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html
• XHTML 1.0 Transitional DTD – http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd 
• XHTML 1.0 Strict DTD - http://trio.co.kr/webrefer/xhtml/dtd/xhtml1-strict.dtd
• How to read the HTML DTD – http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.3
• DTD 어떻게 읽는지 아세요? – http://www.pageoff.net/794

1. 문서형(DTD)을 꼭 선언해야 하나요?
2. 문서형(DTD)의 종류가 많던데 권장하는 것은 무엇입니까?
3. XHTML의 문법은 HTML과 비교해서 무엇이 다른가요?
4. HTML과 XHTML 가운데 어떤 문서형(DTD)을 사용하는 것이 좋을까요?
5. 문자셋(charset)으로 UTF-8을 권장하는 이유는 무엇인가요?
6. 휴먼 랭귀지(human language)가 무엇인가요?
7. 문서의 제목 <title>…</title>을 어떻게 작성하는것이 가장 좋을까요?
8. 의미론적 마크업(semantic markup)이란 무엇입니까?
9. 제목 요소 <hx>…</hx>는 어떻게 작성하는 것이 가장 좋을까요?
10. 의미론적 마크업을 잘 하는 방법이 있을까요?
11. 논리적인 순서란 어떤 것입니까?
12. 논리적 마크업을 위해서 화면 배치를 위한 <table>…</table>을 사용하지 않기로 했습니다. 이제 무엇으로 마크업 하나요?
13. 논리적인 마크업 예제를 한번 볼 수 있을까요?
14. 컬럼 구조 레이아웃을 위한 CSS 기법이 궁금합니다.
15. ‘id/class’ 선택자 사용 기준은 무엇이고 어떻게 네이밍 하는것이 좋을까요?
16. 이미지 대체 텍스트 속성 alt="*" 어떻게 작성하는 것이 가장 좋은가요? title="*" 속성과는 어떻게 다르죠?
17. 이미지에 포함된 텍스트의 양이 너무 많습니다. 어떻게 처리하죠?
18. 모두가 이용할 수 있는 longdesc 텍스트를 제공하고 싶습니다.
19. 웹 브라우저 호환성을 유지하기 위한 CSS 기법은 무엇이 있나요?
20. IR(Image Replacement) 기법이란 무엇입니까?
21. Image Sprite 기법이란 무엇입니까?
22. 동영상 대체 콘텐츠는 무엇이고 어떻게 처리해야 합니까?
23. 프레임셋 <frameset>…</frameset>의 문제는 무엇인가요?
24. 프레임셋 <frameset>…</frameset>을 사용한다면 무엇을 주의해야 하나요?
25. 서버와 데이터를 주고 받기 위해 내용 없는 빈 <iframe>…</iframe>을 사용하고 있습니다. 이런 빈 프레임에도 title="*" 속성을 이용해서 설명해야 하나요?
26. 모든 기능을 키보드로 이용할 수 있도록 하려면 무엇을 주의해야 하나요?
27. onclick과 onkeypress, onkeydown, onkeyup 이벤트 헨들러를 함께 사용하면 안되는 이유가 무엇입니까?
28. <a>…</a> 요소를 마크업 할 때 href 속성의 값으로 "#"을 사용하면 안되나요?
29. <button type="button">…</button> 요소의 의미와 사용법을 알려주세요.
30. <button type="button">…</button> 요소의 디자인을 CSS로 제어할 수 없나요?
31. CSS 기반의 가변폭 텍스트 버튼을 만들고 싶습니다.
32. 키보드의 논리적인 접근 순서를 위해 tabindex="*" 속성을 사용해도 될까요?
33. 건너뛰기 링크는 어떻게 구현하는 것이 가장 좋을까요?
34. 자바스크립트를 이용한 팝업 띄우기는 무엇이 문제인가요? 어떻게 하면 되죠?
35. 데이터 테이블 <table>…</table>을 의미있고 논리적으로 작성하는 방법은 무엇인가요?
36. 탭 메뉴 형태의 네비게이션은 무엇으로 어떻게 마크업 해야 합니까?
37. <label>…</label> 요소는 어떻게 사용하나요?
38. 플래시 <object>…</object> 네비게이션의 문제는 무엇인가요?
39. 겸손한 자바스크립트(Unobtrusive JavaScript)란 무엇입니까?
40. Ajax의 접근성 문제는 무엇입니까?
41. 시각 장애인을 위하여 CSS { display:none } 처리된 콘텐츠를 제공하는 것이 왜 나쁜가요?
42. CSS Framework이란 무엇 입니까?
43. 드림위버와 같은 위지윅(WYSIWYG) 도구는 웹 표준이나 접근성을 지원 하나요?
44. 드림위버는 너무 무거운 프로그램 아닌가요?
45. CSS 파일을 부를 때 <link />와 @import의 차이는 뭔가요? 어떤 방법이 더 좋죠?
46. 인쇄용 CSS를 어떻게 작성하는 것이 좋을까요?
47. IE 6 브라우저는 #id.class 다중 선택자 조합을 지원하지 않습니다.
48. IE 6 브라우저는 .class.class 다중 선택자 조합 일부를 지원하지 않습니다.
49. IE 6 브라우저는 float 처리된 요소의 margin을 두 배로 처리하는 버그가 있습니다.
50. IE 6~7 브라우저는 float된 요소의 문자를 복사하는 버그가 있습니다.
51. IE 6~7 브라우저는 float된 요소 주변에 등장하는 absolute 요소를 표시하지 않는 버그가 있습니다.

허걱 벌써 다 보셨나요? 저는 몇일 걸렸는데. ㅡㅡ;

문제

지금 보시는 화면은 현재 페이지의 콘텐츠를 앵커로 탐색하는 아주 흔한 네비게이션 입니다. 그리고 특정 섹션을 탐색 할 때 다른 섹션은 화면에 노출하지 않고 스크롤 과업도 없애서 되도록 내용에 집중할 수 있도록 고려된 디자인 입니다. 탭을 누를 때마다 마치 슬라이드가 한장씩 넘어가는것 같죠? 오늘의 문제는 이런 인터렉션을 아래 제시된 HTML 코드에 여러분이 직접 CSS 코드를 입혀서 자바스크립트 없이 구현하는 것 입니다.

HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ko">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>CSS Quiz 5 : Anchor Navigation</title>
<style type="text/css">
/* 여러분의 CSS 코드를 이곳에 넣으세요 */
</style>
</head>
<body>
<div id="header">
<h1>Anchor Navigation</h1>
</div>
<ol id="navigation">
<li><a href="#s1">Menu A</a></li>
<li><a href="#s2">Menu B</a></li>
<li><a href="#s3">Menu C</a></li>
<li><a href="#s4">Menu D</a></li>
<li><a href="#s5">Menu E</a></li>
</ol>
<div id="body">
<div id="content">
<div id="s1" class="section">
<p>앵커 네비게이션에 오신것을 환영합니다.</p>
</div>
<div id="s2" class="section">
<p>이 페이지는 앵커를 이용해서 탐색할 수 있습니다.</p>
</div>
<div id="s3" class="section">
<p>자바스크립트를 사용하지 않고도 간단한 인터렉션이 가능하다는 것을 보여줍니다.</p>
</div>
<div id="s4" class="section">
<p>웹 표준을 준수하고 접근성도 뛰어나죠.</p>
</div>
<div id="s5" class="section">
<p>콘텐츠의 높이가 브라우저의 뷰포트 보다 작고 높이가 고정된 상황에서 적절하게 사용할 수 있습니다.</p>
</div>
</div>
</div>
<div id="footer">
<address>
<abbr title="Xpress Engine">XE</abbr> Open <abbr title="User Interface">UI</abbr> Project by <a href="http://naradesign.net/">Naradesign</a>.
</address>
</div>
</body>
</html>

규칙

여러분은 CSS 코드만 작성하시면 됩니다. HTML 코드는 이미 제가 작성해 둔 것을 복사해서 변경 없이 사용해야 하고 자바스크립트는 사용하시면 안됩니다. 글상자 레이아웃의 너비는 800px, 높이는 400px 이며 브라우저의 창 크기를 조절하더라도 글 상자는 항상 화면의 정중앙에 위치해야 합니다. 그 외 자질구레한 레이아웃 요소들의 너비와 높이 및 색상은 여러분이 각자 알아서 결정하시면 됩니다. IE 6~8, Firefox 3, Safari 4, Opera 9, Chrome 2 브라우저에서 호환성을 유지해야 하고 CSS 문법 유효성 검사는 통과하지 않으셔도 됩니다. 캡쳐된 예제는 상자 모서리들이 라운딩 처리가 되어 있지만 그렇게 하지 않으셔도 됩니다. 선택된 메뉴(:active) 배경색이 현재 검정색으로 표시되어 있지만 그렇게 하지 않으셔도 됩니다.

정답은 2009년 6월 30일 자정까지 받겠습니다. 여러분의 계정에 정답 페이지를 생성해서 작성하신 다음 댓글에 URL을 적어 주세요. 퀴즈에 참여하실 분들은 정답을 제출하기 전까지는 다른 분들의 정답을 열람하시면 안됩니다. 이번에도 성공하신 분들께는 빌붙기 이용권이 제공 됩니다. 정답을 맞추시면 언제든 제게 밥을 사달라고 조르실 수 있습니다. ^^ 도전하세요!

참여하신 분들(빌붙기 이용권 획득)

1. dohoons – http://dohoons.com/test/cssQ/quiz5/test.html | http://dohoons.com/test/cssQ/quiz5/test2.html
2. 조성민 – http://elex.clus.org/quiz/quiz5.html
3. 황준상 – http://www.webpeace.net/css5.html
4. 이군 – http://e2goon.kr/study/naradesign-quiz/quiz5.html
5. vori – http://www.vori.net/css/AnchorNavigation.htm
6. hong! – http://viewbox.hosting.paran.com/asdf3.html
7. 조경수 – http://odini84.cafe24.com/naradesign/quiz5.html
8. 현쿠 – http://rokustd.blogspot.com/
9. 길앞잡이 – http://sljy.cafe24.com/temp/exam5.htm
10. 양영복 – http://cfs.tistory.com/custom/blog/23/233747/skin/images/quiz5.html
11. KevinCharis – http://www.kevincharis.com/quiz/anchor_Navigation.html
12. 얼리 - http://esayc.styx.in/quiz/quiz.html
13. 지연 - http://blog.naver.com/hautain/71028325
14. 무엇인가 - http://ecdemo32978.cafe24.com/quiz/cssquiz5.html
15. 조소 - http://pds15.egloos.com/pds/200906/29/28/css5.html
16. 정찬명 – http://naradesign.net/open_content/quiz/anchorNavigation/

목차

1. 지구촌 IE 버전별 점유율
2. 한국의 IE 버전별 점유율
3. 국내외 IE 통계의 시사점
4. IE의 버전별 웹 표준 지원 현황
5. IE8과 낡은 웹 사이트의 호환성 문제
6. 웹 표준 사이트와 낡은 브라우저의 호환성 문제
7. IE8의 향상된 웹 표준 활용하기
8. 개발자 도구를 사용하여 브라우저 호환성 테스트
9. 참고

지구촌 IE 버전별 점유율 ^{2009년 2월 Net Applications 보고서 기준}

한국의 IE 버전별 점유율 ^{2009년 2월 Internet Trend 보고서 기준}

국내외 IE 통계의 시사점

IE6, 7, 8 버전에 모두 대응할 필요가 있습니다. 한편, 0.1% 미만의 IE5.x 점유율을 어떻게 받아들여야 할까요? 0.1% 미만의 점유율을 의미있게 받아들이는 경우 이 문제를 해결할 방법이 전혀 없는 것은 아니지만 되도록 운영체제를 업그레이드 할 수 있게 권장하는 것이 ‘현실적인 타협점’이라고 생각 합니다. 0.1% 미만의 장애인을 정상인으로 만드는 것은 불가능 하기 때문에 인권 보호 차원에서 ‘윤리적/법적’ 으로 ‘반드시’ 대응할 책임이 있습니다. 그러나, 0.1% 미만의 장애 환경은 사용자의 의지에 따라 인위적으로 개선할 수 있는 환경이므로 ‘가능하다면’ 돕는것이 좋겠습니다. Microsoft가 0.1% 고객의 장애환경을 개선하는데 도움이 되었으면 좋겠습니다.

IE의 버전별 웹 표준 지원 현황 ^{Acid2 / Acid3 Test 기준}

Acid2 Test는 HTML/CSS/PNG 등의 렌더링을 표준에 따라 얼마나 잘 구현했는지 테스트 하는 도구 이며 Acid3 Test는 HTML/CSS/DOM/SVG 등의 렌더링을 표준에 따라 얼마나 잘 구현했는지 테스트 하는 도구 입니다.

IE6 = absolutely bad

Acid2	Acid3

IE7 = so bad

Acid2	Acid3

IE8 = so good

Acid2	Acid3

이런 추세라면 IE9 버전이 등장했을 때에는 ‘absolutely good’. IE10 버전이 등장했을 때에는 ‘excellent’ 정도의 평가를 기대해 보겠습니다.

IE8과 낡은 웹 사이트의 호환성 문제

IE8이 웹 표준 준수율을 극도로 개선함으로써 미래의 웹 개발자는 자연스럽게 표준을 준수하게 될 것이고 웹 브라우저의 호환성 문제는 점차 사라질 것입니다. 그러나, 과거에 작성된 낡은 페이지들은 오래된 브라우저에 최적화 되어 있기 때문에 IE8 브라우저에서는 오히려 깨질 것입니다. 이러한 현상은 "언젠가는 넘어야 할 산"이라고 생각합니다.

낡은 웹 사이트를 IE8에서 깨지 않기

낡은 웹 사이트라고 해서 모두 같은 것은 아닙니다. 낡은 웹 사이트는 크게 세 가지 유형으로 나뉩니다.

1. 첫째, DTD가 없는 웹 사이트.
2. 둘째, DTD가 있는 웹 사이트.
3. 셋째, DTD 없는 페이지와 DTD 있는 페이지가 웹 사이트에 혼재되어 있는 경우.

DTD가 없는 웹 사이트 대응법

DTD가 없는 페이지는 아무 대응을 할 필요가 없습니다. IE8은 DTD가 없는 페이지를 여전히 Quirks Mode로 렌더링 하기 때문에 웹 사이트는 깨지지 않습니다.

DTD가 있는 웹 사이트 대응법

DTD가 있는 페이지라고 해서 모두 같은것은 아닙니다.

1. 첫째, IE5에 최적화 된 페이지.
2. 둘째, IE6에 최적화 된 페이지.
3. 셋째, IE7에 최적화 된 페이지.

DTD가 있고 IE5에 최적화 된 페이지 대응법

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

DTD가 있고 IE6에 최적화 된 페이지 대응법

IE6에 최적화 된 페이지는 개편해야 합니다. 적어도 IE7에 최적화 시켜야 하는데 그렇지 않으면 구제할 방법이 없습니다. IE8 브라우저에 IE6 렌더링 엔진이 없기 때문입니다. IE6에 최적화된 페이지를 IE7에 최적화 하는 것은 그다지 어렵지 않습니다. IE6에 최적화 된 페이지는 IE7에 최적화 작업 후 다음 코드로 대응합니다.

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

DTD가 있고 IE7에 최적화 된 페이지 대응법

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

DTD가 혼재되어 있는 웹 사이트 대응법

DTD가 혼재 되어 있는 웹 사이트는 DTD가 없는 페이지와 DTD가 있는 페이지를 구분하여 각각 다른 방법으로 대응해야 합니다. DTD가 없는 페이지는 아무런 대응을 하지 않습니다. IE8은 DTD가 없는 페이지를 Quirks Mode로 렌더링 하기 때문에 페이지는 깨지지 않습니다. DTD가 있는 페이지는 IE7에 최적화 시킨 후 다음 코드를 적용 합니다.

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

만약, X-UA-Compatable 호환 코드를 DTD가 있는 페이지에만 별도로 적용하는 것이 어렵다면 모든 페이지에 호환 코드를 추가하는 방법도 있습니다. DTD가 있는 페이지만 IE7에 최적화 시킨 후 모든 페이지에 다음 코드를 적용합니다.

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

DTD가 없는 페이지는 여전히 Quirks Mode로, DTD가 있는 페이지는 IE7 표준 모드로 렌더링 할 것입니다.

Meta 호환 코드를 서버측 응답 헤더에 적용하는 방법

Implementing the META Switch on IIS

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=EmulateIE7" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>

Implementing the META Switch on Apache.

X-UA-Compatible:IE=EmulateIE7

웹 표준 사이트와 낡은 브라우저의 호환성 문제

웹 표준 사이트는 IE8에 별도로 대응할 필요가 없습니다. IE8이 웹 표준을 잘 지원하고 있기 때문입니다. 그러나, 웹 표준을 잘 지킨 사이트는 낡은 브라우저에서 깨질 것입니다. 낡은 브라우저는 웹 표준을 완전히 지원하지 않기 때문입니다. 또한, 낡은 브라우저라고 해서 다 같은 브라우저가 아닙니다. IE7, IE6, IE5 세 가지 버전의 브라우저 엔진은 지원하는 표준의 범위가 다르기 때문에 렌더링도 각각 다릅니다. 렌더링이 제각기 다르기 때문에 각각의 브라우저에 대응하는 CSS 코드도 달라야 합니다.

IE 조건부 주석을 사용하여 호환성 문제를 해결

조건부 주석이란, IE를 제외한 브라우저는 주석으로 처리하나 IE 브라우저는 버전에 따라 실제 콘텐츠로 인식하는 주석 입니다. 조건부 주석을 활용하면 IE7, IE6, IE5 각각의 브라우저에 최적화된 코드를 각각 다르게 적용할 수 있습니다. UI 개발자는 IE7, IE6, IE5 브라우저에 각각 대응하는 별도의 CSS 코드를 작성하고 각각을 파일로 분리합니다.

• default.css
• ie7.css
• ie6.css
• ie5.css

IE 조건부 주석의 이해

조건부 주석은 다음과 같은 형식을 갖습니다.

<!--[if expression]> HTML <![endif]-->

IE를 제외한 브라우저는 ‘<!--‘ 부터 ‘-->‘ 까지를 모두 주석으로 처리 하고 IE는 ‘HTML’을 실제 콘텐츠로 인식하고 파싱합니다.

IE 조건부 주석의 적절한 사용법

<link rel="stylesheet" type="text/css" href="default.css" />
<!--[if IE 7]><link rel="stylesheet" type="text/css" href="ie7.css" /> <[endif]-->
<!--[if IE 6]><link rel="stylesheet" type="text/css" href="ie6.css" /> <[endif]-->
<!--[if IE 5]><link rel="stylesheet" type="text/css" href="ie5.css" /> <[endif]-->

CSS Hack을 사용하여 호환성 문제를 해결

CSS Hack은 브라우저의 버그를 이용하여 문제를 해결하는 방법입니다. 버전별로 CSS 파일을 각각 작성하지 않아도 간편하게 낡은 브라우저에 대응할 수 있지만 CSS 문법 규격에 맞지 않는것이 흠입니다. CSS Hack은 미래의 다른 브라우징 장치에서 오류로 취급하지 않는다는 보장이 없기 때문에 항상 주의가 필요합니다.

IE5 ~ IE7 대응 Hack

#selector { property:value; *property:value; } /* 문서의 DTD와 무관하게 작용함 */


IE5 ~ IE6 대응 Hack

#selector { property:value; _property:value; } /* DTD가 없는 문서는 IE7에도 작용함 */

IE5 대응 Hack

#selector { property:value; _property /**/:value; } /* DTD가 표준모드인 경우에만 작용함 */

IE8의 향상된 웹 표준 활용하기

IE8이 등장 했지만 낡은 브라우저와의 호환성을 유지하기 위하여 향상된 표준 코드를 사용하지 않는 것은 바보같은 짓이라고 생각합니다. IE8이 지원하는 표준 CSS 코드를 얼마든지 사용할 수 있습니다. 향상된 브라우저에 향상된 스타일을 제공하고 더 나은 사용자 경험을 제공 해야 한다고 생각합니다. 단, 표준 코드가 낡은 브라우저에 대하여 콘텐츠를 차별하는 형태로 구현되어서는 안됩니다.

개발자 도구를 사용하여 브라우저 호환성 테스트

IE8 브라우저는 3가지 종류의 렌더링 모드를 지니고 있으며 웹 사이트 개발자는 IE8에 탑재되어 있는 개발자 도구(F12)를 이용하여 이 모드를 강제로 변경할 수 있습니다.

• Quirks Mode (IE5를 흉내내기 때문에 IE5 모드라고 볼 수 있음)
• IE7 표준 모드
• IE8 표준 모드

렌더링 모드의 전환은 웹 페이지나 서버측 응답 헤더에 ‘IE 호환 유도 코드‘(Meta Tag)를 사용함으로써 가능하지만 웹 페이지에 선언된 코드를 변경하지 않고도 개발자 도구를 이용하여 다양한 렌더링 모드 테스트를 진행할 수 있습니다. 개발자 도구에서 렌더링 모드를 직접 제어하는 방법은 두 가지가 있습니다. 두 가지 방법 모두 렌더링 엔진을 전환하는 기능을 하지만 ‘문서 모드‘는 클라이언트측에서 단순하게 렌더링 모드만을 변경하고 ‘브라우저 모드‘는 렌더링 모드 전환 뿐만 아니라 서버측에 브라우저 식별정보를 보내주어야 할 때 사용합니다.

• 문서 모드(Document Mode) : 클라이언트측 개발자에게 필요한 옵션으로써 다음과 같이 모드 전환이 가능합니다.
  • Quirks Mode : DTD가 있는 문서라도 마치 DTD가 없는듯 IE5를 흉내내는 렌더링을 합니다.
  • IE7 표준 모드 : DTD가 없는 문서라도 마치 DTD가 있는듯 IE7 표준 모드로 렌더링 합니다.
  • IE8 표준 모드 : DTD가 없는 문서라도 마치 DTD가 있는듯 IE8 표준 모드로 렌더링 합니다.
• 브라우저 모드(Browser Mode) : 브라우저 식별정보를 필요로 하는 서버측 개발자에게 필요하며 다음과 같이 모드 전환이 가능합니다.
  • IE7 모드 : IE7 브라우저와 같습니다. DTD가 없는 문서는 Quirks Mode로, DTD가 있는 문서는 IE7 표준 모드로 렌더링 합니다. 서버측에 브라우저 식별 정보를 보낼 때 IE7으로 보냅니다.
  • IE8 모드 : IE8 브라우저와 같습니다. DTD가 없는 문서는 Quirks Mode로, DTD가 있는 문서는 IE8 표준 모드로 렌더링 합니다. 서버측에 브라우저 식별 정보를 보낼 때 IE8으로 보냅니다.
  • IE8 호환성 모드 : IE7 브라우저와 같습니다. DTD가 없는 문서는 Quirks Mode로, DTD가 있는 문서는 IE7 표준 모드로 렌더링 합니다. 서버측에 브라우저 식별 정보를 보낼 때 IE7으로 보냅니다. 단, IE8의 호환성 모드를 이용했다는 정보까지 식별할 수 있게 됩니다.

참 고

• Internet Explorer Developer Center
• Internet Explorer 8 Readness Toolkit
• IE8 Compatibility Test Suites
• CSS Selector Test Suites

약 열흘 전 ‘여러 버전의 IE에서 IE Developer Toolbar 사용하기‘라는 제목으로 ‘Internet Explorer Collection‘ 이라는 도구를 소개해 드린적이 있습니다. UI개발자들이 다양한 버전의 IE에서 개발자용 디버깅 툴바(IE Developer Toolbar)를 사용할 수 있었기 때문에 매우 유용한 도구라고 소개를 드렸는데요. 이 도구가 정식으로 설치된 IE를 정상적으로 동작할 수 없도록 만드는 여러가지 유형의 버그를 포함하고 있는것이 발견되어 이 문제가 해결되기 전까지 더 이상은 권장하지 않는다는 내용을 전합니다. 다음은 현재까지 파악된 버그들 입니다.

1. 즐겨찾기에 등록된 웹사이트로 연결이 안됨.
2. 웹 페이지의 select, option 콘트롤 조작이 안됨.
3. MS 오피스 아웃룩의 이메일 본문에 포함된 링크 연결이 안됨.
4. 팝업 차단 및 차단 해제 기능 사용이 안됨.
5. ActiveX 설치 및 차단 기능 사용이 안됨.

IE를 기본 브라우저로 절대 사용하지 말라는 소개 페이지의 경고가 이런 상황을 염두한 것이었나 봅니다. 저는 설치된 IE Collection 및 IE Developer Toolbar를 모두 삭제하고 다시 Multiful IE를 사용하기로 결정 했습니다. 그리고 IE 8 RC^{Release Candidate} 1을 정식으로 설치 했습니다. 아직 정식으로 릴리즈 되지 않은 IE 8 후보를 설치하게 된 이유는 호환성 보기 버튼으로 IE 7 렌더링 엔진을 흉내낼 수 있고 기본으로 탑재되어 있는 개발자 도구(F12)가 IE 7 이뮬레이터 엔진과 IE 8 RC1 렌더링 엔진에서 모두 사용할 수 있기 때문입니다.

결국 IE 6 브라우저에 대한 디버깅은 순전히 여러분의 내공에 달려 있습니다. 힘내세요!

충분히 사용해 보고 후기를 올렸어야 하는데 너무 기쁜 마음에 허둥지둥 포스팅 하다보니 본의 아니게 여러분들께 불편을 끼쳐드린것 같아 벽보고 반성 중입니다. 죄송합니다. ㅜㅜ;