5 ms·

I'm not personally in the business of maintaining a browser. But if I were, and I were looking to decrease cost of maintenance, "This entire rendering framewor

I'm not personally in the business of maintaining a browser. But if I were, and I were looking to decrease cost of maintenance, "This entire rendering framework that supports a 0.02% use case" would be an outlier for chopping-block consideration. Not all corner-case features match that combination of cost-to-maintain and adoption (after, what, decades at this point?). We wouldn't be arguing the point if the feature in question were fax machine support, right?

righthand 1y ago
Yes we would because people still use fax machines. I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.” Totally brain dead.
- dpark 1y ago
  Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?
  - righthand 1y ago
    Yes I mourn the loss of Gopher, RSS, XML, etc. Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD. You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. All I can do is advocate we support many technologies and ideas. The world you are advocating sounds locked down and uninteresting.
    - shadowgovt 1y ago
      Practically speaking, what does "open web" vs. "Closed web" mean in this context? Is "open web" just "maximally complies with the w3c standard?"
      - righthand 1y ago
        Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. Not: popular browsers needle through technologies and tell everyone they know best Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using. What is open web to you? “Overpaid Mba at Google says this is best so you better fall in line.”
        shadowgovt 1y ago
        Given that the thing we want to support can be supported via server-side translation, client-side translation in JavaScript, or automatic detection and translation via a third-party plugin in JavaScript... What bearing on the open web does it have to preserve this functionality as a JavaScript-accessible API built into the browser? I don't see how removing this API harms the open web. I do see how it imposes some nonzero cost on website maintainers to adapt to the removal of the API, and I respect that cost is nonzero. ... but I also watched OpenGL evolve into OpenGL ES and the end result was a far better API than we started with. I don't think XSLTProcessor joining document.defaultCharset in the history books is damage to the open web. ETA: And not that it matters over-much, but the "overpaid Mba" is an electrical engineering Ph.D who came to software via sensor manufacturing, so if you're going to attempt to insult someone's training, maybe get it right? Not that he'd be wrong if he were an Mba either, mind.
        righthand 1y ago
        No the Mba is Freeds boss who installed him there and ensure he enforces closing of the web. Coming from sensor manufacturing to software isn’t really that impressive but it does make sense why a sensor manufacturing engineer would make arguments for removing a spec like XSLT but not a terribly complicated and security vulnerable spec like bluetooth. Which probably has 10x the complexity and 10x security plane of xslt. Thank you this whole thing is an even bigger joke. Enjoy the precedent this sets for other tech not in the Google stable. You clearly are getting what you want so why continue this discussion. Who are you trying to convince?
    - dpark 1y ago
      The proposal is to remove support and change the standard. Standards evolve. Sometimes features are removed because they are costly to maintain or security problems or both. The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing. > You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. Don’t do this. We can just disagree without resorting to strawman and ad hominem attacks. No one insulted you for holding your opinion. Before this my mental model of you was an engineer who’s frustrated that he’s going to have to do work to deal with the deprecation. I can empathize with that even if I think you are wrong in believing that browsers should invest further in support of xslt. Now I realize you just lack empathy for other engineers who are also forced to make real world trade offs. The fact that you happen to use xslt in the browser does not make it important relative to all the other features browsers support.
      - righthand 1y ago
        > Sometimes features are removed because they are costly to maintain or security problems or both. But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here. There is no negative trade off by maintaining XSLT other than not being lazy developers. I have no empathy for people who hide behind billion dollar corporations and do their bidding. This is not some sort of critical situation, this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.
        shadowgovt 1y ago
        There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt. I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side). > not being lazy developers Laziness is one of the three great virtues of programming. Every second not spent maintaining libxslt is a second we can spend on something more people care about. It's a rule for writers, but it applies to software architecture also: kill your darlings.
  - shadowgovt 1y ago
    Gopher support in browser was never, IIUC, a w3c standard. Piecing the puzzle pieces together from multiple threads: There's an argument to be made that the HTML standard, which post-dates the browser wars and was more-or-less the detente that was agreed upon by the major vendors of the day, includes a rule that no compliant browser should drop a feature (no matter how old or unused that feature is) because "Don't break the web." In other words: it doesn't matter if there's zero users of something in the spec; if it's in the spec and you claim to be compliant, you support it. XSLT has been a W3C recommendation since 1999 and XSLT2 and 3 were added later, and no W3C process has declared it dead. But several browser engines are declaring it's too cumbersome to maintain so they're planning to drop it. This creates an odd situation because generally a detente has held standards in place: you don't drop something people use because users won't perceive the sites that use the tech as broken, they'll perceive your browser is broken and go use someone else's browser. ... except that so many vendors are choosing to drop it simultaneously, and the tech is so infrequently used, that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says. So people are concerned about a perceived shift in the practical "balance of power" between the standards and the browser developers that (reading between the lines) could usher in the bad old days of the Microsoft monopoly again, except that this time it's three or four browser vendors agreeing upon what the web should be and doing it without external input instead of Microsoft doing what it wants and Firefox fighting them / fighting to keep up. Consolidation of most of the the myriad browsers to only be running on three engines enables this.
    - dpark 1y ago
      > that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says. This is coming out of WHATWG so in actuality the spec itself is being updated to remove the functionality. So yes, the end state is very much that devs cannot rely on this functionality.
      - shadowgovt 11mo ago
        Do you have a link to the WHATWG discussion? I went looking for it yesterday and was unable to find details.

righthand 1y ago

Yes we would because people still use fax machines. I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.” Totally brain dead.

dpark 1y ago
Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?
- righthand 1y ago
  Yes I mourn the loss of Gopher, RSS, XML, etc. Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD. You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. All I can do is advocate we support many technologies and ideas. The world you are advocating sounds locked down and uninteresting.
  - shadowgovt 1y ago
    Practically speaking, what does "open web" vs. "Closed web" mean in this context? Is "open web" just "maximally complies with the w3c standard?"
    - righthand 1y ago
      Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. Not: popular browsers needle through technologies and tell everyone they know best Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using. What is open web to you? “Overpaid Mba at Google says this is best so you better fall in line.”
      - shadowgovt 1y ago
        Given that the thing we want to support can be supported via server-side translation, client-side translation in JavaScript, or automatic detection and translation via a third-party plugin in JavaScript... What bearing on the open web does it have to preserve this functionality as a JavaScript-accessible API built into the browser? I don't see how removing this API harms the open web. I do see how it imposes some nonzero cost on website maintainers to adapt to the removal of the API, and I respect that cost is nonzero. ... but I also watched OpenGL evolve into OpenGL ES and the end result was a far better API than we started with. I don't think XSLTProcessor joining document.defaultCharset in the history books is damage to the open web. ETA: And not that it matters over-much, but the "overpaid Mba" is an electrical engineering Ph.D who came to software via sensor manufacturing, so if you're going to attempt to insult someone's training, maybe get it right? Not that he'd be wrong if he were an Mba either, mind.
        righthand 1y ago
        No the Mba is Freeds boss who installed him there and ensure he enforces closing of the web. Coming from sensor manufacturing to software isn’t really that impressive but it does make sense why a sensor manufacturing engineer would make arguments for removing a spec like XSLT but not a terribly complicated and security vulnerable spec like bluetooth. Which probably has 10x the complexity and 10x security plane of xslt. Thank you this whole thing is an even bigger joke. Enjoy the precedent this sets for other tech not in the Google stable. You clearly are getting what you want so why continue this discussion. Who are you trying to convince?
  - dpark 1y ago
    The proposal is to remove support and change the standard. Standards evolve. Sometimes features are removed because they are costly to maintain or security problems or both. The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing. > You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. Don’t do this. We can just disagree without resorting to strawman and ad hominem attacks. No one insulted you for holding your opinion. Before this my mental model of you was an engineer who’s frustrated that he’s going to have to do work to deal with the deprecation. I can empathize with that even if I think you are wrong in believing that browsers should invest further in support of xslt. Now I realize you just lack empathy for other engineers who are also forced to make real world trade offs. The fact that you happen to use xslt in the browser does not make it important relative to all the other features browsers support.
    - righthand 1y ago
      > Sometimes features are removed because they are costly to maintain or security problems or both. But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here. There is no negative trade off by maintaining XSLT other than not being lazy developers. I have no empathy for people who hide behind billion dollar corporations and do their bidding. This is not some sort of critical situation, this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.
      - shadowgovt 1y ago
        There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt. I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side). > not being lazy developers Laziness is one of the three great virtues of programming. Every second not spent maintaining libxslt is a second we can spend on something more people care about. It's a rule for writers, but it applies to software architecture also: kill your darlings.
- shadowgovt 1y ago
  Gopher support in browser was never, IIUC, a w3c standard. Piecing the puzzle pieces together from multiple threads: There's an argument to be made that the HTML standard, which post-dates the browser wars and was more-or-less the detente that was agreed upon by the major vendors of the day, includes a rule that no compliant browser should drop a feature (no matter how old or unused that feature is) because "Don't break the web." In other words: it doesn't matter if there's zero users of something in the spec; if it's in the spec and you claim to be compliant, you support it. XSLT has been a W3C recommendation since 1999 and XSLT2 and 3 were added later, and no W3C process has declared it dead. But several browser engines are declaring it's too cumbersome to maintain so they're planning to drop it. This creates an odd situation because generally a detente has held standards in place: you don't drop something people use because users won't perceive the sites that use the tech as broken, they'll perceive your browser is broken and go use someone else's browser. ... except that so many vendors are choosing to drop it simultaneously, and the tech is so infrequently used, that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says. So people are concerned about a perceived shift in the practical "balance of power" between the standards and the browser developers that (reading between the lines) could usher in the bad old days of the Microsoft monopoly again, except that this time it's three or four browser vendors agreeing upon what the web should be and doing it without external input instead of Microsoft doing what it wants and Firefox fighting them / fighting to keep up. Consolidation of most of the the myriad browsers to only be running on three engines enables this.
  - dpark 1y ago
    > that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says. This is coming out of WHATWG so in actuality the spec itself is being updated to remove the functionality. So yes, the end state is very much that devs cannot rely on this functionality.
    - shadowgovt 11mo ago
      Do you have a link to the WHATWG discussion? I went looking for it yesterday and was unable to find details.