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)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
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.
Assignee | ||
Comment 1•24 years ago
|
||
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.
Assignee | ||
Comment 2•24 years ago
|
||
Comment 3•24 years ago
|
||
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
Assignee | ||
Comment 4•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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]
Comment 8•24 years ago
|
||
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?
Assignee | ||
Comment 9•24 years ago
|
||
This has nothing to do with HoTMetaL's DOCTYPE not working. It's just a bug in
Mozilla.
Assignee | ||
Comment 10•24 years ago
|
||
Any objections to my taking this bug?
Updated•24 years ago
|
Keywords: mozilla0.9.1
Comment 12•24 years ago
|
||
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]
Assignee | ||
Comment 13•24 years ago
|
||
No, it's not on purpose, it's because the DOCTYPE contains "HTML 4.0" and
doesn't contain "Transitional".
Comment 14•24 years ago
|
||
See the comment above
http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsParser.cpp#1270
Assignee | ||
Comment 15•24 years ago
|
||
I'm not sure whether than comment was describing intent or fact.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Comment 16•23 years ago
|
||
Fix checked in 2001-09-08 11:37 PDT (see bug 55264).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•