Closed Bug 47165 Opened 24 years ago Closed 24 years ago

XHTML document spacing is displayed incorrectly when DOCTYPE tag is the first line

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 22274
Milestone:
mozilla1.0

People

(Reporter: megabyte, Assigned: harishd)

References

(
URL
)

Details

(Keywords: xhtml)

Attachments

(1 file)

testcase: if doctype commented out works if not table cells too tall.
(deleted), text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000731 BuildID: 2000073120 In the page http://new.swva.net/bad.html, the layout and spacing of the page is displayed incorrectly (too much space, there should be none) when the DOCTYPE tag is the very first line in the XHTML document. In the page http://kontek.dyndns.org/index1.shtml, the page does not even display. To be a valid document, it is supposed to be the very first line. It can be resolved by adding a line break immediately before the DOCTYPE tag. Reproducible: Always Steps to Reproduce: 1. Create and view a page that has an XHTML DOCTYPE tag as the first line of the document. Also, if the xml tag is present at the beginning, the same problem occurs. Actual Results: The spacing of the layout is very spread out or the page does not display at all. Expected Results: The spacing should not be spread out and the page should display. It should look like http://new.swva.net, and http://kontek.dyndns.org I am aware there is a problem with XHTML, however, this problem does not occur when there is a single line-break directly above the DOCTYPE tag. The DOCTYPE tag must be the first line to validate as XHTML.
Verified on Linux 3009.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This looks like a DUPL of 43570. This report has a little better description of the problem though. *** This bug has been marked as a duplicate of 43570 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Actually, should be 29135
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 29135 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Made a mistake.. should be 29125.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 29125 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Bug 29125 addressed the page non-display issue. The spacing issue is unrelated. Your page layout depends on tables using 'cellspacing="0" cellpadding="0"' attributes. These are not part of HTML 4.0 (and thus not defined in XHTML 1.0 either). When you use the XHTML 1.0 Transitional DOCTYPE, Mozilla ignores all those proprietary HTML extensions. You will see the same spaced-out layout if you replace <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd"> with <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
I spoke too soon. "cellspacing" and "cellpadding" ARE defined in the Strict DOCTYPEs. My apologies. The page displays correctly using the HTML 4.01 Transitional DOCTYPE: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> So it may be a strict/quirks mode issue rather than an XHTML issue, perhaps related to strict ignoring cellpadding and cellspacing.
Okay, this may be a separate issue, reopening... Also, the bug work arounds mentioned in bug 29125 no longer work (probably because other bugs were fixed)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I worked out yet another work around.. if you do this: <!--<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "DTD/html401-transitional.dtd">--> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd"> Mozilla will read the first line, but the other browsers will ignore it. I guess this will work until they fix this bug, or the other.
URL: http://new.swva.net/bad.html → http://www.swva.net/bad.shtml
Just taking a quick look, this WFM on WinNT 2000100408. Over to Nisheeth to verify.
Assignee: clayton → nisheeth
Status: REOPENED → NEW
Still a mess in nightly build 2000101704 under Windows 2000.
Ok, I'm still experiencing this bug. I'm seeing as reported initially. Test page - take a look at http://www.disobey.com/about/ within 2000111508, and focus on the spacing of the upper right hand tables. This page uses the XHTML 1.0 Transitional DOCTYPE. Secondly, take a look at http://www.disobey.com/collected/ which uses the HTML 4.01 Transitional DOCTYPE. The spacing is as intended. This is *not* related to bug 43570 or 29125 and is still a problem as of the 2000111508 release (Win). I've got the latest 20001120 on my work comp., I'll check from there as well.
Yes, this is related to bug 43570... The frames disappear because they are of XHTML DOCTYPE. If you do the same work-around as previously stated, the problem disappears; however, that work-around in itself is another bug, but hopefully it will not be fixed before this issue is resolved.
I'm afraid I'm not sure how they're related then - would you enlighten me? In your original report, you make mention of "the layout and spacing of the page is display incorrectly" - that's what I'm seeing as well, it almost looks like moz adds vertical kerning to font sizes that are smaller than standard (ie., if I use XHTML Transitional, and font size=3, 4, 5, everything's fine. font size=2 or 1 cause the spacing/kerning issue.) To clarify, I hate frames and never use them, thus frames aren't specifically effecting my pages. I'm *not* using any frames on the page, nor am I having problems seeing the page. The work around you propose does solve the problem readily enough (thus my example URLs in my previous post aren't usable out of the box, but can be de-worked around). So, since I don't use frames, the kerning / spacing issue I'm seeing is not, as far as I can tell, related to the frames / not appearing issue described in the other bug reports.
It is because it is an issue with how the XHTML DOCTYPE (or XML) is processed, it's not specifically a spacing issue, though that is what the visual results include. I had to use the work-around on some pages that did include frames, otherwise they wouldn't show up. Another person (don't remember which bug#), thought it was a TD rendering issue; because, if you specify TD with a height that is smaller than, say FONT SIZE=3, the same problem will result. But it isn't a element rendering-specific issue, it's an issue with how the entire XHTML/XML-HTML document is processed.
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
The 'fix' no longer works correctly with the W3C validator, so this needs to be addressed ASAP.
Aaron, generally only bug owners (or their managers) should be setting milestones and priorities. The developers place bugs into "milestone buckets" they think they can fix in that timeframe. If someone else changes the milestone it is, well, rude and most likely does not have the effect you want. You can, however, suggest a milestone etc. and lobby other people to vote for a bug. Having said that XHTML is in the XML/DOM team's interests, and I am tentatively changing the milestone to mozilla0.9 (a little later) and changing priority back to P3. I am adding harishd to CC since he probably knows XHTML issues best.
Priority: P2 → P3
Target Milestone: mozilla0.8 → mozilla0.9
I did not realize it before, but this bug was purposely set because of the "NavQuirks" mode. Even people using HTML 4.01 with namespace or ISO HTML or even HoTMetaL HTML will have the problem. I will reference the numerous related bugs here later on and cross link it to the main discussion thread. The fact is that while this bug is somewhat related to XHTML/XML, the problem truly lies in DOCTYPE handling in general. I think for the sake of the "GOOD THING", page layout should not be sacrificed for supposed "standards." For now, I am submitting yet another work-around that will satisfy Mozilla and the latest W3C HTML Validator, for the time being since the last one broke in both places. The code is as follows: <!--!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"--> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Harish, this bug is related to differeing layout based on DOCTYPE and belongs to you, the parser expert.
Assignee: nisheeth → harishd
Target Milestone: mozilla0.9 → ---
Adding xhtml keyword.
Keywords: xhtml
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
I'd submit that bug 37079 (which I don't believe should have been closed) is a duplicate of this one, even has a simple testcase. Comments? This bug has been nagging at me for some time now (on Mac OS). Putting a vote in :-)
In mozilla an XML ( or XHTML ) document is treated as a strict document. That is, the parser on seeing XHTML, in the PUCLIC identifier, would set a strict layout. The question is should we also consider the document's mime type in selecting a layout mode? In other words ( It think ) documents with text/xml mime type should always be treated STRICT regardless of the DOCTYPE.
CCing David Baron and Ian Hickson for input.
At first glance the layout issues are probably a dup of bug 22274, although I haven't looked closely. Are there doctype issues here too (beyond the fact that our DOCTYPE parsing code sucks, bug 44340 and dependencies)?
We are rendering the page correctly. Say "img { display: block }" to get the rendering you expect. Or, just use an HTML 4.0 Transitional DOCTYPE -- not much point labelling a document as XHTML if you then don't follow the standards! ;-) *** This bug has been marked as a duplicate of 22274 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
img{display:block;} does not fix the problem, it only makes it worse. I don't think images are the problem, because if I only had text, Mozilla would alter the spacing in the same manner. Also, applying display:block to other elements /really/ breaks the page. So while it may be a block issue, it's not dependent on images. Are there other work-arounds besides this, ones that take all elements into account, not just images? You'd think that with the new standards you'd be able to have /some/ way to make it render like the old way. I'll try to post a testcase with just text soon.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
A good example is the aforementioned http://www.kontek.net/index1.shtml vs. http://www.kontek.net/index.shtml Notice the spacing on the smaller print. I think that best represents the overall problem. Maybe it still isn't a bug, but should there not be a general work-around for this ubiquitous spacing issue?
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9 → mozilla1.0
I don't see the problem in that test case. The fact that we're replacing the images by their ALT text doesn't help. I still don't see anything in this bug that's not a duplicate of bug 22274. (Note that 'vertical-align: bottom' won't break things if there are multiple images per line.)
Again, http://www.kontek.net/index1.shtml vs. http://www.kontek.net/index.shtml The first being the problem. There is a spacing issue with the small text, and this has nothing to do with any images. Tables aren't even involved, the problem is the height of any arbitrary line.
Status: ASSIGNED → NEW
Does that "problem" go away if you specify the font on the block level element when you mean to specify it on the block (rather than specifying it on an inline element that contains all the contents of the block)?
This morning's builds had a bug ( bug 80746 ) which may have led to a Bugzilla user inadvertantly changing this bug from the Assignbed/Accepted status to the New status. If you are the owner of this bug please check to see that it is in the correct Status. Thanks.
Worked around with CSS tags such as the following... body{line-height:1px;font-size:8pt;} tt{font-size:10pt;font-family:'Courier New',Courier;line-height:115%;} font{font-family:Arial,Helvetica,'sans serif';line-height:115%;} ol{font-family:Arial,Helvetica,'sans serif';line-height:115%;} select{font-family:Arial,Helvetica,'sans serif';font-size:10pt;line-height:115%;} input{font-family:'Courier New',Courier;font-size:10pt;line-height:115%;} Most important being the entire body tag, and the line-height attribute.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
Aaron, this bug has not been assigned to you, and nobody has said that this will not be fixed in the browser. Therefore I think it was unappropriate to close this bug with WONTFIX resolution. I am reopening. If you genuinely think this should not be fixed, please voice your arguments and we will consider it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
AFAICT, it's a dup of bug 22274.
This is in fact dup of bug 22274. I just felt that that bug was marked 'invalid' when it was more of a 'wontfix' situation. I _do_ think that it should and can be corrected to some extent as discussed in that bug, but I've posted the workarounds here for compatibility sake in the case that it isn't (which is how it looks to stand now). I'm going to open new bugs for a few other quirks that I've found while exploring these workarounds. I'll post links as soon as I have submitted them for those interested. *** This bug has been marked as a duplicate of 22274 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
New bugs: bug 82258 - DOM-based DHTML content shows up in the wrong place... bug 82261 - Incorrect handling of DOCTYPE tag bug 82265 - Small CSS line-height causes form elements to display oddly Also now I remember that the original reason that this wasn't marked DUP of 22274 earlier was that there was a question of why HTML 4.01 and XHTML 1.0 _Transitional_ should be rendered in standard (Strict) mode.
Yes, this is a dupe of bug 22274. Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: