- From: Zack Weinberg <zweinberg@mozilla.com>
- Date: Fri, 29 Jan 2010 15:36:47 -0800
- To: "www-style@w3.org" <www-style@w3.org>
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 UTC