1020232 - dwiggie.com - Should correctly label MacRoman content as charset=macintosh (or re-encode as UTF-8 and then declare as UTF-8)

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Sebastian Redl]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

Visit a site that allows long-text user-submitted content, such as fanfiction archives; dwiggie.com in my case. These pages often use the user's text files as they are, with minimal conversion - in particular no character conversion. This results in a lot of pages with mixed encodings - the basic code of the page may be in UTF-8 (and the page specifies this as its encoding), but the story text is actually in Windows-1252 or MacRoman.


Actual results:

The pages have mixed encodings, and the encoding of the story text doesn't match the advertised encoding. The result is misprinted characters - long dashes, slanted quotes, etc. show up as weird characters. I used to just force the right encoding from the view->encoding menu, but with bug 805374 landed, MacRoman is gone. I can't find any way of restoring it, or otherwise working around the issue. Even using the WebDev tools doesn't work, because modifying the encoding pragma doesn't cause the browser to reparse the page.


Expected results:

There should be some way to restore MacRoman as a choice in View->Encodings. A hidden preference maybe. Currently, modules/CharsetMenu.jsm has simply commented out the relevant points; instead it should add them conditionally.

Basically, I can no longer view these pages with fidelity. I'm aware that technically this is a bug in the website in question, but asking the owners to go through thousands of archived stories, auto-detecting the encoding in each one and fixing it seems to be a bit much when all I need is a simple menu entry to fix this.

Comment 1

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

(In reply to Sebastian Redl from comment #0)
> Visit a site that allows long-text user-submitted content, such as
> fanfiction archives; dwiggie.com in my case.

It would be easier to assess the extent of the problem if URLs for example pages of brokenness were provided.

Internet Explorer doesn't have MacRoman in its encoding menu, either, which suggested it isn't absolutely necessary to have it in the menu. I wonder why the site hasn't already gotten feedback from IE users over the years. Maybe the level of brokenness is tolerable?

> There should be some way to restore MacRoman as a choice in View->Encodings. A hidden 
> preference maybe. Currently, modules/CharsetMenu.jsm has simply commented out the relevant 
> points; instead it should add them conditionally.

If you look at the menu, you'll notice that the labels of the menu items depend on the other menu items. For example, since there is only one item for Korean, the label just say "Korean". There are two entries for Central European, so the labels say "Central European (Windows)" and "Central European (ISO)". There are three entries for Japanese, those don't have obvious high-level designations like "Windows" and "ISO", so they have the full encoding names in parantheses.

Making the full set of encodings change dynamically wouldn't fit this labeling scheme.

> I'm aware that
> technically this is a bug in the website in question, but asking the owners
> to go through thousands of archived stories, auto-detecting the encoding in
> each one and fixing it seems to be a bit much when all I need is a simple
> menu entry to fix this.

I think it's not unreasonable to ask the site to fix this once. I think it's more unreasonable to ask many users to take action countless times.

Comment 2

[Karl Dubost💡 :karlcow]

I have browsed the site and I didn't notice any issues. 
If there's a specific URI, please reopen.
I will close as worksforme.