Suddenly, in a bit more time than a blink of an eye, "standards support" becomes "less i18n support"

by Michael S. Kaplan, published on 2010/11/12 07:01 -05:00, original URI:

Over the years I've had a lot to say about Digit Substitution, the feature so widely used in so many of the bidirectional scripts and the scripts of South Asia:

and so on.

I think this is most of them.

Most of these blogs have talked about the times that Digit Substitution isn't doing what you might expect, or isn't doing what the people designing it intended, or violates the claims and/or implied behavior in the documentation, or is just plain broken.

But when one considers how long this feature has been around, it really seems unlikely that anyone could ever simply dump the functionality and act like it isn't there or doesn't exist, 1984 "Oceania has always been at war with Eurasia" style, right?

Actually, as it turns out, this kind of assumption would be wrong.

In a bold push to prove how conformant the last two versions of Internet Explorer -- IE 8 and IE 9 -- (present in, respectively, shipping and widely available in beta form) truly is, support for Digit Substitution is not there so much, any more.

Because there is not such a feature in the HTML standard (HTML5 or any other version).

Other browsers like FireFox don't support the idea, either (since their installer is still user locale based for installer UI localization, they are not a model I trust for international even outside the lameness that is international support in HTML they follow, but alas I digress).

Now you can specify you want things the old way that follows Regional and Languge Options and its Digit Substitution settings with a meta tag, like the below HTML snippet:

    <meta http-equiv="X-UA-Compatible" content="IE=7" >

That content note -- 5 or 7 will give you Digit Substitution, and 8 or 9 will not.

Note that if you don't have that meta tag (most pages won't) then it will usually use the same as the browser version, though there are interesting and not-very-well-documented exceptions I found, like in HTML file opened from local or network paths, for example. I can't claim I have found anything reliable except when I specify things. I guess Unspecified behavior seems to be unspecified might provide us all with as bit of irony here....

On this blog, where I have very little control over the per-page meta tags and headers, I cannot really control what this behavior will be on pages.

I had better show this a little, so here follows some art....

First set the Format to Arabic (Saudi Arabia) and hit the Additional settings button:

When that other dialog comes up, set the Use native digits control to "National":

hit OK out of both dialogs, and then the fun begins!

You can see the difference between when that compatibility setting is 5:

and when it is 8:

You clearly see Digit Substitution in Internet Explorer being tied to the support of version-specific behavior and standards mode and all the rest of the work in IE.

Suddenly, in a bit more time than a blink of an eye, "standards support" becomes "less Internationalization support"....

Though there are some related features like the "list-style-type" style that can be applied to ordered lists (the OL element) -- features that require specific opt-in by the author of the web content and the user's preferences have no impact upon it (other than by choosing a browser that doesn't support a given "list-style-type" since the full available list of each browser varies, I mean).

I am still deciding how I feel about all of this.

Part of me feels okay about this, given all of the weirdnesses I have been pointing out for years. There are clearly some very real flaws with this feature.

But on balance I consider the following:

and suddenly I don't feel so good.

Given all of the consequences implicit in the above, having this change in the latest version of Internet Explorer and in a public beta of the next version, when no conversations happened among so many of the stakeholders of the functionality, seems to me to be a little unfortunate....

Especially with web apps becoming more and more popular as they become more sophisticated and able to give richer experiences, losing this particular rich experience may not be so pleasant for some users. Users who LIKE that support.

But maybe that is just me being oversensitive, as one of those stakeholders.

Maybe Windows and the .Net Framework should beef up their parsing and formatting support to work in this new world where you may no longer get your numbers, even if you ask for them....

Note to .Net and Windows globalization people (you know who you are!): you may be hearing from me sometime soon about this!

John Cowan on 12 Nov 2010 7:57 AM:

So what happens when there is a U+206E in the text that IE is rendering?  Does it have effect, and if so, what effect?

Michael S. Kaplan on 12 Nov 2010 8:28 AM:

Unknown -- though the general disdain for the Cf characters in markup situations might have made them less interested in doing much here (and of course U+206e -- aka NATIONAL DIGIT SHAPES -- is also not on any keyboard and is not documented as a way to do digit substitution, either)....

referenced by

2012/05/04 You know, it isn't always about us...

2012/04/16 ‎١‎, ‎٢‎, ‎٣‎ o'clock, ‎٤‎ o'clock digit substitution...

2012/04/12 The evolving Story of Locale Support, part 22: Digit Substitution 2.0

2011/05/12 It will take putting NADS out in front to make a diference

2011/03/31 "Digit substitution is maybe a tolerable hack for displaying UI, but it’s definitely bad if you’re creating content."

go to newer or older post, or back to index or month or day