- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Thu, 11 Jul 2013 17:33:40 +0100
- To: www-style@w3.org
- CC: fantasai <fantasai.lists@inkedblade.net>, Simon Fraser <smfr@me.com>
- Message-ID: <51DEDE64.20401@exyr.org>
Le 14/06/2013 16:57, Simon Sapin a écrit : > Hi, > > So, we recently decided that with 'background-attachment: local', the > background positioning area is based on the "inner" scrolled content, > not the "outer" box: > > http://lists.w3.org/Archives/Public/www-style/2013May/0516.html > http://lists.w3.org/Archives/Public/www-style/2013May/0783.html > > What about the background *painting* area? I think it should be the > same. Specifically: > > > When 'background-attachment' is 'local' for a given background layer: Please find attached another test case. The interesting aspects of this test are: * Some scrolling due to 'overflow' on an element (not the viewport) * background-attachment: local * background-clip: content-box * Non-zero padding * Non-zero, semi-transparent border * border-radius bigger than border + padding, so that the curve’s center is within the content area My proposal has two parts, that benefit from being discussed separately. > 1. Both the [positioning and] painting area are based on the scrolled > content. (The difference between padding-box and border-box includes any > non-overlay scrollbars in addition to borders.) We recently decided that for the positioning area. I think the painting area should be the same. Currently, only Safari 6 does this. IE 10, Opera 12 (Presto), Chrome 28 and Epiphany 3.8 (WebKitGTK) all have a painting area that does not scroll: the parts of the background not visible compared to 'background-clip: padding-box' are always visible on all sides whatever the scrolling position. (I’m a bit surprised to see WebKit-based browsers behave differently on something that I did not suspect was WebKit-port-specific, but here it is.) > 2. Values of 'overflow' other than 'visible' also affect the > background layer: the background layer is only visible at the > intersection of the painting area and the "outer" padding area. > > Note: This means that 'background-clip: border-box' is > indistinguishable from 'padding-box'. Now, this is a bit more controversial. It is *possible* to draw 'background-attachment: local' images below the border, but I don’t think it makes sense. If a background image is attached to (scrolls with) the content it’s almost part of the content, and it makes sense IMO that it would be clipped because of the 'overflow' property like the content. In the test case above, the "effective" painting area would be the intersection of a rectangle that scrolls (the one defined by 'background-clip') and one that doesn’t be can have rounded corners (defined by 'overflow'). Cheers, -- Simon Sapin
Attachments
- text/html attachment: background-attachment-local-painting-area-test.html
Received on Thursday, 11 July 2013 16:33:56 UTC