No, it was actually the PDF Association.

They added JXL to the PDF standard.

If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.

Imagine if you couldn't, because you needed to charge your mouse first.

MacOS releases a new version each year, the current MacOS landscape looks like:

- MacOS Sequoia (previous version, everything works as expected)

- MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment")

- MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month)

I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe.

I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate.

I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac.

And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them.

I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test.

---

So, I can't test Safari until I wait a month and purchase a new apple machine.

(Oh by the way, apple keeps cancelling orders for new machines)

You'd want to make it so either:

a) There is nothing to scroll in the first place, so you don't need a scrollbar

b) Capture the pointer so all interaction only occurs within the game's area.

Nope.

Safari only releases a major version once a year, so by only using features that are available in the last two major versions of each major browser, you're already waiting at least 2 years.

> I'd say for safety one should target the browsers of the last 4 years at least.

No.

Supporting browsers that old incentivises users not to update, which causes them to be insecure.

Better they know that something is broken so they have a greater incentive to update.

The common advice now is to only use CSS that is supported in the last two major versions of each major browser. You can check any css property's support here: https://caniuse.com/

> Imho this is a reason why markdown and other rich-textual formats appeared.

Markdown is a superset of html and through it contains css through the style element

> Btw is there a some “w3schools” for recent CSS?

CSS is constantly changing, I'd recommend the following for how to apply new CSS features:

- https://www.youtube.com/@KevinPowell

- https://ishadeed.com

- https://www.joshwcomeau.com

MDN is the best technical reference: https://developer.mozilla.org/en-US/

- You can search any css property in there and it will return all the rulesets for that property.

To see how people are using CSS, I'd recommend:

- https://codepen.io/

- Mastodon/fediverse

  - Reason: All other social networks only have webdevs who sip the coolaid of whatever trend is happening at the moment, they're not actually interested in learning what CSS can do. However, the web devs in the fediverse are actually interested in what CSS can do.

- You can see the proposals here: https://github.com/w3c/csswg-drafts/issues

- Proposals often require experiments which you can find on mastodon/fediverse. For example: https://front-end.social/@kizu

There's also the yearly State of CSS survey to get an overall sense of it: https://2026.stateofcss.com/en-US/

Side note: This feature is in vscode: https://code.visualstudio.com/docs/editing/userinterface#_mi...

No. It can't invent things on its own, it repeats what it's already seen.

People keep seeing LLM outputs without seeing the original source first, then exclaim: The LLM invented it.

Not just in terms of presentation, but also quality.

Amazing!

Yes, but that doesn't mean it wasn't also "helped" along by AI.

See:

1. https://github.com/microsoft/typescript-go/pull/1387

2. https://github.com/microsoft/typescript-go/pull/2978

3. https://github.com/microsoft/typescript-go/pull/1138

4. etc...

Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.

---

The initial port was automated, then devs got in there, then LLMs got in there.

Node's permissions are open by default.

---

Let's suppose that node and deno both have the same 20 permissions.

If we have a project that needs read access to one specific folder and write access to another specific folder, that means:

For deno: I need to turn on 2 permissions to those folders. For node: I need to go through all 18 other permissions to turn them off, and also turn 2 permissions to access only those folders.

So from the get go, node is more work.

---

We're all lazy creatures.

We might forget to turn off the permissions, or worse: think we're safe because we only turned off what we thought were the relevant permissions.

Example:

My project reads this folder and writes to this other folder, I'll turn off the network permission so my data can't be exfiltrated, and commands can't come in down the wire if a dependency becomes part of an attack. And because I'm smart, I'll also turn off the FFI permission so a dependency can't communicate with a program outside of node.

Safe right?

No. The hacker took over a dependency and called cURL through a new process.

There's a million ways to go around things with an open-by-default security model.

Open-by-default is a broken design from the start.

It's a lesson that's been learned over and over again.

A closed-by-default security model is the only way.

---

Deno uses a closed-by-default security model, and implements it in a way that isn't annoying. It just runs your program immediately then when it tries to call a function that requires a permission that it doesn't have, it doesn't crash, instead it pauses execution and asks if it can have that permission. If you say yes, it remembers and doesn't bother you again, if you say no, then the function throws an error to be caught by your code or to bubble up uncaught and crash the program to prevent anything not permitted by you taking place.

The other great thing about it, is that you can run something on deno instead of node, and see which permissions it asks you for.

You'd be surprised how not safe some things are. Once you try it on a few example projects, you'll instantly see why npm has so many hacking incidents. It's an eye-opening anxiety raising experience.

On the other hand, when you run a project and see basically no requests for permissions, you can feel a sense of relief that it can only do what it says on the tin.

It's node + npm compatible and its permission system locks everything down by default.

If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.

Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.

---

Example:

- My linter wants access to my file system?

  - You can have read access to ./src/ts/

  - You can have read access to ./src/ts and write access to ./build-output

  - Huh, what's that? The bundler was trying to both read and write a file in ./src/ts?

  - We don't want input files getting overwritten, that's a recipe for hard-to-diagnose race conditions. Looks like the permission system did more than just keep things secure, it's like a type system for IO.

  - Oh, look at that, there was a very subtle bundler misconfig, let me fix that now. How long would that have existed if we didn't use deno...

---

Addendum: Node now has a permission system, but it's broken by design so it's useless.

It's also the terrible ergonomics.

It's the epitome of putting form before function. It's a desk ornament that leads to frequent injuries with use. See: https://www.google.com/search?q=magic+mouse+injury

Now if someone else a URI, is there going to be any confusion on how many times a URI needs to be decoded?

If the answer is yes, then we have a problem.

(and by looking at the other comments in this thread, the answer is most definitely yes)

Chrome's blink was the only major browser engine not supporting it and that prevented it from becoming a web standard and they refused to acknowledge they were wrong.

Chrome only backtracked once jpeg-xl was subsumed into the PDF standard because if Chrome did not support jpeg-xl, they would by extension also not be supporting pdf.

(too late to make edits)