Hacker Newsnew | past | comments | ask | show | jobs | submit | maelito's commentslogin

The EU should find a way to fund Firefox or another independant browser.

Independant from Safari's and Chrome's engines.


There has been some EU funding for Servo:

- The Sovereign Tech Agency (a branch of the German government) is funding Igalia ~€500,000 over two years to work on Servo (https://www.sovereign.tech/tech/servo).

- And there have been several NLnet grants (that are worth up to €50,000 each) to individuals working on Servo (NLnet gets there money from the EU).

Those aren't huge sums in the context of browser development, but they're not nothing either.


After doing that to my blog too, I added a comment section to any OSM place on https://cartes.app.

You can now review places with an ATproto account. Any app can implement the same lexicon. Review data belongs to users, as JSON on their PDS.


That is very cool. How do you aggregate the data, listening to public bluesky firehose?

Yes, with a simple Deno server that writes local JSON.

https://codeberg.org/cartes/serveur/src/branch/master/atprot...

I haven't coded yet the fetching from zero on the server in case my "db" fails.

If it fails for a few hours only, it's easy to listen to the jetstream with a cursor. It it's more, we'd have to rely on exploring the graph : getting all PDS that have a record lexicon, and rebuilding the DB. Not too complicated I believe, but we'll see.

It's what https://quickslice.slices.network is supposed to do but I haven't been invited yet.


We need a european Kagi.


Note on the fact that this would add JS that needs to be loaded to see the page. No, because similar smart people created server-side rendering, adding another layer of complexity.

How do you implement this keyboard navigation with SSR (if you use buttons)?

https://www.radix-ui.com/primitives/docs/components/radio-gr...


I can’t tell if this is sarcasm or not! Radio buttons support keyboard navigation without JS.

That's what I mean: if you reimplement it, you need client-side JS to support keyboard navigation.

It needs JS to be interactive unlike the native radio button

This interactivity definitely adds a wow effect.

Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.

> Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.

You're absolutely right!

Today I'm using a friends gaming computer. It's a 244hz monitor powered by a RTX 5070 TI and a screamingly fast AMD Ryzen 7 9800X3D CPU with 128GB of overclocked 6000MT/s RAM.

Not only does the radio look mundane for such overcomplicated component, but it also misses clicks where I would expect it to register. Like slightly above or below it.

For example, clicking where the pointer is in this image does NOT select the first radio button. It's not forgiving with regards to precision.

https://i.imgur.com/PNoCJeL.png


It also doesn't catch clicks between the label and the radio button.

I'm pretty sure it was a sarcastic comment.

On a recent MBP, it's indistinguishable from a vanilla radio button.


In a hilarious turn of fate, on iOS safari the first time one of the radio options is clicked after loading, the css focus style is applied, but a click is not always registered so the radio item ends up stuck in an invalid weird-looking state. I highly doubt the issue would occur if the built in radio were being used

Please, make a Fairphone mini. I'd buy it right away, whatever the price.

Also whatever the battery size though?

Not that I disagree. I bought a Fairphone some years ago and sold it onward because it simply didn't fit in my hand, but the phone I got instead had a delicious combo of small physical battery and terribly inefficient chipset (2019 Exynos). I'd still make the same choice but it's a considerable downside (thankfully the only downside of this phone besides its age and software support by now)


Does not work without Google Play services. No-go.

> The trend at the time was that every website should be architected as an application, and then shipped to the user’s browser to render.

This is wrong. Some websites are better mostly (mostly) rendered on the client (we call them "apps", like a map application) and some are better mostly rendered on the server (like blogs).

It was and will be.


Google maps on mobile is directing the user to the native app more and more. So I doubt this. Geolocation on desktop is mostly useless.

I wonder if this new element is used by MapLibre.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: