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

Re: [CSS3, Backgrounds and Borders Module] some questions about border-radius

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 24 Aug 2009 10:31:25 -0700
Message-ID: <4A92CE6D.8040505@terrainformatica.com>
To: fantasai <fantasai.lists@inkedblade.net>
CC: Zack Weinberg <zweinberg@mozilla.com>, W3C Emailing list for WWW Style <www-style@w3.org>
fantasai wrote:
> Andrew Fedoniouk wrote:
>> Zack Weinberg wrote:
>>> Andrew Fedoniouk <news@terrainformatica.com> wrote:
>>>>> I don't think example 9 is rendered right -- I would expect the
>>>>> color gradient to extend as far as "case 3" specifies.  But when
>>>>> the inner corner is not sharp (cases 1-8), cases 1-3 are
>>>>> indistinguishable, because the inner and outer curves start and end
>>>>> on the same lines.  So you don't need to worry about that.
>>>> but this : "color gradient to extend as far as "case 3" specifies"
>>>> will break current spec. that says that transition is limited by
>>>> quarter-ellipses of rounded-corners (as far as I understand wording
>>>> there).
>>>
>>> To reiterate: the spec speaks only of the INNER curve.  Your cases 1
>>> and 2 are bounding the transition based on the OUTER curve.  That's
>>> clearly wrong.
>>
>> And now I have lost any idea what all this means. Anyway...
>>
>> Here is what I've got so far:
>>
>> There are three possible cases of the area where gradient transition 
>> may happen. They are presented on this figure:
>>
>> http://www.terrainformatica.com/w3/border-radius-transition-areas-fig.png 
>>
>>
>> Here is a screenshot where the renderer (latest Sciter build) uses
>> variant (B) of transition areas:
>>
>> http://www.terrainformatica.com/w3/round-corners-sciter-b.png
>>
>> Here is a screenshot where the renderer uses variant (A):
>>
>> http://www.terrainformatica.com/w3/round-corners-sciter.png
>>
>> Variant (C) (gradient area is limited by rectangle-intersection of 
>> two borders) will not work as such rectangle can be outside of the 
>> curve completely - no area to do transition at all.
>
> Thank you for the great illustrations Andrew, I understand better
> what the argument is here.
>
> The intention of the spec is to limit transitions to area B.
> This is because the conjunction of different styles may need
> the full area of B. If you're just joining two solid borders
> and want to do a color transition, you wouldn't want to use
> the full area of B, you'd want to draw lines through the border
> from the ends of the inner curve to the ends of the outer curve.
> In the case where the inner curve is a sharp corner, you draw
> angled lines through the border from the point to the ends of
> the curve on the outer edge. Such a transition is still contained
> within the region dictated by the spec, but by fanning out from
> the inner corner, it looks much more reasonable. If you can make
> an illustration of that, I'll be happy to put it in the spec as
> an example. It's a little beyond my (very limited) graphical
> abilities.
Will try to do such illustration as I understand it.

But try to imagine (just for fun) that we will decide to spec how
transition from border-top-style: inset and border-left-style: outset should
look like. It is clear that such a transition should be contained in the
area where borders are changing their geometry (width for example).
And this is the case marked as (B) here:
http://www.terrainformatica.com/w3/border-radius-transition-areas-fig.png

So I think we just need to specify that *any* visual transition effects 
shall
be contained in the area that I've mentioned in previous message:

"This area is a union of two rectangles, one with dimensions (Rx,Ry)
and another with dimensions (Bx,By).
Where: Rx,Ry are x and y values of border-radius at that corner and
       Bx,By are widths of borders meeting at that corner.

In other words gradient transition area is limited by the area having
following dimensions: max(Rx,Bx), max(Ry,By)."

--
Andrew Fedoniouk.

http://terrainformatica.com
Received on Monday, 24 August 2009 17:32:06 GMT

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