[DOCTYPE] HoTMetaL Pro generates HTML that triggers standard mode

RESOLVED FIXED in mozilla0.9.5

Status

()

Core
HTML: Parser
P3
normal
RESOLVED FIXED
18 years ago
17 years ago

People

(Reporter: Chris Waterson, Assigned: dbaron)

Tracking

Trunk
mozilla0.9.5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P5])

(Reporter)

Description

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

Updated

18 years ago
Keywords: 4xp
(Assignee)

Comment 1

18 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)

Updated

18 years ago
Blocks: 34662
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

18 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).

Comment 5

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

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

18 years ago
rtm-, not being worked on.
Whiteboard: [need minus] → [rtm-]

Comment 8

18 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

18 years ago
This has nothing to do with HoTMetaL's DOCTYPE not working.  It's just a bug in
Mozilla.
(Assignee)

Updated

18 years ago
Depends on: 44340
(Assignee)

Comment 10

18 years ago
Any objections to my taking this bug?

Comment 11

17 years ago
updated qa contact.
QA Contact: janc → bsharma
Keywords: mozilla0.9.1
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

17 years ago
No, it's not on purpose, it's because the DOCTYPE contains "HTML 4.0" and
doesn't contain "Transitional".
(Assignee)

Comment 15

17 years ago
I'm not sure whether than comment was describing intent or fact.
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Updated

17 years ago
Depends on: 55264
(Assignee)

Comment 16

17 years ago
Fix checked in 2001-09-08 11:37 PDT (see bug 55264).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
QA Contact: bsharma → moied
You need to log in before you can comment on or make changes to this bug.