NHacker Next
- new
- past
- show
- ask
- show
- jobs
- submit
login
Rendered at 15:48:17 GMT+0000 (Coordinated Universal Time) with Vercel.
The Daily Sketch series or 'CSS Animation with offset-path' are equally fun.
Have you tried the same thing with shadows? They can also be stacked, I believe.
--c: #5EBD3E,#FFB900,#F78200,#E23838,#973999,#009CDF;
@content: '';PS: Please give me comments on the current design of the blog.
My example: https://codepen.io/spartanatreyu/pen/xggjWz
------------------------------------------------
Overall, CSS tends to be the better tool for the job.
SVG has better paths and more interesting filters, but it's held back by a few critical issues.
1. A small amount of filters are not hardware accelerated in firefox/servo's webrender engine, which causes them to fallback to software rendering. Usually it just freezes the web page for a second or two while the image software renders before returning to normal performance, but if you try to animate any of the values it locks up the entire page.
That basically animated SVGs with filters a no-go.
2. Safari doesn't draw SVGs properly, it has a built-in "performance budget" where it just stops drawing the rest of the SVG if it isn't finished within a split second. Which is fine for something like an icon, but terrible for things like the main feature graphic / background of a page.
Meanwhile CSS keeps getting better. Its filters are improving (filter, mix-blend-mode, backdrop-filter), and its animations are improving too (keyframes + animation, transition, offset, custom-properties + @property's syntax, scroll-timeline, cross-document view transitions).
The two things that CSS is worse at than SVG are:
1. Paths (in which case, you can just put SVG paths into your page and style them with CSS for anything more complex than a static stroke/fill anyway)
2. Generating textures (which you can't guarantee look consistent thanks to Safari, so you're usually better off sending a hand optimized texture over the wire anyway)
SVG is not great for text - HTML has more features - but for display text it's OK.
https://css-doodle.com/
Kudos to the author for posting something cool and new in the age of standardised styles.
Firefox has chosen to expand based on distance at all points, which is one of the reasonable answers and probably the most general one; a cusp then expands to a curve.
The others have chosen to retain cusps, which can be a reasonable answer and I believe is a lot cheaper to compute; but degenerate cases abound as you expand past the feature size (distances between nodes), so that by the fourth red ring it’s obviously incorrect.
Box shadows are another case where expansion occurs: the fourth length parameter, spread distance. If the corner is a cusp, the shadow corner will be a cusp. If it’s rounded, the shadow corner will be rounded. See https://drafts.csswg.org/css-backgrounds/#shadow-shape for some helpful diagrams. A sneaky trick: .1px border-radius means the box still looks square, but the expanded shadow will curve. Sometimes useful. But back on the original content of the article—if you use a font with microscopic curves instead of cusp nodes, Chromium/Safari will look more like Firefox.
(Yes, it could technically be infinite corner cases)
[1] https://www.w3.org/TR/fill-stroke-3/#stroke-linejoin
I may be entirely wrong though, I don't know in detail how browsers render stuff
Made few shots and playground for that back then: https://x.com/myfonj/status/1870178380831732160