[CSS2.1] Background boundaries and attachment

Defining "background-attachment: scroll"
    This part taken mostly from

  From http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html :
   | If a background image is specified, this property specifies
   | whether it is fixed with regard to the viewport ('fixed')
   | or scrolls along with the containing block ('scroll').
   | Note that there is only one viewport per view. If an element
   | has a scrolling mechanism (see 'overflow'), a 'fixed'
   | background doesn't move with the element, and a 'scroll'
   | background doesn't move with the scrolling mechanism.

I think the behavior specified here for 'scroll' is counter-
intuitive. As an author, I would expect the background to scroll
with the element's content just like it does for the <body>.
Indeed this is how several browsers have implemented it. [1]

As a user, I find backgrounds fixed to the content easier to
read, and while having text scroll over an unmoving background
looks cool, it is somewhat distracting. If CSS dictates that
"background-attachment: scroll" no longer scrolls the background
with the text [2], I shall be therefore be somewhat annoyed. (At
the browser manufacturers, most likely.)

I propose that 'scroll' be defined to attach the background
and the content so that they scroll together and that, if
needed, a new keyword 'attached' be defined to attach the
background to the element's box as CSS2.1 currently specifies
for 'scroll'.

The main counter argument seems to be that the behavior of the
background underneath the element's border becomes awkward to
define. [3]

Well, what if the background didn't get painted underneath the
border--what if it was clipped to the padding edge?

Defining the Background Clip Area

Aside from a single inconsistency, the original CSS2 wording
specifies that the background is clipped to the padding box
and therefore does not extend to the border area. [4]

The CSS2 Errata and, hence, the CSS2.1 draft turn the spec
around, considering the area under the border as part of the
background area.

But the new definition results in buggy-looking rendering
and a less-consistent model:

   - Because the positioning box and the clip box are not the
     same, an untiled large image "bleeds" messily through the
     border. Illustration:
        (Part C)

   - CSS3's background-size stretches the background to the
     padding edge, but the background color by default continues
     through the border, splitting the *viewer's* perception of
     the background into two unmatched layers.

   - Specifying the boundaries of backgrounds on border-collapse
     tables needs to be special-cased.

   - Constraining the background to the padding area would allow
     CSS to define "background-attachment: scroll" more intuitively.

Conclusion of Logic:

   By locking the proposed clarifications of "background-attachment:
   scroll" and the background's boundaries together, we get a
   background model that is both more consistent and more intuitive
   than the one drafted in CSS2.1.

   Whether these changes can be made, however, depends on the state
   of current implementations as we don't want to break backward
   compatibility in CSS2.1.

Current State of Implementations

   1. As explained in [1] and [2], the current state of implementations
      favors defining "background-attachement: scroll" as proposed

   2. As explained in [5], the current implementations' background
      boundaries are inconsistent with each other and, except for
      Mozilla, inconsistent with themselves.

Conclusion of Testing:

   There doesn't appear to be any significant backwards-compatibility
   problem for constraining the background to the padding box or for
   defining "background-attachment: scroll" to scroll the background
   with the content.

Summary of Argument

   - The behavior of "scroll" would be most intuitive if the background
     scrolled with the content, as it's called "scroll" and as is how the
     setting behaves when specified for the main canvas.

   - Text content is easier to read if the background scrolls with the
     content instead of remaining fixed to the element's position.

   - If CSS3 is to introduce a third value for "background-attachment" to
     make it possible to specify either of the interpretations of
     "scroll", it can just as easily introduce a new keyword (such as
     'attached') for attaching the background to the element position as
     for attaching the background to the element's content.

   - The main problem with having the background scroll with the content
     is figuring out what to do with the background underneath the
     borders. This problem can be avoided by keeping the background
     within the padding box.

   - Keeping the background within the padding box eliminates the
     "bleeding" untiled image problem.

   - Keeping the background within the padding box prevents the image/
     color background boundary dichotomy.

   - Keeping the background within the padding box makes it easier to
     have the background scroll with the content.

   - The current state of implementations does not seem to be preventing
     this model from becoming official.


[1] Testcase:

      With "background-attachment: scroll", these browsers scroll
      the background with the content:
        Mozilla (& Netscape et al.) *
        IE Win
      These follow the CSS2.1 draft's wording:
        Opera 7.0

     * Although Mozilla actually does both at once (See Ian's test case:
       http://www.hixie.ch/tests/adhoc/css/background/block/002.html )
       transparent background images are rare enough that in almost
       all cases, the perception is that it scrolls the background
       with the content like IE Win.

[2] In CSS1, 'scroll' means that the background "scrolls along
      with the content"; CSS2 changes this to "scrolls along with
      the document". A very high percentage of the browser market
      share is consistent with CSS1's wording, so the expectations
      of both authors and users likely favor scrolling along with
      the content.

[3]  Ian Hickson wrote:
       | The working group discussed this at length.
       | http://www.hixie.ch/tests/adhoc/css/background/block/001.html
       | What would you say should happen under the borders?

       -- http://lists.w3.org/Archives/Public/www-style/2003Mar/0008.html

[4]  fantasai wrote:
       | The CSS2 spec, in four other places, refers to the
       | behavior specified in 14.2, where 'background' is defined.
       | Only in Section 8.5.3 does it extend 'background' to the
       | border area.
       | 14.2 - In defining "background", the spec writes that it
       |        gets painted in the content and padding areas.
       |        Borders styles are mentioned in a separate sentence
       |        dealing with border properties.
       | 14.2 def 'background-image' - The spec writes that tiling
       |        only covers content and padding areas.
       | 14.2 def 'background-attachment' - The spec writes that a
       |        a background image is only visible within the
       |        padding and content areas.
       | 8.1 - The spec states that the backgrounds of the padding
       |        and content areas are specified by the background
       |        properties, but that the background of the border
       |        area is specified by the border properties. (This
       |        can make sense because content that overflows the
       |        border is rendered on top of it, not underneath it.)
       | 17.5.1 - The image depicting a table with background-
       |        colored, double-bordered cells does not show any of
       |        the background between the two stripes of border.
       | This leads me to believe that whoever wrote backgrounds
       | into the spec expected them to render in the content and
       | padding areas, but not the border area.

       -- http://lists.w3.org/Archives/Public/www-style/2001Jul/0189.html

[5] Background boundary browser testing results and comments:

     Microsoft Internet Explorer:
       They render 0% 0% as upper left corner of the padding edge
       and tile/color only the padding box EXCEPT when
            a) the element is not a table
        and b) the element has both auto width and auto height
       in which case they render 0% 0% as the upper left corner of
       the *border* box and tile/color the border box.

     Opera, Konqueror, and Safari:
       They position AND tile the background image within the
       padding box, but fill the entire border box with the
       background color.

       Previous versions of Mozilla behaved like Opera and Safari.
       Recent ones position the background image within the padding
       box but tile it into the border area.

       Current implementations are inconsistent. Choosing to constrain
       both background color and image tiling to the padding box should
       cause no more problems than expanding them to the border box.



Received on Saturday, 11 October 2003 06:58:11 UTC