Closed Bug 7648 Opened 27 years ago Closed 6 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: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.