133577 - no-repeat and fixed screw up background position in block-level elements

Status: VERIFIED DUPLICATE of bug 119518

(Core :: Layout, defect)

Description

[Seth Foley]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

In any block-level with a background image, adding "background-attachment:
fixed;" and "background-repeat: no-repeat;" causes the position of the
background image to reset to the top left of the body element. Consequently,
only the part of the background image that is within said element is displayed,
which looks very ugly. Removing either of those attributes causes the page to
display correctly in Mozilla, but then the background scrolls or repeats ... and
that's not the point.

Note that the shorthand "background: .... no-repeat fixed;" property also causes
this behavior. You can add other positioning/ repeat CSS tweaks and screw things
up even more royally -- I got a checkerboard effect, once -- but the main thing
is that '...: fixed' and '...: no-repeat' do not play nicely.

I don't know of any workarounds in this situation, because specifying the
position of the background with more CSS (think percentages or pixel values)
only works in a fixed layout--in other words, percentages aren't precise enough
in this case, and pixel values get messed up if the user resizes their browsing
window.

I'm pretty sure this is not an imagelib bug, because the same thing happens with
JPEG and GIF images.

Reproducible: Always
Steps to Reproduce:
1. Load the above URL in IE 5+ and Mozilla 0.9.9.  (http://moztest.20m.com/)
2. Resize the browser windows in both browsers.

Actual Results:  Depending on the size of the browser window, Mozilla will
either display a 'corner' of the red background image (or won't display it at all.)

Expected Results:  The red background should 'start' at the top left of the
element that it is attached to, not the top left of the viewing window.

Occasionally, the background images will not display on the 20m site under
Mozilla.  You can use any background images you like if this is the case and you
want to test the code locally; in my case, I created a black 779x450 px image
called "wrapper.png" and a red 444x262 px image called "divbox.png".  Dump them
into the same directory as the code, and all should work.

Comment 1

[Christine Hoffman]

Changing QA contact

Comment 2

[Richard Brodie]

Not a Mozilla bug. DUPE of bug 119518.

Comment 3

[Seth Foley]

This is a similar bug to 119518, as was said ... however, this is not a 
following-the-specification issue, and I'll post this comment to both bugs.  
Either way, there's something that needs to be fixed (no pun intended.)

From the CSS2 Spec:

"If a background image is specified, this property specifies whether it is 
fixed with regard to the viewport ('fixed') or scrolls along with the document 
('scroll').
"Even if the image is fixed, it is still only visible when it is in the 
background or padding area of the element. Thus, unless the image is tiled 
('background-repeat: repeat'), it may be invisible."

This only means that the image is fixed to the viewport.  But it does not 
specify WHERE in the viewport the image should be fixed.  Why, then, should the 
image be stuck in the top left corner of the viewport by default?  Why not 
position it at the top left of the element that it's assigned to, which would 
make an infinitely greater amount of sense?

The user can still position their background however they'd like by adding 
another CSS property.  However, if no 'background-position: xxxx' is included, 
it's logical to change the default implementation.  Note that unless no-repeat 
is included, simply putting in "background-attachment: fixed" doesn't throw the 
background up to the top left.  It's only in this case that things are screwed 
with.

This doesn't violate the spec at all, and this is how IE and Opera implement 
it.  Why should moz be different from the majority of other browsers, if CSS2 
doesn't get specific?  If there's an uncertain area, it makes sense to go along 
with what most of the competition is doing.

Regardless of whether this is not changed, though, there IS still a bug on the 
issue.  Recall that this bug was created because the interaction of no-repeat 
and fixed caused the positioning to fly out of whack; that is still the case.  
The default positioning should be applied whenever 'background-attachment: 
fixed;' is placed in the CSS, and not just when BOTH no-repeat and fixed are 
present.

So.  I would recommend that the default position of a background element should 
be changed to the top left of the element it's attached to or declared in, and 
NOT the top left of the viewport.  This default positioning should REMAIN 
CONSTANT until the user changes it with the appropriate CSS.

Comment 4

[Boris Zbarsky [:bzbarsky]]

My comments from bug 119518:

> Why, then, should the image be stuck in the top left corner of the viewport by 
> default?

http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-position says that 
the intial value of "background-position" is "0% 0%".  So setting only 
"background-attachment: fixed" is exactly equivalent to 
"background-attachment: fixed; background-position: 0% 0%" unless 
background-position is set in the UA or user stylesheet, of course.

> Note that unless no-repeat is included, simply putting in
> "background-attachment: fixed" doesn't throw the 
> background up to the top left. 

So... if one doesn't set no-repeat then we put the image at top-left of the box 
it's the background for and tile from there?  That's wrong, if so.  We should be 
placing it at top-left of viewport and tiling from there (for 
"background-attachment: fixed", of course).

> This doesn't violate the spec at all

Except for the violation of the definition of the background-position property, 
of course.

> Recall that this bug was created because the interaction of no-repeat 
> and fixed caused the positioning to fly out of whack; that is still the case.

As I said, the real bug is that not having no-repeat does _not_ cause the 
positioning to "fly out of whack" (if it actually does not).

Marking this duplicate of the other bug, which is where the discussion is.  If 
the tiled case is broken (which I can't test at the moment, having no Mozilla) 
then we should file a separate bug on it.

Comment 5

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 119518 ***

Comment 6

[Moied]

verified dup

Comment 7

[Seth Foley]

Note that the issue still exists: even though the background SHOULD be in the 
top left (thanks to all those who pointed out the error of my spec reading), 
the behavior needs to happen consistently when 'background-attachment: fixed;' 
is present in a style declaration.  At present, I only observe this happening 
when the position is manually set (as in Meyer's spiral example), or when no-
repeat is ALSO in the declaration.

I'll leave it up to more qualified citizens to re-open the bug, but if someone 
else could confirm the inconsistency that'd be a Good Thing.