Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

Post reply on HN
Print view View original

371–380 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#371

Post by const_cast »

bawolff wrote: post #349
o11c wrote: post #328

Earlier quoted context omitted.

Counterpoint: most websites are not useful. If we only count useful websites a much higher percentage of them are using XSLT. But useful websites are much less likely to be infested by the all consuming Goo admalware.

[Citation needed] Seriously, i doubt this.

A lot of very old SPA like heavy applications use XSLT. Basically, enterprise web applications (not websites) that predate fetch, rest, and targeted or still target Internet Explorer 5/6.

There was a time where the standard way to build a highly interactive SPA was using SOAP services on the backend combined with iframes on the front end that executed XSLT in the background to update the DOM.

Obviously such an approach is extremely out of date and you won't find it on any websites you use. But, a lot of critical enterprise software was built this way and is kind of stuck like this.

Re: "Remove mentions of XSLT from the html spec"

#372

Post by codedokode »

geocar wrote: post #210
codedokode wrote: post #194

Earlier quoted context omitted.

> I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else. Serving a server-generated HTML page could be even faster.

> Serving a server-generated HTML page could be even faster. Except it isn't. Lots of things could be faster than they are.

Loading one page is probably faster that loading a template and only after that loading the data with the second request, given that the network latency can be pretty high. That's why Google serves (served?) its main page as a single file and not as multiple HTML/CSS/JS files.

Re: "Remove mentions of XSLT from the html spec"

#373

Post by codedokode »

geocar wrote: post #297
codedokode wrote: post #187

Earlier quoted context omitted.

> Sort of. JS is much slower than the native XSLT transform, and the XSLT result is cacheable. That's huge. Nobody is going to process million of DOM nodes with XSLT because the browser won't be able to display them anyway. And one can write a WASM implementation.

I think you're confusing throughput with latency. You're right nobody processes a million DOM nodes with XSLT in a browser, but you're wrong about everything else: WASM has a huge startup cost. Consider applying stylesheet properties: XSLT knows exactly how to lay things out so it can put all of the stylesheet properties directly on the element. Pre-rendered HTML would be huge. CSS is slow. XSLT gets you direct-attac…

That's even a rarer case, embedding CSS rules into XSLT template (if I understood you correctly), I never heard of it. I know that CSS is sometimes embedded into HTML though.

Re: "Remove mentions of XSLT from the html spec"

#374

Post by sugarpimpdorsey »

alfiedotwtf wrote: post #352
sugarpimpdorsey wrote: post #216

Earlier quoted context omitted.

> Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications. Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder…

Maybe because Edge is just a wrapper around Blink?

So Microsoft cucked by Google and Mozilla being a puppet regime of Google at this point.

Seems like a rigged game to me.

Yes it's a wrapper but Microsoft represents a completely different market with individual needs/wants.

If it wasn't for Apple (who doesn't care about enterprise) butting in, the browser consortium would be reminiscent of the old Soviet Union in terms of voting.

Re: "Remove mentions of XSLT from the html spec"

#375

Post by codedokode »

Pxtl wrote: post #335

So Google is bringing the deprecation treadmill to the web, yay! Yegge called it: https://steve-yegge.medium.com/dear-google-cloud-your-deprec... """ > Because I sometimes get similar letters from the Google Cloud Platform. They look like this: >> Dear Google Cloud Platform User, >> We are writing to remind you that we are sunsetting [Important Service you are using] as of August 2020, after which you will not be abl…

But if you live in a capitalist country with a free market, several competitors should pop out and suggest migrating your system into their cloud for free, shouldn't they? No way capitalist overlooks an unoccupied market niche.

Re: "Remove mentions of XSLT from the html spec"

#376

Post by codedokode »

joquarky wrote: post #345
codedokode wrote: post #132

Earlier quoted context omitted.

Adding XSLT support is as absurd as adding React into a browser (especially given that it's change detection is inefficient and requires lot of computation). Instead, browsers should provide better change tracking methods for JS objects.

Knockout.js may be off the radar these days, but has robust handling for this. Still the best framework I've ever worked with.

The downside of knockout was that it used proxies for change tracking, and you had to create those proxies manually, so you cannot have an object with a Number property, you had to have an object with a proxy function as a property.

Re: "Remove mentions of XSLT from the html spec"

#377

Post by timeon »

mr_toad wrote: post #323
sedatk wrote: post #308

I love XSLT. I released a client-side XSLT-based PWA last year ( https://github.com/ssg/eksi-yedek - in Turkish). The reason I had picked XSLT was that the input was in XML, and browser-based XSLT was the most suitable candidate for a PWA. Two years ago, I created a book in memory of a late friend to create a compilation of her posts on social media. Again, thanks to XSLT, it was a breeze. XSLT has been orphaned on t…

I’d just use the browsers XML parser and javascript for the transformation. Which is what I assume a putative XSLT javascript library would do. And if you’re leaning towards a declarative framework, use React.

There are many declarative frameworks. React is one of the slowest.

Re: "Remove mentions of XSLT from the html spec"

#378

Post by xg15 »

jmull wrote: post #207

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…

WHATWG broke this quasi-officially when they declared HTML a "Living Standard". The HTML spec is not a standard to be implemented anymore, it's just a method of coordinating/announcing what the browser vendors are currently working on.

(For the same reason, they dropped the name HTML5 and are only talking about "HTML". Who needs version numbers if there is no future and no past anyway?)

https://whatwg.org/faq#living-standard https://github.com/whatwg/html/blob/main/FAQ.md#html-standar...

Re: "Remove mentions of XSLT from the html spec"

#379

Post by const_cast »

sugarpimpdorsey wrote: post #216
kg wrote: post #133

Earlier quoted context omitted.

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…

> Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications. Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder…

> Did anybody bother checking with Microsoft?

> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?

The juxtaposition of these two statements is very funny.

Firefox actually develops a browser, Microsoft doesn't. That's why Firefox gets a say and Microsoft doesn't. Microsoft jumped off the browser game years ago.

No, changing the search engine from Google to Bing in chromium doesn't count.

Ultimately, Microsoft isn't implementing jack shit around XSLT because they aren't implementing ANY web standards.

Re: "Remove mentions of XSLT from the html spec"

#380

Post by b_e_n_t_o_n »

moritzwarhier wrote: post #174
paulvnickerson wrote: post #156

I support the html and browser spec being greatly simplified in general. Makes it easier to develop competing browsers.

But at the same time, people don't want web pages and web apps to become all fully opaque like Flutter web or complex, minified JS-heavy sites. Even the latter have many a11y benefits of markup. I think that's a tradeoff. Simplest approach would be to just distribute programs, but the Web is more than that! Another simple approach would be to have only HTML and CSS, or even only HTML, or something like Markdown, or H…

I think most people just don't care, although the a11y benefits are truely important. HTML isn't going anywhere and often you need JS to make things more accessible.

But like, most people just want a site to work and provide value, save them time etc and the way the site is built is entirely unimportant. I find myself moving towards that side despite being somewhat of a web purist for years.

Post reply on HN