Closed Bug 2926 Opened 26 years ago Closed 25 years ago

BODY background cascading problems

Categories

(Core :: CSS Parsing and Computation, defect, P2)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: peterl-retired)

References

()

Details

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
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Whatever the cause of this, it is now (build of 1999-02-11) fixed.  Marking as
resolved-fixed.
Status: RESOLVED → VERIFIED
verified
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Summary: BODY background should go on BODY → BODY background cascading problems
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"
Assignee: peterl → troy
Status: REOPENED → NEW
Assignee: troy → peterl
Assignee: peterl → troy
Status: NEW → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → WORKSFORME
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?
Whiteboard: Pending .css file from reporter prior to verification
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
Status: RESOLVED → REOPENED
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.
Assignee: troy → peterl
Status: REOPENED → NEW
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...
Resolution: WORKSFORME → ---
Status: NEW → ASSIGNED
Target Milestone: M5
Whiteboard: Pending .css file from reporter prior to verification
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
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!
Status: RESOLVED → VERIFIED
Verified fixed (on all 4 pages).
You need to log in before you can comment on or make changes to this bug.