W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2009

RE: [selectors-api] Selectors API I18N Review...

From: Richard Ishida <ishida@w3.org>
Date: Wed, 4 Feb 2009 14:54:36 -0000
To: "'Henri Sivonen'" <hsivonen@iki.fi>
Cc: <public-i18n-core@w3.org>, <www-style@w3.org>
Message-ID: <008901c986d8$7fe10100$7fa30300$@org>

> From: Henri Sivonen [mailto:hsivonen@iki.fi]
> Sent: 04 February 2009 14:26
...

> Existing browsers have shipped already. That code runs the way it
> runs. If new browser versions (that don't yet exist) ended up behaving
> differently wrt. string equality comparison, there'd be a
> discontinuity point in interop.

I agree that there'd be a discontinuity point, but the question in my mind
is whether or not it's a serious one. 

I said earlier in the thread that I think that the number of people who rely
on browsers making a distinction between different byte sequences for
canonically equivalent strings is vanishingly small, and those people are
anyway doing a Bad Thing.  If some current browsers do support normalization
and others don't, we could occasionally have an issue for those who don't
realise that the browser(s) they tested on hid a normalization operation
that others at that time don't.  But the reason for wanting to put this
normalization behaviour in a standard is so that that situation would go
away fairly quickly, in the scheme of things, rather than sticking with a
different problem that will persist for ever.  It seems to me that the net
gain in terms of avoiding confusion and difficulties for users as the Web
expands into the developing world outweighs the problems involved in
changing the way the browsers run.

RI
Received on Wednesday, 4 February 2009 14:54:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 February 2009 14:54:36 GMT