Graceful Degradation

Graceful Degradation 은 “우아한 낮춤”, “적절한 퇴보”, “성능 저하” 등 여러가지로 번역되고 있습니다.

의미는, 먼저  최신의 기술 기반 혹은 최신의 기기에서 동작하는 기능을 만들고 나서 오래된 기술 기반 혹은 오래된 기기에서도 유사하게 (성능을 낮춰서라도) 동작하도록 조치하는것을 말합니다. 이런 의미에서 위의 번역들은 모두 틀리지 않다고 할 수 있겠습니다. (광의적으로 “성능 저하”도 틀리지는 않지만 웹 개발의 관점에서 보면 사용자 경험을 낮춰서라도 기능을 지원하는 것이기 때문에 “성능 저하”는 맞지 않을 것 같네요.)

※ 컴퓨터 시스템에서의 허용 오차 시스템(Fault tolerant system) 과 유사하다고 할 수 있습니다. 허용 오차 시스템은 프로그램 구동 환경에 문제가 생겨도 프로그램이 정지하지 않고 성능을 낮추면서 프로그램 구동을 지속하도록 하는 시스템을 말합니다.

우리가 잘 알고 있는 예를 들자면 IMG 태그에 alt 속성을 지정하는걸 들 수 있겠네요. 이미지를 표시하는 브라우저에서는 이쁘게 이미지를 표시하지만 텍스트 브라우저라든지 이미지를 렌더링하지 못하는 브라우저에서는 alt 속성에 부여한 대체 텍스트를 표시하도록 구성 합니다. (이 예에서는 성능을 낮춘다기보다 사용자 경험을 낮춰서라도 … 의 표현이 어울리겠네요. )

javascript 관점에서 Graceful Degradation 을 보자면 NOSCRIPT 라는 태그를 들 수 있습니다. 보통 NOSCRIPT 는 두가지 방식으로 사용됩니다.

NOSCRIPT (대체 콘텐츠 제공)

<script type="text/javascript" src="slide.js"></script>
<noscript>
<ul>
<li><a href="some url"><img src="1.jpg" alt="image 1"/></a></li>
<li><a href="some url"><img src="2.jpg" alt="image 2"/></a></li>
<li><a href="some url"><img src="3.jpg" alt="image 3"/></a></li>
</ul>
</noscript>

위의 예제에서 slide.js 는 서버로부터 이미지 3개를 받아 사용자 경험이 풍부한 스라이드 쇼를 만드는 스크립트입니다. (있다고 칩시다 –;) 바로뒤에 NOSCRIPT 태그를 사용해 스크립트가 동작하지 않는 브라우저에게 대신할 수 있는 콘텐츠를 제공하고 있습니다.

꽤 괜찮은 방법이라고 생각합니다. 자바스크립트가 구동되지 않는 환경에서도 콘텐츠에 접근할 수 있으며 IMG에 alt 를 제공하고 링크까지 걸려 있어 검색엔진도 좋아하는 형태입니다.

이 예에서의 문제는 NOSCRIPT 태그의 근본적인 문제입니다. 브라우저는 자바스크립트를 지원하지만 자바스크립트 파일을 통제하는 네트웍 환경 (보안상의 이유로?)에 있거나 자바스크립트를 다운로드 하지 못한 경우 사용자는 아무것도 볼 수 없게 됩니다.

NOSCRIPT (자바스크립트를 켜세요 ?)

<script type="text/javascript"  src="slide.js"></script>
<noscript>
<p>자바스크립트를 지원하는 브라우저를 사용하거나, 자바스크립트를 활성화 시켜 주세요</p>
</noscript>

우리는 사용자가 왜 자바스크립트가 동작하지 않는 브라우저를 사용하는지, 자바스크립트를 비활성화 시켰는지 알지 못합니다. 그런 상황에 사용자에게 “이래라, 저래라” 하는것은 좋은 방법이 아닙니다. 그리고 위 지시 문은 사용자가 자바스크립트가 뭔지 알고 있고, 자바스크립트를 활성화 시킬 수 있다고 가정하고 있습니다. 하지만, 태반의 사용자가 이런 사항 잘 알지 못합니다. 순전히 개발자의 관점에서 작성된 겁니다.

반성합니다 !! 저도 두번째 예제 코드를 무수히 만들었습니다. 변명을 하자면 KADO-WAH 초기 버전에서 (지금은 안 그렇죠?) SCRIPT 태그 이후에 NOSCRIPT 가 없는 경우 오류 (경고?)로 잡았었습니다. 그래서 기계적으로 SCRIPT 태그가 있는 곳에 NOSCRIPT (자바스크립트를 켜세요) 를 넣었고, 이게 또 HEAD 안에서는 P 태그 등이 올 수 없기 때문에 모든 SCRIPT/NOSCRIPT 태그를 BODY 밑으로 내리는 작업을 했습니다.  반성합니다.

Graceful Degradation 접근 방법

위의 두가지 예제를 보면 구현 모양은 다르지만 동일한  Graceful Degradation 접근 방법을 사용하고 있습니다.

자바스크립트로 slide.js 라는 사용자 경험 풍부한 기능을 먼저 만들고 자바스크립가 지원되지 않는 환경을 위해 NOSCRIPT를 이용해 추가(개선) 작업을 하고 있습니다. 이것이 뒤에서 말하려는 Progressive Enhancement 과 대조되는 부분입니다.

Progressive Enhancement

“점진적 향상” 이라고 번역할 수 있겠습니다.

말 그대로 기능을 점진적으로 향상시키는것을 말합니다. 바로 웹과 결부해서 말하자면

1. HTML 로만 콘텐츠를 구성합니다. (CSS 를 지원하지 않는 브라우저에서도 접근 가능합니다.)
2. CSS 로 시각적인 향상을 꾀합니다. (HTML은 이미 구성되었으므로 외부 CSS파일이 적당하겠네요.)
3. Javascript 를 적용해 사용자 경험을 향상 시킵니다. (역시 외부 js 파일을 두고 이벤트를 가로채는 방법으로 사용해야겠네요)

1.2.3 의 순서로 점차적으로 향상 시키고 있습니다. 이렇게 구현했을 때 나중에 나온 기술(css, javascript)들이 지원되지 않더라도 콘텐츠에 접근하는데 무리가 없습니다. 추가로 얻을 수 있는 장점은 이 방법을 사용하면 밑에 예제를 봐도 알겠지만 구조, 표현, 동작이 자연스럽게 분리된다는 점입니다. 단계적으로 html, css, js 가 추가되기 때문입니다. (솔깃하네요.)

직접 Progressive Enhancement 방법을 사용해 구현을 해 보겟습니다. 예제로는 어느 사이트에나 있는 FAQ를 사용합니다.

1. HTML 구성

<h1>자주답변하는 질문들</h1>
<dl id="faq-list">
<dt>백업파일(*.bak)을 생성하지 않는 방법은?</dt>
<dd>'기본설정'->'파일' 에서 '저장시 백업 파일 생성' 옵션을 제거하시면 됩니다.</dd>
<dt>업그레이드 후 이전 설정이 없어진 경우.</dt>
<dd>이전 버전을 올바르게 설치하지 않은 경우 일어나는 현상입니다. 이런 경우에는 '도구'->'INI 파일 디렉토리' 메뉴 옵션을 실행해서 이전 설정 (*.ini 파일)이 있는 디렉토리를 지정해 주십시오.</dd>
<dt>사용자 정의 stx, acp, ctl 파일을 추가하는 방법은?</dt>
<dd>
<p>*.STX 파일과 *.ACP 파일을 설정하는 방법</p>
<ol>
<li>'기본설정' 대화상자에서 '설정 및 구문강조' 페이지를 선택합니다.</li>
<li>원하는 파일 종류를 선택하거나 원하는 파일 종류가 없는 경우 '추가' 버튼을 누른 후 '파일 확장자' 란에 파일 확장자를 지정합니다.</li>
<li>STX 와 ACP 파일의 완전한 경로를 '구문 파일' 과 '자동 완성' 란에 지정합니다.</li>
</ol>
</dd>
</dl>

위의 FAQ는 에디트플러스 사이트에서 가져왔습니다. FAQ 목록에 DL 을 사용하는게 적절한지는 논외로 하겠습니다. HTML 만 사용했을 때 질문과 답변을 구분할 수 있도록 하는 목록 태그로는 적절하다고 생각해서 사용했습니다.

HTML만 적용된 화면

1단계에서 중용한 건 의미 있는 마크업을 논리적인 순서에 따라 구축하는게 중요하겠습니다. 물론, 이를 만족하기 위해서는 웹 표준을 준수하는게 우선되어야 할거고요.

하지만, 기획팀 으로부터 넘어온 스토리보드, 화면설계와 디자인팀으로 부터 잘려 넘어온 이미지들을 보고 있으면 당최 논리적으로 짜보기가 두려워 집니다. 뭐, 이런걸 잘 하는것도 우리의 능력중의 하나라고 봐야겠습니다. (전 멀었습니다.;;)

2. CSS 적용

body,dl,dt,dd {margin:0; padding:0;}
html {font-size:78%;}
html body {font-size: 1em;}
h1 {border:1px dotted #ccc; background:#eee; margin: 0 0 5px 0; padding:5px; font-size:1.4em;}
dt,dd {border-bottom:1px solid #ccc;line-height:1.5em;}
dt {background:black url(images/q.png) no-repeat left center; color:white; padding:7px 0 7px 25px; cursor:pointer;}
dd {background: #eee; padding:10px;}

CSS 까지 적용된 화면

네, 이쁘지 않은거 압니다. 제 미적감각이 이정도입니다. (사실, 최선을 다하지 않았다고 변명을 … ㅠㅠ)

3. javascript 적용

window.onload = function() {
var selectedQ = 0;
var dts = document.getElementsByTagName('dt');
var dds = document.getElementById('faq-list').getElementsByTagName('dd');
for(var i = 0, n = dts.length; i < n; i++) {
dds[i].style.display = (i == 0) ? 'block' : 'none';
dts[i].idx = i;
dts[i].onclick = function() {
if (selectedQ != this.idx) {
dds[selectedQ].style.display = 'none';
dds[this.idx].style.display = 'block';
selectedQ = this.idx;
}
};
}
};

javascript 까지 적용된 화면

네, 썩 좋지 않은거 압니다. (사실, 돌아가게 만드는게 우선이엇다는 변명을 … ㅠㅠ 정말 오랜만에 mootools 없이 javascript 만들어봤네요;;)

좋지 않은 예이긴 하지만, HTML → CSS → javascript 수순으로 점진적으로 향상시키고 있음을 주목해주세요.

위의 예는 faq.htm 에서 보실 수 있습니다. (ie8, firefox 에서만 테스트 되었습니다.)

정리

구현할 때 “누가 요새 javascript 안되는 브라우저를 쓰겠어?” 라는 생각이 들 정도로 자바스크립트는 대부분의 브라우저에서 지원하고 있는게 사실입니다. 사실, 그냥 막 써도 이로인한 불평(자바스크립트가 안되는 환경에서의 불평)도 들어본적이 없습니다. 아마, 사용자들 스스로가 감내하고 있겠지요. 하지만, 웹 접근성을 생각하고 이를 보장하고자 한다면 자바스크립트에 의존하는 코드를 사용해서는 안되겠습니다. href=”javascript:…” , href=”#” onclick=”" 이러 코드 때문에 얼마나 많은 시간을 웹 접근성 개선을 위해 허비했는지 … Progressive Enhancement  방법을 수행하는게 쉬운것만은 아닙니다. 아마 Graceful Degradation 과 비교해서 시간, 노력 등의 자원을 더 필요로 할겁니다. 기 구축된 사이트를 개선하는 작업에 있어서는 Progressive Enhancement 보다 Graceful Degradation 을 선택하는게 더 현명한 방법일지도 모르겠습니다. 하지만 잊지말아야 할 원칙 하나는 “Web for All”. 팀 버너스 리의

웹의 힘은 그것의 보편성에 있다. 장애에 구애없이 모든 사람이 접근할 수 있는 것이 필수적인 요소이다.
(The power of the Web is in its universality, Access by everyone regardless of disability is an essential aspect.)

라는 것이겠지요.

관련 지침

• 3.3.1 (콘텐츠의 선형화) 콘텐츠는 논리적인순서로 제공해야 한다.
• 4.1.1 (마크업 오류 방지) 마크업 언어의 요소는 열고 닫음, 중첩 관계 및 속성 선언에 오류가 없어야 한다.

현재 W3C 의 CSS Validator 에는 버그가 있습니다. 사용에 주의를 요합니다.

버그 내용

아래와 같은 CSS 구문을 입력해 검사를 해보면

#someElement {
background: url(images/img.png) no-repeat center;
}

잘못된 값 : background 해석 오류 [empty string] 이라는 오류를 보실 수 있습니다.

CSS Validator 에서 오류가 아닌 항목을 오류로 판단하고 있습니다.

마지막 background-position 부분에서 값을 하나 생략하는 경우 이와 같이 해석 오류를 보고 하고 있습니다.

CSS 2.1 스펙

CSS 2.1 Specification – background-position

하지만 이 구문은 링크에서 보시는 것 처럼 CSS 2.1 표준에 부합하는 구문이며, 심지어 스펙에서 제공하는 예제 조차 CSS-Validator는 오류를 보고 하고 있습니다.

이 문제는 W3C 의 버그 리포트에도 등록된 상태 입니다. (상태는 NEW ;;)

해법

1. 처음 제시한 구문을 아래 처럼 값 2개를 모두 명시하도록 수정 하거나

#someElement {
background: url(images/img.png) no-repeat center center;
}

2. http://qa-dev.w3.org:8001/css-validator/ 를 이용해서 점검하면 위의 오류를 피할 수 있습니다.

(사족)

# 너무 오랜만에 블로그에 글을 써서 그런지 시간이 굉장히 오래 걸렸습니다. (미리보기를 몇번이나 확인 하는지 ;;)

# 이래서야 2009년에 그랬던 것처럼 블로깅 하기가 꺼려질텐데 … 좀 가볍게 임해야겠습니다.