Category Archives: JavaScript

탭을 헤딩으로 탭 내용을 헤딩에 이어지는 컨텐츠로 구성한 마크업을 위한 jQuery plugin, flowTab

WAI-ARIA의 tab, 아직 사용하긴 이르다. 라는 글을 썼었는데, 탭을 헤딩으로 탭 내용을 헤딩에 이어지는 컨텐츠로 구성한 마크업을 위한 자바스크립트 라이브러리는 찾기가 어려워 하나 만들었다. 이름하여 flowTab. (기본적으로 자연스럽게 흐르는 컨텐츠를 탭 UI로 만든다 하여 이렇게 지었다.)

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

<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

view on Github.

WAI-ARIA의 tab, 아직 사용하긴 이르다.

WAI-ARIA에는 다양한 위젯 – 여기서 위젯이란 tab, dialog, alert 등을 말한다. – 이 있는데 그 중 tab은 아직 조금 문제가 많은 것 같다.

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>
[코드1] 탭이 목록형태로 마크업되고 각각 탭 내용으로 연결되도록 구성한 마크업
<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>
[코드2] 탭을 헤딩으로, 탭 내용을 헤딩에 이어지는 컨텐츠로 구성한 마크업

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

코드1의 키보드 이동 순서

[그림1] 코드1의 키보드 이동 순서는 1번탭 → 2번탭 → … → 마지막 탭 → 선택된 탭 내용 순이다.

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

코드2의 키보드 이동 순서

[그림2] 코드2의 키보드 이동 순서는 1번탭 → 1번탭 내용 → 2번탭 → 2번탭 내용 → …

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

WAI-ARIA의 Live Region

이 글은 아래의 두 문서 내용의 요약 정리본이다.

이 글을 통해 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-relevant: (aria-relevant=[LIST_OF_CHANGES])
live region이 변경될 때 보조기기로 하여금 어떤 변경을 주시하도록 할 것인가를 설정한다. 여기서의 변경은 의미있는 변경 – 예를 들어, 온라인 친구목록에서 친구 리스트 한개가 없어졌다면 이는 친구가 오프라인이 되었다는 의미 – 가능한 설정들은 “additions/removals/text/all“이고 기본값은 “additions text“.

설정값

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

설정값

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

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 구현 방법으로 링크가 걸려있어야 할 것 같은데 아직 스펙의 링크들이 정돈되지 않아보이네요.

참고 링크

IE 자바스크립트 속도튜닝 계의 혁명(?), dynaTrace

dynaTrace는 웹 페이지의 서버 실행 시간, 페이지 렌더링 시간은 물론 자바스크립트 한 줄의 걸린시간까지 볼 수 있는 툴이다. 얼마전 자바스크립트의 실행속도 때문에 시름시름 앓다가 지인의 소개로 이 툴을 알게 된 후로 그런 고민들이 싹 사라졌다.

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

암튼 좀 짱임.

IE6에서 안되는 CSS Selector, IE7 라이브러리

찬명님의 글에서도 알 수 있듯 IE6에서는 CSS multiple selector도 적용되지 않는데다가 child selector도 적용되지 않습니다.

아래와 같이 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 라이브러리를 뜯어보았던 자세한 소감을 말씀드리지요. -_-;;

간단 단어 번역 북마클릿, inline translator

실시간 단어 번역 북마클릿 실행화면

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

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

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

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

간단 단어 번역

추가: 파이어폭스 애드온

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

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

접근성을 해치지 않는 자바스크립트의 사용, 그 다음엔?

접근성을 해치지 않는 자바스크립트의 사용

신현석님의 접근성을 해치지 않는 자바스크립트의 사용이라는 글을 읽어보셨는지요? 혹시 어렵고 복잡하다고 생각하실지 모르나 자바스크립트 기술 위에 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까지 적용했다고 합시다. 그런데 보조기기들은 아직이라면? 답은 의외로 간단합니다. 보조기기 사용자들이 자바스크립트를 꺼둔 상태로 사이트를 작동할 수 있는 기능(문서 시작점에 이 기능에 대한 링크를 제공한다던지…)을 주면 됩니다. :)

canvas와 VML을 통해 이미지를 둥글게…

요즘 웹에서 벡터 그래픽을 표현하는 방법에 대한 관심이 생겨 canvas, SVG, VML 등을 살펴보고 있습니다. SVG라는 표준이 있고 HTML5에는 canvas 요소가 기본적으로 들어가는데 일단 IE 때문에 표준으로 짜자잔이라던지 CSS background로 벡터 그래픽을 사용한다던지 하는 신나는 일은 나~중에나 될 것 같습니다만 자바스크립트를 통해 IR처럼 구현하는 건 가능할 것 같습니다. 컨텐츠를 HTML로 기본적으로 마크업한 뒤 자바스크립트로 갈아치우는거죠.

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

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

계속되는 파이어폭스3 베타의 노력

우연히 Acid Test Results on Popular Browsers라는 글을 보게 되었는데 최신 브라우저들의 Acid3 테스트의 점수를 볼 수 있었다. 놀라운 것은 파이어폭스3 베타의 점수였다. 베타 2는 55점, 베타 3는 59점을 기록한 것이다. 호기심에 베타 4를 테스트 해보니 무려 67점을 기록하였다.

파이어폭스3 베타 4의 Acid3 테스트: 67점

파이어폭스3 베타 3의 Acid3 테스트: 59점

파이어폭스3 베타 2의 Acid3 테스트: 55점

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

IE8 베타의 Acid3 테스트: 17점

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

새로운 웹 표준 테스트, Acid3

최근 IE8이 Acid2 테스트를 통과했다고 해서 웹 표준 진영이 크게 고무된 바 있다. 그런데 HTML5의 리더인 이안 힉슨(Ian Hickson)이 또 웹 브라우저 제작자에게 또 시련을 주려나 보다. 바로 Acid3 테스트이다.


Acid3을 100% 통과한 웹 브라우저의 화면 스크린샷

Ian Hickson has been working hard on the acid3 test. The new test will focus mostly on ECMAScript and Dom through Selectors Level3, Media queries and data URIs. The new acid3 test isn’t quite ready yet but it should become ready within the coming months.

dustin brewerDevelopers are working on ACID3 test이라는 글에 따르면 새로운 Acid3 테스트는 ECMAScriptDOM3, CSS3의 Media Queries, data URIs에 초점을 둔 것이라고 한다. Acid2 테스트가 나온지 3년 가까이 지난만큼 그 동안 나온 새로운 웹 표준 기술들에 대한 검증의 필요성이 대두되어 Acid3 테스트가 작성중인 듯 하다.

글을 쓰며 IE8의 Acid2 테스트 통과에 환호하는 현실이 조금 씁쓸한 기분이 든다. 하지만 IE 역시 웹 표준을 적극 수용하려는 자세를 보이고 있는 만큼 Acid3 테스트는 Acid2의 그것보다 훨씬 빠르게 웹 브라우저에 반영될 것으로 기대한다.

아래는 재미로 최신 웹 브라우저들의 Acid3 테스트를 해본 결과이다. IE8의 점수가 궁금해진다. Acid3 테스트는 아직 완료된 테스트가 아니므로 참고만 하자.

웹 브라우저 테스트 점수
Internet Explorer 6 0%
Internet Explorer 7 0%
Firefox 2.0.0.11 60%
Firefox 3.0b2 63%
Safari 3.0.4 50%
Opera 9.25 56%

Miya Validator 0.2 버전 출시.

Miya Validator에 몇가지 기능을 추가하여 0.2 버전을 공식배포합니다.

변경 사항

MiyaValidator 클래스add 함수
addGroup 함수의 리턴값이 변경되었습니다. 특별히 폼 유효성 검사 외에 다른 작업을 하지 않으셨다면 사용상 변화된 점은 없습니다.

add 함수의 리턴값
MiyaCondition의 instance에서 MiyaValidator의 conditions 변수의 해당 index값으로 변경
addGroup 함수의 리턴값
MiyaGroupCondition의 instance에서 MiyaValidator의 groupConditions 변수의 해당 index값으로 변경

추가 기능

fileonly 속성 추가

첨부파일의 확장자를 제한합니다. 이미지파일의 확장자를 검사하는 imageonly 속성과는 별도로
업로드 가능한 첨부파일의 확장자를 직접 선언할 수 있는 속성입니다. 다음과 같은 방식으로 사용하실 수 있도록 구현됩니다.

var v = new MiyaValidator(form);

v.add("somefile", {
fileonly: ["hwp", "doc", "xls", "ppt"],
message: "아래아 한글 또는 MS 오피스의 문서 파일만 업로드 하실 수 있습니다."
});

trim 속성 추가

입력값의 공백을 제거 후 검사할 수 있는 속성입니다. 공백 제거 방법에 따라 다음과 같은 값을
입력할 수 있습니다. 입력값은 trim 속성에 따라 공백이 제거된 후 검사되지만 실제 사용자의
입력값은 그대로 유지되며 전송시에도 공백이 사용자가 입력한 상태대로 전송됩니다.

"trim" 또는 true
입력값의 시작부분과 끝부분의 공백을 제거합니다.
"ltrim"
입력값의 시작부분의 공백을 제거합니다.
"rtrim"
입력값의 끝부분의 공백을 제거합니다.
"compress"
입력값의 모든 공백을 제거합니다.

minlength 속성 추가

HTML4의 maxlength의 반대개념으로 최소 글자수를 설정합니다.

min/max 속성 추가

입력된 값의 최소/최대값을 정의합니다. 값은 반드시 숫자로 입력되어야 합니다.

법인번호(jurino) 형식(MiyaFormat) 추가

오류 수정

requiremax 속성의 메시지 오류 수정

에러 메시지의 오류를 수정하였습니다. 프로그램 동작에 영향을 미치는 부분이 아니기 때문에 0.1 버전에도 수정 반영되었습니다.
{requiremax}개 이상이하의 항목이 입력되어야 합니다.

Special Thanks To

0.2 버전의 모든 기능을 제안해주신 RedCat Caravan님께 진심으로 감사드립니다.

겸손한 자바스크립트의 기본

겸손한 자바스크립트의
사전적인 의미는 문서(HTML)와 동작(자바스크립트)를
분리하는 것이지만, 그 이전에

기본은 자바스크립트를 사용하는 모든 경우에 대해 사용 가능한 경우와 가능하지 않은 경우를 염두하여 설계하는 것이다.

웹 페이지를 제작하면서 자바스크립트를 어떤 부분에 사용해야겠다라고 마음 먹으면
우리는 자바스크립트를 표시하는 <script> 태그를 쓴다.
앞서 얘기한 설계대로 <script> 태그의 사용 가능하지 않은 경우를 위해 <noscript> 태그를 쓸 수 있다.
어플리케이션 레벨이 아닌 마크업이 잘 되어 정상적인 기능을 하는
HTML 문서에 부가적인 사용자 편의성의 증대를 목적으로
사용하는 자바스크립트라면 <script> 태그가 동작하지 않을 경우
자바스크립트가 없는 HTML 문서와 같이 작동하게 되므로
굳이 <noscript> 태그가 필요하지 않을 것이다.

다음의 두 코드를 보자. 직업을 입력하지 않았을 때 오류메시지를 표시하는 스크립트를 삽입한 폼이다.

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <a href="javascript:checkForm();">전송</a>
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
function checkForm() {
    var form = document.getElementById("f");
    if (form.elements["job"].value == "") {
        alert("직업을 입력해주세요.&quot);
    } else {
        form.submit();
    };
};
// ]]>
</script>
<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <input type="submit" value="전송" />
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
if (document.getElementById && document.getElementById("f")) {
    var form = document.getElementById("f");
    form.onsubmit = function() {
        if (this.elements["job"].value == "") {
            alert("직업을 입력해주세요.&quot);
            return false;
        };
    };
};
// ]]>
</script>

전자는 자바스크립트를 제거하였을 때 아무런 동작을 하지 않는 예제이고
후자는 HTML에 선언된 링크로 이동할 수 있는 예제이다.
어떤 코드를 작성하던 비슷한 시간이 소요되겠지만 – 학습에 필요한 시간은 제외한다. -
전자의 경우 문서의 가치가 훨씬 떨어진다.

모든 사용자가 당신의 자바스크립트 코드를 실행할 수 있을 것이라고 기대하지 말아야 한다.
또, 어떤 사용자는 당신의 자바스크립트 코드 중 어떤 부분을 제대로 해석하지 못한다는 것을 알아야 한다.

자바스크립트는 플래시, ActiveX와 같은 외부 플러그인과 개념 상 다르지 않다.
오히려 언급한 것처럼 사용자에 따라 불완전하게 실행될 가능성이 있기 때문에 더 다루기 어려운 기술임을 인식하여야 한다.

참고 링크

마지막 업데이트: 2008년 4월 25일 04시 30분

진정 어플리케이션 같은 웹어플리케이션, QOOXDOO!

요즈음 웹이 데스크탑 어플리케이션을 흉내내기 시작하다가 어느샌가 데스크탑 어플리케이션의 한계를 뛰어넘은 모습을 자주 보게 된다. 2005년 구글 맵스에 열광하던 시절은 추억거리가 되었고, 2007년 현재에는 다양한 양질의 웹어플리케이션이 우열을 다투고 있다. 오늘 소개할 QOOXDOO는 쉬운 웹어플리케이션 제작을 위한 자바스크립트 프레임워크의 하나이다.

Java의 Interface와 Ruby의 Mixin 개념을 도입한 OO 방식의 프레임워크인 QOOXDOO는 또한 기본적인 UI를 자체 제공하며 관련 아이콘들이 SDK에 포함되어 있다.

한글로 된 QOOXDOO에 관한 정보가 거의 없는 관계로 개발에 조금은 어려움이 있지만, 앞으로 중·소 사이트 제작 간 관리자 툴로서 활용할 목적으로 여러 프레임워크 중 QOOXDOO를 선택하게 되었는데 아직은 목적 달성까지 남은 일이 많은 관계로 구체적인 적용사례나 노하우는 기회가 되면 다시 소개하기로 하겠다. (써보시거나 관련 정보를 보신 적 있으신 분들, 알려줘용!! ㅠㅠ)

QOOXDOO 관련 링크

내 브라우저에 X-Ray를 달자.

X-Ray :: for web developers v0.91a

웹 개발 간 브라우저의 어떤 개체(element)의 상세정보를 알고 싶다면 X-Ray를 이용 해 보자. 단순히 북마크에 X-Ray 스크립트를 넣고 원하는 페이지에서 북마크를 호출하여 주는 것만으로 준비는 끝이다!

X-Ray (북마크 해 주세요!)

XRAY라는 타이틀을 가진 조그마한 레이어가 나타난다. 이제 상세정보를 알고 싶은 어떤 개체(element)를 클릭하면, id, class, position, border, margin, padding 등의 정보를 얻을 수 있다. 그리고 개체(element)가 속한 HTML의 구조가 표시되는데 부모 개체(element) 태그명을 클릭하면 해당 상세정보를 얻을 수 있다.

X-Ray 예제X-Ray 예제

X-Ray를 끄고 싶다면 x 버튼을 클릭하거나 브라우저를 새로고침하면 끝이다.

웹디자이너나 퍼블리셔, 자바스크립트 개발자들에게 상당히 유용한 툴이 될 듯 하다. 이번 버전에서 IE6 이상에 대한 지원이 추가되었다고 하니 IE의 렌더링 오류 수정에도 크게 도움이 될 것 같다. 스크린샷을 찍고 그래픽 툴에서 붙여서 확대해서 픽셀 재는 수고를 좀 덜어주지 않을까? :)

소위 히든폼이라 불리는 HTML의 오용

페이징 기능을 포함한 게시물 리스트 화면이나 Breadcrumb 구조 등 다수의 공통적인 파라미터를 가지고 다녀야 하는 경우가 있다. 이 경우에 쓰이는 방법이 여러가지가 있는데 일반적으로 서버 사이드 스크립트를 통해 공통적인 파라미터를 묶어서 여러 개의 관련 링크에서 일관적으로 적용하도록 하는 방법이다. 그런데 다음과 같은 HTML 코드를 만들어내는 경우가 있다. (common1~3을 공통적인 파라미터라고 가정한 게시물 보기 화면) Breadcrumb 구조 등 다수의 공통적인 파라미터를 가지고 다녀야 하는 경우가 있다. 이 경우에 쓰이는 방법이 여러가지가 있는데 일반적으로 서버 사이드 스크립트를 통해 공통적인 파라미터를 묶어서 여러 개의 관련 링크에서 일관적으로 적용하도록 하는 방법이다. 그런데 다음과 같은 HTML 코드를 만들어내는 경우가 있다. (common1~3을 공통적인 파라미터라고 가정한 게시물 보기 화면)

<script type="text/javascript">
function goDelete(id) {
    var form = document.forms["blahform"];
    form.id.value = id;
    form.action = "delete";
    form.submit();
}
function goUpdate(id) {
    var form = document.forms["blahform"];
    form.id.value = id;
    form.action = "updateForm";
    form.submit();
}
function goList() {
    var form = document.forms["blahform"];
    form.action = "list";
    form.submit();
}
</script>

<a href="javascript:goDelete(1)">삭제</a>
<a href="javascript:goUpdate(1)">수정</a>
<a href="javascript:goList()">리스트</a>

<form name="blahform" method="post">
<input type="hidden" name="common1" value="1" />
<input type="hidden" name="common2" value="2" />
<input type="hidden" name="common3" value="3" />
<input type="hidden" name="id" value="" />
</form>

프로그램 적으로 생각하자면 공통 파라미터의 일관성을 유지할 수 있는 한가지 방법이라고 할 수 있겠지만, 결과적으로 HTML 태그가 의미에 맞지 않고 자바스크립트 의존적인 코드가 되었다. 기본적으로 form 태그는 사용자 입력 양식을 뜻하는데 위에 쓰인 form 태그는 프로그램 내부적인 용도 그 이상의 의미를 지니지 않는다.

앞서 언급한 것과 같이 공통 파라미터를 한 변수에 할당하는 방법으로도 일관성을 충분히 얻을 수 있고 그 이외에도 서버 사이드 스크립트 단에서 위의 코드에서 얻으려고 했던 이득을 놓치지 않을 수 있는 방법이 많이 있다. 이와 같은 오류를 범하지 않으려면 HTML의 구조화를 해치지 않고 자바스크립트 의존적인 페이지를 피하는 자세가 필요하다.

1k DHTML API

1k DHTML API – document를 handling하는 여러가지 경우에 수에 대한 API를 제공한다.

종류로는…

  • element 얻기 – gE
  • element 보이고 숨기기(table 기반 레이아웃에는 적합하지 않다..) – sE, hE
  • z-index style 지정 – sZ
  • element의 left position set – sX
  • element의 top position set – sY
  • element의 가로길이 set – sW
  • element의 세로길이position set – sH
  • clip set – sC
  • write HTML – wH

등이 있다.

제목처럼 1k로 용량도 작은데다가, 개발자가 element handling에 있어 시간을 들여 cross browsing을 크게 신경쓰지 않아도 되니 여러모로 좋을 것 같다. :)

JavaScript/DOM 사용의 비기!..2

우리는 흔히 <script type="text/javascript"> 안의 내용을 다 자바스크립트(이하 JS)라고 생각한다. Document Object Model(이하 DOM)이라는 말 자체가 생소하게 느껴진다는 것이다.

어떤게 JS고 DOM인게 무슨 소용인가? 아니다. 활성화된 커뮤니티에서 문제를 해결할 수도 있겠지만, 그렇지 못할 때에는 매뉴얼을 보아야한다. 에러가 난 부분이 JS인지 DOM인지 알아야 매뉴얼을 찾아볼 수 있지 않겠는가?

분류는 쉽다! html element를 가리키면 DOM이고 아니면 JS다. frame등을 가리키는 것도 DOM이다.

이제 DOM인지 JS인지 알았다면, 매뉴얼을 잘 찾아보는 일만 남았다.

DOM은 W3C DOM Technical Reports (HTML 접근 부분은 DOM Level2 HTML)에서 볼 수 있다.

JS는 Syncro.net의 Core JavaScript Reference (devedge.netscape.com이 좋은 reference 사이트였으나 없어졌다. ㅠㅠ)를 보면 되겠다.

JavaScript/DOM 사용의 비기!..1

JavaScript/DOM은 웹이라는 녀석에 기본적으로 포함되는 것이 아니다. 이 말인즉슨, 포함이 안될 경우도 있다는 것이다. 따라서, JavaScript/DOM 사용에 있어서, 포함이 안될 경우에는 어떻게 될것인가에 대한 고찰이 필요하다. 이렇게 얘기해서는 너무 복잡하게 생각될 수도 있겠다. 예를 한번 들어보자. 버튼을 누르면 폼을 서브밋하고 싶다.. 는 예를 들어보겠다. 편의상 일부 필수 태그는 누락시킨 점.. 이해해주시길.. :)

<html>
<head>
<script type="text/javascript">
function checkForm(form) {
    if (form.elements["title"].value == "") {
        alert("제목을 입력해주세요");
        return;
    }
    form.submit();
};
</script>
</head>
<body>
<form action="someaction">
    <p>
        제목 <input type="text" name="title" />
        <input type="submit" value="전송" />
        <a href="javascript:checkForm(document.forms['someaction'])">전송</a>
    </p>
</form>
</body>
</html>
<html>
<head>
<script type="text/javascript">
function checkForm(form) {
    if (form.elements["title"].value == "") {
        alert("제목을 입력해주세요");
        return false;
    }
    return true;
}
</script>
</head>
<body>
<form action="someaction" onsubmit="return checkForm(this)">
    <p>
        제목 <input type="text" name="title" />
        <input type="submit" value="전송" />
    </p>
</form>
</body>
</html>

위는 나쁜 녀석이고, 아래는 좋은 녀석이다. -_-;;

위의 코드가 무엇이 나쁜고 하니.. JavaScript가 인식되지 않는 브라우저에서는 "javascript:checkForm()" 식의 링크가 어떤 지시를 내리는지 알 수가 없다. "checkForm()" 자체가 JavaScript니까… 따라서 폼 체크를 할 수 없고 서브밋은 꿈도 못꾸게 된다.

반대로 아래의 코드는 기본적으로 HTML에서 폼 서브밋에 사용되는 submit button이 있어 서브밋에 지장이 없다. 폼 체크의 경우에는 JavaScript엔진이 있으면 onsubmit 메소드가 호출되어 checkForm function을 탈 것이고 없다면 onsubmit 메소드가 무시되어 아무런 에러없이 서브밋이 될 것이다.

form 값을 받은 action page에서 해당 값들을 체크하는 센스는 당연히 가지고 있을 것으로 생각한다. :)

아! 근데 이런식이라면 text로 폼 전송을 못하지 않는가? 그렇다. -_-; 안타깝게도 HTML만으로는 단순한 text가 폼 전송의 역할을 할 수 없다.

우리나라 웹시장의 웹디자인 마인드로는 심각한 일이지만, 웹이라는 녀석의 기본 목적 상 큰 문제가 될 것이 없다는 것으로 결론을 내린다! 무책임하다고 하신다면 죄송할 따름.. ㅠㅠ

다음 시간에 계속 쓰겠습니다.. :)