I don't disagree that Google is killing the open web. But XSLT is a pretty weak argument for showing that. It is an extremely complicated feature that is very seldom used. I am very doubtful dropping support is some evil political decision. It is much more likely they just don't want to sink resources into maintaining something that is almost never used. For the specific use case of showing RSS and Atom feeds in the…
Google is killing the open web, part 2
121–130 of 362 posts
Re: Google is killing the open web, part 2
#122Earlier quoted context omitted.
Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH. Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.
Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.
Re: Google is killing the open web, part 2
#123Earlier quoted context omitted.
Mozilla's board are basically Google yes-people. I'm convinced Mozilla is purposefully engineered to be rudderless: C-suite draw down huge salaries, approve dumb, mission-orthgonal objectives, in order to keep Mozilla itself impotent in ever threatening Google. Mozilla is Google's antitrust litigation sponge. But it's also kept dumb and obedient. Google would never want Mozilla to actually be a threat. If Mozilla had…
Can you say more about the teams let go who worked on MDN and Rust? Wondering if I can read anything on it to stay up to speed.
Re: Google is killing the open web, part 2
#124Earlier quoted context omitted.
> Removing XSLT from browsers was long overdue > 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…
> 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 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 a…
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.
Re: Google is killing the open web, part 2
#125Earlier quoted context omitted.
Yes that's why XSLT is such a natural fit when you learn about HTML+CSS. It's the same idea, but applied to HTML templates, which is something you immediately want when you hand-write HTML (e.g. navbars, headers, and footers that you can include on every page).
Your problem here is that you're hand-writing HTML including all the templates. This wasn't a good way to do it 30 years ago and it's not a good way to do it now. See all these "static site generators" everyone's into these days? We used those in the mid-90s. They were called "Makefiles".
Re: Google is killing the open web, part 2
#126Earlier quoted context omitted.
I cannot imagine a time when browsers were "servant-oriented". Every browser I can think of was/is subservient to some big-big-company's big-big-strategy.
There have been plenty of browsers that were not part of a big company, either for part or all of their history. They don't tend to have massive market share, in part because browsers are amazingly complex and when they break, users get pissed because their browsing is affected. 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 softwa…
Re: Google is killing the open web, part 2
#127What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to drop support for xslt. If you want to argue that this is bad because it “breaks the web”, that’s fine, but it has nothing at all to do with whether the web is “open”. The open web means anyone can run a web server. Anyone can write a web site. Anyone can build their own compatible browser (hypothetically; this has become prohibitively expensive). It means anyone can use the tech, not that the tech includes everything possible.
If you want to complain about Google harming the open web, there are some real examples out there. Google Reader deprecation probably hurt RSS more than anything else. AMP was/is an attempt to give Google tighter control over more web traffic. Chrome extension changes were pushed through seemingly to give Google tighter control over ad blockers. Gemini in the search results is an attempt to keep Google users from ever actually clicking through to web sites for information.
XSLT in the browser has been dead for years. The reality is that no browser developer has cared about xslt since 1.0. Don’t blame Google for the death of xslt when xslt 2.0 was standardized before Chrome was even released and no one else cared enough to implement it. The removal of xslt doesn’t change the openness of the web and the reality is that it breaks very little while eliminating a source of real security errors.
Re: Google is killing the open web, part 2
#128>Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead. >This is a trillion-dollar ad company who has been actively destroying the open web for over a decade Google has both done more for and invested more into progressing…
If browser vendors had made it easy for mainstream users, would there have been as much "market demand"?
Between killing off Google Reader and failing to support RSS/Atom, Google handed social media to Facebook et al.
Re: Google is killing the open web, part 2
#129In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived…
> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natu…
XSLT is a functional transform language. The equivalent JavaScript would be something like registry of pure functions of Node -> Node and associated selectors and a TreeWalker that walks the XML document, invokes matching functions, and emits the result into a new document.
Or you could consume the XML as data into a set of React functions.
Re: Google is killing the open web, part 2
#130Seems like getting XSLT (and offering a polyfill replacement) is just a move in the direction of stopping applications from pushing their complexity into the browser.