Two Layer Background + Browser Zoom

HTML & CSS
1

Hi,

As I’m aware, best way to have two layer background is to put one background on html element and the other in body element. So html contain repeat background positioned left top, and body contains repeat-x background positioned left top. Works great on all browsers, but that’s not the case when it comes to zoom (not text resize). Assume the intended effect is striped background with gradient color variation on top.

Results on Firefox
On increase zoom + horizontal scroll: while the html element background takes up the whole scroll width, it’s not same for the body element.

On decrease zoom: works as expected.

Results on Chrome
On increase zoom + horizontal scroll: same as Firefox.

On decrease zoom: Here, when zoom is decreased from default 100% zoom, the body background is misaligned.

Results on Safari 3
On increase zoom + horizontal scroll: same as Firefox, but background doesn’t scale on both html and body element.

On decrease zoom: background doesn’t scale on both html and body element, so technically no breaking occurs, but since everything else is resized it should only be natural for this to resize too, yes?

Results on Opera
On increase zoom + horizontal scroll: same as Firefox.

On decrease zoom: same as Firefox.

Results on IE 7 (buggy zoom)
On increase zoom + horizontal scroll: here the html background doesn’t zoom, but body takes up all the scroll width unlike other browsers. Hence misaligned.

On decrease zoom: Same as increasing zoom, but body doesn’t take up all the width.

Results on IE 8
On increase zoom + horizontal scroll: Same as Chrome only when zoomed +20% (120%, 140%, 160% etc.) otherwise slightly misaligned.

On decrease zoom: Same as Chrome.

So How do I create an effect of striped background with “gradient color variation on top” that consistent across browsers + doesn’t break when zoomed (decreased or increased)?

Thanks in advance. :slight_smile:

2

Paul’s advice of leaving HTML alone is probably your best bet. It’s not an element you can trust cross browser to use for effects… only time I’d even TRY to target it is to null it’s margins and padding and to make sure body can accept a height – as Paul said. Other than that, leave it alone.

3

Hi,

These link should work! (if it doesn’t, I’ll post source + images). :slight_smile:

TEST CASE 1: Test Case 1 link

Please refer to my previous post for test results, and see if you guys get the same results.

TEST CASE 2: Test Case 2 link

edit: I haven’t read the above post by Paul when I made this post. So whether zoom, text-resize, or content expanding to cause horizontal scroll - there is no way to maintain a consistent multilayer background?

4

Hi,

I don’t know if this will make a difference with zooming but as a rule of thumb I never use the html element for anything except margin:0;padding:0 and height:100%. For everything else I leave it alone.

If you need two backgrounds then use the body and then use a 100% high wrapper for the other image.


<!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=utf-8">
<title>Untitled Document</title>
<style type="text/css">
html,body{
    margin:0;
    padding:0;
    height:100%;
}
body{background:url(image1.gif)}
#outer{min-height:100%;background:url(image2.gif)}
* html #outer{height:100%}
</style>
</head>

<body>
<div id="outer">all content in here</div>
</body>
</html>

The body and html have a special relationship and styles (background images) applied to the body are automatically propagated to html. If you apply an image to html then the body effectively shrinks to content height and the you have to use height:100% on html and min-height:100% on the body.

Therefore I find it safer and easier to use the above construct. It would be interesting to see if it zooms better also :slight_smile:

Of course for html documentsyou should not be styling the html element anyway.

w3c:

The background of the root element becomes the background of the canvas and covers the entire canvas, anchored (for [URL=“http://www.w3.org/TR/CSS2/colors.html#propdef-background-position”]‘background-position’) at the same point as it would be if it was painted only for the root element itself. The root element does not paint this background again.
For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element.

5

I’m not quite sure what you mean by zoom here (and an example page to test would be nice).

Anyhow, I would normally put the stripes on the <body> element and then have a 100%wide div at the top with the gradient background on it.

If a test page is really required, then I’ll have to upload it somewhere (will do so after lunch :P).

When I mean Quote: “zoom (not text resize)”, I exactly mean browser zoom option - I’d have thought it’d be obvious especially when I mentioned 120%, 160% etc in IE and the mention of IE7’s buggy zoom. In windows It’s usually CTRL + mouse wheel.

I’ll try to upload a test page somewhere soon. Thanks. :agree:

6

As Ralph said you can either stop the scroll from happening or you set a min-width equal to the largest element that will cause the scroll and the body will match the elements width.

e.g. In your example the element is 57.5em wide so that would be the minimum width you want for the body.


body{min-width:57.5em}

You could instead apply display:table to the body and that would make the body keep track with the content but it’s not really advisable as some browsers can act strange if this is added to the body.

7

I’m not quite sure what you mean by zoom here (and an example page to test would be nice).

Anyhow, I would normally put the stripes on the <body> element and then have a 100%wide div at the top with the gradient background on it.

8

Personally, I prefer to avoid horizontal scroll altogether. In this example, just set a maximum width to the Content.

E.g.

#content {
    max-width: 90%;
}

In normal cases, that would be applied to a wrapper that contains all of the content.

9

Alright, I somewhat knew it was not a problem with zoom feature and I can live with some misalignments when it comes to zoom- this also happened with text resize + horizontal bar. So, only the root element, elements that wrap the expanding element, and few others mentioned will have background through scroll width. I didn’t know that.

So again - whether zoom, text-resize, or content expanding to cause horizontal scroll - there is no way to maintain a consistent multilayer background? If there is absolutely no way, then I’ll be satisfied and let it go, but otherwise I’ll have to know because when in future sometime if I ever get confidence to become a freelancer or get a job somewhere and I run in to multilayer background that is not taking up scroll width - I want to know it’s not doable because it’s not possible and not because of my lack of knowledge. Could you clarify, Paul? Thanks again. :slight_smile:

10

Perhaps you could just post the code, with CSS embedded, and we can test it ourselves. You can upload any images to the web and provide absolute links to them in the code.

Or zip the page code with images and post here.

11

As a user who does use it, uhm… no. Why no? Because so many people are using images instead of text on things like buttons you have no choice but to want images enlarged as well. See the complete accessibility /FAIL/ trash used on these forums for ‘edit’, ‘quote’, ‘post reply’, etc… None of which are even legible due to the fancy script, absurdly small size and poor choice of color contrasts/outline methods.

Which is why I still say Opera is the only browser to get it RIGHT – Not only does it rescale everything, you have the ‘fit to width’ option that forces down the size of things larger than the page… But as I’ve said a few dozen times anyone who needs accessibility is going to be using Opera or IE since gecko based browsers make a right mess of things not only with the strangely broken zoom (like the fixed margin auto’s?) but also by ignoring the system metric. (Aka OS DPI/font-size settings). Then of course there’s webkit standing around confused going “accessibility, what’s that?”

But those of us who use it fully expect many layouts to be broken – especially the retarded fixed width layout crap that so many people vomit up and call websites. Fluid and semi-fluid layouts are much more well behaved in that regard.

For example, google, ebay – work great. Yahoo? Not so much.

Usually the only time it’s really an issue is when you are dumb enough to be trying to use firefox to do something accessibility related in the first place (much of which can be blamed on it’s Nyetscape heritage), or are obsessed with everything being pixel-perfect, which is more myth than fact. (and can be blamed entirely on the “but I can do it in Photoshop” dumbasses)

12

It seems the free host doesn’t allow hosting files. Guess I’ll try to find some other hosts. Since I’m mostly in training and making sites that I never get to launch I don’t have a paid hosting account. :slight_smile:

13

Alright I have uploaded two test cases, one with the problem I was having and the other - Paul’s suggestion.

TEST CASE 1: Test Case 1 link

There were some changes from when I used my original design, the stripes were much smaller. So in this test case some changes occurred from my original observation which I included notes in blue color.

Results on Firefox
On increase zoom + horizontal scroll: while the html element background takes up the whole scroll width, it’s not same for the body element.

On decrease zoom: works as expected.

Results on Chrome
On increase zoom + horizontal scroll: same as Firefox. Chrome misaligns even when zooming in, only not as obvious as when zooming out. The thing is, it’s not scaling uniformly.

On decrease zoom: Here, when zoom is decreased from default 100% zoom, the body background is misaligned.

Results on Safari 3
On increase zoom + horizontal scroll: same as Firefox, but background doesn’t scale on both html and body element.

On decrease zoom: background doesn’t scale on both html and body element, so technically no breaking occurs, but since everything else is resized it should only be natural for this to resize too, yes?

Results on Opera
On increase zoom + horizontal scroll: same as Firefox.

On decrease zoom: same as Firefox.

Results on IE 7 (buggy zoom)
On increase zoom + horizontal scroll: here the html background doesn’t zoom hence misaligned, but body takes up all the scroll width unlike other browsers.

On decrease zoom: Same as increasing zoom, but body doesn’t take up all the width.

Results on IE 8
On increase zoom + horizontal scroll: Same as Chrome only when zoomed +20% (120%, 140%, 160% etc.) otherwise slightly misaligned. It seem the zoom level doesn’t matter in IE8, in this test - it aligns properly at different zoom levels than before, it still misaligns.

On decrease zoom: Same as Chrome.

TEST CASE 2: Test Case 2 link

Hi Paul,

I redid my layout as per your suggestion, test case 2 results are identical to test case 1. I’m not sure if I explained my problem properly.

More suggestions greatly welcome :slight_smile:

14

On increase zoom + horizontal scroll: while the html element background takes up the whole scroll width, it’s not same for the body element.

I think you are misunderstanding what is happening here. If an element causes a horizontal scrollbar then the other elements on the page (that are not causing a horizontal scroll) have their backgrounds painted to the viewports edge. eg. 100% width (just like the body in your example). If you scroll sideways to see the element that is causing the scroll the backgrounds on their elements won’t follow because they finished at 100% and you are now into territory that is grater than 100%.

The only background that follows is the background on the root element and the background on the element causing the scroll and any floated or display table elements wrapping the scrolled element as they are also held open.

This has nothing to do with zoom and will occur when any element forces a horizontal scroll.

Zooming doesn’t seem to be an exact science and to be honest I believe most users who use it for accessibility want bigger text not bigger layouts and use the zoom text only option instead.

I always expect to see some mis-alignment when zooming but as long as the page is working and usable then I don’t mind the odd discrepancy.

15

Those links don’t work. :frowning: