[Webkit-unassigned] [Bug 17873] Encoding override should not be persistent

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=17873


jshin at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-                     |jshin at chromium.org
                   |unassigned at lists.webkit.org |




------- Comment #13 from jshin at chromium.org  2009-02-10 16:33 PDT -------
(In reply to comment #12)
> > Firefox does NOT have this issue.
> 
> I meant, it doesn't work well with this site, in the same way that WebKit would
> if we took the patch (modulo encoding auto-detection). Sorry for being unclear.

Thank you for the clarification. 

> Option 2a sounds reasonable, if we decide that the current behavior is broken
> (which I don't think we have established already).

As for whether the current behavior is better than that of what's proposed (or
that of Firefox), consider the following scenario:

  1. A user on Mac overrides the encoding to MacCyrillic at www.mdf.ru because
the site does not specify the encoding (http, meta) and his default encoding
(to use in such a case) is Windows-1251. 
  2. He browses for a while at the site and everything seems fine.
  3. He goes to another site which correctly specifies the encoding (either
meta or http) that is not MacCyrillic. (say, news.google.ru in UTF-8)
  4. Despite 3, still MacCyrillic will be used totally garbling the page. 
  5. He has to override once more to UTF-8.
  6. He moves to yet another site that correctly specifies the encoding (this
time, ISO-8859-5. I'm on purpose not taking an example of Windows-1251 - the
default encoding of the user in this case to make the case clearer). 
  7. It's garbled (because now UTF-8 is in force) and he has to 'overrides' the
encoding once more to ISO-8859-5


Steps 3/4/5 and 6/7 have to be repeated everytime a user moves to another site
with an encoding different from the current overriden encoding. With this huge
inconvenience and the unnecessary 'punishment' of standard-compliant web sites,
what we get is that a user does not have to change the encoding at some sites 
that certainly need  fixing. (they need to specify the encoding explicitly). 

As I mentioned earlier, setting the default encoding to use in the absence of
explicit encoding declaration (and UTF BOM) to the most likely one for a given
user (Russian speakers would set it to windows-1251) would relieve a user of
having to override the encoding while browsing within a site like like
www.mdf.ru. That works well for Safari users on Windows (the site uses
Windows-1251 [1]), but does not on Mac (the site uses MacCyrillic without a
label and a Russian user would not set it to MacCyrillic even on Mac because
there are lot more unlabelled sites in windows-1251 than in MacCyrillic among
sites he visits). 

To me, that's an evangelism issue for those sites (yeah, needless to say, we
should accomodate as many web sites as possible, but ...)

Because the gain we get (mentioned in step 1) is rather Mac-specific, I think
we can consider yet another alternative if we agree with me (I hope I'm more
convincing this time than before :-)) that the current behavior is not
desirable. 

  2c. Do 2a but only on Mac (or any combination of PLATFORM-macros)

I'm taking this bug (I keep forgetting this bug :-)). 



[1] Obviously, for multi-lingual users (e.g. Russian and Japanese), that'd not
work well. 


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.