제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를 통해 오픈소스화 될 것으로 예상합니다.

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

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

  1. Does Chrome for Android support apps and extensions?

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

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

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

  1. Is Canvas hardware accelerated?

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

  1. What about WebGL support?

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

  1. 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/

미투데이로 한마디 트위터로 한마디 페이스북에 한마디
TAG Browser, html5
WebKit에서 구현된 하드웨어 가속과 WebKit-Clutter를 소개합니다.

미투데이로 한마디 트위터로 한마디 페이스북에 한마디
TAG webkit
작년에 이어 WebKitGtk+ Hackfest 2011에 참석했다. 작년에 이어 같은 장소인 스페인 코루나에서 열려서 그런지, 이제 스페인이 제2의 고향 같다는 느낌이 들 정도다. 물론 스페인은 말은 아는게 "올라"가 전부다. ^^;

작년과 다른 점이 있다면 이번에는 너무나 큰 할 일꺼리를 가지고 갔다는 점이다. 그 동안 webkit-clutter 포트에 작업한 Accelerated Compositing 기능을 WebKitGtk+에 적용하는 것! 너무나 큰 욕심이었을까? 집에 돌아와서 겨우 초기 patch를 반영했다. 어찌되었던 동작하는 데모를 만들었다는데 위안을 삼을 수 있었다. 이외 많은 관심사가 논의되고 해결되었다.

WebKit은 정말 뜨거운 프로젝트다. 이런 프로젝트에 참여하고 있다는 것 자체가 신기할 따름이다. 하지만, 나름 WebKit을 일찍 알아보고 꾸준한 관심을 가져온 결과인 것 같다. 2007년에 QT용 WebKit을 처음으로 TV에 포팅했었으니까, 벌써 4년전 일이다. 안타까운 것은 Mozilla 프로젝트에는 관심을 가질 여유가 없다는 점. 다행스러운 점은 WebKitGtk+를 통해 GNOME기술에 눈을 뜬 점.

얼마전 HP WebOS가 오픈소스 프로젝트가 된다는 발표가 있었다. 내년에는 웬지 할일이 더 많을 것 같다.

미투데이로 한마디 트위터로 한마디 페이스북에 한마디
이번에 새로 출시한 Noikia N9에 WebKit2 기반의 QtWebKit이 탑재되었다. Apple 보다 한 발 빠르게 WebKit2 모델을 적용한 것이다. 내년에 Apple에서 먼저 WebKit2를 적용한 Safari를 출시할 것으로 예상했는데, Nokia가 덕분에 좀 더 빠르게 움직일 듯 보인다. 어쨌든, Nokia가 최초로 Mobile용 브라우저에 Multiple Process Model를 도입한 것이다.

Nokia는  Qt5에서 마지막으로  WebKit1 API를 update하고, 더 이상 개발을 하지 않는다고 한다. 앞으로, iPhone에 WebKit2가 적용되면 Native Application과 Web Application간의 경쟁이 더욱 뜨거워 질 것 같다.

미투데이로 한마디 트위터로 한마디 페이스북에 한마디

지난 달에 제 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'')


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

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

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


AddSearchProvider

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

지원하는 interface 는 다음과 같다

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

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

[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider

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

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

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

HTML Media Capture

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


Navigation Timing

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

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


참고


미투데이로 한마디 트위터로 한마디 페이스북에 한마디
WebKit Contributors Meeting 2011
지난 4월 24,25일 미국 Apple본사가 위치한 Cupertino에서 열린 WebKit Contributors meeting 2011에 참석했습니다. 본 행사는 WebKit Contributor가 한 자리에 모여, 당면한 문제와 앞으로 계획 등을 논의하는 자리입니다. 올해가 두번째 열렸으며, unconference형식으로 진행되는 행사입니다. 지난 1년간 함께 WebKit을 개발해온 사람들이 함께 모이는 축제라고도 할 수 있겠지요. 이번 모임에서 어떤 논의가 있었는지 간단하게 소개하도록 하겠습니다.

WebKit은 모바일 브라우저 엔진 뿐만 아니라 Mobile Platform으로도 사용되고 있기 때문에 Apple과 Google뿐만 아니라, Nokia, RIM, Samsung, Motorola, Ericsson, Sony, Igalia, Sencha 에서도 참석하였고, 저도 Collabora를 대표해서 참석하였습니다.  지난 WebKitGtk+ Hackfest 참석 멤버들도 다시 만나서 반가웠고, 제 Patch를 review해주던 Reviewer도 실제로 만나니 더 반가웠습니다. 오픈소스 프로젝트에 참여하는 맛이 이런게 아닌가 싶었습니다. 

진행된 Session과 내용은 대부분 인터넷에 공개가 되어 있어서, 어떤 논의가 오고갔는지 확인할 수 있습니다.  무엇보다도 관심은 WebKit2였습니다. 작년에 Apple이 소개한 WebKit2는 그 동안 Qt와 Gtk+ Port팀도 활발하게 작업을 진행하고 있습니다. 사실, WebKit2는 WebCore를 제외한 API영역과 Web Process와 UI Process를 새로 개발하기 때문에 그리 간단한 일은 아닙니다. 이날도 많은 Issue가 쏟아져나왔는데, 몇 가지를 소개하면 다음과 같습니다.
  • C API사용이 최선인가? 이미 Qt는 C++ API를 사용하고 있습니다.
  • plugin을 별도 process로 실행하기. 곧 Apple이 소스를 공개한다고 합니다.
  •  WebKit1과 WebKit2와 중복 code를 어떻게 줄일까요?
  • DRT를 다시 작성하는일, WebKitGtk+의 경우 WebKit1용 DRT도 아직 완벽하지 않습니다.
  • theaded model 지원하기. mobile device에서 각 page마다 web process를 실행하는 것은 다소 부담스러운 일입니다.
  • web process와 ui process과 통신하는 부분이 너무 platform 의존적으로 개발되어 있어, 뭔가 추상화 모델이 필요합니다.
  • Mac에서 구현한 접근성 기능을 다른 port에서는 따라하기가 쉽지 않다고 합니다.
그 다음 제가 관심을 가진 부분은 하드웨어 가속입니다.  하드웨어 가속은 크게 2D가속, accelerated compositing, WebGL 지원으로 나눌 수 있는데, 논의된 issue 가운데 몇가지를 소개하면, 
  • Canvas 2D 가속하기 : Canvas 2D를 GPU를 이용하여 가속하는 patch가 WebKit에 반영되어 현재 계속 보완되고 있습니다. Google에서 Skia가속을 위해 계속 작업 중에 있고, 실제 Profilng결과, 성능이 빨라지는 부분만 가속하는 방식을 사용하고 있다고 합니다.
  • WebKit2에서 GPU가속: Chromium처럼 GPU Process 실행시켜 구현. 
이외 Build System을 CMake나 GYP로 일원화 하자는 이야기가 있었지만, 결론은 쉽게 나지 않을 것 같습니다.  그리고, 작년에 HTML5 Parser가 WebKit에 추가되면서 Parser코드가 완전히 교체되었는데, 이에 대한 구현 내용을 소개해주었습니다. 기존 Parser코드를 이해하는데 3 개월(?)이 걸린 만큼 복잡한 코드였는데, HTML5 Spec을 반영하면서 새롭게 개발했다고 합니다.  마지막 Session에서는 Review-a-thon 행사가 열렸는데, 100개를 목표로 Patch룰 review하는 시간을 가졌습니다.  제가 행사 때 올린 Patch 하나도 Review가 되긴 했는데, 다른 방식으로 수정이 되었네요.

마지막 날 오후에 작년 처럼 단체 사진을 찍었는데, 운 좋게 가운데 자리에 자리를 잡아서 사진이 잘 나왔네요.

(C) torarnv
비록 각 contributor가 속해있는 회사는 서로 치열하게 경쟁하지만, WebKit 개발 커뮤니티는 더 나은 브라우저 엔진을 개발하기 위해 서로 협력하고 참여를 독려하고 있습니다. 혼자 개발하는 것 보다, 함께 개발하는 것이 비용과 시간을 줄이고 더 나은 기술을 받아들일 수 있는 좋은 방법이라고 믿기 때문이죠.  내년 모임에서는 더 알찬 소식을 전하도록 하겠습니다~
 

WebKit Party Poster

미투데이로 한마디 트위터로 한마디 페이스북에 한마디
브라우저가 단순히 컨텐츠를 탐색하고 보여주는 애플리케이션이라는 울타리를 벗어나, 또 다른 애플리케이션을 실행하기 위한 플랫폼으로 발전하고 있다. 하지만, 현재 구현된 브라우저 엔진만으로 플랫폼 역할을 하기에는 넘어야할 한계가 있는데, 바로 성능과 안정성 확보다. 이를 위해 각 브라우저 벤더는 아래 3가지 측면에서 여러 기술을 브라우저에 도입하고 있다.

1) 다중 프로세스(Multiple Process) 적용
2) 자바스크립트 가속
3) 그래픽 하드웨어 가속

위 세가지 기술은 아직까지 안정화가 필요한 부분도 있지만, 대다수의 브라우저 이미 적용했거나 적용을 준비 중에 있다. 우선, IE9덕에 많은 분들이 관심을 갖고 있는 "그래픽 가속"에 대해 알아보자.

브라우저에 HTML5, CSS3가 본격적으로 적용되면서 웹에서 표현할 수 있는 컨텐츠의 종류가 다양해졌다. 최근에는 WebGL에 표준화되면서 3D까지 지원하게 되면서, 2D뿐만 아니라 3D도 가속해야할 상황에 도달했고, 애플 iPad로 촉발된 HTML5 Video지원도 그래픽 가속 없이는 브라우저에서 HD영상을 재생하기에는 무리였다.  그런데, 마이크로소프트에서 IE9 베타에서 하드웨어 그래픽 가속를 강력하게 표면화 시키면서, 이에 대한 논쟁이 가열되고 있다. 지금까지 가장 빠른 브라우저는 구글의 크롬(Chrome)이라는 공식에 역습을 가한 것이다.

과연 브라우저에서 그래픽 가속이 어떤 의미있고, 현재 어느 수준까지 지원되고 있는지 살펴보도록 하겠다.

그래픽 가속이란?

일반적으로 화면에 어떤 그래픽 요소를 표현하려면, CPU가 계산한 그래픽 데이터를 메인 메모리에서 Frame Buffer로 복사해야 한다. 그래픽 가속이란, 이를 CPU가 아닌 그래픽 가속기(GPU)에 전달된 명령어를 실행하여 하드웨어적으로 처리하여 성능을 높인 것을 말한다. 즉, 그래픽 연산 부터 생성된 데이터를 Frame Buffer로 복사하는 모든 과정을 GPU에서 알아서 처리한다. 그 사이 CPU는 HTML을 다운로드 받고 파싱하는 등 다른 작업을 처리할 수 있다. 참고로, GPU는 CPU와 달리 데이터 병렬성이 풍부해 큰 데이터량을 한번에 계산하는데 효율적이므로, 3D 벡터 데이터나 멀티미디어 데이터 처리에 유리하다.

그래픽 가속의 종류

그래픽 가속에는 크게 2D, 3D, Video 가속으로 나눌 수 있다. 먼저 2D 가속으로 2D 벡터 그래픽, 이미지 프로세싱/디코딩/인코딩, Font Glyph Caching 등을 지원할 수 있다. 2D 벡터 그래픽은 OpenVG라는 표준 API가 존재하고 이를 지원하는 HW가속칩도 존재하지만, 많이 활용되고 있지는 않다. 현실적으로 2D가속은 CPU에서 제공하는 SIMD 연산와 OpenGL과 같은 3D 라이브러리에 의존하고 있습니다. 참고로, SIMD는 Single Instruction, multiple data의 약자로서 하나의 명령어로 여러개의 값을 동시에 계산하는 방식을 말하며, alpha brending이나 Video Format의 color space 변환 등에 사용한다. ARM Coretex A시리즈에서는 NEON이라고 부르는 SIMD연산을 지원한다[1].

비디오 가속의 경우, 모바일 환경에서는 전용 디코더를 하드웨어적으로 내장하는 경우가 많고, PC환경에서는 GPU를 사용한다. 만약 디코더가 내장되어 있지 않은 경우에는, CPU에서 제공하는 SIMD연산을 사용하기도 한다.

3D 그래픽은 OpenGL이라는 표준 API 규약을 이용하여 구현한다. Mesa3D라고 SW적으로 구현된 OpenGL 라이브러리도 있지만[2], GPU벤더들이 자사 GPU에 최적화된 OpenGL 라이브러리를 제공하기 때문에, OpenGL API만 잘 사용해도 쉽게 가속이 가능하다. 윈도에서는 DirectX를 이용해서 3D가속을 한다. 특히, DirectX 10버전에는 Font Glyph를 GPU memory에 cache하고 GPU에서 Anti-aliasing을 처리하여 폰트 출력를 획기적으로 향상시켰다[3].

브라우저에서 그래픽 가속


위 그림은 WebKit을 예로 하여, 그래픽 가속 관점에서 브라우저 아키텍쳐를 그려보았다. 이 아키텍쳐는 주로 모바일 프로세서를 사용하는 아이폰이나 안드로이드폰에서 볼 수 있으며, PC에서는 사실상 모든 그래픽 작업을 GPU에서 처리할 수 있다. 위 그림을 통해 브라우저에서 표현하는 그래픽 요소가 어떤 라이브러에 의존하여 렌더링되고 어떤 HW를 통해 가속되는지 한 눈에 확인할 수 있다. PC의 경우 GPU에서 직접 H.264 비디오를 디코딩할 수 있으나, 아직까지 Mobile에서는 인코더/디코더를 하드웨어적으로 구현하여 사용한다[4].

앞에서 언급했듯이 2D 벡터 그래픽은 GPU로 가속이 가능해서 위 그림에 이를 표현하였고, 마찬가지로 SIMD연산을 이용해서 VIDEO가속도 일부 가능하므로 역시 이를 그림에 반영하였다.

다음에는 브라우저별 그래픽 가속 현황을 살펴볼 예정이다.

참고

[1] ARM NEON
[2] The Mesa 3D Graphics Library
[3] ClearType in WPF
[4] Hardware-based encoding and decoding

미투데이로 한마디 트위터로 한마디 페이스북에 한마디
현재 WebKit에서 구현 중에 있는 css ime-mode property를 잠깐 소개하겠습니다. 이 property를 사용하면 텍스트를 입력할 때, IME를 강제로 동작하지 않게 할 수 있습니다. 예를 들어, 전화 번호 입력할 때, 한글이 입력되지 않도록 브라우저에서 IME사용을 조정할 수 있습니다. 아직은 표준이 아니지만, 이미 IE와 Firefox에서 구현하여 지원하고 있습니다. WebKit만 지원하면, Opera를 제외한 대부분의 브라우저가 지원하게 됩니다. 

<html>
  <head>
    <title>IME Mode test</title>
  </head>
  <body>
    <form>
      <ul>
        <li>ime-mode:active : <input type="text" size="20" style="ime-mode:active;">
        <li>ime-mode:auto : <input type="text" size="20" style="ime-mode:auto;">
        <li>no style : <input type="text" size="20">
        <li>ime-mode:disabled : <input type="text" size="20"
        style="ime-mode:disabled;">
      </ul>
    </form>
  </body>
</html>
직접 위 코드를 Firefox에서 열어보면 마지막 <input> 엘리먼트에서 한글 입력이 안되는 것을 확인할 수 있습니다. 

처음에 이와 관련한 issue를 WebKit Bugzilla에서 찾았을 때, 올레를 외치며 제가 구현할 수 있는 검토를 했었지요. 물론 쉽지 않아보였습니다. 그러다가 잠시 caret color 표시에 문제가 있음을 알고 이쪽 patch를 먼저 작성하고 있는데, 그 사이에 관련 patch가 올라왔습니다. 

아직은 논쟁이 있나 봅니다. 꼭 필요한 기능이냐 부터 브라우저가 구지 IME를 제어해야 하는 등등.. 영어권 사용자에는 그 필요성에 무감각할 수 있으나, 우리 같이 IME로 고생하는 사람에게는 유용한 기능이죠. 이번 patch는 Mac만 지원하므로 Trunk에 잘 적용되면, WebKitGtk Port 쪽에도 구현 issue가 있을 것 같습니다. 

참고

미투데이로 한마디 트위터로 한마디 페이스북에 한마디

HTML5에 추가된  contentEditable 기능이 있습니다. 웹페이지 전체 또는 특정 노드를 편집할 수 있도록 하는데, caret color처리하는 부분이 브라우저 마다 다르고, WebKit 계열 브라우저는 검은색 배경에서는 caret이 보이지 않는 문제가 있습니다.

이런 사소한 부분에 관심을 갖는 분이 얼마나 있을 지 모르겠지만,

caret이 보이나요??

 

 caret이 보이나요??

 

Safar, Chrome을 쓰는 분은 caret이 보지 않을 것입니다. 무조건 검은 색이기 때문입니다. Firefox를 쓰는 분은 보입니다. caret이 text color를 따르기 때문이죠. Opera와 IE를 쓰시는 분도 caret이 흰색으로만 보입니다. Opera의 경우, 흰 배경에서는 다시 caret이 검은색으로 바뀝니다. (이 페이지에서는 동작안하네요)

이 부분에 관한 버그를 리포트하였고, Firefox방식으로 수정했는데, Opera 방식을 선호하는 분도 있네요.


미투데이로 한마디 트위터로 한마디 페이스북에 한마디
TAG Bug, webkit

Rendering in WebKit

WebKit 2010/01/19 00:04


WebKit의  내부 동작을 설명해주는  video입니다. 구글에서 좋은 정보를 많이 공개하네요..

미투데이로 한마디 트위터로 한마디 페이스북에 한마디
TAG webkit