Live data from Hacker News

Google did not unilaterally decide to kill XSLT

meyerweb.com

11–20 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#11
My jotted down notes:

1. all major vendors (google, mozilla, webkit) want to remove xslt

2. chrome does not have resources to support xslt

3. removing/disabling xslt will be a slow methodical process. don't panic.

4. when opening a proposal change, a pull request of code changes is mandatory to show exact changes; it is not a "countdown to merge"(sic)

5. info that leaks to the public should include context or links to full context

6. removing xslt support in browsers is not good or bad, but "it depends"

Re: Google did not unilaterally decide to kill XSLT

#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.

Re: Google did not unilaterally decide to kill XSLT

#13
post #5

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. Obligatory: https://xkcd.com/1172/

That's how it happens in OSS development. For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version. See also the fabled backwards compatibility hacks in Windows and graphics drivers. Whether OSS or proprietary software has it worse, I can't even guess.

But the argument is mostly irrelevant here. This is a web platform feature. One of the defining characteristics of the web platform is to be very conservative with backwards compatibility. This has nothing to do with it being OSS.

Re: Google did not unilaterally decide to kill XSLT

#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: https://developer.chrome.com/docs/web-platform/chrome-variat...

Re: Google did not unilaterally decide to kill XSLT

#16
post #5

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. Obligatory: https://xkcd.com/1172/

> I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features.

As opposed to non-OSS, where removing features that paying customers care about is of course trivial?

> Obligatory: https://xkcd.com/1172/

I don't mindless comic and its original context, but it's gotten extremely old seeing it wheeled out to justify completely discarding user input on any change. Sometimes an update does break legitimate workflows, and that is bad.

Re: Google did not unilaterally decide to kill XSLT

#17
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.

Are you talking about Google as a whole?

Re: Google did not unilaterally decide to kill XSLT

#19
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 standards-development folks there... do not know the word no. There is no process to tell them that something should not be done. If you do, you broke the code of conduct, because they're Googlers and they Know Better. People like Mason Freed in the XSLT thread are sad that people trying to tell him no are getting in the way of him talking to people who will tell him yes.

At the point where the courts have determined that Google abuses it's monopoly control of the web, honestly, there's a question why Google is involved in standards-setting as opposed to being relegated to an advisory position required to implement standards as-designed by everyone else.

Re: Google did not unilaterally decide to kill XSLT

#20
post #13
post #5

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features. Obligatory: https://xkcd.com/1172/

That's how it happens in OSS development. For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version. See also the fabled backwards compatibility hacks in Windows and graphics drivers. Whether OSS or proprietary software has it worse, I can't even guess. But the argument is mostly…

> For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version

Sometimes yes, but just as often in corporate world, what happens is that they decide that the feature isnt going to increase growth, so it doesn't make sense to keep it. I think in corporate world xslt would have been killed long long ago.

> This has nothing to do with it being OSS.

It has everything to do with the standard being maintained in the style of open source. The reason why google is getting flak despite firefox being the one to propose killing it is because the google employee is the one opening a github issue.

Post reply on HN