Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

461–470 of 559 posts

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

#461
post #209

Earlier quoted context omitted.

I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues. To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute. To be honest if…

If people are upset about xslt being removed, step 1 would have been to actually use it in a significant way on the web. Step 2 would have been to volunteer to maintain libxslt. Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.

What use would count as significant? Only if big corp like Google uses it?

XSLT is used on the web. That's why people are upset about Google & friends removing it while ignoring user feedback.

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

#462
The vision of XML was a semantic web. Nowadays everybody knows that semantic is 'em' and non-semantic is 'b' or 'i'. This is simple, but wrong. In fact a notation is semantic when you can make all the distinctions you care about and (this is important) do not have to make distinctions you do not care about. In this case every distinction means something and thus is semantic.

How do you apply this to documents? They are so different. XML gives the answer: you INVENT a notation that suits just your case and use it. This way you perfectly solve the enigma of semantic.

OK, fine, but what to do with my invented notation? Nobody understands it. Well, that is OK. You want to render it as HTML; HTML has no idea about you notation, but is (was) also a kind of XML, so you write a transformation from your notation to HTML. Now you want to render it for printed media: here is XSL-FO, go ahead. Or maybe you want to let blind people read your document too; here is (a non-existent) AUDIO-ML, just add a transformation into this format. In fact there could be lots of different notations for different purposes (search, for instance) and they are all within a single transformation step.

And for that transformation we give you a tool: XSLT.

(I remember a piece discussed here; it was about different languages and one of examples of very simple languages was XSLT. It is my impression as well; XSLT is unconventional, but otherwise very simple.)

Of course you do not have to invent a new notation each time. It's equally fine to invent small specific notations and mix them with yours.

For example, imagine a specific chess notation. It allows you to describe positions and a sequence of moves, giving you either a party or a composition. You write about chess and add snippets in this notation. First, it can be very expressive; referring to a position should take no more than:

    
Given the party is described this can render the whole board. Or you can refer to a sequence of moves:

    
and this can be rendered in any chess move notation.

And then imagine a specific search engine that crawls the web, indexes parties and compositions and then can search, for example, for other pages that discuss this party, or for similar positions, or for matching sequences of moves.

XML even had a foundation to incorporate other notations. XML itself is, indeed, verbose (although this can be lessened with a good design, which is rare), but starting from v1.0 it has a way to formally indicate that contents of an element are written in a specific notation. If that direction was followed it could lead to things like:

    ... ... 
all in the same document.

The vision of XML was federated web. Lots of notations, big and small, evolving and mixing. It was dismissed on the premise it was too strict. I myself think it was too free.

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

#463
post #391
post #333

Earlier quoted context omitted.

Javascript was instantly a hit from the day it was released, and it grew from there. XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player. There was, at no point, any reason to invest in it any farther. Moreover, even if you pu…

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.

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

#464
post #214

Earlier quoted context omitted.

Also, https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback. It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. This is happening after some serious exploi…

I think this post is useful where the thread author proposed some solutions to the people affected: https://github.com/whatwg/html/issues/11523#issuecomment-318... The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering. I think this could be addressed by introducing a processing instruction that browsers would inter…

Any solution that requires any change to the websites affected, no matter how small, is not a solution at all. DO. NOT. BREAK. THE. WEB.

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

#465
post #356

Earlier quoted context omitted.

Sounds like libxslt needs more than just a small number of fixes, and it sounds like Google could be paying someone, like you, to help provide the necessary guidance and feedback to increase the usability and capabilities of the library and evolve it for the better. Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that hap…

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.

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

#466

Earlier quoted context omitted.

> libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes. I’m having trouble expressing this in a way that won’t likely sound harsher than I really want, but, uh, yes? That’s the fundamental difference between maintaining a part of the commons…

It's one thing if the library was proactively written with ABI compatibility in mind. It's another thing entirely if the library happens to expose all its implementation details in the headers, making it that much harder to change things.

No, it's the same in both cases. ABI stability is what every library should provide no matter how ugly the ABI is.

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

#467
post #241

Earlier quoted context omitted.

Looking at the problem differently. Say some change would make Hacker News unusable, the data would support this and show that it practically affects no one.

First, we are an insignificant portion of the web, and it's okay to admit that. Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.

It's not OK for the Google & co to chip away at "insignificant" portions of the web until all that's left are big corporate run platforms.

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

#468
post #445

Earlier quoted context omitted.

Do Library of Congress and Congress count? https://news.ycombinator.com/item?id=44958929 It's not for the public to identify these sites. It's for the arrogant Googlers to do a modicum of research

At first glance the library of congress link appears to be using server side XSLT, which would not be affected by this proposal. The congress one appears to be the first legit example i have seen. At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.

> Of course someone would have to make that change.

Of course. And yet none of the people from Google even seem to be aware of

> The congress one appears to be the first legit example i have seen.

There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss

Again, none of the people from Google even seem to be aware of these use cases, and just power through regardless of any concerns.

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

#469
post #390

Earlier quoted context omitted.

If this is the reason to remove and or not add something to the web, then we should take a good hard look at things like WebSerial/WebBluetooth/WebGPU/Canvas/WebMIDI and other stuff that has been added that is used by a very small percentage of people yet all could contain various security bugs... If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are…

whatever you do with xslt you can do it in a saner way, but whatever we need to use serial/bluetooth/webgpu/midi for there is no other way, and canvas is massively used.

Of course there is a better way than webserial/bluetooth/webgpu/webmidi: Write actual applications instead of eroding the meaning and user expectations of a web browser. The expectation should not be that the browser can access your hardware directly. That is a much more significant risk for browsers than XSLT could ever be.

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

#470
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…

Bring back VRML! Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :) Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XS…

> Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)

And those that would replace you might care more for the web rather than the next performance review.

Post reply on HN