The World Wide Web Page https://xslt.rip is a thing of beauty on multiple levels.
Uncategorized
13
Posts
4
Posters
7
Views
-
The World Wide Web Page https://xslt.rip is a thing of beauty on multiple levels. View source.
https://jwz.org/b/ykxK -
The World Wide Web Page https://xslt.rip is a thing of beauty on multiple levels. View source.
https://jwz.org/b/ykxK@jwz Oh, that is *glorious*! And awesome in its awfulness, I could make a good case that it's an excellent argument in favor of XSLT's death.
-
The World Wide Web Page https://xslt.rip is a thing of beauty on multiple levels. View source.
https://jwz.org/b/ykxK@jwz I like it as a work of art, but I 100% can't tell if the author is in favor of removing XSLT support from the browser or against it.
It's suffering from that Modest Proposal, Poe's Law problem: if I wanted to do a parody of the arguments for keeping it, I'd do it on a page that looks like it fell out of Geocities cache as a reminder that the web is really different from how it was when XSLT was adopted as a standard.
... even the "thoughts and prayers" is a meme that means "I don't actually care about this."
-
undefined oblomov@sociale.network shared this topic
-
@jwz I like it as a work of art, but I 100% can't tell if the author is in favor of removing XSLT support from the browser or against it.
It's suffering from that Modest Proposal, Poe's Law problem: if I wanted to do a parody of the arguments for keeping it, I'd do it on a page that looks like it fell out of Geocities cache as a reminder that the web is really different from how it was when XSLT was adopted as a standard.
... even the "thoughts and prayers" is a meme that means "I don't actually care about this."
@mark @jwz
If you want to see some more “serious” use XML+XSLT in action, I've been playing around with it for a while.This page:
https://labrador.oblomov.eu/uberprufungslisten/
is XML+XSLT, as are the two subpages you can open by clicking on the two headers.
On my website https://wok.oblomov.eu/ I have plots that track my activity over time, with the SVG generated from XML+XSLT, details on the techniques are at
https://wok.oblomov.eu/tecnologia/plotting-xslt/
https://wok.oblomov.eu/tecnologia/plotting-sparklines-xslt/
and
https://wok.oblomov.eu/tecnologia/sparkling-wok-4/ -
@mark @jwz
If you want to see some more “serious” use XML+XSLT in action, I've been playing around with it for a while.This page:
https://labrador.oblomov.eu/uberprufungslisten/
is XML+XSLT, as are the two subpages you can open by clicking on the two headers.
On my website https://wok.oblomov.eu/ I have plots that track my activity over time, with the SVG generated from XML+XSLT, details on the techniques are at
https://wok.oblomov.eu/tecnologia/plotting-xslt/
https://wok.oblomov.eu/tecnologia/plotting-sparklines-xslt/
and
https://wok.oblomov.eu/tecnologia/sparkling-wok-4/as for the Google attack against XSLT, I have just published the second part of what I hope will be a long series (if not else because the longer it is the more we're on with XSLT):
The first part https://wok.oblomov.eu/tecnologia/google-killing-open-web/ contains a lot of historical background on Google's effort against the open web (of which the attacks on XML and XSLT are a nontrivial part); the second part has less history and more wishing:
https://wok.oblomov.eu/tecnologia/google-killing-open-web-2/ -
as for the Google attack against XSLT, I have just published the second part of what I hope will be a long series (if not else because the longer it is the more we're on with XSLT):
The first part https://wok.oblomov.eu/tecnologia/google-killing-open-web/ contains a lot of historical background on Google's effort against the open web (of which the attacks on XML and XSLT are a nontrivial part); the second part has less history and more wishing:
https://wok.oblomov.eu/tecnologia/google-killing-open-web-2/@oblomov @jwz I have a hard time accepting the story as simple as "Google wants to control the web" when Mozilla and Apple are apparently also on-board with jettisoning XSLT support in the browser.
To me, that smacks a lot more of "The browser vendors think this is one responsibility they can get away with shedding without the end user saying 'hey, the browser broke my favorite website'." And I don't really think the reasoning goes much beyond that; browsers are big hairy balls of code these days and any big subsection that can be shed I bet feels tantalizing to shed.
-
@oblomov @jwz I have a hard time accepting the story as simple as "Google wants to control the web" when Mozilla and Apple are apparently also on-board with jettisoning XSLT support in the browser.
To me, that smacks a lot more of "The browser vendors think this is one responsibility they can get away with shedding without the end user saying 'hey, the browser broke my favorite website'." And I don't really think the reasoning goes much beyond that; browsers are big hairy balls of code these days and any big subsection that can be shed I bet feels tantalizing to shed.
-
@oblomov @jwz What does "open" mean in this context?
This is one of the tricky bits of the whole argument I haven't been really able to wrap my head around.
"Open" can't mean as in "Possible to build an alternative browser to the Big Engines" in this context because if that were the goal, removal of something as complicated as XSLT in the feature spec would be a step in that direction, not away from it.
-
@oblomov @jwz What does "open" mean in this context?
This is one of the tricky bits of the whole argument I haven't been really able to wrap my head around.
"Open" can't mean as in "Possible to build an alternative browser to the Big Engines" in this context because if that were the goal, removal of something as complicated as XSLT in the feature spec would be a step in that direction, not away from it.
JavaScript is way more complex than XSLT. So why don't we start by getting rid of that if the aim is to make things simpler and easier to implement?
Oh wait, maybe that was never the point of the removal of XSLT.
-
@oblomov @jwz Because we can implement XSLT in JavaScript but not the other way around. JavaScript has many, many, many issues, but it's a pretty good example of the "airplane rule" in terms of being the "one really good basket we keep all our eggs in" for security-sandbox purposes.
(Personally, I'd be 100% in favor of maintaining the XSLT APIs but under-the-hood implementing them in JavaScript, though that would still need security consideration since they'd likely be running in privileged context that has access to more state than regular in-page JavaScript. Possibly not necessary; I'm not familiar enough with the XSLT spec to guess off the top of my head).
-
@oblomov @jwz Because we can implement XSLT in JavaScript but not the other way around. JavaScript has many, many, many issues, but it's a pretty good example of the "airplane rule" in terms of being the "one really good basket we keep all our eggs in" for security-sandbox purposes.
(Personally, I'd be 100% in favor of maintaining the XSLT APIs but under-the-hood implementing them in JavaScript, though that would still need security consideration since they'd likely be running in privileged context that has access to more state than regular in-page JavaScript. Possibly not necessary; I'm not familiar enough with the XSLT spec to guess off the top of my head).
if they can implement XSLT in JavaScript, why not just transition their implementation to a JS one, since the excuse they gave for removing XSLT is that the library they were relying on was old an insecure? Heck, they even wrote the JS polyfill, and are now asking everyone who uses XSLT to replace their correct markup to use XSLT with an invalid markup to use the JS polyfill they they need to ship themselves.
Because killing off XSLT and XML with it (RSS epsecially) is the point.
-
if they can implement XSLT in JavaScript, why not just transition their implementation to a JS one, since the excuse they gave for removing XSLT is that the library they were relying on was old an insecure? Heck, they even wrote the JS polyfill, and are now asking everyone who uses XSLT to replace their correct markup to use XSLT with an invalid markup to use the JS polyfill they they need to ship themselves.
Because killing off XSLT and XML with it (RSS epsecially) is the point.
@oblomov @jwz I don't think this is a realistic way to attack RSS. Mostly because I don't really buy the narrative "Google killed RSS when they removed Reader."
100% of my podcasts are discovered via RSS or Atom updates. It's entirely possible that RSS was just a bad fit for aggregating updates to pages people read (in fact, I'd argue that this very network we're on right now represents a better model for being kept up-to-date on news).
-
@oblomov @jwz I don't think this is a realistic way to attack RSS. Mostly because I don't really buy the narrative "Google killed RSS when they removed Reader."
100% of my podcasts are discovered via RSS or Atom updates. It's entirely possible that RSS was just a bad fit for aggregating updates to pages people read (in fact, I'd argue that this very network we're on right now represents a better model for being kept up-to-date on news).
@mark @jwz I will stop responding to your posts until you actually go read _in detail_ the two articles of mine I've linked above, since this has all been addressed there and you've obviously either not read them with enough core or are just sealioning, and in either case you're not worth responding to.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
I made this for Chuck Schumer, but, it's evergreen and context doesn't matter.
-
@oblomov@sociale.network @ju@nugole.it
Quello che avevo letto io mostrava che il gatto riconosceva tranquillamente il proprio nome e dei vocaboli precisi, tipo "seduto" per un cane, perché con l'elettroencefalogramma osservavano l'attivazione di certe zone, ma poi decideva che fregacazzi e ignorava bellamente lo stimolo.
Gatti.
Adorabili, maledetti e infami gatti
-
@mark @jwz I will stop responding to your posts until you actually go read _in detail_ the two articles of mine I've linked above, since this has all been addressed there and you've obviously either not read them with enough core or are just sealioning, and in either case you're not worth responding to.
-
@oblomov @jwz I don't think this is a realistic way to attack RSS. Mostly because I don't really buy the narrative "Google killed RSS when they removed Reader."
100% of my podcasts are discovered via RSS or Atom updates. It's entirely possible that RSS was just a bad fit for aggregating updates to pages people read (in fact, I'd argue that this very network we're on right now represents a better model for being kept up-to-date on news).
-
if they can implement XSLT in JavaScript, why not just transition their implementation to a JS one, since the excuse they gave for removing XSLT is that the library they were relying on was old an insecure? Heck, they even wrote the JS polyfill, and are now asking everyone who uses XSLT to replace their correct markup to use XSLT with an invalid markup to use the JS polyfill they they need to ship themselves.
Because killing off XSLT and XML with it (RSS epsecially) is the point.
-
@oblomov @jwz Because we can implement XSLT in JavaScript but not the other way around. JavaScript has many, many, many issues, but it's a pretty good example of the "airplane rule" in terms of being the "one really good basket we keep all our eggs in" for security-sandbox purposes.
(Personally, I'd be 100% in favor of maintaining the XSLT APIs but under-the-hood implementing them in JavaScript, though that would still need security consideration since they'd likely be running in privileged context that has access to more state than regular in-page JavaScript. Possibly not necessary; I'm not familiar enough with the XSLT spec to guess off the top of my head).
-
Testing Whether Fast Charging Kills Smartphone Batteries, And Other Myths
> With batteries being such an integral part of smartphones, it’s little wonder that extending the period between charging and battery replacement has led to many theories and outright myths ab…
