Closed
Bug 144810
Opened 22 years ago
Closed 3 years ago
Named entities in HTML documents are converted to numbered entities by Composer
Categories
(Core :: DOM: Serializers, defect, P5)
Core
DOM: Serializers
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bugmail, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: testcase)
Attachments
(2 files)
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.
Comment 4•22 years ago
|
||
The compatibility issue is Netscape 4.x. I suggest not altering this behavior.
Comment 6•22 years ago
|
||
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.
Comment 9•22 years ago
|
||
-->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
Reporter | ||
Comment 10•22 years ago
|
||
In fact, it doesn't. Saving the testcase from the browser preserves the named — entity.
Reporter | ||
Comment 11•22 years ago
|
||
Whoops, that was Save As...HTML. Doing Save As...Complete does result in the conversion.
Comment 12•22 years ago
|
||
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
Reporter | ||
Comment 13•21 years ago
|
||
Does this really belong on Browser, or on Composer?
Comment 14•18 years ago
|
||
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.
Updated•15 years ago
|
Assignee: harishd → nobody
QA Contact: sujay → dom-to-text
Comment 15•3 years ago
|
||
Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.
If you have reason to believe this is wrong, please write a comment and ni :jstutte.
Severity: major → S4
Priority: -- → P5
Comment 16•3 years ago
|
||
We're not going to accept the complexity that retaining information about original escaping would entail.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•