For many people, the browser is the essential and principal human interface to the Internet. Because of this, IDN support in browsers is essential. The good news is, in 2019, support for IDNs in major commercial browsers is excellent.
In the past, a browser was a separate piece of software (an “application”) that made requests of web servers and rendered the results of those requests on a display. Today’s browser appears in cars, on tablets, on watches and in settings that wouldn’t have been imagined ten years ago. Even so, IDN support remains crucial. In today’s Internet, a human uses a piece of software to dynamically interact with services and content, and to act as a go-between between complex software, content and people. That we call such a tool a ‘browser’ is more of a nod to the history of the Internet than a reflection of what that tool actually does.
In 2019, we note:
- Traditional, standalone browsers from major developers have excellent support for IDNs;
- Smartphones, tablets and similar mobile devices have seen significant improvements in acceptance, use and display of IDNs;
- Success for IDN universal acceptance in applications that use the world wide web depends largely on underlying operating system and development library support for IDNs; and,
- IDN support in alternative devices – for instance, auto dashboards or community kiosks – is largely dependent on the underlying browser being used to make http requests and parse the results of those requests. There is progress when the underlying browser comes from a major browser vendor, but much less progress (in terms of IDN support) when we see vendors trying to build their own, custom browser components.
Desktop and Laptop Browsers
As in previous years, in 2019 we tested IDNs on seven browsers in “traditional” desktop settings:
- Internet Explorer
In future testing we may make a change to our methodology in that Microsoft’s approach to marketing browsers is changing significantly. We may remove Internet Explorer from the test suite and concentrate on Microsoft’s Chromium-based Edge browser instead. It should also be noted that our methodology assumes that the relevant language packs for each ecosystem are installed correctly.
For each browser our methodology remains the same as in previous years:
- Does the browser correctly resolve an IDN URL and display the appropriate page when the IDN is entered?
- Does the browser correctly display an IDN URL in the location (URL) box once the page has been loaded – for instance, the punycode version is not displayed?
- Do internal links on the page display as IDNs and not punycode?
- Is it possible to enter IDNs into form fields when displayed by the browser?
- Are IDNs rendered correctly in browser “furniture” – for instance, tabs, the browser status bar, bookmarks and other places where domain names appear under the control of the browser?
URLs and pages are tested in the following scripts: Arabic, Chinese (Han), Korean (Hangul), Japanese (Han, Katakana, Hiragana) and Cyrillic.
Where possible, the browsers are tested using Windows 10, Mac OS 10.14 (Mojave) and Ubuntu 18.04.
In 2019, the results of this testing showed marked improvement over previous years. All seven browsers tested, on all three platforms (where available), are able to correctly resolve an IDN URL when it is typed, or pasted, into the location box. In each case, the browsers were also able to correctly display the IDN URL in the location (URL) box.
Display of an IDN is often dependent on support for the script in the operating system. If operating system language support is available and if the IDN URL is passed as a unicode string (and not punycode), each one of the browsers successfully displays the IDN URL as part of the content of the page. This metric is dependent on two things:
- the configuration of the machine; and
- the HTML being processed for display.
As an example, in the case of Windows 10, if the machine has not been configured for language support, some browsers revert to displaying the punycode rather than the unicode equivalent. In addition, if a web page delivers internal links that are in punycode, no browser was found that converted those back to their IDN equivalents for display. As we have noted above, our methodology for testing assumes that the relevant language packs for each ecosystem are installed correctly.
An improvement, this year, is that IDN rendering in parts of the browser that are not the URL or location bar has become much more predictable. In the past, proper handling of the URL in the location bar has become a success story. However, a browser has many places where it can display an IDN. What has improved, with all seven browsers, is the correct display of IDNs in places like bookmarks or other, so-called browser ‘furniture.’
Last year we noted that there was variation in how IDN bookmarks are stored and displayed. One problem is that in two of the seven browsers tested the browsers converted IDN URL to punycode before storing the bookmark. Subsequent display causes the descriptive text of the bookmark to appear correctly, but last year the IDN was displayed as punycode. In 2019, this has been corrected and a user, clicking on an IDN in a list of bookmarks, can reliably see the IDN in the address bar as the browser requests the page.
Mobile and Embedded Browsers
If IDNs are to be usable everywhere, then the marketplace’s emphasis on portability and size needs to also reflect acceptance of IDNs. In particular, smartphone, tablets, e-readers and other portable devices should show the same progress in accepting, using and displaying IDNs as desktops and laptops do. As in previous years, we examined Chrome, Firefox, Safari and Opera in (where available) Android and iOS-based devices.
This year showed no change over 2018. Three of the four tested mobile browsers allow the correct entry, resolution, and display of IDNs. However, we noted a different trend this year. While we have no quantitative data to compare to previous years, it appears that there is a growing reliance on popular browsers for display of web-based content, rather than development of customised browsers in embedded devices. If this trend is accurate, then improvements in browsers from mainstream browser developers would “trickle-down” to applications designers who needed to incorporate web content in their apps. That would result in an evolutionary improvement in support for IDNs in mobile applications. A similar trend seems to be happening in automobiles, where automobile manufacturers are moving away from bespoke, custom applications for passengers toward automotive infotainment systems based on iOS or Android. Once again, if true, this is a welcome development given that both of those environments are making substantial progress in supporting IDNs in mobile and embedded browsers.