박종명의 아름다운 개발 since 2010.06

아이폰과 같은 스마트폰의 가장 기본적인 UI 구성은, 박스가 세로로 나열된 목록형태를 많이 띄고 있다
게임과 같은 엔터테인먼트 어플은 컨텐트의 특성상 독창적인 UI구성을 가지지만 설정화면과 같은 정적인 화면 구성은 대부분 아래와 같이 목록 형식으로 구성된다

 

 

일전에 jQTouch 를 간단히 언급했었다 => [JQTouch] 모바일 웹 UI 라이브러리

이번주에 jQTouch 를 조금 살펴 볼 예정인데, 그 첫글로 기본적인 사용 환경 설정을 다루고자 한다.
웹 개발 환경은 다른 응용개발 환경보다 훨씬 심플하다는 것이 매력적이다

다른 응용 환경 구성과 같은 구구절절한 개발툴과 Add-In 형태의 프로그램, 까탈스러운 구성파일의 설정 과정이 없어 쉽게 시작할 수 있고 개발모델 역시 심플하여 접근하기 매우 용이하다. 맘에 든다 ㅎㅎ

jQTouch 역시 심플한 웹 개발모델을 제시하며, 결국에는 자바스크립트, CSS, HTML 과 같은 기본적인 웹 개발 요소들이 사용될 뿐이다. 물론 jQTouch 라이브러리를 참조해야 하지만 이것 역시 자바스크립트의 범주이다

1. jQTouch 라이브러리 다운로드
흔히 jQTouch 를 플러그인이라 표현 하지만 라이브러리라 표현해도 무방할 것이다
가장 먼저 시작할 것은 이 라이브러리를 개발 PC에 다운로드 하는 것이다. 아래의 링크에서 최신버전의 jQTouch 라이브러리를 다운받는다. 현재시점(2010.10.25) 기준 1.0 beta 2 버전을 다운받는다
: http://www.jqtouch.com/

다운받은 파일의 구성은 jQTouch 라이브러리 파일, 테마 스타일 파일, 확장팩 파일, 데모파일 등이다
여기서 데모를 확인해 보면 참으로, 아이폰 앱 스타일에 적합하다는 것을 느낄 것이다


2. 테마 선택(적용)하기
jQTocuh 는 jQuery 기반의 UI 라이브러리이다. 따라서 스크립트파일과 더불어 스타일을 정의한 CSS파일도 포함되어 있다. 스타일은 총 두개로 나누어져 있는데 jQTouch 테마와 Apple 테마가 그것이다
jQTouch 고유 테마는 검정색 바탕에 회색톤과 하얀 글자가 특징이다. 반면 Apple 테마는 아이폰 UI와 유사하게 청색 계열의 느낌과 흰 바탕 그리고 검정색 글자로 구성된다. 아래 두 화면에서 그 차이를 느낄 수 있다

그리고 기본적인 jQTouch 스타일을 정의한 파일은 jQTouch 폴더에 있는 jqtouch.css 파일이다
이 파일 역시 웹 페이지에 스타일로 정의해 둔다


3. jQTouch 라이브러리 참조하기
일종의 핵심 엔진을 참조하는 것으로 jQTouch 스크립트 라이브러리에 대한 참조이다
jQTouch 폴더의 jqtouch.js 파일이 그것이다. 또한 jQTouch 가 jQuery 기반으로 작성되었기 때문에 jQuery 라이브러리의 참조도 필수이다. jQTouch 를 다운받은 폴더에는 친절하게도 jQuery 라이브러리가 포함되어 있다. 현재 jQTouch 버전은 jQuery 1.3.2 버전을 사용하고 있다. 아래와 같이 스크립트를 참조한다

4. jQTouch 객체 생성으로 시작하기
각종 기본 설정을 정의하는 일종의 초기화 과정을 객체 생성 코드로 정의할 수 있다
이 초기화 객체에 사용되는 매개변수를 보면 jQTouch 가 하이브리드 형태의 웹앱에 초점이 맞춰진 라이브러리라는 것을 간접적으로 알 수 있다. 예를 들어, 아이폰 바로가기 아이콘이라던지 로딩 화면등 웹앱의 구성요소 정의가 그것이다. 

5. 설정 끝, 지금부터는 div 엘리멘트와 id, class 속성들과의 잔치?이다
jQTouch 의 적용을 위한 기본 설정은 이것으로 끝이다. 이제부터는 Div 엘리멘트의 정의와 각종 HTML 요소 그리고 id, class 속성을 통한 형식 지정, 스타일 정의로 화면을 jQTouch 답게 구성할 수 있다. 지금부터가 jQTouch 라이브러리의 구체적 사용법을 알고 진행해야 하는 과정이다.

위 설정들을 포함한 가장 기본적인 jQTouch 기반 웹 페이지의 구성은 아래와 같다

실행 화면

[현상]
HTML5와 같은 차세대 웹 표준의 등장으로 기존의 RIA 플랫폼 기능들이 표준웹으로 통합되며, Web기반 OS, Web App Store등장 등으로 Web이 점차 App과 유사해 지고 있다.

[발전방향]
HTML5는 궁극적으로 오디오, 동영상, 쌍방향 플러그인 등을 필요 없게 만들 것이며, App과 Web은 서로 간의 장단점을 보완하며 궁극적으로 하나의 시스템으로 통합되어 갈 것이다

HTML5 에는 로컬 자원을 활용하는 유용한 기능들이 포함되어 있다
대표적인 예로 웹 스토로지, 웹 데이타베이스, 어플리케이션 캐시등을 들 수 있다

이 블로그에서 이 들 스펙에 대해 간략하게 다루었었다
: [HTML5] Web Storage
: [HTML5] 오프라인 웹 어플리케이션
: [HTML5] Web SQL Database

이와같은 로컬 자원을 활용하면 웹 응용프로그램의 사용성, 응답성, 성능등과 같은 전반적인 효율성을 꾀할 수 있어 많은 활용도가 기대된다

이들 기술의 기능적 구현에 대한 이해와 더불어 환경에 대한 이해도 같이 해 두면 유용할 것이다
이전 글에서는 기술의 개요와 구현에 대해 살펴보았다면 이 글에서는 로컬 자원의 저장 위치와 한계 용량, 지속 기간 등의 환경적 요인들을 살펴 보고 이들 기술의 이해의 폭을 넓히고자 한다

그럼 이제부터 HTML5에서 로컬 자원을 어디에, 얼마나, 언제까지 저장하는지 살펴 보도록 하자.
참고로 로컬 영역에 대한 내용이다 보니 클라이언트 PC의 OS와 브라우저의 종류, 버전에 따라  내용이 조금씩 다를 수 있음을 밝혀 둔다. 그리고 가정을 하건대, 로컬 디스크의 용량은 무제한이라고 가정해 둔다. 기술별 최대 용량을 따져보는 와중에 컴퓨터 하드디스크 자체에 여유공간이 없다면 아무런 소용이 없기 때문이다

이 글은 윈도우 XP를 사용하고 IE8, 그외 브라우저(크롬,사파리등)은 현재시점(2010.10.19) 최신버전을 사용하고 있는 것을 기준으로 하고 있다

어디에 저장되는가?
대부분의 로컬자원은 OS의 사용자별 어플리케이션 데이터 공간에 저장된다
윈도우 XP에서는 'C:\Documents and Settings\사용자계정\Local Settings\Application Data' 가 어플리케이션 데이터를 저장하는 공간이며 이 디렉터리 하위에 있는 각 브라우저별 폴더에 로컬자원이 저장된다
윈도우에서 'C:\Documents and Settings\사용자계정' 의 경로는 %userprofile%로 대체 된다

LocalStorage
크롬: %userprofile%\Local Settings\Application Data\Google\Chrome\User Data\Default\Local Storage
사파리: %userprofile%\Local Settings\Application Data\Apple Computer\Safari\LocalStorage
파폭: %userprofile%\mkex\Application Data\Mozilla\Firefox\Profiles\xxx.default\webappsstore.sqlite 파일
오페라: %userprofile%\Application Data\Opera\Opera\pstorage
IE8: %userprofile%\Local Settings\Application Data\Microsoft\Internet Explorer\DOMStore

SessionStorage
세션스토로지의 경우 브라우저 프로세스의 메모리 영역에 저장되므로 물리적인 시스템 디렉터리에 저장되지 않는다. 따라서 데이터 저장을 위한 별도의 디렉터리 경로가 없다

Web SQL Database
크롬: %userprofile%\Local Settings\Application Data\Google\Chrome\User Data\Default\databases
사파리: %userprofile%\Local Settings\Application Data\Apple Computer\Safari\Databases
파폭: 지원되지 않음
오페라: %userprofile%\Application Data\Opera\Opera\pstorage

Application Cache
크롬: %userprofile%\Local Settings\Application Data\Google\Chrome\User Data\Default\Application Cache
사파리: %userprofile%\Local Settings\Application Data\Apple Computer\Safari\ApplicationCache.db 파일
파폭: %userprofile%\Local Settings\Application Data\Mozilla\Firefox\Profiles\xxxxx.default\OfflineCache
오페라: %userprofile%\Local Settings\Application Data\Opera\Opera\application_cache


얼마나 저장되는가?
LocalStorage
로컬스토로지의 경우 브라우저마다 최대 저장용량이 다를 수 있다. 더 엄밀히 말하면 브라우저, 도메인마다 최대 용량이 다를 수 있다. 로컬스토로지는 같은 도메인 정책보안을 따르기 때문에 최대 용량 역시 도메인별로 한정을 하고 있다. 예를 들어 파이어폭스는 도메인당 최대 5MB 까지 가능하다
표준 스펙에 의하면 5MB를 최대 용량으로 권장하고 있으니 대체로 다른 브라우저도 이와 비슷할 것으로 보인다. 만일 한 도메인에 localStorage의 값을 5MB 이상 저장해야 한다면 브라우저가 이를 지원하는지 따져봐야 한다. (IE8의 경우 도메인당 10MB를 지원하는 것 같다)
(기존 쿠키가 4KB로 제한을 둔 것에 비하면 5MB 공간은 웹 환경에서 상당량이라 할 수 있다) 

SessionStorage
세션스토로지의 경우 전역적인 공간이 아닌 브라우저 컨텍스트 영역에 저장되므로 브라우저 프로세스, 메모리와 연관이 있다. 이런 특징에 기인했는지 최대용량에 대한 언급을 찾을 수 없다. 다시 말해 브라우저 자체적으로 용량에 대한 제한을 두는지 localStorage 와 합쳐서 도메인당 용량을 계산하는지 아니면 브라우저 컨텍스트에서 사용 가능한 시스템의 메모리 크기에 의존하는지 등에 대한 언급은 없지만 개인적으로는 후자, 즉 브라우저 프로세스가 사용하는 시스템 메모리 크기에 의존하지 않을까 예상해 본다

Web SQL Database
웹 데이터베이스 용량의 기준은 LocalStorage와 개념적으로 유사하다.
즉 브라우저별로 최대 용량이 다를 수 있으며 도메인 단위로 관리된다.
그러나 LocalStorage 비해 용량의 유연성이 더 크다. 다시말해 더 큰 크기의 데이터저장이 가능하다는 것이다
HTML5 표준 사양에는 DB 용량에 대한 규정을 별도로 두지 않고 있으며 브라우저의 정책에 따라  DB용량의 기준이 다를 수 있다는 것을 명심하자. DB를 생성하는 openDatabase 함수의 estimatedSize 매개변수에 생성하고자 하는 DB의 크기를 바이트 단위로 지정할 수 있는데 이 크기는 DB의 대략적인 크기를 지정하는 것으로 브라우저마다 그 적용이 다를 수 있다는 것이다.
openDatabase(in DOMString name, in DOMString version, in DOMString displayName, 
                                         in unsigned long estimatedSize, in optional DatabaseCallback creationCallback);

사파리 브라우저를 통해 DB 용량에 대한 내용을 체크 해 보자
다음 코드와 같이 기가(GB)단위의 큰 DB를 생성한다
var db = window.openDatabase("myDB","1.0", "테스트용DB", 1024*1024*1024);

사파리에서 위 코드를 실행하면 다음 그림과 같이 허용할 것인지 대화상자가 나오고 사용자가 허용하면 정상적으로 DB가 생성된다. (심지어 크롬과 오페라는 허용 여부를 묻지도 않고 생성해 준다)

Application Cache
어플리케이션 캐시의 저장 용량을 따져보는 것은 어찌보면 무의미 할 수 있다
로컬스토로지나 웹데이타베이스와 같은 것은 저장소라는 개념이 명확해서 사용 가능한 공간, 용량이라는 개념을 적용시킬 수 있으나 어플리케이션 캐시는 이런 개념과는 조금 다르기 때문이다.
그러나 이것 역시 로컬의 어딘가에 저장되어 캐시 되기에 굳이 용량에 대한 관점으로 본다고 하면, 어플리케이션 캐시가 저장되는 시스템 하드디스크의 크기라고 말할 수 있겠다.

다만 IE의 임시인터넷파일과 같이 저장공간에 제한을 둘 수도 있는데 이것과 관련해서도 역시 각 브라우저 정책에 따른다는 것이다.

HTML5 스펙에서는 어플리케이션 캐시에 대한 디스크 공간을 다음과 같이 설명하고 있다.
User agents should consider applying constraints on disk usage of application caches.
User agents should allow users to see how much space each domain is using, and may offer the user the ability to delete specific application caches. 


언제까지 저장되는가?
LocalStorage
로컬스토로지는 특수한 상황이 아니라면 영구적으로 데이터를 보관한다
특수한 상황이라 하면, 사용자가 직접 데이터를 삭제하거나 브라우저를 제거하거나 OS를 재설치하는 것을 말한다. 이러한 특수한 상황이 아니라면 데이터는 영구적으로 보관된다

SessionStorage
세션스토로지는 브라우저 창이 닫힐 때 까지 보관된다. 엄밀히 말하면 브라우저컨텍스트라는 일종의 프로세스 도메인이 활성화되어 있는 동안만 데이터가 유지된다. 쉽게 말해 브라우저 창이 열려 있는 동안 데이터가 보관 된다고 생각하면 되겠다

Web SQL Database
웹 데이터베이스는 LocalStorage와 같이 특수한 상황이 아니라면 영구적으로 데이터를 보관한다

Application Cache
어플리케이션 캐시에 보관되는 데이터의 유효기간을 따지는 것은 앞서 용량을 따지는 것보다 더 무의미하다
앞서 다른 기술들과 마찬가지로 특수한 상황이 아니라면 영구적으로 보관될 것이며 캐시를 업데이트 하거나 캐시 저장공간이 꽉 찾을 경우 덮어 쓰는 등의 시나리오에서 일부 갱신되거나 유실될 수 있을 것이다

몇해전 MKEXDev.NET 의 로고가 필요하게 된 적이 있었다

대학생에게 무료로 개발도구를 배포하는 마이크로소프트의 DreamSpark 이벤트에 후원 커뮤니티로 선정되어 사이트 로고를 보내줘야 했다. 당시 내 사이트에는 특별한 로고가 없었으나 MS 프로모션 담당자는 이미지로 된 로고를 원했다. 그래서 급조하기로 했는데 개발을 주제로 한 사이트라 뭐.. 특별한 디자인을 하고 싶지는 않았다. 그냥 텍스트에 간단한 효과를 줘서 깔끔하게만 보이면 되겠다 싶었다.

그래서 아는 디자이너에게 매우 심플하게 만들어 달라고 부탁해서 나온 로고가 바로 아래와 같은 모습니다.
심플하면서도 깔끔한 텍스트 기반의 로고로 개인적으로 흡족하며 지금까지 사이트 로고로 사용하고 있다

HTML5 Canvas+Text Example
한참 삘(feel) 받아서 데모를 제작하다가 이 사이트를 알게 되었다
=> http://whatdo.net/html5/example/#2

내가 구현하고자 했던 대부분의 기능이 제공되고 있었다.
사실 데모의 완성도를 꽤 올리고자 맘 먹고 시도하던 도중에 이 사이트를 보게 되었고 동기가 한풀 꺽였다
이미 제공되고 있는 사이트가 있으니 내가 만들고자 하는데모에 새로움은 별로 없기에 받았던 삘(feel)이 사그러져 버렸다 ㅎㅎ. 그래서 적당한 선에서 데모 제작을 완료하고 포스팅 하게 된 것이다

이 사이트를 보면 조금은 다른 방식으로 구현하고 있지만 더 많은 canvas 기능이 활용되었고 구현 방식 역시 배울점이 많아 보인다. 소스보기를 통해 분석해 보면 많은 도움을 얻게 될 것이니 반드시 참고 바란다

기본적으로 웹 페이지는 요소(Element)라고 부르는 개체들의 모음이다
div, table, img 등 각각의 태그는 특정 요소를 정의하기 위한 마크업 규칙이며 이 요소들이 모여 웹 페이지를 구성한다. 이들 요소는 기본적으로는 페이지에 정적으로 표시되지만 스타일 처리와 동적 구현을 위해 자바스크립트와 같은 언어로 핸들링 할 수 있다

이러한 핸들링을 위한 가장 첫 단계가 바로 페이지에 존재하는 요소를 찾아내는 일이다. 이를 '페이지 요소 탐색'이라 한다. 이 글에서는 페이지 요소 탐색을 위한 과거와 현재의 기술적 이슈를 다루고자 한다

document.all
아마 필자와 같은 구식(?)  웹 개발자들은 제일 먼저 document.all 을 떠 올렸을 것이다
요소에 부여된 id를 기반으로 탐색하는데 매우 낡은 방법이다.

아래와 같이 페이지의 div 요소에 "myDiv" 라는 id를 부여했다고 가정한다
<div id="myDiv">ABCD</div>

그리고 다음과 같이 이 요소를 탐색한다
var element = document.all["myDiv"]; alert(element1.nodeName);

그러나 요즘 시대에 이런 낡은 문법을 사용한다면 욕 듣기 딱 쫗다 ㅎㅎ
왜냐하면 비표준 스크립트라는 이유에서이다

document.all 은 과거 마이크로소프트의 인터넷 익스플로러에 채택된 DOM 스크립트이다.당시 넷스케이프에서는 document.layers 와 대응되는 문법이었다. 이러한 비표준 스크립트는 크로스브라우저 환경에 큰 걸림돌이기 때문에 사용을 권장하지 않는다

모든 브라우저에서 사용가능한 document.all ??
document.all 은 MS 가 IE를 위한 비표준 탐색 스크립트지만 현재 존재하는 대부분의 최신 브라우저에서 이를 지원하고 있다.  즉 IE는 물론 크롬, 사파리, 파이어폭스, 오페라에서 잘 동작한다.그럼 표준인가?? ...
그렇지 않다. 표준이라기보다는 워낙 유명한(?) 문법이라 IE호환성을 위해 각 브라우저에서 이를 지원하게 된 것일 뿐이다. 이와 관련한 다음의 글을 참고하기 바란다
=> Mozilla, document.all 부분 지원 시작!   ,  document.all 문제 해결법


document.getElementById
아마 모든 웹 개발자가 알고 있는 문법일 것이다
비표준 탐색 스크립트를 평정하고 W3C 에서 표준으로 정한 탐색 스크립트가 바로 document.getElementById 이다. 앞서 document.all을 다음과 같이 대체할 수 있다. 그리고 표준이기 때문에 브라우저 호환성이 보장된다
var element = document.getElementById("myDiv");

이제 document.all 은 잊어 버리고 document.getElementId 를 사용하자. 이미 오래전에 잊었겠지만...


document.getElementsByTagName
getElementById 와 쌍을 이루는 유명한 문법일 것이다.
getElementsByTagName는 getElementById와 마찬가지로 표준 스크립트이며 딱 두가지 차이점이 존재한다.

1) 하나 이상의 요소 즉 요소의 배열을 반환한다
getElementsByTagName 이 반환하는 것은 요소배열이다.
비록 반환되는 요소가 단 1개라도 배열 접근 형식(ex element[0]) 을 취해야 한다.

2) 요소에 부여된 ID가 아닌 태그에 기반한다
getElementById 가 요소에 부여된 ID를 기반으로 탐색을 수행한다면, getElementsByTagName는 요소의 태그명에 기반한다. 즉 div, table, img 와 같은 요소태그를 대상으로 탐색을 수행한다

이런 특징은 일종의 유연성을 제공해 준다. getElementById와 같이 ID를 기반으로 한다는 것은 일종의 규칙이다. 즉 미리 정의된 ID가 있어야 한다는 규칙이 성립해야 한다. 만일 웹 문서 파서(parse)와 같은 범용적인 외부 제작툴을 개발한다면 이런 규칙을 적용할 수 없기 때문에 공통적인 태그를 기반으로 한다는 것이 유연성이 있다는 예기이다

페이지에 다음과 같이 두개이 div가 정의되어 있다면,
<div>First Div</div>  <div>Second Div</div>

다음과 같이 전체 div요소를 탐색할 수 있다
var element = document.getElementsByTagName("div");    

for(var i = 0; i < element.length; i++){
   alert(element[i].nodeName);  
}


document.getElementsByClassName
웹킷(webkit) 기반 브라우저에서 적용한 탐색 스크립트이다.
getElementByID의 경우 ID가 부여된 단 하나의 요소만을 탐색할 뿐이며 getElementsByTagName의 경우 동일 태그의 모든 요소를 반환한다. 만일 임의의 이름이 부여된 특정 그룹을 탐색하고자 할 경우 이 두가지만으로는 한번에 만족시킬 수 없다. getElementsByClassName 은 그 이름에서도 알 수 있듯이 className 이 부여된 요소(그룹)을 반환한다.

페이지에 다음과 같이 동일한 class가 부여된 div 요소가 정의되어 있다면,
<div class="myDivClass">First Div</div>
<div class="myDivClass">Second Div</div>

다음과 같이 class 명으로 div 요소 그룹을 탐색할 수 있다

var element1 = document.getElementsByClassName("myDivClass");    
    
for(var i = 0; i < element1.length; i++){
   alert(element1[i].nodeName);  
}

참고로 아래 그래프는 getElementsByClassName 과 이와 같은 기능을 xPath, 혹은 커스텀 스크립트로 개발할 대의 스크립트 속도차이를 보여준다. 브라우저 차원에서 제공하는 네이티브 getElementByClassName의 수행 속도가 현저히 빠르다는 것을 보여주고 있다


getElementsByClassName 은 현재 IE8(이하) 를 제외하고는 대부분의 브라우저에서 지원된다
그러나 이 함수는 HTML5 스펙에 포함되었으며 IE 버전 9 부터는 같이 지원될 예정이다


document.querySelectorAll
CSS Selector 규칙을 그대로 이용할 수 있는 방법이 생겼다
W3C 에서는 보다 유연한 탐색을 지원하기 위해 CSS 규칙을 기반으로 하는 Selectors API 를 표준화 시켰다
querySelectorAll 함수를 통해 CSS 탐색 규칙을 맘껏(?) 적용할 수 있다

페이지에 다음과 같이 div 안에 p 요소가 정의되었다고 가정할 때,
<div id="myDiv">
   <p>First paragraph.</p>
   <p>Second paragraph.</p>
</div>

다음과 같이 CSS 규칙을 이용하여 요소를 쉽게 탐색할 수 있다
var element = document.querySelectorAll("#myDiv p");

for(var i = 0; i < element.length; i++ ) {  
    element[i].style.backgroundColor = "red";
}

또한 querySelector 을 통해 특정 요소를 다음과 같이 탐색할 수 있다
var element = document.querySelector("#myDiv > p:first-child")
alert(element.nodeName);

중요한 것은 CSS 탐색 규칙 즉 CSS Selector 을 이용하여 보다 강력한 탐색이 가능하다는 점이다

참고로 querySelectAll 은 IE8 을 포함한 크롬, 사파리, 오페라, 파이어폭스에서 모두 지원하지만
다른 브라우저가 CSS 3 Selector 까지 지원하는 반면 IE8은 CSS 2.1 Selector 까지만 지원된다

다음의 링크를 통해 CSS Selector 에 대한 자세한 정보를 확인하자
- CSS 2.1 Selector
- CSS 3 Selector
- CSS Selector 상세 브라우저 지원 현황
- CSS 3 selectors explained


Selector 라이브러리를 통한 탐색
근래 웹을 개발하는 거의 모든 사람이 추천하는 jQuery, Prototype 과 같은 자바스크립트 라이브러리에서는 훌륭한 탐색 기능을 제공해 준다. 이들 라이브러리는 브라우저 호환성을 제공하고 빠른 수행 속도가 보장되기 때문에 그 사용이 권장되고 있는 추세이다. 다만 스크립트 해석이 한번 더 랩핑된 형태라 아무래도 브라우저 차원에서 제공되는 네이티브(Native) 보다는 수행속도가 조금 떨어지는 것은 사실이다
그러나 비용 대비 효과면에서는 충분히 수용할 만한 아니 그 이상의 성능을 보여주고 있기 때문에 권장된다
다음 그림은 각각의 탐색 API를 활용할 경우 수행 속도의 차이를 보여준다

출서: FireFox3.5의 DOM selectors API

다음 글은 탐색과 관련한 유용한 정보를 제공해 주니 읽어보기 바란다
참고: FireFox3.5의 DOM selectors API