- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Fri, 3 Jan 2014 16:44:32 +0200
- To: "www-international@w3.org" <www-international@w3.org>
On Thu, Jan 2, 2014 at 10:02 PM, Liam R E Quin <liam@w3.org> wrote: > Note that there are plenty of other cases where an encoding is wrongly > marked that this change would not solve. True. As seen in Firefox telemetry, the most common case is overriding the encoding of a labeled page. But it's unclear how much that really helps, considering that the next most common case is overriding a previous override (i.e. the previous attempt at overriding evidently was not successful). > Solving the most common case is > a good thing to do, but it won't obsolete the need for an override menu. Outside developer tools that allow arbitrary DOM editing browsers don't provide user override UI except for two classes of authoring error: bogus character encodings and bogus TLS certificates. And for both of these, there is already a way for the author to remove the override UI (BOM and HSTS, respectively). There's a vast variety of other kinds of authoring errors for which everyone seems to accept that browsers don't provide UI for users to repair severe authoring errors. That is, not providing UI for fixing authoring errors is the norm. At some point, mis-labeling the encoding might be able to join that category of errors. However, *politically* for that to happen, the frequency of encoding menu usage in the CJK locales needs to become similar to other locales. I expect this feature to help on that point. Once the notion that removing the menu is would disproportionately hurt particular locales goes away, we can wait until we see enough nines after 99.99% unuse and eventually decide the menu is unused enough not to be worthwhile anymore. (Chrome already buries it so deep in the submenus that one has to wonder if it's worthwhile to have UI that's so hidden away from users.) -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Friday, 3 January 2014 14:45:00 UTC