- From: fantasai <fantasai@escape.com>
- Date: Sat, 11 Oct 2003 06:58:20 -0400
- To: www-style@w3.org
Defining "background-attachment: scroll" ---------------------------------------- This part taken mostly from http://lists.w3.org/Archives/Public/www-style/2003Mar/0005.html 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: http://lists.w3.org/Archives/Public/www-style/2001Nov/0088.html (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 above. 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: http://fantasai.tripod.com/www-style/2003/background-attachment.html 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 MacIE Safari * 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. Mozilla: 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. Conclusions: 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. ======================================================================== ~fantasai
Received on Saturday, 11 October 2003 06:58:11 UTC