- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 28 Jul 2009 15:23:45 -0500
- To: David Hyatt <hyatt@apple.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org list" <www-style@w3.org>
On Tue, Jul 28, 2009 at 3:01 PM, David Hyatt<hyatt@apple.com> wrote: > On Jul 28, 2009, at 12:17 PM, Brad Kemper wrote: > >> >> On Jul 23, 2009, at 2:32 PM, David Hyatt wrote: >> >>> On Jul 23, 2009, at 3:08 PM, fantasai wrote: >>> >>>> Tab Atkins Jr. wrote: >>>>> >>>>>> (2) The ability to specify bounding-box coverage for backgrounds. >>>>>> - My proposal here is to scrap this feature. >>>>>> - I do not see a use case for placing a background into the >>>>>> bounding >>>>>> box. That just seems like it would give unusual results for both >>>>>> inlines >>>>>> and columns. Columns broken across pages would be even stranger. >>>>> >>>>> I definitely see the use for this ability, but it's nothing that can't >>>>> be done by putting a background on a container element instead. I'd >>>> >>>> Putting a background on the container element would get you a very >>>> different >>>> effect. >>>> >>>> The bounding-box effect is similar to the tables example here: >>>> http://fantasai.inkedblade.net/style/discuss/table-backgrounds/edge.gif >>>> Imagine we just have the first row, and each box is a column rather than >>>> a table cell. >>>> Here's the concept rendering for that image: >>>> >>>> http://fantasai.inkedblade.net/style/discuss/table-backgrounds/edge-d.gif >>>> >>> >>> Yeah, that's not a particularly compelling use case to me. The >>> background broken up by spacing between the columns just looks weird to >>> me... the effect would be prettier if the background had just been on the >>> container and didn't just vanish between the columns. >> >> A horizontal gradient might be a little more compelling as a use case, if >> the gradient is meant to align with a non-broken box above or below it. The >> effect in fantasai's example might also look less weird if there was another >> background image (such as a ghosted version) on the whole container which it >> aligned with. >> >> But in general, I share David Hyatt's concern that the advantages of >> having two properties may not outweigh the extra complexity. A single >> property would be simpler and more intuitive in use. >> > > Another way to achieve this effect would be by making a version of > background-attachment: fixed that works relative to ancestor objects other > than the viewport. To me the concept of children acting as "portholes" > through which you are viewing some container's background is much more like > background-attachment: fixed than like some brand new property. > >>>> What bounding-box does is draw a rectangle that includes all pieces of >>>> the element--without moving those pieces around--and then clips out the >>>> parts of the background that are needed to inside the element's boxes. >>>> >>>> You can see some interesting effects with gradients. See >>>> http://lists.w3.org/Archives/Public/www-style/2009Apr/0131.html >>>> >>> >>> Yeah, I know what it does. I'm just arguing that it's not particularly >>> useful (and would look especially funny with inlines). >> >> I wonder if "bounding-box" can be a value for "background-clip", where it >> would act the same as "border-box", except in cases involving broken boxes >> and "box-break: each-box"? I haven't put a lot of thought into this idea >> yet, but it seems like it would work, be simpler than the current draft, and >> satisfy most or all use cases. > > Or something like: > > background-attachment: relative(<ancestor-id>); > > Yet another idea would be to have a property that established what object > fixed positioned backgrounds inside the container are fixed to: > > background-fixed-container: viewport | self Ah, that feels much more natural. I prefer the latter - in general, I don't like anything that would require explicitly targetting another element, as it either requires a full selector (sort of complex) or something simple like an id (doesn't extend well). And, of course, even within a container with background-fixed-container:self, a descendant can still set background-fixed-container:viewport on themselves if they want a 'normal' fixed background just for themselves again. ~TJ
Received on Tuesday, 28 July 2009 20:24:41 UTC