Editor generates invalid output (tbody)




20 years ago
10 years ago


(Reporter: braden, Unassigned)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][p:3][blocked])



20 years ago
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.)

Comment 1

20 years ago
could the submitter please attach a small test case?

Comment 2

19 years ago
Second request:  could the submitter please describe in more detail what the
problem is?  What is FPI?

Comment 3

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


19 years ago


19 years ago
Target Milestone: M11


19 years ago
Target Milestone: M11 → M15


19 years ago
Depends on: 23838

Comment 5

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

Comment 6

19 years ago
to kathy
Assignee: buster → brade

Comment 7

19 years ago
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

Comment 8

19 years ago
move to M16 for now
Summary: Editor generates invalid output → Editor generates invalid output (tbody)
Target Milestone: M15 → M16


19 years ago
Severity: normal → major
Priority: P3 → P2

Comment 9

19 years ago
FYI: The TBODY is created in EdInsertTable.js when a new table is inserted.

Comment 10

19 years ago
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

Comment 11

19 years ago
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


19 years ago

Comment 12

19 years ago
Can't fix this until we can obtain the doc's DTD version (bug 34424)
Depends on: 34424

Comment 13

19 years ago
Moving bugs I know I won't get to in M16
Target Milestone: M16 → M17


19 years ago
Keywords: nsbeta2

Comment 14

19 years ago
Putting on [nsbeta2-] radar. 
Keywords: beta2
Whiteboard: [nsbeta2-]


18 years ago
Keywords: nsbeta2 → correctness, nsbeta3
Whiteboard: [nsbeta2-]


18 years ago
Target Milestone: M17 → M18

Comment 15

18 years ago
moving to m20 -- 30378 is not milestoned and this cannot be resolved until that 
one is.
Target Milestone: M18 → M20


18 years ago
Whiteboard: [nsbeta3+]

Comment 16

18 years ago
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

Comment 17

18 years ago
changing priority.
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][p:3]

Comment 18

18 years ago
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!)


18 years ago
Target Milestone: M20 → M18

Comment 19

18 years ago
Note: this is a trivial fix, so don't "-" this bug! We are simply waiting for
30378 to be checked in.

Comment 20

18 years ago
Still waiting for 30378 to get checked in
Whiteboard: [nsbeta3+][p:3] → [nsbeta3+][p:3][blocked]

Comment 21

18 years ago
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

Comment 22

18 years ago
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!

Comment 23

18 years ago
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?

Comment 24

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

Comment 25

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

Comment 26

18 years ago
This still depends on whether 30378 is addressed for mozilla0.9

Comment 27

17 years ago
Is this bug still valid? Specifically, does the editor still emit documents with
an HTML 3.2 FPI?

Comment 28

17 years ago
no, we do not output 3.2 doctype

Comment 29

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

Comment 30

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

Comment 31

17 years ago
spam composer change
Component: Editor: Core → Editor: Composer

Comment 32

17 years ago
Assignee: cmanske → brade
Component: Editor: Composer → Editor: Core

Comment 33

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

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.

Comment 34

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

Comment 35

17 years ago
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?

Comment 36

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

Comment 37

17 years ago
removing myself from the cc list


16 years ago
Keywords: helpwanted
QA Contact: sujay → editor
Assignee: brade → nobody
You need to log in before you can comment on or make changes to this bug.