Re: [CSS3 Backgrounds and Borders] Proposal for combining border-break and background-break

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

dave
(hyatt@apple.com)

Received on Tuesday, 28 July 2009 20:01:50 UTC