Closed Bug 55916 Opened 24 years ago Closed 23 years ago

[DOCTYPE] HoTMetaL Pro generates HTML that triggers standard mode

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: waterson, Assigned: dbaron)

References

Details

(Whiteboard: [Hixie-P5])

The above site is clearly not rendered as the author had intended (notice the gaps between images along the left-hand navigation column). It turns out the web page is being rendered in standard mode because of this doctype declaration: <!DOCTYPE HTML PUBLIC "-//SoftQuad Software//DTD HoTMetaL PRO \ 6.0::19990601::extensions to HTML 4.0//EN" "hmpro6.dtd"> Since this HTML is generated with a fairly popular tool, I'm concerned that there may be a significant sample of content that we'll render "incorrectly" (that is, not as the author had intended). This may be an evangelism issue, or it may be a parser doctype detection issue. ekrock et. al., it's your call.
Keywords: 4xp
The test page http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl?DOCTYPE=-%2F%2FSoftQuad+Softw are%2F%2FDTD+HoTMetaL+PRO+6.0%3A%3A19990601%3A%3Aextensions+to+HTML+4.0%2F%2FEN& MODE=fpi shows that this FPI is triggering standard mode. This should be fixed by the patches on bug 44340.
My thoughts on evangelism's limits: basically, any time that an authoring tool with any market share at all has generated something bogus, I consider evangelism futile for addressing the problem. Even if you evangelize the authoring tool vendor to fix whatever it is about their tool that's causing the problem, it doesn't retroactively fix all the pages on the web that were generated with the tool. (I'm of course in favor of contacting the tool vendor and asking them to fix whatever's wrong so the amount of bad HTML on the web doesn't increase, but you have to take the legacy content as a given.) Basically I think evangelism of bad HTML/CSS/JS has a chance of solving problems when particular sites have made some relatively unique goof, not when an authoring tool has been propagating a mistake worldwide. Please explain: what is it about the above DOCTYPE declaration that causes us to go into standard layout mode? IIUC, this is a good example of why having all unknown DOCTYPEs send us into standard mode could be risky (as desirable as that would be from a forward compatibility with future DOCTYPEs standpoint). We've never done a comprehensive survey to find out all the DOCTYPEs out there on the web; we don't even currently have a list of all the DOCTYPEs output by authoring tools. Nominating for RTM. What's the lowest-risk way of fixing this bug? Marking [DOCTYPE] for easy searching. Note related bug 55264 and bug 55263.
Keywords: rtm
Summary: HoTMetaL Pro generates HTML that triggers standard mode → [DOCTYPE] HoTMetaL Pro generates HTML that triggers standard mode
I think it's triggering standard mode because it contains the string "HTML 4.0" without the string "Transitional". The last time I looked at the doctype parsing code it was using heuristics like that rather than just comparing whole strings. I didn't like that approach, so I wrote the patch in bug 44340. I agree that making unknown DOCTYPES trigger standard mode is risky at this stage. That's why I proposed 13 months ago that we do immediately (see both my 1999-09-01 comments on bug 1312).
This is fixed by the patch that I've added to bug 42525. The PDT has elected not to accept these changes.
Status: NEW → ASSIGNED
Since 42525 was checked into the branch, seems like this bug should be closed as a dup of it. Perhaps that's not true because 42525 morphed about 18 times. In any case, 42525 has happened and that leaves this bug without a unique patch. Can you update it to be a dup or explain what's unique about this bug? If you're working on it, please update the whiteboard with [rtm need info] or put in [rtm-] if you're not going to work on it.
Whiteboard: [need minus]
rtm-, not being worked on.
Whiteboard: [need minus] → [rtm-]
My company uses HotMetal alot. We are now going through and removing the DOCTYPE that HotMetal adds to the file. Could some explain or point me to a link how the DOCTYPE works and why HotMetal's DOCTYPE does not work?
This has nothing to do with HoTMetaL's DOCTYPE not working. It's just a bug in Mozilla.
Any objections to my taking this bug?
updated qa contact.
QA Contact: janc → bsharma
Reassigning to dbaron per lack of comments. I think this was actually done on purpose, btw, with the idea that HoTMetaL Pro actually generated "standards-compliant markup"...
Assignee: rickg → dbaron
Status: ASSIGNED → NEW
Whiteboard: [rtm-] → [Hixie-P5]
No, it's not on purpose, it's because the DOCTYPE contains "HTML 4.0" and doesn't contain "Transitional".
I'm not sure whether than comment was describing intent or fact.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Fix checked in 2001-09-08 11:37 PDT (see bug 55264).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: bsharma → moied
You need to log in before you can comment on or make changes to this bug.