Then you need to curl the URL, pipe it to an .html file, and then search the resulting file for "@font-face". The only place that has the @font-face rule for this fancy font is inside <template> syntax, meaning it will do nothing (template content is inert) until JS clones that template into the DOM as active content.
Correct. The code editor that has the subscript: "The colors in the HTML snippet above comes from within the font itself, the code is plain text, and requires no JavaScript."
Which doesn't work without JS. So adding the @font-face to the page itself, so that things works even without JS, would be lovely.
combine it with a <details> and <summary> inside the <dd> and a little CSS checkbox toggle for JS-less "show all details"/"hide all details" and it's pure gold.
Counterpoint: whoever let this past the QC phase got paid very generously, and everyone involved is ignoring the laws that already exist to combat this, because law enforcement, too, gets paid generously. And the laws that forbid that aren't getting enforced because the police doesn't police the police, and dad has made it perfectly clear that flagrantly ignoring the law is fine if you're in power.
What makes you think QA/QC is paid handsomely? It's a bloody cost center mate, and you can't measure "damage prevented" consistently, or at least in a way most high-risk tolerating exec types won't immediately undermine.
"We built a billion dollar business on top of ffmpeg" - "did you make a donation that you won't even notice on the books, say, a measly one million dollars, to ffmpeg?" - "psh, why would we?"
> When self-hosting makes sense: 1. If you're just starting out in software & want to get something working quickly [...]
This is when you use SQLite, not Postgres. Easy enough to turn into Postgres later, nothing to set up. It already works. And backups are literally just "it's a file, incremental backup by your daily backups already covers this".
These laws were never about protecting the children, and trying to argue it's not protecting children really is just a waste of time. These laws are about knowing who wants access to what, so the government can hold that over you when they eventually decide they don't like you and need an excuse to make your life hell.
Are you going to reverse your nonsense "these publications already come with a summary, so we've added a worse, AI generated summary and making that the first thing you see instead" decision though?
Docker containers with root have rootish rights on the host machine too because the userid will just be 0 for both. So if you have, say, a bind mount that you play fast and loose with, the docker user can create 0777 files outside the docker container, and now we're almost done. Even worse if "just to make it work" someone runs the container with --privileged and then makes the terminal mistake of exposing that container to the internet.
I believe they meant you could create an executable that is accessible outside the container (maybe even as setuid root one), and depending on the path settings, it might be possible to get the user to run it on the host.
Imagine naming this executable "ls" or "echo" and someone having "." in their path (which is why you shouldn't): as long as you do "ls" in this directory, you've ran compromised code.
There are obviously other ways to get that executable to be run on the host, this just a simple example.
Another example is they would enumerate your directories and find the names of common scripts and then overwrite your script. Or to be even sneakier, they can append their malicious code to an existing script in your filesystem. Now each time you run your script, their code piggybacks.
OTH if I had written such a script for linux I'd be looking to grab the contents of $(hist) $(env) $(cat /etc/{group,passwd})... then enumerate /usr/bin/ /usr/local/bin/ and the XDG_{CACHE,CONFIG} dirs - some plaintext credentials are usually here.
The $HOME/.{aws,docker,claude,ssh}
Basically the attacker just needs to know their way around your OS. The script enumerating these directories is the 0777 script they were able to write from inside the root access container.
I want the people who make Firefox to make decisions about Firefox based on what users have been asking for instead of based on what a CEO of a for-profit decides is still not going to make them any money, just like every other plan that got pitched in the last 10 years that failed to turn their losing streak around.
It's not a knee-jerk reaction to "AI", it's a perfectly reasonable reaction to Mozilla yet again saying they're going to do something that the user base doesn't work, won't regain them marketshare, and that's going to take tens of thousands of dev hours away from working on all the things that would make Firefox a better browser, rather than a marginally less nonprofitable product.
While I do sympathize with the thought behind it, general user is already equating llm chat box as 'better browsing'. In terms of simple positioning vis-a-vis non-technical audience, this is one integration that does make fiscal sense.. if mozilla was a real business.
Now, personally, I would like to have sane defaults, where I can toggle stuff on and off, but we all know which way the wind blows in this case.
Firefox is not for general users, which is the problem that Mozilla's for a literal decade now. There is no way to make it better than Chrome or Safari (because it has to be better for every day users to switch, not just "as good" or even "way more configurable but slightly worse". It has to be appreciably better).
So the only user base is the power user. And then yes: sane defaults, and a way to turn things on and off. And functionality that makes power users tell their power user friends to give FF a try again. Because if you can't even do that, Firefox firmly deserves (and right now, it does) it's "we don't even really rank" position in the browser market.
The way to make Firefox better is by not doing the things that are making the other browsers worse. Ads and privacy are an example of areas where Chrome is clearly getting worse.
LLM integration... is arguable. Maybe it'll make Chrome worse, maybe not. Clunky and obtrusive integration certainly will.
I find that hard to believe, every general/average user I have spoken to does not use AI for anything in their daily lives and have either not tried it at all or only played with it a bit a few years ago when it first came out.
The problem with integrating a chat bot is that what you are effectively doing is the same thing as adding a single bookmark, except now it's taking up extra space.
There IS no advantage here, it's unnecessary bloat.
> Had to explain to my employer attending that it is still typescript
"is" is doing a lot of heavy lifting there: JSDoc and TypeScript are two different ways to explicit prescribe typing in a way that tooling can use to determine correctness. The TS syntax is _far_ more powerful, but JSDoc can do most of the common TS use cases, for folks who want to stay in JS land while still benefiting from type tooling (either invoked or straight up built into the IDE).
> in a way that tooling can use to determine correctness.
As I pointed out in the article, the "tooling" is exactly TypeScript language services. If you are using JSDoc and you get squigglies or intellisense or any other similar features, you are using TypeScript.
You can copy-paste basically any bit of TypeScript into a JSDoc comment and it will work. JSDoc supports any non-runtime feature of TypeScript (so not enums). Even generics! You can even reference TypeScript utility types!
The whole point of this article was to correct the idea that JSDoc is not TypeScript. It absolutely is! There's almost nothing you can't define in JSDoc that you can't define in a .ts file. Albeit with a sometimes clunkier syntax
> If you are using JSDoc and you get squigglies or intellisense or any other similar features, you are using TypeScript.
This is true in the same way you are "using" C++ if you are on Windows. When most people say "use XYZ language" they mean "are personally writing code in XYZ language" rather than "under the hood my code is transpiled to this other language I don't write in"
By "JSDoc is TypeScript", culi means "JSDoc syntax and TypeScript syntax are two alternative ways to describe types to the TypeScript compiler/language services, and the two syntaxes have nearly-identical expressive power".
I understood it that way too. Only that it fails in that interpretation.
Just because currently the most popular method for parsing JSDoc utilizes TypeScript-related tooling doesn't mean we should associate them with each other.
To my previous example, an ISO C++ can be compiled by GCC but also can be compiled by Clang (and many other compilers).
Perhaps I should've expanded further to "the specific JSDoc dialect supported by the TypeScript compiler and TypeScript syntax are two alternative ways to …".
Unlike ISO C++ I'm not aware of any standard for what JSDoc is outside of specific implementations. There's a bunch of stuff documented on https://jsdoc.app/ but it only partially overlaps with the JSDoc syntax that TypeScript uses, and is not what the article is talking about.
The situation is not unlike Markdown before the CommonMark standard (except with less pressure to standardize, because most codebases are written with specific tooling in mind). Maybe we should refer to it as "TypeScript-flavored JSDoc".
In practice today JSDoc 100% completely and utterly always is Typescript.
It might not have been so originally. It might still be possible to do differently. But in practice today you are getting Typescript in your JSDoc with the out of the box tooling that is everywhere.
Welcome to the "a cat [1] has four legs [2], and therefore everything with four legs [3] is a cat [1]" fallacy. That's not how that works.
JSDoc is its own spec, and is not typescript, and is absolutely not at type annotation parity with typescript. Plenty of things that are hard to type in TS that are impossible to annotate use JSDoc.
So: just because tsc, the tool, can read in typing information that was written in JSDoc, does not make JSDoc typescript. tsc simply supports JSDOc. Very handy! Not the same thing in the slightest.
You are mixing theory with practice. In theory felines can be both cats and tigers. In practice the felines walking around your neighborhood are all cats.
No of course not, that's an absolutely ridiculous thing to say. ∀A -> B does not mean ∀B -> A, it only means ∃B -> A.
tsc, the executable, not only supports TypeScript, the language, but also knows how to read JSDoc when you're not giving it TypeScript. It supports JSDoc for code that isn't TypeScript. I'd repeat that a few more times but hopefully twice is enough to make the point obvious.
Sure. In theory people could be doing that. But for the third time: what is happening in practice?
What people _could_ be doing vs what they _are_ doing was explicitly my point, so please stop pretending it wasn't, less we have to repeat this merry go round.
If the question is about whether JSDoc is TypeScript, and you want to turn it into a different question, maybe your question belongs in a different thread.
JDoc, the spec and docs-in-practice, is not TypeScript, the language and tooling ecosystem in practice, and does not have type annotation parity with TypeScript (so it's not even "the choice is arbitrary in practice because they do the same thing").
JSDoc is simply a supported spec by the TypeScript tooling. Saying "JSDoc is TypeScript" when you're a programmer, especially one that uses one or the other, is idiotic: your job relies on precision in both code and terminology.
But then why does the color disappear if I disallow scripts on this page? Instead of your font, now it uses Consolas.
Are you using JS to load the font in? (if so... web fonts don't need JS to load =)
reply