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

Status: RESOLVED WONTFIX

(Core :: DOM: Serializers, defect, P5)

Description

[Greg K.]

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

Comment 1

[Greg K.]

Attachment: Test case containing a named entity

Comment 2

[Greg K.]

Attachment: The same test case after being saved by Composer

Comment 3

[Greg K.]

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

[Henri Sivonen (:hsivonen)]

The compatibility issue is Netscape 4.x. I suggest not altering this behavior.

Comment 5

[Greg K.]

What's the issue, Henri?

Comment 6

[Henri Sivonen (:hsivonen)]

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

Comment 7

[Greg K.]

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

[Greg K.]

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

[Kathleen :Brade]

-->DOM to text conversion (since presumably saving html complete in the browser
also does this conversion)

Comment 10

[Greg K.]

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

Comment 11

[Greg K.]

Whoops, that was Save As...HTML. Doing Save As...Complete does result in the
conversion.

Comment 12

[Daniel Bratell]

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

Comment 13

[Greg K.]

Does this really belong on Browser, or on Composer?

Comment 14

[TT]

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.

Comment 15

[Jens Stutte [:jstutte]]

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.

Comment 16

[Henri Sivonen (:hsivonen)]

We're not going to accept the complexity that retaining information about original escaping would entail.