표준 쪽에 흥미로운 소식이 있습니다. 우선, HTML 5 초안이 업데이트 되었습니다.

업데이트 사항을 보시거나 상세한 내용을 포함한 변경된 부분에 대한 문서를 보실 수 있습니다:

• canvas 엘리먼트를 위한 API가 말끔히 정리되었습니다. 텍스트 지원이 추가되었습니다.
• globalStorage가 동일근원 정책으로 제한되면서 localStorage로 명칭을 변경했습니다. 관련 이벤트도 깔끔해졌습니다.
• postMessage() API 가 변경되었습니다. 메시지의 출처만 노출되고 URI는 더이상 노출되지 않습니다. 또한 대상 문서의 출처를 가리키는 두번째 인자가 필요해졌습니다.
• 드래그-앤-드롭 API 가 깔끔해졌습니다. dataTransfer 객체가 전송되는 데이터의 타입을 가리키는 types 속성을 가지게 되었습니다.
• m 엘리먼트는 mark 라고 부릅니다.
• 서버-전송 이벤트가 변경되고 깔끔해졌습니다. 새로운 형식을 사용하므로 기존 구현방법은 사용되지 않습니다.
• figure 엘리먼트에 캡션은 필수가 아니게 했습니다.
• ol 엘리먼트는 새로운 reversed 속성을 가지게 되었습니다.

Acid4도 준비중인 것 같습니다.

from New in standards: Acid4 and HTML 5 update

W3C Web API 그룹에서 새로운 초안, Progress Events 1.0을 공개했습니다.

이 문서는 동작의 진행을 모니터링 하는데 사용할 이벤트 타입을 기술합니다. 원래 XMLHTTPRequest이나  Media Access Events에 의해 정의된 데이터 전송과 같은 컨텍스트에 대한 것으로서 고안되었습니다.

이 API는 많은 다른 API들 사이에서 보여진 진행 이벤트들을 표준화합니다.

아래는 정의된 이벤트들입니다.
명세는 두가지 경우로 나누어져있습니다:

• Example 1: 다른 명세에서의 진행 이벤트 사용
• Example 2: SVG 문서에서의 진행 이벤트 사용
  

또 다른 W3C 소식입니다. 노인을 위한 웹 접근성: 문헌 리뷰 초안이 나왔습니다. 75세 이상을 "늙고 늙음(old-old)" 로 표현한 부분은 은근 재밌습니다. 이 문서에서는 60세 부터를 늙음(older)으로 표현하는군요. 59세도 중년(middle-aged)입니다. :)

from W3C Progress Events 1.0 Working Draft on Ajaxian

Mick Chambers씨가 JavaScript와 Flash를 이용하여 HTML5 태그를 구현하셨습니다.

기본적으로, 이 라이브러리는 VIDEO 엘리먼트/태그와 속성을 해석하고, 특정 동영상을 읽어들일 수 있는 Flash 비디오 재생기를 표시하기 위해 적합한 OBJECT 혹은 EMBED 엘리먼트로 대체합니다. h264 컨텐트와 FLV 형식 둘 다 재생가능합니다.

이 라이브러리는 Flash 컨텐트의 표현을 위해 SWFObject JavaScript 라이브러리를 사용했습니다.

현재 구현된 VIDEO 속성은 다음과 같습니다:

• controls
• poster
• autoplay
• width
• height
• playcount

까다로운 부분은 VIDEO DOM 스크립팅 API를 깔끔하게 구현하는 일입니다. 당연히 가능할 거라고 믿고 있긴 하지만 말입니다.

사용해보시려면, 다음과 같이 vedio 태그를 채우시면 됩니다:
예제는 여기서 보실 수 있고, 스크립트는 여기서 받으실 수 있습니다.

from HTML5 Video tag implemented in Flash on Ajaxian

아래는 Anne van Kesteren 씨의 HTML5의 XTech 프리젠테이션입니다:

The Web's language is HTML
(웹의 언어는 HTML이다)

The Web's application language is HTML too
(웹 응용프로그램의 언어도 HTML이다)

HTML is pretty broken
(HTML은 제대로 엉망이다)

HTML5 to the rescue
(HTML은 구원이다)

Defines processing for all of HTML

Is for Web applications and documents

Is defined in as an abstract language

Can be written in both HTML (HTML5) and XML (XHTML5)

Is a multi-vendor effort

Worked on by overlapping groups: WHATWG and W3C HTML WG

HTML5 is (partially) implemented today

HTML5 can be used today

Great Community! (Wikis, tools, tests, reviewing)

<section>, <footer>, <progress>, <time>, …

<input type=date>, <input pattern=[a-Z]>, …

Immediate mode graphics: <canvas>

<video> and <audio>

SQL storage, offline application cache, drag & drop, editing, …

Get involved: w3.org/html and whatwg.org.

EOP_ERR exception raised: slide 21

또한 Anne씨는 HTML5에서 ruby가 지원된다고 알려주셨습니다.

Ruby 개발자라면 너무 좋아하진 마세요. 이것은 다른 ruby입니다.

여기서 말하는 루비란, 원래의 텍스트에 다는 작은 발음기호, 설명 정도가 될 것 같습니다. Ruby의 정의에도 "동아시아 문서에서 발음기호를 표시하기 위한 것"이라고 써두었네요. 예를 들면 이런 것입니다.

한문이 원래의 글이고, 다른 ruby text 들이 발음기호를 알려주고 있습니다. 일본에서 한자와 발음을 병기하는 것을 생각해보시면 될 것 같습니다. 또한 이런 식으로 사용할 수도 있습니다.

분명 유용하긴 한데, ruby라는 글자를 보고 낚인 것은 저 뿐인가요?

from HTML5 and a different kind of ruby support on Ajaxian

CSS Namespace 모듈이 "W3C 예비 권고안"이 되었습니다.

간단하지만, 아주 유용하게 쓰일 모듈입니다:

CSS Namespace 모듈은 CSS에서 네임스페이스 사용 문법을 정의합니다. 기본 네임스페이스 선언과 네임스페이스와 네임스페이스 접두어를 바인딩하는 @namespace 규칙을 정의합니다. 또한 네임스페이스 자격이 있는 이름에서 이러한 접두어를 사용하기 위해 다른 명세를 적용할 수 있는 문법도 정의합니다.

아래는 네임스페이스를 아주 잘 보여주는 예제입니다:

네임스페이스 선언:

[code:css]
@namespace toto "http://toto.example.org";
@namespace "http://example.com/foo";

컨텍스트에서는 기본 네임스페이스가 적용됩니다:

• toto|A:
  http://toto.example.org 네임스페이스에 있는 이름 A를 표시
• |B:
  네임스페이스가 없는 이름 B를 표시
• *|C:
  네임스페이스가 없는 것을 포함한 모든 네임스페이스의 이름 C를 표시
• D:
  http://example.com/foo 네임스페이스의 D를 표시

아주 좋은 발전이긴한데, 우리가 진짜로 기다리는 것은 언제 주요 브라우저들에서 지원이 되느냐는거겠죠!

from W3C CSS Namespaces: Now a Candidate Recommendation on Ajaxian

IEBlog에 IE 8 이 postMessage를 지원한다는 글이 올라왔습니다. 멋진 소식이죠.

지원 사항과 사용 사례에 대한 것은 MSDN 기사를 보라고 링크해두었더군요.

Jeff Walden씨는 "현재의 IE 8 베타가 구현한 인터페이스는 하위 호환성을 보장하지 못하는 방법으로 여러 버전에 걸쳐 HTML5 스펙에 뒤쳐져 있습니다, 따라서 이를 경험해보고자 하신다면, 여러분이 작업한 것이 앞으로 나올 IE8에서 깨질 수도 있음에 주의하십시오."라고 주의시켰으며 차이점에 대해 상세히 설명했습니다.

현재의 스펙을 구현한 것은 Firefox 3 RC 1 와 Webkit Nightly 밖에 없는 것 같습니다.

from IE8 and Cross Domain Messaging on Ajaxian

Flickr, Viddler, Qik, Pownce, Revision3는 oEmbed를 지원하는 첫번째 서비스가 되었습니다. oEmbed는 써드파티 사이트의 특정 URL에 있는 미디어를 편하게 포함할 수 있는 방법입니다.
oEmbed 사이트에서 밝힌 내용입니다:

oEmbed는 써드 파티 사이트에 있는 URL을 포함하는 포맷입니다. 사용자가 해당 리소스의 링크를 포스팅하면 단순한 API를 이용해 리소스를 직접 파싱할 필요없이 웹사이트에서 임베디드 컨텐트(사진이나 동영상)를 표시할 수 있습니다.

이 말의 의미는, 만약 flickr에서 좋은 사진을 찾았다면 URL은 가져와서 임베드가 가능한 데이터로 쉽게 바꿀 수 있다는 것입니다:

원본 URL: http://flickr.com/photos/codepo8/2475016321/

oEmbed URL: http://flickr.com/services/oembed?url=http://flickr.com/photos/codepo8/2475016321/

결과:출력 형식과 최대 너비, 최대 높이 등을 URL 파라미터로 정의할 수도 있습니다:

oEmbed URL:
http://flickr.com/services/oembed?url=http://flickr.com/photos/codepo8/2475016321/&format=json&maxwidth=200

결과:

from oEmbed makes embedding third party videos and images a breeze on Ajaxian

URL 형태의 여러 제안 중 가장 새롭게 눈에 띄는 것이 mountpoint://인데, 브라우저에서의 File I/O API를 위한 Opera 제안사항의 일부입니다:

전통적으로, 웹 응용프로그램은 로컬 파일시스템 측의 리소스에 대해 조금의 접근도 허용되지 않았습니다. File I/O를 위한 ECMAScript 인터페이스들은 샌드박스화된 파일 시스템을 지정해, 위젯이나 다른 신뢰된 컴포넌트들이 로컬 파일 시스템에 접근할 수 있도록 합니다.

이 명세의 파일 I/O 인터페이스들은 추상 파일시스템을 나타내며, 기반 파일 시스템의 경로 분리자, 읽기/쓰기 권한 같은 파일 속성을 설정하기 위한 컨벤션 등에 대한 지식이 없어도 됩니다.

인터페이스는 파일을 열고, 쓰고, 파일이나 디렉토리를 생성하고, 옮기고, 지우고, 그밖의 것들을 위한 메소드를 제공합니다.

파일 작업을 하기 위해, 응용프로그램은 우선 마운트지점(mountpoint)을 얻어야 합니다. 마운트지점은 디스크 상의 파일이나 폴더에 대한 레퍼런스 혹은 같은 폴더가 아닐 수도 있는 파일 묶음에 대한 추상 레퍼런스입니다.

만약 응용프로그램에서 File I/O API를 사용하고 싶으면, 브라우저 사용자에게 가상 파일 시스템을 위한 위치를 선택하도록 요구하게 되고, 그러면 샌드박스 안에서 파일에 접근할 수 있습니다.
코어 인터페이스는 이렇습니다:

FileSystem 인터페이스
FileSystem 인터페이스를 응용프로그램에서 사용할 수 있게되면, 인터페이스는 opera.io.filesystem으로 인스턴스화 됩니다. 인스턴스가 되면, 이 객체는 로컬 파일시스템에 있는 파일들과 폴더들에 접근하기 위한 속성과 메소드를 제공합니다.

File 인터페이스
File 인터페이스는 가상 파일시스템내의 객체를 나타내고, 파일이나 폴더를 나타낼 수 있습니다. 파일 객체는 수많은 속성과 파일이나 폴더객체에 작동하는 메소드들로 구성되어있습니다.
지속성(persistent)있다고 표시된 파일 객체는 응용프로그램이 재시작되어도 지속됩니다.

FileStream 인터페이스
FileStream 인터페이스는 읽기 그리고/혹은 쓰기 속성으로 열린 파일 객체를 나타내며, 이 작업을 위한 메소드와 속성을 정의합니다.

from File API via mountpoint:// on Ajaxian

Simon Willison씨가 data- 속성을 통해 HTML 엘리먼트에 필요한 속성을 추가할 수 있는 방법으로 논의되는 HTML 5 스펙의 일부에 대해 글을 썼습니다.

예를 들어, 게임 상의의 우주선이라고 하면 이렇게 표현할 수 있습니다:

Simon 씨는  "이것은 설정값을 HTML 컨텐트로 저장할 장소가 마땅찮은 겸손한(unobtrusive) JavaScript에서 매우 유용하게 사용할 수 있습니다. 이는 또한 Dojo가 Dojo 위젯임을 표시하기 위해 커스텀 속성을 추가할 수 있는 승인된 방법을 가지게 됐다는 것을 의미합니다." 라는 사실을 지적했습니다.

from Embed your data- in HTML 5 on Ajaxian

W3C의 모바일 웹 테스트 수트 작업 그룹의 공동 의장인 Dominique Hazaël-Massieux씨는 ACID 테스트의 취지에 맞는 테스트를 발표했습니다: 모바일 브라우저를 위한 웹 호환성 테스트(Web Compatibility Test for Mobile Browsers)가 그것입니다:

테스트는 ACID 테스트와 같은 취지 아래, HTTP와 PNG 같이 널리 퍼진(하지만 모바일 장치에서의 구현은 미비한) 기술부터 한 두해 내에 중요하게 될만한 것까지(SVG 애니메이션이나 CSS 미디어 쿼리 같은 기술) 총 12가지 웹 기술의 테스트를 한 페이지 안에 조합했습니다.

테스트는 사각형으로 시각화했으며, 어려운 순서대로 정렬되었습니다(첫번째 줄은 널리 퍼진 기술, 두번째 줄은 점점 널리 사용되는 기술, 세번째 줄은 미래의 기술). 브라우저가 테스트를 통과하려면 모든 사각형이 같은 톤의 녹색이 되어야 합니다. 제가 아는 한 아직까지는 (모바일 장치 등에서) 통과한 브라우저가 없습니다.

테스트 영역입니다:

1. CSS2 min-width

화면 너비의 퍼센트 비율로 정의되는 유동적인 페이지 너비는 종종 작은 화면에서 읽을 수 없게 되는 것을 피하기 위해 min-width와 max-width 속성을 사용합니다. 앞의 속성을 여기서 테스트 합니다.

2. 투명 PNG

비트맵 이미지 형식인 PNG는 멋진 시각 효과를 만드는데 유용한 투명과 알파 채널을 지원합니다.

3. GZIP 지원

HTTP 프로토콜은 클라이언트가 압축을 풀 수 있다고 알려오면(Accept-Encoding 헤더를 통해서), 데이터를 gzip 방식으로 압축해서 보낼 수 있고, 그 결과로 트래픽을 절약할 수 있습니다.

4. HTTPS

HTTPS 프로토콜은 웹 상에서 보안과 암호화된 접속을 생성하기 위해 사용합니다.

5. XML로 제공되는 XHTML을 포함하는 iframe

브라우저가 application/xhtml+xml 타입으로 XHTML 문서를 로드함으로써 XML 컨텐트 타입을 지원하는지 여부를 테스트.

6. 정적 SVG

SVG는 손실없이 확대 축소가 가능해 자유로워 모바일 기기의 필요성에 알맞는 벡터 기반 그래픽을 정의할 수 있습니다.

7. XMLHTTPRequest

XMLHTTPRequest는 새로 전체 콘텐트를 전송하지 않고도 HTML 페이지의 부분만 업데이트 할 수 있는 AJAX 기술의 핵심입니다.

8. CSS 미디어 쿼리

CSS 미디어 쿼리는 제작자가 CSS 규칙을 특정 문맥 내에 제한적으로 적용할 수 있게 합니다. 예컨데, 주어진 최대 너비를 화면에만 적용할 수 있습니다. 여기서는 min-width 기능을 테스트 합니다.


9. 동적 SVG

SVG는 애니메이션도 지원하는데, 이는 상당히 멋진 인터페이스를 작성하는데 사용될 수도 있습니다.

10. canvas 엘리먼트

canvas 엘리먼트는 HTML5에 정의되어있으며, JavaScript 그래픽 API를 제공합니다.

11. contenteditable

contenteditable 속성은 엘리먼트의 리치 텍스트 편집(주: 흔히 웹 에디터라 부르는 기능)을 가능하게 합니다. 이 속성을 테스트할 수 있습니다.

12. CSS3 셀렉터

CSS3 에서 미세한 스타일링과 보다 나은 레이아웃을 설정하게 하는 몇가지의 새로운 셀렉터가 소개되었습니다. 여기서는 nth-child() 셀렉터를 테스트합니다.

아래가 실제로 테스트를 실행한 화면입니다:

from Now your mobile phones get to take some Acid on Ajaxian

from Last call for W3C XMLHttpRequest comments on Ajaxian

W3C는 XMLHttpRequest 스펙의 최종 초안을 발표했습니다:

Web API 작업 그룹은 XMLHttpRequest 객체의 최종 초안을 발표했습니다. XMLHttpRequest 객체 명세는 클라이언트-서버간 데이터 전송을 위한 클라이언트 기능을 제공하는 API를 정의합니다. 6월 2일까지 의견을 받습니다. Rich Web Client Activity 에 대해 더 살펴보세요.

제대로 된 에러(SECURITY_ERR, NETWORK_ERR, ABORT_ERR)를 받을 수도 있습니다. 아직은 스펙에 포함되지 않았지만 앞으로 포함할 내용도 공개되었습니다:

• load 이벤트와 onload 속성;
• error 이벤트와 onerror 속성;
• progress 이벤트와 onprogress 속성;
• abort 이벤트와 onabort 속성;
• 제안받은 Timers, 아마도 ontimeout 속성;
• redirect 를 사용하지 않게 하는 속성;
• text/html 문서를 위한 responseXML;
• 크로스 도메인 XMLHttpRequest;
• 바이트 스트림(주: 바이너리 데이터)를 다루기 위한 responseBody;
• MIME 타입을 정하는 overrideMimeType;
• getRequestHeader()와 removeRequestHeader().

from Event Delegation for blur and focus on Ajaxian

Quirksmode.org에서, Peter-Paul Koch 씨는 click 이벤트에서 멋지게 동작하는 이벤트 위임이 blur와 focus에서도 가능할지 조사하고 있습니다.

이벤트 위임이란 자식노드의 이벤트를 상위 노드의 부모들에게까지 보고하는 것을 의미합니다. 이벤트 핸들러를 각 엘리먼트에 적용하는 대신 하나의 부모 엘리먼트에만 적용하고 이벤트가 발생했다고 판단되는 이벤트 대상을 사용하면 됩니다. 이벤트 위임의 좋은 점은 노드의 갯수를 알 수 없는 경우라도 단 하나의 이벤트 핸들러를 사용할 수 있다는 것입니다. 데이터를 Ajax를 통해 받은 동적 메뉴같은 것을 개발할 때 무척 편리할 수 있습니다.

from Gears and Web Standars on Ajaxian

from Web Archeology: Java Pluglet API on Ajaxian

Ajaxian의 저자 중 한 분인 Dion Almaer씨가 자신의 블로그에 웹 기술의 착상부터 미래까지 다루는 글을 연재하기 시작했다고 합니다.

Ben과 제가 XMLHttpRequest(갑자기 "IE의 어떤 ActiveX"에서 "Ajax"가 되던 기술)를 지원하는 Mozilla의 첫번째 버전의 릴리스 노트를 본 이후로, 저는 나타난 적이 없었을 숨겨진 기술에 관심을 가지게 되었습니다. 릴리스 노트에는 XMLHttpRequest에 대한 언급이 없었지만 FIXprt 같은 기술은 분명 언급되어 있었습니다.

또한, Ajax에 대한 몇가지 흥미로운 점은 그 기술이 1997년부터 가능했었지만, Dilbert 달력이 꽤 많이 지나기 전에는 큰 이슈가 되지 못했다는 사실입니다.

이 점은 과거에도 현재에 부활시킬만한 숨은 진주가 있을지도 모른다는 사실을 말해줍니다. 다시 과거로 눈을 돌려, 저는 어떤 식으로든 흥미로운 것들에 대해 말해야 겠다고 생각했었습니다. 그래서, 웹 고고학에 대한 연재를 하게 된 것입니다. 제가 놓치는 기술이 있다면, 알려주길 바랍니다!

오늘은 Java Pluglet API에 대해 말해볼까 합니다. 이 기술은 모질라의 Blackwood 프로젝트의 일부였으며, 1999년에 Igor Kushnirskiy씨와 Akhil Arora씨가 만들었습니다.

1999년으로 잠깐 돌아가보죠. 무언가를 만들기 위해 수많은 XPCOM, C++ 등과 씨름해야 했던 모질라에서 일하고 있다고 상상해보세요. XUL은 작업을 완료하기 위해 조금 더 웹스러운 기술(XML, JavaScript, CSS, etc)을 사용하죠. 1999년에, Java는 꽤 매력적인 언어였고, 모두가 EJB라는 훌륭한 기술과 함께 멋진 서버측 자바를 준비하고 있었습니다.

Java 개발자가 브라우저 액션에 가담하고 Mozilla를 위한 괜찮은 플러그인을 만들려면 뭘 해야했을까요? 이것이 Java Pluglet API의 출발점입니다. 당신은 C++ 쪽을 흉내내기만 하면 됐습니다:

Pluglet API 가 그것의 C++ 대응부분과 가능한한 닮도록(가능한한 모든 기능을 Java로 반영했다) 설계한 결정은 다분히 의도적이었던 덕에, Plug-in 개발자들은 또 다른 API를 배울 필요가 없었습니다. 우리 생각에는 이 문제가 조금 더 깔끔하고 자바스러운 다른 대체품들보다 우선했습니다. 다른 Plug-in API에 대한 지원은 채택자(contributing adopter)들에 의해 쉽게 추가될 수 있습니다.

pluglet은 mime type을 통해 등록할 수 있습니다. 당신은 application/wicked-cool 라는 것을 만들 수 있고, 서버에서 이 타입이 되돌아가게 되면 Mozilla 브라우저가 이렇게 말합니다 "음, 이 Mime 타입을 이해할 수 없는데요, Pluglet Engine 쪽에선 알까요?"

하이 레벨로 봤을 때, Java로 확장 기능을 작성하는 것은 일리가 있다고 본다. 하지만, 여전히 충분히 로우 레벨 - 많은 일이 가능한 거대 라이브러리 셋을 지원하는 확실한 크로스 플랫폼 - 이기도 하다.

사장되지 않았나요??

아마도요? Ed Burns씨도 참여하게 되어, 최근 프로젝트에 박차를 가하고 있습니다. 활성화의 일환으로 Java와 JavaScript 사이의 직접적인 인터페이스를 제공하고 있습니다.

조금만 눈을 돌리면, 흥미로운 브라우저 플러그인 경로를 알게 될 것입니다. 제가 때때로 C++ 대신 Java 로 만들어진 Gears를 사랑하게 될 거라고 말했죠!

Dimitri Glazkov 씨는 HTML5의 스펙인 사용자 정의 핸들러 지원을 알려주셨고, Ray Cromwell 씨는 Java를 사용해 브라우저를 확장하는 방법으로 그의 GWT 1.5 포스팅을 링크해주셨습니다.

from The performance of your Acid 3 from Ajaxian

Ian Hickson 씨가 Acid 3의 성능면이라는 글을 포스팅했다.

Acid3 테스트는 말한다 "테스트를 통과하려면, 브라우저는 기본값을 사용한 상태에서 애니메이션이 부드럽게 동작해야하고 점수는 100/100 을 받아야 하며 마지막 페이지는 예시된 렌더링과 같이 모든 픽셀이 정확히 일치하게 보여야 한다" (굵은 글씨에 주목해주세요)

"애니메이션이 부드럽게 동작해야한다"라는 말 뜻에 몇가지 의문점이 있다.

그 생각은 브라우저가 표준만큼이나 성능에도 집중한다는 것을 확실히 해주었다. 성능은 표준준수에 해당하는 이슈는 아니지만 모든 웹 제작자와 사용자들에게 영향을 끼친다. 만약 브라우저가 100/100으로 모든 하위테스트를 통과하고 렌더링면에서 모든 픽셀이 정확히 일치한다면(파비콘도 포함해서!), 그 브라우저는 Acid3의 표준 준수 부분을 통과한 것이다. 남은 것은 누가 제일 빠른지 경쟁하는 것 뿐이다.

100/100 을 얻은 브라우저에서 성능 "점수"를 결정하기 위해, 테스트를 두번 실행하고(그러면 브라우저가 캐시를 이용한다), 마친 후에 "Acid3"의 "A"를 클릭한다. 전체 경과시간과33ms 이상이 걸리는 테스트를 알려주는 경고창이 나타날 것이다. 일반적인 DOM과 JS의 연산을 하는 tight loop를 포함하고 있어서 Test 26 만이 유일하게 시간적인 의미가 있는 값을 보여준다. 모든 테스트가 33ms 보다 작다면 "자연스러움" 부문에서의 테스트는 "합격"이다(그렇게 되면 "자바스크립트 에러나 타이밍 문제 없음(No JS errors and no timing issues)." 이라는 글을 보게될 것이다). 이제 남은 이슈는 전체 시간뿐이다 - 다른 모든 브라우저보다 빠른가?

어찌 보면 트집(Ian은 "무슨 하드웨어?"라는 질문을 했다)일 수도 있지만 성능을 표준의 일부로 본 관점은 제법 쿨하다.