Closed Bug 141023 Opened 23 years ago Closed 22 years ago

inconsistent behavior in rendering leading and trailing whitespace in block elements

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: tfo, Assigned: waterson)

References

(
URL
)

Details

Attachments

(1 file)

Testcase
178 bytes, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041712

on a page in which the only change made is a newline in the html preceding a td
tag, there is more whitespace than if the newline is not present.

Reproducible: Always
Steps to Reproduce:
1. launch Mozilla.
2. visit http://www.angelblade.com/vandytest/
3. Cmd-T (to open a new tab)
4. visit http://www.angelblade.com/vandytest/indexnospace.html

Actual Results:  the two pages should be laid out identically.

Expected Results:  the first page, which has a newline between tags, but not
between actual content, includes more whitespace when laid out.
Confirming.
Assignee: attinasi → waterson
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Priority: -- → P3
Hardware: Macintosh → All
Shame on you! This bug is a complete drag. I've dealt with this in a few
instances and it definitely lends to perianal itching. I'll consider this bug
the pinworm of the HTML rendering world. If you're familiar with pinworms,
you'll understand the gravity of this bug.
Changing QA Contact
QA Contact: petersen → amar
Keywords: mozilla1.0
I think the reporter mixed up his "Actual" and "Expected" results. I believe 
they should be the other way around.
oops. yes. reverse Actual and Expected results. my apologies. the bug remains,
though.
Is this really a bug?  Whitespace is supposed to be collapsed to a single space
(which it is), not nothing (which you want).  Can you show us the spec that says
otherwise?
The two testcases render identically for me (Win2K trunk build 2002051608)
except that one has the word "test".  What exactly is the difference you're
seeing?  Please be more specific than "includes more whitespace when laid out".
I don't see a difference between the two URI's when looking at them with two
same-sized browser windows in 1.0 RC2 branch Build ID: 2002051706.
Attached file Testcase — 
There is a difference; this attachment displays them side-by-side.  I still
think this is invalid though.
On branch build 2002051806, Win2k, I see the two pages layed out slightly
differently in quirks mode but identically in strict mode.

Reporter: Mozilla has two layout modes. In one, known as "standards mode" or
"strict mode", Mozilla attempts to render the document according to the
standards. In the other, known as "backwards compatibility mode" or "quirks
mode", Mozilla attempts to render the document as older browsers would, in order
to be compatible with documents written for those browsers. Your pages trigger
quirks mode; see http://mozilla.org/docs/web-developer/quirks/ for more information.

Could this be an intentional behavior for quirks mode?
The HTML 4.01 Specification states: "authors should not rely on user agents to
render white space immediately after a start tag or immediately before an end tag."

The XHTML 1.0 Specification is even more specific: "Leading and trailing
whitespace inside a block element must be removed."

So it appears that the browser is supposed to collapse whitespace in between
elements, but strip whitespace immediately within a block element, for example,
the whitespace immediately within the td tags in this bug's example. Right now,
Mozilla seems to be behaving incorrectly for both XHTML and HTML (from my
personal tests).

For more info on the whitespace specs check:
http://www.w3.org/TR/xhtml1/#uaconf
http://www.w3.org/TR/html4/struct/text.html#h-9.1

It would be a shame not to meet the W3 standards for this before the 1.0 release.
So wait a minute, you're telling me that Mozilla renders this incorrectly ON 
PURPOSE??!! That's totally rediculous. So if I want my HTML to actually 
render according to the W3 specs, I have to specifically declare my 
doctype to be strict? Otherwise I get crap? This is surreal.
Kaldari: making the no-whitespace testcase render identically to the other in
quirks mode will /not/ get us any closer to W3C conformance.  We are already
conformant when using strict mode, in which case the rendering seen in the
testcase with whitespace (leaving space for inline descenders) is actually the
correct rendering.  See bug 22274.

There /is/ apparently a bug here, since Moz currently allows collapsed
whitespace to affect the inline box model in quirks mode, which it probably
shouldn't.  All that fixing this would do would be to make quirks mode more
consistent.  It has no bearing on W3C conformance, however.
sorry Jason, i was testing a few things a little earlier, and that's why the word
"test" showed up.

anyway, i think i'll change the summary a little bit to clarify what seems to be
happening based on my new understanding of Mozilla's rendering bugs and the
whitespace references posted by kaldari.

also, how does one know in which mode Mozilla is rendering its pages?
Summary: layout changing based on whitespace in html (td tags, specifically) → inconsistent behavior in rendering leading and trailing whitespace in block elements
You are able to get actual render mode from Page Info (View | Page Info or
Ctrl+I, tab General). 

To learn more about Quirks:
http://www.mozilla.org/docs/web-developer/quirks/
http://www.mozilla.org/docs/web-developer/quirks/doctypes.html
http://www.mozilla.org/docs/web-developer/quirks/quirklist.html
ok, to back up kaldari a little bit about compliance issues, check out

http://www.angelblade.com/vandytest/xhtmlwithspace.html

vs.

http://www.angelblade.com/vandytest/xhtmlwithoutspace.html

the latter case here, according to the spec and the fact that they're rendering
in standards compliant mode, should remove the whitespace, if i'm reading things
correctly. unfortunately, these two cases are rendered exactly the same. they
render the same as

http://www.angelblade.com/vandytest/index.html

i would've guessed the latter would render the same as

http://www.angelblade.com/vandytest/indexnospace.html
Thomas: no, "removing whitespace" is not the same as "removing inline descender
space below images".  In strict mode Mozilla correctly removes the whitespace,
but also correctly leaves the space for descenders because <img/> is an inline
element like any other and must follow the inline box model.  Please see bug
22274, this has been hashed to death there.  Also see
http://developer.netscape.com/evangelism/docs/articles/img-table/ for a good
layman's explanation.
Ah, I see what you're saying Jason. So actually, the version with extra 
whitespace is the version that is rendering correctly, rather than vice 
versa. Hmmm, that's definitely going to cause some problems :) I guess I 
need to go read bug 22274 now.
in which case, i guess my question is:

why does

http://www.angelblade.com/vandytest/indexnospace.html

remove the descender space?

is there a bug involved in any of the behavior discussed so far, or is this
report invalid, as well?
Since the nospace version has no text, it does not have a descender.
Since the original version has text (albeit invisible), it has a descender.
(And the XHTML versions always have the descender.)

I would not be surprised if the descender disappeared from the original if you
aligned the image to the left.
it does disappear if the image is aligned left.
in which case, should this bug stay valid just for the sake of making quirks
mode more consistent?
> why does
> http://www.angelblade.com/vandytest/indexnospace.html
> remove the descender space?

This is a function of quirks mode, designed to mimic behavior of legacy browsers
for compatibility.

> is there a bug involved in any of the behavior discussed so far, or is this
> report invalid, as well?

I believe there /is/ actually a valid bug here: we don't consistently remove
descender space when there is leading/trailing whitespace vs. when there is no
whitespace.  The specs in comment 11 seem to indicate that the two cases should
be treated identically (as if there were no whitespace), so the quirks mode
rendering should be identical in both cases.  It's a consistency issue.
The rendering may be considered 'inconsistent', but the quirks mode rendering is
consistent with previous Netscape releases (which it tries to emulate), and it
doesn't break any specs since we're talking about HTML 4.0x.  According to SGML
standards, only leading/trailing newlines should be ignored.  The example given
in the HTML 4.01 spec leads me to believe that browsers (ie. IE) were perhaps
'incorrectly' removing the whitespace.  Consistency is treating all whitespace
the same, as we do now.

->INVALID
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: