1,532 karma · joined August 23, 2012
I’ve been building a vector editor that by default draws shapes with smooth curvature and shows the comb. [1] In addition to the four point types mentioned in the article, you get a new “curve” point type. I’ve also been making a font editor with the same drawing capability. [2]
Both are free static web apps that use local storage and have import/export capability for SVG files (and OTF files for the font editor).
Does/could it also fill out an existing `wrangler.jsonc` that’s not fully filled out? Another helpful thing could be prompting when for example the name in package.json mismatches the worker name, etc.
https://github.com/RaymondTana/Lights_Out/blob/31fe5e866c45c...
For fun you can also, for example, invert any board in N moves by tapping every cell straight across any row or column.
Edit: above tested for 5x5 rows&cols. For even boards it seems there’s a small end-game to repeat the process — something about parity I assume.
For example it helps when the anchoring element is inside of an oveflow hidden/scroll container, but geometrically you need the tethered element to sit/extend outside of the container (so—for now at least—its DOM node needs to be outside of the container).
Putting aside for the moment that I personally find Apple’s iOS 26 design objectionable[1], I don’t understand why `backdrop-filter: blur` is the focus of recent implementations jumping on the Liquid Glass hype train.
Using background blur to create UI layer separation (often in combination with darkening/saturation or other contrast enhancements) has been around for over a decade on iOS and almost as long on the web. So what’s new here?
Adding to my confusion, I’m a bit surprised folks here think this is so challenging in CSS. A few commenters have pointed to great implementations elsewhere, but I think they’re underselling them.
Plainly: the solution that involves `backdrop-filter: filter(#filter)` where `#filter` references an inline SVG embedded with `<feImage/>` and `<feDisplacementMap/>` works very convincingly well.
Check out this demo for example:
https://codepen.io/Mikhail-Bespalov/pen/MYwrMNy
This implementation choose to hard-code `<feImage href="data:image/png;base64,..."/>`. But if glass3d.dev chose to implement 3d highlights in a similar fashion (and wanted to support e.g. a dynamic `border-radius`) this image could easily be rendered in the browser runtime in canvas, and dumped into the CSS using `toDataURL()`. Similarly, a component library with a CSS pre-processor could generate these for any static shape at build-time.
The closest thing I’ve seen to this is:
These implementations are out there.
Coming back to the why/should for a second though.
[1] In its current realization, Liquid Glass cannot effectively replace what blur accomplishes. Because Liquid Glass layers are more transparent, the contrast issues are real, and the spectral highlights distract the eye as much as (or more than) they help make up for that lack of contrast. It draws attention to the eye where blur would relax it. It’s a UI meant for an XR system (where it arguably solves a real problem, much like a HUD does in a video game) hacked into devices where it makes no sense, all in the name of a “unified OS” design language.
If any aspect of Liquid Glass is successful it will be when it’s used sparingly to delight in places that are low stakes and where other affordances are present (like a small circular button floating in the corner of the screen with hardware concentricity). A circle shape’s refractions would be smaller, softer, more symmetrical, and therefore arguably less noisy/distracting—in a way resembling a softer blurry background.
Which brings me full circle back to two wrongs.
This website doesn’t do anything new, but that’s why it’s good. Because the truth is, Apple failed to deliver a Siri-based LLM on a schedule it announced and is now trying to distract us with some shiny new thing. Damn, it worked.
For example it was pretty unergonomic to set up support for deploying to a `pathPrefix` [1] while retaining the ability to develop locally [2].
Nevertheless, we were able to make it work and have been relatively happy with Gatsby overall.
Absolutely! The docs are dual MIT and Apache licensed [3] so have at it. One note: we have not yet completely teased apart the so-called “engine” from our particularly implementation itself. This is something we’re planning to do, in part because we need to to support our other docs sites. You may find it easier to work with once we’ve done that. That being said, you can also just fork the repo, change the content and branding, and things should mostly “just work”. Of course if you run into issues along the way, we’d be glad to have contributions back to the project itself. Good luck!
[1]: https://git.io/JUJsy
We also published as part of this release some documentation for the so-called “Docs engine” which powers these new docs, which may somewhat answer this question.
https://developers.cloudflare.com/workers/docs-engine
(Note: They currently live within the Workers docs site for now but will get a proper home soon.)
With respect to the information architecture and content design, much of that is discussed in the Contributor’s Guide [1] and Docs-flavored Markdown [2] pages.
The very short version is that we borrowed many ideas from Divio’s documentation system [3], which recommend dividing your content into four distinct buckets: Tutorials, How-to Guides, Explanation, and Reference.
The layout and visual design were inspired by dozens of other docs sites we tested and studied, stealing the best ideas we could from everywhere we looked.
It’s also worth noting that the Cloudflare Workers docs have been open-sourced for over a year now [4], and these new docs (as well as the new engine which powers them) will continue to carry the same license. Contributions are welcome and we’re hopeful and excited to see further uses of the docs engine over time.
[1] https://developers.cloudflare.com/workers/docs-engine/contri...
[2] https://developers.cloudflare.com/workers/docs-engine/docs-f...
[3] https://documentation.divio.com/
(edit: formatting)
But you’re totally correct about the JS only toggling between path="happy" and path="sad"
Here was the initial commit which added the first diagram (originally there was only one):
- https://lazy.invoice.workers.dev
- https://web.scraper.workers.dev
Both are powered in part by a worker which generates CSS on the fly for whatever components you need, e.g:
While I certainly agree that a lot has changed in the 4 years since Magic was authored, I think this statement is a little strong. I’d argue that chapters 1, 4, 5, and 6 hold up quite well and that 2 and 3 still contain useful information for newcomers to CSS—despite the absence of flex.
A chapter on flex is long overdue, no doubt, and chapters 2 and 3 should be written with this in mind. I’ll definitely get to it at some point, but I’d also be happy to collaborate with the community if anyone were interested in submitting a first draft [1].
We made some improvements to the way theme colors work [1] so you’ll want to upgrade your version to take advantage of that. Thanks so much for using EmbedBox! If you have any feedback on the integration process we’d really appreciate it.
[1]: https://git.io/viR8p
If you ever do, please let us know. We’d love to add https://chatlio.com to our list of companies using EmbedBox.
Oh also, once you’ve finished implementing it, we’d be happy to add https://rakam.io to our list of companies using EmbedBox.