On Mon, Nov 30, 2015 at 7:09 PM, Jörg Knobloch <jo...@jorgk.com> wrote: > As far as I see, there are no objections to removing the ISO-2022-JP-2 > variant as long as the ISO-2022-JP is maintained.
Cool. This intent is indeed scoped to the -2 stuff only. On Mon, Nov 30, 2015 at 7:21 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Mon, Nov 30, 2015 at 7:38 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> Other browsers don't support this extension, so it clearly can't be a >> requirement for the Web Platform > > Generally speaking, I don't think this reasoning is entirely accurate. > We know that there's lots of browser-specific code paths out there, so > just because other browsers don't support a given feature doesn't mean > that removing it from gecko won't affect our users. What you say is a concern in the general case, yes. In the specific case of encodings, it is *very* unlikely that sites would serve ISO-2022-JP-2 on a per-browser basis. First of all, if a site has the capability to vary the character encoding of the HTML it generates, that capability has been fundamentally useless for the past decade: Just use the capability to generate UTF-8 for everyone and then quit varying the output. But Web authors (as a collective, no insult to specific clueful Web authors implied) are known to do fundamentally useless per-browser things, so maybe the above isn't convincing. Let's consider what a hypothetical site that server ISO-2022-JP-2 to Firefox would serve to other browsers: If the site wanted to use JIS X 0212 characters, it could send EUC-JP to other browser. But if you can generate EUC-JP, there's no upside to be had from sending ISO-2022-JP-2 to Firefox. Firefox has had EUC-JP all this time. There's no reason for anyone to have done this instead of using EUC-jP for all browsers. If the site wanted to use Chinese, Korean, Western Latin and Greek characters alongside Japanese ones, it could send UTF-8 to other browsers, but again, if you can send UTF-8, just send UTF8 to everyone, including Firefox. What if the site sends ISO-2022-JP + numeric character references to other browsers? This implies the capability to do more complex re-encoding, since you need Unicode scalars for the NCRs. However, if the site depended on ISO-2022-JP inheriting into CSS and JS, this could be a silly fix that just sending UTF-8 would break. But it seems unlikely that someone is clueful to design for this all the while not being the sort of author who addresses the problem with UTF-8. Finally, one might postulate an Emacs MULE user to have created some content not caring about non-*nix users at the time when "everyone" on *nix used Gecko. Or an insecurely implemented email-to-Web archives containing messages sent from Apple's Mail. However, we aren't in the business of supporting hypothetical Gecko-only fringe content. (Firefox 43 removes support for the previously Firefox-only Unicode-at-On feature of Big5, for example.) > Getting telemetry data is generally a better way to go. ISO-2022-JP in general affects just 0.05% of Firefox release channel sessions. It's reasonable to assume the number to be higher for users who read Japanese and even lower for everyone else. We don't have telemetry for the -2 subfeature, but it has to by *tiny*. Note that even the less popular ones of the many Cyrillic legacy encodings affect a larger proportion of sessions *each* (except KOI8-U). On Mon, Nov 30, 2015 at 8:24 PM, Adam Roach <a...@mozilla.com> wrote: > On 11/30/15 09:38, Henri Sivonen wrote: > > The only known realistic source of ISO-2022-JP-2 data is Apple's Mail > application under some circumstances, which may impact Thunderbird and > SeaMonkey. > > > Does this mean it might interact with webmail services as well? No, for the reasons others gave. The change would be relevant to the Gaia email app to the extent it's relevant to anyone at all. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
