웹브라우저 어떻게 동작하나? - HTML5 대한민국 관심 그룹 9차 회의 발표 자료

Web|2011. 9. 22. 23:19
요즘 화제가 되고 있는 "How browse works"글을 요약 발표했습니다.

댓글()

웹브라우저 안쪽 - HTML처리 과정 (1)

Web|2011. 8. 1. 11:07
http://w3labs.kr/?p=980
미래웹기술연구소 홈페이지로 글을 옮겼습니다.

댓글()

웹페이지 기본 글꼴은 왜 아직도 굴림체인가?

Web|2011. 6. 28. 15:04
Mozilla Bugzilla에 윈도용 Firefox의 기본 글꼴을 굴림체에서 맑은 고딕으로 바꾸자는 버그를 올렸지만, 받아들여지지 않았다. 가장 큰 이유는 윈도95사용자가 여전히 전체 사용자의 절반을 차지 한다는 것과  많은 웹사이트가 여전히 굴림 또는 바탕체를 사용하고 있다는 점이다.

그렇다면, 왜 굴림체를 바꿔야할까?

첫번째 이유는 이름답지 않다는 것이다. 가독성이 높다는 것도 중요하지만, 가독성도 높고 아름다운 글꼴 얼마든지 있다.  아래 Twitter 한글 페이지를 보면, 굴림체가 얼마나 웹페이지를 촌스럽게 만드는지 알 수 있다.

What font is beautiful?
트위터 같은 경우, 웹페이지에 특정 글꼴을 지정하지 않았기 때문에, 기본 글꼴인 굴림체가 사용되었다. 만약 기본 글꼴을 맑은고딕으로 변경하면 아래 그림 같이 표시된다. 훨씬 아름답지 않은가?

두번째 이유는 굴림체가 일본 글꼴에 끼워 맞추어 개발되어 한글의 조형미를 반영하지 못한 부분이다. 

<그림출처> http://www.wikitree.co.kr/main/news_view.php?id=32747

이와 관련된 문제 제기는 오래전 부터 있어 왔다.

역사적 감정으로 글꼴을 바꾸자는 이야기가 아니다. 굴림체가 한글의 아름다움을 충분히 반영하지 못한 부분을 지적하고 싶은 것이다. 한류로 인해 국내 웹사이트에 접근하는 외국인이 많을 것이다. 아마도 그들이 윈도를 사용한다면, 처음 접하는 글꼴이 바로 웹페이지 기본 글꼴인 굴림체일 것이다.

세번째, 이미 MS는 기본 글꼴을 맑은 고딕으로 변경했다. 윈도 비즈타 부터 기본 한글 글꼴은 맑은 고딕으로 변경했고, 최신 Office를 윈도XP에 설치하면 Office UI는 맑은 고딕을 사용한다. 굴림체가 윈도XP의 기본 글꼴임에도 불구하고 유독 Office만 맑은고딕을 사용한다. 심지어 편집할 때도 맑은 고딕을 사용한다.  그 만큼 맑은 고딕은 가독성이나 디자인 측면에서 검증 받은 글꼴이다.

 왜 웹페이지 기본 글꼴을 바꿀 수 없다는 것일까?

첫번째,  IE가 굴림체를 기본 글꼴로 사용하고 있고 동일한 사용자 경험을 제공해야 하므로..

맞는 말이다. 사용자에게 IE나 Firefox에서 동일한 사용자 경험을 제공하는 것은 중요하다. 그렇다면,  나쁜 사용자 경험도 똑같이 따라해야 할까?  개인적으로 윈도7을 사용하면서 유독 굴림체가 눈에 거슬리기 시작했다. 이미 사용자들은 맑은 고딕에 익숙해져서 굴림체가 촌스럽게 느껴지기 시작했고, 이제 웹페이지도 굴림체에서 벗어날 좋은 시기가 된 것이다.

두번째, 많은 웹사이트가 굴림체를 사용하고 있다.
맞다. 많은 웹사이트가 여전히 굴림체 또는 바탕체를 사용하고 있다. 주의 깊게 봐야할 것은 10~12포인트 정도에서만 사용할 뿐 그 이상 크기에서는 굴림체를 거의 사용하지 않고, 대부분 이미지로 대신하고 있다. 그 이유는 굴림체를 확대하면 정말 아름답지 않기 때문이다. 유독 한글 페이지 가운데 텍스트를 이미지로 대신한 사이트가 많은 이유가 바로 굴림체 때문일 것이다. 심지어 모든 내용을 이미지로 보여주는 경우도 많은데, 디자이너들도 역시 굴림이나 바탕체로는 아름다운 웹페이지 만들기가 어렵다는 것을 알기 때문이다.   앞서 트위터에 한국인 디자이너가 있다면 저렇게 굴림체를 크게 확대에서 절대 보여주지는 않았을 것이다. 이렇게, 텍스트르 이미지로 처리하면 많은 부작용이 생기는데, 우선 모바일에서 다운로드 하는데 시간과 비용이 들며, 검색엔진에서 검색이 되지 않는다.

글꼴을 사용자의 취향이라고 생각하기에는 잘못된 기본 글꼴이 주는 피해가 이처럼 큰 것을 알 수 있다. 윈도 플랫폼에서 이제 더 이상 굴림체를 고집할 필요는 없다고 생각한다. 이미 윈도 비즈타 부터, 맑은 고딕이라는 좋은 글꼴이 시스템 폰트로 사용되기 시작했다. 이제 웹페이지도 윈도 사용자를 위해 기본 글꼴에 맑은 고딕을 추가해야 하고, 브라우저도 맑은 고딕을 기본 글꼴을 지정해야 한다. 좀 더 아름다운 한글의 모습을 보고 싶다면, 먼저 변해야 한다.

댓글()

미래웹포럼 2010 못 다한 이야기..

Web|2010. 11. 9. 10:46
아는 것과 그것을 글로 쓰는 것 그리고 말하는 것은 참 다른 것 같습니다. 제일 어려운 것은 역시 말하는 것이죠. 전문 분야에 있는 분들이 참석하는 것이라 나름 열심히 준비했는데, 늘 그렇지만 아쉬움이 남네요.

국내에 생각보다 WebKit을 하시는 분이 많습니다. 이미 커미터가 된 분도 두 분이나 있고, 심심치 않게 WebKIt 관련 블로그/트위터 글도 많이 봅니다. 다음에는 이런 분들과 WebKit에 관한 깊이 있는 이야기를 하면 좋을 것 같습니다.

참고로, 미래웹포럼 홈페이지와 제가 발표한 WebKit자료는 여기에 공개되었습니다.

발표에서 제외된 부분을 잠깐 소개하겠습니다. 일종의 디렉터즈 컷(?).

구글이 제안한 SearchBox API
DOM API로 Chrome(Browser window)에 있는 Search Box를 제어하는 것인데, 기본 Search Provider만 해당 API를 사용할 수 있다고 합니다. 거의 구글만 사용할 수 있겠네요. URL바를 검색창으로도 사용하는 Chrome브라우저에서는 유용한 기능입니다. 굳이 Google Search Page에 접속하지 않아도, 검색 추천어를 미리 볼 수 있수 있습니다. Apple의 반대로 WebKit에 반영되기는 힘들어 보입니다.

참고
https://lists.webkit.org/pipermail/webkit-dev/2010-October/014779.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028818.html

HTML5 Media Capture
Media Capture는 Device에 장착된 외부 기기로 부터 stream 데이터를 주고 받는 기능인데, camera나 스캐너를 대상으로 표준화가 진행 중에 있습니다. 브라우저에서도 화상통신이 가능할 날도 머지않은 것 같습니다. 이미 Ericsson은 WebKitGtk에 구현을 했군요. 소스 공개를 아직 안했는데, 이러다가 누가 먼저 patch 올리면 어찌하려고..

참고
https://bugs.webkit.org/show_bug.cgi?id=43572
http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices

그외 이번 행사 후기...

WebKit에 대한 주도권 경쟁 치열
Apple이 WebKit Project를 시작했지만, Google이 참여하면서 주도권 경쟁이 치열합니다. 각 Port별로 어떤 기능이 추가되는 것은 별 관심이 없지만, 일단 WebCore에 추가되는 부분은 두 회사, 특히 Apple의 최종 허락 없이는 patch가 반영되지 않는 것 같습니다. 물론, Apple은 논의도 없이 WebKit2를 공개하고 발표해버렸습니다. 먼저 시작한자의 특권이죠.
이미 Multiple Process 모델을 적용한 Google은 뒷통수를 맞은 느낌(?), 따라가는 다른 회사는 힘겨워진 것이죠.

IE9에 주목하자
Microsoft는 한번 실행에 옮기면 정말 무섭게 파고드는 회사입니다. IE를 처음 개발할 때도 그렇고, Office시장을 차지할 때도 그랬습니다. MS가 HTML5에 투자하기로 결정한 이상, IE9이 이끌어갈 웹의 미래도 기대가 됩니다. DHTML, XMLHttpRequest와 같은 기능을 IE에서 처음 시작했다는 것을 잊지 않고 있기 때문이죠. 모바일은 좀 늦었지만, 뭔가 새로운 것을 내 놓겠죠?

미래의 플랫폼, 웹!
모든 handset 제조사/이통사가 웹플랫폼에 많은 투자를 하고 있습니다. 2차 스마트폰 전쟁에서는 iPhone에 완패했고(1차는 Windows Mobile vs. Palm), 안드로이드로 버티고 있지만, 이 역시 그들이 주도하고 있는 것은 아닙니다. 웹 플랫폼 중심에 WebKit이 있고 더 많은 업체의 참여가 이루어질 전망입니다. 그 예로, 모토로라가 지금은 안드로이드에 올인하고 있지만, 뒤에서 열심히 WebKit개발에 참여하고 있습니다. 그 만큼 변화, 발전 속도도 빠르겠지요.  작은 힘이나마 그 안에 동참하고 있다는 것이 즐겁네요.

내년 미래웹포럼에서는?
내년에는 Windows7 Phone 브라우저가 소개될 것 같습니다. 그 때면 국내에도 Windows7 Phone이 출시되어 있겠죠? 내년 초에 Firefox4, IE9이 공식 출시되니, 이에 대한 이야기도 뜨거울 것 같습니다. WAC, 웹스토어 대한 이야기도 논의될 것 같습니다. 아마 내년이 웹 애플리케이션 스토어가 시작하는 원년이 되지 않을까 생각합니다. HTML5 저작도구에 대한 소개도 있을 것 같습니다. Adobe또는 MS에서 멋진 툴을 베타 수준에서 준비할 것 같습니다.

그럼, 내년 행사에서 만나요~

댓글()

웹 브라우저 테스트하기

Web|2010. 8. 20. 13:08
모든 소프트웨어가 번거로운 테스트 단계를 거치지만, 웹 브라우저를 테스트하는 일은 좀 더 어렵습니다. W3C 표준에 맞게 기능을 구현해야 하며, 표준화가 미흡한 부분은 다른 브라우저와 비교가 필요합니다. 이렇게 표준을 잘 지켜 브라우저를 개발했다고 하더라도 표준을 벗어난 형태로 작성된 웹페이지도 있고, 현실적으로 모든 웹페이지를 다 테스트할 수 없기 때문에 모든 사람을 만족시킬 수 있는 브라우저를 개발하는 것은 불가능한 일입니다. 웹페이지를 작성하고 테스트하는 것도 마찬가지이겠죠. 모든 브라우저가 표준만 잘 지켜면 좋으련만 기기마다, 플랫폼 마다, 브라우저 마다, 버전 마다 다르게 동작하기 때문에 많은 테스트가 필요합니다. 본 글에서는 다양한 각도로 웹 브라우저를 테스트하는 방법을 한 번 정리해보았습니다. 크게 브라우저 기능, 자바스크립트 성능, 그래픽 성능 테스트로 나누어 설명합니다. 

웹 브라우저 기능 테스트

HTML5 테스트


HTML5 관련 API, 마크업이 있는지 확인해 주는 웹페이지입니다. 단지, 확인만 하기 때문에 정상적으로 동작하는지는 알 수 없습니다. 일단, 잘 동작한다는 가정 아래 어느 정도 HTML5 관련 기능을 구현했는지 확인해볼 수 있습니다.

웹사이트 주소: http://www.html5test.com/

W3C CSS 테스트

<표1> CSS Test Suite 개발 현황 (출처: http://www.w3.org/Style/CSS/Test/)

W3C에서 공식적으로 제공하는 CSS 테스트 스위트(Test Suite)입니다. 회원사에서 기여한 테스트 케이스( Test Case)를 정리한 것으로, 웹에서 바로 테스트할 수 있도록 하였습니다. 자동화된 것은 아니고, 일일히 사람이 확인해야 하는 불편함이 있으나 표준화된 내용 하나하나를 직접 확인해 볼 수 있습니다.

웹사이트 주소 http://www.w3.org/Style/CSS/Test/

CSS Acid1 테스트

원래 Box Acid Test라고 불렀으며, 1998년에 개발되었습니다. 브라우저가 CSS1.0 표준을 잘 지원하는 테스트합니다. CSS1.0은 글꼴 속성, 텍스트 색상, 배경 그림, 엘리먼트 Margin, border, padding, 위치 등을 다룹니다. 


CSS Acid2 테스트

Acid2 Test
Acid2 Test는 주로 CSS 2.1 사용하여 HTML 레이아웃 렌더링이 잘 되는지 확인합니다. HTML 마크업, CSS2.1 Styling, PNG 이미지, Data URIs 등을 테스트합니다.

웹사이트 주소 http://acid2.acidtests.org/

CSS Acid3 테스트


Acid3 Test는 웹브라우저가 DOM과 자바스크립트와 관련하여 웹표준은 얼마나 잘 지키고 있는 확인합니다.

웹사이트 주소 http://acid3.acidtests.org/

JavaScript 성능 테스트

애플(Apple)에서 사파리 브라우저에 스쿼럴 피시(SquirrelFish)라는 자바스크립트 엔진을 적용하면서 자바스크립트 성능 논쟁이 뜨겁기 시작했습니다. 구글(Google)도 이에 뒤질세라 V8이라는 자바스크립트 엔진을 크롬 브라우저에 적용하면서 브라우저 성능 경쟁에 뛰어들었습니다. 모질라도 동참했습니다. 이들 회사가 자바스크립트 엔진만 개발한 것이 아니라, 성능까지 측정할 수 있는 최근까지 벤치마크(Benchmark)를 함께 공개했습니다.
 
개발 회사 벤치마크 특징
모질라 Dromaeo SunSpider와 JavaScript Engine Speeds
기반으로 개발
구글 V8 Benchmark 기존에 개발된 벤치마크 코드를 자바스크립트로 구현하여 사용
애플 SunSpider 실제 사용되는 자바스크립트 코드 사용
<표2> 자바스크립트 주요 벤치마크 스위트

드로마에오(Dromaeo)

JQuery를 개발하고 현재 모질라에서 근무하는 John Resig이라는 분이 개발한 자바스크립트 성능 테스트 스위트입니다. SunSpider와 JavaScript Engine Speeds기반으로 개발되었습니다.

웹사이트 주소 http://dromaeo.com/

V8 Benchmark

구글에서 개발한 V8 자바스크립트 엔진의 성능을 평가하기 위해 개발된 벤치마크 스위트입니다. 

웹사이트 주소 http://v8.googlecode.com/svn/data/benchmarks/v5/run.html

SunSpider

애플사에서 만든 자바스크립트 벤치마크로서 JSON 입력으로 부터 태그크라우드(tagcloud)생성, 3D 레이트레이서(raytracer), 암호기법( cryptography) 테스트, 코드 압축해제(code decompression)등과 같은 실제 문제를 포함하고 있습니다. 실제로 많은 웹 브라우저 벤치마크에서 SunSpider를 사용하고 있습니다.



재미있는 것은 각 벤치마크가 자신들의 자바스크립트 엔진에서 좋은 결과를 보여준다는 것입니다. 테스트케이스를 어떻게 선정하느냐에 따라 결과가 다르게 나올 수 있으므로, 여러 벤치마크 스위트를 사용하여 브라우저의 성능을 테스트하는 것이 좀 더 객관적인 판단을 내리는데 도움을 줍니다. 참고로, 2009년 9월에 FavBrowser.com에서 실시한 웹브라우저 벤치마크에서 크롬2가 높은 평가를 받았습니다.

<표2> 웹브라우저 벤치마크 평가(2009.9) (출처: FavBrowser.com)

그래픽 성능 테스트

마이크로소프트에서 지난 3월 IE9 Preview와 함께 "Internet Explorer9 Test Drive"라는 성능 평가 사이트를 공개했습니다. 사실 IE9보다 이 웹사이트가 더욱 흥미로웠는데, 그 동안 다른 브라우저에서는 중요하게 생각하지 않았던 그래픽 성능 데모가 추가되었기 때문입니다.  특히, IE9이 하드웨어 그래픽 가속을 장점으로 내세우면서 앞으로 자바스크립트 성능 못지 않게 2D/3D 그래픽 가속이 브라우저 성능 평가에 중요한 기준으로 자리잡을 전망입니다.


다음에는 "오픈소스 브라우저 엔진은 어떻게 테스트하는가?"라는 제목으로 Mozilla, WebKit의 테스트 방법을  정리하는 기회를 갖도록 하겠습니다. 고맙습니다.

참고




댓글()

미래 웹포럼 2009 후기

Web|2009. 9. 9. 13:32
지난 9/4(금)에 미래 웹 포럼 2009 워크샵 행사가 성황리에 끝났습니다. 많은 웹 개발자, 기획자, 학생 분들이 참석하셨고, 패널 토의까지 많은 분들이 남아서 눈 앞에 등장한 HTML5와 모바일 웹에 대한 관심을 보여주셨습니다.

이번 행사에서는 저는 "Fennec의 현재와 미래" 제목으로 Fennec 개발 진행 상황에 앞으로 계획에 대해 소개하였습니다. 그 동안 Fennec 개발에 참여하면서 얻은 정보와 주요 Fennec 개발자 블로그를 참고해서 가능한 모질라의 개발 의도를 잘 전달하려고 노력하였습니다. 더불어 Samsung Windows Mobile SDK도 소개하였습니다. (다른 분들의 발표 내용은 여기에)

참석자 분들이 대부분 웹개발자인데, 너무 Fennec 구현에 대한 기술적인 내용을 많이 언급하지 않았나 싶습니다. Device API도 웹개발자 보다는 Add-ons이나 XUL 애플리케이션 개발자에게 관심가는 주제가 아니였나 생각합니다.

부족하지만, 그날 참석을 못한 분은 동영상과 발표 자료를 보시면 Fennec의 개발 진행 상황을 이해하는 도움이 될 것 같습니다.

아울러, 이번에 공개된 Fennec 1.0 beta3 for Windows Mobile를 옴니아를 비롯한 국내에 출시된 Windows Mobile 단말에 설치해 보시고 테스트해서 버그를 올려주시면 좋겠습니다. 특히, 국내 옴니아는 해외 옴니아와 사양이 달라서 Fennec 개발자들이 문제를 잘 모를 수 있습니다.

옴니아2는 이미 해외에서 출시되어 bugzilla에 버그가 등록되고 있습니다. 국내에도 출시되면 Fennec의 사용자가 많이 늘어날 것 같습니다.

패널 토의에서는 HTML5에 대한 많은 이야기가 오고 갔습니다. 과연 앞으로 HTML5를 무장한 웹이 Mobile Application Platform이 될 수 있느냐가 큰 관심이였습니다. 웹개발자에게는 모바일에서 widget뿐만 아니라 애플리케이션 개발까지 관심 영역을 확대할 수 있는 기회가 될 수 있기 때문입니다.

시기는 무르익었다고 생각합니다. Widget은 그 다리 역할을 할 것이고, Palm Pre와 앞으로 출시될 Goolge Chrome OS에 볼 수 있듯이 HTML5가 모바일 애플리케이션 개발에서 큰 역할을 하게 될 것입니다.

Samsung  Mobile Innovator에서 이번에 공개한 Widget 개발툴도 좋은 예인 것 같습니다. 아직은 해외 삼성 단말만 적용되지만, 이런 Widget 개발툴을 미리 경험하는 것도 앞으로 다가올 미래를 대비하는 좋은 방법이 될 것 같습니다.

댓글()

오픈웹 관련 만화 두편

Web|2009. 4. 2. 21:13
오픈웹 이야기

kldp_linux_banking

몇 년전에 그린 그림인데, 아직도 상황은 변한게 없군요~ :-(

고려대 김기창 교수님이 이끄는 오픈웹이 금결원과의 민사 소송 2심에서 패소한 이후, 오픈웹(OpenWeb)에 대한 많은 이야기가 인터넷을 달구고 있습니다.

저도 오픈웹 운동이 시작된 이후로, 꾸준히 관심을 가지고 동참하고 있었는데, 정말 안타깝습니다.

ActiveX라는 거대한 폭탄을 안고 있는 국내 사용자들은 Windows와 Intenet Explorer를 업그레이드 할 때 마다  끊임 없이 발생하는 크고 작은 문제들로 불편함을 겪고 있습니다. 또한 맥과 리눅스 사용자는 브라우저를 통해 금융 거래를 아직까지 못하고 있습니다.

하지만, 여전히 개선될 희망이 보이지 않고 있습니다.

이러한 상황에서 가뜩히나 월드 가든(Walled Garden)에 갖혀버린 우리나라의 모바일 웹은 뿌리를 내릴 수 있을까요?

댓글()

웹 브라우저에서 네이티브 인터페이스 지원하기

Web|2008. 2. 3. 20:56
카메라(Camera) 영상이 표시되는 브라우저.

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

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

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

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

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

Supporting Native Interfaces on the Web

그러면,네이티브 인터페이스(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에서 경험한 그 이상의 혜택을 받게 될 것입니다. 단, 이 모든 것은 표준화와 함께해야하며 특정 벤더가 독점해서는 안되겠습니다.

'Web' 카테고리의 다른 글

미래 웹포럼 2009 후기  (2) 2009.09.09
오픈웹 관련 만화 두편  (0) 2009.04.02
생활속의 오픈웹(OpenWeb) 운동  (3) 2007.12.27
Opera 브라우저의 HTML5 Video 태그 구현  (0) 2007.11.15
다음 DevDay 2007 참석 후기  (3) 2007.09.04

댓글()