237243 - macecraft.com - rendering problems with 20040310

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Lukas Petrovicky (CZilla)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040310 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040310 Firefox/0.8.0+

check the link I supplied - check it with a fresh FireFox 0.8 and then check it
with FireFox 20040310 - what do you see?
I see main differences in jv16 PowerTools' description (it is too much indented
and the last line is not). The second difference is in the RegSupreme's
description (the server names and their ratings are all in one).
These are, IMHO, some new bugs to 20040310, because previous nightlies rendered
this well and FireFox 0.8 renders it well, too...

for better imagination, see enclosed screenshot

Reproducible: Always
Steps to Reproduce:
1. open the site (http://www.macecraft.com/beta/index.php?id=products)
2. take a look
Actual Results:  
the site was rendered bad

Expected Results:  
it should be rendered somehow else, e.g. like FireFox 0.8 does

Comment 1

[Lukas Petrovicky (CZilla)]

Attachment: this is a screenshot with rendering bugs marked red

Comment 2

[Boris Zbarsky [:bzbarsky]]

It looks like the behavior changed between 2004-01-10-08 and 2004-01-11-08.  The
image next to the mis-indented text is a relatively positioned float, so I
suspect the fix for bug 205087 is the problem there.  I don't know what's
causing the overlap; none of the checkins in that range look relevant.

In any case, minimal testcases for both issues would be very helpful.

Removing XHTML from summary, since the page is served as text/html.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 5

[Mats Palmgren (inactive)]

As far as I can see they are both the same problem - we are making room for
the float inside the rel. pos. block without taking its position into account.

Both problems disappear when I back out bug 205087.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm... well, both renderings are exactly what bug 205087 was trying to achieve
and are correct per CSS spec as I understand it...

Comment 7

[Mats Palmgren (inactive)]

I find the new layout undesirable and I can't find anything in the CSS2.1 spec
that forbids the old layout.  Can't we fix bug 205087 by adjusting the
clearance after the block is moved to its relative position? (after all the
rel.pos. also moves the top margin and the clearance is "above the margin-top").
http://www.w3.org/TR/2004/CR-CSS21-20040225/visuren.html#clearance
(So the clearance would grow to compensate for the negative offset to always
fulfill "clear:both" in the testcase for bug 205087).

Opera (7.23/Linux) also has the old (presumably buggy) layout.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The point is that the way relative positioning works is that you lay everything
out as if no positioning were specified and then you move the positioned content
over without changing any layout anywhere else (either inside it or outside it).
 So in my opinion what we used to do and what Opera does is a pretty direct
violation of the definition of relative positioning.

If the flow of the text is to be affected when relative positioning happens,
then in addition to flow around floats you would naturally have to change
line-breaking, etc...

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The first two paragraphs of 
http://www.w3.org/TR/2004/CR-CSS21-20040225/visuren.html#relative-positioning
are pretty clear that relative positioning doesn't affect layout except for
possible creation of scrollbars.

Comment 10

[Hixie (not reading bugmail)]

Our rendering is correct. Both the image and the paragraphs are relatively
positioned, with the effect that it looks like the text is moving out of the way
for no reason. But there is a reason, as you can see if you delete the two
position:relative rules.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Uh... Ian, this is an evang bug at this point.  Invalid means something very
different in this product.

Comment 12

[Hixie (not reading bugmail)]

Oh, my bad. Didn't notice the product change (got the first bug mail, read the
comments, checked the resolution, marked invalid. Nobody mentioned it moving to
TE, so...).

Comment 13

[Mats Palmgren (inactive)]

Attachment: Testcase #3

Comment 14

[Mats Palmgren (inactive)]

Thank you for your replies, after reading 9.4.3 more closely, I agree that
the intention of the spec is pretty clear.

Still, the old layout has its merits.  I suspect that in the majority of cases
you don't want to flow around a float at the normal flow position (Testcase #1)
and also in the majority of cases you do want to flow around a potential float
at the relative position rather than overlap it (Testcase #3).
To me, the old layout seems both more natural and useful.
I think the new layout will cause gaps and overlaps where authors did not
expect them.

Comment 15

[Hixie (not reading bugmail)]

If you want the spec changed, please raise this in www-style. We're just doing
what the specs say...

Comment 16

[Lukas Petrovicky (CZilla)]

I see this was reopened. Why did we reopen?
From the comments I sense we won't do anything about it.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Lukas, this is an evangelism bug.  That is, it's now a bug about contacting the
site and having them fix their code.

Which is what I already said once, in comment 11...

Comment 18

[Lukas Petrovicky (CZilla)]

oh, sorry then... I got it wrong...
I'm gonna have the site fixed, if this is definitely a "new" behaviour.

Comment 19

[Felix Miata]

Conforming summary to TFM item 10 at 
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new