Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better Box Shadows (CSS)

uglyduck.ca

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Better Box Shadows (CSS)

#41

Post by theandrewbailey »

blegit wrote: post #23
touchpadder wrote: post #20

Are people getting interested in realistic design again? These days everything is flat and boring. Bring back the buttons with reflections!

Are you talking about bringing back skeuomorphism, https://en.m.wikipedia.org/wiki/Skeuomorph or is that too far?

(I'm not who you replied to)

Skeuomorphism brings to mind iOS design from 10 years ago. It wasn't good looking at all. (Granted, it was overblown and in your face.)

I'd like a retro look with subtle 3D cues, like how Windows and MacOS used to look ~20 years ago. Transparency used in some places (like Windows 7) would be welcome.

Re: Better Box Shadows (CSS)

#44

Post by retox »

chipotle_coyote wrote: post #13
Tagbert wrote: post #8

Earlier quoted context omitted.

With so many sites using tiny, gray fonts on light gray backgrounds, this is surprisingly readable.

This complaint is kind of a trope on Hacker News now -- which isn't to say that there aren't still sites using tiny gray fonts on light gray backgrounds, but off the top of my head I can't think of any sites that launched or were redesigned within the last... five or six years now, at least, that still follow that particular trend. Medium, for both better and worse, has led an awful lot of design since it exploded on…

SendGrid's website is entirely unusable without zooming; often the fonts render as less than a pixel wide at normal zoom. Combined with light gray on white color scheme it makes the site a headache to use.

More amusing was the advertised blogpost last time I logged in that said using a dark theme for your email promotions was modern and would attract more interaction.

Re: Better Box Shadows (CSS)

#45

Post by littlestymaar »

numlock86 wrote: post #31
err4nt wrote: post #2

The blur filter is notoriously slow on performance. I find it interesting that the author didn't explore the "spread" parameter of box-shadow at all, I wonder if they realize it exists https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow

> The blur filter is notoriously slow on performance. I am curious: Do you have some numbers? What is this statement based on? Intuitively I'd agree, but on a technical level I am not so sure.

I don't have numbers, but browsers must implement it as a Gaussian blur (because that's what the spec says) which is quite costly.

Re: Better Box Shadows (CSS)

#46

Post by mattkrick »

numlock86 wrote: post #31
err4nt wrote: post #2

The blur filter is notoriously slow on performance. I find it interesting that the author didn't explore the "spread" parameter of box-shadow at all, I wonder if they realize it exists https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow

> The blur filter is notoriously slow on performance. I am curious: Do you have some numbers? What is this statement based on? Intuitively I'd agree, but on a technical level I am not so sure.

We used to blur content behind modals. When the modal animated in, it'd hit single digits fps on a MacBook pro. Ditched it for a more opaque scrim and fps was back at 60.

Re: Better Box Shadows (CSS)

#48

Post by tobr »

mistercow wrote: post #10

Maybe I'm missing some detail, but the blur filter seems pointless. Both box-shadow and blur() are approximations of gaussian blurs. If you apply two gaussian blurs, you're multiplying two gaussian functions in the frequency domain. The product of two gaussian functions is another gaussian function, so the same effect can be accomplished more efficiently with a single gaussian blur. You just need to tweak the shadow…

Clearly it’s an over-engineered solution, and there is no way the end result justifies the use of an expensive blur filter. However, just adjusting the radius and opacity would not produce the exact same effect, since the blur is not just blurring the shadow, but the whole . This means that the background color (transparent) will mix with the shadow color. I’m guessing that’s not even intentional, because it’s a strange effect to seek out - a drop shadow that becomes lighter close to the object that is supposed to be blocking the light.

And even that effect should be possible to approximate with a regular box-shadow, by layering a white shadow on top of a transparent black.

Re: Better Box Shadows (CSS)

#49

Post by tobr »

runxel wrote: post #39
err4nt wrote: post #2

The blur filter is notoriously slow on performance. I find it interesting that the author didn't explore the "spread" parameter of box-shadow at all, I wonder if they realize it exists https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow

Should be the opposite, actually, since the :filter are backed by hardware graphic acceleration.

No, it should not be the opposite. Any optimization or performant implementation you can think of that works for Gaussian blur, also works for box-shadow. It is a Gaussian blur, but with the added restriction that you know you’re always blurring a single-colored rect or rounded rect.

Re: Better Box Shadows (CSS)

#50

Post by mistercow »

tobr wrote: post #48
mistercow wrote: post #10

Maybe I'm missing some detail, but the blur filter seems pointless. Both box-shadow and blur() are approximations of gaussian blurs. If you apply two gaussian blurs, you're multiplying two gaussian functions in the frequency domain. The product of two gaussian functions is another gaussian function, so the same effect can be accomplished more efficiently with a single gaussian blur. You just need to tweak the shadow…

Clearly it’s an over-engineered solution, and there is no way the end result justifies the use of an expensive blur filter. However, just adjusting the radius and opacity would not produce the exact same effect, since the blur is not just blurring the shadow, but the whole . This means that the background color (transparent) will mix with the shadow color. I’m guessing that’s not even intentional, because it’s a stra…

That’s a good point. I didn’t think about the mixing of the interior background color. And yeah, I agree that that’s a weird property, and would guess that depending on how you configure the rest of the parameters, could lead to very strange results.

Actually, I was thinking about this as I went to sleep last night, and I think I was wrong about the opacity being a factor. The convolution kernels will be normalized, which means that their composition will also be normalized. That means that the only parameter to adjust is the radius.

As a side note, it’s kind of interesting that the first property “still a Gaussian blur” is easiest to see in the frequency domain as a product, while the second property “still integrates to 1” is easier to see when thinking in the spatial domain as a convolution.

And one last tidbit my brain wandered to: you might notice that the product of two Gaussian functions results in a new Gaussian narrower than the originals. Yet the blur radius in the spatial domain is obviously wider. This is because the Fourier transform of a wider Gaussian is a narrower Gaussian and vice versa, and that is a special case of the uncertainty principle.

God I miss image processing.

Post reply on HN