제13차 W3C HTML5 KIG(Korean Interest Group) 회의에서 발표한 최근 브라우저 기술 동향을 정리해보았습니다.

Android용 Chrome 브라우저 베타 출시되었습니다.

몇가지 특징을 살펴보면,

1. Remote Debugging
2. SPDY, SSL Faststart
3. Hardware Accelerated Graphics
4. V8
5. Navigation Timing
6. Large persistent cache
7. requestAnimationFrame
8. Preloading
9. HTML5 APIs

출처: http://gent.ilcore.com/2012/02/chrome-fast-for-android.html

HTML5 Feature를 살펴보면,

1. AppCache
2. FileSystem and File APIs (File, FileList, FileReader, Blob)
3. localStorage for storing simple key-value pairs
4. WebSQL for relational data (deprecated)
5. IndexedDB

지원하는 Device API를 살펴보면,

1. Geolocation API for accessing location
2. HTML media capture for camera access
3. Device orientation
4. Android Intent URIs such as tel: and geo: that give access to the dialer and Google maps

FAQ 가운데, 중요한 것을 살펴보면,

1. Is Chrome for Android Beta open source?

Android용 Chrome브라우저는 소스코드가 공개되어 있지만, 개발 브랜치는 공개되지 않았으므로, 아직까지 100% 오픈소스라고 말하기는 힘들 것 같습니다. 하지만 향후, Chromium Project를 통해 오픈소스화 될 것으로 예상합니다.

2. Does Chrome for Android now support the embedded WebView for a hybrid native/web app?

아직은 지원하지 않지만, Chrome의 WebView를 쓸 수 있으면 독립 프로세스로 진정한 웹앱을 개발할 수 있을 것 같습니다.

3. Does Chrome for Android support apps and extensions?

아직까지 계획에는 없다고 하지만, WebView를 쓸 수 있다면 앱은 가능할 것이고, 확장은 Desktop과 호환성을 갖추기는 어렵겠지만, 독자적으로 지원할 것으로 예상합니다.

4. What version of Flash is supported on Chrome for Android?

Adobe도 이미 Mobile용 Flash를 지원하지 않기로 했기 때문에, 역시 Andrioid용 Chrome도 지원하지 않는다고 합니다.

5. Is Canvas hardware accelerated?

Andorid가 사용하는 2D 그래픽 엔진인 Skia가 HW가속이 되므로, Canvas도 당연히 가속이 됩니다.

6. What about WebGL support?

이 부분은 의외지만, 아직은 안된다고 합니다.

7. Does Native Client work on Chrome for Android?

역시 지원하지 않습니다.

더 자세한 내용은 아래 원문을 참고하세요.

http://code.google.com/chrome/mobile/docs/faq.html

그외에,

Experimenting with WebRTC on iOS

Erisson에서 WebRTC Demo을 iOS에서 보여주었습니다. Erisson은 그동안 WebKitGtk+과 GStreamer를 기반으로 WebRTC를 구현했습니다. 이번에 iOS용 WebRTC App을 만들어서 서로 화상 통신하는 Demo를 보여준 것입니다. 참고로, WebRTC는 Chrome에서도 이미 구현을 해서 공개를 했고, Mozilla도 관심을 갖고 스펙을 만들고 있습니다. 향후, 웹에서 JS에서 사용가능한 WebRTC API 이용해서 쉽게 화상통신 기능을 구현할 수 있게 될 것입니다.

WebKit에서 <shadow> Element 지원

W3C에서 Shadow DOM이라는 스펙을 표준화하고 있습니다. 웹 UI를 구성하다 보면 자연스럽게 여러개의 구성요소로 화면을 나눌 수 있습니다. 사실 각각의 구성요소가 Widget이 되고 별개로 구분하여 재사용 가능할 수도 있습니다.  사실 HTML에서 사용하는 widget류의 element는 내부적으로 별도의 DOM 구조(Shadow DOM)를 갖고 있으나 접근이 막혀있습니다.  <shadow> 엘리먼트를 이용하면 DOM 구조의 경계를 넘나들 수 있게 됩니다. 그래서 CSS를 조정해서 보이는 모습을 변경할 수 있습니다. 테스트가 필요한 분은 이 글을 참고하세요.

마지막으로, Firefox10에 추가된 개발도구에도 관심을 가져주시기 바랍니다.

나머지 소식을 링크로 확인하세요.

1. Reverse directions for CSS Animations are now available
2. Apple has landed support for hardware accelerated CSS Filter animation.
3. Decoding of JPEG images has been improved by 9% on Chromium.
4. WebGL is now able to report errors to Web Inspector’s console.
5. It is now possible to build Samsung’s WebKit EFL port with support for WebGL.
6. Add a custom CSS Lexer for WebKit, doubling lexing performance!

참고

1. http://peter.sh/2012/01/shadow-dom-pointer-lock-and-a-new-css-lexer/
2. http://peter.sh/2012/02/mutation-observers-reversed-animations-and-faster-jpegs/

지난 달에 제 6차  W3C  HTML5 KIG Meeting에 처음으로 참석하게 되었다.  이 모임은 국내 HTML5 표준화에 관심을 갖는 분들이 모여 HTML5 표준화 현황을 나누고 논의하는 자리이다.  이번 모임에서는 HTML5 Web App, Device API, Navigation Timing Spec에 대한 소개가 진행되었는데, 실제 WebKit에서 어떻게 지원되고 있는지  간단하게 정리해보았다.

Custom scheme and content handlers

브라우저에서 사용하는 Protocol이나 mimetype을 임의로 등록하여 특정 URL에서 처리하도록 하는 기능이다. 즉, http://, ftp://와 같은 Protocol을 브라우저에 임의로 등록할  수고 있고, 이를 Protocol로 요청이 들어오면 특정 URL이 처리할 수 있도록 한다. 아래와 같은 인터페이스를 지원하고 있고, 실제 Spec은 여기서 확인할 수 있다.

window.navigator.registerProtocalHandler(scheme, url, title)
window.navigator.registerContentHandler(mineType, url, title)

예) navigator.registerContentHandler('application/x-soup', 'soup?url=%s', 'SoupWeb'')

위 Feature는 WebKit에 구현되어 있지만, 아래와 같이  Build할 때, enable해야 사용할 수 있다. 하지만, 아직은 Chromium에서만 지원하는 듯 보인다.

WebKit/Tools/Scripts/build-webkit --register-protocol-handler

실제 구현은 된 초기patch는 여기서 확인 가능하다. 최근, 이미 사용 중인 protocol에 blacklist 를 각 브라우저 개발 업체로 부터 수집하였고, 이에 대한 처리가 WebKit에 반영되었다.

AddSearchProvider

Search Box에 검색 엔진을 등록하는 기능인데, 이 역할을 UI에서 할지 Engine에서 해야할지 아직 논란이 있다. 이미 IE와 Firefox에서 지원하고 있지만, WebKit Community내에서는 합의가 필요한 상태다.

지원하는 interface 는 다음과 같다. 

window.external.AddSearchProvider()
window.external.IsSearchProviderInstalled()

whatwg에 다음과 같이 제안이 이루어졌고,

[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider

WebKit에도 오래전에 버그로 등록은 되어 있지만, 현재로서는 구현 계획이 없다.

그러면, 브라우저에서는 어떻게 사용하는지 살펴보자.

• Firefox에서 AddSearchProvider 사용하기

• IE에서 AddSearchProvider 사용하기

• Chromium에서 지원

Google에서 WebKit에 반영하도록 노력한다고 하니, 진행 과정을 지켜봐야겠다.
 

HTML Media Capture

Device API Spec은 특히 Mobile분야에서 관심이 많은데, Web App과 Native App간의 경계를 허무는 작업이라고도 할 수 있다. 그 중에서 HTML Media Capture Spec은 User Agent에서 device의 microphone과 camera에 접근하도록 한다. 현재 WebKit에는 버그만 등록된 상태이다.

Navigation Timing

지금까지 웹 성능을 측정하는 일은 브라우저 개발자만이 가능한 일이였다. 브라우저 개발자도 HTTP 모듈까지 소스코드로 접근해야만 어느 정도 측정이 가능했었는데, 이를 웹 개발자도 가능하도록 Navigation Timing이라는 Spec이 표준화 중에 있으며, 이미 Chromium은 지원하고 있고, 데모 페이지에서 테스트할 수 있다. 이를 통해 Page를 요청하여 로딩하는 전 과정에서 얼마나 시간이 걸리는지 단계별로 Profiling 할 수 있게 된다. 현재, GTK+ port, QT port에서 이를 구현하고 있다.

앞으로 매달 열리는 HTML5 KIG Meeting에서 논의된 웹표준 내용을 가운데, WebKit에서 얼마만큼 구현하고 있는 소개할 예정이다.

참고

• 이재환님 Web Application APIs 발표 자료
  

카메라(Camera) 영상이 표시되는 브라우저.

GPS수신기를 이용하여 구글맵(Google Map)에 위치를 표시할 수 있는 브라우저.

아웃룩에 저장되어 있는 일정을 표시하고 웹기반 주소록과 동기화해주는 브라우저.

물론 ActiveX 콘트롤이나 파이어폭스 (Firefox) 확장을 설치하면 뭔들 불가능하겠습니까? 하지만 이제 표준화된 인터페이스를 통해 현실화되고 있는 기능입니다.

이미 우리는 XMLHttpRequest 인터페이스를 통해 변화하는 웹을 경험했습니다. 하지만 이 기능이 처음 등장한 것은1999년  IE5.0이 출시될 때였습니다. 이후, 파이어폭스가 같은 인터페이스를 지원하고 구글맵에서 사용되기 전까지 잘 활용되지 못했습니다. 여기서 우리가 깨달은 것은 어느 한 브라우저만이 자신들만의 확장 기술로 이러한 인터페이스를 구현해서는 안된다는 것입니다.

실험적인 시도는 어떤 브라우저에서도 가능하겠지만, 표준화를 염두하지 않는다면 기술의 확산과 사용에 혼란을 줄 수 밖에 없습니다. 그런 사실을 누구보다 잘 알고있는 브라우저 업체들은 WHATWG를 만들어 더 나은 웹 환경을 만들기 위해 표준화에 앞장서고 있습니다.



그러면,네이티브 인터페이스(Native Interface)가 무엇이고 이를 지원하기 위해 어떤 움직임이 있는 알아보도록 하겠습니다.

네이티브 인터페이스란, 하드웨어 또는 특정 다른 애플리케이션의 고유 기능을 웹브라우저에서 접근할 수 있도록 표준화한 것을 말합니다. 개발자는 HTML 태그 또는 자바스크립트 개체 형태로 사용이 가능합니다. 그리고 앞서 잠깐 소개했듯이, 다음과 같이 크게 두가지로 형태로 구분할 수 있습니다.

• 하드웨어 네이티브 인터페이스 : 하드웨어 고유 기능을 DOM 레벨에서 사용할 수 있도록 인터페이스화 한 것


• 애플리케이션 네이티브 인터페이스: 디바이스에 내장된 특정 애플리케이션 또는 미들웨어의 기능을 DOM 레벨에서 사용할 수 있도록 인터페이스화 한 것

하드웨어 네이티브 인터페이스 경우, 앞서 언급한 GPS, 카메라와 함께 iPhone에서 보여준 사파리(Safari)에서 전화거는 기능이 대표적인 예라고 할 수 있겠습니다. 또한, 파이어폭스에서 GPS 수신기와 연동하는 기능을 구현한 확장이 이미 공개되어 있습니다.

애플리케이션 네이티브 인터페이스 경우, 로컬 주소록이나 일정을 관리하는 미들웨어의 기능을 브라우저 인터페이스로 노출하여 웹애플이케이션이 이를 사용하여 웹페이지에 데이터를 표시하거나 서버에 전달할 수 있도록 합니다. Remember the Milk라는 할 일 관리 서비스에서도 볼 수 있듯이 현재 이런 기능은 전용 애플리케이션으로 구현하고 있습니다.  모질라에서도 Mozila2 플랫폼을 통해 디바이스의 로컬 일정과 주소록을 동기화하는 부분도 구현중에 있습니다. 물론 이 부분이 파이어폭스에서도 사용될 수 있으나, 보안 문제 등 해결할 문제도 많은 것 같습니다.

또한 HTML5의 <video>태그도 애플리케이션 네이티브 인터페이스 중 하나라고 생각할 수 있습니다. 시스템에 설치된 코텍(codec)을 브라우저 표준 인터페이스를 통해 사용하게 되어 모든 비디오 포맷을 동일한 방법으로 사용할 수 있는 길이 열린 것이지요. 또한 지금까지 플러그인(plug-in)을 통해 구현했던 비디오 출력 기능은 다른 윈도우에 그려졌기 때문에 웹브라우저에서 이를 제어할 수단이 많지 않았습니다. 하지만 <video>태그를 통해 웹페이지가 렌더링되는 같은 메모리 공간(surface)에 비디오가 출력되어 서로 합성이 가능해졌습니다. 이 결과 canvas나 SVG를 이용하여 비디오에 다양한 효과를 줄 수 있게 되었습니다. 이미 이미 오페라(Opera)(와 모질라(Mozilla)에서 이를 구현한 결과를 공개하였습니다.앞으로 웹을 통한 새로운 시도가 계속 될 것이며, 이런 발전을 통해 우리가 웹2.0에서 경험한 그 이상의 혜택을 받게 될 것입니다. 단, 이 모든 것은 표준화와 함께해야하며 특정 벤더가 독점해서는 안되겠습니다.

현재 Opera, Apple, Mozilla가 모여서 HTML5 스펙을 만들고 있습니다.
Opera는 그 중 빠르게 HTML5 스펙을 직접 브라우저에 구현하는 회사 중 하나입니다.

이번에 Opera Lab에서 HTML5의 video 태그를 직접 구현해서 공개했습니다.

지금까지 웹브라우저에서 비디오 처리는 Plug-in 방식으로 구현했습니다. 브라우저 및 코덱마다 사용법이 다르기 때문에 개발자에게 비디오 처리는 번거로운 일이였습니다.

하지만, HTML5에서는 모든 코텍을 video태그를 통해 동일한 방식으로 사용할 수 있게 되었습니다. HTML5를 지원하는 브라우저는 공개 코텍인 기본적으로 지원하고, 다른 포맷은 코덱 설치로 지원하게 되었습니다.

이미 Firefox에서도 video태그를 실험적으로 구현하였습니다.

<video controls src="demo.ogg"></video>
<video controls src="demo.ogg" id="myVideo">Theora decoder not found</video>

사용법은 위 예 처럼 무척 단순합니다. 뿐만 아니라 video가 같은 surface에 html과 함께 렌더링되므로 DOM Scripting을 이용하여 video의 동적인 처리도 가능할 것 같습니다.이미 SVG를 이용한 video transform 예도 이미 구현되어 있습니다.

다른 HTML5 스펙도 어서 구현되기를 기대해봅니다.

Future of Web Apps 에서 발표된 자료를 바탕으로 정리한 것입니다.

SVG와 Canvas

SVG는 웹페이지에 벡터 그래픽을 표현하는 표준이고, Canvas는 웹페이지에 Drawing기능을 제공하는 표준입니다. 둘 다 지금까지 웹에서 경험하지 못한 자유로운 그래픽 표현을 위해 HTML5에 추가될 예정이며, 이미 일부 웹브라우저에서는 구현되어 있습니다.

아래 소개하는 예제는 Firefox3 최근 알파 버전에서 동작하며 실험적으로 구현된 기능을 일부 맛볼 수 있습니다.

웹과 Firefox의 앞으로 모습을 잠깐 살펴보시기 바랍니다.

SVG ForeignObject를 이용하면 SVG에 다른 마크업을 임베딩하여 각종 벡터 그래픽 효과를 줄 수 있습니다.

아래 예제에서는 HTML 태그인 <iframe>를 임베딩하여 20도 돌린 효과를 보여주고 있습니다.

<?xml version="1.0" standalone="yes"?>
<svg xmlns = "http://www.w3.org/2000/svg">
<g transform="translate(300, 0) rotate(20)">
<foreignObject x="10" y="10" width="800" height="800">
<body xmlns="http://www.w3.org/1999/xhtml">
<iframe src="http://starkravingfinkle.org/blog" style="width:700px;height:700px"></iframe>
</body>
</foreignObject>
</g>
</svg>

출처: http://starkravingfinkle.org/blog/2007/07/firefox-3-svg-foreignobject/

SVG ForeignObject를 이용하여 동영상을 자유자재로 돌리는 기능을 구현한 예제도 있습니다.

향후, 웹에서도 플래시(Flash)나 실버라이트(Silverlight) 수준의 그래픽 효과를 구현할 수 있을 것 같습니다.

Canvas3D를 구현한 예제도 있는데, firefox3에서 확장을 설치하면 데모를 볼 수 있습니다OpenGL에 thin layer를 제공하여 구현되었고 Canvas 2D처럼 사용하나 봅니다. 실제 해보니 아직은 잘 안되네요.

video와 audio 태그

HTML5에 추가될 video와 audio태그입니다. WHATWG에서 현재 HTML5 스펙을 만들고 있는데, 오페라의 제안으로 video와 audio 태그가 들어간 것 같습니다. 별도의 plug-in 설치 없이 기본적으로 OGG는 동작하도록 하고 다른 파일은 plug-in 형태로 추가됩니다. plug-in이 다르더라도 앞으로는 <video>, <audio> 태그를 통해 동일한 방식으로 멀티미디어 파일을 제어할 수 있게 되었습니다.

 

<video src="BillysBrowser480.ogg" id='v1' style="width: 640; height: 480;"></video>

<script type="text/javascript">
function time_update(v, t) {
t.innerHTML=v.currentTime;
if(!v.paused)
setTimeout(function() { time_update(v, t); }, 1000);
}

function play(video, time) {
var v = document.getElementById(video);
var t = document.getElementById(time);
v.play();
if(time)
time_update(v, t);
}

function pause(video) {
var v = document.getElementById(video);
v.pause();
}

http://www.double.co.nz/video_test/test2.html

Offline Web Application

현재 offline 기능은 Google Gears, 모질라, WHATWG에서 각각 작업을 하고 있습니다. Google Gears는 얼마전에 출시되어 일부 Google 웹서비스에 적용되었습니다. 모질라에서는 SQLite를 이용해서 cookie, cache, bookmark, profile 등의 데이터를 저장할 계획을 갖고 있습니다. 현재는 각각 작업중이지만 Firefox3에서 모두 통합될 전망입니다.

XMLHttpRequest++

Ajax 혁명을 불러온 XMLHttpRequest도 더욱 발전된 전망입니다. 지금까지 하나의 도메인으로만 Request를 보낼 수 있었는데, Firefox3에서 여러 도메인으로 Request를 지원합니다. 웹 어플리케이션의 서버 의존성이 점점 줄어둘고 브라우저 하나만으로 많은 서비스가 가능해졌습니다. 향후 매쉬업 서비스 개발이 더욱 활성될 전망입니다.

참고

http://ejohn.org/blog/future-of-firefox-and-javascript/

이 글은 스프링노트에서 작성되었습니다.