Google did not unilaterally decide to kill XSLT
21–30 of 138 posts
Re: Google did not unilaterally decide to kill XSLT
#22Re: Google did not unilaterally decide to kill XSLT
#23It 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
#24A/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…
Re: Google did not unilaterally decide to kill XSLT
#25I 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.
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
#26I 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…
Re: Google did not unilaterally decide to kill XSLT
#27Re: Google did not unilaterally decide to kill XSLT
#28Re: Google did not unilaterally decide to kill XSLT
#29I 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…
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.
Re: Google did not unilaterally decide to kill XSLT
#30A/B testing the removal of a browser standard gives me pause. Is there precedent for that?