Live data from Hacker News

Google did not unilaterally decide to kill XSLT

meyerweb.com

21–30 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#22
post #18

[flagged]

Which comments did you see as being arrogant?

The one where the guy speaks for the whole Chrome team and says they want work on new stuff rather than fix things they themselves allege are broken. It's extremely ivory tower and a disservice to the web as a whole.

Re: Google did not unilaterally decide to kill XSLT

#23
The people who use these features are busy using these features. And they are not part of browser development. So they revolt in a nasty manner. Like when ftp was torn down.

It is nice to see workarounds. But those workarounds are not conducive to HTML purists who do things without JS. They are the real web developers. They have always relied on the browser to improve and become faster but not start abandoning old technologies.

Chrome OS also became popular on this point that a browser can do things like being universal viewers and so the need for programs goes away. There are so many lite OS who are also using the browser to do everything.

Now I understand that the web has failed XML and XML failed the web in favor of JSON. I also whole heartedly believe that XML and XSLT can do so much more for the web and do this natively.

But open systems are not in the interest of the big FAANG and Microsoft ecosystem. They abandoned RSS. They abandon APIs on a regular basis. And this turn of events is causing browser vendors to start developing for big companies rather than open indie developers.

There is much gain from XML and XSLT. But I want to see a specific development. I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.

Re: Google did not unilaterally decide to kill XSLT

#24
post #14
post #6

A/B testing the removal of a browser standard gives me pause. Is there precedent for that?

Yes, they've done it before. Some example: onunload: https://developer.chrome.com/docs/web-platform/deprecating-u... Mutation events (replaced by MutationObserver): https://developer.chrome.com/blog/mutation-events-deprecatio... FTP URLs: https://developer.chrome.com/blog/deps-rems-95#ftp_support_r... Here's useful documentation on their process, which they sometimes call Chrome Variations and sometimes Origin Trials…

They may be talking about actually removing whole standards not just specifics of standards like this. FTP is close but it was always adjacent to web browsing. Perhaps HTTP 1.0 removal is closest, but is a different level of abstraction than XSLT which is potentially and subtly everywhere.

Re: Google did not unilaterally decide to kill XSLT

#25
post #12

I think a key problem here has nothing to do with the merits of XSLT, but is that some parties involved have no credibility when it comes to their intentions. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.

I think there are two reasonable incompatible points of view at work here:

1. "Play Nice": Browser vendors are trying to do what’s right for the web with budgets that are substantially outside their control. But browser vendors have the right to control their budgets, and to make decisions about what features to support or not to support. Web developers have to persuade browser vendors in order to get what they want; they have no special moral rights here. It is both practical and ethical to treat browser vendors politely, and not to rudely shame them.

(Eric Meyer's blog post here is firmly in the "Play Nice" point of view. "Google has trillions of dollars," he writes. "The Chrome team very much does not.")

2. "Fight the Power": Browser vendors are in a position of power, and that creates a moral responsibility to web developers. Their budgets are substantially within their control, and if their moral duty requires them to spend more on browser development, then that’s what duty requires. Frequently, browser vendors will try to shirk their duty to web developers in order to manage their budgets; this is always wrong, every time they do it.

There are two sub-bullets under "Fight the Power."

2a. When browser vendors shirk their responsibility, we all have a duty to shame the ones doing it in a noisy protest, not because that’s a practical way to persuade browser vendors, but because protesting/shaming wrongdoers in positions of power is ethical for its own sake.

2b. Browser vendors will try to shield themselves from protests by putting “code of conduct” rules in place against protesting/shaming them, especially against personal attacks. But it’s unethical for browser vendors (actors in a position of power) to enforce a code of conduct that prevents powerless web devs from shaming them, so the code of conduct should be protested, too; browser vendors should furthermore be shamed for having a code of conduct that interferes with the right/duty of web devs to protest shameful behavior. At a minimum, web devs should non-violently resist the code of conduct by actively violating it, and by shaming browser vendors for trying to enforce it.

I think the majority point of view here on HN is "Fight the Power." Google's up to no good, again, huh? Then we've all gotta shame them into doing the right thing again with a righteous flame war, no holds barred, including direct personal attacks. ("Should Mason Freed be removed from web standards?")

And if they try to delete/suppress our flamey personal-attack posts calling out their shameful behavior, why, that's even more shameful, and we've gotta call that out, too.

I think both points of view are reasonable. The problem is when people don't even realize that the other point of view exists.

Re: Google did not unilaterally decide to kill XSLT

#26
post #12

I think a key problem here has nothing to do with the merits of XSLT, but is that some parties involved have no credibility when it comes to their intentions. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.

This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours , not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. One of the things I learned about Google during the AMP4Email fiasco is that the st…

[deleted]

Re: Google did not unilaterally decide to kill XSLT

#28
I hope some form of include makes it into the HTML standard and popular browser implementations before XSLT is gone. It’s perhaps the single largest gap in HTML’s capabilities and could reduce need for SSR, JS, and a build step in a lot of circumstances. Until now XSLT has been able to fill that gap for those who need that capability, but if it’s going away…

Re: Google did not unilaterally decide to kill XSLT

#29
post #12

I think a key problem here has nothing to do with the merits of XSLT, but is that some parties involved have no credibility when it comes to their intentions. They might not even realize how bad their credibility is, because they operate in a self-serving echo chamber.

This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours , not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. One of the things I learned about Google during the AMP4Email fiasco is that the st…

> while they destroy the web

Don't you think you're being a little bit dramatic? The chances of anybody who isn't an ubernerd caring about XSLT's removal is exactly 0.

Post reply on HN