> Google is willing to remove standards-compliant XML support as well.
> They're the same picture.
To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well, it's dashed inconvenient to maintain a WASM layer for a dependency that is not safe to vendor any more as a C dependency" is not the kind of servant-oriented mentality that made the web great, not just as a platform to build on, but as a platform to emulate.
Even the browsers created by individuals or small groups don't have, as far as I've ever seen, a "servant-oriented mindset": like all software projects, they are ultimately developed and supported at the discretion of their developer(s).
This is how you get interesting quirks like Opera including torrent support natively, or Brave bundling its own advertising/cryptocurrency thing.
This is an attempt to rewrite history.
Early browser like NCSA Mosaic were never even released as Open Source Software.
Netscape Navigator made headlines by offering a free version for academic or non-profit use, but they wanted to charge as much as $99 (in 1995 dollars!) for the browser.
Microsoft got in trouble for bundling a web browser with their operating system.
The current world where we have true open source browser options like Chromium is probably closer to a true open web than what some people have retconned the early days of the web as being.
It's also 32 million lines of code which is borderline prohibitive to maintain if you're planning any importantly different browser architecture, without a business plan or significant funding.
There's lots of things perfectly forkable and maintainable in the world is better for them (shoutout Nextcloud and the various Syncthing forks). But Chromium, insofar as it's a test of the health and openness of the software ecosystem, I think is not much of a positive signal on account of what it would realistically require to fork and maintain for any non-trivial repurposing.
But it doesn't really make a difference to my broader point that browser devs have never had "servant-mindset"
It seems like most open source projects either have:
1. A singular developer, who controls what contributions are accepted and sets the direction of the project 2. An in-group / foundation / organization / etc that does the same.
Do you have an example of an open source project whose roadmap is community-driven, any more than Google or Mozilla accepts bug reports and feature reports and patches and then decides if they want to merge them?
That statement was accurate enough if you’re willing to read actively and provide people with the most minimal benefit of the doubt.
1. As we're seeing here, browser developers determine what content the browser will parse and process. This happens in both directions: tons of what is now common JS/CSS shipped first as browser-specific behavior that was then standardized, and also browsers have dropped support for gopher, for SSLv2, and Flash, among other things.
2. Browsers often explicitly provide a transformation point where users can modify content. Ad blockers work specifically because the browser is not a "servant" of whatever the server returns.
3. Plenty of content can be hosted on servers but not understood or rendered by browsers. I joked about Opera elsewhere on the thread, which notably included a torrent client, but Chrome/Firefox/Safari did not: torrent files served by the server weren't run in those browsers.
I responded essentially “it was indeed also the browser”, which it seems you agree with so I don’t know what you’re even trying to argue about.
> willing to read actively and provide people with the most minimal benefit of the doubt.
Indeed
> I don't recall a part of the web where browser developers were viewed as not having agency
Being a servant isn't "not having agency", it's "who do I exercise my agency on behalf of". Tools don't have agency, servants do.
I don't know that road maps are any more or less "community driven" than anything else given the nature of their structures, but one can draw a distinction between them and the degree of corporate alignment like React (Facebook), Swift (Apple).
I'm agreeable enough to your characterization of open source projects. It's broad but, I think, charitably interpreted, true enough. But I think you can look at the range of projects and see ones that are multi stakeholder vs those with consolidated control and their degree of alignment with specific corporate missions.
When Google tries to, or is able to, muscle through Manifest v3, or FLoC or AMP, it's not trying to model benevolent actor standing on open source principles.
Open source principles have to do with the source being available and users being able to access/use/modify the source. Chrome is an open source project.
To try to expand "open source principles" to suggest that if the guiding entity is a corporation and they have a heavy hand in how they steer their own project, they're not meeting those principles, is just incorrect.
The average open source project is run by a person or group with a set of goals/intentions for the project, and they make decisions about the project based on those goals. That includes sometimes taking input from users and sometimes ignoring it.
> The Internet is for End Users
> This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.
--- start quote ---
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
--- end quote ---
However, the needs of browser implementers have long been the one and only priority.
Oh. It's also Google's own policy for deprecation: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
--- start quote ---
First and foremost we have a responsibility to users of Chromium-based browsers to ensure they can expect the web at large to continue to work correctly.
The primary signal we use is the fraction of page views impacted in Chrome, usually computed via Blink’s UseCounter UMA metrics. As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
--- end quote ---
The RFC8890 doesn't suggest anything that overlaps with my understanding of what the word "servant" means or implies. The library in my town endeavors to make decisions that promote the knowledge and education of people in my town. But I wouldn't characterize them as having a "servant-mindset". Maybe the person above meant "service"?
FWIW, Google/Mozilla/Apple appear to believe they're making the correct decision for the benefit of end users, by removing code that is infrequently used, unmaintained, and thus primarily a security risk for the majority of their users.
None of the above reads like a "servant-oriented mindset". It reads like "this is the framework by which we decide what's valuable". And by that framework, they're saying that keeping XSLT around is not the right call. You can disagree with that, but nothing you've quoted suggests that they're trying to prioritize any group over the majority of their users.
what's missing is social infrastructure to direct attention to this (and maybe it's missing because people are too dumb when it comes to adblockers, or they are not bothered that much, or ...)
and of course, also maintaining a fork that does the usual convenience features/services that Google couples to Chrome is hard and obviously this has antitrust implications, but nowadays not enough people care about this either
But instead I’ll point out that W3C no longer maintains the html spec. They ceded that to the WHATWG which was spun by the major browser developers in response to the stagnation and what amounted to abandonment of html by the W3C.
Moreover, Google docs says that even even 0.0001% shouldn't be taken lightly.
As I keep saying, the person who's pushing for XSLT removal didn't even know about XSLT uses until after he posted "intent to remove", and the PR to remove to Chrome. And the usage stats he used have been questioned: https://news.ycombinator.com/item?id=45958966
I didn't look at all documents, but Working Mode describing how specs are added or removed doesn't mention users even once. It's all about implementors: https://whatwg.org/working-mode
I’m not surprised they focus on implementors in “working mode”, though. WHATWG specifically started because implementers felt like the W3C was holding back web apps. And it kind of was.
WHATWG seemed to be created with an intent to return to the earlier days of browser development, where implementors would build the stuff they felt was important and tell other implementors how to be compatible. Less talking and more shipping.
Yes, but the "bug" here was "a single website is broken". Here, we are talking about an outcome that will break many websites (more than removing USB support would break) and that is considered acceptable.
> That's a proposal for Javascript, whose controlling body is TC39
Yes, and the culture of TC39 used to be the culture of those who develop tools for using the web (don't break the Space Jam website, etc.)
Also, the entire measurement is fundamentally just part of the decision. Removing Flash broke tons of sites, and it was done anyways because Flash was a nightmare.
> Shipping the feature in Firefox Nightly caused at least one popular website to break.
and links to https://bugzilla.mozilla.org/show_bug.cgi?id=1443630 which points to a single site as being broken. There's no check as to the size of the impacted user base, but there is a link in the blog post to https://www.w3.org/TR/html-design-principles/#support-existi... which says:
> Existing content often relies upon expected user agent processing and behavior to function as intended. Processing requirements should be specified to ensure that user agents implementing this specification will be able to handle most existing content. In particular, it should be possible to process existing HTML documents as HTML 5 and get results that are compatible with the existing expectations of users and authors, based on the behavior of existing browsers. It should be made possible, though not necessarily required, to do this without mode switching.
> Content relying on existing browser behavior can take many forms. It may rely on elements, attributes or APIs that are part of earlier HTML specifications, but not part of HTML 5, or on features that are entirely proprietary. It may depend on specific error handling rules. In rare cases, it may depend on a feature from earlier HTML specifications not being implemented as specified
Which is the "servant-oriented" mindset I'm talking about here.
> Removing Flash broke tons of sites
Yes, but Flash wasn't part of a standard, it was an ad-hoc thing that each browser _happened_ to support (rough consensus and working code). There were no "build on this and we'll guarantee it will continue to work" agreement between authors and implementers of the web. XSLT 1.0, as painful as it is, is part of that agreement.
Flash doesn’t have an RFC because it was a commercial design by Adobe, not because it wasn’t a defined spec that was supported by browsers.
Meanwhile SSLv2 and v3 and FTP and gopher have RFCs and have been removed.
Making an RFC about a technology is not a commitment of any kind to support it for any length of time.
You’ve conjured a mystique around historical browser ideology that doesn’t exist, and that’s why what you’re seeing today that feel at odds with that fantasy.
SSLv2 and v3 all are protocol versions that anyone can still support, and removing support for them breaks certain web properties. This is less of a problem because the implementations of the protocol are themselves time-limited (you can't get an SSL certificate that is valid until the heat death of the universe).
FTP and gopher support wasn't removed from the browser without a redirect (you can install an FTP client or a Gopher client and the browser will still route-out-to-it).
The point isn't "RFC = commitment", the point is that "the culture of the web" has, for a very long time, been "keep things working for the users" and doing something like removing built-in FTP support was something that was a _long_ time in coming. Whereas, as I understand it, there is a perfectly valid way forward for continuing to support this tech as-is in a secure manner (WASM-up-the-existing-lib) and instead of doing that, improving security for everyone and keeping older parts of the web online, the developers of the browsers have decided that "extra work" of writing that one-time integration and keeping it working in perpetuity is too burdensome for _them_. It feels like what is being said by the browser teams is, "Yes, broken websites are bad for end users, yes, there are more end users than developers, yes, those users are less technical and therefore likely are going to loose access to goods they previously had ... but c'est la vie. Use {Dusk, Temple}OS if you don't want the deal altered any further." And I object to what I perceive as a lack of consideration of those who use the web. Who are the people that we serve.