<Glazblog/>

(this article uses SVG and MathML, Safari has issues with it because of HTML mimetype ; please prefer Chrome or Firefox)

Let's take a given square box. Height and width are the same. We want to apply a red-to-black background at let's say alpha degrees and through the center C (50%, 50%) of the box. The W3C gradients draft says we find the start and end points of the gradient that way:

Let's suppose the size of the box is 100%*100%. In that case, finding the coordinates of the end point (for instance) is easy:

• α is our user-chosen angle
• let β be the angle between the horizontal and the line between the C and D; we have
  ${\displaystyle tan\beta =\frac{C_y-D_y}{D_x-C_x}}$
• the distance between C and D is of course ${\displaystyle l=\sqrt{{(c_y-d_y)}^2+{(c_x-d_x)}^2}}$
• the distance between C and the end point is then ${\displaystyle l\text{'}=l\cdot cos(\beta -\alpha )}$
• and the coordinates of our end point are then ${\displaystyle (C_x+l\text{'}cos\left(\alpha \right),C_y-l\text{'}sin\left(\alpha \right))}$

Of course, Gecko-based gradients use a start point and an angle to define a linear gradient while WebKit-based gradients use a start point and an end point.

But according to the above, we will get different absolute coordinates for our start and end points depending on the box's size even if the angle remains the same.

The above means that it's not possible, in the general case, to derive a -webkit-gradient(linear, ...) from a -moz-linear-gradient(...) - and vice-versa - without having access to the element's size.

Conclusion: sorry, BlueGriffon will not output WebKit-based gradients outside of the trivial cases, it's just not possible.