491–500 of 559 posts
Earlier quoted context omitted.
It would be incredible if we could pull it into the javascript/wasm sandbox and get xslt 3.0 support. The best of both worlds, at the cost of a performance hit on those pages, but not a terrible cost.
Not really, because that would add a dependency on Javascript whereas, at the moment, XSLT works without Javascript enabled.
A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…
Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for con…
Glad to see the disdain for the actual users of their software remains.
[1] https://github.com/whatwg/html/issues/2894 [2] https://www.theregister.com/2021/08/05/google_chrome_iframe/
(FWIW I agree alert and XSLT are terrible, but that ship sailed a long time ago.)
Breaking the fundamental promise of the HTML spec is a big deal. The discussions don't address that. That surprises me, because these seem to be the people in charge of the spec. The promise is, "This is HTML. Count on it." Now it would be just, "This is HTML for now. Don't count on it staying that way, though." Not saying it should never be done, but it's a big deal. They are removing XSLT just for being a long-tail…
That's a concise way to put it. IMHO this is also the main problem of the standard.
However I think XSLT isn't only long tail but also a curiosity with just academic value. I've being doing some experimentation and prototyping with XSLT while it was still considered alive. So even if you see some value in it, the problems are endless:
* XSLT is cumbersome to write and read
* XML is clunky, XSLT even more so
* yes there's SLAX, which is okay-ish but it becomes clear very fast that it's indeed just Syntax sugar
* there's XSLT 2.0 but there's no software support
* nobody uses it, there's no network effect in usage
I think a few years ago I stumbled upon a CMS that uses it and once I accidentally stumbled upon a Website that uses XSLT transformation for styling. That's all XSLT I ever saw in the wild being actually used.
All in all XSLT is a useless part of the way to large long tail preventing virtually everyone from writing spec compliant web browser engines.
> The promise is, "This is HTML. Count on it."
I think after HTML4 and XHTML people saw that a fully rigid standard isn't viable, so they made HTML5 a living standard with a plethora of working groups. Therefore the times where this was ever supposed to be true are long over anyway.
So indeed the correct way forward would be to remove more parts of a long tail that's hardly in use and stopping innovation. And instead maybe keeping a short list of features that allow writing modern websites.
(Also nobody is stopping anyone from using XSLT as primary language that compiles to HTML5/ES5/CSS)
Earlier quoted context omitted.
> Of course. And yet none of the people from Google even seem to be aware of I don't see any reason to assume that. I don't think anyone from google is claiming the literal number of sites is 0, just that it is insignificant. I am very sure the people at google are aware of the rss feed usage. Don't confuse people disagreeing with you with people not understanding you.
> I am very sure the people at google are aware of the rss feed usage. No. No they aren't. As you can see in the discussion: https://github.com/whatwg/html/issues/11523 where the engineer who proposed this literally updates his "analysis" as people point out use cases he missed. Quote: --- start quote --- albertobeta: there is a real-world and modern use case from the podcasting industry, where I work. Collectively,…
Earlier quoted context omitted.
i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.
It solves the problem of not requiring a full turing machine with a giant API that has a history of actual exploits and not just FUD behind it.
it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades.
so the reason XSLT doesn't have a history of exploits is because nobody used it.
Earlier quoted context omitted.
instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395
But can it transform / format the XML?
Earlier quoted context omitted.
> If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. I _do_ use XSLT on my tiny, low-traffic blog, and I _don't_ think that it's reasonable for browser devs to tell me to update my code. Also, it's real easy to manufacture a situation where adoption of a thing is low when the implementation is incomplete and hasn't had significant updates for decades.
The web has grown a thousand fold over those decades, in spite of no support for XSLT. No browser has failed (or gained market traction) by missing support for (or adding more support for) XSLT. It's an irrelevancy, even if you did like it once. Lots of content was lost when Flash was removed as well - much, much more than the amount of content that will be lost if XSLT is removed. And yet the web continued.
Earlier quoted context omitted.
or, the downstream users who use it and benefit directly from it could step up, but websites and their users are extremely good at expecting things to just magically keep working especially if they don't pay for it. it was free, so it should be free forever, and someone set it up many moons ago, so it should keep working for many more magically! // of course we know that, as end-users became the product, Big Tech [si…
Website operators are fine with how libxslt works now. It's browser vendors that want change.
Earlier quoted context omitted.
i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.
You can have template includes that are auto interpreter by the browser - no need to write code AFAIK using XSLT.
in order to create a menu where the current active page is highlighted and not a link, i need to do this:
selected
/
home
|
selected
/about.xhtml
about
|
Earlier quoted context omitted.
i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.
True, but that raises the question, why don't the browsers do that? I think no one would object if they removed XSLT from the browser's core and instead loaded up some WASM/JavaScript implementation when some XSLT is actually encountered. Sort of like a "built-in extension". Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.