Live data from Hacker News

Designing Beautiful Shadows in CSS

joshwcomeau.com

61–67 of 67 posts

Re: Designing Beautiful Shadows in CSS

#61
This article is fantastic. Covers everything I would have said about shadows as a designer (from visual and corner case point of view), great CSS/styled components implementation and clearly written with wonderful presentation. 5/5

Re: Designing Beautiful Shadows in CSS

#62
post #31
post #29

Earlier quoted context omitted.

I disagree, please don’t tangentially deny my data points as “no data”. Four random vendors of “premium brand ” not doing today what was spoken about in this thread (properly casting shadows as described in tfa has zero business value for premium brands) is not no-data.

OK good point, instead of "no data" I'll say "an insignificantly small amount of data from which it's impossible to draw any conclusions as you could use the same data to say pretty much anything".

At least I wasn’t drawing from pure imagination.

Re: Designing Beautiful Shadows in CSS

#63

> One more quick tip: unlike box-shadow, the filter property is hardware-accelerated in Chrome, and possibly other browsers. In Firefox, everything is hardware-accelerated. And the `will-change` property is largely obsolete. (I personally wish they had stuck to the old translateZ(0) hack which was obviously a hack rather than defining will-change, since WebRender—what lets Firefox do all the rendering on the GPU—was…

While I generally agree, even in a hardware accelerated world will-change can still be useful. If you're transforming a complex box with lots of typeset international text and stuff in it, it can be necessary to buffer that whole box to a scratch surface first, so will-change is useful to optimize that.

But does will-change do that? I would think what you describe would be a pessimisation in many (perhaps most) cases.

(I haven’t the foggiest idea and my guess is wild rather than educated. I would like to be informed.)

Re: Designing Beautiful Shadows in CSS

#64
post #60

Earlier quoted context omitted.

Yes, largely, the top-left light position is quite outdated, and modern designs are a lot more likely to have the light directly above. Top-left was used in the past because the only lighting hints was the edge colours, and this looks weird with a light that is directly above, so typically a 45-degree light was assumed. In modern design, there is very little edge colouring used, and instead the light determines only…

You do see top-left lighting in 'neomorphic' designs nowadays. The use of bevels has similar attributes to the edge-highlights of win 95, where putting the light from the top can make the left/right edges indistinct.

Does anyone other than design showcase websites use "neumorphic" designs? I have not seen any serious app use it, and it is ugly as hell.

Re: Designing Beautiful Shadows in CSS

#65

> If CSS had a real lighting system, we would specify a position for one or more lights. Sadly, CSS has no such thing. Are there any post processing libraries that can add this? It would be super interesting to treat elements on the page in 3 dimensions

I threw together a crude implementation of a pure CSS lighting system if you're interested: https://github.com/kinseywk/zShadows/blob/gh-pages/index.md

Re: Designing Beautiful Shadows in CSS

#66

Earlier quoted context omitted.

While I generally agree, even in a hardware accelerated world will-change can still be useful. If you're transforming a complex box with lots of typeset international text and stuff in it, it can be necessary to buffer that whole box to a scratch surface first, so will-change is useful to optimize that.

But does will-change do that? I would think what you describe would be a pessimisation in many (perhaps most) cases. (I haven’t the foggiest idea and my guess is wild rather than educated. I would like to be informed.)

It's a hint, so it has no (afaik) spec-required behavior. Whether it does that is up to the browser vendor and could depend on your device configuration.

The MDN guidance says not to use it unless absolutely necessary, which I agree with - but it was added to solve a real problem on certain browser engines (and the problem can be way worse on mobile.)

Re: Designing Beautiful Shadows in CSS

#67
"Physically Based Rendering in CSS" sounds kind of silly, but here we go

First, the width of the blurred region (penumbra). Imagine putting a camera on the ground and pointing it at the sun. By moving the camera in and out of shadow, it can see more or less of the sun. Intuitively we know that the higher the box is, the bigger the penumbra. The sun has an apparent size of .53°, and so does the region of partial shadow descending from the edge of the box. Some trigonometry later, and The ratio of the width of the penumbra to the elevation of the box is .00925 or about 1%

Next, we can calculate what portion of the sun is visible from the penumbra. The amount of sun visible is a portion of a circle, so we do an integral of a circle function and hoo boy would that be a pain to type on mobile. The graph is sort of a `smoothstep` shape, but is very close to linear

Post reply on HN