Now that you have the fix where CSS backgrounds on BODY end up on HTML if there is no HTML background, the attributes of the BODY html element should actually set the background on BODY (they now seem to work on HTML) to ensure correct interaction of CSS and non-CSS presentational hints. See the above URL for how this problem shows up.

Actually, this bug may be entirely different. I think it may have to do with when you do the BODY-> HTML change if HTML has transparent background. I was playing with a user stylesheet (in ua.css) that had a BODY background color defined in CSS, and I looked at a web page that had a different body color, and I saw the yellow from the ua.css around the edge of the BODY of http://www.fas.harvard.edu/~dbaron/csstest/results.html

Whatever the cause of this, it is now (build of 1999-02-11) fixed. Marking as resolved-fixed.

verified

Reopening bug... This bug has now started up again (using build 99-02-24). See the URL above (http://www.fas.harvard.edu/~dbaron/csstest/noncss.html). The image background is being put on HTML, and the yellow background on BODY is not being moved onto HTML to completely replace the tiled image (or, really, the image background is moved too soon, before the yellow background overrides it). Thus the image shows up in the BODY margin (or, if the image doesn't load, the blue background shows up). Going back to old builds, this problem reappeared between the builds of 99-02- 18 and 99-02-19. The image is specified on BODY BACKGROUND="bg.gif", where a color is also specified (light blue), but the color is overridden by the style sheet, which gives a yellow color and no image.

This bug shows up in a stripe (a different shade of blue, which comes from the first linked stylesheet) at the bottom of: http://www.misunderstood.net/ Retitling bug from "BODY background should go on BODY" to "BODY background cascading problems"

It looks okay to me, but then again it isn't exactly clear what's wrong from the many bug summaries. If there is a bug, a very simple (as simple as possible) example would be very helpful. Peter, I haven't changed the body code in months and it seems to work fine for all cases I've seen. Is David suggesting the problem is with how we're handling CSS cascading?

David: Can't get to the .css file from the test case (http://www.fas.harvard.edu/~dbaron/csstest/noncss.html). Could you please send it to me?

Troy - what I was suggesting was that your fix for "If the HTML background is transparent, then set the HTML background to the BODY background and make the BODY background transparent" was done too early, so that if BODY background was set at two levels of the cascade, one of them would end up on BODY and the other would end up on HTML. I also saw this bug when switching between alternate stylesheets. All - I'll try and check it out now to see if its fixed. This bug is one that has a habit of disappearing and reappearing. I may not finish checking until tomorrow.

That makes sense, and that's why I was asking Peter about whether it was a problem with cascading. I don't know that there's much I can do about it in layout. At least not without Peter's help

Since you say this code hasn't been changed in months, I'm reopening it on the basis of the 99-03-30 build. Here are the problems I see: http://www.fas.harvard.edu/~dbaron/csstest/noncss The entire canvas should be yellow. You should *not* see the black and white image of a hurricane peeking through around the edges, in BODY's margin. http://www.fas.harvard.edu/~dbaron/tests/nglayout/altss As you switch between alternate stylesheets (using "Select Alternative 2", etc.), the color of BODY's margin (which is most of the page) doesn't change, as it should. It stays the original blue. It should turn off-white for 2 and white for 3, I think. Only the middle part is changing right now. The other pages are basically variants of these two problems.

Peter, the code in BodyFixupRule::MapStyleInto(), which is where the CSS precedence rules for dealing with BODY background live, hasn't been changed since 1/15 or so. Looking at David's style sheet it looks like the problem is that the BODY has HTML attributes for things like BGCOLOR, and the linked style sheet also specifies a background color. Things behave differently depending on whether there is a LINKED style sheet, or whether the style rule is specified in the HEAD of the document. This way: <HTML> <HEAD> <BASE href="http://www.fas.harvard.edu/~dbaron/csstest/"> <LINK REL="stylesheet" HREF="noncss.css" TYPE="text/css"> </HEAD> <BODY BACKGROUND="bg.gif" BGCOLOR="#C0C0FF" TEXT="#000080" LINK="#800000" VLINK="#008000" ALINK="#000080"> <H1>Handling of non-CSS presentational hints - Author stylesheet</H1> </BODY> </HTML> it displays wrong, and this way: <HTML> <HEAD> <BASE href="http://www.fas.harvard.edu/~dbaron/csstest/"> <STYLE> BODY { background-image: none; background-color: yellow; color: black; } </STYLE> </HEAD> <BODY BACKGROUND="bg.gif" BGCOLOR="#C0C0FF" TEXT="#000080" LINK="#800000" VLINK="#008000" ALINK="#000080"> <H1>Handling of non-CSS presentational hints - Author stylesheet</H1> </BODY> </HTML> it displays correctly...

The problem here was in the body fixup rule after all. During the first reflow (before the external style sheet loaded) it propogated the body background into the HTML element. Then when the style sheet loaded, it chose NOT to propogate the body background because the previous BODY background was still set (so it thought that the HTML picked up a background from somewhere else). I added a "propogated" bit to the background flags, so that the BODY can tell if the HTML's background is one that came from the BODY before, and it safe to replace.

I remember asking you about whether that code needed to worry about that. I was under the impression that the style system always reset the HTML element's style before calling the body fixup's rule. That way we always started with a clean slate. I guess that wasn't the case after all

Actually, the style system DOES reset the HTML's style, it was more sublte than that. When the frame model got tossed and re-generated for the style sheet load, the old frames weren't getting deleted until long after the new ones were created (and style resolved for them), so the old child context for the previous body was still inserted in the style context tree when the new body was resolved, so it still propogated it's data upward and whacked the freshly reset HTML style...

It must have been a beauty to track down. Thanks for fixing it!

Verified fixed (on all 4 pages).