Comment by shadowgovt
9 hours ago
You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.
9 hours ago
You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.
Do you still beat your wife? <https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife?>
I don't think that applies here (especially since I didn't even ask a question).
"I'm sad it's going away in the client!"
"So move it to the server, and the end-user will get essentially the same experience."
Am I missing something here?
> especially since I didn't even ask a question
Oh, that's the operative part? Accept my apologies. What I meant to say is, "I can see that you're deeply, deeply concerned about being able to continue beating your wife. I think you should reconsider your position on this matter."
No question mark, see? So I should be good now.
> Am I missing something here?
Probably not. People who engage in the sort of underhandedness linked to above generally don't do it without knowing that they're doing it. They're not missing anything. It's deliberate.
So, too, I would guess, is the case with you—particularly since your current reply is now employing another familiar underhanded rhetorical move. Familiar because I already called it out within the same comment section:
> The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke.
<https://news.ycombinator.com/item?id=45824392>
1 reply →