panzerboiler

Are you saying that windows ignores the `powerPreference: "high-performance"` setting of the WebGL context creation?

Yes, it does. https://www.sqlite.org/vtab.html

Today no music.

https://www.youtube.com/watch?v=J2FiFAuQOK8

I usually prefer a binary encoding. More efficient on the wire, easier to parse and generate, and with no ambiguity. We have 2 control codes given to us by the teletype era that have the perfect meaning for this kind of data:

    0x1E Record Separator
    0x1F Unit Separator

Hallo. I am a contractor. Why you shouldn't pay for the time my machine is building your project?

Those benchmarks are measuring the speed of the tool used to run the benchmark, not the http servers. Take them with a pack of salt.

In Safari there is no transition. The viewport height snaps between svh and lvh at the end of the browser's chrome collapse/expand animation. I don't have an android phone to check the Chrome's implementation, but I imagine it working in the same way, since animating the heights of potentially all the elements in the page can not be done in an efficient way by the browsers, and having a stuttery scroll as soon as you start scrolling a web page would not be a great user experience.

Also 100dvh is less than ideal, since it snaps between 100svh and 100lvh when the browser's chrome contracts/expands (at least on Safari. I would like to know how google did implement it in Chrome on android). The reflow that this generates is probably even worse than just having the bottom part of the viewport clipped.

Good art stems from an intimate context. AI regurgitated noise in not going to have that peculiarity for a long time, if ever.

The best example I know of is the OkLCH color picker from Evil Martians (https://oklch.evilmartians.io), linked at the end of the article. It shows the gamuts of sRGB, p3 and rec2020. You need a screen capable of showing them to appreciate the difference (recent Apple devices are all p3 capable).

I don't think the real issue is that one. At least in Safari I get this:

    t = document.createElement("template")
    t.innerHTML = `<style id="outside"></style><svg><style id="inside"></style></svg>`
    t.content.querySelector("#outside").sheet // null
    t.content.querySelector("#inside").sheet // undefined

That means that the .sheet property is present on the style element, but not if it is inside an svg element.

For some reason, the style element inside the svg does not have a .sheet property. A workaround is to create the style element in js and append it to the svg, or move it outside the svg and let the styles cascade. A strange bug...

I am sure that there are plenty more! Working on top of customeditable is hell, but it is the price to pay if you want to implement a custom editing experience. Of the issues you listed, the triple-click is a good one, and easy to solve with a custom handler (even if there is no tripleclick event, the detail property of the event object holds the number of consecutive clicks). I am pretty sure that ProseMirror does something similar, because it uses [contenteditable="false"] decorations without interfering with the triple-click selection. For mobile devices and Firefox I would surrender, and gracefully degrade the editing experience.

Why not use ProseMirror? It doesn't fix this issue, does it? At least in the demos on their website you cannot insert text at the beginning of a styled element. You cannot do it even in a native application (at least on macOS) without a custom handling of the selection.

Thank you for the example. I do mostly the same thing and as a Safari user there is no way to place the caret in "the right spot". What I found working (but I still have to test on other browsers and make my mind if it is really worth the hack) is to place a dummy marker with [contenteditable="false"] at the beginning and the end of the inline elements (the one on the end has to be skipped to avoid getting stuck in a limbo inside the parent element). This way the result is similar to the one in Bike, with the caret that stops on both sides of the element. Let's see if this thing goes somewhere...

> It is possible via JS to place the cursor in that position...

How? No matter what I try, the insertion point is always before the bold element, and not inside it.

Thank you for the nice tool, and for all the nice things released by Mercury. I loved ["On"](https://www.pouet.net/prod.php?which=65350) so much, and [hg_sdf](https://mercury.sexy/hg_sdf/) is a very nice library.

Thanks for the correction. I should have read the producthunt page before providing my uninformed guess.

I don't think so. It is clearly raymarching Signed Distance Fields, and doing so in realtime is quite slow. Even if you use proper acceleration structures, for every pixel you have to compute the distance to the closest primitive in the scene, and shade it. For a bunch of primitives using simple materials it is no problem even on a potato GPU, but as your scene gets more complex, the performance goes down, quickly. It is a beautiful and elegant technique, but it has its downsides. If you are interested in going deeper, Inigo Quilez (https://iquilezles.org/) has a lot of articles and code explaining how it works. I would start from https://iquilezles.org/articles/raymarchingdf/

I love SQLite but this is a terrible take, in my opinion. The Web is not meant to be a property of Google. Browsers don't have to implement the Chrome's API in a compatible way. There is a standardization process in place that should govern the progress of the Web Platform. The "do whatever Chrome does, then everybody else will be forced to follow suit" is doing it wrong.

Time is being stolen to work on uninteresting things, and should be reclaimed.

> The most "interesting thing" (happened in computing since the shut down of Xerox PARC) has been the contrast between appreciation/exploitation of the inventions/contributions vs. the almost complete lack of curiosity and interest in the processes that produced them. > Alan Kay

To integrate the article with Creative Commons implementations in glsl:

- [Photoshop blends by ben](https://www.shadertoy.com/view/XdS3RW)

- [Photoshop Blends Branchless by poljere](https://www.shadertoy.com/view/Md3GzX)

Where can I find such design specification? All I can find is https://w3ctag.github.io/private-mode/ and https://www.w3.org/2001/tag/doc/private-browsing-modes/ that tell nothing about the short duration of a private session. Some emphasis is put on the necessity that private mode and normal mode should be transparent to the user (i.e. not breaking any normal feature). It should be not possible to tell the two modes apart. If you break a feature like ServiceWorker you are providing a way to detect a private browsing session, and that is a bad thing, worse than anything a SW could provide, in my opinion.

I don't agree that private browsing is for short-term use. You can use a temporary storage for how long it is needed (in my case up until the operating system or the browser crashes, aka almost never).

Not because "it is cool" but because it needs that code to operate. Consider this scenario, even for a classic website/blog: you can eagerly download all of the textual content at first load as markdown, cache it in the ServiceWorker together with a markdown parser, and go offline. You can then ask the network, if available, only for downloading images that then get added to the offline cache. Even with a spotty and slow mobile connection, after the initial load you are done with the network and you can read all the content in an efficient, environmental friendly and fast way. When the network is available, you can check if there are updates by sending a small request to the server, and update the cache.

I really don't understand your point. Since ServiceWorkers provide an offline experience and can be inspected from the client, they should be better than no ServiceWorker with respect to privacy.

The new fast webserver (flash) is still --unstable, hence not production ready. It has a performance comparable to nodejs+uWebSockets.js and bun (that should be using under the hood a slighly modified version of uWebSockets).

edit: as a silly point of reference, an hello world that writes the same headers and the same body on a 2016 intel macbookpro is able to serve 125k rps in bun, 145k rps in deno/flash and 140k rps in nodejs+uws.

If you want to see which one is faster (kind of pointless since both bun and deno/flash are not production ready) test your own application, and not an "hello world" or a specific workload that has been optimized to win a specific benchmark.

I can confirm. It is extremely choppy and resource hungry for what it does. Since they use Flutter, the UI is rendered using 119 canvas elements. The same thing could be implemented using the web platform (no flutter and no rust) with better results.

Do you want the operating system to prevent an app to read/manipulate the pixels of a raster image submitted to it? No, thanks. I would avoid instead any app that forces me into doing something that I don't want to do. Detecting screenshots is just one of the many abusive behaviours that most users accept when they register to those services. The same technology that they abuse enables a lot of useful things. Blame the services, not the tech.