Closed Bug 146095 Opened 23 years ago Closed 23 years ago

charset of page not saved by composer

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: u32858, Assigned: tetsuroy)

References

(
URL
)

Details

(Keywords: intl)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 2002051013 Currently that page does not have a charset definition in a meta tag. I set auto detect to Japanese and it selects ISO-2022-JP, i edit in composer and save, but the charset is not saved. it should save it by default IMO. Reproducible: Always Steps to Reproduce: 1.go to that url 2.file->edit 3.save as (not save as charset) Actual Results: not saved <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Project Heke</title> </head> Expected Results: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Project Heke</title> <meta http-equiv="content-type" content="text/html; charset=ISO-2022-JP"> </head> IMO, the charset should always be saved. This saves the auto detection problems. This is independent of "Save as charset" as that is used to convert between charsets.
I think this is an expected behavior. We respect the original doc's settings. cc momoi for his input
Confirming the bug. Once you edit a page and if you have an option for "Reformat HTML source" turned on, which is ON by default, there should be nothing wrong with inserting the meta charset info. Once the editor takes hold of a document, it should be able to normalize the source in various ways. This seems to be a bug for current builds. Please make sure that other normalizations are going on as long as the proper option is selected for HTML source modification under the Composer preference section.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
QA Contact: ruixu → kasumi
I think "Reformat HTML source" here is means "HTML", like we added: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> and reformat the HTML tags if necessary.(e.g. if we the original source only has "<p>", we'll reformat it as a pair <p>...</p>) For encoding, we have an option "Save as charset" and "Save as", if you want to add encoding, you can select "Save As Charset", otherwise, "Save As" only for save as a new file name, the encoding still keep the one in Composer window but just without meta-charset. So, the current behavior is more reasonable and give user choises.
> I think "Reformat HTML source" here is means "HTML", like we added: > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > and reformat the HTML tags if necessary.(e.g. if we the original source only has > "<p>", we'll reformat it as a pair <p>...</p>) How do you make a distinction that the meta declaration is not part of the HTML source? The meta lines are defined in HTML protocol like the element tags that you talk about. Save as charset has nothing to do with whether or not the meta charset line should be included. That has to do with whether or not document encoding should be changed. It is OK for HTML editor to normalize the HTML source and we should promote the use of document charset meta statement. I think it best not to insert meta lines if the option to retain original source is checked off. I think we used to insert the meta charset line before. This could be a regression.
> How do you make a distinction that the meta declaration is not > part of the HTML source? The meta lines are defined in HTML protocol > like the element tags that you talk about. HTML charset meta-tag is an option item. > I think we used to insert the meta charset line before. This could be a > regression. As far as I remember, it's not a regression. At least for N6.2x. Save As Charset can do 2 things right now: 1. Add a charset meta-tag. 2. Convert a document to another encoding. For my opnion, the current behavior is good. cc more people for input.
We know the default, so it should be saved, IMO it does not break anything to add more meta data to an html file. (and actaully helps for those of us who do not have iso-8859-1 as our default html charset) The problem here is that the default for html pages is iso-8859-1, this page is not defined as japanese, or any charset, so i manually select ISO-2022-JP, it then displays fine. However I want to edit it, "File->edit" it it pops up in composer ( still in ISO-2022-JP), but when i save it is saved with no charset, so each time i load i have to manually select the charset again. This does not break anything (assumming the user is not editing a file in composer in the wrong charset, but that is the users mistake), we should implement the best solution and that is to save the charset IMO JG
But sometimes pages may prefer no meta-tag because of their own reason or purpose, e.g. www.yahoo.co.jp which charset defined by their server not html source...etc. Yes, it didn't break anything, but give user options to add charset meta-tag (Save as charset) or keep the orginal source (Save As). If you really want to have charset meta-tag in html source, you can do Save As Charset. If there is no difference between Save As and Save As Charset, why we need two menu items? In that case, I'll file a bug for having two menu items with save function.
When we first worked on the Editor Encoding menu spec published here: http://www.mozilla.org/projects/intl/uidocs/editorcharmenu.html It was explicitly agreed on that we will promote the use of meta-charset tag. Let me quote the version 1.0 of this document: ============================================== * Save menu: These Windows will also have Save menu. Engaging this menu will save page/message using the current document Character Encoding. * Meta HTTP-Equiv Charset tag: every saving action will create an appropriate meta charset tag or there must be a pre-existing valid meta charset tag in the document which does not conflict with the current document charset. ============================================== Note that the wording says, 'every saving action will create an appropriate meta charset tag...' It cannot be clearer than this. I just published version 1.2 of this document and you should see it soon. The intent of the spec is clear. We would like to make it easier for web users to display a page without having to touch an encoding menu. The charset tag helps in this respect. The principle we should support is that any document our editor should mark its encoding clearly. This is mentioned more explictly in version 1.2 of the document: ========================================== * Every document must have an appropriate meta charset tag or there must be a pre-existing valid meta charset tag in the document. Such a meta tag must match the Current Document Charset. ========================================== The fact that when you save a document right now using either "Save as ..." menu or Save button, the editor does not insert a meta-charset line **only when the encoding is the same as the original one** is a bug. Try this experiment, 1. Open a document without a meta-charset line. 2. Change the encoding to something other than the original one. (There is a bug here in that this will corrupt the original data even when conversion is reasonable. This is a bug and needs to be fixed but has no bearing on the current discussion.) 3. Now save using the save button or Save as dialog. This will insert the meta charset line. Currently it does not insert this line **only when** the encoding chosen is the same as the original one. This is a bug. If you want to know the difference between the Save as .../Save button or Save as Charset .. menus, please read the version 1.2 of the document which will be appearing soon. Save as Charset ... menu is there for you to change the encoding of the document when the ordinary changing of Character Coding menu is not available. I repeat this: whether or not the Editor will insert the meta-charset line has no direct relationship to Save as Charset menu... Not inserting the meta line does not serve average users needs at all. We should not produce documents which require manipulation of Character Coding menu on the part of users. This is against the designing principle of the Character Coding menu itself. I recommend that we insert the meta-charset line as agreed on in the spec version 1.0 and 1.2 and fix this bug. For those special advanced users, we have an Editor option to preserve original source formatting.
Hi, > ------- Additional Comments From ylong@netscape.com 2002-05-23 09:24 ------- > But sometimes pages may prefer no meta-tag because of their own reason or > purpose, e.g. www.yahoo.co.jp which charset defined by their server not html > source...etc. if i am saving the page locally it will not have this server defined charset. And when i load locally the page will be all corrupted. IMO, when i edit a page (after either charset has been selected auto, by server, or by me) it should then save locally in that meta charset format. > Yes, it didn't break anything, but give user options to add charset meta-tag > (Save as charset) or keep the orginal source (Save As). If you really want to > have charset meta-tag in html source, you can do Save As Charset. > > If there is no difference between Save As and Save As Charset, why we need two > menu items? In that case, I'll file a bug for having two menu items with save > function. Save as Charset is for conversion IMO, so if i edit yahoo.co.jp it is EUC-JP so saving should not list save as charset EUC-JP, but all others. This is the current format though i think? JG
Let's _not_ discuss <Save As charset> from Editor. It only confuses the issue. I just want clarify things, so here it goes...... > 'every saving action will create an appropriate meta charset tag...' This spec is for Editor. I agree that we should add a meta charset tag from <Save>/<Save As...> from Editor. > if i am saving the page locally it will not have this server defined charset. How about <Save Page As..> from browser? Do we also add a meta charset tag?
Status: NEW → ASSIGNED
ylong: this isn't Linux specific, correct?
No, it's for all platforms. Change platform/OS from linux to All.
OS: Linux → All
Hardware: PC → All
Blocks: 152111
Any progress on this? Could it be assigned a higher priority and target please? JG
Tested on 7.01 JA on Win XP. Specified page already has "ISO-2022-JP" as meta. I tested http://www.geocities.co.jp having no meta. Saved like <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=Shift_JIS"> </head> I can't reproduce.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.