On 11/1/10 1:43 PM, Max Carlson wrote:
Nope, sorry. We need to overload shadowblurradius, not shadowdistance. It just doesn't work in practice to use distance, because it forces the shadow to be offset according to the angle...So, I stand by my original change! Here's an updated testcase so you see what I mean: <canvas> <view x="10" y="10" shadowblurradius="-100" shadowdistance="0" width="100" height="100" bgcolor="white" oninit="this.animate('shadowblurradius', 100, 10000)"/> </canvas> On 10/29/10 7:33 PM, P T Withington wrote:Shadow angle + distance are polar coordinates that are equivalent to the cartesian coordinates x-offset + y-offset. That's the transform we're making. x = d * cos(a), y = d * sin(a), right? Blur radius is the radius of the blur around the edge of the shadow. The shadow is at 100% at edge-radius and 0% at edge+radius. This is the same for us an CSS. CSS has an additional property 'spread distance', which is how much bigger/smaller the shadow is than the original box. That is, this value is added to the coordinates of the edge of the shadow box, making it correspondingly larger (or smaller for a negative value) than the original box. We have no equivalent parameter for this, that I can see. Finally, CSS has a flag, 'inset'. Since blur radius is the same in both models, it seems odd to me to use the sign of that to encode 'inset'. On the other hand, a negative distance in polar coordinates makes no sense, so it seemed reasonable to me for that to be the encoding for 'inset'. Especially where a distance of 0 is "no shadow", _unless_ you apply a blur, in which case you will see only the outside half of the blur (which I guess we call a glow). In fact, if you consider animating attributes, it makes a lot more sense to use the sign of distance to mean inset because by animating distance from from a positive to negative value, you would make the shadow go smoothly from giving an outdented appearance, through no shadow, to an indented appearance. Whereas animating the blur radius from positive to negative would make the shadow go from blurred to sharp, then suddenly jump to an inset shadow, that slowly gets blurred. I'd still like to see a separate flag, so you don't have to use `-0` to mean an 'inset glow', but I guess we might as well make use of the existence of -0. On 2010-10-29, at 19:48, Max Carlson wrote:I thought we agreed on shadowblurradius. Otherwise, you can't set the start of the shadow distinctly from where it ends: blurradius - distance...I think you are confusing distance here with the CSS 'spread' value, which we don't have. And that is what that value is for, to make the shadow a different size than the box is is created from At least that's what I take from the reference Fred sent: http://www.w3.org/TR/css3-background/#the-box-shadowOn Oct 29, 2010, at 4:38 PM, P T Withington wrote:I thought we agreed that we were going to use negative shadowdistance values to mean 'inset'? On 2010-10-29, at 19:34, Max Carlson wrote:Change maxcarlson-20101029-Ujt by [email protected] on 2010-10-29 16:16:27 PDT in /Users/maxcarlson/openlaszlo/trunk2 for http://svn.openlaszlo.org/openlaszlo/trunk Summary: Add support for inner shadows to swf10 and DHTML Bugs Fixed: LPP-9466 - inner glow/shadow Technical Reviewer: ptw QA Reviewer: ffeng Overview: Setting a negative shadowblurradius value will cause the LzSprite.js - Set 'inset' property to work for negative shadowblurradius values. Details: LzSprite.as - Set 'inner' property to work for negative shadowblurradius values. Add typing, remove unneeded this. LaszloView - Snap values that are close to 0 to 0, update documentation Tests: See LPP-9466 for a testcase. Files: M WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js M WEB-INF/lps/lfc/kernel/swf9/LzSprite.as M WEB-INF/lps/lfc/views/LaszloView.lzs Changeset: http://svn.openlaszlo.org/openlaszlo/patches/maxcarlson-20101029-Ujt.tar
<<attachment: FirefoxScreenSnapz001.png>>
