Closed Bug 7648 Opened 25 years ago Closed 4 years ago

Editor generates invalid output (tbody)

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: braden, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [nsbeta3-][p:3][blocked]) 

The editor includes TBODY elements in its output while using an HTML 3.2 FPI. TBODY is not an HTML 3.2 element.

(Sorry if this is a dupe. Mozilla flaked out the last time I tried to submit this.)
could the submitter please attach a small test case?
Second request:  could the submitter please describe in more detail what the
problem is?  What is FPI?
Sorry I'm late in getting back to this...

Attaching an example seemed unnecessary, as this occurs in both the default
page brought up by Composer and starting text in the message edit window.

FPI stands for Formal Public Identifier; it is a label for the document type
definition to which a SGML document claims to conform.

TBODY is not part of the document type definition corresponding to the FPI
Composer-generated documents are using.
Status: NEW → ASSIGNED
Target Milestone: M11
Target Milestone: M11 → M15
Depends on: 23838
Presently, this bug is not "valid" since the current Composer (2000-01-12-10)
seems to insert no FPI at all (bug 23838).  We can't work on this one until
that's fixed.
to kathy
Assignee: buster → brade
Status: ASSIGNED → NEW
One problem is that the parser adds a tbody to every table we read in.  So even
if we don't generate a tbody when we first create the table, the parser will add
one the next time we re-read that file in from disk.

I've filed bug 30378 requesting that the parser not do that.  This bug is, of
course, dependant on that one.
Depends on: 30378
move to M16 for now
Summary: Editor generates invalid output → Editor generates invalid output (tbody)
Target Milestone: M15 → M16
Severity: normal → major
Priority: P3 → P2
FYI: The TBODY is created in EdInsertTable.js when a new table is inserted.

Adding beta2 keyword: the marketing feature spec lists "roundtrip issues" as a
P1 item for beta 2, and having the tbody there makes the document uneditable by
old composer, which means this would be an interoperability issue for people
trying to send html mail with tables.
Keywords: beta2
reassign to cmanske; Charley--after the dependent bugs are resolved, you'll need 
to make sure we don't create a tbody unless the dtd is html 4.0 strict.
Assignee: brade → cmanske
Status: NEW → ASSIGNED
Can't fix this until we can obtain the doc's DTD version (bug 34424)
Depends on: 34424
Moving bugs I know I won't get to in M16
Target Milestone: M16 → M17
Keywords: nsbeta2
Putting on [nsbeta2-] radar.
Keywords: beta2
Whiteboard: [nsbeta2-]
Keywords: nsbeta2 → correctness, nsbeta3
Whiteboard: [nsbeta2-]
Target Milestone: M17 → M18
moving to m20 -- 30378 is not milestoned and this cannot be resolved until that 
one is.
Target Milestone: M18 → M20
Whiteboard: [nsbeta3+]
we really need to export valid html for previous versions of the browser.
setting to nsbeta3+
Charley, can you please add the level of priority -- thanks
changing priority.
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][p:3]
Yes, but it's not in yet. I can't change my side until 30378 is closed. (I
tried it, but there were bad side effects!)
Target Milestone: M20 → M18
Note: this is a trivial fix, so don't "-" this bug! We are simply waiting for
30378 to be checked in.
Still waiting for 30378 to get checked in
Whiteboard: [nsbeta3+][p:3] → [nsbeta3+][p:3][blocked]
30378 is being futured, there will need to be more indepth analysis as to the 
more global impact of this change. Currently, when a new document is generated, 
the doctype refers to 4.01, where tbody is legal. A document with no doctype 
gets a doctype pointing to 4.01. The issue would be if the doctype is preset to 
3.2. The model for 3.2 is to ignore unknown elements. We can address this issue 
in the release.
Whiteboard: [nsbeta3+][p:3][blocked] → [nsbeta3-][p:3][blocked]
Target Milestone: M18 → Future
Note: 4.x composer uses "4.0 Transitional" and it is 4.x mail that is the 
source of the problem with "tbody"
I have no problem with futuring this issue, however!

Remember that this means that our messages are no longer backwards
compatible with 4.x.  See Beth's comment in bug 30378 as of 2000-08-02 12:29.

The latest comment in that bug says that the relevant code is in and working
properly.  I don't understand why this is being futured, or why that bug is
still open.  Can someone summarize?
The "relevant code" (fix for 30378) is *ready*, not checked in. It required
more review by Karnaze. My trivial change can't be checked in unless 30378 code
is in. In Composer, we can test for the DTD and "do the right thing". I think
the code suggested for 30378 should do the same.
I just tested not inserting "tbody" in Insert Table and it still doesn't work;
cycling through HTML Source confirms that parser still insists on having 
a <tbody> in the table.


The part I'm doing has been in for some time. There's a #define at the top of 
CNavDTD which disables the automatic production of <TBODY>. Karnaze feels that 
he can't sufficiently test this for RTM.
This still depends on whether 30378 is addressed for mozilla0.9
Is this bug still valid? Specifically, does the editor still emit documents with
an HTML 3.2 FPI?

no, we do not output 3.2 doctype
Yes we do, on existing files: If you edit a table with a 3.2 DTD, which has no
tbody, we save it with the same doctype and we still incorrectly add in the
tbody.  And this is still a problem for 4.x mail AFAIK.
right, but the doctype was already present, I have agrued in the past that the
doctype should be updated when any edits take place iwthin COmposer. Updating
the doctype to 4.01 transitional in  no way breaks anything in the existing
document, however, it does guarentee that when we make edits like adding tables,
the document is still valid on output. Keeping the 3.2 doctype, IMHO, is just
downright wrong.
spam composer change
Component: Editor: Core → Editor: Composer
-->core
Assignee: cmanske → brade
Status: ASSIGNED → NEW
Component: Editor: Composer → Editor: Core
beppe: There are two ways to fix this bug: either properly support HTML 3.2, or
explicitly *not* support it. The latter option would seem to be the shortest
path to victory, but it is not a complete victory.

If Mozilla explicitly does not support HTML 3.2, it is appropriate to issue a
warning to the user and change the doctype to 4.0 when saving a document that
was HTML 3.2. The problem with this approach is DOM support. If an author uses
the DOM with a 3.2 document and tries to get a child of TABLE, he will be
expecting CAPTION or TR. But if the document was treated as HTML 4.0 by the
parser when constructing the DOM tree, the children available may be CAPTION,
TBODY, THEAD, TFOOT, COLGROUP, or COL.

At this point, the number of HTML 3.2 documents using the DOM is probably so
small as not to matter. So having that hole in Mozilla's HTML support may be
acceptable. It is certainly the case that changing the doctype would be better
than what Mozilla does now, which is to fail silently.


duh! I bad, I totally glossed over the comments about 3.2 -- please accept my 
apologies for jumping in and not absorbing the facts before inserting comments. 
You are correct of course, tbody should not be inserted if a current doctype of 
3.2 is present.
Braden, I found this in http://www.w3.org/TR/REC-html32#head :

SCRIPT reserved for future use with scripting languages.
STYLE reserved for future use with style sheets

These are place holders for the introduction of style sheets and client-side
scripts in future versions of HTML. User agents should hide the contents of
these elements.
---
If I understand it correctly, there couldn't be scripts using DOM. Is it correct
idea or not?
The HTML 3.2 spec says that SCRIPT can contain CDATA, which would presumably be
script code of some kind. While the HTML 3.2 spec provides no means of telling
the browser what kind of script code, Mozilla assumes it is JavaScript and
executes the code as such. So as far as Mozilla is concerned, valid HTML 3.2
documents can contain scripts.

There is another possibility, too. I know some folks have talked about wanting
to expose sub-document (OBJECTs) DOM trees to scripts in the host document. I
don't know if this has been implemented yet. But, if the sub-document were HTML
3.2, it would need to have a DOM tree that reflected HTML 3.2 document structure.

removing myself from the cc list
Keywords: helpwanted
QA Contact: sujay → editor
Assignee: brade → nobody

<tbody> is a valid HTML element as of now, closing.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.