문서형(DTD)을 꼭 선언해야 하나요?

대부분의 웹 브라우저들은 문서형(DTD:Document Type Definition)이 선언되지 않은 웹 문서를 낡은 웹 문서로 간주하고 아주 오래된 웹 브라우저(IE4)의 렌더링을 흉내 냅니다. 이런 상태를 쿽스모드(Quirks Mode)라고 부르는데 웹 브라우저들마다 쿽스모드일 때 화면을 표시하는 방법이 달라서 문서형을 선언하지 않으면 브라우저 호환성을 확보하기 어렵습니다. 문서형을 선언하는 것은 다양한 환경에서 상호 운용성을 보장하기 위한 첫 걸음 입니다.

문서형(DTD)의 종류가 많던데 권장하는 것은 무엇입니까?

HTML의 버전에 따라서 크게 HTML과 XHTML로 나눌 수 있고 각 DTD별로 또 다시 호환형(transitional)와 엄격형(strict)으로 나뉩니다. 호환형은 더 이상 권장하지 않는 요소와 속성까지 지원하기 때문에 오래된 콘텐츠를 다룰 때 호환성이 좋고 사용자들의 오랜 습관(비록 나쁜 습관이라 할지라도)을 배려할 수 있기 때문에 보다 권장 합니다. 엄격형은 호환형보다 뛰어난 품질의 코드를 작성할 수 있지만 더 이상 낡은 요소와 속성을 지원하지 않기 때문에 오래된 콘텐츠와의 호환성이 떨어지고 새 창(새 탭) 띄우기와 같은 익숙한 기능을 제한하기 때문에 권장하지 않습니다.

새 창 띄우기 속성을 엄격형에서 지원하지 않는 이유는 브라우저 타겟의 선택권을 사용자에게 돌려주기 위함이나 최근에 이르러 대부분의 웹 브라우저들이 보다 나은 성능의 탭 브라우징을 지원(모바일 브라우저 포함)하고 문맥에 따라 웹 콘텐츠 제작자가 사용자 편의를 배려하는 측면에서 새 창 띄우기를 채택할 수 있기 때문에 새 창 띄우기를 제한하는 것이 항상 올바른 선택이라고 보기도 어렵습니다.

결국 HTML을 선택하든 XHTML을 선택하든 엄격한(strict) 문서형보다 호환형(transitional) 문서형을 권장합니다. DTD는 HTML 문서의 첫 번째 라인에 공백 없이 작성해야 합니다.

HTML 4.01

Strict: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Transitional (권장): <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Frameset: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0

Strict: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Transitional (권장): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Frameset: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML의 문법은 HTML과 비교해서 무엇이 다른가요?

엄격한 문법

HTML은 잘못된 중첩을 느슨하게 허용했으나 XHTML은 잘못된 중첩이 허용되지 않습니다. W3C 문법 검사기나 웹 개발자 도구의 지원을 받아 문법의 유효성을 확보하지 않으면 호환성(오류, 깨짐) 문제가 발생합니다.

<div><p>...</div></p> (X) <div><p>...</p></div> (O)

소문자 작성

HTML 태그는 대소문자를 구분하지 않고 혼용하여 사용했었지만 XHTML은 이 둘을 구분하며 모든 '요소'와 '속성'을 소문자로 작성해야 합니다.

<DIV CLASS="value"> (X) <div class="value"> (O)

태그의 종료

HTML은 <td>, <p>, <img> 와 같은 태그들을 종료하지 않아도 허용했지만 XHTML은 반드시 종료해야 합니다. 내용을 포함하지 않는 태그도 반드시 종료<img /> 합니다.

<img src="..." alt="..."> (X) <img src="..." alt="..." /> (O)

생략 금지

HTML은 속성의 값에 대한 단축 표기를 허용했지만 XHTML은 단축 표기를 허용하지 않습니다.

<input type="radio" checked> (X) <input type="radio" checked="checked" /> (O)

따옴표 사용

HTML은 속성의 값에 대한 따옴표 생략이 가능했지만 XHTML은 따옴표 생략을 허용하지 않습니다.

<p class=value> (X) <p class="value"> (O)

HTML과 XHTML 가운데 어떤 문서형(DTD)을 사용하는 것이 좋을까요?

HTML이든 XHTML이든 모두 괜찮지만 HTML보다 XHTML 문법이 더 엄격하고 확장 가능성이 높기 때문에 개발 편의 및 상위 호환성 측면에서 보다 권장 합니다. 어떤 이들은 이 선택을 선호의 문제라고 보는 반면 어떤 이들은 어느 한쪽이 더 우월한 기술이라고 이야기 합니다. 그러나 둘 중 어떤 형식을 선택하더라도 현재의 사용자에게 불리하게 작용하지는 않으므로 결국 개발자 조직 내부에서 선택의 문제로 귀결 됩니다.

문자셋(charset)으로 UTF-8을 권장하는 이유는 무엇인가요?

전세계 모든 문자를 컴퓨터에서 일관되고 풍부하게 표현할 수 있기 때문에 다국어 환경에 적합합니다. 뿐만 아니라 EUC-KR 보다 표현할 수 있는 한글 표현이 더 많아서 온라인 사전 콘텐츠는 반드시 UTF-8 문자셋을 사용합니다.

HTML 문서에서 UTF-8 문자셋을 사용하려면 <head>...</head> 안쪽에 다음과 같이 선언 합니다. 파일 저장시 선언한 문자셋과 동일한 인코딩 형식으로 저장해야 문자가 깨지지 않습니다.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

휴먼 랭귀지(human language)가 무엇인가요?

말 그대로 인간이 사용하는 언어를 말합니다. HTML 문서에 휴먼 랭귀지를 선언하면 HTML을 해석할 수 있는 소프트웨어들이 올바르게 동작하는 것을 돕습니다. 예를 들면 화면낭독 프로그램이나 점자 출력기 같은 보조 도구들이 이 선언을 이용할 수 있고 검색 엔진은 사용자의 주 사용 언어와 일치하는 검색결과를 제시할 수 있습니다. 주된 휴먼 랭귀지 속성은 <html> 요소에 한번 선언하고 콘텐츠 안에서 다양한 휴먼 랭귀지가 사용되는 경우 특정 요소마다 각각 다시 선언할 수 있습니다. 최소한 주된 휴먼 랭귀지는 반드시 선언하는 것이 좋고 각각의 콘텐츠 요소에 대한 휴먼 랭귀지는 가능하다면 선언하는 것이 좋습니다.

랭귀지 코드는 주 사용 언어에 따라 '한국어(ko), 영어(en), 일어(ja), 중국어(zh) ...' 형식으로 지정할 수 있고 선언하는 방법은 다음과 같습니다.

HTML: <html lang="ko"> <p lang="en">
XHTML: <html xmlns="http://www.w3.org/1999/xhtml" lang="ko" xml:lang="ko"> <p lang="en">

문서의 제목 <title>...</title>을 어떻게 작성하는것이 가장 좋을까요?

<title>...</title> 요소는 문서의 제목을 선언하는 요소로써 다음과 같은 세 가지 측면에서 중요합니다.

첫째, 검색엔진 최적화 관점에서 가장 적은 비용으로 가장 큰 효과를 거둘 수 있습니다. 검색엔진은 본문의 콘텐츠보다 문서의 제목에 가중치를 둡니다.
둘째, 웹 브라우저의 탭에 표시되기 때문에 다른 탭으로부터 현재의 문서를 빠르게 인지할 수 있도록 돕습니다. 즐겨찾기 아이콘(Favicon)과 함께 사용하면 더욱 효과적입니다.
셋째, 화면 낭독 프로그램 사용자는 웹 문서가 열리는 순간 문서 제목을 음성으로 전달받기 때문에 시각 장애인의 탐색을 돕습니다.

가장 좋은 제목은 현재 문서의 핵심 키워드를 사용한 짧은 제목 입니다. 하나의 웹 사이트에서 동일한 키워드가 반복해서 제목으로 등장하는 것은 검색엔진의 정확도를 떨어뜨리고 시각 장애인의 접근성에도 좋지 않은 영향을 미칩니다. 현재 문서에 이르는 문서의 계층 구조를 제목으로써 모두 나열하는 것도 동일한 제목을 반복해서 사용하기 때문에 권장할만한 방법은 아닙니다.

아무 의미 없는 부적절한 제목: <title>○○○에 오신것을 환영합니다</title> (X)
문서의 계층 구조를 표현해서 과도하게 반복하는 제목: <title>○○○ > ○○○ 안내 > ○○○ 역사</title> (X)
가장 적합한 제목: <title>○○○ 역사</title> (O)

의미론적 마크업(semantic markup)이란 무엇입니까?

의미론적 마크업이란 웹 콘텐츠 요소에 가장 적합한 의미의 HTML 코드를 부여해서 데이터가 정보로써의 가치를 갖게된 형태를 말합니다. 의미론적 마크업은 기계적으로도 해석이 가능하기 때문에 사람의 인지 작용을 돕습니다. 제목을 제목 요소 <hx>...</hx> 으로 마크업 하면 제목 정렬 기능을 갖춘 소프트웨어는 보다 빠르게 원하는 콘텐츠로 이동하는 것을 돕습니다. 이런 기능은 현존하는 화면낭독 프로그램이 대부분 지원하고 있기 때문에 웹 접근성을 높여주고 검색엔진 최적화 관점에서 <title>...</title> 다음으로 중요 합니다. 웹 콘텐츠의 구조와 순서를 바로잡기 위한 논리적 마크업(logical markup)과 맥을 같이 합니다.

제목 요소 <hx>...</hx>는 어떻게 작성하는 것이 가장 좋을까요?

<hx>...</hx> 제목 요소는 '섹션, 블럭' 콘텐츠에 대한 제목을 마크업 하는 요소로써 문서의 계층 구조를 여섯 단계로 표현 합니다. 작은 숫자일수록 큰 제목으로써 웹 브라우저들은 흔히 좀 더 크고 굵은 글꼴로 표시하시만 CSS를 이용해서 초기화 하거나 원하는 스타일로 변경할 수 있습니다. 제목의 단계는 건너뛰지 않는 것이 좋고 단지 굵은 글꼴을 표현하기 위해 사용하는 경우 논리적인 마크업을 해치게 됩니다. <h1>...</h1> 요소는 한 문서에 반드시 한 번 이상 선언이 되어야 하고 한 문서에서 여러번 선언할 수 있는데 사이트 제목과 본문 제목에 동시에 선언함으로써 검색엔진으로부터 더 높은 점수를 받을 수 있습니다. <h2> ~ <h6> 요소 또한 문서의 계층 구조에 따라 여러번 선언할 수 있습니다.

<h1>...</h1> 요소는 콘텐츠의 최상위 계층에 대한 제목을 선언한다는 점에서 <title>...</title> 요소와 같은 역할을 하지만 <title>...</title> 요소는 웹 문서 자체에 대한 메타 데이터 성격을 갖고 오직 한 번만 선언할 수 있다는 점이 <h1>...</h1> 요소와 다릅니다. <title>..</title>은 문서의 제목을 마크업 하면서 스스로는 콘텐츠가 될 수 없지만, <hx>...</hx>는 콘텐츠의 제목을 마크업 하면서 스스로 콘텐츠가 된다는 차이가 있습니다. 그리고 <title>...</title> 요소와 <h1>...</h1> 요소의 내용은 같을 수 있지만 다를 수도 있습니다.

<title>사람에 관한 연구</title> <h1>인체의 신비</h1> _<h2>뇌의 구조</h2> __<h3>전두엽의 주요 기능</h3> ___<h4>타인의 아픔에 공감하는 기능</h4> _<h2>눈의 구조</h2> __<h3>망막의 역할</h3>

웹 사이트의 로고(조직의 이름, 브랜드 이름)를 <h1>...</h1>으로 작성해야 한다고 주장하는 사람도 있고 콘텐츠 본문의 제목을 <h1>...</h1>으로 작성해야 한다고 주장하는 사람들이 있는데 두 가지 방법 모두 통용되는 방법이며 사이트 제목과 본문 제목을 모두 <h1>...</h1>으로 마크업 하는 것도 가능 합니다.

의미론적 마크업을 잘 하는 방법이 있을까요?

네, 있습니다. '제목(keyword)'과 '내용(content)'의 의미를 판독해서 구분하는 것이 가장 중요 하고 '내용'으로부터 '제목'을 분리해 냈다면 가장 적절한 의미의 '제목 요소 마크업'을 사용 합니다. 제목 요소 마크업은 다음과 같이 구분할 수 있습니다.

문서 제목: <title>...</title>
섹션 제목: <hx>...</hx>
정의 제목: <dt>...</dt>
표의 제목: <caption>...</caption> 표제 _<th>...</th> 제목 셀
폼의 제목: <legend>...</legend> fieldset 제목 _<label>...</label> form control에 대한 레이블

<th>...</th> 요소와 <label>...</label> 요소는 제목 요소로 분류하기에 애매하고 논란의 여지가 있지만 짝이 맞는 내용 요소를 갖는다는 점에서 제목 요소로 포함시켰습니다.

논리적인 순서란 어떤 것입니까?

논리적인 순서는 사용자에게 내용이 전달되는 형태에 따라 크게 세 가지로 구분할 수 있고 각각의 순서는 '선형화 순서'를 중심으로 되도록 일치시키는 것이 좋습니다.

논리적인 화면 배치 순서: 모니터와 같은 비주얼 장치에서 보이는 흐름이나 순서를 말합니다. 왼쪽에서 오른쪽으로 글을 쓰고 읽는 문화권에서는 중요한 제목이나 내용을 화면의 좌측 상단으로부터 배치하고 덜 중요한 내용은 우측 하단으로 순차적으로 배치 합니다. 이 순서를 지키지 않으면 읽고 이해하는데 어려움을 격지만 시각이 있는 사람들은 불필요한 내용을 빠르게 건너 뛸 수 있기 때문에 치명적이지는 않습니다. 화면 배치를 위해 HTML 구조(예:table)에 지나치게 의존하면 의미론적 마크업을 포기해야 하는 경우가 발생하기 때문에 CSS를 이용해야 합니다. <table>...</table> 요소를 의미와 무관하게 화면 배치를 위해 사용하는 경우 논리적인 순서를 해칠 가능성이 높습니다.
논리적인 선형화 순서(가장 중요): 시각적인 흐름과 무관하게 작성된 HTML 마크업 순서로써 '웹 브라우저, 화면 낭독기'와 같은 도구들은 이 순서에 따라 문서를 해석 합니다. 가장 많이 발생하는 실수는 여러 단계의 노드를 갖는 내용을 작성할 때 '부모A>자식a-부모B>자식b' 순서로 마크업 하지 않고 '부모A-부모B-자식a-자식b' 순서로 마크업 하는 것입니다. 이렇게 노드 관계를 무시하는 마크업은 화면 낭독기 사용자에게 치명적 입니다. HTML 마크업의 논리적인 순서는 키보드의 접근 순서에도 직접 영향을 미치기 때문에 중요 합니다.
논리적인 키보드 접근 순서: 키보드 접근 순서는 기본적으로 HTML 마크업 순서에 따릅니다. 웹에 매우 익숙하거나 또는 마우스를 사용할 수 없는 장애인들이 키보드를 사용합니다. 화면에 보이지 않는다고 해서 HTML의 논리적인 순서를 충분히 고려하지 않으면 키보드의 접근 순서가 엉망이 되기 때문에 키보드의 논리적인 접근 순서를 바로잡는 문제는 전적으로 HTML의 논리적인 순서에 종속 됩니다. 잘못된 HTML의 논리적인 순서를 바로잡지 않고 tabindex 라는 속성을 이용해서 키보드 접근 순서만 바르게 교정하는 경우 마크업 순서와 키보드 접근 순서가 일치하지 않기 때문에 바람직하지 않습니다. CSS를 제거하는 기능이 포함된 브라우저에서 키보드로 접근하기에 혼란스럽게 됩니다.

논리적 마크업을 위해서 화면 배치를 위한 <table>...</table>을 사용하지 않기로 했습니다. 이제 무엇으로 마크업 하나요?

우선 데이터의 의미에 가장 적합한 HTML 요소를 찾아 마크업 합니다. 그 이상 의미 단위로 더 묶거나 더 나눌 필요가 있을 때 또는 화면 배치를 위해 더 필요할 때에는 콘테이너 개념의 <div>...</div> 요소 또는 <span>...</span> 요소를 사용합니다.

다른 HTML 요소들이 스스로 어떤 의미를 갖는데 반해 <div>...</div> 요소와 <span>...</span> 요소는 스스로는 의미를 갖지 않고 내용을 나누거나 묶는 역할을 하는 콘테이너 입니다. <div>...</div> 요소가 블럭 요소를 위한 마크업이라면 <span>...</span> 요소는 블럭보다 작은 단위의 인라인 요소를 위한 마크업 입니다. 한 가지 유의할 점은 스스로는 의미를 갖지 않는 마크업이기 때문에 사용을 남발해서는 안된다는 점 입니다. 만약 제목과 내용을 구분하거나 목록의 아이템을 구분하기 위하여 <div>...</div> 또는 <span>...</span> 요소만을 사용했다면 이것은 논리적인 마크업이 아닙니다. <div>...</div>와 <span>...</span> 요소는 내용을 마크업 할 때 가장 나중에 떠올려야할 마크업 입니다.

의미 없는 비 논리 마크업 (X): <div>제목</div> <div> _<div>목록 하나</div> _<div>목록 둘</div> </div>
의미를 살린 논리 마크업 (O): <h2>제목</h2> <ol> _<li>목록 하나</li> _<li>목록 둘</li> </ol>

논리적인 마크업 예제를 한번 볼 수 있을까요?

논리적인 마크업에 유일한 정답은 있을 수 없고 코드를 작성하는 사람에 따라서 다양한 구조가 등장할 수 있습니다. 누가 보더라도 이해할 수 있고 설명 가능한 방법으로 마크업 하면 됩니다. 가장 보편적이고 일반적인 웹 사이트 구조를 고려하여 마크업을 작성한다면 다음과 같은 구조가 하나의 적절한 예가 될 수 있습니다.

논리적인 구조의 HTML 마크업 예: <div id="container"> _<div id="header"> __<h1 class="h1">웹 사이트 제목</h1> __<div id="globalNavigationBar">전역 네비게이션</div> _</div> _<div id="body"> __<div id="content"> ___<h2 class="h2">콘텐츠 제목</h2> ___<div class="section">콘텐츠 본문</div> __</div> __<div id="localNavigationBar">지역 네비게이션</div> _</div> _<div id="footer"> __<address>저작자 정보(contact information)</address> _</div> </div>
논리적인 구조로 작성된 하나의 HTML 마크업으로 구현한 다양한 화면 배치 예: #container
#header
.h1
#globalNavigationBar
#body
#content
.h2
.section
#localNavigationBar

#footer; #container
#header
.h1
#globalNavigationBar
#body
#content
.h2
.section
#localNavigationBar

#footer; #container
#header
.h1
#globalNavigationBar
#body
#content
.h2
.section
#localNavigationBar

#footer; #container
#header
.h1
#globalNavigationBar
#body
#content
.h2
.section
#localNavigationBar

#footer

컬럼 구조 레이아웃을 위한 CSS 기법이 궁금합니다.

컬럼 구조 레이아웃이란 콘텐츠를 화면의 좌우로 나누는 배치 기법을 말하는데 대부분의 웹 사이트가 이런 구조를 사용하고 있습니다. 간단하게 준비된 HTML 구조와 CSS 코드를 보면서 이해해 주세요.

기대하는 출력 결과: .container 저는 자식 요소(컬럼 블럭)들이 밖으로 나가지 못하도록 담아두는 블럭 입니다.
.content 저는 왼쪽으로 흐르는 블럭 입니다.
.navigation 저는 오른쪽으로 흐르는 블럭 입니다.
HTML 마크업: <div class="container"> _<div class="content">...</div> _<div class="navigation">...</div> </div>

배치해야 하는 화면의 구조를 이해했고 HTML 마크업을 끝냈습니다. 다음은 CSS 코드를 작성하면서 문제 상황을 발견하고 그것을 해결해야 하는데요. 처음부터 정답을 알려 드리지 않겠습니다. 제가 초보였을 때에는 정말로 이렇게 코드를 작성 했었습니다.

미완성 CSS 코드: .container { background:#ddd; } .content { width:70%; float:left; background:#f00; } .navigation { width:20%; float:right; background:#00f; }
미완성 CSS 코드에 대한 화면 출력 결과: .container 부모 요소가 자식의 높이를 상자의 크기에 전혀 반영하지 못하는 상황 입니다.
.content 저는 왼쪽으로 흐르는 블럭 입니다.
.navigation 저는 오른쪽으로 흐르는 블럭 입니다.

만약 배경색을 넣지 않았다면 무엇이 문제인지 알아차리지 못했을껍니다. 부모 요소가 자식의 높이를 상자의 크기에 전혀 반영하지 못하고 있는 상황 입니다. 때문에 자식 요소들은 부모 밖에서 따로 존재하는 것처럼 보입니다. 이것은 브라우저 버그가 아니라 정상적으로 표준에 따라 잘 렌더링 된 것입니다. 부모 상자는 왜 자식만큼 커지지 않았을까요? 그것은 float 속성 때문입니다. float 요소가 적용된 상자는 마치 둥둥 떠 다니는 레이어 처럼 float 되지 않은 다른 블럭 요소와 다른 층에 떠 있게 되어서 자식의 높이가 부모에게 전달되지 않은 것입니다. 자식의 높이를 부모에게 전달하기 위한 여러가지 방법들이 있습니다.

부모 요소에 float 속성을 부여

.container { float:left }

float된 요소들끼리는 서로 어울리기 때문에 부모 요소에도 flaot 속성을 부여 합니다. 하지만 이 방법은 결국 현재 문서의 모든 블럭에 불필요한 float 속성을 부여하도록 만듧니다. 왜냐하면 모든 블럭들이 같은 층에 떠 있어야만 서로의 영역을 침범하지 않기 때문입니다. 만약 하나의 블럭이라도 float 되지 않았다면 이 상자는 float된 다른 상자와 겹칠 것이므로 이런 방법은 절대로 권장할 수 없습니다.

부모 요소에 overflow 속성을 부여

.container { overflow:hidden }

overflow 속성을 변경 합니다. 모든 요소는 overflow 속성의 기본 값을 지니고 있는데 기본 값은 visible 입니다. 이 값을 visible이 아닌 다른 값으로 변경해 주면 됩니다. 다른 값으로는 auto, scroll, hidden 이 있습니다. 이 방법은 자식 블럭이 부모 블럭을 넘칠 때 스크롤이 발생하거나 숨김 현상이 발생하기 때문에 언제나 가장 안전한 방법은 아닙니다. 자식 요소 가운데 부모 상자의 바깥쪽으로 펼쳐지는 레이어 .layer { position:absolute } 를 넣어야 한다면 절대로 이 방법을 사용할 수 없을 것입니다. 향후 이런 레이어를 띄우는 상황이 절대로 발생하지 않으리라고 누구도 장담할 수는 없기 때문에 이 방법 역시 권장하는 방법은 아닙니다.

빈 요소에 clear 속성을 부여

.clear { clear:both }

clear 속성은 float된 요소의 흐름을 끊고 자기 자신은 float된 요소로부터 줄 바꿈 처리하는 속성 입니다. float된 요소의 아래쪽에 내용 없는 블럭 <div class="clear"></div>을 하나 추가한 다음 clear 속성을 추가하면 비로소 float된 자식 요소들의 높이가 부모에게 반영이 되는데 clear 속성의 값으로는 left, right,both가 있습니다. 이 방법은 아무 의미 없는 빈 요소를 추가해야 하기 때문에 역시 권장하는 방법은 아닙니다.

가상 선택자 :after 를 사용하는 방법

.container:after { content:""; clear:both; display:block; }

가상 선택자란 실제로는 존재하지 않는 요소나 특수한 상황에서만 발생하는 동적인 요소를 CSS 명령으로 제어하는 기법 입니다. 가상 선택자는 다시 '가상 클래스 선택자'와 '가상 요소 선택자'로 구분할 수 있는데요. 가상 클래스 선택자(:link, :visited, :hover, :active, :focus, :first-child)는 특정 요소에 마치 동적으로class를 부여한 것과 같은 이치로 이용할 수 있습니다. 가상 요소 선택자(:first-line, :first-letter, :before, :after)는 실제로 존재하지 않는 요소를 마치 존재하는 것처럼 이용하는 기법 입니다. :after 라는 가상 요소 선택자는 content 라는 속성을 이용해서 .container 블럭이 끝나기 직전 content 속성의 값 "*" 을 화면에 출력할 수 있습니다. 이렇게 생성된 요소에 clear:both 속성을 부여하면 자식의 높이를 부모에게 전달할 수 있는데 실제로 HTML 코드에는 빈 요소가 존재하지 않기 때문에 가장 이상적인 방법이라고 할 수 있습니다. 그러나 IE 6~7 브라우저는 가상 요소 선택자를 지원하지 않습니다.

IE 전용 확장 zoom 속성을 이용하여 IE 6~7 문제 해결

.container { *zoom:1; }

IE 6~7 브라우저는 가상 요소 선택자 :after를 지원하지 않습니다. 그러나 CSS hack을 이용하여 자식의 높이를 부모에게 전달 할 수 있습니다. zoom:1 속성은 IE 전용 확장 속성으로써 본래의 존재 목적은 IE 브라우저에서 웹 문서를 자유롭게 'zoom in / zoom out' 하는 것 입니다. 이 속성을 부여하게 되면 요소는 IE 브라우저에서만 존재하는 hasLayout 이라는 개념의 속성을 갖게 되는데 이 속성이 IE 브라우저에서 float 문제를 해결하는 trigger로 작용을 하고 다른 브라우저에는 영향을 미치지 않습니다. zoom 속성 앞에 '*'을 붙이는 이유는 현재는 존재하지 않지만 향후 zoom과 동일한 이름을 지닌 속성이 표준으로 등장하거나 다른 웹 브라우저에서 CSS 확장 속성으로 등장하더라도 이 코드를 무시하도록 만드는 'hack'을 사용한 것입니다. 속성 앞에 공백 없이 '*'을 붙이면 해당 속성은 IE 6~7 브라우저에서만 작용하게 됩니다.

다양한 시행 착오를 통해서 얻은 컬럼 구조 만들기 CSS 결과 코드

다양한 시행 착오와 IE 6~7 브라우저의 버그를 격었지만 우리는 다음과 같은 방법으로 컬럼 구조 레이아웃을 위한 CSS 코드를 얻었습니다.

.container { background:#ddd; *zoom:1; } .container:after { content:""; clear:both; display:block; } .content { width:70%; float:left; background:#f00; } .navigation { width:20%; float:right; background:#00f; }

'id/class' 선택자 사용 기준은 무엇이고 어떻게 네이밍 하는것이 좋을까요?

id

CSS 선택자로 사용할 수 있다.
DOM이 객체를 식별하는 역할을 할 수 있다.
한 문서에 한 번만 사용할 수 있다.
링크에 대한 앵커(목표 지점)로 사용할 수 있다.

class

CSS 선택자로 사용할 수 있다.
DOM이 객체를 식별하는 역할을 할 수 있다.
한 문서에 여러번 사용할 수 있다.

'id/class' 권장 기준

한 문서에서 반드시 한 번만 사용 확신 + 앵커로써 가치가 있다면 = id를 사용 합니다.
한 문서에서 두 번 이상 사용 가능성 + 앵커로써 가치 없다면 = class를 사용 합니다.
한 문서에서 두 번 이상 사용 가능성 + 앵커로써 가치가 있다면 = id/class를 함께 사용 합니다.

'id/class' 네이밍 규칙

특수 문자를 제외한 '모든 자연어와 숫자'의 사용이 가능 합니다.
특수 문자 가운데 '_' 언더바와 '-' 하이픈은 사용할 수 있습니다.
첫 글자로 숫자가 올 수 없습니다. 특수 문자 '_', '-'가 첫 글자로 올 수 있지만 이 때에는 숫자가 뒤따를 수 없습니다.
영문 대/소문자를 다르게 취급 합니다. (단, DTD가 표준이 아닐때 대부분의 웹 브라우저들이 대소문자를 동일하게 취급)

'id/class' 네이밍 요령

카멜 케이스 : 영문 소문자를 사용하되 두 번째 단어부터 첫 번째 문자를 대문자로 처리하는 기법. ex) camelCase
파스칼 케이스 : 영문 소문자를 사용하되 모든 단어의 첫 번째 문자를 대문자로 처리하는 기법. ex) PacalCase
언더바 사용 : 단어와 단어를 '_' 언더바로 연결하는 기법 ex) under_score
하이픈 사용 : 단어와 단어를 '-' 하이픈으로 연결하는 기법 ex) hyphen-nate
CSS 선택자와 DOM에 필요한 선택자를 분리하기 위하여 CSS 선택자용으로 카멜 케이스를 사용하고, DOM 객체 식별용으로 파스칼 케이스를 사용하는 방법도 있습니다.

이미지 대체 텍스트 속성 alt="" 어떻게 작성하는 것이 가장 좋은가요? title="" 속성과는 어떻게 다르죠?

<img alt="*" />

이미지 대체 텍스트 alt="*" 속성은 <img />, <area /> 요소의 필수 속성 이고 <input type="image" /> 요소에서 선택적으로 사용할 수 있으나 이미지가 로드되지 않거나 화면 낭독기 사용자를 위해서 반드시 작성하는 것이 좋습니다. alt 속성이 title 속성과 다른 점은 alt 속성은 이미지를 대체(alternative text)하는 목적을 지니고 있고title 속성은 참고 제목(advisory title)의 목적을 지니고 있으므로 확연히 구분하여 사용해야 합니다. 실례로 이미지가 로드되지 않는 상황에서 alt 텍스트는 이미지 대신 화면에 표시 되지만 title 텍스트는 표시되지 않습니다. 이미지 대체 텍스트를 작성하는 요령은 다음과 같습니다.

아무 의미 없는 장식용 이미지는 배경으로 처리 합니다.
아무 의미 없는 장식용 이미지를 전경으로 처리하는 경우 alt 속성을 사용하되 값을 비워 둡니다. ex) <img alt="" />
대체 텍스트는 이미지에 표시된 텍스트와 완전히 동일하게 처리 합니다.
이미지가 텍스트를 표현한 것이 아니라 추상적인 모양의 아이콘이나 장면이라면 시각 장애인이 이해할 수 있도록 묘사 합니다.
대체 텍스트의 '한글/영문' 표기를 동일하게 처리 합니다. 고유 명사는 다른 언어로 변환해서 표기하는 것을 금기하는 경우도 있습니다.
대체 텍스트의 '대/소문자' 표기를 동일하게 처리 합니다. '대/소문자'를 다르게 처리하면 의미가 달라지는 경우도 있습니다.
링크 걸린 이미지의 대체 텍스트로써 "~로고, ~링크, ~바로가기, ~이동합니다" 와 같은 부가 설명은 화면 낭독기 사용자에게 오히려 방해가 됩니다.
title 속성을 alt 속성 대신 사용해서는 안됩니다.
title 속성의 값으로 alt 속성과 동일한 값을 사용하는 것을 권장하지 않습니다. 두 속성의 용도가 '대체(alternative)'와 '참고(advisory)'로써 명확히 다르기 때문 입니다.

이미지에 포함된 텍스트의 양이 너무 많습니다. 어떻게 처리하죠?

대체 텍스트의 문자 수는 사실상 제한이 없습니다. 그러나 설명이 너무 길어지는 경우(약 250글자 이상) longdesc 속성을 이용하여 보완하면 됩니다. 단, longdesc 속성이 alt 속성을 대체하면 안됩니다. longdesc 속성은 alt 속성을 보완하는 목적으로 사용해야 합니다. 이미지가 로드되지 않는 상황에서 alt 속성은 대체 텍스트로써 표시가 되지만 longdesc 속성의 값은 표시되지 않기 때문입니다. longdesc 속성의 값은 웹 문서(*.html) 또는 텍스트 파일(*.txt) 모두 가능하지만 보다 의미 있고 형식을 갖춘 문서로 작성하려면 HTML 마크업을 지원하는 웹 문서(*.html) 포멧을 사용하는 것이 좋습니다.

<img alt="○○○ 조직도. ○○○ 산하 ○○개의 조직이 있다." longdesc="organization.html" />

organization.html 문서를 다음과 같이 마크업 할 수 있습니다.

<h1>정부 조직도</h1>

<h2>대통령 산하</h2>

대통령
- 대통령실
- 감사원
- 국가정보원
- 방송통신위원회
- 국가안전보장회의
- 민주평화통일자문회의
- 국민경제자문회의
- 국가교육과학기술자문회의

<h2>국무총리 산하</h2>

국무총리
- 국무총리실
- 특임장관
- 법제처
- 국가보훈처
- 공정거래위원회
- 금융위원회
- 국민 권익위원회

<h2>정부 부처</h2>

기획재정부
- 국세청
- 관세청
- 조달청
- 통계청
교육과학기술부
외교통상부
통일부
법무부
- 검찰청
국방부
- 병무청
- 방위산업청
행정안전부
- 경찰청
- 소방방재청
문화체육관광부
- 문화재청
농림수산식품부
- 농촌진흥청
- 산림청
지식경제부
- 중소기업청
- 특허청
보건복지가족부
- 식품의약품안전청
환경부
- 기상청
노동부
노동부
여성부
국토해양부
- 해양경찰청
- 행정중심복합도시건설청

모두가 이용할 수 있는 longdesc 텍스트를 제공하고 싶습니다.

이미지에 사용된 텍스트 버전의 설명은 시각 장애인의 탐색에 도움이 되지만 텍스트를 인용하기를 원하는 사용자에게 아무런 도움이 되지 않습니다. longdesc 속성에서 지정한 URL이 웹 브라우저에 출력되지 않기 때문입니다. 이런 경우 텍스트를 복사하거나 인용하기를 원하는 사용자를 위하여 다음과 같이 D-Link(Description-Link)를 제공할 수 있습니다.

<img alt="○○○ 조직도. ○○○ 산하 ○○개의 조직이 있다." longdesc="organization.html" /> <a href="organization.html" title="○○○ 조직도에 대한 상세한 설명">[D]</a>

웹 브라우저 호환성을 유지하기 위한 CSS 기법은 무엇이 있나요?

IE 6~7 브라우저는 완벽하게 표준에 따라 구현되어 있지 않고 버그가 많다는 사실을 알아야 합니다. 그리고 이 브라우저들의 디버깅 기법을 익혀야 합니다. IE8, Firefox, Safari, Chrome, Opera 브라우저는 표준 계열 브라우저로써 대부분의 HTML/CSS 코드를 표준에 따라 동일하게 렌더링 하기 때문에 표준 명세에 따라 코드를 작성하면 되고 별도의 디버깅 기법은 필요가 없습니다. 그러나 IE 6~7 브라우저는 표준 계열 브라우저들과 적지 않은 차이를 갖고 있습니다. IE 6~7 브라우저 디버깅 기법에는 다음과 같은 두 가지 방법이 있습니다.

첫째, 별도의 CSS 파일을 작성하고 IE 조건부 주석 처리

조건부 주석(Conditional Comment)이란 IE 계열 브라우저에서 IE 브라우저의 버전 타겟팅을 위해 사용하는 주석 입니다. IE 계열 브라우저들은 겨냥한 버전에 따라 주석 안쪽에 있는 내용을 해석하지만 표준 계열 브라우저들은 이 주석을 모두 주석으로 받아들여 해석하지 않습니다. IE 6~7 브라우저에 각각 대응하는 두 개의 파일을 만들고 표준 CSS 코드를 덮어쓸 수 있도록 표준 코드 아래줄에 선언 합니다.

<link rel="stylesheet" type="text/css" href="default.css" />  

'if IE 7'은 IE 브라우저에서 '만약 IE 7 브라우저라면 이 주석을 해석할 것' 이라는 의미로 받아 들입니다. 결국 IE 7 브라우저는 ie7Debug.css 파일을 해석할 것이고 표준계열 브라우저는 무시할 것입니다. 이 방법의 장점은 문법적으로 유효한 CSS 코드를 얻을 수 있다는 점인데 별도의 CSS 파일을 관리해야 하기 때문에 개발 편의를 떨어 뜨리고 전송 요청 횟수를 증가시켜 웹 문서 속도에 좋지 않은 영향을 미칩니다.

둘째, 별도의 파일 작성 없이 CSS hack 을 이용

CSS 코드의 문법적 유효성을 포기하는 대신 개발 편의와 성능 향상을 위해 CSS hack을 사용하는 방법 입니다. CSS 코드의 문법적 유효성을 유지하려는 목적은 브라우저 호환성을 획득하기 위함인데 CSS 코드는 문법적으로 유효하지 않더라도 브라우저 호환성 획득이 가능하기 때문에 코드의 무결성을 고집스럽게 주장할 필요가 없습니다. 현재 CSS의 활성 표준은 2.0 인데 반해 실제로 현존하는 대부분의 브라우저들은 이미 아직 표준으로 확정되지 않은 CSS 2.1 문법을 모두 지원하고 CSS 3.0 문법을 일부 지원하고 있으므로 CSS 코드에서 표준 코드에 대한 무결성은 이미 의미가 없습니다. CSS hack이 필요한 브라우저는 오직 IE 6~7 뿐인데 다음과 같은 형식으로 디버깅 할 수 있습니다. 같은 속성을 두 번 선언하여 앞에 선언된 표준 속성을 덮어쓰기 하는 원리 입니다.

.selector { property:value; *property:value; } /* IE 7 이하의 브라우저에 작용 합니다 */ .selector { property:value; _property:value; } /* IE 6 이하의 브라우저에 작용 합니다 */

IR(Image Replacement) 기법이란 무엇입니까?

의미가 포함되어 있는 이미지를 배경으로 처리하고 대신 전경에 상응하는 텍스트를 넣는 방법으로써 시각이 있는 사용자는 이미지로 처리된 화면을 볼 수 있지만 '화면 낭독기를 사용하는 시각 장애인, CSS 제거, 인쇄' 시에는 텍스트 데이터에 접근하거나 텍스트를 볼 수 있는 형태로 설계하는 기법을 말합니다. 이 기법의 장점은 접근성을 떨어뜨리지 않으면서도 검색엔진으로부터 높은 가중치를 받을 수 있다는 점 입니다. 한편 모바일 브라우징 장치에서 전송 요금 등을 고려하여 일부러 이미지를 끈 상태로 웹 사이트를 이용하는 사용자에게는 이미지와 텍스트가 모두 출력되지 않기 때문에 치명적일 수 있습니다. 따라서 의미가 포함된 이미지는 전경으로 처리한다는 원칙을 먼저 세우고 여러 조각의 이미지가 전송 성능에 영향을 미치지 않도록 고려해야 하는 경우에만 Sprite(조각난 이미지들을 하나의 이미지로 배경 처리해서 전송 성능을 높이는) 기법과 함께 사용하는 것이 좋습니다.

HTML

<a href="#"><span>NAVER</span></a>

CSS

a { position:relative; display:inline-block; width:193px; height:47px; overflow:hidden; background:url(naver.gif) no-repeat; text-decoration:none; } a span { position:absolute; z-index:-1; visibility:hidden; }

화면 출력 결과

Image Sprite 기법이란 무엇입니까?

조각난 이미지 파일들을 하나의 파일로 병합 후 배경으로 처리해서 웹 문서 전송 속도를 높이는 기법 입니다. 이 때 의미가 있는 이미지는 전경에 상응하는 텍스트를 포함시켜서 접근성을 확보해야 하기 때문에 IR(Image Replacement) 기법이 함께 사용 됩니다.

HTML

<ul id="naverMenu">
_<li class="mail"><a href="#"><span>메일</span></a></li>
_<li class="cafe"><a href="#"><span>카페</span></a></li>
_<li class="blog"><a href="#"><span>블로그</span></a></li>
_<li class="kin"><a href="#"><span>지식iN</span></a></li>
_<li class="shopping"><a href="#"><span>쇼핑</span></a></li> 
</ul>

Sprite Image

CSS

#naverMenu { position:relative; list-style:none; margin:0; padding:0; width:197px; padding:0 0 0 15px; background:url(http://naradesign.net/open_content/lecture/wp/img/naverMenu.gif) no-repeat; *zoom:1; }
#naverMenu:after { content:""; display:block; clear:both; } 
#naverMenu li { position:relative; float:left; } 
#naverMenu li a { position:relative; display:block; height:38px; text-decoration:none; } 
#naverMenu li.mail a { width:33px; } 
#naverMenu li.cafe a { width:32px; }
#naverMenu li.blog a { width:43px; }
#naverMenu li.kin a { width:42px; }
#naverMenu li.shopping a { width:32px; } 
#naverMenu li a span { position:absolute; z-index:-1; visibility:hidden; }

화면 출력 결과

동영상 대체 콘텐츠는 무엇이고 어떻게 처리해야 합니까?

동영상 대체 콘텐츠란 '청각'이나 '시각'이 없는 사용자도 동영상을 이해할 수 있도록 여러가지 감각기관(시각, 청각, 촉각)을 두루 고려한 대체 수단을 말합니다. 동영상에 대체 콘텐츠를 제공하면 다음과 같은 사람들도 동영상을 이해할 수 있습니다.

청각 장애인
음성 출력 장치가 없는 사람
시끄러운 장소에 있는 사람
음성 출력 장치가 있더라도 주변에 방해가 되기 때문에 사용할 수 없는 사람
시각 장애인
시력이 있더라도 스크린을 일시적으로 볼 수 없는 사람

동영상 대체 콘텐츠의 종류는 다음과 같습니다.

닫힌 자막(Closed Caption)

텍스트 기반으로 작성된 자막으로써 사용자가 원할 때 닫을 수 있는 자막 입니다. 가장 이상적인 자막 제공 방법 입니다. 청각 장애인은 이 자막의 혜택을 받습니다.

텍스트로 처리된 동영상의 닫힌 자막 예(자막을 켜거나 끌 수 있다)

열린 자막(Open Caption)

그래픽 기반으로 작성된 자막으로써 사용자가 원치 않는 경우에도 화면에 표시되는 자막 입니다. 텍스트로 처리되지 않았기 때문에 기계적으로 인식 불가능 하지만 자막으로 인정되는 방법 입니다. 청각 장애인은 이 자막의 혜택을 받습니다.

그래픽으로 처리된 동영상의 열린 자막 예(자막을 켜거나 끌 수 없다)

음성 해설(Audio Description)

동영상에 음성이 포함되지 않았거나 일시적으로 영상만을 제공하는 경우(예:한국의 사계절을 음성 없이 영상만 제공) 시각 장애인은 상황을 이해할 수 없기 때문에 이 때 음성 해설이 필요 합니다. 모든 상황에서 필수적이지는 않지만 시각 장애인 또는 일시적으로 시감각을 이용할 수 없는 사용자를 위해 제공하는 것이 좋습니다.

음성이 포함되지 않은 영상 예 - 풍경이 흐르는 장면

텍스트 대본(Transcript)

'영상'과 '음성'을 모두 제공받을 수 없는 상황에서도 내용을 이해할 수 있도록 '자막'이나 '음성 해설'을 텍스트 버전으로 제공한 것을 말합니다. 이렇게 텍스트 버전으로 제공된 콘텐츠는 '화면 낭독기, 점자 출력기'와 같은 도구가 모두 인식 가능하기 때문에 '시각 장애인, 청각 장애인' 그리고 동영상의 '대본'을 인용하기를 원하는 사람들에까지 두루 유익한 방법 입니다.

텍스트 대본 제공 예

프레임셋 <frameset>...</frameset>의 문제는 무엇인가요?

프레임셋은 사용성을 떨어뜨리고 보안 측면에서 치명적일 수 있습니다. 프레임셋을 이용해서 웹 사이트를 구현하는 경우 자식 문서가 갱신 되더라도 항상 프레임셋 문서의 동일한 제목을 탭에 표시하게 됩니다. 또한 모든 문서의 URL이 브라우저 주소창에 노출되지 않기 때문에 해당 문서에 대한 링크를 걸거나 북마크를 할 수 없게 됩니다. 이 주소를 감추는 것이 보안에 도움이 된다는 지침이나 설명은 모두 잘못된 지식으로써 주소를 노출하지 않는 것이 오히려 보안 위험이 높습니다. 웹 문서의 진짜 주소가 노출되지 않기 때문에 오히려 더 쉽게 속일 수 있습니다. 검색엔진은 프레임셋을 수집하지 않기 때문에 주변의 맥락 정보가 제거된 프레임셋 일부 문서만을 검색 결과로 제시하게 되는데 이때 문서의 이해도가 떨어지게 됩니다.

프레임셋 <frameset>...</frameset>을 사용한다면 무엇을 주의해야 하나요?

프레임셋 문서를 사용하면서 title 속성을 사용하여 프레임을 의미 적절하게 설명하지 않으면 접근성이 크게 떨어집니다. 시각장애인은 화면낭독 프로그램을 이용해서 프레임 사이를 탐색할 수 있는데 title="topFrame" 또는 title="bottomFrame"과 같이 내용 아닌 방향 정보만을 제공하는 참고 제목은 무의미 합니다. 프레임셋이 어떤 내용을 포함하고 있는지 다음과 같이 설명해야 합니다.

<frameset> _<frame title="메뉴" /> _<frame title="콘텐츠" /> </frameset>

내용 없는 빈 <iframe>...</iframe>을 사용하고 있습니다. 이런 빈 프레임에도 title="*" 속성을 이용해서 설명해야 하나요?

'빈 프레임', '내용 없음' 으로 설명해야 합니다. 설명하지 않으면 화면 낭독기 사용자는 콘텐츠가 있는 프레임으로 오인해서 탐색을 시도 합니다. 아예 건너 뛸 수 있도록 비어있다는 설명이 필요합니다.

<iframe title="빈 프레임"></iframe>

모든 기능을 키보드로 이용할 수 있도록 하려면 무엇을 주의해야 하나요?

onclick 이벤트 헨들러를 다음 요소에만 사용하면 됩니다. 아래 요소들은 특정 입력 장치에 구애받지 않고 focus를 가질 수 있으며 onclick 이벤트 헨들러가 어떤 동작을 유발 하더라도 사용자가 충분히 예측 가능한 요소들 입니다.

이 밖의 요소들은 키보드가 focus를 가질 수 없거나 또는 onclick 이벤트 헨들러가 어떤 동작을 유발하리라고 충분히 예측할 수 없기 때문에 되도록 onclick 이벤트 헨들러 사용을 피해야 합니다. 단, onclick 이벤트 헨들러가 현재 페이지의 내용을 갱신하지 않는다면 사용해도 괜찮습니다. 라디오 버튼 인풋이나 체크 버튼 인풋에onclick이 발생했을 때 label 텍스트를 빨강색으로 변화시키는 정도(내용 아닌 스타일의 변화)라면 괜찮습니다.

onclick과 onkeypress, onkeydown, onkeyup 이벤트 헨들러를 함께 사용하면 안되는 이유가 무엇입니까?

<a onclick="action()" onkeypress="action()">...</a> (X) <a onclick="action()">...</a> (O)

마우스에 상응하는 키보드 이벤트 헨들러를 작성해야 한다는 지침 때문에 onclick 이벤트 헨들러에 onkeypress 이벤트 헨들러를 함께 작성하는 실수가 적지 않게 발생 합니다. 그러나 onclick은 마우스 전용 이벤트 헨들러가 아닙니다. onclick 이벤트 헨들러는 키보드 Enter의 입력을 마우스 클릭과 동일하게 취급 합니다. 한편 다음 이벤트 헨들러들은 Enter키의 입력 뿐만 아니라 Tab키의 입력을 함께 받기 때문에 onclick과 함께 사용해서는 안됩니다. 포커스를 이동하기 위해 Tab 키를 누르거나 떼는 순간 onkeypress, onkeydown, onkeyup 이벤트 헨들러가 동작을 실행하는데 이것은 사용자가 기대하지 않는 결과 입니다.

onkeypress: 키 입력이 지속되는 동안(키가 눌려 있는 동안) 계속해서 이벤트가 발생 합니다.
onkeydown: 키 입력이 들어갈 때 단 한 번의 이벤트가 발생 합니다.
onkeyup: 키 입력이 빠질 때 단 한 번의 이벤트가 발생 합니다.

<a>...</a> 요소를 마크업 할 때 href 속성의 값으로 "#"을 사용하면 안되나요?

<a href="#">...</a> (X) <a href="#destination">...</a> (O)

<a>...</a> 요소의 어원은 anchor(닻) 입니다. 다른 자원을 연결하는 의미를 지니고 있고 href 속성으로 하여금 어떤 자원을 연결하고 있는지 표시할 수 있습니다. href속성의 어원은 hypertext reference 입니다. href의 값으로 아무 의미 없는 "#" 을 사용한다는 것은 <a>...</a> 요소를 본래의 의미(자원의 참조)와 다르게 사용했다는 것을 반증합니다. 참조하는 자원이 있다면 유효한 URL 값을 넣어 줍니다. 다른 자원을 참조하는 의미 없이 버튼이나 텍스트가 키보드 포커스를 받아야 한다면<button type="button">...</button> 요소를 사용해야 합니다. 물론 form을 전송하기 위한 버튼이라면 <input type="submit" /> 또는 <input type="image" /> 요소를 사용해야 합니다.

<button type="button">...</button> 요소의 의미와 사용법을 알려주세요.

<button type="button" onclick="action()">...</button>

<button type="submit | button | reset">...</button> 요소는 <input type="submit | button | reset" /> 요소와 동일한 기능을 수행 합니다. <button>...</button> 요소는 어떤 의미를 마크업하는 요소가 아니라 사용자 인터페이스에 대한 기능을 정의하는 마크업 으로써 type 속성의 기본 값은 submit 이며 다음과 같은 기능을 수행합니다.

<button type="submit">...</button>: form을 전송하는 기능. (기본 값, 그러나 IE 6~7 브라우저는 표준 명세에 따르지 않았다)
<button type="button">...</button>: 자바스크립트의 도움을 받아 인터페이스를 조작하는 기능. (IE 6~7 브라우저의 기본 값)
<button type="reset">...</button>: form 입력 항목들을 초기화하는 기능.

<input /> 요소와 가장 큰 차이점은 내용을 가질 수 있다는 점 입니다. <button>...</button> 요소는 텍스트 뿐만 아니라 이미지 요소를 자식으로 포함할 수 있습니다.

<button type="button">...</button> 요소의 디자인을 CSS로 제어할 수 없나요?

<button>...</button> 요소는 웹 브라우저 기본 값으로 회색 배경과 2px 크기의 outset 스타일이 지정되어 있는데 이 값을 다음과 같이 초기화 할 수 있습니다.

button { border:0; padding:0; background:transparent; cursor:pointer; *overflow:visible; }

*overflow:visible 속성과 값을 추가한 것은 버튼 텍스트 길이에 비례하여 비 정상적으로 버튼의 폭이 커지는 IE 6~7 브라우저 버그를 해결하기 위한 hack 입니다.

CSS 기반의 가변폭 텍스트 버튼을 만들고 싶습니다.

<a>...</a>, <button>...</button>, <input type="submit | button | reset"/> 요소의 버튼에 그래픽으로 처리된 배경을 사용하는 기법 입니다.

HTML

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

Image

CSS

.button,
.button a,
.button button,
.button input { position:relative; margin:0; display:inline-block; text-decoration:none !important; border:0; height:23px; font-size:12px; line-height:23px; font-family:Tahoma, Sans-serif; white-space:nowrap; background:url(http://naradesign.net/open_content/lecture/wp/img/button.gif) no-repeat; vertical-align:middle; color:#333;}
.button { padding:0; margin-right:2px; background-position:left top; }
.button a,
.button button,
.button input { left:2px; overflow:visible; padding:0 10px 0 8px; background-position:right top; cursor:pointer; _vertical-align:top; }
.button *:hover,
.button *:active,
.button *:focus{ color:#690; }
.button.strong * { font-weight:bold !important;}

화면 출력 결과

저는 <a>...</a> 요소로 마크업된 버튼 입니다

참고

CSS Text Button Design - http://naradesign.net/open_content/reference/button/
CSS Text Button Code - http://naradesign.net/open_content/reference/button/css/button.css

키보드의 논리적인 접근 순서를 위해 tabindex="*" 속성을 사용해도 될까요?

아니요. tabindex 속성은 사용하지 않는 것이 좋습니다. tabindex 속성을 사용한다는 것은 HTML 마크업의 논리적인 순서가 바르지 못하게 설계되었다는 것을 반증하는 것입니다. tabindex를 사용하는 경우 tabindex를 사용하지 않은 다른 요소보다 Tab키의 접근 순서에서 우선 순위를 갖기 때문에 일부 요소의 접근 순서는 맞을 수 있지만 문서 전체에서 보면 접근 순서가 맞지 않게 됩니다. 키보드 접근 순서는 HTML 마크업의 논리적인 순서에 따르기 때문에 HTML 마크업의 논리적인 순서를 바로잡는 것으로 해결해야 합니다.

건너뛰기 링크는 어떻게 구현하는 것이 가장 좋을까요?

대부분의 웹 사이트는 모든 페이지에서 항상 반복되는 글로벌 네비게이션과 로컬 네비게이션을 포함하고 있는데 이런 요소들이 본문보다 먼저 마크업이 된 경우 키보드 사용자가 이것을 건너 뛸 수 있는 앵커를 제공해 주어야 합니다. '본문 바로가기'와 같은 표현보다 무엇을 건너 뛰는지 알 수 있도록 '메뉴 건너뛰기'와 같은 이름이 좋고 여러개의 앵커보다 하나의 앵커만 제공하는 것이 좋습니다. 앵커를 제공하는 방법은 다음과 같은 세 가지 형태가 있는데 세 번째 방법을 가장 권장 합니다.

메뉴 건너 뛰기 상시 숨김: 항상 보이지 않도록 처리하는 방법 입니다. 시각 장애인에게 유효한 방법 입니다. 단, 시각은 있으나 키보드만을 사용할 수 밖에 없는 지체 장애인 또는 키보드를 선호하는 사용자가 이용할 수 없으므로 권장하지 않습니다.
메뉴 건너 뛰기 상시 보임: 항상 보이도록 처리하는 방법 입니다. 시각 장애인, 키보드 사용자에게 모두 유용한 방법이나 시각이 있고 마우스를 주요 제어 수단으로 사용하는 사람에게는 이 링크가 오히려 공해가 될 수 있으므로 적극 권장하지 않습니다.
키보드 접근시에만 보임: 메뉴 건너 뛰기 링크를 키보드 접근시에만 보이도록 처리하는 방법 입니다. 키보드에 의존하는 사용자는 편리하게 이용할 수 있고 마우스에 의존하는 정상 시각의 사용자는 불필요한 링크를 키보드로 건너 뛸 필요가 없기 때문에 간결한 화면을 유지할 수 있어서 가장 권장하는 방법 입니다.

키보드 접근시에만 보이는 메뉴 건너뛰기 링크의 구현 예는 다음과 같습니다. 중요한 것은 화면에서 이 링크를 숨길 때 상자의 너비 또는 높이를 0px 으로 지정하면 이 링크를 인식하지 못하는 브라우저(Safari, Chrome, Opera)가 있으므로 반드시 1px 이상의 너비와 높이를 지정해서 브라우저 호환성을 확보해야 합니다.

HTML: <div id="skipToContent"><a href="#content">메뉴 건너 뛰기</a></div>
CSS: #skipToContent { position:relative;} #skipToContent a { display:block; height:1px; width:1px; margin-bottom:-1px; overflow:hidden; text-align:center; color:#000; white-space:nowrap;} #skipToContent a:focus, #skipToContent a:active { height:auto; width:100%; padding:5px; margin-bottom:10px;}
참고: 메뉴 건너 뛰기 링크 적용 예 - http://naradesign.net/open_content/reference/navigation.html

자바스크립트를 이용한 팝업 띄우기는 무엇이 문제인가요? 어떻게 하면 되죠?

모든 상황에서 HTML의 본래 기능을 대체하는 자바스크립트는 부적절 합니다. 자바스크립트 없이 HTML만으로 기능을 수행할 수 있도록 구현한 다음 자바스크립트를 지원하는 환경을 위한 코드를 추가하면 문제가 되지 않습니다. 아래 예는 자바스크립트 미 지원 환경을 고려하지 않은 코드와 고려한 코드가 어떻게 다른지 보여 줍니다.

<a href="#" onclick="window.open('http://example.com/','_blank')">...</a> (X) <a href="http://example.com/" target="_blank" onclick="window.open(this.href, 'popName', 'width=300, height=200'); return false">...</a> (O)

데이터 테이블 <table>...</table>을 의미있고 논리적으로 작성하는 방법은 무엇인가요?

표(table)에 제목(caption)을 기재하고 표를 요약(summary)한 다음 헤더셀(th)과 내용셀(td)을 논리적으로 구분하면 됩니다. 이렇게 논리적으로 구성된 표는 화면 낭독기 또는 다른 장치에서 <th>...</th> 요소와 <td>...</td> 요소의 관계를 사용자에게 의미있게 재 구성해서 전달 할 수 있습니다. 예를 들면 음성으로 <td>...</td>의 내용을 전달 할 때 이 셀의 헤더 셀 <th>...</th>을 함께 읽어 주는 것입니다.

표 예제

정아람의 2010 성적표
학기 구분	국어	영어	수학
1학기	100	60	40
2학기	100	70	50

HTML

표에 시각적 속성 border="1"을 인라인 으로 추가한 이유는 CSS 미 지원 환경에서도 표의 보더를 볼 수 있도록 고려한 것입니다.

CSS

table{ border:1px solid #ccc; border-right:0; border-bottom:0; border-spacing:0;} caption{ text-align:left; font-weight:bold;} th, td{ border:1px solid #ccc; border-left:0; border-top:0; padding:0 5px; border-spacing:0;} thead th{ background:#f4f4f4;} tbody th{ background:#f8f8f8;}

탭 메뉴 형태의 네비게이션은 무엇으로 어떻게 마크업 해야 합니까?

탭 형태 뿐만 아니라 대부분의 메뉴 네비게이션은 목록 <ul>...</ul> 요소로 마크업 하는 것이 가장 적절합니다. 한편 메뉴 네비게이션은 보통 2단계 이상의 구조를 갖는데 이것을 마크업으로 적절하게 표현하는 방법은 다음과 같습니다. 상위 노드와 하위 노드의 관계를 논리적으로 표현 하려면 ul > li > ul > li 형태로 중첩해서 마크업 해야 합니다.

HTML

CSS

.gnbContainer{ height:60px; margin:0 0 20px 0;} .gnb{ position:relative; list-style:none; margin:0; padding:0; font-size:12px; border-bottom:1px solid #ccc; *zoom:1;} .gnb:after{ content:""; display:block; clear:both;} .gnb a{ position:relative; text-decoration:none; white-space:nowrap;} .gnb li{ float:left; margin:0 -1px -1px 0;} .gnb li a{ display:inline-block; border:1px solid #ccc; border-bottom:0; height:15px; padding:7px 15px; color:#333;} .gnb li li{ padding:0 15px; border-left:1px solid #ccc;} .gnb li li a{ border:0; padding:0; color:#767676; font-weight:normal !important; letter-spacing:normal !important;} .gnb li ul{ display:none; position:absolute; left:0; top:40px; list-style:none; margin:0; padding:0;} .Gnb1-1 .gnb1 ul, .Gnb1-2 .gnb1 ul, .Gnb1-3 .gnb1 ul, .Gnb2-1 .gnb2 ul, .Gnb2-2 .gnb2 ul, .Gnb2-3 .gnb2 ul{ display:block;} .Gnb1-1 .gnb1 a, .Gnb1-2 .gnb1 a, .Gnb1-3 .gnb1 a, .Gnb2-1 .gnb2 a, .Gnb2-2 .gnb2 a, .Gnb2-3 .gnb2 a{ font-weight:bold; letter-spacing:-1px; border-bottom:1px solid #fff;} .Gnb1-1 .gnb1-1 a, .Gnb1-2 .gnb1-2 a, .Gnb1-3 .gnb1-3 a, .Gnb2-1 .gnb2-1 a, .Gnb2-2 .gnb2-2 a, .Gnb2-3 .gnb2-3 a{ font-weight:bold !important; letter-spacing:-1px !important}

화면 출력 결과

<label>...</label> 요소는 어떻게 사용하나요?

<label>...</label> 요소는 form 콘트롤 요소를 설명하는 텍스트로써 모든 form 콘트롤은 항상 label과 명시적인 방법으로 1:1 대응해야 합니다. label 텍스트를 제공하면 화면 낭독기 사용자는 특정 form 콘트롤에 대하여 주변 문맥의 도움 없이 독립적으로 접근 하더라도 label 설명을 전달 받을 수 있습니다. 그러나 label 텍스트를 생략하거나 두 개 이상의 <input /> 요소에 하나의 설명만을 제공해야 할 때 <label>...</label> 요소 대신 title 또는 value 속성을 사용할 수 있습니다. label 텍스트가 존재함에도 불구하고 label을 사용하지 않고 title, value 속성을 사용하는 것은 바람직 하지 않습니다.

<label>...</label> 요소의 명시적 연결 예: <label for="search">검색</label> <input type="text" id="search" /> <input type="submit" value="검색" />
title 속성 사용 예 (label 텍스트가 생략된 경우): <input type="text" title="검색" /> <input type="submit" value="검색" />
title 속성 사용 예 (인풋이 두 개 이상인 경우): <input type="text" title="주민등록번호 앞 6자리" /> <input type="text" title="주민등록번호 뒤 7자리" />
value 속성 사용 예 (인풋이 두 개 이상인 경우): <label for="address">주소</label> <input type="text" id="address" /> <input type="text" value="나머지 주소 입력" />

위와 같이 label 텍스트를 마크업 할 때 for/id 속성을 연결하는 방법을 '명시적 연결' 이라고 부릅니다. 다른 방법으로써 '암시적 연결'이 있는데 암시적 연결 방법은 현존하는 화면 낭독기들이 명확하게 인식해서 처리하지 못하는 문제 때문에 문법적으로 유효함에도 불구하고 사용을 권장하지 않습니다.

<label>...</label> 요소의 암시적 연결 예: <label>검색<input type="text" /></label> <input type="submit" value="검색" />

플래시 <object>...</object> 네비게이션의 문제는 무엇인가요?

MS IE를 제외한 모든 웹 브라우저들은 플래시 객체에 키보드만으로 접근이 되지 않습니다. 따라서 비주얼 요소가 아닌 네비게이션 목적의 플래시는 사용을 지양해야 합니다. 만약 불가피하게 플래시 네비게이션을 사용한다면 플래시 제작단계에서 다음과 같은 방법으로 플래시의 자체적인 접근성을 확보해야 합니다.

키보드 접근을 받아야 하는 객체를 '버튼 심볼' 또는 '무비클립 심볼'로 만듧니다.
키보드 접근을 받아야 하는 객체를 선택한 다음 단축키 Shift+F11을 이용하여 Accessibility Panel을 활성화 합니다.
Accessibility Panel에 접근성 관련 속성을 작성합니다.
1. Make object accessible : 객체에 접근 가능하도록 만듬. (필수)
2. Make child object accessible : 자식 객체에 접근 가능하도록 만듬. (선택)
3. Name : 짧은 대체 텍스트. (필수)
4. Description : 긴 대체 텍스트. (선택)
5. Shortcut : 접근키로써 HTML의 accesskey 속성과 같은 역할을 합니다. (선택)
6. Tab index : 탭 순서. (필수) 설정하지 않으면 네비게이션의 구조와 관계없이 객체의 위치에 따라서 키보드 접근 순서가 결정됨.

플래시가 자체적인 접근성을 갖도록 제작했다면 플래시 객체를 HTML 문서에 삽입할 때 wmode의 값을 window 으로 처리 합니다. Flash Player는MSAA(Microsoft Active Accessibility)에 맞게 최적화되어 있는데 MSAA는 transparent와 opaque 모드를 지원하지 않습니다.

<param name="wmode" value="transparent" /> (X) <param name="wmode" value="opaque" /> (X) <param name="wmode" value="window" /> (O)

참고: Adobe Flash CS4 Professional > 액세스 가능한 내용 만들기 -http://help.adobe.com/ko_KR/Flash/10.0_UsingFlash/WSd60f23110762d6b883b18f10cb1fe1af6-7c47a.html#WSd60f23110762d6b883b18f10cb1fe1af6-7c43a

겸손한 자바스크립트(Unobtrusive JavaScript)란 무엇입니까?

모든 사용자가 자바스크립트 실행 환경에 존재하지 않는다는 것을 전제한 후 자바스크립트 미 지원 환경과 지원 환경을 각각 고려하여 설계하는 것을 말합니다.

모든 콘텐츠와 기능을 'HTML/CSS/서버측 스크립트'지원 환경에서 이용할 수 있도록 구현합니다.
'HTML/CSS/서버측 스크립트'지원 환경에서 구현된 코드 위에 자바스크립트 코드를 추가 합니다.
자바스크립트를 끄고 모든 콘텐츠와 기능을 이용할 수 있는지 점검 합니다.
자바스크립트를 켜고 모든 콘텐츠와 기능을 이용할 수 있는지 점검 합니다.

실례로 자바스크립트 미 지원 환경에서 회원 가입 양식을 작성하는 경우 사용자가 입력한 데이터의 유효성은 서버측에서 검사 하도록 구현 합니다. 그러나 자바스크립트 실행 환경에 있는 사용자는 자바스크립트를 이용해서 유효성을 검사할 수 있고 이 때에는 잘못된 데이터가 발견 되더라도 페이지 전환을 할 필요가 없기 때문에 보다 편리하게 사용할 수 있습니다.

AJAX의 접근성 문제는 무엇입니까?

AJAX는 서버측으로부터 갱신된 데이터를 페이지 이동 없이 사용자 화면에 출력해주는 장점이 있습니다. 화면 낭독기 프로그램은 자바스크립트에 의해 출력된 HTML 결과물에 접근할 수 있지만 AJAX에 의해 화면이 갱신된 사실을 인식하지 못하기 때문에 시각 장애인의 접근성을 떨어뜨립니다. W3C에서는 WAI-ARIA 1.0표준을 통해 이 문제의 해결을 시도하고 있으나 현재 국내 보조기기 제조사가 이 기능을 구현하지 않았기 때문에 웹 제작자는 WAI-AIRA 표준에 따르더라도 접근성이 개선되지 않습니다.

시각 장애인을 위하여 CSS { display:none } 처리된 콘텐츠를 제공하는 것이 왜 나쁜가요?

display 속성은 모든 미디어 도구에 적용되는 명령으로써 '스크린, 인쇄' 장치 뿐만 아니라 '음성, 점자'와 같은 보조공학기기들도 이 속성을 받아서 처리해야 합니다. 따라서 { display:none } 이라고 선언된 요소는 화면에서 보이지 않을 뿐만 아니라 인쇄가 되어서도 안되고 '음성, 점자' 장치에서도 건너 뛰어야 하는데 현존하는 국산 화면 낭독기 프로그램은 표준과 다르게 구현되어 있기 때문에 { display:none } 처리된 콘텐츠를 기본값으로 음성 전달합니다. 그러나 사용자가 이 옵션을 사용하지 않으면 더 이상 { display:none } 콘텐츠를 읽지 않기 때문에 중요한 데이터를 {display:none } 으로 처리하면 안됩니다. 화면에 출력되지 않지만 시각 장애인을 위한 별도의 콘텐츠가 필요한 경우 다음과 같이 처리할 수 있습니다.

.blind { position:absolute; left:-1000%; top:0; width:1px; heght:1px; font-size:0; line-height:0; overflow:hidden; }

width, height 값을 1px씩 지정한 이유는 내용물이 <a>...</a> 요소일 때 키보드의 focus를 받아야 하기 때문 입니다. 어떤 브라우저(Safari, Chrome, Opera)들은 면적이 없는 요소에는 focus를 받지 않도록 구현되어 있기 때문입니다. visibility:hidden 속성을 특별히 사용하지 않는 이유 또한 같습니다.

CSS Framework이란 무엇 입니까?

CSS Framework이란 다양한 구현이 가능하도록 미리 작성된 CSS 코드 라이브러리 입니다. HTML 문서의 구조와 전혀 무관하게 작성할 수도 있고 또는 HTML 문서의 구조에 기대어 작성할 수도 있습니다. CSS Framework의 장점은 미리 작성된 코드를 쉽고 빠르게 재 활용할 수 있다는 점이며 단점은 다양한 경우의 수를 고려하여 작성되기 때문에 특정 디자인에 최적화된 코드보다 더 많은 코드를 필요로 합니다.

레이아웃용 CSS 프레임웍 예

XE CSS Framework for Layout 사용자 가이드 - http://naradesign.net/wp/2009/07/17/998/
XE CSS Framework for Layout 데모 - http://naradesign.net/open_content/reference/layout/
XE CSS Framework for Layout (HTML 구조) - http://naradesign.net/open_content/reference/layout/layoutTemplate.html
XE CSS Framework for Layout (CSS 구조) - http://naradesign.net/open_content/reference/layout/css/layout.css

버튼 디자인용 CSS 프레임웍 예

CSS Text Button Design 사용자 가이드 - http://naradesign.net/wp/2008/10/31/203/
CSS Text Button Design 데모 - http://naradesign.net/open_content/reference/button/
CSS Text Button Design (CSS 구조) - http://naradesign.net/open_content/reference/button/css/button.css

드림위버와 같은 위지윅(WYSIWYG) 도구는 웹 표준이나 접근성을 지원 하나요?

네, 지원하고 있습니다. 'HTML/CSS' 문서의 유효성 검사로부터 웹 접근성 지침(WCAG 1.0 / Section 508) 준수 여부까지 점검할 수 있습니다. 표준 'HTML/CSS/DOM' 코드의 자동완성을 지원 합니다.

드림위버를 이용한 웹 표준 코딩 가이드 참고

URL : http://naradesign.net/open_content/lecture/DW&CSS/

드림위버는 너무 무거운 프로그램 아닌가요?

드림위버는 위지윅(WYSIWYG) 모드를 지원하기 때문에 위지윅 모드를 지원하지 않는 다른 프로그램보다 무거운 것이 사실 입니다. 그러나 빠르게 사용할 수 있습니다. 위지윅 모드에서 CSS 렌더링 끄기 (CSS 스타일 표시 전환 버튼) 상태로 사용하게 되면 드림위버가 CSS 코드를 디자인뷰에서 렌더링 할 필요가 없기 때문에 높은 성능을 기대할 수 있습니다. '보기(View) > 스타일 렌더링(Style Rendering) > 스타일 표시(Display Style)' 항목을 끄는 것도 동일한 방법 입니다.

CSS 파일을 부를 때 <link />와 @import의 차이는 뭔가요? 어떤 방법이 더 좋죠?

@import 명령은 CSS 문서에서 다른 CSS 문서를 부르는 방법이고 <link />는 HTML 문서에서 CSS 문서를 부르는 방법이라는 점이 다릅니다. IE 6~7 브라우저는 @import명령을 사용하는 경우 HTML 문서를 모두 해석한 다음에 CSS 문서를 해석하는 방식으로 구현되어 있어서 사용자의 체감 성능을 떨어뜨리는 요인으로 작용하기 때문에 되도록 사용을 권장하지 않습니다.

<link /> 요소를 사용하는 방법(권장): <link rel="stylesheet" type="text/css" href="default.css" />
@import 명령을 사용하는 방법(권장 안함): <style type="text/css"> @import url("default.css"); </style>

인쇄용 CSS를 어떻게 작성하는 것이 좋을까요?

기본 CSS 코드보다 아래쪽에 작성하고 @media 명령을 이용하여 인쇄시 필요한 스타일을 정의 합니다. 인쇄용 CSS를 별도의 파일로 분리하는 경우 전송 요청 횟수를 증가시켜 웹 문서의 성능에 좋지 않은 영향을 미칩니다.

/* For Screen */ body { background:black; color:white; } /* For Print */ @media print { body { background:white; color:black; } }

IE 6 브라우저는 #id.class 다중 선택자 조합을 지원하지 않습니다.

IE 6에서 발생하는 '다중 선택자 버그' 입니다. 하나의 아이디와 여러개의 클래스를 교차 조합하여 선택자를 만드는 경우 IE 6는 첫 번째 선택자의 조합만을 유효하게 처리하고 나머지 선택자 조합을 무시하는 버그 입니다. 이 버그 때문에 사실상 #id.class 다중 선택자 조합은 사용할 수 없습니다.

HTML

<body id="bold" class="red">#bold.red</body>
<body id="bold" class="green">#bold.green</body>
<body id="bold" class="blue">#bold.blue</body>

CSS

#bold.red { font-weight:bold; color:red; } 
#bold.green { font-weight:bold; color:green; } /* IE6는 이 스타일을 처리하지 않음 */ 
#bold.blue { font-weight:bold; color:blue; } /* IE6는 이 스타일을 처리하지 않음 */

기대하는 결과

#bold.red
#bold.green
#bold.blue

IE 6 렌더링 결과

#bold.red
#bold.green – 잘못된 렌더링
#bold.blue – 잘못된 렌더링

IE 6 브라우저는 .class.class 다중 선택자 조합 일부를 지원하지 않습니다.

IE 6에서 발생하는 '다중 클래스 버그' 입니다. 둘 이상의 클래스를 조합할 때 마지막에 선언된 클래스의 이름(.blue)이 다른 곳에서 이미 선언되어 있는 경우 다중 클래스 조합 .class.class 을 처리하지 않는 버그 입니다. 따라서 이미 선언된 클래스 이름을 다중 클래스 형식으로 재 사용 하고자 할 때 재 사용되는 클래스 이름을 마지막에 조합할 수 없습니다.

HTML

<ol>
_<li class="red">.red</li>
_<li class="blue">.blue</li>
_<li class="red blue">.red.blue</li>
_<li class="red bold blue">.red.blue.bold</li>
</ol>

CSS

.red { color:red; } 
.blue { color:blue; } 
.red.blue { color:silver; text-decoration:underline; } /* IE6는 .red 선택자를 무시 */ 
.red.bold.blue { color:black; font-weight:bold; } /* IE6는 .red.bold 선택자를 무시 */

기대하는 결과

.red
.blue
.red.blue
.red.bold.blue

IE 6 렌더링 결과

.red
.blue – 잘못된 렌더링
.red.blue – 잘못된 렌더링
.red.bold.blue – 잘못된 렌더링

IE 6 브라우저는 float 처리된 요소의 margin을 두 배로 처리하는 버그가 있습니다.

IE 6에서 발생하는 '더블 마진 플롯 버그' 입니다. float된 요소에 float된 방향과 동일한 방향의 margin을 설정하는 경우 margin값이 두 배로 작용하는 버그 입니다. 이 버그는 float된 방향과 같은 방향으로 형제 엘리먼트가 존재하는 경우에는 발생하지 않습니다. float 처리된 요소에 display:inline 속성을 부여해서 디버깅 할 수 있습니다. 참고로 float 처리된 요소는 표준 명세에 따라 display:block 속성을 갖게 되는데 제작자가 선언한 display:inline 속성보다 우선순위가 높기 때문에 요소가 실제로 display:inline으로 바뀌는 것은 아닙니다. 단지 IE 6 브라우저의 버그를 해결하는 trigger가 될 뿐입니다.

HTML: <div class="parent"> _<div class="child">...</div> </div>
CSS: .parent { height:100px; background:silver; padding:10px;} .child { float:left; margin-left:100px; width:100px; height:100px; background:red; } /* IE6는 왼쪽 마진을 200px으로 출력 */
기대하는 결과: .child
IE 6 렌더링 결과: .child

IE 6~7 브라우저는 float된 요소의 문자를 복사하는 버그가 있습니다.

이 버그는 float된 요소의 콘텐츠를 화면에 복사 출력해서 레이아웃을 깨뜨리는 버그 입니다. float된 요소 주변에 화면에 표시하지 않는 콘텐츠나 주석이 포함된 경우 간헐적으로 발생 합니다. float 처리된 요소에 display:inline 속성을 부여해서 디버깅 할 수 있습니다. 참고로 float 처리된 요소는 표준 명세에 따라 display:block속성을 갖게 되는데 제작자가 선언한 display:inline 속성보다 우선순위가 높기 때문에 요소가 실제로 display:inline으로 바뀌는 것은 아닙니다. 단지 IE 6 브라우저의 버그를 해결하는 trigger가 될 뿐입니다.

CSS: .container { float:left; width:300px; border:1px solid #ddd; padding:3px; margin:0 20px 0 0; font-size:.75em; } .container *{ margin:0; } .container .float1 { float:left; width:290px; background:#ccc; padding:5px; /*display:inline;*/ } .container .none { display:none; } .container .float2 { float:left; width:290px; background:#eee; padding:5px; }
HTML:  <div class="container"> _<h2 class="float1">W3C Develops Web Standards and Guidelines</h2> _<element class="none">화면에 출력되지 않는 요소 또는 주석</element> _<p class="float2">W3C primarily pursues its mission through the creation of Web standards and guidelines. Since 1994, W3C has published more than 110 such standards, called W3C Recommendations.</p> </div> 
기대하는 결과: W3C Develops Web Standards and Guidelines
W3C primarily pursues its mission through the creation of Web standards and guidelines. Since 1994, W3C has published more than 110 such standards, called W3C Recommendations.
IE 6 렌더링: W3C Develops Web Standards and Guidelines
W3C primarily pursues its mission through the creation of Web standards and guidelines. Since 1994, W3C has published more than 110 such standards, called W3C Recommendations.
Since 1994, W3C has published more than 110 such standards, called W3C Recommendations.

IE 6~7 브라우저는 float된 요소 주변에 등장하는 absolute 요소를 표시하지 않는 버그가 있습니다.

부모 요소에 position:relative 속성이 있고 자식 요소가 float된 요소는 형제 관계에 있는 position:absolute 요소를 간헐적으로 화면에 표시하지 않는 버그가 있습니다. 이런 경우 부모 요소에 zoom:1 속성을 부여하고 float된 요소와 absolute 요소 사이에 float되지 않은 빈 요소를 추가한 다음 zoom:1 속성을 부여해서 문제를 해결할 수 있습니다.

CSS: .container { position:relative; } .float { float:left; width:100%; } .absolute { position:absolute; top:1em; }
HTML: <div class="container"> _<div class="float">.float</div> _<div class="absolute">.absolute</div> </div>
기대하는 결과: .float
.absolute
IE 6~7 렌더링: .float

IE 6~7 문제를 해결하기 위하여 다음과 같이 작성 합니다.

CSS: .container { position:relative; *zoom:1; } .float { float:left; width:100%; } .dummy { *zoom:1; } .absolute { position:absolute; top:1em; }
HTML: <div class="container"> _<div class="float">.float</div> _<div class="dummy"></div> _<div class="absolute">.absolute</div> </div>

유니버설 디자인을 위한 실전 UI(HTML/CSS)개발 가이드

유니버설 디자인을 위한 실전 UI(HTML/CSS)개발 가이드

HTML 4.01

XHTML 1.0

<h1>정부 조직도</h1>

<h2>대통령 산하</h2>

<h2>국무총리 산하</h2>

<h2>정부 부처</h2>

W3C Develops Web Standards and Guidelines

W3C Develops Web Standards and Guidelines

관련글

티스토리툴바