Blurry rendering of games on Mac (colincornaby.me)
315 points by bangonkeyboard 11h ago 200 comments
Snapshots of Kids Bike Jumping in the 1970s (flashbak.com)
33 points by bookofjoe 3d ago 25 comments
Should we remove XSLT from the web platform?
46 edent 47 8/15/2025, 7:37:13 AM github.com ↗
For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
I see it hasn't changed.
It kind of baffles me that they could even consider this, maybe I'm just naiive but the webs greatest strength has always been it's backwards compatibility; I can fire a page up written 30 years ago and it still renders (assuming it wasn't built in flash lol). Breaking the user experience like this and saying "well the owners need to update their site" doesn't work - a lot of these pages won't be actively maintained or under the control of someone who can make changes.
Users don't like when you take functionality away from them. This is an appropriate response to a proposal to break part of the web just to make things a bit easier for browser developers (who are meanwhile adding a gazillion other things that are much more complex and actively hurt the users interests).
This change would make people sad because things they like would stop working.
It would cause them stress because they would have to work hard to fix or replace things.
It would cause them anger because some unaccountable people would be making decisions without considering them.
It would make them afraid that those same people might destroy something else which is useful.
These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback.
Web developers aren't Vulcans. We have and use emotions.
I think this is especially true on GitHub where people are using their real professional identities. I’m honestly shocked that anyone can just comment on these proposals given how toxic it gets. Imagine if this is your day to day work environment - you’re trying to improve the web, which is already a tremendously difficult thing while all of these keyboard warriors are insulting you and your efforts. I wouldn’t want to wish that on anyone.
Very true. But why is that argument never deployed against the bullies?
Chrome's developers say "We want to do X". People say "No, please don't." Chrome says "I'm not going to respect your wishes."
Where's the equality in that?
> Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have.
The same is also true of people making those proposals. Chrome devs should know (from bitter experience) that releasing a high-handed statement, studiously ignoring all dissent, and then swinging the ban-hammer is going to lead to ill-will.
Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
> I wouldn’t want to wish that on anyone.
I've been on the receiving end and - yes - it sucks. But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
Unfortunately part of being an adult is realizing there are no bullies. There are adults with power and some people who wield unfairly, but that’s different from a mean schoolchild, although the similarities are there. I don’t think the people who work on browser standards are bullies and it’s weird to frame them in that way.
> Where's the equality in that?
I guess why do you think there should be equality between users and the people that work on browser standards? It’s a committee not a direct democracy. Although they do take user feedback seriously, they surely can’t only do what every vocal minorities wants right?
> Again, why isn't anyone calling for them to be more calm and respectful of the people they're hurting?
They’re not be disrespectful by moderating the thread. They’re simply trying to do their jobs without being insulted constantly. It’s a bit different. They are actively responding respectfully to the feedback, I don’t think they’re hurting people.
> But given that they know these proposals would be contentious, why didn't they approach this in a more respectful and collaborative manner?
How could it be more collaborative? It’s already a request for feedback on an open forum. The comments aren’t even deleted just hidden because they’re duplicates. I’m curious what could be more collaborative?
How would you expect equality in an arrangement where you have a few hundred to a few thousand very specific kind of people producing something for billions?
They are in a special position. Every time you depend on someone to do something for you you cannot perform yourself, either due to a time or any other constraint, that is no longer an equal relationship, and it cannot be. You can make it codependent at best, which is not the same, and doesn't apply here.
All the licensing and open collaboration theatrics are just that, "words on a piece of paper" and things that can go away. I feel people really misjudge the "power" they "gain" from "open" and "transparent" processes like this.
And that position should not be that of a dictator.
Absolutely not what's happening in that thread. Complete nonsense. It's a discussion/proposal.
The bullies are the people coming in and commenting with a bunch of rants, personal abuse, etc. Not the ones wanting to have a technical discussion (either pro or against removal). This is classic "reversing victim and offender" abuser/bully stuff.
You might find that the people on their end, too, have and use emotions.
Acknowledging and voicing your emotional and mental position is one thing, that alone doesn't make it overly emotional. What does is being so taken by them, that it ends up trampling on others'.
By definition overly emotional is bad – that’s what separates “overly emotional” from just “emotional”.
Regardless, having emotions is not the problem, lashing out at others because of those emotions is the problem.
> These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback.
The person you are responding to said:
> we were constantly called names for absolutely any change we would do. Insulted and accused of the worst intentions.
Why are you misrepresenting this as “it will make me sad”?
Human reactions are by definition not bad. They are a genuine expression of how we feel. We use that to signal our emotional state to others.
Try an experiment for me. Tell your partner that you want to split up. Once they finish crying, tell them that they're being "overly" emotional. See how that goes for you.
> Why are you misrepresenting this as “it will make me sad”?
Your mental model of the world has to include that other people have emotions, right? When you announce a change, you know that some people are going to be upset by it. That means you need to craft your message to account for other people's reactions.
Much like the above experiment, email your mother and tell her that you've decided that calling her every week is too much of a hassle and you're not going to do it any more. What do you think her reaction would be?
Perhaps you have a genuine reason for doing so. How would you best communicate that with her? What mitigation strategies would you use? What would you be prepared to compromise on?
Gatekeepers are usually terrible at accounting for the emotions of others. This is a repeated pattern and, by now, shouldn't be surprising to them.
[1] https://thedailywtf.com/articles/Sketchy-Skecherscom
XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):
https://news.ycombinator.com/item?id=44393817
The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
When i was young and stupid and learning to program i made an xslt stylesheet to extract dictionary definitions from the api.
It was meant to be combined with a bookmarklet that when you double clicked a word opened it in an iframe.
It was terrible, but i was so proud of it at the time.
It seems like it stopped working at some point, i guess browsers are probably more strict with mime types now. https://en.wiktionary.org/w/api.php?action=parse&format=xml&...
Sorry if this is too off topic, it just triggered some memories
Terrible why? Bookmarklets and XSLT (and things like Greasemonkey userscripts) were some of the things that made the web more "read-write" in the '00s: anyone could remix web content however they saw fit, optimizing it for their personal use-cases, and often attracted kids and "normies" to coding.
Even today, they can be used to do stuff that most people find magical. Unfortunately they are unfashionable, so they're slowly getting strangled by the big players who want to have all the control all the time.
How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread.
Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.
I already said why:
> The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
If you read the GitHub issue that this submission links to, the issue points out security vulnerabilities and links to:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.
This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company.
Indeed, to me it seems that at some point, you either have to
a) freeze the standard
b) drop old stuff
c) accept that there is no standard
and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate.
(Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)
How great that five years later WebGPU is something we can rely on in portable way. /s
Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...
It will always have a special heart too.
However, in the way it was used in my roles at least - I found it enforced far too rigid a separation between the data and the presentation.
There were multiple times a backend could not perform some function or transformation of the data, for various and always non technical reasons.
That left it to the xslt developers to figure out a solution, and sometimes due to the limits of the language that involved writing a custom java function / xslt plugin.
Things that were incredibly simple when some sort of scripting language is available in your frontend web app could be incredibly convoluted when all you had was an xslt processor.
Now to think of it, I'd like to see one useful example of its usage. Haven't seen one in a long long time.
Securing an XSLT 3.0 implementation would be much easier.
It’s always about balance. I think I read, somewhere, that Microsoft actually reintroduced bugs into their OS, because so many people depended on workarounds and the buggy behavior.
Imagine (if you can!) being able to have two programs, one (program A) that supports JS and all that shite, and another (program B) that supports XSLT and all that shite. If you're still with me imagine that program A could just call program B when it detects stuff that it doesn't support and vice versa.
I know, I know, a measly 16 core CPU with 32Gi of memory is not going to be capable of such feats, but one can dream...