Inline Translator uses Bing translation API of microsoft. Bing API has usage limit and so Inline Translator’s default API key goes limit often. You can simply change API key to yours so you can avoid API usage limit.

Change Bing Translation API Key

1. At first, go to application page of bing webmaster
2. Login with Windows Live ID. If you don’t have Windows Live ID, create one! :)
3. So you can see the list page like below
   
4. Click “Add” button and fill up and save form.
5. After save form, list page will shown again.
6. You can see App ID like below (if App ID doesn’t exist, try page reload.
   
7. Copy App ID and paste into Bing App ID textbox of Inline Translator’s option page.
   

That’s all. Enjoy. :)

이 글은 Accessible Culture의 Programmatically Determined라는 글의 일부 발번역과 나의 견해가 포함된 글임을 알린다.

프로그래밍 방식으로 결정

"프로그래밍 방식으로 결정" 이라는 문구는 61개의 WCAG 2.0 성공 기준 중 6개에서 눈에 띄는 항목이다. 그것은 아마 처음으로 접근성과 WCAG를 접하는 사람들에게는 약간은 어려울지 모르겠지만, 사실은 그렇게 복잡하지는 않다. 사실, 당신이 이 문구 자체에 익숙하지 않더라도 당신은 이미 그것을 다루고 있을 것이다.

어쨌든, 난 "프로그래밍 방식으로 결정"이 웹 개발자들에게 WCAG에 관해 웹 접근성이란 무엇이며 왜 HTML의 적절한 사용이 중요한지 설명할 때 상당히 유용한 개념이라고 생각한다.

HTML에 포함

일반적인 웹 페이지 내용의 기반은 물론 HTML 마크업이다. 제대로 사용하면 그것은 의미론적 구조 그리고 콘텐츠 간 연관 관계 및 차이점을 식별하는 역할을 한다.

대부분의 사람들은 웹 페이지의 HTML을 보지 못한다. 그러나 웹 페이지에 액세스하는 데 사용되는 브라우저는 페이지의 콘텐츠를 이해하기 위해 HTML에 의존한다. HTML은 브라우저에게 다음과 같은 것들을 알려준다.

• 이 콘텐츠는 단락으로 이루어저 있고 2레벨 제목 아래에 제공되고 있다.
• 이것은 5개의 항목을 가진 순서 있는 항목의 3번째 항목이다.
• 이것은 텍스트 입력 필드이고 어떤 이름을 가지고 있다.
• 이것은 그 웹 사이트의 저 페이지로 이동할 수 있는 링크이다.
• 이 웹 페이지는 불어로 되어 있다. 단 이 문장은 영어 등으로 구성되어 있다.

콘텐츠 구조와 관계에 대한 정보를 제공하는 것은 어떻게 HTML이 설계 되었는지와 그것을 사용하기 위한 방법에 대한 기본적인 부분이다.

우리는 그것을 '프로그래밍 방식으로 결정'이라고 부른다.

콘텐츠가 HTML로 적절히 마크업 된 경우, 그 의미론적 구조와 관계는 마크업 자체에 포함된다. 즉, 그것들은 "프로그래밍 방식으로 결정"될 수 있다. 말하자면 이러한 정보는 코드에 포함되기 때문에 지원 기술은 프로그램을 통해 그것을 해석하여 사용자에게 다른 방식으로 제공할 수 있다. 이 정보는 "다른 감각 형식(예. 비주얼, 음성) 혹은 개인 사용자들의 요구에 맞는 표현 양식으로 변경"될 수 있다. 이것이 접근성 있는 웹 콘텐츠와 WCAG 2.0의 핵심 컨셉의 중요한 측면이다.

이러한 정보는 브라우저를 통해 다양한 디바이스 혹은 소프트웨어가 그것을 이용 가능한 형태로 전달될 수 있다. 스크린리더, 음성 인식 소프트웨어, 대체 입력 장치 등이 각각의 콘텐츠가 무엇인지 이야기하고 사용자가 적절하게 그것들과 상호 작용하도록 할 수 있다.

위의 인용문은 WCAG 등 웹 접근성 규격에서 말하는 "프로그밍 방식으로 결정"이 무엇인지를 설명하고 있다.

쉽게 말해 HTML을 의미에 맞게 작성하면 브라우저나 보조 기기에서 그 의미를 해석하여 나름대로 가공하여 사용자에게 전달할 수 있고 이것은 곧 해당 콘텐츠가 "프로그래밍 방식으로 결정"될 수 있다고 할 수 있다.

링크를 a 요소가 아닌 span 같은 요소로 구현하고 키보드 접근성을 위해 tabindex를 0으로 주고 자바스크립트로 링크처럼 구현했다고 치자. 자바스크립트 비활성화 경우는 차치하고 무슨 문제가 있을까? 결론은 해당 링크가 "프로그래밍 방식으로 결정"되지 못한 것이 문제이다. 사용자는 링크처럼 클릭해서 사용할 수 있지만 브라우저나 보조 기기는 해당 콘텐츠가 링크인지 알 수가 없다는 것이다.

이 문제는 브라우저나 보조 기기가 링크를 가공할 때 도드라진다. 가령 브라우저는 링크를 우클릭할 경우 즐겨찾기에 추가, 새 창으로 열기 등 관련 편의 기능을 제공하고 스크린리더는 링크만 모아서 제공하거나 "무슨 무슨 링크"라고 읽어주는 등의 기능을 제공하는데... 위의 경우 그것이 불가능하게 된다.

결론 요약

가능하다면, 적절한 HTML 요소와 속성을 사용하라. 내용의 구조와 관계가 표현되게끔 마크업을 작성하라.

• 그것은 어떤 종류의 콘텐츠인가?
• 주위 콘텐츠와의 관계는 무엇인가?
• 기능을 제공하는 경우 그것은 무엇을 하는가? 이름, 역할, 상태, 그리고 값이 마크업에 드러나는가?

이러한 질문에 대한 답변을 HTML과 WAI-ARIA 마크업만으로 명확하게 제공된다면, 이는 곧 이와 같은 정보가 브라우저에 의해 프로그래밍 방식으로 결정되는 것이고 이는 곧 보조 기술 및 장치를 지원한다는 것을 뜻한다.

결국 인용한 글의 결론과 같이 의미있는 웹 콘텐츠가 있을 때 해당 의미가 HTML에 포함되도록 HTML 코드를 만들면 "프로그래밍 방식으로 결정"이라는 명제를 만족할 수 있다.

Microformat이 뭐냐고? NULI 블로그에 아마티님이 좋은 소개글을 작성하신 바 있으니 참고하면 되겠다.

facebook 이벤트에 추가된 Microformat은 이벤트에 hCalendar가 추가된 것, 그리고 이벤트 장소에 hCard가 추가된 것이다. hCard도 추가되었다고 해서 액티비티나 댓글 등에 있는 모든 프로필 정보에 hCard가 추가되었나 했더니 그건 아니었다.

Microformat은 Microformat이 사용된 웹 문서가 엄청나게 많아지기 전에는 크게 활용성이 떨어진다. 반대로 활용성이 떨어지는 Microformat을 굳이 웹 문서에 넣으려고 하는 제작자는 별로 없다. 그런 의미에서 facebook에 있는 수백만개의 이벤트가 Microformat으로 제공된다는 것은 활용성 측면이나 제작자들에게 미치는 영향이 클 것이다.

일정이나 연락처 등의 서비스들을 제공하고 있고 툴바나 브라우저 확장기능 같이 Microformat을 당장 써먹을 수 있는 제품을 갖고 있는 우리나라 포털 업체들에게는 참 ROI가 높은 맛있는 먹잇감일텐데… 누가 먼저 물라나… ㅋ

facebook에 Landmark Role이 추가된 건… 길게 쓸 건 없을 것 같고… 참 쉬운데… facebook도 넣는데… 안 넣는 게 이상한거다. 게다가 WAI-ARIA는 벌써 CR(Candidate Recommendation)! ㅋ

Landmark roles는 정적인 웹 페이지에 책갈피를 달아놓은 것이라고 설명할 수 있다. 이는 HTML을 스타일링하지 않아도 어느 부분이 메인 컨텐츠 영역인지 사이드바(부가 정보) 영역인지 메인 메뉴(내비게이션) 영역인지 명확하게 구분하도록 해준다.

Landmark roles는 현재 다음의 8종류가 있다.

• application: 웹 응용 프로그램에 선언한다. 여기서 웹 응용 프로그램이란 GMail, SVG와 같은 정적인 웹 문서와 반대되는 개념이다. 스펙에 따르면 보조 기기는 이 선언을 만나면 브라우저 탐색 키를 웹 어플리케이션에게 돌려줘야 한다고 한다. (이 개념에 대해서는 독립 주제로 다루어야 할 정도네요.)
• banner: 사이트의 로고(최초의 헤딩) 또는 내부 페이지의 제목을 포함하는 영역. 이 영역의 컨텐츠는 대체로 사이트 전체에 걸쳐 동일하다.
• complementary: 문서의 독립적이고 부가적인 컨텐츠 영역. 메인 컨텐츠에서 분리되어도 그 자체로 의미가 있는 영역이다. 보통 메인 컨텐츠의 오른쪽에(서브메뉴가 왼쪽일 경우) 포함되는 컨텐츠를 이 영역으로 분류할 수 있다. HTML5의 aside 요소와 대응된다.
• contentinfo: 상위 문서에 적용되는 메타데이터를 의미한다. (스펙의 설명은 이렇고 쉽게 말하자면 저작권, 사이트 관련 연락처 - 주소, 전화번호, ... - 등이 포함된 푸터를 이 영역으로 분류할 수 있다.) HTML5의 footer 요소와 대응된다.
• form: 폼 전송 영역(말 그대로 폼). 다만, search role에 해당되는 폼은 제외.
• main: 문서의 메인 컨텐츠. 반드시 1번만 선언되어야 한다.
• navigation: 메뉴(내비게이션 묶음) 영역. HTML5의 nav 요소와 대응된다.
• search: 문서 검색 툴을 의미하며 보통 통합 검색 영역을 지정할 수 있다. 추가로 우리나라에서 통용되는 게시판 목록의 검색 폼에도 사용하면 좋을 것이라고 생각한다.

Landmark roles 작성법은 여기까지다. 정말 쉽지 않은가?

그런데 landmark roles를 쓰면 뭐가 좋은걸까?

우선, 보조 기기의 사용성이 향상된다. Screen Readers And WAI-ARIA Landmark Roles라는 글에 따르면 현재 스크린리더 중 Jaws와 NVDA에서 landmark roles를 지원한다. Landmark roles를 지원하는 스크린리더 사용자는 landmark role간을 탐색하는 핫키를 이용하여 영역을 탐색할 수 있다. 문서를 순차적으로 읽어내려가는 스크린리더 사용자에게 이는 스킵 내비게이션과 비교했을 때 훨씬 유용한 것으로 생각된다. 스킵 내비게이션은 물리적으로 문서의 맨 처음에서만 접근 가능한 대신 landmark role은 필요할 때 핫키를 통해 문서의 주요 시작점을 자유롭게 탐색할 수 있기 때문이다.

참고한 글들 중 보조 기기의 사용성 향상 이외에 다른 장점에 대해 언급한 것은 없다. 그래서 아래에 개인적으로 생각한 장점들에 대해 나열해본다.

첫째, 사람이 HTML 코드를 이해하기 쉬워진다. 굳이 주석을 달지 않아도 어느 태그가 메인 영역을 감싸고 있고 어느 태그가 푸터 영역을 감싸고 있는지 코드로 설명된다. 쓸데없는 주석이 줄어들 수 있겠다.

둘째, 기계가 HTML 코드를 이해하기 쉬워진다. 웹 페이지의 일반적인 레이아웃 구조가 프로그래밍 방식으로 결정 되는 것이다. 예를 들어 검색엔진 입장이라면 극단적으로 main landmark의 컨텐츠만 검색하거나 아니면 main landmark의 컨텐츠의 중요도를 높게 취급한다면 검색 품질의 향상을 꾀할 수 있을 것이고 브라우저는 인쇄용 CSS를 메인 컨텐츠용으로 따로 준비하지 않았다고 하더라도 "메인 컨텐츠만 인쇄하기" 같은 메뉴를 제공할 수 있을 것이다. 또 나같이 지저분한 사이트(광고로 도배된 신문사 사이트)를 혐오하는 사람들을 위해 부가 정보(complementary role) 숨기기 같은 옵션을 제공할 수도 있을 것이다.

셋째, Landmark roles라는 약속된 규칙에 의해 이정표를 삽입하는 것이기 때문에 Landmark roles를 지원하는 웹 페이지들은 일관성 있는 탐색을 보장할 수 있게 된다.

센스리더에서는 지원하지 않지만 이미 iPhone에 내장된 스크린리더인 VoiceOver에서 지원중이다. 게다가 적용하는게 망설일 필요도 없을 만큼 쉬운 것이 landmark roles다! 이미 만들어져 있는 사이트도 5분만 투자하면 바로 적용할 수 있을 것이다!

마크업과 자바스크립트를 아래 코드와 같이 작성하면 된다.

<script type="text/javascript">
// <!--
$(function() {
    $('#tabs').flowTab();
    // $('#tabs').flowTab({tabSelector: '> .heading'});
});
// -->
</script>
<div id="tabs">
    <h2 class="heading">tab1</h2>
    <div>tab1 content <a href="#">link example</a></div>
    <h2 class="heading">tab2</h2>
    <div>tab2 content <a href="#">link example</a></div>
    <h2 class="heading">tab3</h2>
    <div>tab3 content <a href="#">link example</a></div>
</div>

flowTab plugin은 몇가지 옵션이 있다.

• tabSelector: 탭을 가리키는 jQuery 선택자. (기본값: "> .heading")
• tabEnabledClass: 활성화된 탭 요소에 추가될 class명. (기본값: "headingEnabled")
• contentDisabledClass: 비활성화된 탭 내용 요소에 추가될 class명. (기본값: "contentDisabledClass")

예제와 다운로드

예제: jQuery flowTab plugin example

다운로드: jquery.flowTab.js

no jQuery 버전

탭 이외에 특별히 jQuery를 사용하지 않는 사이트는 no jQuery 버전이 더 가볍게 동작한다.

jQuery 버전과의 약간 옵션 차이가 있다: tabSelector 옵션 대신 tabClassName 옵션을 사용한다. 루트 요소에서 탭을 찾을 때 tabClassName에 기재된 클래스명으로 찾는다. 기본값은 "heading".

아래는 코드 예제

<script type="text/javascript">
// <!--
// onload 구현은 알아서...;;
window.onload = function() {
    new flowTab(document.getElementById('tab'));
    // new flowTab(document.getElementById('tab'), {tabClassName: 'heading'});
};
// -->
</script>
<div id="tabs">
    <h2 class="heading">tab1</h2>
    <div>tab1 content <a href="#">link example</a></div>
    <h2 class="heading">tab2</h2>
    <div>tab2 content <a href="#">link example</a></div>
    <h2 class="heading">tab3</h2>
    <div>tab3 content <a href="#">link example</a></div>
</div>

다운로드(no jQuery): flowTab.js

WAI-ARIA 저작 가이드 문서의 tab 부분을 보면 탭 인터페이스를 구현하는 방법을 자세히 소개하고 있는데 그 중 키보드 인터페이스에서 좌/우, Ctrl+Tab/Ctrl+Shift+Tab, Ctrl+PageUp/Ctrl+PageDown 키를 이용하여 탭과 탭을 이동하는 기능을 구현하도록 문서화되어 있는데 좌/우 키는 기존에 웹 페이지에서 탭 키를 통해 링크를 이동하던 사용자에게 혼란을, Ctrl+Tab/Ctrl+Shift+Tab이나 Ctrl+PageUp/Ctrl+PageDown 키는 브라우저의 탭간 이동에 사용되고 있어 중복된다. (문서에 이 내용도 언급이 되어있다! -_-)

현재 탭(처럼 보이는) 마크업에는 크게 2가지 코드 형태가 사용된다고 생각한다.

<div class="tabpanel">
    <ul class="tablist">
        <li><a href="#tab1">Tab1</a></li>
        <li><a href="#tab2">Tab2</a></li>
        <li><a href="#tab3">Tab3</a></li>
    </ul>
    <div id="tab1">
        <h1>Tab1</h1>
        Tab1 Content</div>
    <div id="tab2">
        <h1>Tab2</h1>
        Tab2 Content</div>
    <div id="tab3">
        <h1>Tab3</h1>
        Tab3 Content</div>
</div>

<div class="tabpanel">
    <h1>Tab1</h1>
    <div id="tab1">Tab1 Content</div>
    <h1>Tab2</h1>
    <div id="tab2">Tab2 Content</div>
    <h1>Tab3</h1>
    <div id="tab3">Tab3 Content</div>
</div>

[코드1]에는 문제가 발생할 여지가 많다. 탭에서 href="#tab1"와 같은 링크가 생략되는 경우, 링크가 올바로 컨텐츠를 가리키지 못하는 경우, 컨텐츠에 헤딩이 누락되는 경우 등이다. 그리고 [코드1]을 자바스크립트를 통해 구현한 경우 보통 탭의 링크를 취소(preventDefault) 시키기 때문에 다른 탭들을 건너뛰어 해당 내용으로 이동해야 하기 때문에 마우스 사용자 이외에는 비효율적이다. 탭이 많으면 많을수록 더욱 더 비효율적이 된다.

[코드2]는 코드1의 키보드 비효율성이 전혀 없다. 코드1의 문제가 발생할 여지들도 애초에 차단된다. 탭 UI를 위해 헤딩을 작성하도록 유도시키고 빼먹거나 잘못 구현할지 모르는 탭 링크들을 애초에 제거하였다.

웹 어플리케이션 위젯을 OS의 그것들처럼 인식시키려고 하는 ARIA의 구현방식에서 볼 때는 코드2와 같은 구현이 적절하지 않다고 생각되기도 한다. 하지만 마우스 사용자에게는 어차피 상관없는 문제이고 키보드 사용자에게는 이전의 웹 페이지들과 다른 사용행태에 대한 혼란을 없앨 수 있다(익숙함을 유지하는 것을 영원히 장점이라고 하긴 어렵지만…). 무엇보다 개발자들에게 오류 발생 가능성을 상당히 줄여줄 수 있다는 사실 때문에 앞서 언급했던 ARIA tab의 문제들을 제거한 라이브러리들이 등장하기 전까지는 코드2와 같은 구현 방식을 추천하고 싶다.

• WAI ARIA Live Regions – MDC
• How to use ARIA Live Regions for dynamic content – CodeTalks

이 글을 통해 ARIA 개발의 감각을 끌어올릴 수 있기를 바라며 스펙(Taxonomy of WAI-ARIA States and Properties)에 더 많은 내용이 있으니 참고바란다. 예제들은 ARIA를 지원하는 스크린리더(Korean JAWS for Windows (한글용; 유료), NVDA (영어용; 무료))로 어떻게 동작하는지 테스트해볼 수 있다.

Live Region이란?: 개발자가 웹 문서의 특정 부분을 동적인 컨텐츠라고 명시할 수 있는데 그 영역을 일컬어 Live Region이라고 할 수 있다.

개요

과거에는 웹 페이지 변경은 전체를 읽어주게 하거나 거의 읽어주지 않아서 일부 혹은 전체의 정보에 접근할 수 없도록 만들어 종종 사용자를 짜증나게 했다. 최근까지는 보조기기는 이를 개선할 수 없었다. 왜냐하면 변경에 대응하여 보조기기에 경고해줄 수 있는 마크업 표준이 없었기 때문이다. Live Region은 이 차이를 메우고 보조기기에 DOM 변경을 알려줄 수 있는 설정을 제공하였다. 설정은 언제 어디서 업데이트가 발생하고 얼마나 중요한지를 포함한다. Live Region을 사용하는 목표는 가장 먼저 관련 정보를 제공하고 가능한한 사소한 정보는 제한하는 것이다. 웹 개발자는 Live Region 사용에 익숙해져야 하고 웹 사이트의 사용자 인터페이스를 설계할 때 이것을 고려해야 한다.

Live Region state

페이지를 다시 로드하지 않고 업데이트 되는 동적 컨텐츠는 반드시 Live Region을 표시해야한다. Live Region은 ARIA 가이드라인 상태의 영향을 받으며 많은 사용자 정의 설정들은 가지고 있다. 다음은 각 관련 설정의 목록과 그 설명이다.

aria-live: (aria-live=POLITENESS_SETTING)

보조기기가 live region의 업데이트를 처리하는 우선순위를 설정하는데 사용된다. 가능한 설정들은 “off/polite/assertive“이며 기본값은 off.

설정값

• aria-live="off": live region의 업데이트를 알리지 않음.

  예제: http://accessibleajax.clcworld.net/simple/live_off.htm

• aria-live="polite": live region의 업데이트를 사용자의 현재 동작이 끝날 때 알림.

  예제: http://accessibleajax.clcworld.net/simple/live_polite.htm

• aria-live="assertive": live region의 업데이트를 사용자에게 바로 알림.

  예제: http://accessibleajax.clcworld.net/simple/live_assertive.htm

aria-relevant: (aria-relevant=[LIST_OF_CHANGES])

live region이 변경될 때 보조기기로 하여금 어떤 변경을 주시하도록 할 것인가를 설정한다. 여기서의 변경은 의미있는 변경 – 예를 들어, 온라인 친구목록에서 친구 리스트 한개가 없어졌다면 이는 친구가 오프라인이 되었다는 의미 – 가능한 설정들은 “additions/removals/text/all“이고 기본값은 “additions text“.

설정값

• aria-relevant="additionals": 추가되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_additions.htm

• aria-relevant="removals": 제거되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_removals.htm

• aria-relevant="text": 변경되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_text.htm

• aria-relevant="all": 위의 세가지 변화를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_all.htm

aria-atomic: (aria-atomic=BOOLEAN)

live region이 변경될 때 보조기기가 live region 중 변경된 요소만을 알려줄지, live region 전체를 알려줄지 설정한다. 가능한 설정들은 “false/true“이고 기본값은 false.

설정값

• aria-atomic="false": live region 중 변경되는 요소만 알려주도록 설정한다.

  예제: http://accessibleajax.clcworld.net/simple/atomic_false.htm

• aria-atomic="true": live region이 변경되면 영역 전체를 다시 알려주도록 설정한다.

  예제: http://accessibleajax.clcworld.net/simple/atomic_true.htm

aria-controls: (aria-controls=[IDLIST])

사용된 요소가 컨트롤하는 요소들을 나타내는데 사용된다. 값에는 컨트롤하는 요소들의 ID가 공백으로 구분되어 들어갈 수 있다. 예) aria-controls="myRegionID1 myRegionID2"

예제: http://accessibleajax.clcworld.net/simple/controls.htm

aria-labelledby: (aria-labelledby=[IDLIST])

live region에 해당하는 레이블들을 나타내는데 사용된다. live region에 사용하며 값에는 레이블 요소들의 ID가 공백으로 구분되어 들어갈 수 있다.

예제: http://accessibleajax.clcworld.net/simple/labelledby.htm

aria-describedby: (aria-describedby=[IDLIST])

live region에 해당하는 설명들을 나타내는데 사용된다. live region에 사용하며 값에는 설명이 포함된 요소들의 ID가 공백으로 구분되어 들어갈 수 있다.

예제: http://accessibleajax.clcworld.net/simple/describedby.htm

KWAG 12번째 모임 발표자료 WAI-ARIA in Real World(on slideshare.net)입니다.

첫 발표라 긴장되고 어색했다는 느낌이 드네요. 죄송해요. ㅠ_ㅠ

발표에서 빼먹었던 내용들

이렇게 큰 모임에서의 발표는 처음이었던 관계로 긴장이 되어 준비했던 것들을 다 전달해드리지 못했습니다. 아쉬운 마음 글로나마 보충해봅니다. 참가하셨던 분들 중에 몇 분이나 보실지는 모르겠지만 도움이 되셨으면 좋겠네요.

브라우저별 ARIA 지원표에서…

프리젠테이션 10번 슬라이드의 내용입니다. 브라우저별 ARIA 지원표의 마지막 업데이트는 2009년 9월 23일이었고 1년 가까이 지난 관계로 더욱 향상되었을 것입니다. (모든 브라우저들이 적극 ARIA 지원의사를 밝혔으니까요.) 지원표는 Windows Vista의 MSAA role에 대한 지원 정도를 나타냅니다.

Widget Roles의 구현은 자바스크립트로만!

프리젠테이션 17번부터 시작되는 슬라이드의 내용입니다. Tab 같은 Widget Role은 자바스크립트가 비활성화된 경우 선형화된 컨텐츠로 표시되도록 Progressive Enhancement 방식으로 개발하시죠? 따라서 자바스크립트가 비활성화된 경우는 Tab도 일반 컨텐츠이기 때문에 Widget Role은 자바스크립트로 구현합니다. role attribute나 aria-* attribute를 자바스크립트에서 페이지가 로딩된 즉시 부여한다는 이야기입니다.

다만, Landmark Role은 정적인 문서의 영역을 표시해주는 역할을 하기 때문에 HTML에 직접 attribute로 삽입합니다.

Widget Role의 개발 시 추가 참고 문서

Widget Role 개발 시 보여드린 각 Role별 스펙에 추가로 Authoring Practices 스펙의 각 Role별 interaction 구현 방법을 참고하셔야 합니다. 원래 각 Role별 스펙에서 각 Role별 interaction 구현 방법으로 링크가 걸려있어야 할 것 같은데 아직 스펙의 링크들이 정돈되지 않아보이네요.

참고 링크

• The Paciello Group Blog: ARIA role support: how the Windows browsers stack up – Update: 브라우저별 ARIA 스펙 준수 테스트 결과 (Windows Vista MSAA 기준)
• Official Google Reader Blog: Reader and ARIA: A new way to read: 구글 리더 제작팀 블로그의 ARIA 지원 알림
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » Landmark Roles: 문서의 내비게이션, 메인 영역 지정들을 위한 Landmark Roles 스펙
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » Widget Roles: 탭, 다이얼로그 등의 RIA(리치 인터넷 어플리케이션) 위젯 접근성을 위한 Widget Roles 스펙
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » tab (role): Widget Roles의 하나인 Tab Role 스펙
• The Paciello Group Blog: WAI-ARIA Implementation in JavaScript UI Libraries – updated: WAI-ARIA가 구현된 자바스크립트 라이브러리 목록
• 3.2.5 Content models — HTML5 (Edition for Web Authors) » 3.2.6 Annotations for assistive technology products (ARIA): HTML 5 스펙의 ARIA에 대한 설명

자바스크립트 속도 때문에 골치를 앓고 있는 이라면 당장 설치하길…

암튼 좀 짱임.

<link rel="canonical" href="http://example.com/page.html" />

위의 코드를 넣어주면 끝입니다. 간단하죠? 단어 그대로 표준 혹은 대표 링크를 선언해주는 것입니다. 이미 많은 발표자료, 동영상 등이 공개되어 있네요. 보시죠~ 참고로 첫 링크만 보시면 정리가 다 됩니다. :)

• Learn about the Canonical Link Element in 5 minutes
• Specify your canonical – Google Webmaster Central Blog
• Fighting Duplication: Adding more arrows to your quiver – Yahoo! Search Blog
• Partnering to help solve duplicate content issues – MS Live Search Webmaster Center Blog

아래와 같이 a와 b라는 ID를 갖는 디비전이 같은 클래스명을 갖는 하위요소를 포함하고 있다고 칩시다.

<div id="a">
    <div class="content">…</div>
</div>

<div id="b"> <div class="content">…</div> </div>

그런데 문제는 각각 다른 사람 – 혹은 같은 사람이더라도… – 이 작업한 a와 b가 부모, 자식간이 되는 경우입니다. (물론 이미 부모, 자식간인 걸 알고 있어도 문제는 있습니다.)

<div id="a">
    <div class="content">…</div>
    <div id="b">
        <div class="content">…</div>
    </div>
</div>

a에 포함된 content에 스타일을 입히려고 쓴 CSS가 b의 그것에도 영향을 미치게 됩니다. 서로에 대해서 염두해두고 작업을 해야만 하는 것이죠. 프로젝트 규모가 커지고 요구사항이 빈번하게 바뀐다면 작업 시간은 그에 비례해서 더 커지게 됩니다.

IE6만 아니었으면 #a div.content라는 선택자 대신 #a > div.content라는 선택자를 썼으면 해결될 일이겠죠. 그래서 저희 팀에서는 아래와 같이 항상 prefix를 달아주기로 결정했답니다.;;

<div id="a">
    <div class="a_content">…</div>
    <div id="b">
        <div class="b_content">…</div>
    </div>
</div>

괜찮은 해결책이라고 생각합니다만 클래스명이 쓸데없이 길어지고 마크업만 놓고 보면 “a_”와 같은 의미없는 접두어가 생겨버렸습니다. 마이크로포맷 같은 걸 적용하려고 할 때도 귀찮은 일이죠. 웹 개발자가 살아나지 못하는 한 울며 겨자먹기로 이 방법을 쓸 것 같습니다.

IE7 자바스크립트 라이브러리

IE7(브라우저가 아닙니다.)이라는 라이브러리는 IE6의 CSS 지원 정도를 IE7처럼 만들어주는 마법같은 라이브러리입니다. 그런데! 열라 느립니다. -_-

IE7 라이브러리의 구동원리는 CSS 파일을 XML HTTP 요청으로 다시 받아 그 텍스트를 자바스크립트로 파싱하여 적용해주는 것입니다. 그 이유는 cssText로 읽을 수 있는 텍스트가 있지만 IE6의 경우 지원하지 않는 선택자 부분이 “UNKNOWN”이라는 문자열로 치환되어 버리기 때문입니다.

UNKNOWN이라는 문자열로 바뀌어버린 Child Selector와 마지막 밖에 인식하지 못하는 Multuple Class Selector

따라서 일단 쓸데없는 요청이 한 번 늘어나는 데다가 안 그래도 굼벵이 자바스크립트 엔진을 가진 IE6에서 그 큰 CSS 파일을 파싱한다는 것 자체가 느릴 수 밖에 없는 원인입니다.

IE7 라이브러리 중 Multiple Selector 부분과 Child Selector 부분만 사용해보고자 하였었는데 XML HTTP 요청이라는 제약(CSS 파일의 도메인을 문서와 항상 같게 해야한다는 제약)과 그래도 부담될 IE6의 굼벵이 자바스크립트 엔진 때문에 포기하였습니다. 혹시 시도해보고자 하는 분이 계시면 연락주세요. 그간 IE7 라이브러리를 뜯어보았던 자세한 소감을 말씀드리지요. -_-;;

오페라10 알파 버전이 공개되었습니다. 다양한 기능과 속도 향상과 더불어 웹 폰트도 지원하는군요. 파이어폭스 3.1도 웹 폰트를 지원하니 이제 모든 주요 브라우저(IE와 사파리 포함)가 웹 폰트를 지원하게 되었네요.

EOT냐 TTF냐 하는 이슈가 있긴 합니다만, Ajax 등장시절 구글 지도가 그랬던 것처럼 Best Case가 나오면 붐이 일 수도 있지 않을까 싶어요.

관련 읽을거리들

• 오페라10 알파 버전 공개
• Webfonts.info
• For & against standardizing font embedding

단어를 드래그, 더블클릭 등으로 선택하면 선택된 단어를 번역하여 보여주는 북마클릿, 이름하여 inline translator를 만들었습니다. 개인적으로 영문서 읽기 성공률을 올려보고자 만들었는데 생각보다 쓸만한 것 같아 공유해봅니다. :)

Google AJAX Language API를 사용하였고 API 지원하는 모든 언어가 번역되어 보여집니다.

Google 번역 API가 12월 1일부로 폐기된 관계로 Microsoft Translation API로 번역 API가 변경되었습니다.

아래의 링크를 북마크에 추가하신 후 원하시는 페이지에서 실행하여 사용하시면 됩니다. ( IE7 이상과 파이어폭스, 오페라, 사파리 등의 최신 브라우저에서 사용 가능합니다.)

간단 단어 번역

추가: 파이어폭스 애드온

다운로드: Inline Translator 파이어폭스 애드온

아직 정식 애드온으로 등록되지 않은 관계로 로그인 후 받으실 수 있습니다. 정식 애드온이 되었으면 하시는 분들은 리뷰 작성 부탁드립니다. 그런데 영어로 작성하지 않으면 의미가 없다니 고려해주세요. ㅠㅠ 감사합니다. ^^

우리는 자신의 전자 시종에게 억압당하고 있다.

이 책을 우리의 해방을 위해 바친다.

사내의 동료들(웹 클라이언트 개발자들)과 Humane Interface (인간 중심 인터페이스)를 읽기 시작했습니다. 인간-기계 사이의 인터페이스는 무엇보다 인간이 사용하기 편해야한다.라고 이야기하는 이 책은 우리가 일상적으로 사용하고 있는 기계들에 대하여 알고 있는 불편한 점이나 혹은 익숙해져 불편한지 조차 모르는 것들을 끄집어내고 인간중심으로 바꾸어가는 방법과 그러기 위해 인터페이스를 담당하는 사람들이 해야할 것들에 대해 얘기하고 있습니다.

뭐 아직 1장만 읽었을 뿐이라 더 자세히 설명드리기는 부족하네요. ㅎ 아무튼 매우 재미있는 시간들이 될 것 같습니다. 아, 혹시 다른 분들과 책을 함께 읽어보고 있는 분들은 오픈마루 개발자 권남씨의 스터디하는 법을 참고해보세요. 저희도 비슷하게 진행하고 있습니다.

그리고 첫 시간에 생각나는 게 있어 하나 적어봅니다.

은행 자동 입출금기(ATM)에서 출금이 카드 인식, 비밀번호 입력, 출금 금액의 순서로 진행되잖아요?

그런데 제가 비밀번호를 입력했는데 화면이 그대로여서 비밀번호 끝자리 1자리를 빼먹었나 싶어 마지막 1자리를 누르려는데 누르기 직전에 화면이 바뀌어서 출금 금액 중에 제일 큰 70만원을 선택해버렸어요. 그랬더니 이 기계가 바로 그냥 70만원을 주더라고요.

책 읽기 중 어떤 분의 경험담을 들은 것인데 요는 비밀번호 입력 후 입력이 잘 되었고 다음 단계로 진행중이라는 피드백이 적절하게 제공되지 않은 것이다. 그런데 요즘 웹 사이트들을 돌아다니다 보면 이와 같은 피드백이 상당히 불편하다.

웹에서 표현을 담당하는 CSS에는 사용자의 동작에 대한 여러가지 피드백을 제공할 수 있는 기능이 있다. 바로 동적 가상 클래스(dynamic pseudo class)인데 그 종류에는 link, visited, hover, active, focus가 있다.

active와 같은 경우에는 요즘 인터넷 회선 속도가 너무 빨라져 거의 사용되지 않고 있는지 모르겠지만 누구나 게시판 등의 폼 전송 시 진행이 되지 않는 것 같아 전송 버튼을 여러번 클릭해본 경험이 있을 것이다. 물론 페이지가 이동되면서 브라우저 자체적인 피드백이 제공되기는 하지만 Ajax 등의 RIA라면 또 얘기가 달라진다.

나머지 경우들에 대해서도 상당히 간과되거나 미적 요소 정도로 치부되는 경향이 있는 듯 하다. 심지어 focus 되었을 때 브라우저에서 기본적으로 제공되는 테두리 점선이 이쁘지 않다는 이유만으로 없애버리는 경우도 있고…

얘기가 딴데로 새고 반말, 존대말 섞어가며 저부터 이 글을 읽는 분들께 혼란을 드린 듯 합니다. 죄송합니다. (__)

여하튼 책 읽기 들어가는 마당에 많은 것을 느꼈는데 중요한 건 최소한 직접 인간이 사용하게 될 무언가를 만드는 사람으로써 이 분야에 대한 공부는 생각보다 훨씬 중요하다는 겁니다. :)

IE6을 사용하는 사람들에게 캠페인을 할 게 아니라 MS를 들들 볶아야 한다.

아, 제발… 서비스팩도 좋고 뭐도 좋으니… IE7로 자동 업그레이드 좀 시켜주소. 지금 안되고 있는 게 아니라 심각한 보안 문제처럼 적극적으로 푸시해달란 말이오. 웹 사이트 좀 만들어볼라면 IE6 성능문제 때문에 상상의 날개가 부러진 채로 시작하고 있소. 실버라이트도 좋고 혁신도 좋소. 그 전에 기본적인 것 좀 어떻게 안되겠소?

신현석님의 접근성을 해치지 않는 자바스크립트의 사용이라는 글을 읽어보셨는지요? 혹시 어렵고 복잡하다고 생각하실지 모르나 자바스크립트 기술 위에 HTML 표준에 대한 이해가 수반된다면 크게 복잡한 과정이 아닙니다. 웹 사이트 개발에 들어가기 앞서 위의 과정을 이해하고 있다면 접근성을 해치면서(?) 사용하는 자바스크립트와 같은 비용으로 자바스크립트가 불가능한 환경의 접근성, 검색엔진 최적화(SEO) 등의 이득을 챙길 수 있습니다. 접근성을 보장하는 것이 그렇지 않은 것에 비해 추가비용을 필요로 하는 것은 사실이지만 그 추가비용 안에 위의 언급한 이득은 포함되어 있지 않습니다. 즉, 위의 이득들은 꽁짜란 얘기죠. ㅋ 실제로 미투데이라는 서비스의 경우 자바스크립트를 제거한 상태에서도 정확하게 원하는 기능을 사용할 수 있고, 자바스크립트가 이 기능들을 좀 더 편하고 신속하게 이용할 수 있는 보조장치로 쓰인 모습을 볼 수 있습니다.

그 다음엔?

자… 그럼 이렇게 하면 끝일까요? 사실 아닙니다. 그 이유는 말빨이 부족한 제가 설명하는 대신 유명한 웹 접근성 관련 블로그인 456 Berea Street의 Roger Johansson옹의 글 Reading up on WAI-ARIA에서 따왔습니다.

One of the more problematic areas of web accessibility is how to handle the custom widgets and dynamic changes to content used in most web applications and on many content-based websites.

Using JavaScript to add custom behaviour and update content can cause problems for people who rely on assistive technology (AT) such as screen readers. The problems often consist of the AT not being aware that content on the page has changed, the user not noticing that something has changed, or the user being aware that something changed but not what.

웹 접근성에서 상당히 골칫거리인것들 중에 하나가 커스텀 위젯이나 대부분의 웹 어플리케이션이나 많은 컨텐츠 중심 웹 사이트들에서 사용된 컨텐츠의 동적인 변경을 어떻게 다루느냐하는 것이다.

자바스크립트를 사용하여 특정 동작을 추가하고 컨텐츠를 갱신하는 것은 스크린리더와 같은 보조기기에 의지하고 있는 사람들에게 문제를 일으킬 수 있다. 그 문제란 대개 보조기기가 페이지의 컨텐츠가 변경된 것을 감지하지 못하여 사용자가 무엇인가 바뀌었다는 것을 알지 못하거나, 혹은 사용자가 무엇인가 바뀌었다는 것은 알지만 그게 무엇인지는 모르는 문제를 가리킨다.

그래서 나온게 WAI-ARIA입니다. 자, 그러면 당장 적용을 시키면 되나? 그렇습니…다라고 말씀을 드려야 하지만 좀 상황이 편하지만은 않습니다. WAI-ARIA라는 스펙 자체가 초안(Working Draft) 상태라 아직 표준으로 인정할 수 없는 상태이고 국내에서 유명한 스크린리더인 센스리더는 WAI-ARIA의 W자도 찾아볼 수 없습니다. 구현이 전혀 안되어 있다는 얘기죠.

구글리더는 ARIA 기능을 사용할 수 있는 감춰진 링크를 제공하고 있다.

보조기기들도 지원안하는 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 하실 수 있습니다. 마찬가지로 센스리더 등의 보조기기 제작사에서는 구현된 사이트도 없는데 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 할 수 있고요. -_-;;;

둘 중 누가 먼저라는 걸 서로 주장하는 것도 웃깁니다. 오히려 서로 시급히 도입해야 할 판국이죠. 그렇지 않습니까? ^^

지금 당장은?

우여곡절 끝에 접근성을 해치치 않는 자바스크립트를 사용하고 그 위에 WAI-ARIA까지 적용했다고 합시다. 그런데 보조기기들은 아직이라면? 답은 의외로 간단합니다. 보조기기 사용자들이 자바스크립트를 꺼둔 상태로 사이트를 작동할 수 있는 기능(문서 시작점에 이 기능에 대한 링크를 제공한다던지…)을 주면 됩니다. :)

쬐금 공부해본 결과물을 공유합니다. 이미지의 모서리를 둥글게 하는 스크립트 예제입니다. 사용한 이미지가 조금 거시기하니 뭐 드시는 중이시거나 비위가 약한 분들은 조심하세요. -_-;;

원래 animated gif 파일인데 canvas를 사용하면 안되네요. 안되는건지, 제가 방법을 못 찾은건지… 원본이 궁금하신 분들은 원본 이미지를 보셔요. ㅋㅋ

youtube의 동영상을 검색하고 보고 묶고 공유하고 간직할 수 있다. 단지 접속 후 언어를 선택한 후 원하는 동영상을 찾으면 된다. 마우스를 다루는 재미를 느끼다보면 원하던 기능을 익힐 수 있다.

사용자에게 실제로 유용한 부분을 재미있는 UI를 통해 극대화시켰고 그 외에는 아무것도 없다. :)

Juice – Discover. Organize. Share.

동영상, 이미지의 수집, 둘러보기와 웹 사이트를 구경하다가 궁금한 단어를 드래그 & 검색하는 기능을 갖춘 파이어폭스 익스텐션이다. 아래의 설명 동영상을 보면 어떻게 작동되는 녀석인지 쉽게 알 수 있다.

Juice’s rocking webcast from Linkool Labs on Vimeo.

동영상이나 이미지는 마우스를 올리면 나타나는 drag me 버튼을, 텍스트 검색은 선택된 텍스트 혹은 링크를 살짝 드래그했다가 놓으면 수집·검색된다. 굳이 우측에 열려있는 사이드바까지 드래그할 필요도 없다. 그런데 오히려 이 편해 보이는 기능이 쓸데없는 컨텐츠를 수집·검색해버리는 오류를 가지고 있긴 하다.

앗, 겨우 2개네요. -_-a

겨미의 일로 그 어떤 때보다 슬프게 시작한 2008년. 군대 때문에 2년을 비우긴 했지만 2003년부터 몸 담았던 회사도 점점 상황이 좋지 않아 즐겁게 함께 하던 동료들과 헤어지기도 했어요.

전화위복이라고 했던가요? 여름이 다가올 즈음 영광스럽게도 오픈마루의 일원이 되었고 지난 10월 10일에는 혼인신고를 올리게 되었어요. 7달 전 6개월 시한부 선고를 받았던 겨미도 예전같지는 않지만 이쁘게 지내고 있구요. 안정된 가정을 갖게 되었고 행복한 나날을 보내고 있답니다. ^^

생존신고는 여기까집니다. 사실 개인적인 얘기를 공개적으로 주저리 주저리 적어보긴 처음인 것 같습니다. 이 블로그를 처음 시작할 때는 웹과 관련된 이슈와 생각들만을 적고자 마음 먹었었는데 그럴 당위성이 없는 것 같고 얘기꺼리도 너무 부족한 듯 해서 마음을 고쳐먹었습니다. 아무거나 적기로… ㅋ

이제 오픈마루 얘기를 좀 해볼께요.

여름냄새가 조금씩 풍겨올 무렵에 입사를 해서 벌써 5개월이 넘었는데요. 이제 조금씩 적응이 되고 있는 느낌이랄까?

5개월 지났는데 겨우 조금씩 적응되고 있다는 게… 서비스 회사도 처음(사실 정말 처음은 아닙니다만 처음인 느낌)인데다가 후덜덜한 괴수분(?)들께 주눅들기도 하고 누가 밥을 떠먹여주는 것도 아닌데다 밥 숟가락부터 스스로 만들어 부지런히 밥을 떠먹어야 되는 듯한 분위기도 낯설었습니다. 아! 그리고 저 스스로 특별한 능력이라 여기는 부분 – 마크업, CSS, 웹 접근성 – 이 현재 오픈마루에서는 크게 다룰 시점이 아닌 단계라는 점도 있습니다.

부지런히 밥을 떠먹어야 되는 듯한 분위기? 다른 많은 곳에서도 다양한 대안들이 실행되고 있겠지만 오픈마루는 제가 몸에 익었었고 개선시키고자 하는 의지는 가지고 있었지만 헤어나지 못했던 소위 폭포수식 웹 사이트 제작과 정반대의 작업환경입니다. 제가 바라던 이상향과 많은 부분 닮아있죠. 그런데 제 버릇 개 못준다더니 막상 오픈마루식 개발방식을 따라가려니 누군가 어떤 중간물을 전달해주기 전까지 무엇을 해야 하는지, 그 때까지의 목표는 어떻게 설정해야 하는지, 당장 필요없는 기우로 시간을 낭비하고 있지는 않은지 무척이나 혼란스러웠습니다. 지금은 이런 혼란들을 어떻게 이겨내야 하는지에 대한 방법을 조금씩 찾아가고 있는 상태랄까요?

오픈마루 입사 전, 저는 회사의 고객(클라이언트)이 제공하는 정보를 웹 상에서 잘 전달되도록 하는 기술을 연마하고 있었고 그런 일을 해왔습니다. 물론 오픈마루의 서비스들 – 스프링노트, 레몬펜 등 – 처럼 정보의 제공이 아닌 정보의 생산이 주가 되는 웹 사이트도 만든 적이 있습니다만 그 때 팀원들은 기존에 하는 방식 – 정보를 전달하는 방식 – 을 중심으로 생각하고 만들었고 저도 그랬습니다. 그리고 오픈마루에 와서 기존의 생각과는 많이 다른 접근법과 진행방식에 놀랐습니다. 기술적으로는 HTML 중심이 아닌 Javascript 중심, WCAG의 고려가 아닌 WAI-ARIA의 고려를 하는 방식에 대한 이해부족이 뒤따라왔죠. 컨텐츠 중심의 웹 표준 구현, 방탄 Ajax라는 서적에서도 얘기하는 Ajax 애플리케이션의 점진적인 개선법에 대한 아집도 큰 장애물이었습니다. 아이러니하게도 스스로 사내에 이런 식이 아니면 안된다라는 얘기도 하기 전에 스스로 모순에 빠졌었습니다. -_-;

어제 오픈마루가 분당에서 번지르르한 엔씨소프트 본사의 R&D 센터로 이사를 했습니다. (오픈마루의 정식명칭은 엔씨소프트 오픈마루 스튜디오입니다.) 오픈마루라는 조직도 큰 변화를 겪고 있는 시점이고 저도 갓 유부남이 되어 개인적인 변화까지 합쳐 큰 변화를 겪고 있는 듯 합니다. 오픈마루나 저나 멍석은 제대로 깔렸다고 할까요? ㅎㅎ

대회에는 제가 참여하고 있는 하코사 강남스터디에서 3개의 조로 나누어 그 안에서 비티님과 한 조로 참석하였습니다. 웹 표준에 많은 관심을 가진 디자이너이신 아트강님도 함께 참여하려고 했는데 개인적인 사정이 있으셔서 하차하시어 아쉬웠습니다.

각설하고…

참여 작품

디자인

……

상을 받았지만 많이 신경쓰지 못해 부끄러움과 아쉬움이 남는 부분입니다. 그냥 심플하게 만들었어요. (…)

마크업

다음의 것들에 신경을 써서 작성하였습니다.

• 각 페이지에 맞는 keywords, description 메타 정보를 제공
• 영문으로 표기하는 내용에 언어를 구분할 수 있는 마크업(xml:lang, lang 속성)을 부여
• id, class 속성을 의미있는 단어로 구성.
• 라이센스 인식 마이크로포맷(microformat) – <a rel="license">…</a> 사용

다음은 심사결과 감점을 받은 내용들에 대한 변명(?)입니다. ㅋ

h2, h3 단계 부적절

텍스트 아닌 콘텐츠의 인식 페이지를 보면 페이지 좌측의 인식의 용이성이라는 지침명과 페이지 우측의 텍스트 아닌 콘텐츠의 인식이라는 항목명을 모두 h2 요소로 마크업 하였는데 이게 감점 요인이었던 것 같습니다.

제 의도는 이 두 가지를 지침과 항목이라는 상·하 개념이 아닌 내비게이션과 컨텐츠라는 개별적인 문서의 최상위 요소 – 사이트 이름 다음 최상위 요소 – 라고 보았던 것이고요.

저작권 표기에 address 요소 미사용

저작자와 관련된 정보라고 요약되는 address 요소, 저작권이 과연 저작자와 관련된 정보일까요? 무조건 아니라고 생각하진 않지만 그렇다라고 단정할 수는 없는 부분입니다.

저작자의 정보는 웹 페이지의 필수 구성 요소가 아니기 때문에 빠질 수 있습니다. 실제로 Web Standards Project, A List Apart 등의 웹 표준 관련 해외 대표 사이트들에는 address 요소가 사용되지 않았으며 저작권 표기에 address 요소를 사용하지 않은 모습을 보여주고 있습니다.

rel 속성은 a 요소에 사용해야 한다.

이건 확실히 제 실수입니다. 라이센스 인식 마이크로포맷을 실수로 a 요소가 아닌 그 부모 요소인 p 요소에 넣었었답니다. -_-; 덕택에 Markup Validation 오류도 있었군요. ㅋ

CSS

• 기본 스타일시트와 더불어 브라우저의 가로 길이가 좁은 경우를 위한 스타일시트를 포함하여 자바스크립트 등을 이용하여 스타일시트를 동적으로 포함하게끔 하려고 하였으나 시간 관계 상 대체 스타일시트(alternate stylesheet)로만 포함하는 것으로 마쳤습니다.
• wrapper div, li 요소의 첫번째 자식 요소를 위한 클래스명(IE6에서 적용되지 않는 first-child의 대체)을 제외하고 표현을 위한 마크업 – id, class 속성 포함 – 이 없도록 하였습니다.
• 프린트용 스타일시트를 별도로 제작하였습니다.

• min-width 속성을 지원하지 않는 IE6을 위해 Conditional Comments를 통해 min-width와 같은 동작을 하는 IE 전용 속성(expression)을 사용하였습니다.

  이 부분에서 CSS Hack으로 인한 감점이 있었는데 기본 CSS로 구현할 수 없는 부분에 사용된 핵에 대한 감점이 타당한가 하는 의문이 들었습니다. 이 문제를 자바스크립트나 표현을 위한 마크업 등으로 우회하여 해결할 수는 있지만 CSS Hack을 사용한 경우와 크게 다르지 않다는 생각입니다.

• 로고 부분에 IR을 사용하였습니다. 여기에 또 표현을 위한 마크업이 들어갔네요. ^^;

  사용한 방법은 Gilder/Levin Method라고 하는데 이미지가 로드 되지 않았을 경우를 고려한 방법입니다. 그런데 이미지가 로드되지 않는 상황을 고려하지 않았다는 감점 항목이 있었어요. ㅠ_ㅠ 물론 텍스트 확대·축소 시 텍스트 영역을 온전하게 확보하지 못한다는 단점이 있긴 합니다. 그래서 이 정도로… ㅋㅋ

그 외…

미약하게나마 사이트 이용안내 – 우리네 제작자들 사이에서 accessibility.html이라는 고유명사로 통하죠? – 페이지도 만들어보았고, 심플 그 자체로 만든만큼 접근성 지침에 위배됨이 없도록 제작하였습니다.

외부 사이트로의 링크를 할 수 있는 부분을 다 빼먹는 등의 실수도 있었습니다. ^^;

CDK에 감사드리며…

웹 표준 경진대회와 같은 멋진 행사를 만들어주신 CDK와 관계자 여러분께 감사드립니다.

심사결과에 약간 불만이 있는 부분도 적고 했습니다만… 심사해주신 분들, 행사 진행해주신 분들 모두 수고 많으셨고 2회 때는 조금 더 발전된 대회가 되는 마음에 정리해보았습니다.

늦었지만 참가하신 모든 분들, 진행에 참여하신 모든 분들, 대놓고던 마음 속으로던 응원해주신 분들 모두 좀 짱인 듯 합니다. 더 멋진 2회 웹 표준 경진대회를 기약합니다. ^^

| View | Upload your own

IE6의 역사

• Windows와 함께 버전 업.
• Windows 98과 함께 IE5가 거의 쓰이지 않게 됨.
• Windows XP가 쓰이지 않게 되는 시점에 IE6에 대한 지원을 없애게 될 것
• Windows 7의 기본 탑재 브라우저에 귀추가 주목됨

웹 표준의 현재

• 최신 브라우저들에 비해 IE6은 웹 표준의 구현 정도가 상당히 뒤쳐짐.
  • CSS 2.1 지원 부족
  • CSS 3 지원 거의 없음
  • DOM 2, 3 지원 부족
  • HTML 4.01 일부 지원하지 못함(abbr 등)

산 넘어 산, IE7

• 최신 브라우저들에 비해 부족하지만 IE6보다는 나은 IE7
• IE6이 거의 쓰이지 않았을 때 지원해야 할 최고(最古) 브라우저
• Windows Vista에 기본 탑재

우아한 성능저하

• 최신 웹 표준 기술은 현재 자바스크립트로 구현 가능한 것들을 더 짧은 코드로 가볍게 지원할 수 있다.
• 이런 기술들을 지원하지 않는 구 브라우저(IE6, 7 등)는 정보를 얻는데는 불편함이 없지만 디자인은 일부 요소가 표현되지 않는 우아한 성능저하를 도입할 수 있다.
• 전체 사용자들의 사이트 이용비용을 계산했을 때 최소가 되도록 고려.
• IE6 사용자가 과반수인 현재는 아직 무리
• 우리나라 웹 업계의 인식 전환 필요

끊임없는 웹 표준 기술의 발전

• IE6, IE7은 지원하지 않는 SVG, CSS3, HTML5
• 웹 제작자들은 현재 실제로 적용하는 웹 표준 기술 이외에 새로운 기술들을 미리 익혀 시장 변화에 대비해야 한다.

웹 표현 기술의 다음, CSS3

• Firefox, Opera, Safari 등이 점점 지원의 폭을 넓혀가고 있는 CSS3
• 모듈이 세부화되어 W3C에서 표준화를 계속하여 진행중이다.
• IE8은 아직 지원 부족

CSS3, 뭐가 좋을까?

• 표현을 위한 마크업을 걷어낼 수 있다.
• 자바스크립트 등의 외부기술에 의존하지 않은 자체 표현(Native expression) 가능
• RIA의 무분별한 이용 감소

IE6은 아직 살아있지만…

• 곧 시장에서 사라지게 될 것
• IE6에서 사용할 수 없었지만 IE7 등의 브라우저에서는 사용할 수 있는 기술들에 대한 선학습 필요

기능 소개

Wrap Selection, Wrap Selection Each Line은 리스트 마크업 – <ul>, <ol> – 을 작성할 수 있게 해주는 TextMate의 기능이다. 텍스트를 복사해넣은 후 각 줄의 시작과 끝에 <li> 태그를 넣는 수고를 크게 덜어주는 편리한 기능이다.

Aptana에 기능 추가

1. 운영체제에 맞는 스크립트 압축파일을 다운로드 받는다.

   • 윈도우(Windows), 유닉스 계열(Unix, Linux, …)용 Aptana Wrap Selection 스크립트
   • 맥(Mac)용 Aptana Wrap Selection 스크립트
2. scripts 혹은 monkey라는 이름으로 존재하는 프로젝트 중 하나의 최상위에 폴더를 만들고 다운 받은 스크립트 파일들을 이동시킨다.

기능 시험해보기

맥의 경우 Command + Ctrl + W 키 조합이 선택한 텍스트 전체를 하나의 태그로 감싸는 기능이고, Command + Ctrl + Shift + W 키 조합이 선택한 텍스트의 각 줄을 지정한 태그로 감싸는 기능이다. 맥이 아닐 경우 Command 키 대신 Alt 키를 조합하면 된다.

1. 
   몇 줄의 텍스트를 준비한다.

2. 
   Command(or Alt) + Ctrl + Shift + W 키 – Wrap Selection Each Line – 를 누른다.

3. 
   기본으로 설정되어 있는 li 태그를 확인 후 엔터를 누른 후 각 줄이 li 태그로 쌓인 것을 확인

4. 
   Command(or Alt) + Ctrl + W 키 – Wrap Selection – 를 누른다.

5. 
   기본으로 설정되어 있는 ul 태그를 확인 후 엔터를 누른 후 전체가 ul 태그로 쌓인 것을 확인

스크립트 추가하기

Aptana를 좀 더 강력하게 해주는 Eclipse Monkey Script는 간단하게 작성하고 추가할 수 있다. Aptana 홈페이지의 Eclipse Monkey 관련 페이지 혹은 필자가 작성한 스크립트를 보면 자바 스크립트를 조금 다뤄본 사람이면 어렵지 않게 자신이 원하는 기능을 추가할 수 있을 것이다.

파이어폭스 3.1의 CSS 지원

2008년 안에 출시될 것으로 알려진 파이어폭스 3.1은 앞서 언급한 CSS 지원의 아쉬움을 많이 해결해줄 것임을 약속하고 있다. 모질라의 Platform/Post1.9Planning 문서를 보면 파이어폭스 3.1에서 새로 지원할 웹 표준 기술들 – 문서 내 1.9.next – 에 대해 정리되어 있는데 아쉬웠던 것들 중 상당수에 대해 지원할 것임을 명시하고 있다.

Downloadable Web Fonts (@font-face)

드디어 파이어폭스에도 웹 폰트를 사용할 수 있게 된다. 웹 폰트 지원을 제일 먼저 주장했던 오페라는 아직도 소식이 없는 게 이상하지만, 10에는 추가되지 않을까? 드디어 IE에는 EOT, 나머지에는 TTF로 쓸 데 없는 img 요소를 제거할 날이 온 걸까? IE의 알리아싱 관련 문제가 걸림돌이겠지만…

text-shadow

text-shadow는 웹 폰트 없이 우리나라의 웹 사이트들에는 별로 유용한 속성은 아니지만… 지금은 사용할 수 없겠지만… – IE, IE, IE…!! 아무튼 IE만 남게 되었다. – 난 이게 큰 의미를 가진다고 생각한다.

@media queries

자바스크립트 없이 CSS가 사용자들을 조금 더 구체적으로 파악할 수 있게 해주는 @media queries도 이제 IE만 남았다.

그 다음, 파이어폭스 4는?

파이어폭스 4 – 모질라 2 – 에는 Webkit이 제안한 CSS Animations and Transition, calculated values가 예고되고 있다. 현재 자바스크립트와 DOM이 복잡하게 지지고 볶고 있는 RIA 어플리케이션이 좀 더 간단해지고 완성도 높아지고 고품격이 될 수 있다는 것이다!!

그 밖에…

HTML5의 audio와 video 요소, SVG fonts - background-image에 사용될 수 있어야 크게 와닿을 것이라고 생각되는데 그게 빠졌다! – 등 많은 유용한 향상이 예고되고 있다. Multiple Backgrounds의 언급이 없는 것은 꽤나 아쉬운 부분이지만…

참고 문서

• Platform/Post1.9Planning – MozillaWiki
• David Baron’s weblog: Some new CSS features in Firefox 3
• New features in Firefox 3.1 & beyond
• Mozilla to release Firefox 3.1 this year

정보를 꾸며주기 위한 <img> 태그

<img> 태그는 사전적으로는 정보를 지닌 – 의미 있는 – 시각 요소를 문서에 삽입하기 위한 태그이지만, 앞서 언급한 표현의 제약으로 인해 폰트 등을 원하는 대로 표현하기 위한 용도로 사용하기도 하다. 예전부터 – 대다수의 웹 제작자들이 마크업을 표현을 위한 용도로 사용하던 시절부터 – 국내의 거의 모든 사이트들이 사용하는 방법이기도 하다.

문제점

우선 <img> 태그의 남용이 마크업의 의미를 떨어뜨린다. 단순 텍스트와 <img> 태그는 기본적으로 의미하는 바가 다르다. 이미지 검색엔진의 결과물로 나타나는 수많은 텍스트 꾸밈용 이미지들을 보면 <img> 태그의 남용이 잘못된 마크업이라는 생각을 할 수 있다.

또, 남용된 <img> 태그는 구조와 표현의 분리라는 CSS의 목적을 달성하는 데 장애물이 된다. 마크업에 박혀있는 특정 시각 디자인 결과물을 위한 <img> 태그들은 다양한 표현의 걸림돌이다. <img> 태그가 남용된 사이트에서 프린트를 위한 CSS를 제작한다면 그 결과물은 어쩔 수 없이 스크린의 그것에서 크게 달라질 수 없을 것이다. 스크린 디자인을 위해 사용된 <img> 태그의 모양새는 바꾸기가 어렵기 때문이다.

CSS를 이용한 이미지 대치법(Image Replacement)

문제점

앞서 언급한것처럼 <img> 태그는 많은 문제점이 있지만 CSS를 이용한 이미지 대치법 역시 많은 문제를 가지고 있다. 가장 대표적으로 대다수의 이미지 대치법이 텍스트를 숨기거나(display: none;) 화면 밖으로 위치시키는 방법(text-indent: -999em;)을 사용하기 때문에 CSS 활성화·이미지 비활성화 상태에서 화면 상에 아무것도 출력하지 못하며 이 방법을 프린트용 CSS에 동일하게 적용하였을 때 보통의 웹 브라우저들이 기본적으로 배경 이미지를 출력하지 않기 때문에 백지 상태의 인쇄물을 보게되는 경우가 생긴다. (<img> 태그 사용시에는 사용자가 의도하지 않은 사이에 프린터의 잉크나 토너가 낭비된다!)

약간의 해결책

CSS 활성화·이미지 비활성화 상태의 경우 Gilder/Levin의 방법이나 Gilder Levin Ryznar Jacoubsen의 방법을 통해 해결할 수 있다. 하지만 이 방법은 이미지 뒤에 가려진 텍스트가 표시될 수 있는 충분한 공간이 확보되지 않으면 무용지물이 될 수 있다. z-index를 이용한 이미지 대치법도 하나의 방법인데 대치할 요소의 부모 요소에 배경색이 들어가있거나 한 경우에 문제가 생길 수 있다. 그리고 앞의 방법들과 마찬가지로 텍스트의 공간에 대한 문제가 있다. 그리고 이 모든 방법들은 의미없는 추가적인 마크업을 필요로 한다.

프린트 시의 문제는? 프린트용 CSS를 별도로 제작하면 바로 해결된다. 설마 로고와 메뉴가 덕지덕지 붙은 화면을 사용자에게 그대로 출력시키게 하는 것을 그냥 지켜보고 있다면 바로 당신이 관리하는 사이트에 프린트용 CSS를 추가하라.

어떤 것을 선택하느냐?

<img> 태그, 이미지 대치법(Image Replace). 이 방법들 중 어떤 것도 완벽하지 않다. 다만 각 방법들이 서로 다른 문제를 가지고 있고 어떤 것을 선택하느냐에 앞서 이 방법들의 문제점들에 대해 이해한 후에 선택하는 것이 필요하다.

Web Fonts

간략한 배경

웹 폰트는 상당히 오래된 기술입니다. 브라우저 전쟁 시절 IE와 넷스케이프가 각자의 독자적인 기술로 사용했고 IE에는 그 때의 웹 폰트가 아직도 남아있습니다. 그런 과정에서 MS는 웹 폰트에 대한 표준 제정을 제안했고 현재 CSS3의 한 부분이 되었습니다.

진행상황

오페라의 CTO인 Håkon Wium Lie가 A List Apart에 기고한 CSS @ Ten: The Next Big Thing이 웹 브라우저에서의 웹 폰트 지원과 그 필요성에 대해 설명하였고 현재 사파리 3.1 버전이 이를 지원하고 있습니다. 오페라는 아직 지원하지 않습니다만, 정황 상 곧 지원하겠죠?

파이어폭스의 경우 버그질라의 글을 통해 지켜보고 있습니다만, 파이어폭스3의 일정에는 웹 폰트의 지원이 빠져있습니다. 그러나 브레인 스토밍에 언급된 것은 고무적인 일이고 곧 추가될 것이라는 기대를 갖게 하는군요.

IE의 경우 현재 출시된 IE8 베타에서도 Embedded OpenType만을 지원하고 있습니다. 늘 그렇듯 앞으로의 판도를 예상할 수 있는 정보를 찾을 수 없었죠.

몇 개의 테스트

CSS @ Ten: The Next Big Thing에서 쓰인 예제 중 한 개를 사파리 3.1을 통해 보았습니다. 트루타입 폰트를 사용한 예제입니다. 그리고 해당 트루타입 폰트들을 Embedded OpenType으로 변환 후 IE에서 실험해보았습니다.

제법 비슷합니다. 하지만 다릅니다.

다음으로 HY견명조라는 한글 폰트를 본 블로그에 포함시켜서 테스트 해보았습니다. IE에서는 위와 마찬가지로 변환 후 테스트 하였습니다.

XP와 비스타의 윈도우의 폰트 렌더링 기술인 클리어 타입을 적용한 결과입니다. IE에서 사용할 수 없을만큼 투박하게 표시됩니다. 운영체제의 문제라고 생각됩니다만 결론은 비스타의 IE에서도 웹 폰트용으로 특수하게 가공되지 않은 폰트들은 사용할 수 없다는 것입니다. 그다지 좋은 결과는 아니군요. 제가 폰트에 관한 지식이 부족한 관계로 테스트를 잘못 수행한 것은 아닌지 약간은 염려됩니다. 혹시 그런 부분이 있으면 지적 부탁드립니다.

결론

애석하게도 CSS3의 웹 폰트 모듈은 마지막 업데이트가 6년전(2002년)이었고 아직도 Working Draft 상태입니다. 또한 IE는 Embedded OpenType만을 지원하고 있으며, 폰트의 렌더링 또한 우리가 원하는 모양새가 아닙니다.

오페라 진영의 제안과 사파리의 지원이 있었지만 IE와 파이어폭스에서 매끄럽게 사용할 수 있기 전까지는 마냥 기다릴 수 밖에 없을 것 같습니다.

대안을 통한 조금 나은 결론

True Font Family에서는 웹 폰트 속성을 대체하는 자바스크립트 라이브러리를 제공하고 있습니다. 자세히 살펴보지는 않았지만 웹 폰트가 점점 정착되어 가는 동안 하위 호환성을 보장할 수 있는 대안이 될 수 있을 것 같습니다. 국내에서는 우리글닷컴이 확대·축소 가능한 웹 폰트를 제공하고 있습니다. 윈도우에서 깨져보이지 않도록 가공된 폰트이죠. (싸이월드나 네이버 등에서 사용하는 가독성 떨어지는 고정 사이즈의 비트맵 웹 폰트랑은 많이 다릅니다.)

조만간 마크업에서 텍스트를 미려하게 표현하기 위한 <img> 태그를 곧 거둬낼 수 있지 않을까 하는 기대를 해봅니다.

IE6, 7에 대해서는 display:inline-block; 과 같은 효과를 내게 합니다. ( inline-block 이 지정된 요소에도 vertical-align 이 유효하게 됩니다.)

div.sample1 div{
    display:table-cell;
    width:100px;
    vertical-align:middle;
}

* html div.sample1 div{ /* IE 6 */
    display:inline;
    zoom:1;
}

*:first-child+html div.sample1 div{ /* IE 7 */
    display:inline;
    zoom:1;
}

IE에 display: inline; 부여 후 zoom 속성을 통해 레이아웃 요소로 만듦으로서 inline-block 의 효과를 만드는 것이 핵심입니다. display: table-cell; 이 적용되지 않은 블럭 요소는 세로 중앙 정렬이 되지 않고 inline 이 적용된 요소는 세로 중앙 정렬이 되는 차이를 미묘하게 이용한 것이지요.

지원 브라우저

yomotsu님의 글에서 발췌한 내용입니다.

• 파이어폭스 1, 2
• 넷스케이프 6, 7.1
• 사파리 2, 3
• 오페라 9.2 이상
• IE 5.01, 5.5, 6, 7 ( inline-block 으로 구현 )

제약사항

이 방법의 제약사항은 인라인 요소의 세로 중앙 정렬은 다른 인라인 요소의 최대값에 영향을 받는다는 것입니다. 이것은 가로 너비를 갖지 않는 – 공간을 차지하지 않는 것처럼 보이는 – 마크업을 삽입하여 해결할 수 있습니다. 당신이 시맨틱 마크업 신봉자라면 IE Conditional Comments 필터링이나 자바스크립트와 DOM을 통해 의미없는 마크업을 삽입할 수 있겠습니다. 이마저도 싫다면… 글쎄요. ㅠㅠ

또 한가지가 IE를 위해 사용하는 핵입니다. IE7 구분을 위해 사용되어 온 핵 *:first-child+html이 현재의 IE8 – 베타 (8.0.6001) 버전 – 에도 적용되고 있고 IE8은 display: table-cell;을 지원하고 이전 버전과 달리 레이아웃(hasLayout)이 사라졌기 때문에 yomotsu님이 사용한 IE용 핵과는 다른 방법 - 예를 들어 IE Conditional Comments 필터링 – 으로 적용하기를 추천합니다. 아래 예제에는 IE Conditional Comments 필터링을 사용하였습니다.

IE7 이하에서 세로 중앙 정렬할 요소가 차지하는 영역이 다른 최신 브라우저들과 다를 수 있습니다. 이미지와 텍스트가 나란히 출력되는 예제에서 텍스트에 배경색이 부여된 영역을 비교해보세요.

몇가지 예제

• 이미지와 텍스트가 나란히 출력되는 예제
• 텍스트를 높이가 지정된 블럭요소의 세로 중앙에 위치시키는 예제

참고 URL

• Position browse
• 이미지 등의 옆에 있는 텍스트를 상하중앙으로 배치하기
• Display
• hasLayout 속성과 홀리 핵(Holly hack)
• Vertical Centering With CSS: 이 글에서 다루지 않은 다른 여러가지 방법에 대한 소개. 괜찮은 방법이 많다.

Multiple Backgrounds

라운딩된 가로와 세로 길이가 유동적인 박스 제작해보신 경험이 있으신가요? 이 박스를 CSS2의 Background 속성만으로 제작하려면 많은 고통이 따릅니다. 예를 들어 어떤 <div> 태그로 마크업한 박스를 앞에 쓴 것과 같이 만들려면 추가로 의미없는 마크업을 잔뜩 집어넣거나 자바스크립트를 사용해야 합니다. – 이 경우에도 자바스크립트가 의미없는 마크업을 집어넣는 것은 마찬가지입니다. 대체로 다음과 같은 형식의 마크업이 필요합니다.

<style type="text/css">
div { background: url("left-top.png") no-repeat left top; }
div div { background: url("right-top.png") no-repeat right top; }
div div div { background: url("left-bottom.png") no-repeat left bottom; }
div div div div { background: url("right-bottom.png") no-repeat right bottom; }
</style>

<div>
    <div>
        <div>
            <div>내용</div>
        </div>
    </div>
</div>

이게 뭡니까? (ㅠㅠ)

Multiple Backgrounds가 지원되면 하나의 <div> 태그만으로도 이것을 지원할 수 있습니다. 아무리 복잡한 박스라도 말이죠. 배경 이미지를 몇 십개도 깔 수 있으니까요(실제로 몇 십개를 만들면 안되겠지만요.;;).

<style type="text/css">
div {
    background:
        url("left-top.png") no-repeat left top,
        url("right-top.png") no-repeat right top,
        url("left-bottom.png") no-repeat left bottom,
        url("right-bottom.png") no-repeat right bottom;
}
</style>

<div>내용</div>

아, 얼마나 간결하고 아름다운 코드입니까?

그럼 현재 브라우저들의 Multiple Backgrounds 지원 현황을 알아볼까요?

IE (인터넷 익스플로러)

IE8의 CSS3 지원은 다른 최신 브라우저들에 비해 상당히 열악합니다. CSS Improvements in Internet Explorer 8에서도, IEBlog에서도 언제 지원하겠다는 내용은 찾을 수 없었습니다.

파이어폭스

파이어폭스 개발의 핵심 인물 중 하나인 David Baron은 Multiple Backgrounds에 관해 다른 견해를 가지고 있는 것 같습니다. 좀 난감하지요.

처음 글 쓸 때에서 상당히 많은 변화가 있었습니다. 결국 David Baron이 Multiple Backgrounds를 지원하기로 결정하였고 현재의 Nightly Build인 3.2pre1에서는 실제로 동작합니다.

오페라

오페라는 아마 곧 Multiple Backgrounds를 지원하리라 생각합니다. 오페라의 개발자 David Storey의 글 Selectors complete, what next?에서 짐작해볼 수 있었습니다.

사파리

이미 지원합니다. 2005년부터요. :D

슬픈 얘기지만 아마도 IE8에 추가되지는 못할 것 같습니다. 파이어폭스의 경우 David Baron의 결정이 나면 바로 추가되지 않을까 하고요. 결국 IE9일까요? IE9라면 4~5년 정도만 삽질하면 되는 걸까요? 하하하;; 그래도 IE9에서라도 추가된다면 3년쯤 후에는 기본적으로 Multiple Backgrounds를 사용하여 마크업을 구성하고 IE8 같은 하위 브라우저를 위해 자바스크립트로 의미없는 마크업을 추가하는 라이브러리를 사용할 수 있겠네요. 이거 뭐 기뻐해야 하는건지 슬퍼해야 하는건지 모르겠습니다.

다음 글에 Web Fonts에 관한 내용이 이어집니다. 기대해주세요. :D

IE8은 Acid2 테스트를 통과하였다. 그러나 Acid3 테스트에서는 겨우 17점이라는 초라한 성적표를 보여주었다. 파이어폭스3 베타가 각 버전마다 4점, 8점의 향상을 보여준 것과 대조적으로 IE8은 IE7에서 겨우 3점 오른 것이 전부였다. MS 제품군이 그러하듯 IE8도 파이어폭스3 베타와 같은 계속적인 향상을 보여주기는 힘들지 않을까 생각된다.

파이어폭스3 베타 4의 Acid3 테스트 점수 67점은 오페라 9.50 베타 1의 점수 60점을 뛰어넘었다. 흐뭇한 마음으로 파이어폭스3 베타의 웹 표준 지원 노력이 어디까지 계속될지 지켜보아야겠다. 마음 속으로나마 열렬히 응원한다!