Better Box Shadows (CSS) | Hacker News Reader

Better Box Shadows (CSS)

uglyduck.ca

143 pointsbradley_taunt59 comments

A few people have mentioned that it seems the author didn't realize this is already the 4th parameter in `box-shadow`, so I made a quick demo:

https://codepen.io/gkoberger/pen/rNOommB

You can also apply multiple box-shadow on the same element separated by commas if you want even more control on the shadow.

    box-shadow: 0 18px 16px -15px rgba(0,0,0,0.3), 0 10px 10px -20px rgba(0,0,0,0.8);

So you use a negative spread-radius to make the shadow more narrow than the box. Cool!

The only problem with this (and it is infuriating) is that while Chrome and Firefox render box positive box-shadow values identically, they differ substantially with negative values. As a result, to get matching shadows you will need to use browser-specific shadows.

Thanks for sharing! I am aware of the spread property and using it as you have in the demo works well. The main reason I use a separate element most times is for when I want the shadow to render at ~60-70% the width of its parent. Not sure there is a way to do that with box-shadow directly, unless I've overlooked something?

If you were aware of this option, you should've mentioned it in the intro of your post, before getting into a solution for a specific case not covered by it.

You're absolutely correct. Once I get a little time I will update the post with those details (and be sure to link you credit for giving me a heads up)

Credit gkoberger, not me.

I avoid using this 4th param "spread", as the effect varies wildly between browsers. Safari and Chrome, the two most popular browsers on mobile, are also the two most different, with Firefox and IE/Edge (pre-Chromium) landing in between.

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.

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.

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.

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 opacity and blur radius.

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 <div>. 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.

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.

Layered shadow builder (without blur filter) https://brumm.af/shadows

Pretty cool stuff

Very cool!

Pure CSS box shadows without extra markup can be achieved with using negative spread (with increased blur to compensate) and multiple shadows. I believe it allows to achieve the exact look the author demonstrates at the end.

What I'd like to see is browser engines converge on identical box shadow rendering. Currently shadows tend to be more pronounced in Firefox relative to WebKit.

>Currently shadows tend to be more pronounced in Firefox relative to WebKit.

yeah, last i looked at this, negative spread was essentially useless for anything but the most subtle tweak because it looked so different in firefox and chrome.

What I would prefer to see is user settings for box shadow rendering, so that the user can configure how much pronounced it is or to disable it entirely, with presets for imitating Firefox and for imitating WebKit.

The problem is that Firefox extends visible shadow past WebKit, too. If you rely on box shadow to match certain area in your design, such discrepancy in rendering could break it.

A little off-topic, but this site is close to unusable.

On desktop, I had to set my browser zoom to 75% for it to be legible at all, at which point a new column on the left appeared. I thought I'd accidentally clicked on a link or something.

Then I tried scrolling with my trackpad and it wouldn't, finally figuring out because my cursor was over the left half of the screen, and only the box inside of the right half of the screen scrolls.

The overall visual look is cool, but the usability is terrible. Ironic that the first words on the home page are:

  Make a good first impression
  Your website might be the first and only interaction with potential customers.
  Don’t screw it up.
  ...overly complex UIs can make for a horrible experience. 
  You need to treat your users with respect and value their time.

Your website is gorgeous.

I disagree. It uses too large fonts, too large boxes, to narrow areas, etc.

And using an inner scrolling area for the content instead of the document scrolling area is very problematic for keyboard users, unless you focus the true scrollable pane on load, and ensure that any time the body becomes the active element, you change it back to the scrollable pane. This is fiddly to get right, and requires JavaScript; I should finish the blog post I started writing on the topic. I made sure we got it as right as possible for Fastmail’s webmail, but I don’t think I’ve ever encountered any other site using an inner scrolling area even trying to get it right.

As it is, keyboard users will have to press Tab seven times before the keyboard navigation keys (arrows, Space, Shift+Space, Page Up, Page Down, Home, End) work.

For this reason, I strongly recommend that websites (as distinct from web apps) avoid placing article content within a new scrolling area. Use the document scroll area.

Yes, I see that too much too, although in this case I just disabled CSS. (In other cases, I sometimes click with the mouse on the area I want to scroll and then use the arrows and page up and page down keys to scroll.)

> For this reason, I strongly recommend that websites (as distinct from web apps) avoid placing article content within a new scrolling area. Use the document scroll area.

I agree with this.

I spent a couple of minutes staring at it, unsure if I liked it or not. I concluded that the retro styling is kinda cool, but they make me expect a text adventure or puzzle. Nice for a change. :)

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 onto the scene, and as far as I know it's always had bigger-than-default body text that's near-black on a pure white background. WordPress's default theme going back at least to 2016 is the same way; ditto for Ghost; ditto for virtually every theme from Squarespace.

Again, I'm sure there are lots of sites still out there like this, but I just don't see them very often. My eyesight isn't top-notch anymore, but the only site that I routinely visit that I have to have set on a higher-than-default zoom to be able to read is (ahem) Hacker News, because it uses tiny black fonts on light gray backgrounds. (Except for the places it uses, uh, tiny gray fonts on light gray backgrounds.)

> the only site that I routinely visit that I have to have set on a higher-than-default zoom to be able to read is (ahem) Hacker News, because it uses tiny black fonts on light gray backgrounds. (Except for the places it uses, uh, tiny gray fonts on light gray backgrounds.)

Your whole comment is spot on, but this is particular funny because I pointed it out to someone the other day and instead of scrolling up to see for himself he just...chose not to believe it. [1]

1. https://news.ycombinator.com/item?id=23201007

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.

Their front page doesn't look that bad to me, but as I poke through other pages, there's definitely a lot of text at "usually reserved for legal disclaimers" font size, isn't there?

I don't use Sendgrid, so I don't know what their admin panel is like. I recall that some of the worst remaining offenders in the "gray text on gray background" category are SaaS dashboards...

I prefer to just avoid CSS as much as possible. That way, it uses the user's settings in their browser in order to make it readable according to the user's preferences.

That's a laudable attitude in general. Problem is, most users are not aware that these preferences exist, nor do they care. Most usecases are covered by Ctrl+Mousewheel.

Agreed. The typography, the colors, everything is very well done IMO.

Also the content; I have read almost every article since I clicked on this link.

Wow, thank you for the kind words! There are certainly some performance and accessibility issues I could improve on (and plan to fix one day)

I find the text shadows inside the code samples very distracting. Fortunately nothing that a quick trip to the dev tools can't fix.

To me, the lower contrast of the "better" boxes makes them "worse". My eye keeps trying to find the edge of the box and failing; I begin to wonder why the content is in the box to begin with.

Same for me. I like the first example best, because the last one makes me dizzy a bit. It feels weird.

Broken on my browser - the bottom box doesn't display a drop-shadow at all. (Chromium/Linux)

Also, please nobody actually use this on a site I might visit - using all this processing power to make a drop shadow marginally better/worse is one of the many reasons we can't have nice things.

> please nobody actually use this on a site I might visit

Hard to force others to not use it, but you can override those declarations in your browser's user style sheet so it will not render them (that's what user styles are for).

`, :before, *:after { box-shadow: none !important; }` in real user style sheet, i.e. in Firefox profile in chrome sub-folder and `toolkit.legacyUserProfileCustomizations.stylesheets` turned on should do the trick. Or -- with boosted selector specificity -- you can use some userstyle manager extension (like Stylus) to do the same.

Looks like it can be easily achieved with layered shadows, https://brumm.af/shadows

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

Proper soft shadows are useful for flat UI multi window applications too, like on macOS: https://i.imgur.com/8k5b4UC.png

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.

We need 3D buttons with raytracing !

A 'realistic' drop shadow can never be smaller than the occluding object itself.

It can appear that way if the light source is large, or there are multiple light sources. Then what you mostly see is a faint penumbra rather than a dark shadow (the umbra).

True, this is looking like a studio light setup to me, and it's rather pleasing (albeit not making much sense.)

I assumed it was to simulate perspective.

Sure it can be.

Just needs an area light source or more than one spot source.

Try looking at the pavement under a car on a cloudy day.

I want to sue for disability now that I have ripped my eyeballs out because that page is so ugly.

why so cruel?

Reply on news.ycombinator.com