W3C home > Mailing lists > Public > www-style@w3.org > July 2009

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 28 Jul 2009 15:23:45 -0500
Message-ID: <dd0fbad0907281323g2ed07acbv6233df130086c886@mail.gmail.com>
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.

Received on Tuesday, 28 July 2009 20:24:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC