HTML4 명세는 tabindex를 다음과 같이 설명합니다. 이 설명은 XHTML 문서에도 동일하게 적용됩니다.

• 이 속성은 문서의 탭 순서 안에서 현재 요소의 순번을 결정한다. 값은 0부터 32767 사이의 숫자여야 한다. 브라우저는 값 앞에 0이 붙어있으면 무시해야 한다.
• 탭 순서는 사용자가 키보드를 통해 탐색할 때 어떤 요소가 초점을 받는 순서가 되는지를 결정한다.
• 초점을 받을 요소는 브라우저에서 다음과 같은 규칙에 따라 탐색되어야 한다.
1. 요소가 tabindex 속성을 지원하고 양의 값이 할당되어 있으면 먼저 탐색되어야 한다. 탐색은 tabindex 값의 가장 작은 수에서 시작하여 가장 큰 값으로 향한다. 값은 연속되는 일련의  숫자가 아니어도 상관이 없고 어떤 수로 시작해도 무방하다. 요소에 동일한 tabindex 값이 지정되어 있다면 코드 안에서 먼저 등장하는 순서대로 탐색되어야 한다.
2. tabindex 속성 지원 여부에 관계 없이 “0″의 값이 할당된 요소는 그 다음으로 탐색된다. 이 요소들은 코드 안에서 등장하는 순서대로 탐색된다.
3. disabled 속성이 사용된 요소는 탭 순서에 관여하지 않는다.
• a, area, button, input, object, select, textarea 요소가 tabindex 속성을 지원하는 요소이다.

어쨌거나 표준에 따르면 tabindex 속성에는 음수 값을 사용할 수 없습니다. 그러나 현존하는 브라우저들은 tabindex=”-1″ 속성이 부여된 요소에 대해 키보드가 접근하지 않는 방식으로 구현을 해놨더라구요. 결국 이 방식이 사실상 표준이거나 또는 공식 표준이 아닐까 하는 생각이 들어 HTML5 명세를 찾아 봤습니다.

HTML5 명세는 tabindex 속성의 음수 값을 다음과 같이 설명합니다.

• tabindex 값이 음의 정수라면 요소에 초점이 도달하지 않도록 해야 한다.

결국 tabindex 속성에서 음수 값을 사용하여 초점을 받을 수 없도록 하는 스펙을 추가한 것입니다. 그리고 현존하는 웹 브라우저들은 문서의 DTD에 관계 없이 이런 새로운 스펙을 낡은 문서에서도 사용할 수 있도록 구현해 둔 것입니다.

지구인들이 가장 많이 사용하고 있는 위지윅 에디터 TinyMCE와 CKEditor는 이런 코드를 도구모음 버튼에 적용하여 키보드 사용자들이 도구모음 블럭을 아예 건너 뛰도록 해 놨더라구요. 이런 구현방식에 대해 어떤 분들은 키보드 사용자를 고려하지 않았다고 주장할 수 있는데요. 제가 보기에는 이 친구들 센스있게 잘 처리한 것으로 봅니다. 키보드만으로 위지윅 에디터를 사용해 본 분들은 이런 처리를 이해할 수 있습니다.

네이버 스마트에디터와 다음 에디터는 도구모음 블럭에 키보드가 접근할 수 있도록 처리해 놨지만 실제로는 키보드만으로는 절대로 사용할 수가 없습니다. 일단 본문 영역에 초점이 들어가면 빠져나올 방법이 없기 때문에 문제가 시작됩니다. 편집 영역에 초점이 들어가면 Tab 키를 눌러서 빠져 나와야 하는데 Tab 키에 들여쓰기 기능을 맵핑해 놓았기 때문에 편집 영역에서 빠져나올 수 없습니다. 결국 키보드만 사용하는 시각 장애인 또는 상지 장애인(팔이 없거나 불편한)은 글쓰기 과업을 수행할 수 없었습니다.

tabindex=”1″

문서 안에서 가장 먼저 초점을 받을 수 있습니다. 그러나 자연스러운 마크업 순서를 거스르기 때문에 주의해서 사용해야 합니다. 검색엔진 사이트에서 검색창에 사용하면 적합하지만(이 대신 autofocus=”autofocus” 속성이 더 적절할 듯 해요) 그 외 적합한 경우는 잘 떠오르지 않는군요.

tabindex=”0″

키보드 초점을 받을 수 없는 div, span과 같은 요소도 초점을 받을 수 있도록 만들어 줍니다. 초점을 받되 초점을 받는 순서는 자연스러운 마크업 순서를 따릅니다.

tabindex=”-1″

키보드 초점을 받을 수 있는 요소도 초점을 받을 수 없도록 만들어 줍니다. 초점을 받을 수 없기 때문에 “-1″ 이외의 다른 음의 정수 값은 사실상 의미가 없습니다.

웹킷 엔진을 사용하는 크롬과 사파리 브라우저는 <input type=”search”  /> 요소를 다른 브라우저와 다르게 표시하는 특징(또는 버그)이 있습니다. search 타입은 HTML5 문서에서 새로 등장한 속성입니다.

보통의 경우 input 요소에 적용되어 있는 브라우저의 기본 CSS는 웹 제작자의 CSS 코드를 이용하여 덮어 쓸 수 있는데요. 크롬과 사파리 브라우저는 유독 <input type=”search”  /> 요소에 border 속성을 덮어쓰지 않도록 처리를 해 놨습니다. 원인을 찾다가 보니 크롬 브라우저에서 다음과 같은 코드가 UA(User Agent) 스타일시트 안에 포함되어 있더라구요.

input[type="search"] {
-webkit-appearance:searchfield;
box-sizing:border-box;
}

다른 타입의 input은 이렇지 않은데요. 유난히 search 타입만 이렇습니다.

• -webkit-appearance:searchfield; 라는 코드는 웹 제작자가 검색 input에 대한 border 속성을 덮어 쓸 수 없도록 만듭니다.
• box-sizing:border-box; 속성은 다른 일반적인 박스와 다르게 패딩과 보더를 너비값에 포함시켜 버리는 방식으로 면적(너비와 높이)을 계산합니다.

결국 웹 제작자는 검색 인풋을 의도한 대로 디자인 하기 어렵고 다른 브라우저와 다른 면적 계산 방식 때문에 당황하게 됩니다. 다른 input 요소와 동일한 방법으로 검색 input에 border 속성을 제공하고 일반적인 면적 계산 방식을 가질 수 있도록 하려면 웹 제작자는 다음과 같은 코드를 사용해서 UA 스타일을 덮어쓰기 할 수 있습니다.

input[type="search"] {
-webkit-appearance:textfield;
box-sizing:content-box;
}

끝입니다. 웹킷 개발자는 어떤 의도로 이렇게 처리를 해놓은 것일까요?

javascript:location='http://shauninman.com/vs/?url='+escape(location)

북마클릿은 원래 책갈피 등록이 되지 않기 때문에 아무 주소나 먼저 즐겨찾기에 추가한 다음 등록된 URL을 이 북마클릿 코드로 교체하면 됩니다. 그 다음 소스 보기를 원하는 페이지에서 이 북마클릿을 실행합니다.

스크린샷은 데스크탑에서 넣어야겠네요. 이런 짓을 왜 하냐고 물으신다면 다른 사람의 소스 코드가 미치도록 궁금해서 애달아 그럽니다.

단계1: 북마클릿을 아이폰 사파리 책갈피에 추가

단계2: 소소 보기를 원하는 페이지에 접속

단계3: 책갈피에서 북마클릿 실행

단계4: HTML 소스를 볼 수 있다

단계5: CSS 소스를 볼 수 있다

참고: http://goo.gl/LyRxH

CSS3 Media Queries

여러분이 CSS3를 배울 기회가 있었다면 다음과 같은 코드 @media (조건문) {실행문} 으로 무엇을 할 수 있는지 알 수 있습니다. CSS3 미디어 쿼리를 이용하면 모바일 환경의 뷰와 데스크탑 환경의 뷰를 원하는 해상도에 따라 완벽하게 분기 처리할 수 있습니다. 단 하나의 HTML 문서만가지고 말입니다.

@media (max-width:799px) { ... CSS for Mobile ... }  /* 이 코드는 799px 이하의 해상도에서 해석 됩니다 */ 
@media (min-width:800px) { ... CSS for Desktop ... } /* 이 코드는 800px 이상의 해상도에서 해석 됩니다 */

현존하는 최신 버전의 브라우저들은 CSS3 미디어 쿼리를 잘 지원하기 때문에 문제가 없지만 이 코드는 두 가지 문제가 있습니다. 첫째, 미디어 쿼리를 지원하지 않는 모바일 브라우저에 적용되지 않습니다. 둘째, 미디어 쿼리를 지원하지 않는 데스크탑 브라우저에 적용되지 않습니다. 두 가지 문제를 하나씩 풀어 보도록 하지요.

Mobile First CSS

미디어 쿼리를 지원하지 않는 모바일 브라우저에 대응하기 위해 저는 다음과 같이 코드를 작성 했습니다. 모바일에 대응하기 위한 코드를 미디어 쿼리 밖에 작성한 것입니다.

... CSS for Mobile ...
@media (min-width:800px) { ... CSS for Desktop ... }

이것으로 첫 번째 문제를 해결 했습니다. 미디어 쿼리를 지원하지 않는 모바일 브라우저는 미디어 쿼리 조건문 밖에 있는 코드를 해석합니다. 미디어 쿼리 구문은 지원하지 않으므로 해석하지 않습니다. 미디어 쿼리를 지원하는 모바일 브라우저는 해상도가 800px이 넘지 않는 이상 미디어 쿼리 구문을 해석하지 않습니다. 조건에 맞지 않으니까요. 미디어 쿼리 지원 여부에 관계 없이 799px 이하의 해상도를 지닌 모든 브라우저는 모바일용 CSS 코드만 해석합니다. 간단 명료하죠? 한편 미디어 쿼리를 지원하지 않는 IE 6~8 브라우저에서는 어떻게 보일까요?

IE 6, 7, 8 Compatibility

미디어 쿼리를 지원하지 않는 데스크탑 브라우저(IE 6~8)는 모바일 퍼스트 CSS 코드만 해석하기 때문에 모바일 뷰로 보일 것입니다. 낡은 데스크탑 브라우저가 미디어 쿼리문을 바르게 해석하도록 하기 위해 저는 다음과 같이 CSS3 미디어 쿼리 활성 스크립트를 HTML 문서에 추가 했습니다. 

<!--[if lt IE 9]>
<script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
<![endif]-->

IE 조건부 주석 'if lt IE 9 = if less than IE 9 = IE 9 미만이면 해석'을 사용하여 IE 9 보다 버전이 낮은 브라우저에서만 이 스크립트를 해석하게 됩니다. 표준계열 브라우저는 이 부분을 주석으로 처리하죠. 이제 IE 6~8 브라우저는 미디어 쿼리 구문을 올바르게 해석할 수 있게 됐습니다. 간단 명료하죠?

Tip 1: Performance Improvement

미디어 쿼리를 이용하여 데스크탑용 배경 이미지(background-image)와 모바일용 배경 이미지를 다르게 설정해 보세요. 미디어 쿼리를 이용하여 해상도별로 배경 이미지를 다르게 설정하면 다른 해상도에 필요한 배경 이미지는 서버로 전송 요청하지 않습니다. 즉, 특정 해상도에서 필요로하는 이미지만 요청(http request)하므로 미디어 쿼리를 통해 네트워크 자원을 아낄 수 있습니다. 웹 브라우저 개발자 도구의 네트워크(Network) 탭을 통해서 직접 확인해 보세요.

Tip 2: Override Mobile by Desktop CSS

모바일 퍼스트 CSS 코드는 낮은 해상도의 모바일용 브라우저에서만 해석하는 것이 아니라 높은 해상도의 데스크탑 브라우저에서도 동시에 해석하게 됩니다. 따라서 미디어 쿼리 조건문 안에서는 데스크탑용 CSS 코드가 모바일용 CSS 코드보다 더 높은 우선순위를 가질 수 있도록 덮어쓰기 하는 작업이 필요합니다. 손이 많이 갈것 같지만 모바일용 코드는 비교적 단순하기 때문에 그리 어렵지는 않을 것입니다.

References

• Responsive Design with CSS3 Media Queries
  
• Flexible, Mobile-First Layouts with CSS3
• HTML5 & Responsive Web Design
• Mary Meeker: Mobile Internet Will Soon Overtake Fixed Internet

HTML5

HTML5로 변경하는데는 약 2~3시간 정도 밖에 걸리지 않았습니다. 하지만 고민했던 시간은 꽤 길었습니다. div, section, article 요소를 혼동하지 않기 위해서 의미를 정확하게 이해해야 했습니다. DTD를 변경하고 header, footer 같은 새 요소들을 사용하면 IE6와 같은 낡은 브라우저에서 저 낮선 요소들을 어떻게 처리하는지 걱정도 했습니다.

HTML5 DTD declaration

HTML5 DTD는 매우 간단합니다. 예전에는 DTD를 외워보려고 갖은 애를 써도 그러지 못했는데 이제는 잊으려 애를 써도 잊지를 못합니다. <!doctype html> 이라고 적으면 끝입니다. case-insensitive. 대소문자를 구별하지 않으니 대문자로 쓰거나 소문자로 쓰거나 섞어 쓰거나 상관 없습니다. HTML5는 DTD 뿐만 아니라 요소와 속성 모두 case-insensitive 입니다. 대소문자를 구별하지 않습니다. 그러나 요소 이름과 속성을 대문자로 쓴다고 하면 말리고 싶습니다. 다른 이유는 없구요. 보기 불편하니까요.

Human language declaration

WCAG 2.0 지침의 3.1.1 항목을 보면 다음과 같은 구문이 있습니다.

"페이지 언어: 모든 웹 페이지의 기본 휴먼 랭귀지는 기계적으로 판단할 수 있어야 한다. (수준 A)"

휴먼 랭귀지란 사람이 쓰는 자연어를 말합니다. 수준 A란 최소한의 요구 조건 입니다.

<html lang="ko">

이렇게 html 요소에 한국어 휴먼 랭귀지 선언을 할 수 있습니다. 웹 문서에 휴먼 랭귀지를 선언하면 텍스트를 음성으로 변환해주는 시각장애인용 화면낭독기는 적합한 음성 엔진을 이용해서 웹 문서를 읽어줍니다. 예를 들어 로마자는 영어에만 쓰이는 것이 아니라 유럽에서 두루 쓰이는데요. 휴먼 랭귀지 속성을 선언하면 시각장애인용 화면 낭독기가 로마자를 어떻게 발음을 해야 하는지 정확히 알 수 있습니다. 한국형 웹 콘텐츠 접근성 지침인 KWCAG 2.0 지침에도 동일한 내용이 포함되어 있습니다. KWCAG 2.0에 포함되어 있다는 것은 향후 웹 접근성 품질마크 심사 지표에도 반영이 된다는 의미 입니다. 다음 회차의 웹 접근성 품질마크에는 이 기준이 적용되므로 웹 접근성 품질마크 심사에 도전하는 제작자는 반드시 휴먼 랭귀지를 작성해야 합니다. 이것은 HTML5 뿐만 아니라 다른 버전의 마크업 언어(HTML, XHTML)에도 동일하게 적용됩니다.

HTML5 enabling script

HTML5에는 여러가지 새로운 요소들이 등장 했습니다. 그러나 낡은 브라우저들은 이것을 알아차리지 못하는 문제가 있기 때문에 새로운 HTML5 요소들을 해석하거나 렌더링하지 않습니다. 도통 사람들이 업데이트를 하려고 하지도 않고 자동으로 업그레이드를 해주지도 않는 IE 6~8 브라우저가 그렇습니다. 우리는 낡은 브라우저가 새 요소들을 인식할 수 있도록 스크립트로 처리할 수 있습니다. 이 스크립트는 문서 head에 포함해서 브라우저가 낮선 태그를 만나 허둥대는 일이 없도록 처리하는 것이 좋습니다.

<!–[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]–>

"if lt IE 9 = if less-than IE 9" IE 조건부 주석을 사용해서 IE9 보다 버전이 낮은 브라우저에서만 이 스크립트를 해석하도록 한 것입니다. 스크립트는 새로나온 HTML5 요소들을 브라우저가 인식할 수 있도록 추가해서 낡은 브라우저들이 HTML5 요소들을 해석하고 렌더링 할 수 있도록 해줍니다.

CSS Reset

새로 추가된 요소들이 inline 요소인지 block 요소인지 브라우저들은 모를 수 있습니다. 따라서 다음과 같이 CSS display 상태를 정의해 줍니다. HTML5에서 새롭게 추가된 요소들을 모두 block으로 선언 했습니다.

header, footer, section, article, aside, nav, hgroup, details, menu, figure, figcaption {
    display: block
}

HTML5 Markup – Document Structure

의미론적 마크업을 글로만 배우면 막상 실무에 적용할 때 생각하지 못했던 고려사항들이 발생해서 고민도 되고 마크업을 하더라도 확신이 서지 않게 됩니다. 그런 의미에서 개인 블로그는 좋은 실험 재료인 것이죠. 제 블로그의 마크업 구조는 다음과 같습니다. 

• div
  • header
    • h1
  • section
    • article
      • h1
    • section
      • h2
    • section
      • h2
      • form
    • nav
  • nav
    • ul
      • li
  • footer

조금 더 자세히 풀어 볼까요?

• div – 본문의 폭을 제한하거나 중앙으로 배치하는 역할만 합니다. 별 의미는 없기에 div 요소를 사용 했습니다.
  • header – 사이트 제목과 설명이 등장하는 헤더 섹션입니다.
    • h1 – 사이트 최상위 제목.
  • section – 헤더, 풋터, 네비게이션 섹션이 아닌 일반적인 섹션입니다. section 요소는 웹 문서의 구조를 결정하는 핵심 요소 입니다. 섹션은 통상 하나의 헤딩과 명시적인 관계를 갖는것이 좋습니다. section & hx의 관계는 마치 fieldset & legend 요소와 구조적으로 흡사합니다. section 안에 포함된 hx는 section 내부에 포함된 콘텐츠의 제목이 됨과 동시에 현재 웹 문서의 개요 역할을 합니다. 제 블로그의 경우 section 요소와 hx 요소 사이에 article이 끼어들어 section이 제목 없이 글 본문, 댓글, 댓글 쓰기 폼을 감싸는 역할을 하고 있습니다. section은 바로 아래 첫 번째 자식으로 hx를 갖추는 것을 구조적으로 권장하지만 제 경우는 그러지 못했네요. 하지만 꼭 그런 구조를 갖추지 못해도 괜찮습니다. hx가 없어도 section은 section 이니까요.
    • article – 포스트 본문 섹션으로써 처음에는 section 요소와 어떤 의미적 차이를 지니는지 구분하기 어려웠습니다. 그러나 article 요소는 이 영역을 독립적으로 다른곳에 옮겨놔도 하나의 완전한 문서 또는 섹션이 될 수 있는 '재 사용' 가능한 또는 '배포 가능한' 본문 영역이라고 설명할 수 있겠습니다. section 요소와 마찬가지로 hx 요소를 갖는것을 강력하게 권장합니다. section과 article 요소 가운데 무엇을 써야 할지 망설여질 때에는 주변의 맥락과 분리하여 독립해도 하나의 완전한 콘텐츠가 되는지 아닌지를 판단해 보세요. 독립적이라면 article에 가깝고 현재 문서의 개요와 구조를 결정하는 역할이라면 section에 가깝습니다.
      • h1 – 포스트 본문 제목. h1이 두 번째 등장하죠. h1은 하나의 웹 페이지에 2번 이상 등장할 수 있습니다. W3C 웹 사이트도 이런 구조를 가지고 있으며 검색엔진 최적화에 좋습니다. 게시판에서 게시물 제목도 h1으로 마크업 하면 검색엔진으로부터 좋은 점수를 받을 수 있습니다. h1에 포함된 텍스트가 문서 헤드의 title 요소에도 들어가 있으면 금상 첨화죠. 제 블로그는 그렇게 처리되어 있습니다. 검색엔진이 좋아합니다.
    • section – 댓글 목록 섹션.
      • h2 – 댓글 목록 제목.
    • section – 댓글 쓰기 섹션.
      • h2 – 댓글 쓰기 제목.
      • form – 댓글 쓰기 폼.
    • nav – 이전 포스트 / 다음 포스트 네비게이션.
  • nav – 사이트 글로벌 네비게이션.
    • ul – 비순차 목록 컨테이너.
      • li – 네비게이션 항목.
  • footer – 저작물 이용 안내 및 RSS 주소를 담은 풋터 섹션.

HTML5 Markup – Form Controls

HTML5 Form의 위력은 아이폰을 사용하는 분들이면 쉽게 체감할 수 있습니다. 제 블로그에서는 다음과 같은 타입의 Form Control을 사용 했습니다. 제 블로그의 End-user 페이지에서 Form Control 이라고 해 봐야 검색창과 글쓰기창 뿐인데요. 적용 결과는 다음과 같습니다.

<input type="search" autocomplete="on" />
검색창의 인풋 타입이 search 입니다.

<input type="url" autocomplete="on"  />
댓글 쓰기 창에서 웹 사이트 주소 입력 인풋 타입이 url 입니다.

이 밖에도 HTML5에는 새롭게 추가된 다양한 input type이 있습니다. 아래 항목들은 HTML5에 새롭게 추가된 input type 입니다. 링크를 클릭하면 실제로 코딩된 페이지를 만날 수 있습니다. 현재는 오페라 브라우저만 input type을 거의 완벽하게 지원하고 있습니다. 오페라 브라우저를 통해 예제를 확인해 보세요. 다른 브라우저와는 다르게 인풋을 좀 더 편리하게 작성할 수 있도록 도울 것입니다.

• input type="search"
• input type="tel"
• input type="url"
• input type="email"
• input type="number"
• input type="datetime"
• input type="datetime-local"
• input type="date"
• input type="time"
• input type="month"
• input type="week"
• input type="range"
• input type="color"

HTML5의 인풋 타입을 적절하게 사용하면 아이폰 사용자에게 다음과 같이 문맥에 알맞는 자판을 보여줄 수 있습니다. 입력 커서가 인풋에 들어갔을 때 인풋 타입을 인식해서 최적화된 자판 배열을 표시합니다.

input type="search" 일 때 아이폰은 자판에 Search 키를 보여줍니다. 아이폰으로 input type="search" 테스트 해보기.

input type="tel" 일 때 아이폰은 자판에 숫자와 + * # 키를 보여줍니다. 아이폰으로 input type="tel" 테스트 해보기.

input type="url" 일 때 아이폰은 자판에 .com과 Go 키를 보여줍니다. 아이폰으로 input type="url" 테스트 해보기.

input type="email" 일 때 아이폰은 자판에 @와 . 키를 보여줍니다. 아이폰으로 input type="email" 테스트 해보기.

input type="number" 일 때 아이폰은 자판에 숫자와 특수문자 키를 보여줍니다. 아이폰으로 input type="number" 테스트 해보기.

Responsive Web Design

사용자가 어떤 해상도의 단말을 사용하든 그에 알맞는 뷰를 보여줄 수 있는 유연한 레이아웃 설계 기법입니다. 이름은 정말 근사하지만 막상 내용 뜯어보면 참 볼것 없습니다.

Mobile Viewport Declaration

모바일 단말기는 기본적으로 PC용 화면 전체를 작은 화면 안에서 모두 보여줍니다. 작은 화면에 전체를 담으려니 다음과 같이 글씨가 깨알만해져서 확대하지 않고는 보기가 어렵겠지요.(물론 아이폰4는 그냥 봐도 보입니다. 326dpi & 640*960px을 자랑하는 레티나 디스플레이잖아요.) 적당히 확대한 다음 수직 수평 스크롤을 해 가면서 어렵게 읽을 수 밖에 없습니다.

모바일 뷰포트를 선언하면 모바일 단말에 탑재된 웹 브라우저(Safari Mobile for the iPhone, Android browser, webOS browser in Palm Pre and Pixi devices, Opera Mini, Opera Mobile and BlackBerry browsers)는 웹 페이지를 적절히 크게 확대해서 보여줍니다.

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=2, user-scalable=yes" />
meta 태그의 각 속성에 대한 자세한 설명

그러나 콘텐츠의 너비가 크기 때문에 당연히 수평 스크롤이 필요합니다. 아래 이미지를 보면 아시겠지만 오른쪽에 내용이 더 있는데 잘려서 보이지 않습니다. 사용자는 여전히 수직 수평 스크롤을 모두 해야만 하는데 이것은 여간 짜증스러운 일이 아닙니다.

그래서 필요한 것이 바로 Responsive Web Design 입니다. 사용자가 어떤 해상도의 단말기를 가지고 있더라도 알아서 유연하게 콘텐츠를 정돈해서 보여주는 기술이 필요합니다. 한때는 320px의 화면 너비가 모바일 화면 크기의 대세가 될 줄 알았지만 지금은 그렇지 않습니다. 매우 다양한 해상도를 지닌 디바이스들이 쏟아져 나오고 있지요. 그렇게 새로운 단말기가 등장할 때마다 그 해상도에 맞는 웹 페이지 화면을 추가로 개발하시겠습니까? 세상에 그런 삽질을.

CSS3 Media Queries

CSS3에는 Media Query 라는 명세가 있고 최신 브라우저들(IE9, Chrome, Safari, Firefox, Opera)과 아이폰용 모바일 사파리 브라우저도 이를 지원하고 있습니다. 다음은 모바일 뷰포트를 설정해서 적당히 확대한 다음 Media Query를 이용해서 레이아웃을 알맞게 정돈한 제 블로그의 모바일 화면 입니다. 아름답지요.

미디어 쿼리 문법을 간단하게 살펴보죠. 제 블로그는 모바일 환경이든 아니든 불문하고 브라우저의 너비가 980px 이하로 작아지면 화면 우측에 있는 글로벌 네비게이션이 화면 아래쪽으로 뚝 떨어집니다. 지금 브라우저의 폭을 조절해서 한번 확인해 보세요.

@media all and (min-width:980px) {    /* 화면 너비가 980px 이상이고 미디어쿼리를 지원하는 브라우저라면 아래 코드를 해석함 */
    .content{ float:left; width:600px }    /* 콘텐츠 플롯하고 너비를 고정 */
    .nav{ float:right; width:330px }    /* 네비게이션 플롯하고 너비를 고정 */
}

딱 이정도의 사용법만 알아도 반응형 웹 디자인은 게임 끝입니다. 게임 끝 아닙니다. 모바일 퍼스트 CSS 전략에 대해 더 자세히 알아보세요.

• W3C Media Queries - http://www.w3.org/TR/css3-mediaqueries/
• CSS3 Media Queries Vol.1 - http://mydeute.com/txp/article/631
• Mobile first strategy for CSS designer - http://naradesign.net/wp/2012/01/18/1742/

 게임 끝.

모든 웹 기반의 위지윅 에디터를 조사한 것은 아니지만 제가 간단하게 벤치마킹한 결과에 따르면 국내외를 막론하고 대부분의 제품들은 웹 브라우저가 기본으로 제공하는 처리 방식에 따라 p 요소에 Enter키를 맵핑해 두었고 br 요소에 Shift+Enter키를 맵핑해 두었습니다.

한편 글로벌 제품들은 p 요소에 브라우저가 제공하는 기본적인 상하 여백 {margin:1em 0} 스타일을 그대로 살려두는 방식을 채택했는데 국내 제품들은 p 요소에 브라우저가 제공하는 기본적인 상하 여백을 {margin:0} 으로 덮어쓰기 하는 방식으로 리셋 했습니다.

이를 통해서 우리는 다음과 같은 세 가지 사실을 알 수 있습니다.

• 해외에서는 Enter키를 치면 단락을 변경하는 것으로써 단락 사이의 여백이 학습되어 있다. 행간 여백 없이 줄 바꿈을 하려면 Shift+Enter를 치면 된다.
• 한국에서는 Enter키를 치면 단락을 변경하는 것이 아니라 단순히 줄 바꿈을 하는것으로 학습되어 있다. 단락을 구분하려면 Enter키를 두번 치면 된다. 문단 요소 p의 여백이 제거되어 있으므로 Shift+Enter를 알 필요도 없다.
• 외국 사람과 한국 사람은 웹에서 선호하는 글쓰기 모양도 다르고 경험도 다르다. 외국 사람은 하나의 문장에 마침표를 찍더라도 다음 문장을 줄 바꿈 없이 이어쓰며 단락을 바꿀 때에만 Enter를 치는 경향이 있고 한국 사람들은 마침표를 찍으면 다음 문장을 쓰기 위해 줄을 바꾼다. 외국인이 생성하는 태그는 의미론적 관점에서 옳은 방향이나 한국인이 사용하는 방식은 편리하다.

외국인과 한국인의 습성이 다를 뿐만 아니라 글쓰기 교육 시간에 문단을 바꿀 때에만 개행하라고 배웠다 하더라도 한국 사람들의 글쓰기가 틀렸다고 보기는 어렵다고 생각합니다. 국민 모두가 한 방향으로 틀렸다면 그 방향이 우리 나라에서는 사실상 통용되는 표준이라고 인정해야 한다는 생각입니다. 따라서 우리의 고민은 다음과 같이 전개됩니다.

• 한국에서 제품을 만들기 시작했지만 글로벌 시장에 진출하려면 사실상 국제 표준에 따라야 한다.
• 글로벌 시장에 진출하더라도 한국 시장은 포기할 수 없다.
• 우리 제품은 내수용과 수출용 구분이 따로 없다.

‘A’도 만족해야 하고 ‘B’도 만족해야 한다면 둘 다 만족 시켜주자라는 것이 중론인데요. 다음과 같은 제안들이 검토 대상에 올랐습니다.

• p 요소는 Enter키로 생성하며 br 요소는 Shift+Enter키로 생성한다.
• p 요소의 여백을 관리자 화면에서 원하는 방식으로 선택할 수 있도록 옵션을 제공한다. "[v] p 요소에 여백 제거"
• p 요소의 여백을 글 쓰는 사람이 에디터에서 직접 선택할 수 있도록 옵션을 제공한다. "[v] p 요소에 여백 제거"
• p 요소에 브라우저가 제공하는 기본 마진을 보존한 다음 Enter 한번은 br 요소를 생성하고 Enter 두번은 p 요소를 생성한다. (이 방법은 작년부터 제안되었으나 구현에 대한 난제가 있었던 것으로 지금은 정확히 기억이 나지 않네요)

글 쓰는 사람이 에디터에서 직접 선택할 수 있도록 옵션을 제공하는 방법은 개인적으로 반대하는 방법입니다. 개발자 또는 관리자가 해야 할 선택을 사용자에게 떠넘겨 UI를 복잡하게 만든다는 느낌을 지울 수가 없고 의미를 정확하게 간파하는 사용자도 드물꺼라 생각합니다. XE개발팀에서 XEED라는 새로운 에디터를 개발하며 이 문제를 어떻게 해결하는지 지켜봐주세요. 그리고 좋은 의견이나 경험담이 있으면 댓글로 함께 의견 나누시죠.

IE6는 아직 살아있다.

넷어플리케이션즈의 2010년 9월 최근 통계에 따르면 아직 전세계적으로 IE6 사용자는 16% 수준의 점유율을 보이고 있습니다. 인터넷트렌드의 2010년 9월 통계에 따르면 국내 IE6 사용자는 무려 36%나 됩니다. IE7과 IE8은 국내에서 각각 30% 수준의 점유율을 보이고 있습니다. 사람들은 IE6 브라우저의 장례식을 치를만큼 낡은 브라우저가 하루속히 사라져주길 원하지만 IE6는 아직 죽지 않았습니다. 웹 개발자는 IE6, IE7, IE8, IE9 브라우저에 모두 대응해야 합니다.

IE 브라우저 버전은 4개 이지만 둘로 구분할 수 있다.

IE6, IE7, IE8, IE9 브라우저 버전은 4개이나 표준 준수율 또는 버그 발생률에 따라 단 두 가지 종류로 간단하게 구분할 수 있습니다.

IE8~9 브라우저는 HTML/CSS 표준 준수 테스트 도구인 Acid2 테스트에서 모두 만점을 받은 브라우저 들입니다. 따라서 이 두 버전의 브라우저는 다른 여느 표준계열 브라우저들(크롬, 사파리, 오페라, 파이어폭스)과 어깨를 나란히 합니다. IE8 또는 IE9 브라우저에 최적화된 웹 페이지는 다른 브라우저에서도 별 문제 없이 똑같이 잘 보입니다.

그러나 IE6~7 브라우저는 표준 준수율이 상대적으로 떨어지고 버그도 많습니다. 다행인것은 IE6 브라우저와 IE7 브라우저가 그다지 큰 차이가 없다는 점입니다. IE6 브라우저에서 발생하는 문제는 IE7 브라우저에서 동일하게 발생할 확률이 높습니다. IE7 브라우저가 조금 더 나을 뿐입니다.

결국 저는 IE8~9 브라우저에 대해서는 할 말이 많지 않습니다. IE6~7 브라우저의 문제 해결을 위해서 몇 가지 팁을 소개합니다.

IE6~7 문제해결.

• IE6~7 브라우저도 표준에 따라 구현된 브라우저 입니다. 표준 DTD를 사용하면 표준에 따라 잘 렌더링 해줍니다. 반드시 표준 DTD를 사용하세요. DTD를 사용하지 않으면 모든 브라우저들이 IE5 버전의 브라우저를 흉내내는 Quirks Mode 상태가 되어 각기 다른 뷰를 출력합니다.
• 사용자에게 무엇이 더 좋은지 HTML과 XHTML의 우위를 논하는 것은 무의미 합니다. 그러나 XHTML의 엄격한 문법이 개발자에게는 더 유리할 것입니다.
• 엄격한(Strict) DTD와 호환형(Transitional) DTD 가운데 호환형 DTD를 추천합니다. 엄격함은 많은 오류를 유발할 뿐입니다.
• 마이크로소프트의 독자적인 표현방식인 hasLayout이 존재한다는 것을 알아야 합니다. hasLayout이 없으면 문제가 발생하는 경우가 많습니다. IE6~7 브라우저에서 화면에 특정 요소가 보이지 않거나 잘못된 표현을 하면 { zoom:1 } 속성을 추가로 부여하여 해결되는 경우가 많습니다. zoom 속성은 hasLayout Trigger 이며 다른 브라우저들은 해석하지 않는 속성입니다.
• float된 방향와 같은 방향의 margin이 존재하는 경우 IE6 브라우저는 margin을 두 배로 출력하는 빈도 높은 버그가 있습니다. float이 부여된 요소에 display:inline 속성을 부여하면 해결됩니다. float 처리된 요소는 display 속성이 block으로 바뀌는데 이 값은 절대로 덮어쓰기가 되지 않습니다. float된 요소에 inline 속성을 부여해도 여전히 block 이라는 뜻입니다. 그 밖에 float 요소는 마지막 텍스트 콘텐츠를 복사해서 출력하는 버그도 있는데 이 때에도 display:inline 속성을 부여하면 해결됩니다.
• zoom 속성으로 문제가 해결되지 않으면 position:relative 속성을 사용해 봅니다. display:block 으로 처리한 a 요소의 클릭 영역이 제대로 잡히지 않는 문제를 해결할 수 있습니다. 마우스 커서 모양의 잘못된 출력도 바로잡아 줍니다.
• *property:value와 같은 형식으로 속성 앞에 ‘*’ 별표를 붙이면 IE6, IE7 브라우저만 이 속성을 해석하고 다른 브라우저는 무시합니다.
• _property:value와 같은 형식으로 속성 앞에 ‘_’ 언더바를 붙이면 IE6 브라우저만 이 속성을 해석하고 다른 브라우저는 무시합니다.

IE6~9 브라우저에서 CSS3 사용하기.

낡은 브라우저 때문에 신기술을 사용할 수 없다는 생각은 극복할 수 있습니다. 마이크로소프트에서 이미 오래전에 브라우저에 탑재했던 기술이 CSS3 표준으로 채택(word-wrap, text-overflow, @font-face)이 되기도 했고 CSS3와 유사한 기술(filter)이 이미 IE6~8 브라우저에 구현되어 있기도 합니다. 우리는 신기술을 사용하거나 또는 모방하면서 브라우저 호환성도 유지할 수 있습니다.

IE6~9 브라우저에서 사용하거나 모방할 수 있는 CSS3에 대한 설명은 HTML5 오픈 컨퍼런스에서 발표했던 CSS3 소개 자료로 대신합니다.

요점 정리.

1. 현존하는 하위 버전 브라우저에 대한 호환성을 지원해야 합니다.
2. 신 기술의 사용을 두려워 할 필요가 없습니다. 좋은 도구를 선택한 사용자에게 향상된 경험을 전달해야 합니다. 
3. 낡은 브라우저 비난하기 보다는 새 브라우저를 추천 합시다.

다소 지루하고 딱딱한 발표였음에도 불구하고 관심을 가지고 들어주셔서 고맙습니다. IE10 런칭 행사에서는 더 이상 낡은 브라우저 이야기는 나오지 않았으면 하는 바램입니다. 아마 한국 마이크로소프트도 그런 기대를 가지고 있을 것입니다. 발표자료. 발표영상.

컨퍼런스는 신청자 접수를 시작한지 20시간만에 650좌석이 모두 매진될만큼 큰 관심을 끌었습니다. 발표자들은 단순히 프리젠테이션을 공개하는 것에서 끝나지 않았고 책(실전 HTML5 가이드)으로 만들어 배포할 것을 처음부터 염두했습니다. 때문에 컨퍼런스 참석자들에게는 책자로 제공이 되고 참석하지 못한 분들께도 무료(CCL 3.0)로 배포가 되었습니다.

저는 CSS3에 대한 소개자료 집필과 발표를 맡았습니다. CSS3는 어떤 HTML 버전을 선택하더라도 사용할 수 있는 HTML 버전과 무관한 기술이기 때문에 특별히 HTML5에 대응한다고 보기는 어렵습니다. 단지 HTML5와 같은 시기에 개발이 되면서 브라우저 벤더들이 이를 현실로 구현했기 때문에 주목을 받은것 뿐입니다. 엄밀하게 따져서 굳이 HTML5 오픈 컨퍼런스에 포함되지 않아도 무방하지만 빠졌을 때 아쉬움이 남을 수 있는 섹션이라고 이해하시면 될 것 같습니다. 소개팅 자리에 그냥 이성이 등장하는 것보다 예쁘거나 멋진 이성이 등장하기를 바라는 것과 같은 마음으로 이해하시면 될 것 같습니다.

CSS3는 아직 권장 표준이 아닙니다. 그러나 대중적인 브라우저 벤더들은 일부 스펙(모듈)을 현실 속에서 이미 구현했습니다. text-overflow, word-wrap, @font-face와 같은 속성이나 규칙들은 이미 IE 6~8 브라우저에서도 사용할 수 있습니다. 마이크로소프트에서 이미 오래전에 제안하고 자체적으로 구현했지만 이제서야 CSS3 스펙으로 수용되면서 다시 세상의 빛을 보게 된 샘이죠. 이 밖에도 브라우저들은 실험적으로 또는 정식으로 CSS3 속성들과 선택자들을 앞다투어 지원하고 있습니다. W3C에 의해 권장 표준이 되는 것이 공식적인 표준이라 할 수 있지만 이미 많은 브라우저 벤더들에 의해 구현되어 있다면 사실상 표준이라고 볼 수 있으며 실무에서 유용하게 사용할 수 있습니다.

CSS3의 기교와 데모에 관한 자료들은 검색을 통해서 외국의 자료들을 쉽게 접하실 수 있습니다. 그러나 IE 점유율이 97%에 이르는 한국의 상황을 감안하면 한국의 웹 개발자에게는 뭔가 추가적인 정보를 제공해야 한다고 생각 했습니다. 최신 표준 브라우저의 지원 현황 뿐만 아니라 IE 6~8 브라우저에서도 사용할 수 있는 기법들을 소개하고 만약 IE 브라우저가 지원하지 않는 속성이라면 fallback을  제공하는 방법도 소개해야 한다고 생각 했습니다. CSS3가 아무리 뛰어난 기술이라 해도 낡은 브라우저에서 사용할 수 없다면 흥미는 곧 반감될 것입니다. 여기서 fallback이란 CSS3를 지원하지 못하는 상황에서 이를 대체할 수 있는 대안들 입니다. 마이크로소프트의 filter 속성이나 자바스크립트 라이브러리가 그러한 예 입니다.

CSS3를 소개하는 것이 저의 역할이었지만 저는 다음과 같은 메시지를 가장 중요하게 기억해 달라고 청중에게 부탁 했습니다.

더 좋은 도구를 선택한 사용자에게는 더 향상된 경험을 주자. 이것은 좋은 도구(브라우저)를 선택하지 않은 사용자를 차별하는 것이 아니며 그래서도 안된다. 중요한 것은 ‘경험의 질’을 높이는 것이지 어떤 사용자를 ‘포기’하자는 것이 아니다.

최근 웹 표준을 준수하지 않는 낡은 브라우저라는 이유로 IE6 브라우저를 지원하지 않는것을 마치 대단한 업적이 되는 것과 같이 말하는 것은 옳지 않다고 말했습니다. 아직까지 상당히 많은 사용자 수를 확보하고 있는 낡은 브라우저(IE6, 국내 42.84%)를 지원하지 않는 것은 웹 표준의 목표인 상호 운용성(하위 호환성이 포함된 개념)과 대치되는 것이라고 설명 했습니다. 웹 표준은 목표가 아니라 수단일 뿐입니다. IE6가 웹 표준 준수율이 낮다는 이유로 배척하는 것은 옳지 않다고 생각합니다.

발표자료(참고자료) 내려받기 + 북마크

• 실전 HTML5 가이드 내려받기 - http://html5.creation.net/html5-guide.pdf
• CSS3 소개 – http://naradesign.net/ouif/css3/
  • CSS3 소개(인쇄용) – http://naradesign.net/ouif/css3/documentation.html
  • CSS3 소개(발표용) – http://naradesign.net/ouif/css3/presentation.html
• 참고(구글에서 제공하는 HTML5/CSS3 프리젠테이션) 추천 – http://slides.html5rocks.com/

몇 가지 오류 정정

• gradient 속성과 animation 속성을 설명하는 과정에서 ‘linear’라는 단어의 발음을 ‘라이니어’라고 잘못 발음 했습니다. ‘리니어’라고 발음해야 합니다.
• 프리젠테이션에는 흥미를 유발하기 위하여 ‘여우’가 두 번 등장하고 ‘늑대’는 아예 등장하지도 않았는데 제가 ‘늑대’라고 잘못 말했습니다. ‘여우’로 정정 합니다. 
• ‘우리나라’를 ‘저희나라’라고 잘못 표현했습니다. ‘저희나라’라는 표현은 청중이 외국인인 경우에 ‘우리나라’를 겸손하게 표현하기 위하여 사용할 수도 있는 표현이지만 이를 포함한 모든 상황에서 국가를 낮추어 부르는 것은 적절하지 못한 표현이라는 의견이 있다는 것을 뒤늦게 알았습니다.

두 가지 아쉬운 점

• 유료 세미나 자료를 무료로 웹에 공개하는 것이 불편하다고 느끼는 분이 있어서 제 마음도 불편했습니다. 이 세미나를 주최한 누구도 특정 계층에게만 좋은 정보가 폐쇄적으로 공유되는 것에 찬성하지 않을 것입니다. 이 컨퍼런스는 HTML5 ‘독점’ 컨퍼런스가 아닙니다. 지금은 생각이 바뀌셨길 바랍니다.
• CSS3 또는 제 발표에 대하여 궁금증을 가진 분들은 Q&A 시간에 질문자로 선택받지 못했습니다. 편파적인 진행에 감사드립니다. (농담입니다. ㅎㅎ)

웹 표준 프로젝트 멤버, 발표자, 후원자, 자원봉사자, 긍정적이든 부정적이든 여러가지 피드백을 보내주신 여러분들께 두루 감사드립니다.

제가 요즈음 싸부로 모시는 행복한고니의 jQuery 강의를 들을 기회가 있었는데 이런걸 알려 주더라구요. jQuery를 잘 쓰려면 먼저 세 가지 순서를 기억해야 하는데 그것은 바로 '선택하고-실행하고-조정하라'는 것이었습니다. 오늘 제 포스팅은 '선택'과 관련된 이야기 입니다. jQuery 코드는 아직 한 줄도 없지만 사실 저는 jQuery 강좌를 시작한 것과 다를 바 없습니다.

저 jQuery 잘하냐구요? 아니요. 저는 제가 이미 알고 있는 것들을 글로 옮기는 일에는 사실 흥미가 없습니다. 주로 모르는 것을 잘 알기 위해 글을 쓰는 편이죠. 얼마전 라디오를 듣는데 어떤 교수님께서 이런 고백을 하십니다. "교수들은 사실 학생들을 가르치는 척 하면서 배운다" 라구요. 이것은 교수님들만의 이야기는 아닌것 같아요.

참, 그리고 한 가지 더 추가 하자면 CSS는 낡은 브라우저(IE6)에서 선택자 사용을 지원하지 못하는 호환성 문제가 있지만 자바스크립트는 그렇지 않습니다. jQuery는 아래 표시된 모든 브라우저에서 똑같이 선택자 사용을 지원합니다. 이것 또한 jQuery의 장점 이라고 할 수 있겠네요. CSS를 이용해서 뭔가 선택하지 못하는 경우 jQuery를 이용하면 선택할 수 있으니까요.

가령 게시판을 제작할 때 짝수 행 <tr> 만을 선택하여 배경색을 지정하려는 경우 tr:nth-child(even) 이라는 CSS 선택자를 사용할 수 있지만 IE 6~8 브라우저는 아직 CSS 3 선택자를 지원하지 않기 때문에 표현이 불가능 합니다. 그러나 jQuery는 이렇게 '선택+실행' 할 수 있습니다.

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script>
<script type="text/javascript">
jQuery(function($){
  $('tr:nth-child(even)').css('background','red');
});
</script>

odd는 홀수를 의미하고 even은 짝수를 의미하죠. 아직 자바스크립트 또는 jQuery를 배울만한 동기가 없으셨던 분들께는 새로운 동기부여가 되었으면 좋겠습니다. 아주 쉽다는 것을 깨닫고 한 번 사용하기 시작하면 걷잡을 수 없이 빠져드는 매력이 있답니다. 그러나 과유불급. 어느곳에 쓰고 어느곳에는 쓰지 말아야 할지 정확히 알고 쓰는것이 더 중요합니다. HTML/CSS 만으로도 충분히 가능한 일을 JS에게 완전히 의존하는 코드를 보면 저는 이렇게 이야기 한답니다. "건방지게 어딜 나서? 겸손할 줄 알아야지. 넌 항상 HTML/CSS 다음이야." 라구요.

문제 1 _ CDK는 무엇의 약어 입니까?
[CSS Design Korea]

문제 2 _ KWAG은 무엇의 약어 입니까?
[Korea Web Accessibility Group]

문제 3 _ CSS, HTML, XHTML 무엇의 약어 입니까?
[Cascading Style Sheet, Hyper Text Markup Language, eXtensible Hyper Text Markup Language]

문제 4 _ W3C는 무엇의 약어 입니까?
[World Wide Web Consortium]

문제 5 _ 이 이미지가 사용되는 테스트의 이름은 무엇입니까?
[Acid2 Browser Test]

문제 6 _ DOCTYPE 선언은 닫힘 태그가 있다?
[X - 없습니다.]

문제 7 _ XHTML 태그의 속성 및 값은 소문자만 사용할 수 있다?
[X - 속성은 소문자로만 작성해야 하나 값은 대문자 사용 가능합니다.]

문제 8 _ 오래된 웹 브라우저들을 위해 디자인된 웹 페이지의 하위 호환성을 유지하기 위해 W3C나 IETF의 표준을 엄격히 준수하는 Standards Mode를 대신하여 사용되는 웹 브라우저의 기술을 나타내는 용어는?
[Quirks Mode - Quirks Mode는 IE5 브라우저를 흉내낸다]

문제 9 _ 다음 중 대중적인 브라우저에서 Quirks Mode로 랜더링 되는 DTD를 모두 고르시오.
1. DTD 없음.
2. <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0//EN”>
3. <!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
4. <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” ”http://www.w3.org/TR/html4/loose.dtd”>
5. <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
6. <!DOCTYPE html>
[1번, 5번. 참고 - http://naradesign.net/wp/2007/03/27/118/]

문제 10 _ 하이퍼링크에서 밑줄을 없애기 위한 방법으로 맞는 것은?
1. a { text-decoration:no underline; }
2. a { decoration:no underline; }
3. a { text-decoration:none; }
4. a { underline:none; }
[3번]

문제 11 _ 소문자로 작성된 영문 단어의 첫 글자를 대문자로 바꾸는 CSS 스타일은 무엇입니까?
1. CSS로는 불가능하다.
2. { text-transform:uppercase; }
3. { text-transform:capitalize; }
[3번]

문제 12 _ IE6 브라우저에서 float과 margin을 같은 방향으로 설정 했을 때 발생하는 더블 마진 버그를 예방하는 방법은?
1. width 값을 부여한다.
2. { position:relative; }
3. { display:inline; }
4. { zoom:1; }
[3번 - IE6 브라우저는 float과 margin의 방향이 같은 경우 두 배의 마진이 발생한다. 이 때 display 속성을 inline으로 바꾸면 더블 마진 버그가 발생하지 않는다. 그러나 float 속성이 부여된 요소는 display 속성이 block이 된 상태로써 이 값은 어떤 경우라도 덮어 쓸 수 없기 때문에 이 요소의 display 속성은 여전히 block 이다.]

문제 13 _ CSS 속성 중 cursor 속성의 값으로 올바르지 않은 것은?
1. default
2. help
3. pointer
4. hand
[4번 - hand라는 값은 MS IE 전용 값으로써 비 표준 속성이다. 그러나 IE 5.5 버전 이하의 브라우저는 pointer라는 값을 지원하지 않고 hand라는 값을 지원하는데 hand라는 값은 pointer와 같은 모습으로 랜더링된다.]

문제 14 _ CSS의 속성 가운데 박스의 border-color 속성이 지정되지 않은 경우 border-color의 값은 color 속성의 값으로부터 상속 받는다?
[O - 정답 입니다. border-color의 값이 지정되지 않은 경우 color의 값은 border-color의 값이 됩니다. 즉, border-color 를 지정하지 않은 요소에 color:blue 값을 지정하는 경우 이 요소의 border-color는 blue가 됩니다.]

문제 15 _ <input> 요소의 type 속성은 생략할 수 있다?
[O - 생략할 수 있습니다. 생략하는 경우 type 속성의 기본 값은 text가 됩니다. 한편 사용자의 입력 내용을 서버로 전송하려면 반드시 name 속성을 사용해야 합니다. 그러나 문법적으로는 어떤 속성도 필수로 요구하지 않습니다.]

문제 16 _ Transitional DTD를 사용하는 HTML 또는 XHTML 문서에서 CSS font 속성은 table 요소에 상속되지 않는다?
[X - 상속 됩니다. 그러나 DTD가 Quirks Mode인 경우에는 상속되지 않습니다.]

문제 17 _ <textarea> 요소는 row 속성과 col 속성을 생략할 수 있다?
[X - 반드시 작성해야 하는 속성으로서 생략할 수 없습니다.]

문제 18 _ CSS 속성 중 background-color는 Javascript에서 backgroundcolor로 표기한다?
[X - 대소문자에 유의해야 합니다. Javascript 에서는 CSS 속성을 카멜 케이스로 표기하는데 background-color는 backgroundColor 라고 표기 합니다.]

문제 19 _ <button> 요소에 type 속성을 지정하지 않는 경우 type 속성의 기본값은 button 이다?
[X - button  요소에 type 속성을 지정하지 않으면 기본 값은 submit이 되어 form을 전송하게 됩니다. 따라서 form을 전송하기 위한 목적이 아니라 단순하게 UI를 조작하기 위한 버튼(예:닫기, 인쇄) 이라면 type 속성을 button 이라고 정확히 명시해 주어야 합니다. 한편 IE6~7 브라우저는 button 요소에 type 속성을 지정하지 않는 경우 type 값이 button으로 동작하므로 혼동하지 않도록 유의해야 합니다.]

문제 20 _ XHTML 1.0 문서는 어떤 종류의 DTD를 가지고 있습니까?
[Strict, Transitional, Frameset]

문제 21 _ 웹 접근성 국가 표준의 4가지 원칙은 무엇입니까?
[인식의 용이성(Perceivable), 운용의 용이성(Operable), 이해의 용이성(Understandable), 신기술적 진보성(Robust)]

문제 22 _ CSS를 발명한 사람은 누구 입니까? 두 명을 고르세요.
1. Eric Meyer
2. Håkon Wium Lie
3. Tim Berners Lee
4. Bert Bos
5. Jeffrey Zeldman
[2번, 4번]

문제 23 _ 다음은 HTML DTD 문서가 문법을 정의하는 기호에 관한 설명입니다. 맞지 않는 것은?
1. A | B : A 또는 B로써 순서에 무관하게 사용할 수 있다.
2. A || B : A 또는 B로써 순서를 지켜야 한다.
3. A, B : A 그리고 B는 순서를 지켜야 한다.
4. A & B : A 그리고 B는 순서에 무관하다.
[2번 - || 기호는 DTD에 없습니다.]

문제 24 _ 다음은 HTML DTD가 문법을 정의하는 기호에 관한 설명입니다. 맞는 것을 모두 고르시오. 
1. A : A는 필수적이며 한 번만 사용할 수 있다.
2. A+ : A는 필수적이며 한 번 이상 사용해야 한다.
3. A? : A는 생략하거나 한 번만 사용할 수 있다.
4. A* : A는 생략하거나 한 번 이상 사용할 수 있다.
5. +(A) : 추가적으로 A를 사용할 수 있다.
6. -(A) : 예외적으로 A는 사용할 수 없다.
[1번, 2번, 3번, 4번, 5번, 6번 모두 맞는 설명 입니다.]

문제 25 _ 웹 접근성 준수를 의무화한 이 법률의 이름은 무엇입니까?
[장애인차별금지 및 권리구제 등에 관한 법률로써 줄여서 장차법이라고도 부릅니다. 이 법률은 웹 접근성 뿐만 아니라 사회 전반에 걸쳐 발생하는 장애인의차별에 관한 문제를 다루고 있습니다.]

문제 26 _ <title> 요소는 생략할 수 있다?
[X - 생략할 수 없습니다.]

문제 27 _ XHTML 문서에서 fieldset 요소를 사용하는 경우 legend 요소는 생략할 수 있다?
[O - 생략할 수 있습니다. 그러나 HTML 문서에서는 생략할 수 없습니다.]

문제 28 – HTML/XHTML Transitional 문서에서 address 요소는 자식 요소로 어떤 블럭 요소도 포함할 수 없다?
[X - 거의 모든 블럭 요소를 포함할 수 없습니다. 그러나 유일하게 P 요소를 포함할 수 있습니다. 한편 HTML/XHTML Strict 문서에서는 P 요소를 비롯하여 어떤 블럭 요소도 포함할 수 없습니다.]

문제 29 – inline 요소로 분류되면서도 block 요소와 inline 요소를 모두 포함할 수 있는 요소 이름을 아는대로 쓰시오.
[button, map, object, iframe, applet, ins, del]

문제 30 – iframe 요소는 HTML5(WD) 버전에서 폐기 되었다?
[X - 2010현 현재 초안에 의하면 폐기되지 않았습니다. 현재라는 단서를 붙인 것은 스펙이 아직 확정되지 않았기 때문입니다.]

문제 31 - CSS3(WD)의 border-radius 속성을 이용하여 좌측 상단의 모서리를 둥글게 처리하고자 한다. 이 때 표준 초안에서
제안하고 있는 속성의 표기법은?
1. border-radius-left-top
2. border-left-top-radius
3. border-radius-top-left
4. border-top-left-radius
[4번 - border의 수직(top, bottom) 방향을 먼저 작성하고 수평(left, right) 방향을 작성한 다음 radius를 작성 합니다.]

문제 32 – ‘I18N’은 무엇의 약어 입니까?
[internationalization(국제화) - 첫 글자인 'i'와 마지막 글자인 'n' 사이에 포함된 알파벳의 개수가 '18'개인데 이것을 'i18n' 으로 줄여서 표기하고 있습니다. W3C의 국제화 활동 참고. http://www.w3.org/International/]

고생하셨습니다. 몇 문제 맞히셨나요? 어떤 문제가 어렵게 느껴지셨나요? 새롭게 배운 지식이 있으셨나요? 너무 많이 틀렸다고 낙심하지는 마세요. 제가 주관적으로 판단하건데 20문제 이상 맞히셨다면 충분히 훌륭하다고 생각하구요. 16문제 이상 맞히신 분들도 양호한 편이라고 생각합니다. 문제는 16문제 미만인데요. 내년에도 이러시면 곤란해요. ^^