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

Re: [css3-background] border-radius color transitions using gradients recommended but undefined

From: Zack Weinberg <zweinberg@mozilla.com>
Date: Fri, 29 Jan 2010 15:36:47 -0800
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20100129153647.3bd5e828@mozilla.com>
Andrew Fedoniouk <news@terrainformatica.com> wrote:
> 
> Think about transitions from inset to outset border style.
> Someone may think that one of cases here:
> http://www.terrainformatica.com/w3/border-radius-transition-styles-fig.png
> is a bug.

I can't tell if either of those is an appropriate rendering, 'cos it's
much too blown up.  Inset/outset/groove/ridge only work as visual
effects when the border is fairly thin.  My current thinking is that
treating them the same as color transitions (one gradient per stripe,
of course) should be fine.

N.B. Gecko uses only two stripes per side for groove/ridge and one for
inset/outset.

> We just need to define *reasonable* schema that looks OK in typical
> use cases. That schema should be known as having effective
> implementation as high CPU consumption is a bug too. Tradeoffs as
> usual, sigh.

I may take this back after playing with AGG a bit but right now I don't
see why gradients over arbitrary angles should be dramatically less
efficient than gradients over 90°.  The gradient is defined over the
entire plane, and you clip it to whatever area you need. Sure, clipping
parallel to the Cartesian axes is faster than clipping at arbitrary
lines, but not by so much that it's a fatal problem.

If it *is* for some reason impractical to have the gradient edges be at
arbitrary angles, I think I still want the center of the cone forced to
coincide with the inner corner when the inner corner is sharp.  That's
the bigger problem with your case 10 renderings.

zw
Received on Friday, 29 January 2010 23:37:22 GMT

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