Named entities in HTML documents are converted to numbered entities by Composer




16 years ago
9 years ago


(Reporter: Greg K., Unassigned)


(Depends on: 1 bug, {testcase})


Firefox Tracking Flags

(Not tracked)



(2 attachments)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc2)
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 —.

Comment 1

16 years ago
Created attachment 83754 [details]
Test case containing a named entity

Comment 2

16 years ago
Created attachment 83755 [details]
The same test case after being saved by Composer

Comment 3

16 years ago
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.

Comment 5

16 years ago
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:

Comment 7

16 years ago
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.

Comment 8

16 years ago
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,


16 years ago
Keywords: testcase

Comment 9

16 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

Comment 10

16 years ago
In fact, it doesn't. Saving the testcase from the browser preserves the named
— entity.

Comment 11

16 years ago
Whoops, that was Save As...HTML. Doing Save As...Complete does result in the

Comment 12

16 years ago
I don't understand what thid has to do with DOM->Text conversion.


15 years ago
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All

Comment 13

14 years ago
Does this really belong on Browser, or on Composer?


14 years ago
Depends on: 200264

Comment 14

12 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.
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.