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

Re: [css3-background] does border-radius round the border-image ?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 13 Jan 2009 08:45:12 -0600
Message-ID: <dd0fbad0901130645l4894e6ecycd49ad8309d4dc86@mail.gmail.com>
To: "Brad Kemper" <brad.kemper@gmail.com>
Cc: "Faruk Ateš" <faruk@apple.com>, "CSS mailiing list W3C" <www-style@w3.org>
On Mon, Jan 12, 2009 at 9:45 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>
> On Jan 12, 2009, at 3:45 PM, Faruk Ateš wrote:
>
>> On Jan 12, 2009, at 1:31 PM, Brad Kemper wrote:
>>>>
>>>> Perhaps an expansion to the spec here would be useful, as I can see
>>>> reason for both scenarios to co-exist rather than one being dropped in favor
>>>> of the other.
>>>
>>> Can you give an example of where you would see a reason for the
>>> background to continue under the border when background-clip: padding-edge
>>> is used?
>>
>>
>> Any scenario where your background is tailored more directly to the (flow
>> of the) text or content within the box, but you explicitly have padding on
>> it for legibility purposes or something alike.
>
> I'm sorry, but I don't see how having the background to continue under the
> curved part of the border (instead of stopping at he inner edge, as it does
> with the rest of the border) will aid in legibility. There is no more or
> less padding either way. The only place you would see something different is
> through the gaps in the lines (or as color fringing on the edge of the
> curve, or when the line is removed via border-images and there is either the
> same or more background showing). Are you saying that those gaps between the
> dashes, dots, and double lines are going to add to the legibility near the
> corners? That seems like quite a stretch.
>
>> I think the real challenge here is figuring out how to handle the new
>> paradigm of having visually rounded corners / edges to a box, but still a
>> rectangular "real" box that represents that content. Whether one
>> implementation's scenario is more likely or more common than the other is
>> less relevant in my opinion, as that issue persists in either case. It's
>> just an extension of that problem, really.
>
> The implementors and everyone else have limited time. They have usually no
> interest in complicating the language and adding to their implementation
> burdens to add switches that no one will ever use. And in this case, the
> author can already be clear with background-clip: padding-edge that he wants
> the background to stop at the inner edge of the border. Adding a new value,
> such as "background-clip:inner-border" could make the intent more clear, I
> suppose, but is unnecessary since the author will almost never want the
> background shape to kind-of-but-not-quite follow the border shape at the
> corners, as it does in WebKit.

I apologize for not having anything better to say, but this is really
a simple issue with little to argue about.  I agree with Brad that
"background-clip:padding-box" should clip to the inner border edge,
for exactly the reasons he cites.  There's simply no good reason to do
otherwise.

~TJ
Received on Tuesday, 13 January 2009 14:45:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT