[webkit-dev] Proposal: Use ICU in WebKit code

[Darin Adler]

Hi folks.

A while back the WebKit project made use of ICU directly. There were some port maintainers who instead wanted to make WebKit work without ICU. At the time, the strategy we pursued was to make a Unicode layer in WTF that layered on top of ICU. We then created multiple implementations of that layer on top of other back ends.

But this Unicode layer is simply an awkward renamed subset of ICU. I find it inconvenient when doing work that requires ICU features and it has held back my work in the past.

At this point we are down to only two back ends: The one for ICU, and one that is implemented on top of Windows functions, UnicodeWchar.h/cpp. I believe UnicodeWchar is currently used only by the WinCE port. A number of the UnicodeWchar implementations are not complete. For example, the toLower function does not handle the “ß” character.

I suggest we remove the Unicode.h abstraction and use ICU directly. I suggest we continue to use the ICU C API, by the way, not the C++ API.

For the WinCE port, I suggest we do one of these two things:

A) Change the port to require the ICU library.

B) Implement a subset of ICU that is enough to compile WebKit, using implementations quite like the ones in UnicodeW.h/cpp today, but using the ICU function names and constants, rathe than an abstraction layer invented for WTF.

Thus, code in WebKit can make use of ICU directly in a way that’s easier to understand. Any port that wants to work without ICU can implement an ICU subset compatibility layer in a way that does not require changes to the WebKit code.

I am not in a good position to test this ICU subset compatibility layer, but I think it would be a quick easy job to refactor UnicodeWchar.h/cpp into that form.

Any thoughts on this? I am not sure what the status of the WinCE port is, but I’d like to hear from the maintainers of that port on the port status and their view on this strategy.

— Darin