editable-website VS caniuse

Been dedicating a ton of time to this goal lately.

I released a "SvelteKit template for building CMS-free editable websites" earlier this year and the idea has evolved since. I started out with using Postgres + MinIO for storage, but have switched entirely to SQLite. I also added an in-place image cropper, to resize and optimize images on the client side (WebP output) before uploading and storing them in SQLite. I chose Svelte because it's easy to build classic Web pages (with minimal JS overhead), and at same time implement the reactive layer (e.g. editing) on top of it (will be loaded async). However we are also evaluating the possibility to port this to a LAMP stack at some point. Oh and everything is dynamic here, no build steps involved, edits are live immediately.

Just launched my first client project using this approach:

https://trails-shop.at?editable=true (hit the red button in the bottom-right corner)

Project website: https://editable.website

The editor payload now is loaded on demand (after you click edit), so it's truly progressively enhanced now. :)

Thank you Nils Kjellman for the patch. https://github.com/michael/editable-website/pull/8

Can I X, is a question about the readiness/compliance of a certain thing at time = now. Can I use CSS version X was the iconic early meme.

https://caniuse.com/?search=css3

For a generalized example, if you wanted to know if the basketball courts were ready for you to “ball it up” in a certain city, it’d be caniball.com

If you want to know if you can use a certain frontend technology, the idea is like: canwefigma?

It’s a glorified feature matrix, and usually a project of a passionate community. I approve, even if some of the memes are a bit dank.

https://caniuse.com/ is a popular tool to check what web features are working across different browsers - "can you use this and assume that it will work for others".

The article uses custom css @properties which are awesome and have 88% browser support [1].

One thing to watch out for is differences in how browsers handle setting the fallback initial-value. Chrome will use initial-value if CSS variable is undefined OR set to an invalid value. Firefox will only use initial-value if the variable is undefined. For most projects, this won't be an issue, but for a recent project, I ended up needing to use javascript to set default values in Firefox to iron out the inconsistency between browser implementations.

[1] https://caniuse.com/?search=%40property

Safari is the only browser that doesn't support extending HTML element

https://caniuse.com/?search=Custom%20Elements

You forgot to mention (Web)Workers. This is explicit creation, management, and communication with additional threads within JavaScript. What's more, they've been around in JavaScript longer than the V8 engine has even existed!

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

https://caniuse.com/?search=webworkers

Do you happen to know where can I check out the cutoff version for each browser? https://caniuse.com/?search=wasm doesn't have it (or other things like WasmGC for that matter)

(https://caniuse.com/) A handy tool for checking the browser compatibility of HTML, CSS, and JavaScript features. Can I Use provides up-to-date support tables for various web technologies across different browsers.

Caniuse