From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 2002051005 A named entity in an HTML document is changed to its' numbered equivalent by Composer without the editor's consent. Named entities should be maintained as named entities. Reproducible: Always Steps to Reproduce: 1. Access the attached testcase 2. Invoke the "Edit Page" command 3. Save the page locally 4. View the newly saved HTML source Actual Results: The original — entity has been changed to its' numerical equivalent, —. Expected Results: The entity should have remained —.
Is some capability necessary to determine whether special characters should be saved as named or numbered entities by Composer? I imagine most editors would almost always prefer names if available.
The compatibility issue is Netscape 4.x. I suggest not altering this behavior.
What's the issue, Henri?
Netscape 4.x doesn't support dashes and smart quotes as mnemonic entities but does support them as decimal references. Test case: http://www.hut.fi/~hsivonen/test/quotes-dashes.html
The issue here is that we're changing HTML that already exists. If Mozilla wants to only create new HTML that 4 supports, fine, but we shouldn't be changing existing HTML to support 4.
That said, I'd still like to see some way to choose whether to create new HTML using names or numbers. Composer's HTML+CSS is way beyond what Nav 4 can handle, anyway.
-->DOM to text conversion (since presumably saving html complete in the browser also does this conversion)
Assignee: syd → harishd
Component: Editor: Composer → DOM to Text Conversion
In fact, it doesn't. Saving the testcase from the browser preserves the named — entity.
Whoops, that was Save As...HTML. Doing Save As...Complete does result in the conversion.
I don't understand what thid has to do with DOM->Text conversion.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
Does this really belong on Browser, or on Composer?
I think this is definitely a Composer bug. However, it has another side effect. On Mac OS X, when I use Composer to edit a document that has — in it, Compose will change to an em dash in the document, rather than the numberical equivalent. The problem is that when I publish the document, and then try to view it, I get strange accented characters instead of my em dash. I think it has to do with the character encoding. Is the em dash character part of ISO 8859? If not, then that's probably the problem. When Seamonkey views the page, it sees the em dash character, but the character doesn't allow it, so it displays something goofy. This can all be avoided if Composer didn't convert "—" (or any other named entity), when it sees it.
Assignee: harishd → nobody
QA Contact: sujay → dom-to-text
You need to log in before you can comment on or make changes to this bug.