This is misleading. The “real statistics” you link to include non-standard, Blink-only APIs like Web Bluetooth and Web USB. These are not web standards. Google proposed them and both Mozilla and Apple have rejected them on security and privacy grounds. Google have not been able to convince anybody to implement them.
Web standards are not simply whatever Google unilaterally decide they want. Standards require consensus.
Jim once again you are jumping in to defend Apple no matter what the topic is. It’s a really strange behaviour yet again.
Since you seemed to be in such a rush to offer a defence it seems you misread what the chart was… like every other time this topic comes up over the past few years.
That chart is *the official web platform standards* and shows which tests ONLY FAIL IN A SINGLE BROWSER
So this idea of “oh no it’s just evil Google doing their own thing doesn’t actually apply here because that’s literally already accounted for by the fact that it’s how many of the official web standards only fail in one browser.
I don’t know why you keep glossing over this no matter how many times it has been politely pointed out to you.
> Jim once again you are jumping in to defend Apple no matter what the topic is. It’s a really strange behaviour yet again.
Is it possible for you to respond to me without personal attacks? This is the second time this week you have decided it’s appropriate to call me weird.
I have not misread anything. Web USB and Web Bluetooth are not web standards.
> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
The specifications literally tell you they aren’t standards.
They have been rejected by both Mozilla and WebKit:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
> The low-level nature of this API means that it is insecure, has a massive privacy risk, and perhaps most importantly doesn't meet the web platform's device-independence bar.
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label. This spec also depends on a specific hardware technology, and enables dependency on specific attached hardware accessories, which risks the device independence of the web; thus concerns: device-independence.
Something isn’t a web standard just because Google decided to publish a specification. No other rendering engine has accepted these specifications.
> I don’t know why you keep glossing over this no matter how many times it has been politely pointed out to you.
I don’t believe anybody has ever said this to me before, let alone repeatedly, let alone politely, but perhaps I am forgetting. Could you refresh my memory? When did this happen?
Listen spending all of your free time to defend the worlds richest company no matter the circumstances is strange behaviour, I don’t know how else to put it. I think you’re odd and I’m not trying to be impolite but you’re going to have to accept the fact that people find your hobby weird.
You have once again however just done the exact same thing I accused you of where you are responding to an argument that nobody actually made and then pretending you’re somehow victorious which again is odd behaviour.
Please explain to me how you’re reconciling the idea of:
1. Apple and Firefox decided not to implement Web USB
2. The chart is measuring something entirely different.
In the web USB example that doesn’t show up in that chart precisely because more than one browser fails those tests.
The fact of the matter is that the world richest company makes the worlds shittiest browser and has some of the most unusual fans.
> spending all of your free time to defend the worlds richest company
I am not doing this. Every time you and I disagree on this subject we are both participating in the discussion, yet you characterise only my participation being unreasonable. This is a double standard that you are using to tell me to shut up.
> I think you’re odd and I’m not trying to be impolite
I have asked you repeatedly to stop this. At this point it is not so much impolite as deliberately antagonising. You know this. You continue to do it.
> but you’re going to have to accept the fact that people find your hobby weird.
This is not my hobby. When we disagree, you jump into personal attacks. That is what is happening, repeatedly.
Stop dragging these conversations down into the mud. If you cannot reply without being insulting, then simply do not reply.
You keep doing the exact same thing on repeat literally for years at this point.
You are the one who replies here looking for a response despite knowing exactly how it was going to go. Don’t be upset when you put yourself in that situation intentionally and it doesn’t go the way you want it to and for no other reason than to misrepresent the data to suit your favourite company yet again.
Please just do both of us a favour and don’t reply, if there was a block button on here it would be much better for both of us. I’m not trying to be rude to you I just really don’t enjoy talking to you.
Ah haha. I love this conversation of trying to find a product market fit in public.
What if the input to the JavaScript (mermaid in this case) is not trusted to run on the end client machines but by running untrusted input on a sandbox (this service, or self hosted idk) is somehow acceptable and the output a blob of an image is acceptable to display on the actual client machines.
Takes the planets to align just right and need us to squint just enough but I think we can find something if we look hard enough.
But then mermaid can simply output PNG so you could run it as a worker... Thinking...
> In many respects 2025 was a lost year for programming. People speak about tools, setups and prompts instead of algorithms, applications and architecture.
I think the opposite. Natural language is the most significant new programming language in years, and this year has had a tremendous amount of progress in collectively figuring out how to use this new programming language effectively.
What surprised me is that when I went to look at the Wikipedia page for CF, apparently its latest release was this year! I haven’t heard anybody mention it in a very long time.
I worked at a major university that used ColdFusion. They had one guy furiously writing all these websites that were total one-offs. They didn't use source control. Every project was a copy of his original. If there was a bug, he had to update dozens of projects instead of maintaining common source across those dozens of sites. He was totally insane and making bank.
I was active in the ColdFusion/CFML community for a long time, and still run some production code in it. It certainly isn't popular, but just carries on quietly, powering a lot of internal applications you'll never hear about. Many run the open source version of it (Lucee).
Indeed it does. I maintain one such application while an in-progress rewrite develops. Gotta say, it's not been that bad and the Lucee docs have served me well, but for whatever reason I tend to be pleased/impressed by all kinds of tech, even when popular opinion is negative about it.
With how deeply embedded cold fusion was in many gigantic corporations I've worked with, I would not be surprised if it stays alive for decades to come because nobody ever can port off of it.
Don't remember the full context, but I heard a few years ago from Adobe that they could never sell another license to the private sector and government licenses would be self-sustaining.
And then you make a global index of those skills available to models, where they can search for an appropriate skill on demand, then download and use them automatically.
A lot of the things we want continuous learning for can actually be provided by the ability to obtain skills on the fly.
There is no single organisation that has done more to push the mobile web forward than Apple. Seriously, name one.
Nobody gave a shit about the mobile web until Apple launched the iPhone, where one of its main selling points was a “desktop-class web browser”, where Steve Jobs told announced that if they wanted to run apps on the iPhone, they should be web apps.
Then suddenly everybody started demanding “iPhone-compatible websites” overnight. Nobody was asking for “mobile websites”, which until that point were shitty WAP/WML things, or – in the best case – cut back m.example.com microsites. People wanted “iPhone-compatible websites”.
And then all the other phone vendors used Apple’s open-source WebKit code (open-source thanks to KDE, useful on mobile thanks to Apple) to release their own browsers, and the mobile web took off like a rocket because suddenly it was useful because people could use real websites.
And let’s not forget Steve Jobs telling people to avoid Flash and use open web standards instead.
There is a very clear before/after with the mobile web, and it’s the launch of the iPhone and all the work Apple put into making WebKit work well on mobile that provided that watershed moment.
Apple were championing the web in the time period you claim they were “intentionally undermining and artificially crippling it”.
Now, you may be underwhelmed by their performance in more recent years, but it’s simply factually untrue that they have had a 20 year campaign to undermine the web.
> We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.
I think that’s an exceptionally uncharitable description of what happened. This is a decision the WebKit team has been repeatedly publicly asking people to participate in for over 18 months.
> Help us invent CSS Grid Level 3, aka “Masonry” layout
> P.S. About the name
> It’s likely masonry is not the best name for this new value. […] The CSSWG is debating this name in [this issue]. If you have ideas or preferences for a name, please join that discussion.
> Help us choose the final syntax for Masonry in CSS
> We also believe that the value masonry should be renamed.
> As described in our previous article, “masonry” is not an ideal name, since it represents a metaphor, and not a direct description of its purpose. It’s also not a universally used name for this kind of layout. Many developers call it “waterfall layout” instead, which is also a metaphor.
> Many of you have made suggestions for a better name. Two have stood out, collapse and pack as in — grid-template-rows: collapse or grid-template-rows: pack. Which do you like better? Or do you have another suggestion? Comment on [this issue] specifically about a new value name (for the Just Use grid option).
The debates went on for years and following it closely became a poor use of time. Even the subgrid conversation seemed completely stalled. I think a lot of people tuned out long before any vote was discussed. I did.
But if you were the one who tuned out, then isn’t it uncharitable to describe it as their failing to make you aware of the vote? Isn’t it on you to stay in the loop?
Surely they can’t start just pinging everyone who might have cared at some point during the time to get involved.
I get what you're saying but making interminable arguments and keeping the "debate" going is a tactic. There's that CIA sabotage manual with the section about meetings and conferences, it can feel like that. The duration of these debates aren't usually measured in hours, days, or weeks, but years. And the people who dragging them on and staying in the fights are employed full-time to do exactly that.
It got to the point where I believed that subgrid was dead. FF implemented it but absolutely no one else did, for years.
Is it our fault for tuning out of the debate? Yep. But tactics were employed to achieve that exact outcome. I'm fine admitting that I tuned out. But it was a battle of attrition waged by people who were fine holding up progress indefinitely.
Is that how you want decisions to be made?
Ultimately I'm not too concerned what you call the masonry feature. However the debate over what to call it was an extreme case of bikeshedding. I would have rather given up the fight over semantics to resolve the non-issues and ship the feature years ago. As it stands we're still years away from actually being able to use the feature in production.
I've stopped waiting for companies, committees, or projects to change course. I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist. Why bother? I have an incentive to spend my time building features that users will use.
There’s no incentive to the companies or the employees to draw out the discussion, especially over something so trivial. It’s much more preferable to try and speed through things to get things done in a time frame that can be adopted.
And regardless, if you don’t feel it’s worth your time, then why cast aspersions that it was something clandestine and intentionally hidden? You could have shown up and kept up with it, just like everyone else involved presumably did.
I didn’t ascribe a motive to anyone. Their reasons are their own and it only makes sense that the people who stay in these fights do it because it’s part of their jobs.
There are people who, for whatever reason, keep debates going over small points of disagreement and prevent issues from being settled. Sometimes for years. Right?
The older I get, the more likely I am to recognize and route around or ignore interminable debates. Especially if it’s not for a company, project, or initiative under my direct control.
Remember, the question at the top of this thread was essentially “What happened to ‘masonry’?” Well, there were quibbles over the descriptors.
I don’t care about quibbles. “masonry”, “grid-lanes”, “grid-masonry”, pick one, they’re equivalent. I don’t like it when quibbles block progress.
Sometimes people and companies do want to block things. You’d have to ask them why. Like I said earlier:
> I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist.
Pick your battles… Actually, no, it’s usually better to ignore the fights and just get what you need to get done so you can move on.
I prioritize simplicity and adoption for non-technical users over strict IETF compliance right now. My goal is to make this work for a shop owner on Shopify and Wix, not just for sysadmins.
That said, I am open to supporting .well-known as a secondary location in v1.1 if the community wants it.
I am the initiator, not the dictator.
Governance is defined in Section 13: Contributing & Governance.
Decisions are made by consensus of the Working Group. Right now, we are bootstrapping. I make the initial calls to ship v1.0, but the roadmap involves the community. I invite you to open an Issue.
Try uploading a file to /.well-known/ on Shopify or Wix. You cannot.
Their file managers block hidden directories (starting with a dot). To do it, you need a custom app, a meta-field hack, or a reverse proxy.
That is sysadmin work.
Uploading a file to the root is user work. That is the difference.
Agreed. In a perfect world, they would.
But I cannot merge PRs into Shopify's core.
Waiting for trillion-dollar corporations to change their security models is a death sentence for a new protocol.
We build for the infrastructure that exists today, not the one we wish for. When they open the gates, we will move. Until then, we live in the root.
I’ve implemented a search crawler before, and detecting and switching to the WordPress API was one of the first things I implemented because it’s such an easy win. Practically every WordPress website had it open and there are a vast number of WordPress sites. The content that you can pull from the API is far easier to deal with because you can just pull all the articles and have the raw content plus metadata like tags, without having to try to separate the page content from all the junk that whatever theme they are using adds.
> The reality is that the ratio of "total websites" to "websites with an API" is likely on the order of 1M:1 (a guess).
This is entirely wrong. Aside from the vast number of WordPress sites, the other APIs the article mentions are things like ActivityPub, oEmbed, and sitemaps. Add on things like Atom, RSS, JSON Feed, etc. and the majority of sites have some kind of alternative to HTML that is easier for crawlers to deal with. It’s nothing like 1M:1.
> Investing the effort to 1) recognize, without programmer intervention, that some random website has an API and then 2) automatically, without further programmer intervention, retrieve the website data from that API and make intelligent use of it, is just not worth it to them when retrieving the HTML just works every time.
You are treating this like it’s some kind of open-ended exercise where you have to write code to figure out APIs on the fly. This is not the case. This is just “Hey, is there a <link rel=https://api.w.org/> in the page? Pull from the WordPress API instead”. That gets you better quality content, more efficiently, for >40% of all sites just by implementing one API.
This is misleading. The “real statistics” you link to include non-standard, Blink-only APIs like Web Bluetooth and Web USB. These are not web standards. Google proposed them and both Mozilla and Apple have rejected them on security and privacy grounds. Google have not been able to convince anybody to implement them.
Web standards are not simply whatever Google unilaterally decide they want. Standards require consensus.
reply