- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 13 Jan 2009 08:45:12 -0600
- 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 UTC