Rendering bugs

by **and** » Thu Mar 22, 2007 11:31 pm

These issues may not be directly related to HTML5 as such, but I believe that this forum is supposed to be slightly more general.

The page http://html5.ouvaton.org/bugs1.html illustrates two apparent rendering bugs:

1) The grey box is rendered immediately after the yellow paragraph in Opera and Firefox, but separated by the yellow paragraph's margin-bottom in Safari and IE7. The behaviour in Safari and IE7 seems more reasonable, but that does not, alas, necessarily mean that it conforms to the specifications. Is this a known issue? If not, to whom should the bug reports be sent?

2) Opera seems to have a problem with createElement.

Thanks in advance for your advice.

--
&

by **zcorpan** » Fri Mar 23, 2007 1:24 am

It seems you're testing at least two things here.

I'd suggest you split up your test case into separate tests so that each file only tests one thing. Then it's a lot easier to debug.

This could be of help: http://www.hixie.ch/advocacy/writing-te ... b-browsers

by **and** » Fri Mar 23, 2007 3:44 am

Quite right.

http://html5.ouvaton.org/bugs11.html and http://html5.ouvaton.org/bugs12.html now illustrate the two separate issues.

--
&

by **zcorpan** » Fri Mar 23, 2007 5:00 am

bug12.html is clearly a bug in Opera (things shouldn't appear or disappear randomly). Try to simplify it as much as possible and make a clear pass condition, then file a bug.

bug11.html I'm not sure which is correct; you'd have to read the CSS21 spec about margin collapsing and absolutely positioned elements. Assuming Opera and Firefox are correct, here's a reduced test case:

Code: Select all: <!doctype html> <title>Margin collapsing and absolutely positioned elements</title> <style> p { margin-bottom:50px; width:10em; border-bottom:10em solid red; } div { position:absolute; width:10em; height:10em; background:lime; margin-top:-10em; } </style> <p>There should be a green box below and no red: <div></div>

HTH,

by **and** » Fri Mar 23, 2007 1:58 pm

Thanks.

I uploaded your test case to http://html5.ouvaton.org/bug1.html. http://html5.ouvaton.org/bug1-rendering.html show sample renderings.

CSS 2.1, §8.3.1 says:

Margins of absolutely positioned boxes do not collapse (not even with their in-flow children).

I think this is enough to show that Safari’s rendering is wrong, but does it actually say that both the margin of an absolutely positioned box and the margins of its adjacent non-absolutely positioned elements shall be respected?

Anyway, the rules for collapsing of positive and negative margins say that the resulting margin is the sum of the most negative and the most positive margins*, so it would seem that IE7 had got it right here in any case.

I clearly do not know the CSS specification well, though, so this analysis may be completely wrong.

--
&

*) Paraphrasing of the following paragraph from CSS 2.1, §8.3.1:

Two or more adjoining vertical margins of block boxes in the normal flow collapse. The resulting margin width is the maximum of the adjoining margin widths. In the case of negative margins, the maximum of the absolute values of the negative adjoining margins is deducted from the maximum of the positive adjoining margins. If there are no positive margins, the absolute maximum of the negative adjoining margins is deducted from zero.

by **and** » Fri Mar 23, 2007 2:28 pm

More obvious test case on http://html5.ouvaton.org/bug2.html. I’ll report this bug later.

--
&

by **and** » Fri Mar 23, 2007 5:34 pm

bug2.html filed as bug-257560.

--
&

by **MikeFoster** » Fri Mar 23, 2007 6:59 pm

I'm still working with your original file. I only just now saw the follow-up replies and other files.

I see several problems with your tests. First, I obviously don't understand something about HTML5 because IMO those files are completely invalid HTML.

Absolutely positioned elements are taken out of "the flow". They should not respect their previousSibling's bottom margin. However, you have not specified a value for "top" - and it's default value is 'auto'. Note what the spec says about this:

If 'top' has the value 'auto' replace it with the distance from the top edge of the containing block to the top margin edge of a hypothetical box that would have been the first box of the element if its 'position' property had been 'static'. (But rather than actually computing that box, user agents are free to make a guess at its probable position.)

IE and other browsers have always "guessed" differently about this. The moral of the story is... if you specify "position:absolute" then specify a position other than 'auto' - don't make the browsers "guess"

. If you want that element to respect it's previousSibling's bottom margin then specify 'relative' (or 'static') instead of 'absolute'.

Here's the code I experimented with:

Code: Select all: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Boxes</title> <style type='text/css'> body { background: red; margin: 50px; /*border: 3px solid green;*/ } #div1 { position: absolute; left: 100px; top: 100px; min-width: 400px; padding: 0px; background: white; border: 2px solid brown ; } p { background: yellow; margin: 0px; margin-bottom: 50px; } #footer { position: absolute; background: gray; padding: 35px; left: 10px; right: 10px; border: 1px solid yellow; } #box1 { position: absolute; left: 20px; height: 20px; width: 20px; bottom: 0px; background: green; } #box2 { position: absolute; width: 20px; height: 20px; right: 20px; bottom: 0px; background: lime; } </style> <script type='text/javascript'> window.onload = function () { // IE does not implement createElementNS //var newDiv = document.createElementNS("http://www.w3.org/1999/xhtml", "div"); var newDiv = document.createElement("div"); newDiv.id = "box1"; document.getElementById("div1").appendChild(newDiv); newDiv = document.createElement("div"); newDiv.id = "box2"; document.getElementById("div1").appendChild(newDiv); } </script> </head> <body> <div id='div1'> This is an abolutely positioned <code>div</code> containg all the text and all the other elements. <p>Normal paragraph in the flow with <code>margin-bottom: 50px;</code></p> <div id='footer'> - This absolutely positioned <code>div</code> is positioned differently in different browsers: Safari and IE7 respect the <code>margin-bottom</code> set on the preceding <code>p</code>; Opera and Firefox ignore it. <br style="margin-after: 1em;"> - The light green square (created using <code>createElement()</code>) does not render correctly in Opera; the dark green (created using <code>createElementNS("http://www.w3.org/1999/xhtml",)</code>) does. </div> <div>static DIV which is nextSibling of 'footer'</div> </div> </body> </html>

Also note that my demo takes care of the Opera rendering issue. This is related to an old "gotcha" that manifests itself in different ways in different browsers. It is related to the fact that absolutely positioned elements do not contribute to the height of their parent because they have been taken out of "the flow". I wouldn't call this an Opera "bug" - I call it a "quirk"

. Technically I guess it is a bug. I haven't had a chance to check the bug database but I would suspect that it is a known issue.

by **zcorpan** » Fri Mar 23, 2007 8:00 pm

MikeFoster wrote:I see several problems with your tests. First, I obviously don't understand something about HTML5 because IMO those files are completely invalid HTML.

Test cases don't need to be conforming; they might test error handling for instance. However, in this case the test cases do in fact conform to the HTML5 syntax. All are not conforming HTML5 though, because div isn't allowed to have both block-level elements and inline-level content as children at the same time. But that doesn't affect what is being tested.

by **and** » Fri Mar 23, 2007 9:07 pm

Thanks for your feedback.

MikeFoster wrote:IMO those files are completely invalid HTML.

You may want to have a look at http://validator.w3.org/check?uri=http%3A%2F%2Fhtml5.ouvaton.org%2Fbugs1-foster.html&charset=%28detect+automatically%29&doctype=Inline&ss=1.

MikeFoster wrote:rather than actually computing that box, user agents are free to make a guess at its probable position

I always thought that this educated "guess" should give the same result as the actual calculation except for possible edge cases, but you are right in pointing out that the specification does not actually seem to require that.

IMHO, the only difficulty in my example is to determine how the margins should or should not collapse, and I am not sure whether the spec actually is unclear or whether I simply fail to read it correctly because I do not know its terminology. (Assuming, for now, that a browser is not actually allowed to make any stupid guess.)

http://html5.ouvaton.org/bugs3.html illustrates how borders collapse or not on static (green) and absolutely positioned (red) elements; there is a difference between IE7/Safari and Opera/Firefox, but where is the bug? In CSS 2.1?

MikeFoster wrote:Also note that my demo takes care of the Opera rendering issue.

Indeed, the bug is not triggered, but I am not sure that your analysis actually explains why the problem occurred in the first place. My initial test did not really exhibit the bug well, though.

Interestingly, the bug vanishes if "bottom: 0px" is replaced with "top: 0px" (the position, incidentally, does not change) in the code on http://html5.ouvaton.org/bug2.html, but replacing the JavaScript with equivalent HTML also fixes the problem, so there is clearly something slightly more complex going on here.

--
&

by **hasather** » Fri Mar 23, 2007 11:00 pm

Test 12 renders a blue rectangle for me in Opera 9.10 (build 521) on Linux.

by **MikeFoster** » Fri Mar 23, 2007 11:14 pm

Hi zcorpan,

Thanks for the link. I had been slowly reading that document but had not yet made it that far.

Hi and,

Yes, I know my file is valid HTML4.01. But I was refering to your files as invalid - however I was basing that on HTML4.01 - I am still quite ignorant on HTML5

http://html5.ouvaton.org/bugs3.html illustrates how borders collapse or not on static (green) and absolutely positioned (red) elements; there is a difference between IE7/Safari and Opera/Firefox, but where is the bug? In CSS 2.1?

I don't think there is any bug at all. The CSS spec allows browsers to "guess" at what 'auto' means for an absolute element.

IMO absolute elements should never respect the margins of their static siblings because they are no longer in the flow. IMO the default value of the top/right/bottom/left properties should be zero, instead of auto. 'auto' implies that the element is relatively positioned and in the flow. By definition, absolutely positioned elements are positioned relative to their nearest positioned ancestor - they are not in the flow. It is no wonder browsers have to guess at how to render this.

...but I am not sure that your analysis actually explains why the problem occurred in the first place.

You are right. I apologize for that. I can't honestly say that I understand the "exact" cause of the problem. I think I went off on a tangent there

. In the newer versions of Opera and Firefox many of those old problems no longer exist. And now, as you noted, this only happens to a dynamically created element.

by **zcorpan** » Fri Mar 23, 2007 11:56 pm

MikeFoster wrote:Yes, I know my file is valid HTML4.01. But I was refering to your files as invalid - however I was basing that on HTML4.01 - I am still quite ignorant on HTML5

It was his file. He just changed the doctype.

MikeFoster wrote:I don't think there is any bug at all. The CSS spec allows browsers to "guess" at what 'auto' means for an absolute element.

I think you're misreading the spec. The guess-work is only a hint that UAs can optimize their implementation, but the end result still has to be the same as if they followed the algorithm literally.

by **and** » Sat Mar 24, 2007 12:13 am

zcorpan wrote:It was his file. He just changed the doctype.

Actually, http://html5.ouvaton.org/bugs1-foster.html is a modified version of the code posted by MikeFoster. Alternatively, I could indeed have modified the doctype and added type attributes to <style> and <script>.

The point I was trying to make is that valid HTML 4.01 Strict can look very much like my initial code.

--
&

by **and** » Sat Mar 24, 2007 12:27 am

hasather wrote:Test 12 renders a blue rectangle for me in Opera 9.10 (build 521) on Linux.

Can you confirm that http://html5.ouvaton.org/bugs12.html (or the equivalent http://html5.ouvaton.org/bug2.html) renders correctly also after reload (ctrl-R, F5 or whatever it might be on Linux). The bug corrects itself after resizing or other events that trigger a redraw, which also seems to happen when one presses enter in the address bar.

I have tested on OS X (build 3588, so the numbers are clearly not directly comparable), and I have been told that the bug also exists on Windows.

--
&

Rendering bugs

Rendering bugs

Who is online

Who is online