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.
I filed this as http://jira.openlaszlo.org/jira/browse/LPP-9498. It's
not currently a requirement, at least until we add HTML5 box-shadow
parsing support (filed as
http://jira.openlaszlo.org/jira/browse/LPP-9499)...
Finally, CSS has a flag, 'inset'.
I _really_ don't want to add another attribute just for this...
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.
Yes, you've convinced me. I'll change and send again for review.
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.
According to my tests, both '-0 == 0' and '-0 === 0' return true :( but
I don't think it really matters.
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-shadow
I was assuming a spread of 0. If we add spread support.
On 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
