Re: [css3-background] box-shadow spread radius and rounded corners

I'm sorry to essentially necro this conversation. I unfortunately was
not able to follow along at the time, and only went back and caught up
with this thread after I read the minutes that just went out.

I absolutely agree that
-- Spread and choke have a long history in the
printing/publishing/graphic design world and are relatively well
defined there
-- Brad has described exactly how those attributes behave (in e.g.
Photoshop or Illustrator)
-- We obviously shouldn't attempt to redefine the terms for CSS
-- Adding more numerical options to the box-shadow property would be
very unfortunate
-- The use cases for spread definitely exist. (Brad's example of the
long thin rectangle + spread is perfect for explaining why a scaling
would fail as a spread implementation)
-- Neither shadow spread nor shadow scaling are capable of describing
the other, though in many cases they will be close

All that said, the optional argument to box-shadow should be a scaling
factor and not a spread one.

First, it's important to note that spread came to the printing process
first as a technique to deal with empty gaps due to inevitable color
misalignment, and was only _adapted_ to produce drop shadows. It was
essentially a hack to add shadows that became standard due to its
widespread use.

Second, (I think) box-shadow should be defined from the opposite
direction: as a pseudo-physical effect, a shadow cast by an element.
An obvious need is to be able to add a sense of depth, not just
through the offset value, but through some kind of perspective scaling
effect (whether from a close-up light source or a distant
shadow-receiving surface). Scaling allows the totally valid use case
of retaining a shape's shape (including rounded or sharp corners) even
for shadows that are extremely "close" or "far".

Spread is instead an entirely graphic effect, originally defined by
the needs of print, but with definite use cases today. I think the key
is in these cases, because outside of simulating shadows, it is
primarily used to add an offset shape (or path), to add a second
border (which was mentioned as one natural outcome from where the spec
is going right now), or to add a pseudo inner or outer glow.

Spread is used to make bigger shadows _or_ it is used to make
something not very shadow-like at all; the rasterized results can look
similar (hence the historical use of spread to create drop shadows),
but the motivations are totally different.

So, I propose having box-shadow mimic our intuitive sense of a shadow
by having a scale parameter, but also adding a new background
property, something like "box-spread". Obviously another new property
isn't great, especially since the possible rendered results are not
entirely disjoint from box-shadow, but the use cases for both are
there and conceptually a split is much cleaner. Conveniently, the
language for the property is already mostly written, so that's also a
plus =)

Brendan

On Wed, May 12, 2010 at 11:14 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> Here is a comparison of how the fake offset actually looks a little better
> when it is for inner shadows (also applies to negative shadows). So if that
> is also more performant, then, great.
>
> On May 12, 2010, at 1:22 AM, Brad Kemper wrote:
>
> Anyway, I've posted a rendering of how spread is expected to work, for it's
> "normal" interpretation:
> http://www.bradclicks.com/cssplay/spread-sample.png
> I think that if a radius was calculated based on where the straight parts
> ended (offset directly from where they were before the spread) then that
> should be fine too. I started to do a rendering of that too, but it was
> almost identical on the big gray shape, so I don't think anyone would
> complain (especially since there will typically be blur too). For the inner
> shadow spread or for negative spread (aka "choke"), it might even look
> better, smoothing out the weird corner joins that can happen as in this
> example (upper left corner), when one dimension of the ellipse loses its
> roundness before the other.
>
>
> On Apr 29, 2010, at 5:00 PM, Alex Meiburg wrote:
>
> This makes it even worse, I feel. It's not an ellipse or a circle. It's
> something else, construed only from unusual rules. The only reason people
> haven't be arguing about blurs (I think someone already said this) is
> because they're largely up to the user agent. That doesn't mean they won't
> suffer from the same problems. I think anything that's decided for the
> spread should immediately be applied to the shadow as well, just because it
> isn't doesn't mean the spread should do what the shadow does.
> ~6 out of 5 statisticians say that the number of statistics that either make
> no sense or use ridiculous timescales at all has dropped over 164% in the
> last 5.62474396842 years.
>
> On Wed, Apr 28, 2010 at 8:16 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>
>> On Apr 28, 2010, at 6:40 PM, Alex Meiburg wrote:
>>
>> > Then, the shadow would add something like 5px to each radius
>>
>> No, it just follows the radius in the same way that it follows the
>> straight parts. So does the blur, for that matter. For instance, take a look
>> at this, where you can see the difference between a sharp corner and a
>> heavily blurred one (no spread in either):
>>
>> http://www.bradclicks.com/cssplay/Blur-vs-Corner.html
>>
>> Now look at this image, where the white has been changed to yellow, so
>> that you can clearly see the extent of the blurred area:
>>
>> http://www.bradclicks.com/cssplay/Blur-vs-Corner_result.png
>>
>> This shows that the blur area has extended the boundary of the shadow out
>> 25px, and created a shape with a 50px corner radius! Yet no one is
>> complaining about how it increases the radius from 0 to 50px. This is the
>> same sort of thing that spread does, but with a solid colored brush instead
>> of a fuzzy-edged brush. In fact it is what 'border' does too, but no one
>> complains about it having inner radii that are different from the outer
>> radii. Border is more like inner shadow, in that the radius of the inner
>> part gets smaller than the specified part, but that's just because the spec
>> says to apply the radius to the outside of the border instead of the inside.
>> It could just as easily have gone the other way.
>
>
>

Received on Sunday, 16 May 2010 10:52:36 UTC