W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: [css3-backgrounds] Should a non-zero border-radius create a new stacking context ?

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sat, 20 Nov 2010 12:38:04 -0800
Message-Id: <68018D9A-23E5-4CEC-81D9-8B30E53D8FC4@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Sylvain Galineau <sylvaing@microsoft.com>
I'm more in the mode of trying to understand the problem than in arguing against the solution. 

If Firefox is doing it right, then it is not insurmountable. If we are talking about a gigantic extra mess of code to deal with this, then I am not unsympathetic. Is that the case, or are we talking about making things a little easier in order to meet deadlines? Did Mozilla have the same level of difficulty? Is this difficulty what is holding back Safari, Chrome, and Opera? If any of them can do the corner clipping soon, then we will have two implementations. 

I'm not an implementor, but I imagine that if you already have code to clip the edges based on remembering where the parent edges are, that it wouldn't be that much more to also track the location and sizes of corner radii. But I'll listen to your answer and other implementers to try to understand how big the problem is. 

Also, I am a bit concerned that this stacking context change would change existing pages, in possibly unfixable ways, as border-radius is already widely used, with and without prefixes.  

On Nov 20, 2010, at 11:29 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote:

> Well, I don't see a good reason for the current behavior either; so what ? Just as I don't see a good reason - from an authoring standpoint - for opacity changing z-ordering, especially when applied on :hover as it often is. That opacity < 1 does create a new stacking context doesn't only make implementation a lot easier, ease of implementation is the only reason given by CSS3 Color for this behavior. I will grant that applying opacity - or arbitrary transforms - without creating a new stacking context is harder than clipping to the proper geometry but ease of implementation clearly is a reason to make certain features change z-ordering. While the existence of a precedent is not sufficient to prove that this particular feature should do the same, I don't see why implementation considerations should not apply in this case and any number of others. Especially when the CR stage is reached and most browsers fail the clipping requirements as specified.
> The argument I think you're making is that this would result in a rather odd overflow discontinuity between border-radius:0 and > 0. But that's no different that what you have between opacity:1 and < 1 or transform:none and transform:scale(1). I honestly don't know why the discontinuity is OK in these cases but not for border-radius. If you've explained why I'm still missing it.
> From: Brad Kemper [brad.kemper@gmail.com]
> Sent: Saturday, November 20, 2010 10:10 AM
> To: Sylvain Galineau
> Cc: www-style@w3.org
> Subject: Re: [css3-backgrounds] Should a non-zero border-radius create a new stacking context ?
> On Nov 20, 2010, at 8:25 AM, Sylvain Galineau wrote:
>> I never said it shouldn't clip to the inner corner curve. That's not at all the point. If the element with border-radius in my original testcase created a new stacking context then the blue box moves below the green one (as it also will if you give the parent opacity < 1, or a transform). It still must clip to the parent's curve within that parent's stacking context. 
>> So no one is questioning whether the element should clip to the border curve.
> OK, I thought that was part of what you were questioning, because your statement "It's not  clear to me why this is useful or desirable" seemed to be questioning something that was already in the spec. And the spec has no special implications for stacking contexts that I can see.
>> The suggestion is that the non-zero radius would result in a different z-order for the blue box.
> I see no reason why it would or should.
> On Nov 20, 2010, at 8:42 AM, fantasai wrote:
>> What Brad is saying is that the problem you're running into wrt stacking
>> contexts has nothing to do with whether the border is curved or square.
>> (Give the element some negative margins, and you'll get the same behavior
>> with a square border.)
>> Having non-zero border radius affect the z-order doesn't follow from the
>> problem you describe: it's not creating any new or interesting stacking
>> effects. It's just changing the shape of the clip mask.
> Right.
Received on Saturday, 20 November 2010 20:39:15 UTC

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