Closed Bug 80607 Opened 24 years ago Closed 24 years ago

[AltSS] <body> background doesn't cover canvas for alternate stylesheets [BG]

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 63863
Milestone:
mozilla1.0.1

People

(Reporter: fantasai.bugs, Assigned: hyatt)

References

(
URL
)

Details

(Keywords: css1, testcase, Whiteboard: [Hixie-P2] very visible when demonstrating alternate stylesheets)

Attachments

(3 files)

Preferred Stylesheet ("Green")
146 bytes, text/css
Details
Alternate Stylesheet ("Blue")
48 bytes, text/css
Details
testcase
521 bytes, text/html
Details
Overview: Setting the CSS background property on HTML <body> should paint the canvas. (http://www.w3.org/TR/REC-CSS2/colors.html#q2) Mozilla does this correctly for the original style set on a page, but treats the <body> as a normal block when applying an alternate stylesheet. (Note that the canvas background is correctly reset to the user prefs before applying the alternate stylesheet.) Steps to Reproduce: 1. Open up testcase (to be attached shortly) in Mozilla. 2. Go to View > Use Stylesheet and select Blue Expected Results: The canvas should turn light blue. Actual Results: The canvas turns white and only the <body>'s block has a blue background. Tested on Mozilla nightly build (id: 2001051220) on Windows 2000
Attached file testcase —
Hyatt: This is probably something that you can look at since it is probably very close to the BodyRule stuff.
Assignee: pierre → attinasi
URL: http://www.libpr0n.com/
Component: Style System → Layout
Keywords: css1, mozilla1.0, testcase
OS: Windows 2000 → All
Hardware: PC → All
Summary: [AltSS] <body> background doesn't cover canvas for alternate stylesheets → [AltSS] <body> background doesn't cover canvas for alternate stylesheets [BG]
Whiteboard: [Hixie-P2] very visible when demonstrating alternate stylesheets
This sort of thing happens on David's site. http://www.people.fas.harvard.edu/~dbaron/css/ 1. Load the page 2. Switch from the "Oldstyle" stylesheet to "none" 3. Now switch back to "Oldstyle" 4. Notice the leftover white are around the normal content area and the shrunken space for the normal content area. Seems that either the body is given an excessive amound of margin, or the html element is given an excessive amount of padding. NOTE: The same sort of thing happens when going into prefs and changing the default unvisited link color to something else and then applying it. Try going to http://www.mozilla.org/ and then try it. You will see the black borders grow wider and there will be more padding between the borders and the text. I commented on this behavior in bug 81152 Refreshing the page alleviates both of these problems, but it sure is annoying and significantly reduces usefulness of alternative stylesheets. Jake
*** Bug 82592 has been marked as a duplicate of this bug. ***
*** Bug 83076 has been marked as a duplicate of this bug. ***
Apparently this only happens in standard mode? (See bug 83086)
Yep. Just checked. (BTW, the workaround is to specify the background on <html> or :root.)
FIXED between 2001053104 and 2001060308 builds, probably by Hyatt's "Rule matching performance improvements" checkin on 2001-05-31 (bug 78695) Tested on the above two builds and 2001062004 on Windows 2000
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Fantasai, How did you test this? The way I see it the behavior is worse than it was before! Using the testcase attached to this bug, did you you ever select the "Blue" stylesheet and then select the "Green" stylesheet? After doing that, I still see the exact same behavior as I did before with build 2001062104 (the one from 10:20 today) on Win2k (SP2). That is, the green background now only covers the area surrounding the text, not the entire page.... and you still see the blue on the rest of the page. Also, after selecting "Blue" and then selecting "none", no change is made at all. I would expect to see green since that is the main stylesheet. Blue, being an alternative stylesheet should no longer be used when selecting "none", yet no change is apparent. Reopening Jake
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Tested in the wrong direction, apparently. Sorry~ m(_)m >I would expect to see green since that is the main stylesheet. You should see your default background, since 'none' disables both alternate and preferred stylesheets.
>You should see your default background, since 'none' disables both alternate >and preferred stylesheets. Yep, you are right on that one. Brain fart. Also, I had made a testcase for bug 82446 (marked as a dup of bug 47760) which used to show the text color not being changed back to defaults when switching the style to "none" resulting in text that disappears (first white on black, then white on white). However, now, nothing happens at all when the stylesheet is switched to "none". The titled stylesheet is still used. http://bugzilla.mozilla.org/showattachment.cgi?attach_id=35929 Jake
I bet my new rule tree cache isn't getting invalidated when you switch between alternate stylesheets. Taking.
Assignee: attinasi → hyatt
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
Just wanted to note my comments from bug 47760 here:... "I had posted a testcase in bug 82446 which showed the body text disappearing into the white background after the style sheet was switched to none (originally, the styles said color: white; background: black; and when swithed to none, it would revert to defaults color: black; background: white;) because the white text didn't switch to html.css' defaults (which is what this bug is about). http://bugzilla.mozilla.org/showattachment.cgi?attach_id=35929 However, now I am see that switching to "none" doesn't do anything to the styles whatsoever. It doesn't even turn the background to white. This is something pretty new." I thought Hyatt's fix for bug 90081 might have fixed this, but it didn't do anything to fix this one. I still see the above behavior. Tested with build 2001071903 on Win2k (SP2) Jake
Target Milestone: mozilla0.9.3 → mozilla0.9.4
I think this bug may have been fixed by fixing bug 88681. Can this be marked as a dup of that one??? Jake
On second thought, http://www.libpr0n.com/ still has this issue with its "blue.css" stylesheet. When choosing this stylesheet, the bottom part of the screen doesn't get painted blue/purple, rather, it is white. I observed this on: http://www.libpr0n.com/faq.html This seems to be a fringe case since "blue.css" ( http://www.libpr0n.com/blue.css ) has some funky stuff going on in it like: body { display: table; -moz-binding: url(bindings.xml#blue); width: 100%; margin: 0; padding: 0; } In fact, there are a lot of instances of -moz- specific styling. The problem is remedied by either: 1. resizing the window 2. dragging the window just off the screen. In this case, each part of the window that goes offscreen get repainted as can be seen by moving just a small part of the screen and pulling it back. The part that was offscreen is repainted to the proper background-color (blue/purple). Hixie, I believe you are the author of "blue.css". Any idea why this is happening pretty much just with libpr0n.com and "blue.css"? Jake
no idea whatsoever, blue.css is one crack-baby stylesheet. Do you want to work on minimising it? ;-)
I was afraid you'd say that, Hixie :-) I can certainly try, but I don't know what a lot of that css is doing in the first place? Especially the -moz- binding stuff. Any reference you can point me to for the -moz proprietary styles? jake
not really... the easiest thing to do is to try to remove them first, and see if that causes a difference. Chances are most of them will not be the root cause of the problem. For example, -moz-border-radius almost certainly isn't. -moz-binding is how you link XBL into the document, it _might_ be relevant.
Target Milestone: mozilla0.9.4 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
The only issue I see here is the repaint issue in *** This bug has been marked as a duplicate of 63863 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: