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

It's not an issue of feasibility; it's not a hard problem to solve in the absolute sense.

Accept for the sake of the following two paragraphs that this scenario is a testcase, not a use-case; by which I mean a) it would be very rare in practice b) those authors who want to achieve the effect could and would use patterns that don't rely on on overflow/z-index clipping combos.

If that is true then we're asking implementations to add extra code and carry extra information for all children of elements with border-radius just so they can get this kind of clipping right in test suites and other contrived 'acid' tests. One can certainly argue this kind of trade-off is not new with CSS, especially when it comes to overflow. But that's not a good-enough reason imo to say that new features should carry and extend this complexity further; and penalize the runtime performance of every page that uses the feature. Even if it's a small hit.

Getting children to clip properly according to a rectangular mask is easy enough and everyone is already doing it; once parent and child have border-radii, getting the right geometry - anywhere from a rectangle with one rounded corner to a circle, an ellipse or some almond-shape object - is doable but a bit more work if you can't rely on direct composition. I don't mind the work and runtime penalty if it's generally and genuinely useful. I'm not sure that's the case here so I'm inclined to consider alternatives and ask for feedback.

As for changing existing pages in unfixable ways, that was my concern as well. But if it was a real issue I would expect many bugs and blog posts telling authors to avoid using opacity or transforms because they mess up z-ordering in ways too ghastly to work around. If I'm looking in all the wrong places for that feedback - I am not an author, after all - then do enlighten me. I just note that opacity is used all over the place, including on :hover on elements with border-radii.

I do not claim this is what is holding back other implementations. But as we're entering CR, it is relevant to note that only one browser achieves this. I do assume simplifying the implementation work does help. And while it is necessary to have two implementations for the spec to exit CR, that is not sufficient for authors. We want all implementations to achieve the same result.

As you point out, this feature has been around for quite some time. Feature requirements that still don't work right after this much time and use deserve some honest scrutiny.

________________________________
From: Brad Kemper [brad.kemper@gmail.com]
Sent: Saturday, November 20, 2010 12:38 PM
To: Sylvain Galineau
Cc: www-style@w3.org
Subject: Re: [css3-backgrounds] Should a non-zero border-radius create a new stacking context ?

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<mailto: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<mailto:brad.kemper@gmail.com>]
Sent: Saturday, November 20, 2010 10:10 AM
To: Sylvain Galineau
Cc: <mailto:www-style@w3.org> www-style@w3.org<mailto: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.